Re: COBOL issue

[Massimo Biancucci]

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

[Bernd Oppolzer]

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

[Massimo Biancucci]

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

[Massimo Biancucci]

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

[Tony Thigpen]

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

[Tony Thigpen]

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: PL/I vs. JCL

[Seymour J Metz]

I don't find EXEC's handling of positional parameters, keyword parameters with 
value and keyword parameters without value to be complex. But other things in 
CLIST drive me up the wall.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Skip Robinson 
Sent: Thursday, September 30, 2021 10:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Even a dead horse needs a tail. Parsing CLIST parms involves more than
sorting out characters and delimiters. There are (my terminology) three
kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each
variable is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the
keyword is present, the variable is assigned the value that matches the
variable name. 'Match' here means an unambiguous (sub)string. If the match
is ambiguous, CLIST prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded
like this: keyword(value). Value can be anything. Keyword entered by the
user must unambiguously match one coded in the CLIST, else CLIST prompts
the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user
had to supply lots of data at execution time. This framework offers
flexibility.


On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:

> I once wrote an external routine that can break a character string into
> various individual parms and return them on the stack.  It correctly parses
> strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work perfectly
> well with a string of one-word arguments, and if I don't have to remember
> what order they come in and don’t have to label them, anything more is
> almost never required.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Having your book turned into a movie is like seeing your oxen turned
> into bouillon cubes.  -John LeCarré */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> one of the most powerful features of CLIST is the mechanism by which
> parameters/options are passed by the user: positional or keyword, required
> or optional, with system prompting. I once saw a REXX routine that
> simulated the old command/CLIST parm processing. It was very complicated
> and hardly worth the trouble IMHO.
>
>
--

Skip Robinson
323-715-0595

--
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

[Farley, Peter x23353]

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: PL/I vs. JCL

[Seymour J Metz]

Can you guaranty that there will never be a name that is used for both a member 
and a ddname?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Friday, October 1, 2021 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I would never have seen this in advance, but one advantage I found when 
switching to REXX is that I'm almost eliminated positional parms from my 
commands.  In all but a few cases, the program can tell what it is by looking 
at it.  Thus every user can enter the arguments in the order that seems most 
logical to him, or (in my case) in the order that occurs to me at the time.  
It's a small convenience, but I cherish it.

The one exception that occurs to me just now is my LOC command, which I use to 
find a module in a DD concatenation of libraries.  Like this:

  ==> tss loc modulenm sysproc
  SYSPROC  XYZ.ISPF.GENERAL.CLIB
  SYSPROC  XYZ.ISPF.COMBINED.V65.CLIB
  SYSPROC  TTP.CAI.V44.CAICLIB
  Member MODULENM found in dataset TTP.CAI.V44.CAICLIB (#3in SYSPROC).

...and then starts that module in View.  (This is a big help when programming 
in ISPF, among other things.)  In this case LOC needs to know which is the 
module name and which the DD name, since they both look the same.

...But wait:  An idea strikes.  I already have a function DSDD that receives a 
string and returns a code telling whether the string represents a catalogued 
DS, an allocated DD, or both, or neither.  So even LOC doesn't need these two 
args to be positional; it can look over the args, determine which DD(s) to 
search, and any other args are module names.  Cool!  I have work to do :).

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* if we consider the unblushing promises of reward and the staggering 
nature of the rewards promised in the Gospels, it would seem that our Lord 
finds our desires not too strong, but too weak. We are half-hearted creatures, 
fooling about with drink and sex and ambition when infinite joy is offered us, 
like an ignorant child who wants to go on making mud pies in a slum because he 
cannot imagine what is meant by the offer of a holiday at the sea.  -from _The 
Weight of Glory_ by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Thursday, September 30, 2021 22:37

Even a dead horse needs a tail. Parsing CLIST parms involves more than sorting 
out characters and delimiters. There are (my terminology) three kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each variable 
is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the keyword 
is present, the variable is assigned the value that matches the variable name. 
'Match' here means an unambiguous (sub)string. If the match is ambiguous, CLIST 
prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded like 
this: keyword(value). Value can be anything. Keyword entered by the user must 
unambiguously match one coded in the CLIST, else CLIST prompts the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user had to 
supply lots of data at execution time. This framework offers flexibility.


--- On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:
> I once wrote an external routine that can break a character string
> into various individual parms and return them on the stack.  It
> correctly parses strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work
> perfectly well with a string of one-word arguments, and if I don't
> have to remember what order they come in and don’t have to label them,
> anything more is almost never required.
>
> -Original Message-
> From: Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> one of the most powerful features of CLIST is the mechanism by
> which parameters/options are passed by the user: positional or
> keyword, required or optional, with system prompting. I once saw a
> REXX routine that simulated the old command/CLIST parm processing. It
> was very complicated and hardly worth the trouble IMHO.

--
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 Oppolzer]

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

