|
View previous topic :: View next topic
|
| Author |
Message |
RALAKKAL
New User
Joined: 03 Jun 2017
Posts: 11
Location: Canada
|
|
|
|
Hi ,
First of all a Big thank you to the forum administrators for maintaining this forum.
Below is my query.
I am using syncsort and the code is below
| Code: |
//MATCH DD DSN=RQTS.P1.ADO.DAILY.ACTV.PAIRED3,
// DISP=(OLD,CATLG,DELETE),UNIT=DVHSM,
// SPACE=(27998,(100,10),RLSE),
// DCB=(RECFM=VB,BLKSIZE=0,LRECL=204)
//*
//UNMATCH DD DSN=RQTS.P1.ADO.DAILY.ACTV.UNPAIRE3,
// DISP=(OLD,CATLG,DELETE),UNIT=DVHSM,
// SPACE=(27998,(100,10),RLSE),
// DCB=(RECFM=VB,BLKSIZE=0,LRECL=204)
//*
//SYSIN DD *
JOINKEYS FILE=F1,FIELDS=(168,10,A)
JOINKEYS FILE=F2,FIELDS=(01,10,A)
JOIN UNPAIRED
OPTION COPY,VLSHRT
REFORMAT FIELDS=(F1:1,4,F2:1,32,?,F1:5)
OUTFIL FNAMES=MATCH,
INCLUDE=(37,1,CH,EQ,C'B',AND,119,10,CH,EQ,C'SETTLEMENT'),
BUILD=(1,4,37)
OUTFIL FNAMES=UNMATCH,
INCLUDE=((37,1,CH,EQ,C'1'),OR,
(37,1,CH,EQ,C'B',AND,119,10,CH,NE,C'SETTLEMENT')),
BUILD=(1,4,37)
/* |
However iam getting below error.
| Code: |
SYNCSORT LICENSED FOR CPU SERIAL NUMBER 73F27, MODEL 2964 504
SYSIN :
JOINKEYS FILE=F1,FIELDS=(168,10,A)
JOINKEYS FILE=F2,FIELDS=(01,10,A)
JOIN UNPAIRED
OPTION COPY,VLSHRT
REFORMAT FIELDS=(F1:1,4,F2:1,32,?,F1:5)
OUTFIL FNAMES=MATCH,
INCLUDE=(37,1,CH,EQ,C'B',AND,119,10,CH,EQ,C'SETTLEMENT'),
BUILD=(1,4,37)
OUTFIL FNAMES=UNMATCH,
INCLUDE=((37,1,CH,EQ,C'1'),OR,
(37,1,CH,EQ,C'B',AND,119,10,CH,NE,C'SETTLEMENT')),
BUILD=(1,4,37)
WER813I INSTALLATION OPTIONS IN MFX LOAD LIBRARY WILL BE USED
WER276B SYSDIAG= 1854003, 4511262, 4511262, 9904895
WER164B 7,044K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 48K BYTES RESERVE REQUESTED, 1,004K BYTES USED
WER146B 20K BYTES OF EMERGENCY SPACE ALLOCATED
WER481I JOINKEYS REFORMAT RECORD LENGTH= 237, TYPE = V
WER110I MATCH : RECFM=VB ; LRECL= 204; BLKSIZE= 27998
WER110I UNMATCH : RECFM=VB ; LRECL= 204; BLKSIZE= 27998
WER074I MATCH : DSNAME=RQTS.P1.ADO.DAILY.ACTV.PAIRED3
WER074I UNMATCH : DSNAME=RQTS.P1.ADO.DAILY.ACTV.UNPAIRE3
WER247A MATCH HAS INCOMPATIBLE LRECL
WER247A UNMATCH HAS INCOMPATIBLE LRECL
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
WER482I JNF1 STATISTICS
WER483B 3,484K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER483B 0 BYTES RESERVE REQUESTED, 1,000K BYTES USED
WER108I SORTJNF1 : RECFM=VB ; LRECL= 204; BLKSIZE= 27998
WER073I SORTJNF1 : DSNAME=RQTS.P1.ADO.DAILY.ACTV.TESTFILE
WER482I JNF2 STATISTICS |
Would really appreciate if some one can review my Sort card and let me know if any correction needs to be done. |
|
| Back to top |
|
 |
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2263
Location: USA
|
|
|
|
The whole "prefix" in REFORMAT FIELDS=(F1:1,4,F2:1,32,?,... has length (4+32+1)=37 bytes. So the next F1 part begins at position 38.
You need not BUILD=(1,4,37) but BUILD=(1,4,38)
* * *
So, actual problem is not in programming, but in calculation (4+32+1)=37
 |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
Location: Dublin, Ireland
|
|
|
|
RECFM=VB,LRECL=204,BLKSIZE=27998 doesn't seem right either. Specification of space parameter in JCL seems to negate BLKSIZE=0.
e.g. (204 * 137) + 4 = 27952 or (204 * 138) +4 = 28152.
Garry. |
|
| Back to top |
|
|
RALAKKAL
New User
Joined: 03 Jun 2017
Posts: 11
Location: Canada
|
|
|
|
Oh shoot!
I am ashamed!
Can i delete this post  
Thankyou Gary and Ken. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2263
Location: USA
|
|
|
|
| Garry Carroll wrote: |
RECFM=VB,LRECL=204,BLKSIZE=27998 doesn't seem right either. Specification of space parameter in JCL seems to negate BLKSIZE=0.
e.g. (204 * 137) + 4 = 27952 or (204 * 138) +4 = 28152.
Garry. |
Since long time parameter BLKSIZE=0 is supported, to automatically calculate the most appropriate value based on RECFM=/LRECL=/UNIT= |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
Location: Dublin, Ireland
|
|
|
|
| sergeyken wrote: |
| Garry Carroll wrote: |
RECFM=VB,LRECL=204,BLKSIZE=27998 doesn't seem right either. Specification of space parameter in JCL seems to negate BLKSIZE=0.
e.g. (204 * 137) + 4 = 27952 or (204 * 138) +4 = 28152.
Garry. |
Since long time parameter BLKSIZE=0 is supported, to automatically calculate the most appropriate value based on RECFM=/LRECL=/UNIT= |
TS job shows both SPACE=(27998,(100,10),RLSE) and BLKSIZE=0. Syncsort output shows the BLKSIZE as 27998, which is not a value that the system would calculate in this case - but is the value coded in the SPACE parameter
Garry. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2263
Location: USA
|
|
|
|
| Garry Carroll wrote: |
| TS job shows both SPACE=(27998,(100,10),RLSE) and BLKSIZE=0. Syncsort output shows the BLKSIZE as 27998, which is not a value that the system would calculate in this case - but is the value coded in the SPACE parameter |
The value SPACE=(27998,... does not play any role in defining BLKSIZE shown by SYNCSORT.
The value for BLKSIZE is chosen by hierarchy:
1) from DD parameter [DCB=(]BLKSIZE=value, or calculated by zOS from RECFM=/LRECL=/UNIT= when value=0
2) from DSCB for output DSN, if one has been previously created with defined BLKSIZE
3) used the same value as LRECL[+4] when no other definition found |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
Location: Dublin, Ireland
|
|
|
|
| sergeyken wrote: |
| Garry Carroll wrote: |
| TS job shows both SPACE=(27998,(100,10),RLSE) and BLKSIZE=0. Syncsort output shows the BLKSIZE as 27998, which is not a value that the system would calculate in this case - but is the value coded in the SPACE parameter |
The value SPACE=(27998,... does not play any role in defining BLKSIZE shown by SYNCSORT.
The value for BLKSIZE is chosen by hierarchy:
1) from DD parameter [DCB=(]BLKSIZE=value, or calculated by zOS from RECFM=/LRECL=/UNIT= when value=0
2) from DSCB for output DSN, if one has been previously created with defined BLKSIZE
3) used the same value as LRECL[+4] when no other definition found |
So,if the SPACE=(27998,.... doesn't play any role in calculating the value shown in SYNCSORT report, where does it come from? BLKSIZE=0 would not result in this value, based on LRECL=204. Is Syncsort reporting an incorrect blocksize (in which case it is a bug)? Or has Syncsort overridden the system-calculated value and imposed a blocksize based on the SPACE parameter?
Garry. |
|
| Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1427
Location: Bamberg, Germany
|
|
|
|
| @Garry: Try with FB vs VB in a IEFBR14. You will notice the difference. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
Location: Dublin, Ireland
|
|
|
|
| Joerg.Findeisen wrote: |
| @Garry: Try with FB vs VB in a IEFBR14. You will notice the difference. |
Dataset attributes after allocating with IEFBR14 show LRECL=204 & BLKSIZE=0 regardless of whether FB or VB whether I specify SPACE=(27998,.. or SPACE=(TRK,...
I don't see this explaining why Syncsort is reporting a blocksize of 27998?
Garry. |
|
| Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1427
Location: Bamberg, Germany
|
|
|
|
| Although different topic, when I try allocating with VB I get 27998, with FB I see what you commented. Syncsort is correctly reporting a valid BLKSIZE here. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2263
Location: USA
|
|
|
|
| Garry Carroll wrote: |
| So,if the SPACE=(27998,.... doesn't play any role in calculating the value shown in SYNCSORT report, where does it come from? BLKSIZE=0 would not result in this value, based on LRECL=204. Is Syncsort reporting an incorrect blocksize (in which case it is a bug)? Or has Syncsort overridden the system-calculated value and imposed a blocksize based on the SPACE parameter? |
BLKSIZE=0 is converted by z/OS NFS Server while handling DISP=NEW from DD statement. Known values of RECFM=/LRECL=/UNIT= are taken into account.
If any of needed values of RECFM=/LRECL=/UNIT= is not known at dataset allocation time, then acceptable BLKSIZE cannot be calculated.
| z/OS Network File System Guide and Reference wrote: |
| Block size (BLKSIZE) specifies the maximum length, in bytes, of a physical block of storage in MVS. If BLKSIZE(0) is specified, the system will determine the optimal block size based on the maximum record length (LRECL) and the physical characteristics of the disk, or approximately half of a physical track. Half track blocking is optimal in that it reduces the amount of wasted storage on the disk. If BLKSIZE(0) is specified for Direct Access (DA) data sets, the system does not determine the block size. z/OS NFS Server uses a formula to calculate the block size; see blksize(0) in Data set creation attributes syntax. |
Block size and record length
After running SYNCSORT with no DCB parameters specified in the SORTOUT or other output DD, nevertheless good value of BLKSIZE is assigned.
I use BLKSIZE=0 since long time in most of cases. Appropriate values are substituted successfully.
Often, for RECFM=VB, there is no need to calculate exactly BLKSIZE=(LRECL*n + 4), because V-records rarely are all of the same maximum size. It makes sense to choose maximum BLKSIZE fitting the given disk drive.
This commonly used value for commonly used UNIT - 27998 bytes - has been used by someone also to allocate space via parameter SPACE=(27998,... Here it is used ONLY to recalculate required block size of physical record to corresponding number of tracks, or cylinders, - in case different type of drive is ever used. |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
