GETMAIN limitations in COBOL?? 
Author Message
 GETMAIN limitations in COBOL??

I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
allocate and release memory in my programs.

I ran into the following problem and did not know what caused it,

my linkage section has two fields defined like this

LINKAGE SECTION

01 FIELD-1     PIC X(10000000).
01 FIELD-2     PIC X(10000000).

PROCEDURE DIVISION

.
.
** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
**(which means only 10000 bytes of each of the fields are addressable
**then subsequently i coded this.

MOVE FIELD-1 TO FIELD-2

*While I tested this code in XPEDITOR  CICS suspended my task
indefinitely on the above 'MOVE'

Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
the whole of 10000000 declared in the picture clause from FIELD-1 TO
FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN ( and
since it could not get the 10 megabytes of storage it just suspended
the task??)

I had to bounce the CICS region before we could execute any other
transaction in the region.

Any  light into this topic is appreciated.

krishna.

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
COBOL doesn't know that the storage was 'GETMAIN'ed. In fact, COBOL
doesn't care that it is running as a CICS task at all. It just generates
an MVCL instruction for 10000000 bytes.

What you need to do is this:

) Set a field in working storage 01 GM-LEN PIC S9(8) COMP.
) Move 10000 (or some other value) to it
) Do a GETMAIN using this field as the length of the GETMAIN.
  (GETMAIN may not like a 4-byte length for it's length parameter.
   If not,you will have to improvise).
) Do a MOVE with reference modification instead:
    MOVE FIELD-1 (1:GM-LEN) TO FIELD-2.

This should work .

Tim Coffey


Quote:

> I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> allocate and release memory in my programs.

> I ran into the following problem and did not know what caused it,

> my linkage section has two fields defined like this

> LINKAGE SECTION

> 01 FIELD-1     PIC X(10000000).
> 01 FIELD-2     PIC X(10000000).

> PROCEDURE DIVISION

> .
> .
> ** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
> **(which means only 10000 bytes of each of the fields are addressable
> **then subsequently i coded this.

> MOVE FIELD-1 TO FIELD-2

> *While I tested this code in XPEDITOR  CICS suspended my task
> indefinitely on the above 'MOVE'

> Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
> the whole of 10000000 declared in the picture clause from FIELD-1 TO
> FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN ( and
> since it could not get the 10 megabytes of storage it just suspended
> the task??)

> I had to bounce the CICS region before we could execute any other
> transaction in the region.

> Any  light into this topic is appreciated.

> krishna.

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.


Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
You've Acquired 10000 Bytes via the GETMAIN but, the COBOL Compiler is going
to generate an In-Line MVCL for 10000000 Bytes or even possibly issue a BALR
to a COBOL Run-Time Routine. The Compiler doesn't know you've only Acquired
10000 bytes ! Therefore, when the microcode hits byte 10001, you're going
down with a S0C4 (Protection Exception), because you don't have
addressability past byte 10000. My advice is to define an S9(09) BINARY
field, move 10000 to it (or LENGTH OF FIELD-1 or FIELD-2), issue the
GETMAIN's using this fullword and then perform the MOVE, using the fullword
as the length-portion of a REFERENCE-MODIFICATION move.

03 WS-FLENGTH PIC S9(09) BINARY VALUE +10000.

getmain done here....

MOVE FIELD-1 TO FIELD-2 (1:WS-FLENGTH).

You won't need the reference modification in the sending field if you're
starting at byte-01.

Unless you have a good reason NOT to Acquire Storage above the line, use the
FLENGTH parameter in the GETMAIN.

HTH....

WOB

Quote:

> I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> allocate and release memory in my programs.

> I ran into the following problem and did not know what caused it,

> my linkage section has two fields defined like this

> LINKAGE SECTION

> 01 FIELD-1     PIC X(10000000).
> 01 FIELD-2     PIC X(10000000).

> PROCEDURE DIVISION

> .
> .
> ** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
> **(which means only 10000 bytes of each of the fields are addressable
> **then subsequently i coded this.

> MOVE FIELD-1 TO FIELD-2

> *While I tested this code in XPEDITOR  CICS suspended my task
> indefinitely on the above 'MOVE'

> Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
> the whole of 10000000 declared in the picture clause from FIELD-1 TO
> FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN ( and
> since it could not get the 10 megabytes of storage it just suspended
> the task??)

> I had to bounce the CICS region before we could execute any other
> transaction in the region.

> Any  light into this topic is appreciated.

> krishna.

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??

Quote:

> I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> allocate and release memory in my programs.

<Rest Snipped>

BTW, a FREEMAIN is only necessary if you're going to continue with the
task but you're done with the storage. However, depending on the amount
of executable code that is left to reach task termination, sometimes
it's not worth explicitly FREEING the storage, simply because CICS will
implicitly FREE the storage at task termination.

You're going to have to use reference modification in the FREEMAIN:

EXEC CICS FREEMAIN
          DATA(FIELD-1 (1:WS-FLENGTH))
          END-EXEC.

Note that in my previous post, I had suggested using the LENGTH OF
FIELD-1 or FIELD-2 in the GETMAIN, which was INCORRECT, so please
DISREGARD this suggestion, I had my head up my A$$.

Slowly removing head from cavity....

WOB

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
Tim,

your move will cause also a storage-violation because Cobol
fill trailing spaces to Field-2

Roland



Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
That is just what happened.
You are MIXING two different concepts.
For the GetMain, you pass  it an item of type

    01 ws-field    USAGE POINTER.

If it is not equal NULL or Zero upon return, then it is a
memory address.

The attempt to Move FIELD1 to FIELD2 did cause itto attempt to
move that much.

Quote:

> I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> allocate and release memory in my programs.

> I ran into the following problem and did not know what caused it,

> my linkage section has two fields defined like this

> LINKAGE SECTION

> 01 FIELD-1     PIC X(10000000).
> 01 FIELD-2     PIC X(10000000).

> PROCEDURE DIVISION

> .
> .
> ** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
> **(which means only 10000 bytes of each of the fields are addressable
> **then subsequently i coded this.

> MOVE FIELD-1 TO FIELD-2

> *While I tested this code in XPEDITOR  CICS suspended my task
> indefinitely on the above 'MOVE'

> Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
> the whole of 10000000 declared in the picture clause from FIELD-1 TO
> FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN ( and
> since it could not get the 10 megabytes of storage it just suspended
> the task??)

> I had to bounce the CICS region before we could execute any other
> transaction in the region.

> Any  light into this topic is appreciated.

> krishna.

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
Almost:
MOVE FIELD-1 (1:GM-LEN) TO FIELD-2 (1 :GM-LEN) will work
You need to specify the actual length of the area because COBOL thinks
that the area obtained is described by the picture.


Quote:

> COBOL doesn't know that the storage was 'GETMAIN'ed. In fact, COBOL
> doesn't care that it is running as a CICS task at all. It just generates
> an MVCL instruction for 10000000 bytes.

> What you need to do is this:

> ) Set a field in working storage 01 GM-LEN PIC S9(8) COMP.
> ) Move 10000 (or some other value) to it
> ) Do a GETMAIN using this field as the length of the GETMAIN.
>   (GETMAIN may not like a 4-byte length for it's length parameter.
>    If not,you will have to improvise).
> ) Do a MOVE with reference modification instead:
>     MOVE FIELD-1 (1:GM-LEN) TO FIELD-2.

