Syncsort question: Why do I get error RDW NOT INCLUDED?

[Farley, Peter x23353]

I am trying to set up a Syncsort OUTREC to overlay certain fields in VB records. This is the OUTREC I have:

OUTREC IFTHEN(WHEN=(0032,1,CH,EQ,C'1'),
OVERLAY=(1,4,
32:32,2,C'7X',
358:358,2,C'F#',
366:366,1,C'C')),
IFTHEN(WHEN=NONE,
BUILD=(1,4,5:5))

I get these Syncsort messages:

WER276B SYSDIAG= 1680787, 4697249, 4697249, 4893065
WER164B 1,028K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 156K BYTES RESERVE REQUESTED, 1,000K BYTES USED
WER146B 24K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I SORTIN : RECFM=VB ; LRECL= 8004; BLKSIZE= 27998
WER073I SORTIN : DSNAME=HLQ.INPUT.FILE
WER235A OUTREC RDW NOT INCLUDED
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000

I think I am including the RDW in each of the IFWHEN phrases (1,4). Can anyone tell me what I am doing wrong here?

TIA for any help you can provide.

Peter


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 list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Lizette Koehler]

Message states:

WER235A {ddname} {INREC,OUTREC} RDW NOT INCLUDED

EXPLANATION: The ddname will be SORTOUT, SORTOFxx, SORTOFx or the
ddname provided by an OUTFIL FNAMES parameter. Four bytes must be
provided for the RDW of the variable length output record in
the FIELDS parameter of the INREC, OUTREC or OUTFIL OUTREC
specification. These bytes must appear at the beginning of the record and
must not be edited.


Lizette

[Clark Morris]

On 21 Oct 2015 15:57:42 -0700, in bit.listserv.ibm-main you wrote:

>Message states:
>
>WER235A {ddname} {INREC,OUTREC} RDW NOT INCLUDED
>
>EXPLANATION: The ddname will be SORTOUT, SORTOFxx, SORTOFx or the
>ddname provided by an OUTFIL FNAMES parameter. Four bytes must be
>provided for the RDW of the variable length output record in
>the FIELDS parameter of the INREC, OUTREC or OUTFIL OUTREC
>specification. These bytes must appear at the beginning of the record and
>must not be edited.
>

Why can't COBOL record descriptions be used like they could in
SYNCSORT for HP-UX in 2002?

Clark Morris

[Farley, Peter x23353]

Answered my own question by experimentation. Seems that OVERLAY is just like BUILD except that it does not permit the shorthand notation of "position:position" at the end of the specifications to mean "from here to the end of the record, however long it may be". And OVERLAY is not needed to overlay values in certain positions, BUILD will do that just fine.

For the archives, this is the revised OUTREC which works:

OUTREC IFTHEN=(WHEN=(32,1,CH,EQ,C'1'), FOR RECORDS WITH THIS VALUE ONLY
BUILD=(1,4,5:5,27, RDW + UP TO FIRST CHANGE
32:C'7X', FIRST CHANGE
34:34,323, UP TO NEXT CHANGE
358:C'F#', NEXT CHANGE
360:360,5, UP TO LAST CHANGE
366:C'C', LAST CHANGE
367:367)), REST OF RECORD
IFTHEN=(WHEN=NONE, ALL OTHER RECORDS
BUILD=(1,4,5:5)) OUTPUT AS-IS

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Wednesday, October 21, 2015 5:29 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Syncsort question: Why do I get error RDW NOT INCLUDED?

--

[Farley, Peter x23353]

It can. See sort docs on the SYMNAMES input DD for the sort (either Syncsort or DFSORT), and IBM (well, actually I think it was Frank Yeager or one of his close cohorts) provided us with a nice Rexx tool to convert COBOL copy books to SYMNAMES input.

ftp://ftp.software.ibm.com/storage/dfsort/mvs/cobdfsym.txt

Search for COBDFSYM on the web to see more information and IBM-MAIN postings about it. The only drawback is that it expects compiler listing output from Enterprise COBOL 4.1, so we will certainly need an update to that tool when we move to COBOL 5.x.

There is also a small trove of interesting SORT papers and examples here:

http://www-01.ibm.com/support/docview.wss?rs=114&uid=isg3T7000097

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Clark Morris
Sent: Wednesday, October 21, 2015 11:03 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Syncsort question: Why do I get error RDW NOT INCLUDED?

On 21 Oct 2015 15:57:42 -0700, in bit.listserv.ibm-main you wrote:

