COBOL programs dynamic linking

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

Hi all,

We support 2 mainframe applications. Right now these 2 apps share common Changeman library and common load libs. However, we need to separate these 2. Application A calls some COBOL programs of app B. A uses static linking. So everytime any COBOL program is changed, all the called and calling programs need to be brought into package and compile linked.
After separating the libraries it won't be possible to bring B's modules into A's package. Trying to find the solution to this. I tried using dynamic linking (where call 'program1' using... is specified; changed it to call wk-program1 using... and added 01 wk-program 1 pic x(8) value program1 in working storage section) Compilation issue was resolved but got run time error S0C1 abend.

Please suggest anything helpful if possible. I am quite a beginner.

Thanks

Bill Woodger · Posted: Tue Jul 15, 2014 2:03 pm

Why don't you talk to the technical people responsbile for Changeman. Aren't they involved in this already? Generally when a decision is made to do something, it is already known that it can be done in a reasonble manner. Someone responsible for Changeman should know how they'd lilke it done.

On what you've attempted, there was no need to change to CALL data-name if you are able to override/change compile options, as DYNAM will turn CALL literal into a dynamic CALL.

For your S0C1, that would normally be an "unresolved" static CALL. Implying you didn't change everything. Without seeing the output from the linker/binder it is hard to be accurate...

Marso · Posted: Tue Jul 15, 2014 6:47 pm

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

I am using dynam option. But cant get the reason why few modules throw S0C1 abend. Few run perfectly fine.

Akatsukami · Posted: Wed Jul 16, 2014 1:56 am

A S0C1 abend is an operation exception. As the compiler will not generate bad opcodes, the conclusion is that code has been overlaid by data. Begin by checking that the addressibility of parameters is correct; in particular, ensure that the loaded subroutines are really he same as the linked ones.

Bill Woodger · Posted: Wed Jul 16, 2014 2:37 am

Well, a static CALL which is expected to be resolved by the linker/binder yet no object of the correct name is found is on a wild and crazy ride to a S0C1. Well, not that wild and crazy, this is computers, after all.

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

There is a huge set of subroutines. I am changing subroutine D. JCL proc calls cobol subroutine A, A calls B, B calls C and C calls D. Each of these call many other subroutines too.

I checkout D into a package,compile it using dynam option, promote it and test it. But still the old D is being used. So i compiled A and B too. Now i get stuck by S0C1 abend at the subroutines called by B.

I have the promotion library and application load library coded in steplib. i ensured all the subroutines called are present in that loadlib.

I was thinking if i use dynam, i have to checkout just D and perhaps A into package and compile it. And other called/calling subroutines have to be present in the loadlib and that load lib should be present in steplib. Is my understanding wrong?

Bill Woodger · Posted: Wed Jul 16, 2014 11:11 am

For the step getting the S0C1, show the output from the linker/binder.

Bill O'Boyle · Posted: Wed Jul 16, 2014 2:46 pm

Make sure you're specifying the same AMODE and RMODE for all modules.

Also, a S0C1 (an invalid OP CODE) can be raised when attempting to access a file which has not been successfully opened or had been closed.

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

Tried changing rmode to rmode(any). Getting the following error:

An attempt was made to pass a parameter address above 16 megabytes to AMODE(24) program C

From compile unit B at entry point B at compile unit offsset +00001706 at entry offset +00001706 at address 1F1BF706.

Akatsukami · Posted: Wed Jul 16, 2014 9:55 pm

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

I don't really understand what you want to do after the split.

No more calling 'B' from 'A'? Or do you mean you're going to split the Changeman library?

If you mean that you need to dynamically call the modules out of the 'B' changeman library, but still statically link packages in 'A', then you'll have to add the 'B' library to the LINK step, not the compile step.

You may have to create only OBJECT files from the Changeman process, then have a separate process to run the link that can see both libraries. That process would produce a statically linked load module to be in 'A' library.

If this were SCLM, it would be easy to change the project configuration to include another library in the link step. I'm guessing that ChangeMan can do the same thing. It would be no different than if you had a vendor product with its own library of modules that need to be included.

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

Hi Ed,

Right now my problem is - I have 3 Cobol programs A, B and C. A is calling B and C. I compile, link A using Dynam option. I promote it and test it. I provide the loadlib containing B and C in the steplib.

On running the job, B gets called successfully. whereas job fails at C. 'No active module found'

USER COMPLETION CODE=4039 REASON CODE=00000000
TIME=09.34.10 SEQ=16656 CPU=0000 ASID=00BA
PSW AT TIME OF ERROR 078D1000 84EC501A ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN

