Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Bill Woodger wrote:
I'm moving this to the DFSORT part of the forum so that Kolusu can comment on it.
No pressure, Kolusu... :-)
Not sure what to comment on here as the DSN info is quite different from the DFSORT sysout. I am guessing that this is program invoked sort. Is the program modifying the records to F and passing to DFSORT?
DFSORT messages
Code:
ICE089I 1 OS03QM10.SORT20 .A , INPUT LRECL = 250, TYPE = F
ICE091I 0 OUTPUT LRECL = 250, TYPE = F
Code:
Data Set Name . . . . : XXXX.DS.DATASET.D01
Record format . . . : VBS Used cylinders . . : 4,396
Record length . . . : 256 Used extents . . . : 4
Data Set Name . . . . : XXXX.DS.DATASET.D04
Record format . . . : VBS Used cylinders . . : 4,638
Record length . . . : 256 Used extents . . . : 2
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Yes, this is an old one, perhaps even from the same site. DCPSORT PROC.
Further down is:
Code:
//DCPSORT PROC SP='10,10',SOUT='*',REG=2048K
//*
//* DCP UTILITY ----- SORT/MERGE OF COMPRESSION FILE
//*
//* SYSIN CONTROL CARD STATEMENT
//* OPTION SORTINS=1
//* SORT FIELDS=(N,N,CH,A) (SAME AS NEWSORT)
//* RECORD TYPE=F,LENGTH=(X) (LOGICAL LENGTH)
//*
//* IF MULTI SORTIN EXIST THEN DO
//* OPTION SORTINS=N ----- NO. OF SORTINXX
//* // EXEC DCPSORT
//* //SORTIN01 DD DSN=-----
//* //SORTIN02 DD DSN=-----
//* //SORTIN03 DD DSN=-----
//* //SORTOUT DD DSN=-----
//* //SYSIN DD *
//* OPTION SORTINS=N ----- NO. OF SORTINXX
//*
//* WHERE NN ----- MAX 16
//A EXEC PGM=SORTX,REGION=®
//STEPLIB DD DSN=DCP.DCPLIB,DISP=SHR /* DCP LIBRARY */
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=&SOUT
//SORTIN01 DD DDNAME=SORTIN
Also got to here, in much the same way as enrico once found this :-)
There is a reference to NEWSORT in the above, which links the whole thing to this one. And this one.
So, I guess "DCP" is "DeComPress", a "wrapper" which can be used around DFSORT to turn a "compressed" file (specified as VBS) into its original fixed-length format, and compress it again on the way out.
From the difference in the known LRECL example, the 256 VBS vs 250 F, and connecting it to what the current TS has said, I'd guess that the perhaps only trailing blanks are "compressed", with the two bytes being the "count" of trailing blanks.
IF only trailing blanks are compressed, I can't help but think that VB is better. It has the length of the data, and once it has a control card to know the length of the de-compressed record, it would be no problem to re-create the correct number of trailing blanks and saving two further bytes per record.
However, it seems to have been in use for eight years or more, so maybe they're happy with it.
If VB would work, the records could be used in the SORT without decompression. Even, if only trailing blanks are dropped, the VBS records could be used directly as well.
I wonder if they'll hire me to check everything out? Looks like there could be a mass of savings there...
Let's hope DCP does a bit more than the TS thinks, eh? :-)
