Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
AMODE 31 modules have no problem addressing parmlists built and passed by an AMODE 24 Caller. It's when an AMODE 31 Caller (building and passing an AMODE 31 parmlist) calls an AMODE 24 Caller and then you've got trouble.
Perhaps you approached them in the wrong way. If they've not changed anything for years, they won't take kindly to you jumping in their faces saying its wrong.
It sounds like when they set up the Changeman, they used at least one different compile option (DYNAM). Someone should have noticed at the time.
You need to look at one of the old programs, a loadmodule containing it, and find out the compile options used. You need to check those compile options to those currently used. If there are any other differences in options which generate code, so may have some "interesting" impact analysis for someone to do.
You currently have two systems sharing the same libraries and sharing some sub-programs.
You are splitting those out to separate libraries, and need still to be able to use the common sub-programs in both systems.
Who is responsible for maintaining the common sub-programs? Same Project for all, or some split?
You've already changed at least some programs to use CALL data-name instead of CALL literal. That was unnecessary. Compiler option DYNAM will cause the CALL literal source to generate the code for a dynamic CALL.
The change would only be necessary if you are unable to change the compile option to DYNAM. Guess who knows the answer to that question?
You will need to get the bosses responsible for the two different systems and the Changeman team together. The discussion will require technical input, from someone who is aware of the meaning and impact of the compile options. That, along with the way the Changeman team have as their standard for managing source/executable systems should lead to a list of what needs to be done and who needs to do it. Get your best COBOL person in on that meeting.
Anything you come up with yourself will likely be bounced by the Changeman team as not the standard way to do it. If they are left on their own, I'd be worried they'd not have the knowledge to set the correct compile/linker-binder options. If common modules are "shared", there will always be problems when one Project wants a change, and the other doesn't. So you have to get all that sorted out before you can get anywhere.
So, stop what you are currently doing, reveal to your boss the mess that exists, so that such a meeting (probably not just one) can be arranged. Don't do anything else until you are doing what everyone has agreed to. Else you'll be continuing in the same manner for weeks, only for all your work to be scrapped when someone finally realises independently that there is a problem.