On 09/11/2013 12:02 PM, John McKown wrote: > A programmer came by today with a problem. He is sometimes getting a S0C4-4 > abend in a COBOL program. This is a subroutine. One of the parameters > passed in is a data area, which can be of various lengths. It is defined > with an OCCURS DEPENDING ON with a data element within the area. I.e. the > first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data set > into this area. This is where the abend occurs. The reason is because the > OCCURS DEPENDING ON maximum size is significantly larger than what the > caller is passing it. And the READ to the 01 is trying to pad the entire > possible 01 level with blanks. > > The problem is how do I describe this to a COBOL programmer who just > doesn't "get it". He expects COBOL to _not_ pad the "non existent" > occurrences with blanks. And, if fact, to not even reference this area > wherein they would have resided, had they existed. I'm just get "deer in > headlights" looks. I'm not using the correct words, somehow. >
Presumably the "area" in question is the target of INTO as in "READ... INTO area". The manuals say data movement for READ to the INTO "area" is governed by the rules for "MOVE", and the semantics for MOVE says any length evaluation of the receiving field is determined just "before" any data is moved. Is the DEPENDING ON variable in the receiving group item initialized to the proper expected value or to the maximum acceptable value that the calling program can accept prior to the READ? The way I read the manuals, the implicit MOVE of the READ instruction will replace the DEPENDING ON value in the receiving structure, so afterwards it should reflect the actual number of occurrences present, but the length of the MOVE and any padding of the receiving field as part of that MOVE will be based on contents of the receiving field's DEPENDING ON variable prior to the move. If the programmer is expecting COBOL to *assume* that the length of the receiving field is the length of the source field (in this case, the record just read), the manuals seem to explicitly indicate that is not the way things work. If my understanding is correct, a more efficient way to avoid unnecessary padding would be to do a READ without "INTO", then set the DEPENDING ON value in the receiving area to minimum of max count space supplied by caller and the DEPENDING ON value in the actual record read, and finally MOVE the file record to the receiving area. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
