Hi Frank, We are in the process of upgrading from COBOL 4.2 to 5.1 and, let me tell you, it's been a nightmare.
First off, before even considering ordering 5.2, convert all your load libraries to PDSE - as someone else stated, you have no option. This in itself leads to confusion and mis-information. Questions will arise, e.g. Is it possible to copy from PDSE to PDS? The answer is "depends" if you compile/link a module using COBOL 4 to a PDSE, it is possible to copy it to a PDS. However, a COBOL 5 modules are linked (bound, really) as program objects and cannot be copied to PDS. When copying load modules (whatever format) using IEBCOPY, behind the scenes it calls the binder to ensure the correct module format. I wrote a REXX exec to take a list of library names, rename the library to have .PDS on the end, allocated a new PDSE library and called IEBCOPY, obviously checking at each stage and making the process restartable. And, unusually, we started with the production libraries and worked our way back through the food chain. Update COBOL 4 to issue MIGR messages, which your developers will ignore no matter how many times you stress the importance of checking and eliminating them. Be aware that due to IBM's (new) licensing policy, you will only be allowed to use COBOL 4 and COBOL 5 concurrently for one year, and again, no matter how much you stress to developers, they'll try to wait till the last minute. In the first release of COBOL 5, there was no AMODE(24) support. That has now been changed but it has led to several S0C4's as some of the compiler modules have not been "fixed". Whereas in previous versions of ECOBOL a minimum and maximum record length did not have to be specified when defining a variable file, v5.1 will return a file status of '04' if any record is less than or greater than the minimum / maximum specified. Working-storage BLW cells have been replaced by WSA (Writeable Static Area) which means a change to the way your developers will find their working storage fields in a dump. If you want any help and advice from one who's been through the process, then feel free to ask. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Frank Swarbrick <[email protected]> To: [email protected], Date: 01/04/2015 00:06 Subject: migrating compiler versions Sent by: IBM Mainframe Discussion List <[email protected]> Does anyone have a good list of best practices when migrating to a new version of a compiler? While our shop is 35+ years old, we have rarely actually migrated compilers (or even compiler versions), so we don't have a lot of experience in this area. When migrating from DOS/VS COBOL to VS COBOL II there were almost always source code changes, so all programs were tested before they were migrated, and no program was simply "automatically migrated", as it were. I'm sure we had COBOL II for at least ten years before all of our DOS/VS COBOL programs were eliminated. (From what I hear that's actually better than many shops, which STILL have pre-COBOL II programs out there!) Going from VS COBOL II to IBM COBOL for VSE/ESA was a more "normal" migration. If I remember correctly (and I should because I was pretty much "in charge" of the migration) we at first only migrated to the new compiler if other changes were being made to a program and a special "flag" was set to indicate that this program should be compiled with the new compiler instead of the older one. Only after many, many programs were migrated in this fashion (and it probably took us several years to get to this point, though I honestly do not recall) did we finally eliminate the COBOL II compiler altogether. But I believe at no point did we do any kind of "mass recompile". We simply used COBOL for VSE/ESA for all programs going forward (old-COBOL had all been converted to COBOL II or COBOL for VSE/ESA already). Then we migrated to z/OS and IBM Enterprise COBOL 4.2. Of course in this situation EVERYTHING was recompiled and regression tested. So now we're pondering how to get the Enterprise COBOL 5.2. The easiest thing, of course, would be to simply change our compile procs to use COBOL 5.2. But being as how COBOL 5.2 has been out for only a month that's probably not a good idea. Probably the best thing to do would be to have developers "choose" to use COBOL 5.2 by this 'setting a flag' for an individual program indicating that their test compiles should use 5.2, and in turn so should their production compiles. Should we also, at least at first, have them do a regression test of the current 4.2 results comparing against the results of the program compiled with 5.2? And for how long should we keep that up? At some point (6 months? a year?) we'd want to stop using 4.2 altogether. But we also (I don't think!) don't want to regression test every single program. All advice appreciated. Thanks! Frank SwarbrickApplication Development ArchitectFirstBank -- Lakewood, CO USA ---------------------------------------------------------------------- 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
