Joined: 12 Apr 2012 Posts: 28 Location: LA, California
Hi All
I have been trying to understand why the RECFM of my IAM VSAM file has been assumed F or V in different cases.
To be more clear, I have a VB VSAM file from which I need to extract few records. I say its a VB vsam file because the AVG record length and the MAx record length are different.
My JCL has a step to extract few records from my VSAM file.
SYSIN :
SORT FIELDS=COPY
INCLUDE COND=(5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002')
WER161B ALTERNATE PARM USED
WER276B SYSDIAG= 946049, 2835054, 2835054, 1986975
WER164B 8,864K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 1,424K BYTES USED
WER146B 32K BYTES OF EMERGENCY SPACE ALLOCATED
[color=red]
WER108I SORTIN : RECFM=F ; LRECL= 4978; CISIZE = 22528
WER073I SORTIN : DSNAME=PROD.MASTER.MARKET
WER110I SORTOUT : RECFM=FB ; LRECL= 4982; BLKSIZE= 24910
WER074I SORTOUT : DSNAME=TEST.MASTER.WORK.MARKETO.OUTFB
[/color]
WER410B 7,836K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER410B 0 BYTES RESERVE REQUESTED, 1,296K BYTES USED
WER055I INSERT 0, DELETE 27113
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
WER416B VSAM WAS USED FOR SORTIN
WER416B SORTOUT : EXCP'S=0,UNIT=3390,DEV=BE74,CHP=(7778797A8788898A,1),VOL=TSTG85
WER054I RCD IN 27113, OUT 0
WER169I RELEASE 1.4 BATCH 0520 TPF LEVEL 0.1
WER052I END SYNCSORT - TESTJCLA,STEP020,,DIAG=CA00,51C6,E22C,006E,82D2,6CCB,2228,04E0
STEP030 SYSOUT:
Code:
SYSIN :
SORT FIELDS=COPY
INCLUDE COND=(5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002')
WER161B ALTERNATE PARM USED
WER276B SYSDIAG= 940500, 2829505, 2829505, 1986975
WER164B 8,864K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 1,404K BYTES USED
WER146B 32K BYTES OF EMERGENCY SPACE ALLOCATED
[color=red]
WER108I SORTIN : RECFM=V ; LRECL= 4978; CISIZE = 22528
WER073I SORTIN : DSNAME=PROD.MASTER.MARKET
WER110I SORTOUT : RECFM=VB ; LRECL= 4982; BLKSIZE= 27998
WER074I SORTOUT : DSNAME=TEST.MASTER.WORK.MARKETO.OUTVB
[/color]
WER410B 7,836K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER410B 0 BYTES RESERVE REQUESTED, 1,280K BYTES USED
WER055I INSERT 0, DELETE 27067
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
WER416B VSAM WAS USED FOR SORTIN
WER416B SORTOUT : EXCP'S=1,UNIT=3390,DEV=3838,CHP=(4C4D4E4F5C5D5E5F,1),VOL=TSTG36
WER054I RCD IN 27113, OUT 46
WER169I RELEASE 1.4 BATCH 0520 TPF LEVEL 0.1
WER052I END SYNCSORT - TESTJCLA,STEP030,,DIAG=8000,5346,A82A,0064,C8D6,6CEB,2A28,A4E6
My Question is , why does the SORTIN assume the RECFM as F in step020 and RECFM as V in step030.
Has that assumed the RECFM based on the SORTOUT RECFM ?? If so why shud it. Note that only the STEP030 has got some output records.
If the SORTIN were an flat file the step020 would have abended for sure. I have tested that as well and it abended. Should the above JCL also not abend considering this... ?
Background:
In my prod job it was mistakenly given as FB in the SORTOUT recfm and because of that the Job extracted no records and it failed in the corresponding step as per the logic. When we analysed we found that the RECFM in the output step was the reason and hence the condition is position 5 did not match out exactly. That is when i got this doubt and tested with two different RECFM in the sortout and found the RECFM of the SORTIN is assumed differently in both the cases.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Vinodh S,
What are you trying to do with this?
Code:
INCLUDE COND=(5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002')
No matter how many times you ask the same question, the answer will always be the same, if nothing has changed, and here there has been no opportunity for change...
Joined: 12 Apr 2012 Posts: 28 Location: LA, California
Bill Woodger wrote:
Vinodh S,
What are you trying to do with this?
Code:
INCLUDE COND=(5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'HASD0002')
No matter how many times you ask the same question, the answer will always be the same, if nothing has changed, and here there has been no opportunity for change...
Hi All
Sorry, with the SORTCARD having the same Include cond. Its different , but when i just pasted here, I changed it. It would be something like this.
Code:
INCLUDE COND=(5,8,CH,EQ,C'HASD0002',OR,
5,8,CH,EQ,C'GSPD0002',OR,
5,8,CH,EQ,C'LOWE0002',OR,
5,8,CH,EQ,C'KNWE0003')
Joined: 12 Apr 2012 Posts: 28 Location: LA, California
Nic Clouston wrote:
Possibly the difference is because in your first sort you specified RECFM=FB for SORTOUT and in the second your RECFM=VB
Nic, thats exactly is what my question is. Why should the Input file attributes change upon what my Output Attribute is ? Should the Input file's attribute not be retained what ever the case be.. ?
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Quote:
Why should the Input file attributes change upon what my Output Attribute is ? Should the Input file's attribute not be retained what ever the case be.. ?
Because VSAM files do not use record descriptor words; hence SORT is determining whether to treat the input file as fixed or variable based UPON WHAT YOU TELL SORT about the output file. VSAM files, since you must specify average and maximum record length for every KSDS file, may be treated as always having variable length records so the behavior you are experiencing is not entirely unexpected. You don't tell SORT via control statements whether or not the input file is fixed or variable, so it is reasonable for SORT to use the output file attributes to determine what the input file attributes are.
