Many thanks to all who responded and especially to Peter for posting
this piece of ASSEMBLER
which solves the problem.
I am very impressed by the helpfulness of this mailing list, which I
experienced this time again
and many times before.
@Max: the code that you provided unfortunately does not work on my
compiler version (VSE),
because it forbids getting the address of WS items. That's why I need an
ASSEMBLER subroutine
to do this, much the same way as the generated code for the DB2
interface DSNHLI does it
(at least in earlier releases, IIRC).
Kind regards
Bernd
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
