Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
1. "This manual left intentionally blank". Try a DATASORT. If you have that, you probably have everything. 2. Yes, symbols are great. SyncSORT doesn't call them symbols as such, I think they are "dictionary" or something like that. I've been known to change Kolusu's inline comments to symbols... There was mention of using WORD in Rexx to get the 10th word for something the other day. //THIRDWRD EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SYMNAMES DD * THIRD-WORD,%01 //SYMNOUNT DD SYSOUT=* //SORTOUT DD SYSOUT=* //SYSINDD * SORT FIELDS=COPY INREC PARSE=(%=(ENDBEFR=BLANKS, STARTAT=NONBLANK, STARTAFT=BLANKS), %=(ENDBEFR=BLANKS), THIRD-WORD=(ENDBEFR=BLANKS, FIXLEN=30)), BUILD=(THIRD-WORD) //SORTIN DD * A120 B1230 C0 D12340 E123450F1230 G120 H10 I0J0K0 L0 Adapt by repeating the "%=(ENDBEFR=BLANKS)," an appropriate number of times, and change the symbol name (this is more the power of PARSE, than symbols, but I was reminded). Also, it is very effective to generate a symbol-file in one step, and use the symbol-file in another step. It means, for instance, that you can have a modified value for INCLUDE/OMIT (like a formula to get a selection date), amongst other things. Even for simply saving on the typos when using the same field for the sixth time... makes Sort Cards "self-documenting" :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
If you don't need the physical file for anything except to extract from it, you can just establish a SEQNUM for each selection, and just use an OUTFIL (or more) with your selection by number. Saves the SORT, the creation of the new file, and the processing of the new file, just cutting straight to the chase, the extract(s) you want. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
Just some general suggestions that may be helpful: 1. ICETOOL has a number of commands that may make it easier to do what you want. It's worth getting familiar with it. I've recently discovered that SYNCTOOL handles my ICETOOL jobs just fine. I've not seen a byte of doc on SYNCTOOL, so there may be other options. 2. SORT symbols make almost all sorting (and ICETOOLing) much easier to write, read, and maintain. Symbol definitions are easy to create from DSECTs, header files, etc. by anyone who has edit skillz (or scripting). Again, SYNCSORT supports the same syntax as DFSORT as far as my tests go. sas On Mon, Apr 24, 2017 at 5:40 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Thanks Bill, that put me on the right track. Another regular poster also > offered me some other options offline that might require fewer passes, > which I am exploring. > > I will report back for the archives when I figure out what I am going to > use. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Woodger > Sent: Monday, April 24, 2017 3:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for > changes in RESTART value > > Also, your initial BUILD creates the extra byte which is used. You can > change the subsequent BUILDs to OVERLAY which just change the one byte at > column 5: (will save you one BUILD per record, you'll notice). > > If 220k+ were really large, you could also (since the test values are > mutually exclusive) put the header and trailer processing before the > WHEN=NONE. That you may not notice on 220k+ records. > -- > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
Thanks Bill, that put me on the right track. Another regular poster also offered me some other options offline that might require fewer passes, which I am exploring. I will report back for the archives when I figure out what I am going to use. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: Monday, April 24, 2017 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value Also, your initial BUILD creates the extra byte which is used. You can change the subsequent BUILDs to OVERLAY which just change the one byte at column 5: (will save you one BUILD per record, you'll notice). If 220k+ were really large, you could also (since the test values are mutually exclusive) put the header and trailer processing before the WHEN=NONE. That you may not notice on 220k+ records. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
Also, your initial BUILD creates the extra byte which is used. You can change the subsequent BUILDs to OVERLAY which just change the one byte at column 5: (will save you one BUILD per record, you'll notice). If 220k+ were really large, you could also (since the test values are mutually exclusive) put the header and trailer processing before the WHEN=NONE. That you may not notice on 220k+ records. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
It doesn't matter where you physically locate the SORT control card, SORT will execute after INREC. You need to put anything which the SORT relies upon in INREC, and anything which relies upon the SORT in OUTREC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value
I am trying to partition a fairly large RECFM=VB dataset (220K+ records) by various characteristics of the records using a unique identifier byte and a SEQNUM. The goal is to be able to subsequently extract in a second pass some "count" number of records by "type" to create an extracted sample file with a counted number of each type of record. The original input is sequenced by a record key in bytes 1-136. To start with I am partitioning the records by type, assigning a type identifier and a SEQNUM, but the problem is that the SEQNUM does not restart at 1 for each unique identifier and does not consistently increment by 1 for each record of each type. This is the SYSIN control input: SORT FIELDS=(5,147,CH,A) INREC IFTHEN=(WHEN=INIT, BUILD=(1,4,5:C' ', 6:SEQNUM,10,ZD,START=1,RESTART=(5,1), 16:5)), IFTHEN=(WHEN=(16,2,CH,EQ,X''), HEADER RECORD (1 PER FILE) BUILD=(1,4,5:C'A',6)), IFTHEN=(WHEN=(16,2,CH,EQ,X''), TRAILER RECORD (1 PER FILE) BUILD=(1,4,5:C'Z',6)), IFTHEN=(WHEN=(16,2,CH,EQ,C'D1',AND, FIRST TYPE (1370,1,CH,EQ,C'Y',OR, 1371,1,CH,EQ,C'Y')), BUILD=(1,4,5:C'C',6)), IFTHEN=(WHEN=(16,2,CH,EQ,C'D1',AND, SECOND TYPE (none of this type occur in the example input file) 1604,2,CH,EQ,C'CD'), BUILD=(1,4,5:C'D',6)), IFTHEN=(WHEN=(16,2,CH,EQ,C'D1',AND, THIRD TYPE (1145,1,CH,EQ,C'2',OR, 1145,1,CH,EQ,C'4')), BUILD=(1,4,5:C'E',6)), IFTHEN=(WHEN=NONE, NOT ONE OF THE OTHER TYPES BUILD=(1,4,5:C'B',6)) This control input results in output identifiers "A", "B" and "Z" each getting a SEQNUM starting at 1, but identifiers "C" and "E" (there are no "D" types in the example input file) each seem to start at numbers equal to their record number in the original dataset minus 1 (e.g., input record # 51 is the first type "C" record and gets SEQNUM 50). Subsequent records of each type do not get "prior SEQNUM of unique type + 1" value, but again a SEQNUM equal to their record number in the original dataset minus 1 (e.g., third record of type "C" gets SEQNUM 52 but fourth record of type "C" gets SEQNUM 125). What I want to see in the output is that all unique identifiers get a SEQNUM starting at 1 and incrementing by 1 for each record of that type. Below are example outputs showing the SEQNUM values resulting from the above SORT control instructions. Any help you can provide in generating the result I am aiming to produce is appreciated. Peter Example output results showing only identifier, SEQNUM and first 2 bytes of record: A01.. (This is the header record) B01D1 B02D1 . . . B225201D1 C50D1 (First "C" record Is not SEQNUM 1) C51D1 C52D1 C000125D1 (Fourth "C" record is not thired-record-SEQNUM + 1) C000126D1 . . . C224188D1 E016714D1 (Same issue as for "C" records) E016715D1 E016716D1 E016717D1 E016736D1 (Same issue as for "C" records) E016737D1 . . . E223279D1 (Same issue as for "C" records) E223280D1 E224051D1 (Same issue as for "C" records) E224052D1 Z01..(This is the trailer record) -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
