This was posted over on the IMS List and I thought it interesting to post here as well.
We have major challenges with Cobol 5 due to the fact that IBM dropped the NUMPROC(MIG) compile option with COBOL 5 and only allow NUMPROC(NOPFD) and NUMPROC(PFD). The best fit for our client to be the closest to Cobol 4 is NUMPROC(NOPFD). This however causes unsigned display numeric fields not to abend on an S0C7 when there are low-values , spaces or invalid data in a field, when arithmetic functions are done on these fields, as the signed bits are ignored. Our systems have over the past 30 years kind of relied on this implied protection and due to the NUMPROC(MIG) option they have been built in the past 30 years not really worrying in some cases about using unsigned display numeric fields and signed numeric data fields. Anyone experienced the same issues ?? , due to the uncertainty created around all the systems and the risk involved and the amount of work to be done and cost (+- 15000 Cobol programs and 700 IMS databases in production) our client is at the moment contemplating to NOT implement Cobol 5 at all. The Cobol manual indicates to either fix the programs or fix the data -- if only that was so easy !! Has anybody experienced this ?? or where should I ask this question On the COBOL CAFÉ on Developerworks, I found the following posting that might be helpful. Thread title: Latest COBOL V5 migration recommendations Several things have come together to give us a better recommendation for customers who want to migrate to COBOL V5 but who also want to avoid discovering 'differences' when they deploy into production. First, some background. Some of the most difficult problems when migrating to COBOL V5 are caused by 'invalid COBOL' that cannot be detected by inspecting source code. The top six most common of these are: o Invalid data in numeric USAGE DISPLAY data items o Parameter/argument size mismatch: o Modifying data outside the bounds of a table o Using tables when the ODO object value is not in the legal range o Modifying data following a table with INDEXED BY indexes o Overpopulated data items, with values that have more digits than are defined in the data definitions In order to find these more easily, we should recommend that users: - Always compile with RULES(NOEVENPACK) - Use the "Scanning COBOL programs for compatibility" feature of RDz 9.5 to check parameters and arguments - Compile with SSRANGE, ZONECHECK and OPT(0) for initial code changes and unit test - Recompile with NOSSRANGE, NOZONECHECK and OPT(2) for quality assurance test and production Finally, in the topic of "Before you buy COBOL V5", we should recommend the following: - Install the latest maintenance on LE and other products for COBOL V5 (Use the COBOL V5 FIXCAT feature) - Change build processes to add REPLACE IGZEBST in the BIND/LINK step to fix the "old VS COBOL II bootstrap" problem - Convert PDS load libraries to PDSE - Locate all OS/VS COBOL programs and either target them for early migration to V5 or migrate to V4 now And from Tom Ross We do have a new compiler option called ZONECHECK, which can find the source of such bad data. This problem is not just with NUMPROC(MIG), relying on specific instructions being generated by a compiler to get ABENDs is a terrible idea, how can we use new instructions that run faster but might behave differently on bad data? We are finding that such invalid COBOL coding is causing migration problems for quite a few customers. So I just thought I would pass this along. Still issues with COBOL V5 no matter where you look Lizette Koehler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
