Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
IEFBR14 is a "dummy" program which just returns control to the system immediately. It can be used to allocate/delete files but does not do any record processing. The results of inputting a file created by IEFBR14 to a program are very predictable - you get the ENDFILE condition every time.
You can output records to the file from the program.
If you need a blank record in the file, suggest you try using another utility such as IEBGENER or IEBDG.
@murmohk1
i don't want 2 say "we cannot create the blank file with IEFBR14"
i know we can allocate/delete Files thru IEFBR14
Code:
Reading an empty file?? You should understand the possibilities before using it
.
ADJACTELY!!! so can you please let me know the posssibilities????????
@Garry Carroll
please read the steps below what i am trying to do:
1) STEP1-> thru rexx it will check the dataset either it's on mainframe or not.
2) STEP2-> if DSN is not on mainframe then it will create the file thru IEFBR14.
3) STEP3-> we are using the same file in QUIKJOB, to update the file.
actually my Job is getting Failed with U3336 ABEND in STEP3, when the DSN is not Present , but if dataset is already cataloged and we bypass the STEP2 then we didn’t get any ABEND/Failure.
[/code]
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
Hi,
Quote:
Why we cannot create the blank file with IEFBR14 and then input in to a program and what are the possibilities of unpredictable result?
It's kinda half truth, if your shop is SMS managed (usually most of the shops are these days..) IEFBR14 would create an empty file with proper EOF which would not lead to any "unpredictable" outcome. If the file does not have an EOF marker, the code will typically abend. (case non-SMS managed sites)
The EOF marker is internal, you don't write code to look for the "EOF value" in your program - when program code issues a read, the "at end" condition is raised when the EOF is encountered.
In days past, simply cataloging a dataset caused the problem of no EOF which in turn caused abends (or running with incorrect data). With SMS-managed data, an EOF is created automatically when the file is allocated.
Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
Quote:
please read the steps below what i am trying to do:
1) STEP1-> thru rexx it will check the dataset either it's on mainframe or not.
2) STEP2-> if DSN is not on mainframe then it will create the file thru IEFBR14.
3) STEP3-> we are using the same file in QUIKJOB, to update the file.
If you are checking the existence of the file in REXX why not just create it in the REXX if not found?
Do you expect to update existing records or add new records?
Anuj's suggestion of disp=(MOD,,) seems eminently sensible if just adding records and you wouldn't need REXX to check for existence. If the file is there it stays there, else it gets allocated. The QUIKJOB step would also use DISP=MOD to add to the file.
It's kinda half truth, if your shop is SMS managed (usually most of the shops are these days..)
Just to add my bit to this-
DFSMSdfp comes as default with z/OS, so all the shops using the z/OS should have it.
One more point- I see UNIT=FPRARZ in the JCL, could this be causing any problem? We don't know much about his site standards to know about FPRARZ properties.
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hello,
Quote:
The results of inputting a file created by IEFBR14 to a program are very predictable - you get the ENDFILE condition every time.
Unfortunately, not every time. . .
If the dasd is sms-managed there will be a valid eof. If the dasd is not sms-managed, the results are unpredictable - someimes a dcb mis-match abend occurs, sometimes incorrect data is read depending on what was on the dasd prior to the new file being allocated, sometmes an eof is processed.
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
I use IEFBR14 to create datasets frequently.
In my experience at several shops (my current shop runs z/os and I believe SMS) If DSORG=PS is not specified and you create the dataset with IEFBR14 you may not be able to read it.
I have a question at this point. Maybe expat will come for help here.
Suppose user is creating a dataset in a SMS managed environment without specifying STORCLAS/DATACLAS. Then the ACS routines will decide the DATACLAS. If what douglas has mentioned is correct (DSORG=PS is not specified and you create the dataset with IEFBR14 you may not be able to read it. ) then does it indicate problem related to ACS?
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
The ACS routines have the capability of assigning a default DSORG for new dataset allocations, so if set up correctly they would remove the need for having to specify DSORG in the JCL or panel when a new dataset is allocated.
So, in my view, not a problem with the ACS routines, only the people that wrote them
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
I suppose that to be certain you could always use a little PROC to setup the datasets, and ensure that they are correctly written to to stop any problems.
Here's one I prepared earlier
This one can also create PDS & PDSE datasets, works with GDG's too.
.jpg)