<Snipped>

Why can't COBOL record descriptions be used like they could in
SYNCSORT for HP-UX in 2002?

Clark Morris

--

[Clark Morris]

On 22 Oct 2015 08:09:23 -0700, in bit.listserv.ibm-main you wrote:

>It can. See sort docs on the SYMNAMES input DD for the sort (either Syncsort or DFSORT), and IBM (well, actually I think it was Frank Yeager or one of his close cohorts) provided us with a nice Rexx tool to convert COBOL copy books to SYMNAMES input.
>
>ftp://ftp.software.ibm.com/storage/dfsort/mvs/cobdfsym.txt
>
>Search for COBDFSYM on the web to see more information and IBM-MAIN postings about it. The only drawback is that it expects compiler listing output from Enterprise COBOL 4.1, so we will certainly need an update to that tool when we move to COBOL 5.x.

Syncsort for HP-UX read the COBOL record definition. Unfortunately
SYNCSORT manuals aren't available online.

Clark Morris

>
>There is also a small trove of interesting SORT papers and examples here:
>
>http://www-01.ibm.com/support/docview.wss?rs=114&uid=isg3T7000097
>
>HTH
>
>Peter
>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Clark Morris
>Sent: Wednesday, October 21, 2015 11:03 PM
>To: IBM-...@LISTSERV.UA.EDU
>Subject: Re: Syncsort question: Why do I get error RDW NOT INCLUDED?
>
>On 21 Oct 2015 15:57:42 -0700, in bit.listserv.ibm-main you wrote:
>
><Snipped>
>Why can't COBOL record descriptions be used like they could in
>SYNCSORT for HP-UX in 2002?
>
>Clark Morris

[Farley, Peter x23353]

That would be a very significant and useful addition to SORT capabilities from either vendor.

There are "gotcha's" though, like when the COBOL copy book written by the programmer uses illegal COBOL strings to allow REPLACE of the high-level part of the data names in the definition file/member, like this:

01 :HLN:-RECORD-AREA.
05 :HLN:-FIELD-1 PIC X(10).
05 :HLN:-FIELD-2 PIC S9(5)V9(2) COMP-3.

Use of a direct-copybook-read process would require (like the COBDFSYM process requires a dummy program compile) some other process or parameters to expand any required REPLACE strings, or a separate "sort" copy of the definition with all REPLACE strings already resolved.

Not to say it cannot be programmed (SMOP), but definitely a factor to be considered.

Plus once COBOL is supported, what about assembler DSECTS, PL/1 DECLARE's, C struct's and typedef's? I'm sure users of those languages would also want that kind of support. That gets really complex really quickly.

--

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.

[Bill Woodger]

On Wednesday, October 21, 2015 at 10:29:04 PM UTC+1, Farley, Peter x23353 wrote:
> I am trying to set up a Syncsort OUTREC to overlay certain fields in VB records. This is the OUTREC I have:
>
> OUTREC IFTHEN(WHEN=(0032,1,CH,EQ,C'1'),
> OVERLAY=(1,4,
> 32:32,2,C'7X',
> 358:358,2,C'F#',
> 366:366,1,C'C')),
> IFTHEN(WHEN=NONE,
> BUILD=(1,4,5:5))
>
> I get these Syncsort messages:
>
> WER276B SYSDIAG= 1680787, 4697249, 4697249, 4893065
> WER164B 1,028K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
> WER164B 156K BYTES RESERVE REQUESTED, 1,000K BYTES USED
> WER146B 24K BYTES OF EMERGENCY SPACE ALLOCATED
> WER108I SORTIN : RECFM=VB ; LRECL= 8004; BLKSIZE= 27998
> WER073I SORTIN : DSNAME=HLQ.INPUT.FILE
> WER235A OUTREC RDW NOT INCLUDED
> WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
>
> I think I am including the RDW in each of the IFWHEN phrases (1,4). Can anyone tell me what I am doing wrong here?
>
> TIA for any help you can provide.
>
> Peter
>

Your actual problem is that you are trying to amend the RDW with OVERLAY. Don't do that. I don't have access to SyncSORT, so can't check for certain that that produces that particular message, which would be a bit confusing.

When using BUILD for a variable-length record, an RDW must always be specified. Maintenance of the values in the RDW is entirely down to the SORT product. BUILD always makes a new copy of the current record.

