Buffer limit reached while handling huge records

Bill O'Boyle · Posted: Wed Apr 02, 2014 5:29 pm

I think you maybe in luck. Review the LE Callable Service routine CEECRHP (Create Heap), where you can request 24-Bit storage by the AMODE(31) Caller.

The only issue might be the PARMLIST created by COBOL, when calling the AMODE(24) sub-program, as it might be built from the AMODE(31) callers TGT (Working-Storage).

If the PARMLIST is created from AMODE(31) storage, when the AMODE(24) sub-program gains control, you may get a S0C4, because (under the covers), the sub-program needs to address R1 and if the address is 31-Bit, the high-order byte of the parmlist-address (at zero off R1) will be lopped-off, resulting in an invalid-address and a S0C4.

Lots of fun and games....

Bill Woodger · Posted: Wed Apr 02, 2014 5:54 pm

rajendra kalepu,

Can you show the definitions of your three tables?

dick scherrer · Posted: Wed Apr 02, 2014 6:46 pm

Hello,

Possibly this is too far afield, but could you not have 2 callable modules - 1 for 24 and the other for 31?

Personally, i'd prefer a single bit of code, but properly documented and understood, this might be a simple workaround . . .

Rohit Umarjikar · Posted: Thu Apr 03, 2014 12:13 am

Raj,

Let us get to the root cause, tell us agian few things.

1) As Nic and Terry said here, can you be able to store only key values to these array's ?
2) Why would you need to store entire record and apprently all the records into working storage and getting them exausted with storage?
3) If you have input as PS file then can't your program do sequential logic processing as others do in this industry?
4) If there is a limit of 128MB designed or may be more depending upon the MODE, still why would like to reach to that limit now or in nearer future?

So I think as well as Dick also said please explain us the logic and may be restructuring the piece of code would solve the problem forever.

dbzTHEdinosauer · Posted: Thu Apr 03, 2014 7:17 pm

the TS has stated that this program is 15 years old.

sounds as if his shop was an old DOS shop,
thus the 24 bit constraint,
and put everything on a new (semi-new)
MVS machine and let everything rip.
sounds as if they are trying to do everything on the cheap.

they probably have a billion sub-programs and the company has not made very good plans to migrate the system.

before i would start enabling 32 bit code, and dealing with the problem of calling 24 bit modules,
i would revisit the module in question.
Nic, Terry and Dick all alluded to the logic problem.
WTF does everything have to be stored?
Machine time would be better spent properly SORTing input against the proposed usage
than running indexes up and down tables searching for a hit.
If the problem is multi-hit on same input and required accumulation,
output a record for each hit
and create the accumulation with SORT.
SORT will run in 32bit environment, with nearly unlimited record count,
thus minimizing the required changes to the existing program
and forcing a one-by-one conversion in this unprepared rookie environment.

an alternate approach would be to replace this old program with a JOINKEYS sort.

rajendra kalepu · New User Joined: 29 Jul 2011 Posts: 21 Location: India

Hi All,

Sorry for the Late reply as i am out of station

Rohit-

You are right, Storing Key is better compared to entire record

Unfortunately since the program was written 15 years back i was just thinking whether they might have written it for a reason

The program just reads the file, stores type0, type1 and type 2 records in 3 different arrays for a particular key until new key is found, Then loads database with respective values.
Once the new key is found the array is initialized and new Key is loaded and process repeated.

I am taking each and every one of your inputs and will try to re structure it
which will give me along term solution

i will update you all on my findings and approach shortly

Thanks

Nic Clouston · Posted: Mon Apr 07, 2014 8:37 pm

If you are just merging data from 3 files into one record per key then maybe a JOINKEYS solution in you sort product may be the way to go? Create each record to be loaded in sort and use your COBOL program to load it. JOINKEYS would not have been available when the program was originally written so it may be worth a look.

Rohit Umarjikar · Posted: Tue Apr 08, 2014 3:36 am

If you are using DB2 as a Data Base then instead of an array use a Global Temp Table and insert all the rows into it than populating Array , or as Nic and others suggested to check if JOINKEYS makes sense to get what you want bedore you invoke a COBOL program.