[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

COBOL issue

[Bernd Oppolzer]

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

Re: PL/I vs. JCL

[Bob Bridges]

I would never have seen this in advance, but one advantage I found when 
switching to REXX is that I'm almost eliminated positional parms from my 
commands.  In all but a few cases, the program can tell what it is by looking 
at it.  Thus every user can enter the arguments in the order that seems most 
logical to him, or (in my case) in the order that occurs to me at the time.  
It's a small convenience, but I cherish it.

The one exception that occurs to me just now is my LOC command, which I use to 
find a module in a DD concatenation of libraries.  Like this:

  ==> tss loc modulenm sysproc
  SYSPROC  XYZ.ISPF.GENERAL.CLIB 
  SYSPROC  XYZ.ISPF.COMBINED.V65.CLIB
  SYSPROC  TTP.CAI.V44.CAICLIB   
  Member MODULENM found in dataset TTP.CAI.V44.CAICLIB (#3in SYSPROC).

...and then starts that module in View.  (This is a big help when programming 
in ISPF, among other things.)  In this case LOC needs to know which is the 
module name and which the DD name, since they both look the same.

...But wait:  An idea strikes.  I already have a function DSDD that receives a 
string and returns a code telling whether the string represents a catalogued 
DS, an allocated DD, or both, or neither.  So even LOC doesn't need these two 
args to be positional; it can look over the args, determine which DD(s) to 
search, and any other args are module names.  Cool!  I have work to do :).

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* if we consider the unblushing promises of reward and the staggering 
nature of the rewards promised in the Gospels, it would seem that our Lord 
finds our desires not too strong, but too weak. We are half-hearted creatures, 
fooling about with drink and sex and ambition when infinite joy is offered us, 
like an ignorant child who wants to go on making mud pies in a slum because he 
cannot imagine what is meant by the offer of a holiday at the sea.  -from _The 
Weight of Glory_ by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Thursday, September 30, 2021 22:37

Even a dead horse needs a tail. Parsing CLIST parms involves more than sorting 
out characters and delimiters. There are (my terminology) three kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each variable 
is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the keyword 
is present, the variable is assigned the value that matches the variable name. 
'Match' here means an unambiguous (sub)string. If the match is ambiguous, CLIST 
prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded like 
this: keyword(value). Value can be anything. Keyword entered by the user must 
unambiguously match one coded in the CLIST, else CLIST prompts the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user had to 
supply lots of data at execution time. This framework offers flexibility.


--- On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:
> I once wrote an external routine that can break a character string 
> into various individual parms and return them on the stack.  It 
> correctly parses strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work 
> perfectly well with a string of one-word arguments, and if I don't 
> have to remember what order they come in and don’t have to label them, 
> anything more is almost never required.
>
> -Original Message-
> From: Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> one of the most powerful features of CLIST is the mechanism by 
> which parameters/options are passed by the user: positional or 
> keyword, required or optional, with system prompting. I once saw a 
> REXX routine that simulated the old command/CLIST parm processing. It 
> was very complicated and hardly worth the trouble IMHO.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Control-M

[kekronbekron]

On mainframe, BMC got it right with Control M/O/R/...
The interface is just spot on, ultra easy to quickly understand what's going on.

I don't know about the distributed app, but on mainframe, oh boy, I love CTM.
Have even seen a guy write REXX scripts to build out CTM schedule decks.
So for example, he can run a job to build a schedule that clones a DB2 
subsystem.
These days' tools can't hold a candle to that.

- KB

‐‐‐ Original Message ‐‐‐

On Friday, October 1st, 2021 at 3:40 PM, Radoslaw Skorupka 
 wrote:

> W dniu 22.09.2021 o 21:06, Ward, Mike S pisze:
>
> > Anyone on here ever used Control-M from BMC? Any comments on the 
> > Installation/Maintenance/Performance ...ET AL? Any additional products that 
> > had to be purchased because Control-M didn't have everything it needed to 
> > run successfully?
>
> I don't know current product packaging, but definitely take Control-M
>
> with Control-R. This is for job restart.
>
> Paid option, as some competition have also.
>
> Other Controls (-O, -T, -D) are not related to batch scheduling.
>
> My favourite list:
>
> 1.  Control-M
>
> (gap)
> 2.  CA-ESP
> 3.  IBM IWS vel TWS vel OPC
>
> (big gap)
>
> other products
>
> --
>
> Radoslaw Skorupka
>
> Lodz, Poland
>
> 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: z/OS 2.5 Announcement out yet?

[Richards, Robert B. (CTR)]

Thanks, Gil!

Very useful.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, September 30, 2021 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.5 Announcement out yet?

On Thu, 30 Sep 2021 12:06:46 -0500, David Elliot  wrote:

>Google it. There is a preview published and one or two other documents.
>I hope you are not hoping for any surprises.
> 
I now see Doc at:



-- gil

--
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: Control-M

[Radoslaw Skorupka]

W dniu 22.09.2021 o 21:06, Ward, Mike S pisze:

Anyone on here ever used Control-M from BMC? Any comments on the 
Installation/Maintenance/Performance ...ET AL? Any additional products that had 
to be purchased because Control-M didn't have everything it needed to run 
successfully?


I don't know current product packaging, but definitely take Control-M 
with Control-R. This is for job restart.

Paid option, as some competition have also.
Other Controls (-O, -T, -D) are not related to batch scheduling.

My favourite list:
1. Control-M
(gap)
2. CA-ESP
3. IBM IWS vel TWS vel OPC
(big gap)
other products

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN