Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I don't use reference modification a lot, and having used it here to allow the 2nd and 3rd INSPECTs to do less work, I thought I'd check it out against the "potentially INSPECT the whole field" version below:
The three INSPECTs in the first version occupy 53 Assembler instructions. The two INSPECTs in the latest, only six Assembler instructions (all five INSPECTS actually use a Cobol-subroutine to do the INSPECT, IGZIN1, all the extra stuff is to do the counting in the first INSPECT and handle the variable-length fields from the reference-modification).
Yes, in the first program fewer bytes will be used in the INSPECT, but much more work will be done (with only 60 bytes in question) to save those few bytes.
I suspect doing the INSPECT with OCCURS DEPENDING ON limiting the length would be even more "wordy" than reference-modification, but I like the flexibility/maintainability of the ODO over the reference-modification.
Note: if the input is actually variable in length, it would perform better to MOVE it to a fixed-length field first thing and then work with that, than to use a variable-length field.
Note also: this is a specific solution for that specific problem. If the data was like this:
the fish would be of a different kettle. However, as long as the possibly-quoted-fields are trailing and interspersed by no more than one non-quoted-field, then it'll be OK.
Oh dear. Thinking about those three dollar amounts, the second-to-last one may only be unquoted in this case. If it were bigger rather that zero, as in over 999.99, then there would be another quoted field. OK, that's no problem. But, what if the last field is less than 1000? That would be a problem with the solutions provided with INSPECT/UNSTRING only.
So, for the specific example, you need an appropriate:
Code:
INSPECT W-DATA-TO-UNSTRING
REPLACING ALL X'6B7F' BY X'7C7F'
ALL X'7F6B' BY X'7F7C'
ALL X'6Bxx' BY X'7Cxx'
replacing the existing one. It is "appropriate" in the sense of whether use choose reference-modification or fixed-length field, and in the value of xx, which is the hex for the dollar symbol, which I didn't include as yours may well be different from mine.
Test it Rohit. It may just be that the data never allows the one field to have a different number of significant digits than the other, but it seems unlikely unless the fields will always be equal. Now I think the code will cover all the possibilities for those last three fields, but remember that "Bill thinks that it is so" is not a substitute for thorough testing and cuts no ice at all with your Boss.
),