I also see one more line in the end of the message
IMS BATCH REGION ABEND- SYS 00C1 BTCH

Not able to find why B gets called successfully and not C. Checked rmode, amode for both. they are amode 24, rmode 24 for C and amode 31, rmode (any) for B.

When i try to specify rmode(any) for C, it gives me error message as indicated in the previous post.

Bill O'Boyle · Posted: Thu Jul 17, 2014 12:16 am

An AMODE 31 program cannot Dynamically Call (with a Parmlist) an AMODE 24 Program as an addressability error will occur. Under the covers, the AMODE 24 program attempts addressability to the 31-Bit Parmlist built by the AMODE 31 Caller and an addressability error occurs.

Is there any particular reason for having an AMODE/RMODE 24 COBOL module?

steve-myers · Posted: Thu Jul 17, 2014 12:32 am

AMODE 31, RMODE 24 -- Possible for Assembler, unlikely for Cobol. For Assembler, the module is not reenterable and has one more DCB areas and related data areas that are actually used. Any use of 24 bit data areas ensures the high order 8 bits of a pseudo 31-bit address are cleared.
AMODE 24, RMODE 24 -- Possible for Assembler, unlikely for Cobol. For Assembler, the module is not reenterable and has one more DCB areas and related data areas that are actually used. Further, this program is using the 24-bit data areas without making sure any high order bits introduced by a L instruction or equivalent are cleared.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

I've seen this kind of situation before, and I don't mean the technical problem.

You seem to be in that crazy thrashing place where you are trying to solve the problems you make by trying to solve the other problems. I'm very familiar with this space, because I spend days there sometimes.

I recommend you take a step back and start from the beginning. Re-state exactly what you are trying to accomplish, then start from there. Something changed, what was it?

Your first hint is that you recompiled and existing program that was working before. So, you need to see why the new load module is different from the old.

If you are changing the compile process to meet new standards, then you're going to have to include the older programs as part of the impact analysis. (It almost sounds like somebody thought this was a no-brainer and didn't do their homework)

Bill O'Boyle · Posted: Thu Jul 17, 2014 6:03 pm

Adding to Ed's recommendations, if you're using Enterprise COBOL 5.1, your loadlib's MUST be PDSE format. This is a requirement. There's also some obscure requirements with AMODE 24 in COBOL 5.1.

Speak to your MVS guys.

HTH....

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

I could se multiple amode rmode values in SSO.

Amode for module B:

processing options: unspecified
save module options: 31

Amode for module C:

processing options: unspecified
save module options: 31
processing options: unspecified
save module options: 24

Rmode for module B:

processing options: unspecified
save module options: any
processing options: unspecified
save module options: any

Rmode for module C:

processing options: any
save module options: unspecified
processing options: any
save module options: unspecified

Confused.. will have to read more perhaps

Bill O'Boyle · Posted: Thu Jul 17, 2014 9:31 pm

Are you saying that program "C" is AMODE 24 and is being "Called" by program "B", which is AMODE 31? If this is true, then program "C" will blow-up attempting to address the 31-Bit parmlist built and passed by program "B".

I think they all need to be AMODE 31 RMODE ANY and make sure the COBOL Compile option DATA(31) is set or just let it default. This affects addressability to WS.

Please advise....

John Kondrick · New User Joined: 15 Jun 2010 Posts: 2 Location: USA

COBOL V5.1.0 does not support AMODE 24. COBOL V5.1.1 does. It is most likely the shop is on V4.2.0, however.

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

am rm 24 24 calling 2 modules with am rm 31 any.

Can call 1st successfully, but gets stuck on 2nd

I changed am rm of calling module to 31 any. Still the same, no change.
S

Loadlib is pdse. I have old load lib which is in pds, when i use that, it doesnt event call the 1st module

Bill O'Boyle · Posted: Thu Jul 17, 2014 11:37 pm

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.

I'm fresh out of ideas.

Please use English that we can all understand.

I can't read Pig-Latin....

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

Our load libraries exist from long time and Changeman was set up just few years back.

I found that the modules that were recently modified (using changeman)get called dynamically. whereas the ones that have not been modified since years (did not ever use changeman) throw error.

So there might be some mismatch. Will try contacting Changeman team.

shreya19 · New User Joined: 13 Mar 2014 Posts: 34 Location: USA

Changeman team sent me back saying it is a coding issue

Bill Woodger · Posted: Sat Jul 19, 2014 5:31 am

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.