Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

COBOL programs dynamic linking
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
shreya19

New User


Joined: 13 Mar 2014
Posts: 20
Location: USA

PostPosted: Tue Jul 15, 2014 5:58 am    Post subject: COBOL programs dynamic linking
Reply with quote

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
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Jul 15, 2014 2:03 pm    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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...
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1218
Location: Israel

PostPosted: Tue Jul 15, 2014 6:47 pm    Post subject: Re: COBOL dynamic linking
Reply with quote

shreya19 wrote:
After separating the libraries it won't be possible to bring B's modules into A's package.

If you have option NODYNAM and static calls, you will need B's modules during linkedit.
If you have option DYNAM or dynamic calls, you will still need B's modules during run time.
Some how, some time, you will need access to both libraries.
Back to top
View user's profile Send private message
shreya19

New User


Joined: 13 Mar 2014
Posts: 20
Location: USA

PostPosted: Wed Jul 16, 2014 1:44 am    Post subject:
Reply with quote

I am using dynam option. But cant get the reason why few modules throw S0C1 abend. Few run perfectly fine.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Wed Jul 16, 2014 1:56 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Jul 16, 2014 2:37 am    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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.
Back to top
View user's profile Send private message
shreya19

New User


Joined: 13 Mar 2014
Posts: 20
Location: USA

PostPosted: Wed Jul 16, 2014 3:57 am    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Jul 16, 2014 11:11 am    Post subject: Reply to: COBOL dynamic linking
Reply with quote

For the step getting the S0C1, show the output from the linker/binder.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 16, 2014 2:46 pm    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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.
Back to top
View user's profile Send private message
shreya19

New User


Joined: 13 Mar 2014
Posts: 20
Location: USA

PostPosted: Wed Jul 16, 2014 9:14 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Wed Jul 16, 2014 9:55 pm    Post subject:
Reply with quote

shreya19 wrote:
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.


But Mr. O'Boyle wrote:
Make sure you're specifying the same AMODE and RMODE for all modules.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed Jul 16, 2014 10:43 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
shreya19

New User


Joined: 13 Mar 2014
Posts: 20
Location: USA

PostPosted: Wed Jul 16, 2014 11:04 pm    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Jul 17, 2014 12:16 am    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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? icon_confused.gif
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Thu Jul 17, 2014 12:32 am    Post subject:
Reply with quote

  • 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.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Thu Jul 17, 2014 5:42 pm    Post subject:
Reply with quote

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)
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Jul 17, 2014 6:03 pm    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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....
Back to top
View user's profile Send private message
shreya19

New User


Joined: 13 Mar 2014
Posts: 20
Location: USA

PostPosted: Thu Jul 17, 2014 9:23 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Jul 17, 2014 9:31 pm    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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....
Back to top
View user's profile Send private message
John Kondrick

New User


Joined: 15 Jun 2010
Posts: 2
Location: USA

PostPosted: Thu Jul 17, 2014 11:00 pm    Post subject: Reply to: COBOL dynamic linking
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am
No new posts Cobol list of programs being called biswajit.dattagupta COBOL Programming 5 Tue Nov 01, 2016 2:10 am
No new posts Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us