> This should work .

> Tim Coffey



> > I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> > allocate and release memory in my programs.

> > I ran into the following problem and did not know what caused it,

> > my linkage section has two fields defined like this

> > LINKAGE SECTION

> > 01 FIELD-1     PIC X(10000000).
> > 01 FIELD-2     PIC X(10000000).

> > PROCEDURE DIVISION

> > .
> > .
> > ** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
> > **(which means only 10000 bytes of each of the fields are addressable
> > **then subsequently i coded this.

> > MOVE FIELD-1 TO FIELD-2

> > *While I tested this code in XPEDITOR  CICS suspended my task
> > indefinitely on the above 'MOVE'

> > Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
> > the whole of 10000000 declared in the picture clause from FIELD-1 TO
> > FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN ( and
> > since it could not get the 10 megabytes of storage it just suspended
> > the task??)

> > I had to bounce the CICS region before we could execute any other
> > transaction in the region.

> > Any  light into this topic is appreciated.

> > krishna.

> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Sun, 03 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??

Quote:

> COBOL doesn't know that the storage was 'GETMAIN'ed. In fact, COBOL
> doesn't care that it is running as a CICS task at all. It just generates
> an MVCL instruction for 10000000 bytes.

> What you need to do is this:

> ) Set a field in working storage 01 GM-LEN PIC S9(8) COMP.
> ) Move 10000 (or some other value) to it
> ) Do a GETMAIN using this field as the length of the GETMAIN.
>   (GETMAIN may not like a 4-byte length for it's length parameter.

It loves it, try FLENGTH(...) - be sure to define a fullword (the voice
of experience).

Better yet, code:

        FLENGTH(length of your-object)

The translator will do all the housekeeping for you.

Bill {*filter*}



Mon, 04 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
Will I be able to use cobol verbs like INSPECT ans INITIALIZE on these
fields if they do not have full addressability??



Quote:
> You've Acquired 10000 Bytes via the GETMAIN but, the COBOL Compiler
is going
> to generate an In-Line MVCL for 10000000 Bytes or even possibly issue
a BALR
> to a COBOL Run-Time Routine. The Compiler doesn't know you've only
Acquired
> 10000 bytes ! Therefore, when the microcode hits byte 10001, you're
going
> down with a S0C4 (Protection Exception), because you don't have
> addressability past byte 10000. My advice is to define an S9(09)
BINARY
> field, move 10000 to it (or LENGTH OF FIELD-1 or FIELD-2), issue the
> GETMAIN's using this fullword and then perform the MOVE, using the
fullword
> as the length-portion of a REFERENCE-MODIFICATION move.

> 03 WS-FLENGTH PIC S9(09) BINARY VALUE +10000.

> getmain done here....

> MOVE FIELD-1 TO FIELD-2 (1:WS-FLENGTH).

> You won't need the reference modification in the sending field if
you're
> starting at byte-01.

> Unless you have a good reason NOT to Acquire Storage above the line,
use the
> FLENGTH parameter in the GETMAIN.

> HTH....

> WOB




- Show quoted text -

Quote:
> > I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> > allocate and release memory in my programs.

> > I ran into the following problem and did not know what caused it,

> > my linkage section has two fields defined like this

> > LINKAGE SECTION

> > 01 FIELD-1     PIC X(10000000).
> > 01 FIELD-2     PIC X(10000000).

> > PROCEDURE DIVISION

> > .
> > .
> > ** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
> > **(which means only 10000 bytes of each of the fields are
addressable
> > **then subsequently i coded this.

> > MOVE FIELD-1 TO FIELD-2

> > *While I tested this code in XPEDITOR  CICS suspended my task
> > indefinitely on the above 'MOVE'

> > Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
> > the whole of 10000000 declared in the picture clause from FIELD-1 TO
> > FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN (
and
> > since it could not get the 10 megabytes of storage it just suspended
> > the task??)

> > I had to bounce the CICS region before we could execute any other
> > transaction in the region.

> > Any  light into this topic is appreciated.

> > krishna.

> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.


Mon, 04 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??
Thank you for the replies.
That was helpful.
As you said earlier , If i wanted to do a getmain on the whole of the
declared field then I could still use the LENGTH OF field.

Not helpful in my case though.
Also I am doing my freemains almost at the end of the transaction.
i will remove these.



Quote:


> > I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
> > allocate and release memory in my programs.

> <Rest Snipped>

> BTW, a FREEMAIN is only necessary if you're going to continue with the
> task but you're done with the storage. However, depending on the
amount
> of executable code that is left to reach task termination, sometimes
> it's not worth explicitly FREEING the storage, simply because CICS
will
> implicitly FREE the storage at task termination.

> You're going to have to use reference modification in the FREEMAIN:

> EXEC CICS FREEMAIN
>           DATA(FIELD-1 (1:WS-FLENGTH))
>           END-EXEC.

> Note that in my previous post, I had suggested using the LENGTH OF
> FIELD-1 or FIELD-2 in the GETMAIN, which was INCORRECT, so please
> DISREGARD this suggestion, I had my head up my A$$.

> Slowly removing head from cavity....

> WOB

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.


Mon, 04 Nov 2002 03:00:00 GMT  
 GETMAIN limitations in COBOL??

:>I am using CICS supplied GETMAIN/FREEMAIN commands to dynamically
:>allocate and release memory in my programs.

:>I ran into the following problem and did not know what caused it,

:>my linkage section has two fields defined like this

:>LINKAGE SECTION

:>01 FIELD-1     PIC X(10000000).
:>01 FIELD-2     PIC X(10000000).

:>PROCEDURE DIVISION

:>** i did  EXEC CICS GETMAIN on the 2 fields for 10000 bytes each.
:>**(which means only 10000 bytes of each of the fields are addressable
:>**then subsequently i coded this.

:>MOVE FIELD-1 TO FIELD-2

:>*While I tested this code in XPEDITOR  CICS suspended my task
:>indefinitely on the above 'MOVE'

:>Looked to me like CICS (or COBOL or XPEDITOR) was attempting to move
:>the whole of 10000000 declared in the picture clause from FIELD-1 TO
:>FIELD-2 instead of the 10000 bytes that I acquired thru. GETMAIN ( and
:>since it could not get the 10 megabytes of storage it just suspended
:>the task??)

:>I had to bounce the CICS region before we could execute any other
:>transaction in the region.

:>Any  light into this topic is appreciated.

Exactly how did you expect COBOL to know that the fields really really REALLY
weren't 10M long?

You said they were!!

Odds are you overlayed some important CICS control blocks which are kept in
unprotected storage and CICS went bye bye.

You probably should use explicit lengths or an OCCURS DEPENDING ON clause to
move what you know to be the real length of the fields.

--


http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Mon, 04 Nov 2002 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. GETMAIN/FREEMAIN routines in MVS Cobol/370

2. GETMAIN ACROSS LINKAGE IN COBOL

3. strange limitation in Microfocus COBOL

4. Power cobol Limitations

5. File Size limitation under RM Cobol Version 5.XX

6. GETMAIN

7. Getmain Help

8. GETMAIN

9. GETMAIN

10. MVS: GETMAIN / FREEMAIN

11. How to Do a GETMAIN in VS COBOL II Batch?

12. COBOL COBOL COBOL

 

 
Powered by phpBB® Forum Software