cobol, GETMAIN limitations in COBOL??

GETMAIN limitations in COBOL??

Author	Message
kittu.. #1 / 11	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

tscof.. #2 / 11	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

WOB #3 / 11	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

WOB Consultin #4 / 11	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

Roland Schiradi #5 / 11	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

mangogw #6 / 11	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

Clark F. Morris, Jr #7 / 11	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

William Lync #8 / 11	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

kittu.. #9 / 11	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 - Hide quoted text - - 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

kittu.. #10 / 11	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

Binyamin Diss #11 / 11	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

Page 1 of 1

[ 11 post ]