Hi Andre,
Sorry that this is after your class, but I think the other posters have included the most important information for you. Here are a few additional considerations for anyone following this post.
1. To save CPU time, you should definitely use the ARCH options and be sure to use the lowest level machine, including D/R, where the program will be running. Online COBOL (CICS/IMS) will usually not provide significant savings, and may actually cost you CPU time.
2. Consider ABO for situations where you've lost the source. Initially the cost was prohibitive, but IBM has changed the pricing method and could now be a good option for some sites. IBM says you don't need to test as well, but you can't convince me.
3. If an old COBOL program hasn't been used in many years, then take a chance on not upgrading it. When/if you need to update it, do the migration at that point in time. Remember that's it's only the compiler that is going out of service. All of the LE routines will remain current.
4. Follow Tom Ross' recommendations earlier in this thread. He is THE SOURCE.
5. I've uploaded a 13-page article on COBOL Compiler Tips from our
Cheryl Watson's Tuning Letter 2018 No. 4 that might be helpful.
Best regards,
Cheryl
------------------------------
Cheryl Watson
Watson & Walker, Inc., CEO
cheryl@watsonwalker.comwww.watsonwalker.comSarasota, FL USA
------------------------------
Original Message:
Sent: Tue February 02, 2021 06:58 AM
From: Andre van Wyk
Subject: Migrate Enterprise PL/I v4.3 to v5.3 and Cobol v4.2 to v6.2
Thanks everyone for posting a response. I have a number of customers that need to migrate to Cobol v6 and one to PL/I v5. I'm presenting to a large bunch of developers tomorrow and propose the following framework for Cobol, similar for PL/I:
- Establish a project and identify the team that will do the migration
- Read through all the tips, migration and supplementary documentation. Attend any webinars if they are available
- At the same time install the Cobol v6 compiler
- Create new Cobol load libraries. Note that the old libraries are in PDS format and the new libraries are ins PDSE format. This is a significant change.
- Set up JCL so that the compiled code is put into the new libraries
- Start by compiling all the source. Note the following:
- This is a major compiler change from IBM. Some programs from previous versions that are in the current libraries may never have been re-compiled are still the original programs. These programs may have errors that have been masked and are now surfacing that have to be addressed.
- Cobol v6 handles invalid code and data differently than in Cobol 4. So there may have to be changes made to the source code.
- Some copybooks or source code may be missing. There will have to be a re-evaluation of the programs to determine if they are still necessary for the business and if so a re-write may be required.
- For CICS programs, put all the compiled code in a unique library for easy identification (for example LOADLIBC for CICS and LOADLIBB for batch). Set up or use an existing CICS region to point to these libraries and do the testing
- Similar steps for batch
- Do thorough testing
- Once all has been done move to production
------------------------------
Andre van Wyk
Original Message:
Sent: Wed January 27, 2021 07:40 AM
From: Hans Emrich
Subject: Migrate Enterprise PL/I v4.3 to v5.3 and Cobol v4.2 to v6.2
Hello Andre,
you can find Migration Guides in the IBM Knowledge Center:
PL/I: https://www.ibm.com/support/knowledgecenter/en/SSY2V3_5.3.0/com.ibm.ent.pl1.zos.doc/welcome.html
COBOL: https://www.ibm.com/support/knowledgecenter/en/SS6SG3_6.2.0/welcome.html
And by-the-way. Current COBOL Version is 6.3 to which you should probably migrate to.
As Matthew posted already there is a Migration Portal for COBOL which is quite helpful.
For COBOL a recompile off all applications is NOT required. (In case you here something different: there was a misunderstanding about this some years ago when COBOL V5 came out) .
The biggest migration effort should usually be testing. Most problems after migration are caused by bad programming (e.g. using uninitialized storage, etc. ..). Because such problems come up during runtime only testing is a key topic for the migration. That may be different for very old COBOL applications But this is described very detailed in the migration guide.
For PL/I i would guess it is the same, but i am not really in expert for this.
------------------------------
Hans Emrich
Original Message:
Sent: Mon January 25, 2021 04:51 AM
From: Andre van Wyk
Subject: Migrate Enterprise PL/I v4.3 to v5.3 and Cobol v4.2 to v6.2
Can anyone please point me in right the direction to find migration guides for these two products ie. Pitfalls, recommendations and best practices. Do the customers have to re-compile all their programs noting that the source is not available for some programs. As bau development proceeds and new programs get written, point to the latest compiler and leave old code as is? When doing maintenance compiles use the latest compiler but leave the rest of the suite on old code seeing that it is already object code?
| | | TSSA | Mainframe Architect | Avanti Towers South Block, 35 Carl Cronje Drive, Bellville, 7530 | | | | | | | | | Registration Number: 1989/007547/07 | | | | | |
Disclaimer: This message and/or attachment(s) may contain privileged, confidential and/or personal information. If you are not the intended recipient you may not disclose or distribute any of the information contained within this message. In such case you must destroy this message and inform the sender of the error. T-Systems does not accept liability for any errors, omissions, information and viruses contained in the transmission of this message. Any opinions, conclusions and other information contained within this message not related to T-Systems' official business is deemed to be that of the individual only and is not endorsed by T-Systems.