How to force working-storage "above the line"

dick scherrer · Posted: Fri Jul 20, 2012 3:17 am

Earlier, Someone came to me with their crisis du`jour and when i heard what they had and where they wanted to go, i said to myself, Self, we could to this with some array(s). This batch process will pass several hundred million records when the full folume is used. The arrays will drive selection of a few hundred thousand records from the monster set (should be quite a bit faster than creating a VSAM file and i don't have the authority to just add a couple of database tables). . .

So, when we put together a prototype to test with only a few hundred entries it worked quite well. Then when the crisis holder changed the code to full volume, the program would not run:
CEE0813S Insufficient storage was available to satisfy a get storage (CEECZST)
request.
The traceback information could not be determined.

The linkedit shows:
IEW2278I B352 INVOCATION PARAMETERS - LIST,XREF,LET,MAP,AMODE=24,RMODE=24

Because i had suggested this approach, i kinda felt i should see it thru, so:
I cobbled up a new linkedit trying to kick the w/s over the line. When this is linkedited, the following is shown:
IEW2278I B352 INVOCATION PARAMETERS - LIST,XREF,LET,MAP,AMODE=24,RMODE=AN
IEW2658E 5119 USER-SPECIFIED AMODE(24) AND RMODE(ANY) ARE INCOMPATIBLE.
Looking up the IEW2278I, the last bit says the ever popular IBM phrase - "the results may be unpredictable". This appears to be true as running the code gives an s0c6 (yup - 6).

The array is only a bit over 10meg which is way below the max in the Compiler Options.

Suggestions on how to get the w/s over the line? This is the first time i've tried to specify RMODE in several years - it has been automagic everywhere i've been if it was used. . . This system is z/OS 1.11. The "tech" group here stopped supporting the mainframe years ago (direction was to change everything to "servers" - which isn't happening at all really), so all of this comes my way - which is kinda cool

Thanks,

d

dbzTHEdinosauer · Posted: Fri Jul 20, 2012 4:17 am

AMODE(31)

dbzTHEdinosauer · Posted: Fri Jul 20, 2012 4:28 am

LPARM='AMOD=31,LIST,REFR,RENT,RMOD=ANY,XREF'

Robert Sample · Posted: Fri Jul 20, 2012 4:42 am

Compiler option DATA(31)
Linkage editor / binder options AMODE(31),RMODE(ANY)
CEE run time option HEAP(,,ANYWHERE)

The combination should do the trick, unless there's something sneaky going on there.

Bill O'Boyle · Posted: Fri Jul 20, 2012 6:38 am

Dick,

The LE Callable Service routine to get heap storage is "CEEGTST".

It sounds like you should define the array in LINKAGE as a true "ODO" and only get the storage you need.

Regards,

dick scherrer · Posted: Fri Jul 20, 2012 7:52 am

Thanks Guys!

Changed the linkedit to this:
IEW2278I B352 INVOCATION PARAMETERS - LIST,XREF,LET,MAP,AMODE=31,RMODE=AN
and it worked.

I already had the DATA(31) in the COBOL options and haven't yet tried doing anything with HEAP.

Don't know where my brain was earlier, but i intentionally stayed away from AMODE(31) . . . Tried all of the combinations using AMODEs and RMODEs and was most consistent avoiding AMODE(31) . . . I have no idea why . . .

I'll run a few more tests tonight and send an e-mail so others can continue early tomorrow.

Perhaps this is now a done deal

@Bill

Bill Woodger · Posted: Fri Jul 20, 2012 12:47 pm

(other Bill)

From this and what you have said it would initially point to REGION.

If the program is not requesting additional storage, then I can only think that it is the load of the program failing or, after googling, maybe the program is using an intrinsic function which acquires storage for its purposes?

The parameters for getting storage from the HEAP can be generated at run-time. Would keep the storage used by the program to a "minimum" for the volume of data for that run.[/url]

don.leahy · Posted: Fri Jul 20, 2012 6:15 pm

dick scherrer · Posted: Fri Jul 20, 2012 6:38 pm

Hello,

Tried a few REGION= values including 0M as well as no REGION= parameter. All runs failed with the "insufficient storage" condition.

As soon as i corrected the linkedit, all went well.

d

don.leahy · Posted: Fri Jul 20, 2012 6:50 pm

That makes sense. If you use amode/rmode(24) then the system will try to find all the storage you need below the line no matter what you specify for the REGION parm.

Below the line storage is a scarce resource; in most shops there is likely to be less than 10M available because of overhead. In our shop the systems programmers are on a relentless campaign to get all application code above the line. (The main problem is that we still have some OS/VS Cobol code, where below the line was your only option).

dick scherrer · Posted: Fri Jul 20, 2012 7:17 pm

Hello,

I made a few calls this morning to some previous sites and it seems that many places now use:
Linkage editor / binder options AMODE(31),RMODE(ANY)
for all of their batch compiles.

Is this how the standard compile/link is set up on your systems?

Is there any reason to continue to use:
AMODE=24,RMODE=24?

I'll probably try to get our standard batch compiles changed officially if this is the right way to go.

Thanks again,

d

Anuj Dhawan · Posted: Fri Jul 20, 2012 8:24 pm

don.leahy · Posted: Fri Jul 20, 2012 8:27 pm

We use AMODE(31),RMODE(ANY) as the default.

When we have to call an old OS/VS Cobol subroutine or 24 bit Assembler subroutine (rare), the calling program (usually Enterprise Cobol) is compiled with DATA(24) to avoid parameter addressing issues.

If we have to change an OS/VS Cobol program, we are required to upgrade it to Enterprise Cobol. IMO this is a smart way to go; you have to test the change anyway so why not upgrade at the same time? The possible incompatibilities are well documented in the Cobol Migration guide.

dbzTHEdinosauer · Posted: Fri Jul 20, 2012 8:35 pm

during the late 80's and 90's, i found converting old dos shops to mvs also meant getting rid of the amode(24) mentality.
as robert mentioned in an assembler thread recently, assember must use the dcbe to get above the line (16 meg line).

otherwise, simply recompiling/relinking everything in the world to amode(31),rmode(any) had little impact on integrity of output,
but had a very large impact on throughput. especially the old legacy 30,000 line cobol modules.

it took a while for the speed of the iron to increase to the point that db2 would actually be faster than manual book-keeping.
it took a while to change the mindset of older programmers to modularize instead of one-big-module to do it all. actually, it was easier to take competent java and c programmers, teach and mentor them in cobol, than to change behaviour of old-style programmers.

the fear of 'time lost' loading (dynamic CALLs) sub-modules has always been an argument of dinosaurs,
but my argument has been, why, if dynamic CALLs are sooooo bad,
does IBM write the ops-sys with so many small, dynamically CALLed modues?

I have always used AMOD(31) rmode(any) for cobol II.

as don pointed out:
if you stay amod(24) you never have access to the memory above 16mg.

Bill O'Boyle · Posted: Fri Jul 20, 2012 9:21 pm

Don/DBZ,

Yes, I thnk we all know Jim from the defunct "MVS Forums", but I haven't been able to contact him as his e-Mail comes back as inactive/unknown.

He would be a welcome addition to this site.

Regards,

don.leahy · Posted: Sat Jul 21, 2012 1:28 am

I've always admired Jim not just for his technical knowledge, but for his superb communication skills.