Unless you take the perspective that "everything that is not illegal is legal" - undocumented closing of "loopholes" or making undesirable (but legal) coding practices now illegal doesn't seem to necessarily seem to be in the best interest o fhte customer ...
Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services : humana.com 123 East Main Street Louisville, KY 40202 Humana.com (502) 714-8615, (502) 476-2538 > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Frank Swarbrick > Sent: Monday, May 23, 2016 1:08 PM > To: [email protected] > Subject: Re: [IBM-MAIN] A couple of interesting COBOL V5 fixes > > Very interesting stuff, Bill. Thanks for pointing them out! > > Just goes to show that some shops did "interesting" things to get around > limitations within the COBOL standard. While IBM was "right" from some > perspective to make the changes they did to COBOL, not considering (and > why would they) how shops might have "abused" unintended/undefined > behaviors, it also shows that shops often do depend on these > unintended/undefined behaviors. > > Frank > > Date: Sun, 22 May 2016 04:00:37 -0500 > > From: [email protected] > > Subject: A couple of interesting COBOL V5 fixes > > To: [email protected] > > > > Firstly, evidence of IBM's plans to make V5 (and onwards) more compatible > with how V4 works. > > > > http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330 > > > > "In earlier versions of COBOL, customer source frequently handled > > dynamically sized pieces of storage by using a PIC X(1) linkage > > section data-item and then reading or writing beyond the bounds of > > that array. This APAR will add this type of support to COBOL V5 to > > make the behavior consistent with COBOL V4. > > > > LINKAGE Example: > > > > WORKING-STORAGE SECTION. > > 01 wrk-len PIC s9(08) binary. > > LINKAGE SECTION. > > 01 L-String1 PIC X(1). > > 01 L-String2 PIC X(1). > > PROCEDURE DIVISION. > > 0000-MAIN. > > MOVE 1000 TO wrk-len > > MOVE L-String1(1:wrk-len) TO L-String2(1:wrk-len) > > > > Behavior difference: COBOL V4 moves 1000 bytes. COBOL V5 moves 232 > > bytes due to differing instructions. > > > > TABLE ODO Example: > > WORKING-STORAGE SECTION. > > 01 CONTROLVAR PIC 9(5) BINARY. > > 01 MYCONTAINER. > > 02 MYTABLE. > > 03 TBL OCCURS 0 TO 1 TIMES DEPENDING ON CONTROLVAR. > > 05 MYFIELD PIC X(1). > > 02 DUMMY PIC X(300). > > PROCEDURE DIVISION. > > MOVE 1 TO CONTROLVAR > > MOVE ALL 'Z' TO DUMMY > > DISPLAY DUMMY <= Contains all Z's > > MOVE 300 TO CONTROLVAR > > MOVE ALL 'M' TO MYTABLE <= MYTABLE has 1 byte of M's in V4 > > DISPLAY MYTABLE > > MOVE 1 TO CONTROLVAR > > DISPLAY DUMMY <= DUMMY HAS 299 BYTES OF M's in V4. > > > > Behavior difference: COBOL V4 overlays storage following MYTABLE > > exactly as expected byte for byte. COBOL V5 handles the overlay > > differently such that the storage results differ from COBOL V4." > > > > And: > > > > "Problem conclusion > > > > The compiler was updated to ensure that in the above move > > scenario the runtime length of the move, as implied by the > > variable length reference modification, is always used > > regardless of the defined length of the receiving data item in > > the linkage section." > > > > Note, it won't work if compiled with SSRANGE. > > > > No "Local Fix" was outlined. The idea is that you no longer have to > > fix the code :-) > > > > Where such techniques are used, it will make migration easier. > > > > Secondly, some movement on the NUMPROC(MIG) issue which has > previously been discussed here. > > > > http://www-01.ibm.com/support/docview.wss?uid=swg1PI56073 > > > > " > ********************************************************** > ****** > > * USERS AFFECTED: Users of Enterprise COBOL V5.2 migrating * > > * from a pre-V5 compiler, compiling and * > > * running programs that were using the * > > * NUMPROC(MIG) compiler option in pre-V5. * > > * * > > > ********************************************************** > ****** > > * PROBLEM DESCRIPTION: Performance: Programs compiled with * > > * NUMPROC(NOPFD) using Enterprise COBOL * > > * V5 is slower than programs compiled * > > * with NUMPROC(MIG) using a pre * > > * Enterprise COBOL V5 compiler. * > > * * > > > ********************************************************** > ****** > > * RECOMMENDATION: Apply the provided PTF. * > > > ********************************************************** > ****** > > NUMPROC(MIG) does not require sign codes to be cleaned before > > comparing two zoned decimal data items. NUMPROC(NOPFD) requires > > sign codes to be cleaned. > > > > Problem conclusion > > > > A more efficient code sequence for cleaning sign codes during > > comparisons was developed." > > > > So, NUMPROC(MIG) has not returned (and is less likely to), but > NUMPROC(NOPFD) has been made faster. > > > > This is an amusing one: > > > > http://www-01.ibm.com/support/docview.wss?uid=swg1PI59344 > > > > ADD 0 TO a-zoned-decimal-field was "optimized out" under the new > ZONEDATA(NOPFD)/ZONEDATA(MIG). Since this was sefl-defeating (the > ADD 0 would cause zones, and signs, to be fixed), the ADD 0 will remain. > > > > It is still optimized-out for ZONEDATA(PFD) because "the zone bits are > assumed to be correct with ZONEDATA(PFD)". > > > > I'm not so sure that last is a good idea, because the ADD 0 also affects the > sign. Research needed. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
