http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.0.0/com.ibm.ent.cbl.z
os.doc/migrate/igymopt.html

John T. Abell
Tel:            800-295-7608    Option 4
President 
International:  1-416-593-5578  Option 4
E-mail:  john.ab...@intnlsoftwareproducts.com
Fax:            800-295-7609

International:  1-416-593-5579


International Software Products
www.ispinfo.com


This email may contain confidential and privileged material for the sole use
of the intended recipient(s). Any review, use, retention, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient),
please contact the sender by reply email and delete all copies of this
message. Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive
emails on the basis that we are not liable for any such corruption,
interception, tampering, amendment or viruses or any consequence thereof.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, October 14, 2015 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V5 and IMS Concerns

Didn't IBM bring one of those missing NUMPROC options back in COBOL 5.2 or
am I confused?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Wednesday, October 14, 2015 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL V5 and IMS Concerns

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to