View previous topic :: View next topic
|
Author |
Message |
f8ful
New User
Joined: 02 Nov 2006 Posts: 30
|
|
|
|
I have a sequential file I'm modding to. When I run a batch job to mod the file the attributes of the "modded to" file are being changed. How can I prevent this?
Before attributes of the input and output file:
Record format . . . : VB
Record length . . . : 0
Block size . . . . : 32760
Attributes after modding:
Record format . . . : VB
Record length . . . : 32756
Block size . . . . : 32760
The JCL I've tried to mod
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=(Indataset),DISP=SHR
//SYSUT2 DD DSN=(Outdataset),DISP=MOD,
// DCB=(RECFM=VB,LRECL=0,BLKSIZE=32760)
//SYSIN DD DUMMY
and
//SYSUT1 DD DSN=(Indataset),DISP=SHR
//SYSUT2 DD DSN=(Outdataset),DISP=MOD,
// DCB=(RECFM=VB,BLKSIZE=32760)
and
//SYSUT1 DD DSN=(Indataset),DISP=SHR
//SYSUT2 DD DSN=(Outdataset),DISP=MOD
All JCL has produced the same results.
There must be some type of JCL coding that will prevent the LRECL from changing.
Thanks. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
There must be some type of JCL coding that will prevent the LRECL from changing. |
Actually, no there does not have to be.
LRECL=0 is valid ONLY for RECFM=U. Your data set is VB, not U, and hence it is NOT valid for you to have LRECL=0. The system is properly changing your invalid value to a valid value. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2024 Location: USA
|
|
|
|
Parameter LRECL (and other DCB subparameters) from DD statement always have priority over the same values stored in DSCB (e.g. “dataset control block”). Whenever your output dataset is OPEN/CLOSED, those high-priority values do mandatory replace the previous ones.
BTW: if no LRECL>0 were defined anywhere, then most likely you would get OPEN ABEND... |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
The probability is high that it was IEBGENER that changed the LRECL, because it was 0. Look in the IEBGENER SYSPRINT data set: I think you will see a message that it copied the input LRECL to the output LRECL.
Mr. Sample is incorrect when he says LRECL 0 is valid only for RECFM U. It is always valid when allocating a data set; it must be set before opening the data set for the first time. For V record formats the LRECL defines the maximum length for the data set. The exception to that particular rule is RECFM U data sets where BLKSIZE defines the maximum record length; Assembler programs that use QSAM to write to the data set use LRECL to specify the length of the next record the program is writing to the data set. |
|
Back to top |
|
|
f8ful
New User
Joined: 02 Nov 2006 Posts: 30
|
|
|
|
Thanks all. In particular Steve Myers. Yes it was IEBGENER with the SYSPRINT message you mentioned, causing the problem. I used another utility to do the MOD and it did not change the LRECL upon the mod. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2024 Location: USA
|
|
|
|
f8ful wrote: |
Thanks all. In particular Steve Myers. Yes it was IEBGENER with the SYSPRINT message you mentioned, causing the problem. I used another utility to do the MOD and it did not change the LRECL upon the mod. |
It all sounds like playing an unknown game with the computer...
Doesn’t make any sense. What is your goal in doing this strange activity? |
|
Back to top |
|
|
|