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'),
> 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.
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).
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:
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:
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.