Storage problem at run-time due to "Calling subprograms"

[PMSDonald]

Hi,

For calling subprograms I use "dynamic calls". At run-time I get problems with "insufficient storage". The coding looks like:

PROGRAM A.
MOVE "B" TO PGM
CALL PGM USING parameter
CANCEL PGM
.

PROGRAM B.
MOVE "C" TO PGM
CALL PGM USING parameter
CANCEL PGM
statements
GOBACK
.

PROGRAM C.
statements
GOBACK
.

It seems that after the calling SEVERAL times a subprogram, the called program is still (everywhere) in the storage, but the link doesn't exists anymore...Is there any way to give the used storage free after calling/executing the sub-program(s) by using a COBOL-statement or adding a JCL-option during compilation/run-time, because it seems that for each called subprogram he stores the program in his storage.....after a while, the storage get full.....

Thanks in advance!

 

[webrabbit]

You didn't specify your platform. I presume it is IBM Mainframe.

How many different programs are involved? If there are not very many, remove the CANCELs or try this code:

 01  PGM       PIC X(08) VALUE SPACE.
 01  NEW-PGM   PIC X(08).    
   .
   .
   .
    MOVE 'A' TO NEW-PGM
    IF NEW-PGM NOT = PGM
        IF PGM NOT = SPACE
            CANCEL PGM
        END-IF
        MOVE NEW-PGM TO PGM
    END-IF
    CALL PGM USING parameters

 

[gregsimpson]

Have you tried upping or even using the REGION parameter.

Also a long shot but would issuing a COMMIT help?

Would using "PROGRAM IS INITIAL" and not cancelling the program each time make any difference.

May be worth looking at your compile, link and runtime options too.

These are not definites just thoughts from the top of my head which may or may not help you. Knowing this forum they will prompt some discussion and you'll end up with you answer.

Cheers
Greg

 

[Dimandja]

If you need to reuse the subprograms, why CANCEL them?

There is no telling how long it takes your operating system to clean up each CANCEL. You are firing away well ahead of the clean-up routines (if they exist/work on your system).

Remove CANCEL pgm. There's a statement that's never been very useful.

 

[razalas]

I have found that programmers use CANCEL when they want all the variables re-initialized when re-entering a sub-program rather than using the INITIAL attribute as gregsimpson points out. I believe that this is mainly due to a lack of awareness of the INITIAL attribute and/or what it means.

I agree with Dimandja that CANCEL should be reserved for situations where you know that you are done using a sub-program and won't be using it again. "Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[gregsimpson]

I agree with the other posts. See if they give you any success. I am able to expand a little on my post now I am back in front of a mainframe

LINK EDITOR

AMODE=value indicates whether the program uses 24 or 31 bit addressing, that is whetehr it cann address memory above the 16MB line. AMODE=31 specifies 31 bit addressing, AMODE=ANY specifies both 24 and 31 bit addressing. AMODE=24 specifies 24 bit addressing and requires the program to run below the 16MB line.

RMODE=value indicates where the program can reside in virtual storage. RMODE=ANY allows the program to reside above the 16MB line and requires AMODE=31 or AMODE=ANY. RMODE=21 requires the program to reside below the 16MB line. IF AMODe is coded, RMODE=24 defaults. Otherwise the compiler establishes the default.

You can use the REGION parameter on the EXEC statement or more rarely on the JOB statement.

EXEC Statement

//STEPA EXEC PGM=MYPROG,REGION=64K - This allocates 64K of Storage

//COB2UCLG,REGION.LKED=128L,REGION.GO=64K - This allocates the LKED step of the COB2UCLG PROC128K and the GO step 64K.

//EXEC COB2UCLG,REGION=1920K - This allocates each step in the COB2UCLG PROC 1920K of storage.

JOB Statement

IF you put the REGION parameter on the JOB statement you must allow enough storage for the maximum region required by any step. Also if this is used the system ignores all REGION parameters on EXEC statements within the job.

//RT452216 JOB(12345),'GREGS',CLASS=C,REGION=1920K


REGION=0K or 0M means the system allocates all available storage both above and below the line. You get different results from different settings depending on what you use. I suggest you look up the REGION PARM in a JCL manual for the full info on extended region size etc.

Cheers
Greg

 

[PMSDonald]

Hi all,

Thanks for all the issues and remarks, but after trying them out, no issue helped me further so far....I still have storage problems...
Are there maybe things I can try at the compilation, link or run-time options...
Other ideas?...

Thanks in advance !

Kind regards,
Donald.

 

[webrabbit]

You never did answer the question of how many programs are involved.

 

[Dimandja]

Also, see if you can show some code.
For example, what is parameter in: CALL PGM USING parameter?

 

[gregsimpson]

Donald,

I have posted some options for run time and linking. I suggest you

a) Post a cut down version of your code as WEBRABBIT and Dimandja have requested you.

b) Post your job output with JCL etc.

Perhaps then we can see exactly what your problem is rather than just guessing cryptically.

Cheers
Greg

 

[PMSDonald]

Thanks to all of you guys out there for your suggestions. It did help me a lot as it made me review all the options you mentioned, which led me to find the best(?) way to solve this specific problem is to link a chain of programmes together in 1 module.

After that was done, we were still having problems which were erroneously taken for storage problems. These were actually errors in the way sql calls to our CA/Datacom database and calls to nested programmes are handled in our environment.

But, as the saying goes ; all's well that ends well.