IBM Mainframe Forum

Hi All,

i am new to assembly programming, this question may be small one.... but i am not able to get it.
I have a assembler program.. where it is not handling the input file status(like file empty or not).
in my job there are two input files and one output file.... job is getting abended if my input files are empty or any one of the input file is empty.

i have tried resolving through JCL condition parameters and IDCAMS,ICETOOL... but in my condition all steps need to run even if file is empty.

can you somehelp me how to handle this abend. if any code changes is requried ... what all i need to include in my assembly program.

Thanks

1) Where is any code: what did you try?

2) What are any relations between mentioned: Assembly, JCL, IDCAMS, ICETOOL, jobs, files, input(s), … - ???

Are you aware that z/OS treats data sets with no records (that is, a record has been written to the data set at some point but it no longer has any records in it) differently than empty (that is, no records have ever been written to the data set). If the data set is empty (as opposed to not having any records), you'll need to open the data set for output (either in a program or a system utility -- note that IEFBR14 cannot be used for this since it does not open the data set) before you can use the data set as input to any program.

There are five situations.

1. A data set designated in JCL that does not exist on the volume allocated by the DD statement.
2. A non-SMS sequential data set that has just been allocated but never written to. This is the toughest.
3. An SMS sequeuntial data set that has just been allocated but never written to.
4. A sequential data set that has been opened for output but has no records in the data set before the data set is closed.
5. A data set designated as a PDS member in JCL, but the member does not exist in the data set.

1. Provided the DD statement allocated a disk volume, your program can check, before you attempt to open the data set that the data set exists. If the data set is designated as a tape data set you cannot pre test and have to accept the ABEND.
2. As above, provided the data set is on DASD, you have the data set's Format 1 DSCB. Investigate DS1LSTAR in the Format 1 DSCB. If it is binary 0s, the data set is empty. If you open this mess and try to read it, most likely you will get whatever existed in the space before it was reallocated to your program. Most likely some sort of I/O error.
3. When an SMS sequential data set is allocated, the system writes a DASD end of data set record on the first track. An attempt to read this data set will result in an immediate end of data set.
4. The system will write an end of data set record so that an attempt to read the data set will result in an end of data set.
5. You have to test if the member exists. This van be done quite easily.
   1. As preparation to determine if the data set exists you will have read the JFCB for the data set. Check bit JFCPDS in JFCBIND1 to determine if the JCL specifies a member name.
   2. To determine if the member exists, open the data set with an EXCP DCB and use the BLDL macro to determine if the member exists.

These users thanked the author steve-myers for the post:

sreekanth_reddy (Fri Apr 17, 2020 1:55 pm)

Robert Sample wrote:note that IEFBR14 cannot be used for this since it does not open the data set) before you can use the data set as input to any program.

This was true a long time ago, and it really caused a lot of problems (because just allocated space on disk contained some previous unexpected records, not limited by EOF physical marker). Attempt to read just allocated dataset resulted in I/O error in 99.99% of times, or in reading some garbage information in 0.01% of other cases.
This problem has been fixed by IBM long time ago as well; now after DISP=NEW is handled, also EOF marker is placed at the very beginning of the dataset, to make it "really empty", e.g. "containing no records".

I will not respond to PMs in this topic. If you want a response, post your concern with the main topic.

A response to a PM amounts to unpaid consulting, which I will not do, both because I am retired and unwilling to compete in that that marketplace, and also because many colleagues are not retired and need the work.