When using OVERLAY, which affects the current copy of the current record, there is already an RDW present, and since SORT is maintaining it, SORT will moan if you try to do something with it.

Note that with OVERLAY it is pointless to set a current column to its own existing value. OVERLAY defaults to starting at column one for a variable-length record. So your 1,4 was interpreted as 1:1,4, and that means "change the data at position one for a length of four to the current value at position one for a length of four". No point in even trying that, and you repeat that later in the same card.

(there is one case where you may want to set a value to itself, which is to emulate a NOP for an IFTHEN=(WHEN=(logicalexpression).

OUTREC IFTHEN(WHEN=(0032,1,CH,EQ,C'1'),
OVERLAY=(34:C'7X',
360:,C'F#',
367:C'C'))

Note that there is 100% absolutely no need to BUILD for all the records which fail the condition. They already look exactly how you want. Including a WHEN=NONE with a BUILD is just chewing up CPU.

Your own amended card, which does different things to your original, could look like this:

OUTREC IFTHEN=(WHEN=(32,1,CH,EQ,C'1'), FOR RECORDS WITH THIS VALUE ONLY

OVERLAY=(32:C'7X', FIRST CHANGE

358:C'F#', NEXT CHANGE

366:C'C')) LAST CHANGE

Again no need for the WHEN=NONE. WHEN=NONE is to be used when you want to do something to records which don't meet any IFTHEN=(WHEN=(logicalexpression). Not when you don't want to do anything to them.

A note on using columnes (n:) in BUILD. Don't, unless you need to.

A simple example is here:

> IFTHEN(WHEN=NONE,
> BUILD=(1,4,5:5))

The places data from position one for a length of four from the "old" current record into the new current record. BUILD cannot splatter data it has already placed in the new current record. So the next data specified in the BUILD will "naturally" be at position five. So no need for 5:.

Doesn't make much nevermind in a simple example, but if using columns and you get one or more wrong, the time taken to find the error(s) is just total waste.

Anyone looking at a BUILD with lots of columns specified will also wonder "why?" and have to check that there is not a specific reason.

Only use columns in BUILD when there is a specific reason. An example:

INREC BUILD=(1,10,C'XYZ',11,5,80:X)

That takes a fixed-length input which could happen to be 15 bytes long, modifies the data by inserting a constant, and ensures that the output records are 80 bytes long with trailing blanks. The 80:X says "put a blank at position 80, and space-pad any intervening bytes between that and the previous data referenced in the BUILD".

80:X you should see a lot when generating SORT control cards or symbol/SYMNAMES files.

[Bill Woodger]

On Thursday, October 22, 2015 at 5:18:38 PM UTC+1, Farley, Peter x23353 wrote:
> That would be a very significant and useful addition to SORT capabilities from either vendor.
>
> There are "gotcha's" though, like when the COBOL copy book written by the programmer uses illegal COBOL strings to allow REPLACE of the high-level part of the data names in the definition file/member, like this:
>
> 01 :HLN:-RECORD-AREA.
> 05 :HLN:-FIELD-1 PIC X(10).
> 05 :HLN:-FIELD-2 PIC S9(5)V9(2) COMP-3.
>
> Use of a direct-copybook-read process would require (like the COBDFSYM process requires a dummy program compile) some other process or parameters to expand any required REPLACE strings, or a separate "sort" copy of the definition with all REPLACE strings already resolved.
>
> Not to say it cannot be programmed (SMOP), but definitely a factor to be considered.
>
> Plus once COBOL is supported, what about assembler DSECTS, PL/1 DECLARE's, C struct's and typedef's? I'm sure users of those languages would also want that kind of support. That gets really complex really quickly.
>
> Peter
>

The consumption and translation of a COBOL (or anything else) structure would require time each and every time a SORT that used a structure was run.

This is also true of symbols/SYMNAMES, but the translation of those is pretty routine as they have a very definite format. Symbols can't even be multi-line.

Any structure can be translated into symbols/SYMNAMES. Yes you have to code it (or use someone else's code), and yes there is "extra" work whenever a structure is changed.

However, avoiding the "need" for SORT to be able to "compile" multi-language structures (or even just COBOL structures) would save CPU expenditure for no real benefit (that can't be provided by the other method).

If deeply worried that your Change Control procedures can't keep copybooks and symbol files in step, generate the symbol-file in a step prior to the SORT. You then get the automatic ability to provide symbols guaranteed to be to the latest copybook, without expecting wildly excessive coding to be implemented in SORT.