What functionality is lost with AMODE(24) RMODE(24) ?

dcshnier · Posted: Fri Jul 10, 2009 7:16 pm

We are releasing a brand new COBOL-DB2 program that has to call some legacy programs that are statically linked at AMODE(24) RMODE(24).
Our initial tests failed on a S0C4 when calling these modules because our new COBOL-DB2 calling program was compiled at AMODE(31) RMODE(ANY). We fixed the problem by recompiling the new program using AMODE(24) RMODE(24). Unfortunately, the better alternative of recompiling the called programs to be above the line, was not an option. Can anyone give any examples of functionality that we wil have lost by now having to run this new calling program 'below' the 16 MEG line.
For example. I seem to recall 12 years ago during a file expansion project, when the new record length became very large, that the program would periodically blow up. We fixed the problem by compiling above the line AMODE(31) RMODE(ANY). So I am looking for those types of examples of lost functiionality (i.e. dealing with large record lengths), when the program is compiled below-the line. Can anyone think of any ?

thanks greatly
dcshnier

Robert Sample · Posted: Fri Jul 10, 2009 8:03 pm

After accounting for system overhead, there's generally about 9 to 10 megabytes available below the line for programs to run in. If you have a lot of programs being called, or large programs, you could run into memory issues. By contrast, above the line you've got about 1.9 gigabytes of memory available so there is not as much a chance of running into memory issues (although you never know about Java).

dcshnier · Posted: Fri Jul 10, 2009 8:26 pm

Thank-you Robert

That is really useful to know.
Your patience is appreciated, because I am not the best person who can judge just how much of that 9-10 megabytes we may be using up.
But two questions arise on this memory limitation that you bring up:

(1) If we could make this program a pure COBOL program (without DB2), do you think that would buy us some memory to make it worth the effort ?
(albeit, it would still have to call some DB2 programs).

(2) The program that we are releasing calls 4 programs in static mode and 2 programs in dynamic mode. However, those called programs make calls to other programs that in turn make calls to other programs. So when you imply that calling many programs could lead to memory issues, is this threshhold impacted by all calls throughout the calling chain or just those programs that are being directly called ?

again, your patience is appreciated.

regards
dcshnier

Bill O'Boyle · Posted: Fri Jul 10, 2009 8:29 pm

Are you running this in CICS? If so, what's your version/release?

Regards,

Robert Sample · Posted: Fri Jul 10, 2009 8:58 pm

If you're running in CICS, the call chain depends upon whether an XCTL or LINK is done -- the XCTL can release the calling program's storage since you're not going back to it; the LINK requires that the calling program be preserved since you will be going back to it.

Generally, static and dynamic refer to whether the program is part of the load module or not; the memory requirement (for batch) tends to be the length of the calling chain (although CANCEL of a dynamic program can change that). Static programs are part of the memory requirement of the load module while dynamic programs only require memory upon invocation. Of course, if you have dynamic program calling dynamic program calling dynamic program ... you will sooner or later run into memory issues.

I don't know for sure whether including the DB2 stuff in the load module has an impact, but I suspect the impact, if any, would be minor. If it is not part of the load module, then it has to be dynamically loaded at run time when the DB2 call occurs. You can pay the piper now, or you can pay the piper later but the piper is getting paid. The only exception would be if the bulk of the DB2 work is being done in a different address space, which would have its own memory.

If this seems like a serious issue to you, contact your site support group and discuss how your site is set up. There may be some things they can do to help alleviate your memory issues.

dcshnier · Posted: Fri Jul 10, 2009 9:54 pm

Thank-you to all who have replied.
In case this makes a difference to what responses have been offered thus far, this is a batch process (not a CICS process).
But you have given us much thought to go over.
thanks again.

regards
dchnier