Re: COBOL issue
Bernd, forget it ! :D Your code works on my zOS. Best regards. Il giorno ven 1 ott 2021 alle ore 17:55 Bernd Oppolzer < bernd.oppol...@t-online.de> ha scritto: > 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 > >> > >> 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-LENPIC 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
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 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-LENPIC 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
I'm sorry, I'm not at a terminal so my idea had not been proven. Il giorno ven 1 ott 2021 alle ore 17:46 Massimo Biancucci ha scritto: > Bernd, > > AFAIK the SET ADDRESS OF is to set a pointer to address a piece of storage. > This is why Cobol doesn't you allow to do such a command. > > If you want to "grab" the ADDRESS OF your working storage variable, you > should define a POINTER in LINKAGE then set it to the value and then move > it to your commarea pointer. > > CALLING-PROGRAM. > WORKING-STORAGE. > > 01 MY-AREA PIC X(1000) > 01 COMMAREA. > 05 CA-FUNCTION_CODE PIC X(8). > 05 CA-STATUS PIC 99. > 05 CA-AREA-ADDR USAGE POINTER. > 05 CA-AREA-LENPIC S9(4) COMP. > > LINKAGE-SECTION. > 01 MY-PTR USAGE IS POINTER. > > PROCEDURE DIVISION. > > SET MY-PTR TO ADDRESS OF MY-AREA. > MOVE MY-PTR TO CA-AREA-ADDR. > > Best regards. > Max > > > Il giorno ven 1 ott 2021 alle ore 15:50 Bernd Oppolzer < > bernd.oppol...@t-online.de> ha scritto: > >> 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-LENPIC 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 >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
Bernd, AFAIK the SET ADDRESS OF is to set a pointer to address a piece of storage. This is why Cobol doesn't you allow to do such a command. If you want to "grab" the ADDRESS OF your working storage variable, you should define a POINTER in LINKAGE then set it to the value and then move it to your commarea pointer. CALLING-PROGRAM. WORKING-STORAGE. 01 MY-AREA PIC X(1000) 01 COMMAREA. 05 CA-FUNCTION_CODE PIC X(8). 05 CA-STATUS PIC 99. 05 CA-AREA-ADDR USAGE POINTER. 05 CA-AREA-LENPIC S9(4) COMP. LINKAGE-SECTION. 01 MY-PTR USAGE IS POINTER. PROCEDURE DIVISION. SET MY-PTR TO ADDRESS OF MY-AREA. MOVE MY-PTR TO CA-AREA-ADDR. Best regards. Max Il giorno ven 1 ott 2021 alle ore 15:50 Bernd Oppolzer < bernd.oppol...@t-online.de> ha scritto: > 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-LENPIC 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
Also, it's in the back of my mind that you can set a pointer to a '01' level, but only a '01' level. But, I work across all platforms and I may be thinking z/OS. If you are not using the SET ADDRESS against an '01' level, give it a try. Tony Thigpen Tony Thigpen wrote on 10/1/21 10:57 AM: Grab my small assembler program to do this: http://dinomasters.com/coolstuff/bsttezsp.txt Tony Thigpen Bernd Oppolzer wrote on 10/1/21 10:27 AM: 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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
Grab my small assembler program to do this: http://dinomasters.com/coolstuff/bsttezsp.txt Tony Thigpen Bernd Oppolzer wrote on 10/1/21 10:27 AM: 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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
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) LA15,0(,15) MVC 0(4,1),0(15) SR15,15 BR14 Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bernd Oppolzer Sent: Friday, October 1, 2021 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 > > 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-LENPIC 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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-LENPIC 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL issue
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 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-LENPIC 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
