I would agree with that assessment Bernd. The only remaining restriction on
ADDRESS OF in z/OS COBOL is for FILE section items, and even that can be solved
with a simple assembler "give me the address of this variable" subroutine if
you need it. Most shops already have one such subroutine laying around
somewhere, but even if not it is trivial to create.
If you already have DB2 in house and operational, you can even co-opt one of
the DB2 subroutines for your own use. Just carefully examine the SQL-INIT
paragraph in a normal DB2 COBOL compile listing to figure out which one to use.
Or just use this:
GETADDR CSECT
GETADDR AMODE ANY
GETADDR RMODE ANY
L 15,4(,1)
LA 15,0(,15)
MVC 0(4,1),0(15)
SR 15,15
BR 14
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Bernd Oppolzer
Sent: Friday, October 1, 2021 10:27 AM
To: [email protected]
Subject: Re: COBOL issue
Sorry, forgot to mention:
I'm on VSE, the Compiler release is COBOL for VSE/ESA 1.1.1; this Compiler
definitely only allows items from the Linkage Section.
Nice to know about later version on other OSes.
So there is no danger in applying an ASSEMBLER workaround and probably no other
(simple and performant) COBOL-only fix.
Kind regards
Bernd
Am 01.10.2021 um 16:18 schrieb Joe Monk:
> Depends on the release of the COBOL compiler. Later releases support
> working-storage items, earlier releases only allow linkage items.
>
> Joe
>
> On Fri, Oct 1, 2021 at 8:50 AM Bernd Oppolzer
> <[email protected]>
> wrote:
>
>> Probably asking a COBOL question for the first time :-)
>>
>> I am thinking about writing a general sub-program using COBOL which
>> does several different computations, each of them needing different
>> input and output data of different size.
>>
>> Because this should work with Batch and CICS, I am thinking about a
>> single communication area with fixed size, which points to another
>> communiation area of variable size.
>>
>> The area looks like this:
>>
>> 01 COMMAREA.
>> 05 CA-FUNCTION_CODE PIC X(8).
>> 05 CA-STATUS PIC 99.
>> 05 CA-AREA-ADDR USAGE POINTER.
>> 05 CA-AREA-LEN PIC S9(4) COMP.
>>
>> I managed to write the called subroutine; the COMMAREA is in the
>> LINKAGE SECTION there, and I can use the address in the CA-AREA-ADDR
>> and read and write the values in the variable comm-area, which is
>> linked to the fixed area. No problem so far.
>>
>> But:
>>
>> in the calling program, when setting up the COMMAREA.
>> I cannot put the address of a WORKING-STORAGE FIELD into the
>> CA-AREA-ADDR. Because simply it is not allowed to use SET
>> CA-AREA-ADDR TO ADDRESS OF field on WS fields.
>>
>> Why? IMO there is no danger in passing the address of a WS field to a
>> subprogram.
>> Even if the WS field were in automatic storage (which it is not,
>> IMO), there would be no problem. In fact, this is done implicitly
>> using call-by-reference, but I want to do it now sort of explicitly
>> (this way overcoming some restrictions with CICS and fixed lengths
>> of COMMAREAs).
>>
>> I recall having seen the DB2 precompiler generating ASSEMBLER routine
>> calls to do just this (getting the address of a WS field to feed it
>> into the
>> DB2 interface
>> DSNHLI). Is this the only possible way to go?
>>
>> Thank you, kind regards
>>
>> Bernd
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
