|
View previous topic :: View next topic
|
| Author |
Message |
deshmukhec
New User
Joined: 23 Jul 2008
Posts: 7
Location: india
|
|
|
|
| Why we cannot create the blank file with IEFBR14 and then input in to a program and what are the possibilities of unpredictable result? |
|
| Back to top |
|
 |
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
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.
Regards,
Garry. |
|
| Back to top |
|
|
deshmukhec
New User
Joined: 23 Jul 2008
Posts: 7
Location: india
|
|
|
|
@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] |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
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. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
Hi,
| Quote: |
| my Job is getting Failed with U3336 ABEND in STEP3, when the DSN is not Present |
A very wild guess- how about using DISP=(MOD,?,?) |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
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.
Regards,
Garry. |
|
| Back to top |
|
|
deshmukhec
New User
Joined: 23 Jul 2008
Posts: 7
Location: india
|
|
|
|
please see the Program:
| Code: |
/TEST123 JOB ('xxxP77',12),'RAJ',
// MSGCLASS=T,CLASS=4,REGION=0M
//STEP1 EXEC CMDEXIST,
// CLIST=PPC.TSG.REXX,
// CLNAME=DSNFIND,
// DSNAME=T91IPXX.DGN.SUPP.CHKTAB.M0508
//*
//* IF FILE NOT EXIST
//*
//IFSTEP IF STEP1.EXIST.RC¬=0 THEN
//STEP2 EXEC PGM=IEFBR14
//DD1 DD DSN=T91IPXX.DGN.SUPP.CHKTAB.M0508,
// DISP=(,CATLG,DELETE),
// UNIT=FPRARZ,
// SPACE=(CYL,(10,10),RLSE),
// DCB=(RECFM=FB,LRECL=21,BLKSIZE=27993)
// ENDIF
//*
//STEP3 EXEC PGM=QUIKJOB,PARM='9006X'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSUT1 DD DSN=T91IPXX.DGN.SUPP.CHKTAB.M0508,DISP=SHR
//SYSUT2 DD DSN=&&CHKTMP,
// DISP=(,PASS,),
// UNIT=SYSWRK,
// SPACE=(CYL,(10,10),RLSE),
// DCB=(RECFM=FB,LRECL=21,BLKSIZE=27993)
//SYSIN DD DSN=T91IPXX.PROD.QJOBLIB(RAJQJOB),DISP=SHR
//*
//STEP4 EXEC PGM=SYNCGENR
//SYSIN DD DUMMY
//SYSUT1 DD DSN=&&CHKTMP,DISP=(OLD,DELETE)
//SYSUT2 DD DSN=T91IPXX.DGN.SUPP.CHKTAB.M0508,
// DISP=(,CATLG,DELETE),
// UNIT=FPRARZ,
// SPACE=(CYL,(10,10),RLSE),
// DCB=(RECFM=FB,LRECL=21,BLKSIZE=27993)
//SYSPRINT DD SYSOUT=*
//* |
|
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
Location: Dublin, Ireland
|
|
|
|
I would think that you don't need the REXX step. Coding DISP=(MOD,CATLG,DELETE) in STEP02 should be enough.
You have the same file then as DISP=SHR in STEP03 and again as DISP=(,CATLG,DELETE) in STEP04. This will surely give you a JCL error in STEP04 ??
Regards,
Garry. |
|
| Back to top |
|
|
Bill Dennis
Active Member
Joined: 17 Aug 2007
Posts: 562
Location: Iowa, USA
|
|
|
|
rajesh said:
| Code: |
| actually my Job is getting Failed with U3336 ABEND in STEP3 (QUIKJOB) |
What does the U3336 mean to QUIKJOB? This may be more helpful. |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
| Back to top |
|
|
agkshirsagar
Active Member
Joined: 27 Feb 2007
Posts: 691
Location: Earth
|
|
|
|
| Quote: |
| 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. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
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.
Yup, and one should be locked - suggestions? |
|
| Back to top |
|
|
Douglas Wilder
Active User
.jpg)
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.
| Code: |
Dsorg Recfm Lrecl Blksz
------------------------------------------------------------------
hlq.TESTBR14.NODSORG FB 80 0
hlq.TESTBR14.WDSORG PS FB 80 27920 |
I would use DCB=(RECFM=FB,LRECL=21,BLKSIZE=0,DSORG=PS)
As mentioned before if DISP=(MOD,CATLG,CATLG) is used the REXX to check to see if the dataset exists will not be needed. |
|
| Back to top |
|
|
agkshirsagar
Active Member
Joined: 27 Feb 2007
Posts: 691
Location: Earth
|
|
|
|
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? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
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  |
|
| Back to top |
|
|
deshmukhec
New User
Joined: 23 Jul 2008
Posts: 7
Location: india
|
|
|
|
many thanks for all instructive suggetions.
now what i tried is instead of using IEFBR14 i am creating/updating the dataset through Quikjob and it went fine.
again many thanks for your help 
|
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
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.
| Code: |
//*
//SETFILE PROC DSN=,RF=,LR=,UN=TRK,PR=1,SC=1,DR=
//SETFILE EXEC PGM=IEBGENER
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DUMMY,RECFM=&RF.,LRECL=&LR
//SYSUT2 DD DSN=&DSN.,
// DISP=(,CATLG,DELETE),
// SPACE=(&UN.,(&PR.,&SC.&DR.)),
// RECFM=&RF.,LRECL=&LR
//SETFILE PEND
//*
//FILE01 EXEC SETFILE,
// DSN='data.set.name',
// RF=FB,LR=80,DR=',44'
//*
//FILE02 EXEC SETFILE,
// DSN='data.set.name(+1)',
// RF=FB,LR=80
|
FILE01 is a PDS with 44 directory blocks
FILE02 is a plain old PS file AND a GDS as well. |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
