Re: What time is it in Lebanon?

[ITschak Mugzach]

Lebanon Time is not a joke. `christians and muslims can't agree on
anything, including what time is now.

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Mon, Mar 27, 2023 at 9:49 AM Gadi Ben-Avi  wrote:

> We changed the time on Friday March 24th at 2 am.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: יום ב 27 מרץ 2023 09:44
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What time is it in Lebanon?
>
> On Mon, 27 Mar 2023 04:49:32 +, Gadi Ben-Avi  wrote:
>
> >When I install a new version of z/OS in Israel I set the time zone in
> SYS1.PARMLIB(CLOCKxx) and in /etc/profile. I set TZ to IST-2IDT.
> >
> On what date this year does that change the offset from IST to IDT?  By
> experiment on MacOS, I see March 12, which is the convention for USA, not
> ISRAEL.
>
> With TZ=IST-2IDT,M3.4.4/26,M10.5.0 I get March 26, which
> www.timeanddate.com says is correct for Israel.
>
> >Some USS based tasks have their own time zone setting which must be
> updated as well.
> >
> Why more than one?  Just one works fine on my desktop and phone.
> Is it to support geographically distributed systems, or can IBM just not
> get its act together?
>
> >The time comes from STP which is set to UTC.
> >
> IBM recommends in the PoOps TAI-10 seconds, which is now UTC-27.
>
> >STP get its time from enterprise NTP servers.
> >
> >Nothing comes preconfigured.
> >
> Ouch!  Does IBM not even suggest the correct strings for TZ for various
> locations?
>
> --
> 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
>

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

Re: What time is it in Lebanon?

[Paul Gilmartin]

On Mon, 27 Mar 2023 06:48:49 +, Gadi Ben-Avi  wrote:

>We changed the time on Friday March 24th at 2 am.
>
Do you mean you changed the TZ variable on March 24?

>-Original Message-
>On Mon, 27 Mar 2023 04:49:32 +, Gadi Ben-Avi  wrote:
>
>>When I install a new version of z/OS in Israel I set the time zone in 
>>SYS1.PARMLIB(CLOCKxx) and in /etc/profile. I set TZ to IST-2IDT.
>>
That variable causes the offset to change on March 12, American rules,
not Israeli, according to:

If this Daylight Saving Time rule is omitted altogether,
the values in the rule default to the standard rules for
American Daylight Saving Time. 

-- 
gil

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

Re: What time is it in Lebanon?

[Gadi Ben-Avi]

Actually, there was no need to change the TZ variable.
What we did is issue the command SET TIMEZONE=E.03.00 at 2 am on March 24th.
On Sunday (our next regular work day), I changed the CLOCKxx member to reflect 
the change, in case we decide to IPL at some time in the future.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: יום ב 27 מרץ 2023 11:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What time is it in Lebanon?

On Mon, 27 Mar 2023 06:48:49 +, Gadi Ben-Avi  wrote:

>We changed the time on Friday March 24th at 2 am.
>
Do you mean you changed the TZ variable on March 24?

>-Original Message-
>On Mon, 27 Mar 2023 04:49:32 +, Gadi Ben-Avi  wrote:
>
>>When I install a new version of z/OS in Israel I set the time zone in 
>>SYS1.PARMLIB(CLOCKxx) and in /etc/profile. I set TZ to IST-2IDT.
>>
That variable causes the offset to change on March 12, American rules, not 
Israeli, according to:

If this Daylight Saving Time rule is omitted altogether,
the values in the rule default to the standard rules for
American Daylight Saving Time. 

--
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: ASM call by value

[Binyamin Dissen]

On Sun, 26 Mar 2023 21:35:13 + Frank Swarbrick
 wrote:

:>Can the MVS CALL macro be used to call a C function with "value" parameters 
(rather than reference parameters)?

What does "call by value" look like?

Does the subroutine definition indicate that the parameters are by value? If
not, all call by value means is that should the subroutine alter the value,
the change is discarded.

For example, instead of

  CALL  rtn,(A,B)

do

   MVC   ACOPY,A
   MVC   BCOPY,B
   CALL rtn,(ACOPY,BCOPY)

Should RTN change the first parameter, it will not change A.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: ASM call by value

[Seymour J Metz]

No. Don't confuse semantics with implementation. Call by value means that the 
called routine can't change the parameter. Whether the compiler passes the 
address or not, it will not allow assignments to a call by value parameter.

Just be glad that you don't have to deal with call by name.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
> Can the MVS CALL macro be used to call a C function with "value" parameters 
> (rather than reference parameters)?
>
>
> --
> 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: ASM call by value

[Bernd Oppolzer]

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as 
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter 
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process 
remains reentrant.


Then the called prog can, if it wants, change the passed values, which 
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective 
of the caller.


This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and 
not for parameter lists which

dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
kind regards

Bernd



Am 27.03.2023 um 12:57 schrieb Seymour J Metz:

No. Don't confuse semantics with implementation. Call by value means that the 
called routine can't change the parameter. Whether the compiler passes the 
address or not, it will not allow assignments to a call by value parameter.

Just be glad that you don't have to deal with call by name.


From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Monday, March 27, 2023 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

 CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

 CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:

Can the MVS CALL macro be used to call a C function with "value" parameters 
(rather than reference parameters)?


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

setfacl question

[Mark Jacobs]

I’ve never been able to get the setfacl command to do what I’m trying to do. 
Any assistance would be appreciated. I’m trying to set the default ACL for any 
new files or directories created in /foo/bar to be world readable/writable, in 
short I’m looking for the permissions set to 666 for those newly created 
files/directories.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

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

Re: ASM call by value

[Bernd Oppolzer]

Take as an easy example a C function which gets two double parms and 
builts the sum:


double sum (double x, double y)
{
    return x + y;
}

there you have register 1 pointing at an address list (which should be 
called parameter list in this case);
the first double is at 0(r1), and the second double is at 8(r1). The 
VALUEs of the doubles are passed,

not the addresses.

You cannot call this function using the ASSEMBLER CALL macro. No chance.

Kind regards

Bernd


Am 27.03.2023 um 13:10 schrieb Bernd Oppolzer:

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as 
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter 
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process 
remains reentrant.


Then the called prog can, if it wants, change the passed values, which 
are in fact local variables,
as seen be the called prog. But nothing is changed from the 
perspective of the caller.


This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, 
and not for parameter lists which

dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
kind regards

Bernd



Am 27.03.2023 um 12:57 schrieb Seymour J Metz:
No. Don't confuse semantics with implementation. Call by value means 
that the called routine can't change the parameter. Whether the 
compiler passes the address or not, it will not allow assignments to 
a call by value parameter.


Just be glad that you don't have to deal with call by name.


From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

 CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

 CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
Can the MVS CALL macro be used to call a C function with "value" 
parameters (rather than reference parameters)?



--
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: setfacl question

[Rick Troth]

I started a longer reply, but got stuck in the weeds.

Can you describe what you're trying to do?

-- R; <><


On 3/27/23 07:10, Mark Jacobs wrote:

I’ve never been able to get the setfacl command to do what I’m trying to do. 
Any assistance would be appreciated. I’m trying to set the default ACL for any 
new files or directories created in /foo/bar to be world readable/writable, in 
short I’m looking for the permissions set to 666 for those newly created 
files/directories.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

--
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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Cameron Conacher]

Good morning Peter,
SNOBOL??
Geeze that takes me way back.

I had a smile and had to call some old colleagues.

Thank you!

…….Cameron
OOO – March 28, 29, 30 and 31.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Stop the ragging on COBOL please [was: RE: ASM call by 
value]

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: setfacl question

[Mark Jacobs]

I want a directory that anyone can write to/read from and for any files or 
directories created under it also to be world readable/writable by default.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Monday, March 27th, 2023 at 8:05 AM, Rick Troth  wrote:


> I started a longer reply, but got stuck in the weeds.
> 
> Can you describe what you're trying to do?
> 
> -- R; <><
> 
> 
> 
> On 3/27/23 07:10, Mark Jacobs wrote:
> 
> > I’ve never been able to get the setfacl command to do what I’m trying to 
> > do. Any assistance would be appreciated. I’m trying to set the default ACL 
> > for any new files or directories created in /foo/bar to be world 
> > readable/writable, in short I’m looking for the permissions set to 666 for 
> > those newly created files/directories.
> > 
> > Mark Jacobs
> > 
> > Sent from ProtonMail, Swiss-based encrypted email.
> > 
> > GPG Public Key - 
> > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > 
> > --
> > 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Seymour J Metz]

Has anybody used a version older than SNOBOL 4?



From: IBM Mainframe Discussion List  on behalf of 
Cameron Conacher <03cfc59146bb-dmarc-requ...@listserv.ua.edu>
Sent: Monday, March 27, 2023 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

Good morning Peter,
SNOBOL??
Geeze that takes me way back.

I had a smile and had to call some old colleagues.

Thank you!

…….Cameron
OOO – March 28, 29, 30 and 31.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Stop the ragging on COBOL please [was: RE: ASM call by 
value]

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, http://www.americanexpress.ca/. If 
you no longer wish to receive these e-mails, please notify the sender by reply 
e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, 
http://www.americanexpress.ca/. Si, par la suite, vous ne souhaitez plus 
recevoir ces courriels, veuillez en aviser les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

--
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: ASM call by value

[Seymour J Metz]

There's more than one implementation; they all  enforce the 
semantics. Again, what call by value is all about is that the caller's variable 
in not altered, regardless of how the compiler enforces that. The whole shtick 
with R1 and DSA is not part of the semantics.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
kind regards

Bernd



Am 27.03.2023 um 12:57 schrieb Seymour J Metz:
> No. Don't confuse semantics with implementation. Call by value means that the 
> called routine can't change the parameter. Whether the compiler passes the 
> address or not, it will not allow assignments to a call by value parameter.
>
> Just be glad that you don't have to deal with call by name.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Bernd Oppolzer 
> Sent: Monday, March 27, 2023 2:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASM call by value
>
> Sorry that I post to the original question;
> that's because most of the answers so far missed the point.
>
> Call by value means that a value is passed to the caller;
> call by reference means that a reference (technically: an address) is
> passed to the caller.
>
> In ASSEMBLER:
>
>  CALL SUBPROG,(A,B,C),VL
>
> sends address constants of fields A, B and C to the caller (via reg1
> address list),
> so that is always call by reference.
>
> You can instead send an integer constant to the caller using CALL or a
> register:
>
>  CALL SUBPROG,(1024,(R3))
>
> with the integer constant, this sure is call by value, but you are
> limited to integer arguments.
> With the register argument, it depends on what is contained in the
> register;
> if it is an address, you have call by reference again.
>
> The only real "call by value" I can see here is the case where an
> integer constant is part
> of the reg1 parameter list (the 1024 constant above); and this is what C
> technically does
> in the "call by value" case. If C passes larger values "call by value",
> it copies them in the
> reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
> would be
> the correct answer to the original question.
>
> HTH,
> kind regards
>
> Bernd
>
>
> Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
>> Can the MVS CALL macro be used to call a C function with "value" parameters 
>> (rather than reference parameters)?
>>
>>
>> --
>> 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[esst...@juno.com]

+2
-- Original Message --
From: Tom Brennan 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]
Date: Sun, 26 Mar 2023 23:22:03 -0700

+1

On 3/26/2023 10:55 PM, Farley, Peter wrote:
> I am getting increasingly tired of snide or outright dismissive references to 
> COBOL and by extension to COBOL programmers.
> 
> Programmers like me.
> 
> Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
> SORT (at least as far as knowing and using JOIN's), SQL, JCL and various 
> other z/OS utilities, MetalC, and lately python and bash scripting.  I even 
> remember some of the PL/I and Fortran and Pascal I used in college and my 
> early employment days.  I even remember some SNOBOL, which I actually got to 
> use productively at a then-major NY bank very early in my career.
> 
> COBOL pays my bills and keeps my employer operating successfully and 
> profitably.
> 
> COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
> substances can, in fact, do that.  Intelligently devising business solutions 
> to business problems in ANY computer language does NOT rot the brain.
> 
> It is not funny or acceptable to say so.  It never was.
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Paul Gilmartin
> Sent: Sunday, March 26, 2023 8:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASM call by value
> 
> On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:
> 
> 
> 
>> In COBOL, for example, the following end up doing the same thing.
>>
> Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
> brain.
> 
> --
> 
> 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Steve Thompson]

+1 for me as well

In fact, I have written code to read catalog records, in COBOL, 
because I needed to solve a problem back in z/OS 1.4 days and I 
didn't have time to write the code in ALC/HLASM, and management 
would not purchase tools since they were migrating off mainframes


Steve Thompson

On 3/27/2023 2:22 AM, Tom Brennan wrote:

+1

On 3/26/2023 10:55 PM, Farley, Peter wrote:
I am getting increasingly tired of snide or outright 
dismissive references to COBOL and by extension to COBOL 
programmers.


Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, 
somewhat facile in SORT (at least as far as knowing and using 
JOIN's), SQL, JCL and various other z/OS utilities, MetalC, 
and lately python and bash scripting.  I even remember some of 
the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I 
actually got to use productively at a then-major NY bank very 
early in my career.


COBOL pays my bills and keeps my employer operating 
successfully and profitably.


COBOL does NOT rot the brain.  Alcohol and various other legal 
and illegal substances can, in fact, do that.  Intelligently 
devising business solutions to business problems in ANY 
computer language does NOT rot the brain.


It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  
On Behalf Of Paul Gilmartin

Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



In COBOL, for example, the following end up doing the same 
thing.


Do not use CO BOL as an exemplar of programming discipline. 
Cobol rots the brain.


--

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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bob Bridges]

Peter!  I don't think I've heard from you recently; maybe I just wasn't paying 
attention until I read this one.

I myself dislike COBOL for the very simple and personal reason that it's so 
WORDY.  But even when I had to use it a lot (I was a COBOL developer for about 
15 years), I was aware that it's a powerful language with good organizational 
features for what we used to call top-down programming, and I enjoy sneering (a 
nasty, superior smirk) at claims that it's a dinosaur and will soon die an 
unmourned death as other languages supplant it.  Not gonna happen, not in my 
lifetime anyway.  Maybe in the Millennium, though I'm doubtful.

Not true, though, that it's "not acceptable" to rag on COBOL.  Obviously it is. 
 Don't waste your time and energy taking offense; we haven't enough of either 
to throw about to no benefit.

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

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 01:56

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

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

SMPe securing zones

[Bill Giannelli]

I want to create another TARGET and DLIB zone for another level of maintenance.
I am currently, showing "newbie" offshore folks our SMPe environment.
Is there a way to "secure" the newly created TARGET and DLIB zones so they are 
not inadvertently updated?
thanks
Bill

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

Re: SMPe securing zones

[Seymour J Metz]

Why not give them read-only access?


From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Monday, March 27, 2023 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe securing zones

I want to create another TARGET and DLIB zone for another level of maintenance.
I am currently, showing "newbie" offshore folks our SMPe environment.
Is there a way to "secure" the newly created TARGET and DLIB zones so they are 
not inadvertently updated?
thanks
Bill

--
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: SMPe securing zones

[Mark Jacobs]

If you have those zones in their own CSI datasets, you can use your security 
system just to allow READ access.

Mark Jacobs 


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Monday, March 27th, 2023 at 9:46 AM, Bill Giannelli 
 wrote:


> I want to create another TARGET and DLIB zone for another level of 
> maintenance.
> I am currently, showing "newbie" offshore folks our SMPe environment.
> Is there a way to "secure" the newly created TARGET and DLIB zones so they 
> are not inadvertently updated?
> thanks
> Bill
> 
> --
> 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: ASM call by value

[Bernd Oppolzer]

What is important to me at least: a parameter passing mechanism where 
addresses are passed
and the value on the caller's side cannot be altered (because it has 
been copied before, like in the

DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a 
parameter passing mechanism.
That is: it is not only important that the caller's variable is not 
altered;
it is also important that VALUEs are passed, not addressed. Otherwise 
you have some sort of

"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the 
implementation,

only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:

There's more than one implementation; they all  enforce the 
semantics. Again, what call by value is all about is that the caller's variable in 
not altered, regardless of how the compiler enforces that. The whole shtick with R1 
and DSA is not part of the semantics.


From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Monday, March 27, 2023 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Seymour J Metz]

I believe that the problems are:

 1. Some people conflate the language and
those who use it.

 2. Some people believe that those who
use the language are interchangeable.

 3. Some people think of COBOL as not
having changed since CODASYL.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Monday, March 27, 2023 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

Peter!  I don't think I've heard from you recently; maybe I just wasn't paying 
attention until I read this one.

I myself dislike COBOL for the very simple and personal reason that it's so 
WORDY.  But even when I had to use it a lot (I was a COBOL developer for about 
15 years), I was aware that it's a powerful language with good organizational 
features for what we used to call top-down programming, and I enjoy sneering (a 
nasty, superior smirk) at claims that it's a dinosaur and will soon die an 
unmourned death as other languages supplant it.  Not gonna happen, not in my 
lifetime anyway.  Maybe in the Millennium, though I'm doubtful.

Not true, though, that it's "not acceptable" to rag on COBOL.  Obviously it is. 
 Don't waste your time and energy taking offense; we haven't enough of either 
to throw about to no benefit.

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

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 01:56

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

--
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: ASM call by value

[Seymour J Metz]

Why is it important to you that an address not be passed and why do you believe 
that a PL/I dummy variable means that the argument was not passed by value? 
Languages specify black box behavior, not how you enforce that behavior.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:
> There's more than one implementation; they all  enforce the 
> semantics. Again, what call by value is all about is that the caller's 
> variable in not altered, regardless of how the compiler enforces that. The 
> whole shtick with R1 and DSA is not part of the semantics.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Bernd Oppolzer 
> Sent: Monday, March 27, 2023 7:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASM call by value
>
> Implementation enforces semantics in this case ...
>
> The C implementation (on z/OS at least, but IMO on other platforms as
> well) builts a reg1 parameter list
> and puts the "value parms" there. With C on z/OS, the reg1 parameter
> list resides on the "stack", which
> is addressed by reg 13 in the caller's DSA, so that the whole process
> remains reentrant.
>
> Then the called prog can, if it wants, change the passed values, which
> are in fact local variables,
> as seen be the called prog. But nothing is changed from the perspective
> of the caller.
>
> This is what call by value is about.
>
> The ASSEMBLER call macro supports this, but only for integer parms, and
> not for parameter lists which
> dont reside in the caller's CSECT. So we have two issues here:
>
> - no "larger" data types supported
> - no support for the reentrant case
>
> HTH,
> 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bill Johnson]

+1
About a year or so ago I posted about the number of lines of COBOL code in use 
worldwide and stated COBOL was going to be the language of choice for many 
decades to come. Estimates say 800 billion lines (and growing) in use today. As 
usual, I was attacked for my fact based opinion. 
https://www.zdnet.com/article/programming-languages-how-much-cobol-code-is-out-there-the-answer-might-surprise-you/




Sent from Yahoo Mail for iPhone


On Monday, March 27, 2023, 1:56 AM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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: ASM call by value

[Bernd Oppolzer]

   DCL X BIN FIXED (31);
   CALL SUB ((X));

SUB: PROC (P);
   DCL P BIN FIXED (31);

   END SUB;

The statement CALL SUB ((X));
creates a dummy argument for X (that is, a copy of variable X).
The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
This is NOT call by value.

The subroutine cannot change X, because it gets the address of the copy 
of X

and not the address of X. That is:

call by reference of a dummy argument
and not
call by value

The types of X and P may be different; if so, the dummy argument gets 
the type of P.
In this case, no parantheses are required (but a warning message is 
issued, if there are
no parentheses). But the mechanism is the same, regardless if the types 
match (with parantheses)
or if the types don't match (without parantheses). Only in the case when 
the types match and
there are no parantheses, you have a real call by reference where the 
subroutine can change

the value of the caller.

This is PL/1 ... other languages don't behave this way. With other 
languages, you will get a

problem at runtime, if the types don't match.

Kind regards

Bernd



Am 27.03.2023 um 16:03 schrieb Seymour J Metz:

Why is it important to you that an address not be passed and why do you believe 
that a PL/I dummy variable means that the argument was not passed by value? 
Languages specify black box behavior, not how you enforce that behavior.


From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Monday, March 27, 2023 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:

There's more than one implementation; they all  enforce the 
semantics. Again, what call by value is all about is that the caller's variable in 
not altered, regardless of how the compiler enforces that. The whole shtick with R1 
and DSA is not part of the semantics.


From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Monday, March 27, 2023 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
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: ASM call by value

[Bernd Oppolzer]

Counter example:

DCL X BIN FIXED (31);
   CALL SUB (X);

SUB: PROC (P);
   DCL P BIN FIXED (31) BYVALUE;

   END SUB;

This is NOT the same as the example below;
a C caller (and: an ASSEMBLER caller) must do VERY DIFFERENT things to 
call the SUB here

and the SUB in the previous example.

From the perspective of the PL/1 main program, the SEMANTICS are the 
same (X is not changed),
but in this case enforced by the BYVALUE clause of the SUB subroutine 
and known for sure by all callers;
in the earlier post by the parantheses around (X) ... SUB in the earlier 
post could change its parameter P ...

who knows? The definition doesn't tell it.

HTH, kind regards

Bernd


Am 27.03.2023 um 16:13 schrieb Bernd Oppolzer:

   DCL X BIN FIXED (31);
   CALL SUB ((X));

SUB: PROC (P);
   DCL P BIN FIXED (31);

   END SUB;

The statement CALL SUB ((X));
creates a dummy argument for X (that is, a copy of variable X).
The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
This is NOT call by value.

The subroutine cannot change X, because it gets the address of the 
copy of X

and not the address of X. That is:

call by reference of a dummy argument
and not
call by value

The types of X and P may be different; if so, the dummy argument gets 
the type of P.
In this case, no parantheses are required (but a warning message is 
issued, if there are
no parentheses). But the mechanism is the same, regardless if the 
types match (with parantheses)
or if the types don't match (without parantheses). Only in the case 
when the types match and
there are no parantheses, you have a real call by reference where the 
subroutine can change

the value of the caller.

This is PL/1 ... other languages don't behave this way. With other 
languages, you will get a

problem at runtime, if the types don't match.

Kind regards

Bernd



Am 27.03.2023 um 16:03 schrieb Seymour J Metz:
Why is it important to you that an address not be passed and why do 
you believe that a PL/I dummy variable means that the argument was 
not passed by value? Languages specify black box behavior, not how 
you enforce that behavior.



From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:
There's more than one implementation; they all  
enforce the semantics. Again, what call by value is all about is 
that the caller's variable in not altered, regardless of how the 
compiler enforces that. The whole shtick with R1 and DSA is not part 
of the semantics.



From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
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 instructi

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Farley, Peter]

Apologies - I should have said SNOBOL4, which is what I used at that time, not 
any earlier SNOBOL version.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, March 27, 2023 8:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

Has anybody used a version older than SNOBOL 4?



From: IBM Mainframe Discussion List  on behalf of 
Cameron Conacher <03cfc59146bb-dmarc-requ...@listserv.ua.edu>
Sent: Monday, March 27, 2023 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

Good morning Peter,
SNOBOL??
Geeze that takes me way back.

I had a smile and had to call some old colleagues.

Thank you!

...Cameron
OOO - March 28, 29, 30 and 31.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Stop the ragging on COBOL please [was: RE: ASM call by 
value]

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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: A question or two on zOS issues

[Schmitt, Michael]

The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
to VS COBOL II in 1992. Since then we've migrated our 7 million lines of COBOL 
code...

- 1998 Language Environment
- 2000 COBOL for MVS & VM
- 2003 COBOL for OS/390 & VM
- 2004 COBOL for z/OS & OS/390 3.2
- 2005  3.3
- 2006  3.4
- 2011  4.2
- 2020  6.2

By doing... nothing.

The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
requirement for load modules.


So, in my experience, we don't need to know when our COBOL programs were last 
used. And we already have tools that give us the compile date and version, both 
from IBM and home grown.

We still have a large number of programs that haven't been recompiled since the 
VS COBOL II migration. They coexist just fine.

(You may have to *relink* to pick up the Language Environment bootstrap 
programs)


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Pryor
Sent: Friday, March 24, 2023 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A question or two on zOS issues

There are a couple of pressing issues in z/OS that I'm sure many folks are 
aware of but about which there doesn't seem to be much being done. I'm curious 
as to what other IBM-MAINer's thoughts might be. Specifically, I'm talking 
about:

1.) migration to IBM's latest COBOL release, and

2.) the not-really-that-far-off issue of Year 2042

I've been asked several times recently whether we (a z/OS ISV) should consider 
developing products to address these issues. Frankly, though, I live in an 
ivory tower and while I sometime *think* I know what installations problems and 
needs are, I'm usually surprised to find that reality is quite different. So 
I'd like to throw a couple of questions out to the list for comment:

1.) Would a reporting utility that determined which COBOL programs were 
executed (and which ones weren't), and what release and options they were 
compiled with be significantly helpful in a COBOL migration? What other 
features would be nice to have? Or is this a low priority for most 
installations, who are perhaps trying to justify keeping the mainframe alive 
and/or conducting business as usual, let alone doing a COBOL migration project?

2.) It's rather shocking that 2042 is so close and not much seems to be 
happening. We are one of the vendors that have a date-simulation utility, but 
we don’t know if data centers have any near-term plans for 2042. Would it be 
worthwhile to have a 2042 date-simulation product now, or is everyone going to 
cross their fingers and try to use a test LPAR once the operating system fully 
supports 2042 dates?

Thanks for any comments and insight the IBM-MAIN hive mind might have.

Steve Pryor
CTO
DTS Software, LLC

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

DFSORT to count and sum subsets of data

[Billy Ashton]

Hey everyone - happy Monday!

I am trying to come up with a single SORT step to give me counts and a 
sum of a field on subsets of data, and using control breaks. Here is a 
sample of my input with lines shortened for the email:


A01DDATE  001D<< Cols 23 to 101 MISCELLANEOUS DATA >>   10   
 2
A01DDATE  001W<< Cols 23 to 101 MISCELLANEOUS DATA >>   93   
 2
A01MEXTRA 047D<< Cols 23 to 101 MISCELLANEOUS DATA >>3   
 2
A01MEXTRA 022P<< Cols 23 to 101 MISCELLANEOUS DATA >>5   
 2
A01MEXTRA 019R<< Cols 23 to 101 MISCELLANEOUS DATA >>   35   
 2
A02QTRAN  103D<< Cols 23 to 101 MISCELLANEOUS DATA >>  802   
 2
A02QTRAN  014R<< Cols 23 to 101 MISCELLANEOUS DATA >>9   
 2
A02QTRAN  012T<< Cols 23 to 101 MISCELLANEOUS DATA >>   41   
 2
A02QTRAN  083V<< Cols 23 to 101 MISCELLANEOUS DATA >>   12   
 2
A02ZHORIZ 023D<< Cols 23 to 101 MISCELLANEOUS DATA >>  456   
 2
A02ZHORIZ 011P<< Cols 23 to 101 MISCELLANEOUS DATA >>   81   
 2
A02ZVERTICAL  011D<< Cols 23 to 101 MISCELLANEOUS DATA >>  773   
 2
A02ZVERTICAL  003M<< Cols 23 to 101 MISCELLANEOUS DATA >>1   
 2


This is the layout:
  1 - len  3, Dept
 19 - len  3, numeric
 22 - len  1, Indicator
 23 - len 77, miscellaneous
102 - len  9, Counter
111 - len 19, miscellaneous

What I want to do is produce a single line for each Department (cols 
1-3), that tells me the number of articles (Count of all rows with a 
numeric value in cols 19-21, and an Indicator in col 22 of "D"), and a 
sum of the Counter (cols 102-110, pic 9), with a grand total. It 
will look like this:


Department A01:   2 articles, total items:  13  (# = 
suppressed zeros)

Department A02: ##3 articles, total items: ###2031
*** TOTAL *** : ##5 articles, total items: ###2044

I can get the count to work through a simple sum, but I can't get the 
number of articles to break on the Department code (there could be 
1-to-n departments in each file).


Can someone help me with what should be fairly simple here?

Thank you and best regards,
Billy Ashton

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

Re: ASM call by value am

[Seymour J Metz]

You are repeating your claim instead of explaining it. I understood, and 
disagreed with, what you claimed the first few times. What I am asking for is 
the basis of your claim that when the compiler puts the address of a dummy 
variable in the plist it is not a call by value.

In fact, your definition would make call-by-value array parameters impossible 
on machines like the B5000 and B6500.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

DCL X BIN FIXED (31);
CALL SUB ((X));

SUB: PROC (P);
DCL P BIN FIXED (31);

END SUB;

The statement CALL SUB ((X));
creates a dummy argument for X (that is, a copy of variable X).
The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
This is NOT call by value.

The subroutine cannot change X, because it gets the address of the copy
of X
and not the address of X. That is:

call by reference of a dummy argument
and not
call by value

The types of X and P may be different; if so, the dummy argument gets
the type of P.
In this case, no parantheses are required (but a warning message is
issued, if there are
no parentheses). But the mechanism is the same, regardless if the types
match (with parantheses)
or if the types don't match (without parantheses). Only in the case when
the types match and
there are no parantheses, you have a real call by reference where the
subroutine can change
the value of the caller.

This is PL/1 ... other languages don't behave this way. With other
languages, you will get a
problem at runtime, if the types don't match.

Kind regards

Bernd



Am 27.03.2023 um 16:03 schrieb Seymour J Metz:
> Why is it important to you that an address not be passed and why do you 
> believe that a PL/I dummy variable means that the argument was not passed by 
> value? Languages specify black box behavior, not how you enforce that 
> behavior.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Bernd Oppolzer 
> Sent: Monday, March 27, 2023 9:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASM call by value
>
> What is important to me at least: a parameter passing mechanism where
> addresses are passed
> and the value on the caller's side cannot be altered (because it has
> been copied before, like in the
> DUMMY argument mechanism of PL/1, for example) it NOT call by value.
>
> You cannot call a true BYVALUE module or function by using such a
> parameter passing mechanism.
> That is: it is not only important that the caller's variable is not
> altered;
> it is also important that VALUEs are passed, not addressed. Otherwise
> you have some sort of
> "restricted" call by reference, which is not the same as call by value.
>
> You are right, of course, that Reg 1 and DSA etc. are details of the
> implementation,
> only mentioned here to clarify the idea.
>
> Kind regards
>
> Bernd
>
>
> Am 27.03.2023 um 14:25 schrieb Seymour J Metz:
>> There's more than one implementation; they all  enforce the 
>> semantics. Again, what call by value is all about is that the caller's 
>> variable in not altered, regardless of how the compiler enforces that. The 
>> whole shtick with R1 and DSA is not part of the semantics.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Bernd Oppolzer 
>> Sent: Monday, March 27, 2023 7:10 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: ASM call by value
>>
>> Implementation enforces semantics in this case ...
>>
>> The C implementation (on z/OS at least, but IMO on other platforms as
>> well) builts a reg1 parameter list
>> and puts the "value parms" there. With C on z/OS, the reg1 parameter
>> list resides on the "stack", which
>> is addressed by reg 13 in the caller's DSA, so that the whole process
>> remains reentrant.
>>
>> Then the called prog can, if it wants, change the passed values, which
>> are in fact local variables,
>> as seen be the called prog. But nothing is changed from the perspective
>> of the caller.
>>
>> This is what call by value is about.
>>
>> The ASSEMBLER call macro supports this, but only for integer parms, and
>> not for parameter lists which
>> dont reside in the caller's CSECT. So we have two issues here:
>>
>> - no "larger" data types supported
>> - no support for the reentrant case
>>
>> HTH,
>> 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 I

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bob Bridges]

Yeah, #3 is the one I keep coming back to.  "COBOL?  I took a COBOL class in
1975; how can it compete with a modern language like ?"

The same thing with mainframes; they're from the 1950s, and should long
since have gone to a well-deserved grave.  They were great in their day,
but...  We had this conversation after that news item about a New-England
state government's difficulty with some web-based function that had
mainframes in the background; I don't remember the details, but there were
problems getting the application's attention on the web, and the article
concluded it must be because it used aging mainframes running COBOL.

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

/* When I have a little money, I buy books; and if I have any left, I buy
food and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Monday, March 27, 2023 09:56

I believe that the problems are:

 1. Some people conflate the language and
those who use it.

 2. Some people believe that those who
use the language are interchangeable.

 3. Some people think of COBOL as not
having changed since CODASYL.


From: IBM Mainframe Discussion List  on behalf of
Bob Bridges
Sent: Monday, March 27, 2023 9:44 AM

I myself dislike COBOL for the very simple and personal reason that it's so
WORDY.  But even when I had to use it a lot (I was a COBOL developer for
about 15 years), I was aware that it's a powerful language with good
organizational features for what we used to call top-down programming, and I
enjoy sneering (a nasty, superior smirk) at claims that it's a dinosaur and
will soon die an unmourned death as other languages supplant it.  Not gonna
happen, not in my lifetime anyway.  Maybe in the Millennium, though I'm
doubtful.

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

Re: ASM call by value

[Joel C. Ewing]

All you really need to do a "call by value" in ASM is a special Call 
macro (say maybe VCALL)  that allocates "hidden" space for a copy of the 
variable value, copies the original variable, and somehow passes that to 
the called program, and a programming rule that says you only invoke 
that particular subroutine using the intended interface.  You can even 
add a special Subroutine entry macro and employ some "tricks" so that 
attempts to reference the subroutine name by an ordinary Call macro or 
direct reference will fail.


If your only allowed interfaces to the subroutine allows it so see the 
value of a variable passed by the caller but not change the 
corresponding variable known to the caller, then that IS call by value, 
no matter what the underlying implementation in low-level code.


Native machine instructions and standard subroutine linkages may only 
support call by reference, but the advantage of a macro assembler is 
that you can extend the language through macros and create an enhanced 
language that can do so much more. Some notable examples of this are 
various implementations using macros that allow use of 
structured-programming control constructs and recursive procedures with 
dynamic variable storage in Assembly programs.


    Joel C Ewing

On 3/27/23 09:13, Bernd Oppolzer wrote:

   DCL X BIN FIXED (31);
   CALL SUB ((X));

SUB: PROC (P);
   DCL P BIN FIXED (31);

   END SUB;

The statement CALL SUB ((X));
creates a dummy argument for X (that is, a copy of variable X).
The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
This is NOT call by value.

The subroutine cannot change X, because it gets the address of the 
copy of X

and not the address of X. That is:

call by reference of a dummy argument
and not
call by value

The types of X and P may be different; if so, the dummy argument gets 
the type of P.
In this case, no parantheses are required (but a warning message is 
issued, if there are
no parentheses). But the mechanism is the same, regardless if the 
types match (with parantheses)
or if the types don't match (without parantheses). Only in the case 
when the types match and
there are no parantheses, you have a real call by reference where the 
subroutine can change

the value of the caller.

This is PL/1 ... other languages don't behave this way. With other 
languages, you will get a

problem at runtime, if the types don't match.

Kind regards

Bernd



Am 27.03.2023 um 16:03 schrieb Seymour J Metz:
Why is it important to you that an address not be passed and why do 
you believe that a PL/I dummy variable means that the argument was 
not passed by value? Languages specify black box behavior, not how 
you enforce that behavior.



From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:
There's more than one implementation; they all  
enforce the semantics. Again, what call by value is all about is 
that the caller's variable in not altered, regardless of how the 
compiler enforces that. The whole shtick with R1 and DSA is not part 
of the semantics.



From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no suppor

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bob Bridges]

I've been resisting the temptation, because it's a repeat, but it's still a 
good one:

/* Joke begins */
Jack was a COBOL programmer in the late 1990s who (after years of being treated 
as a technological dinosaur by all the UNIX programmers, Client/Server 
programmers, website developers etc) was finally getting some respect:  He'd 
become a private consultant specializing in Year-2000 conversions.  He was 
working short-term assignments for prestigious companies, traveling all over 
the world on different assignments.  He was working 70- and 80- and even 
90-hour weeks, but it was worth it.

However, several years of this relentless, mind-numbing work had taken its toll 
on Jack.  He had problems sleeping and began having anxiety dreams about the 
year 2000.  It had reached a point where even the thought of the year 2000 made 
him nearly violent.  He must have suffered some sort of breakdown, because all 
he could think about was how he could avoid the year 2000 and all that came 
with it.

Near the end of 1998 Jack had decided to contact a company that specialized in 
cryogenics.  He made a deal to have himself frozen until 2001 through their 
totally automated (and very expensive) process.  He was thrilled.  The next 
thing he would know, he'd wake up in the year 2001 -- after the New Year 
celebrations and computer debacles, and after the dust had settled. Nothing 
else to worry about except getting on with his life.

He was put into his cryogenic receptacle, the technicians set the revive date, 
he was given injections to slow his heartbeat to a bare minimum, and that was 
that.

The next thing Jack saw was an enormous room filled with excited people.  They 
were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". 
 There were odd-looking cameras and equipment that looked like it came out of a 
science-fiction movie.

Someone who was obviously a spokesperson for the group stepped forward.  Jack 
couldn't contain his enthusiasm.  "It's over?" he asked.  "Is 2001 already 
here?  Are all the millennial parties and promotions and crises all over and 
done with?"

The spokesman explained that there had been a problem with the programming of 
the timer on Jack's cryogenic receptacle.  It hadn't been year-2000 compliant; 
it was actually 8000 years later, not the year 2001.  But the spokesman told 
Jack that he shouldn't get excited; someone important wanted to speak to him.

Suddenly a wall-sized projection screen displayed the image of a man that had a 
striking resemblance to Bill Gates.  This man was Prime Minister of Earth.  He 
told Jack not to be upset - that this was a wonderful time to be alive.  There 
was world peace and no more starvation.  The space program had been reïnstated 
and there were colonies on the moon and on Mars.  That technology had advanced 
to such a degree that everyone had virtual-reality interfaces that allowed them 
to contact anyone else on the planet, or to watch any entertainment, or to hear 
any music recorded anywhere.

"That sounds terrific," said Jack. "But I'm curious:  Why is everybody so 
interested in me?"

"Well," said the Prime Minister.  "The year 10 000 is just around the corner, 
and it says in your files you know COBOL..."
/* Joke ends */

I've always had a problem with one detail.  After 8000 years Jack is talking to 
the PM of Earth?  PM of the galaxy, I'd have thought.  Colonies on the moon and 
Mars?  After that amount of time I'd hope we're a lot farther than that!  
Still, it's a detail.

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

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Monday, March 27, 2023 10:08

About a year or so ago I posted about the number of lines of COBOL code in use 
worldwide and stated COBOL was going to be the language of choice for many 
decades to come. Estimates say 800 billion lines (and growing) in use today. As 
usual, I was attacked for my fact based opinion. 
https://www.zdnet.com/article/programming-languages-how-much-cobol-code-is-out-there-the-answer-might-surprise-you/

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

Re: DFSORT to count and sum subsets of data

[Martin Packer]

Hint: A count might be achieved by summing the constant X’0001’ inserted 
into qualifying rows. (That is if you don’t want to do it in eg OUTFIL.)

Cheers, Martin

From: IBM Mainframe Discussion List  on behalf of 
Billy Ashton 
Date: Monday, 27 March 2023 at 16:03
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] DFSORT to count and sum subsets of data
Hey everyone - happy Monday!

I am trying to come up with a single SORT step to give me counts and a
sum of a field on subsets of data, and using control breaks. Here is a
sample of my input with lines shortened for the email:

A01DDATE  001D<< Cols 23 to 101 MISCELLANEOUS DATA >>   10
  2
A01DDATE  001W<< Cols 23 to 101 MISCELLANEOUS DATA >>   93
  2
A01MEXTRA 047D<< Cols 23 to 101 MISCELLANEOUS DATA >>3
  2
A01MEXTRA 022P<< Cols 23 to 101 MISCELLANEOUS DATA >>5
  2
A01MEXTRA 019R<< Cols 23 to 101 MISCELLANEOUS DATA >>   35
  2
A02QTRAN  103D<< Cols 23 to 101 MISCELLANEOUS DATA >>  802
  2
A02QTRAN  014R<< Cols 23 to 101 MISCELLANEOUS DATA >>9
  2
A02QTRAN  012T<< Cols 23 to 101 MISCELLANEOUS DATA >>   41
  2
A02QTRAN  083V<< Cols 23 to 101 MISCELLANEOUS DATA >>   12
  2
A02ZHORIZ 023D<< Cols 23 to 101 MISCELLANEOUS DATA >>  456
  2
A02ZHORIZ 011P<< Cols 23 to 101 MISCELLANEOUS DATA >>   81
  2
A02ZVERTICAL  011D<< Cols 23 to 101 MISCELLANEOUS DATA >>  773
  2
A02ZVERTICAL  003M<< Cols 23 to 101 MISCELLANEOUS DATA >>1
  2

This is the layout:
   1 - len  3, Dept
  19 - len  3, numeric
  22 - len  1, Indicator
  23 - len 77, miscellaneous
102 - len  9, Counter
111 - len 19, miscellaneous

What I want to do is produce a single line for each Department (cols
1-3), that tells me the number of articles (Count of all rows with a
numeric value in cols 19-21, and an Indicator in col 22 of "D"), and a
sum of the Counter (cols 102-110, pic 9), with a grand total. It
will look like this:

Department A01:   2 articles, total items:  13  (# =
suppressed zeros)
Department A02: ##3 articles, total items: ###2031
*** TOTAL *** : ##5 articles, total items: ###2044

I can get the count to work through a simple sum, but I can't get the
number of articles to break on the Department code (there could be
1-to-n departments in each file).

Can someone help me with what should be fairly simple here?

Thank you and best regards,
Billy Ashton

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

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

Re: A question or two on zOS issues

[Mike Schwab]

There are faster instruction that the older compilers didn't have
available, such as relative addressing instead of base register /
offset.
https://www.ibm.com/products/automatic-binary-optimizer-zos can copy
the load module and replace binary instructions with newer
instructions for testing and implementation without recompiling.  SMF
and program analysis to pick the most cost savings programs to
convert.

On Mon, Mar 27, 2023 at 9:31 AM Schmitt, Michael
 wrote:
>
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don’t know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Farley, Peter]

Bob,

Respectfully, I disagree.  It isn't a waste of time or energy to be offended by 
patent insults, however slyly delivered or with whatever level of snigger 
behind the words.

I did not used to support any of the campaigns against "micro-aggressions" so 
popular in recent years on university and college campuses across the country, 
but I have come to see that they are not entirely wrong-headed or petty or 
overblown.  Taken too far at times, yes, I see that too.  But they are not 
wrong at the base.

This particular one just "got to me".  The proverbial straw on that poor 
camel's back.

I'm old and cranky and ornery, so I say things when they happen to hit me 
because time is not on my side.  I do try very hard not to impugn anyone else's 
character or capabilities, because that's just wrong.  There is solid advice in 
the old adage to say nothing if you cannot say something good.

I am also reminded of some pithy advice from Robert Heinlein's character 
Lazarus Long about the absolute necessity of maintaining consistent politeness 
in order to sustain a functioning and loving family, and in the broader sense 
to maintain a functioning and civil society.

Peter

P.S. -- I love your Erasmus tagline and agree wholeheartedly.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

EXTERNAL EMAIL

Peter!  I don't think I've heard from you recently; maybe I just wasn't paying 
attention until I read this one.

I myself dislike COBOL for the very simple and personal reason that it's so 
WORDY.  But even when I had to use it a lot (I was a COBOL developer for about 
15 years), I was aware that it's a powerful language with good organizational 
features for what we used to call top-down programming, and I enjoy sneering (a 
nasty, superior smirk) at claims that it's a dinosaur and will soon die an 
unmourned death as other languages supplant it.  Not gonna happen, not in my 
lifetime anyway.  Maybe in the Millennium, though I'm doubtful.

Not true, though, that it's "not acceptable" to rag on COBOL.  Obviously it is. 
 Don't waste your time and energy taking offense; we haven't enough of either 
to throw about to no benefit.

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

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 01:56

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.
--

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: DFSORT to count and sum subsets of data

[Sri h Kolusu]

>> What I want to do is produce a single line for each Department (cols 1-3), 
>> that tells me the number of articles (Count of all rows with a numeric value 
>> in cols 19-21, and an Indicator in col 22 of "D"), and a sum of the Counter 
>> (cols 102-110, pic 9), with a grand total. It will look like this:

Billy,

It is quite simple.  Use the following control cards.

//SYSINDD *
  INCLUDE COND=(22,01,CH,EQ,C'D')

   SORT FIELDS=(01,03,CH,A)

  OUTFIL REMOVECC,NODETAIL,
  SECTIONS=(01,03,
  TRAILER3=(' DEPARTMENT  ',
01,03,
COUNT=(M10,LENGTH=8),
' ARTICLES, TOTAL ITEMS: ',
TOT=(102,09,UFF,M10,LENGTH=12))),
  TRAILER1=('*** TOTAL *** : ',
COUNT=(M10,LENGTH=8),
' ARTICLES, TOTAL ITEMS: ',
TOT=(102,09,UFF,M10,LENGTH=12))
/*


If you do need to validate the contents of 19-21 for numeric , then you just 
need to use the following control cards.  Just add an IFTHEN statement for 
numeric check.

//SYSINDD *
  INCLUDE COND=(22,01,CH,EQ,C'D')

  INREC IFTHEN=(WHEN=(19,3,FS,EQ,NUM),
   OVERLAY=(130:C'1'))

   SORT FIELDS=(01,03,CH,A)

  OUTFIL REMOVECC,NODETAIL,
  SECTIONS=(01,03,
  TRAILER3=(' DEPARTMENT  ',
01,03,
TOT=(130,01,ZD,M10,LENGTH=8),
' ARTICLES, TOTAL ITEMS: ',
TOT=(102,09,UFF,M10,LENGTH=12))),
  TRAILER1=('*** TOTAL *** : ',
TOT=(130,01,ZD,M10,LENGTH=8),
' ARTICLES, TOTAL ITEMS: ',
TOT=(102,09,UFF,M10,LENGTH=12))
/*



If you intend to have the spaces trimmed in the output, let me know and I will 
suggest an alternative.


Thanks,
Kolusu
DFSORT Development
IBM Corporation


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

Re: ASM call by value

[Frank Swarbrick]

Oops, "typo".  I meant "*k = i + j".

From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Sunday, March 26, 2023 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

My C is rusty... I need to review pointer/address-of syntax.  The idea for
the 3rd argument was to show one "passed by reference"; in any case
modifiable by the subroutine.

But where did x and y come from?

sas

On Sun, Mar 26, 2023 at 7:53 PM Frank Swarbrick 
wrote:

> Also, "*k = x + y".
> 
> From: IBM Mainframe Discussion List  on behalf
> of Frank Swarbrick 
> Sent: Sunday, March 26, 2023 5:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: ASM call by value
>
> I'm guessing he meant "int *k" rather than "&int k".
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, March 26, 2023 5:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: ASM call by value
>
> On Sun, 26 Mar 2023 19:35:59 -0400, Steve Smith wrote:
>
> >I forgot to mention, to pass by value with CALL, you need [a] register[s].
> >e.g.:
> >void foo(int i, int j , &int k)
> >  {
> >  k = i + j;
> >  }
> >
> That shouldn't be legal.  In fact, gcc gives me:
> cc tinyc.c   -o tinyc
> tinyc.c:3:25: error: expected parameter declarator
> void foo(int i, int j , &int k)
>
> --
> 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: DFSORT to count and sum subsets of data

[Sri h Kolusu]

Billy,

On second thoughts, you don't even need the IFTHEN statement as you can perform 
the numeric check in the INCLUDE cond itself.

//SYSINDD *
  INCLUDE COND=(19,03,FS,EQ,NUM,AND,
22,01,CH,EQ,C'D')

   SORT FIELDS=(01,03,CH,A)

  OUTFIL REMOVECC,NODETAIL,
  SECTIONS=(01,03,
  TRAILER3=(' DEPARTMENT  ',
01,03,
COUNT=(M10,LENGTH=8),
' ARTICLES, TOTAL ITEMS: ',
TOT=(102,09,UFF,M10,LENGTH=12))),
  TRAILER1=('*** TOTAL *** : ',
COUNT=(M10,LENGTH=8),
' ARTICLES, TOTAL ITEMS: ',
TOT=(102,09,UFF,M10,LENGTH=12))
/*


Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Frank Swarbrick]

As a COBOL programmer for almost 27 years I agree that COBOL should not be 
dismissed.  Though, as someone who has "studied" 30+ other languages I would 
say that COBOL is somewhat unique and if it's your first and primary language 
it may cause hardships when trying to learn other languages.  But I absolutely 
agree that the dismissal of COBOL programmers is, well, not very nice to say 
the least.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 26, 2023 11:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Stop the ragging on COBOL please [was: RE: ASM call by value]

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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: A question or two on zOS issues

[Steve Thompson]

Glad to hear that someone followed all the rules so that, 
unannounced COBOL 5+ didn't cause you packed decimal problems 
with Truncation and the like. Or same thing with binary.


Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:

The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
to VS COBOL II in 1992. Since then we've migrated our 7 million lines of COBOL 
code...

- 1998 Language Environment
- 2000 COBOL for MVS & VM
- 2003 COBOL for OS/390 & VM
- 2004 COBOL for z/OS & OS/390 3.2
- 2005  3.3
- 2006  3.4
- 2011  4.2
- 2020  6.2

By doing... nothing.

The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
requirement for load modules.


So, in my experience, we don't need to know when our COBOL programs were last 
used. And we already have tools that give us the compile date and version, both 
from IBM and home grown.

We still have a large number of programs that haven't been recompiled since the 
VS COBOL II migration. They coexist just fine.

(You may have to *relink* to pick up the Language Environment bootstrap 
programs)


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Pryor
Sent: Friday, March 24, 2023 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A question or two on zOS issues

There are a couple of pressing issues in z/OS that I'm sure many folks are 
aware of but about which there doesn't seem to be much being done. I'm curious 
as to what other IBM-MAINer's thoughts might be. Specifically, I'm talking 
about:

1.) migration to IBM's latest COBOL release, and

2.) the not-really-that-far-off issue of Year 2042

I've been asked several times recently whether we (a z/OS ISV) should consider 
developing products to address these issues. Frankly, though, I live in an 
ivory tower and while I sometime *think* I know what installations problems and 
needs are, I'm usually surprised to find that reality is quite different. So 
I'd like to throw a couple of questions out to the list for comment:

1.) Would a reporting utility that determined which COBOL programs were 
executed (and which ones weren't), and what release and options they were 
compiled with be significantly helpful in a COBOL migration? What other 
features would be nice to have? Or is this a low priority for most 
installations, who are perhaps trying to justify keeping the mainframe alive 
and/or conducting business as usual, let alone doing a COBOL migration project?

2.) It's rather shocking that 2042 is so close and not much seems to be 
happening. We are one of the vendors that have a date-simulation utility, but 
we don’t know if data centers have any near-term plans for 2042. Would it be 
worthwhile to have a 2042 date-simulation product now, or is everyone going to 
cross their fingers and try to use a test LPAR once the operating system fully 
supports 2042 dates?

Thanks for any comments and insight the IBM-MAIN hive mind might have.

Steve Pryor
CTO
DTS Software, LLC

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


--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

Re: A question or two on zOS issues

[Schmitt, Michael]

I didn't mention that because I consider it to be self-inflicted.

We believed that we were consistently using correct signs, so we changed from 
NUMPROC(MIG) to (PFD) in 2015.

We're STILL running into issues with this, in fact I hit some just last week. 
But not enough to give up and downgrade to NOPFD. Some of the bad signs are 
originating from other languages.

For binary, we've always compiled TRUNC(OPT).


Some of our programmers believe that a numeric field with spaces should be 
processed as zero, just because before it worked!


Also, we do know that recompiling with COBOL z/OS 6 dramatically improves 
performance, but we're not recompiling just to gain that, as recompiling is 
always a risk. And, we're not gaining the full benefit because we can't allow 
it to use vector packed instructions until all sites where the code can run are 
on compatible hardware.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, March 27, 2023 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don’t know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

Re: ASM call by value

[Frank Swarbrick]

So it looks like all I need is the following:
CALL @@GETCB,(3)
which should call the @@GETCB function passing integer 3 by value, returning 0 
or 1 in R15 to indicate if the task is running in a CICS environment.
Will give this a shot.  Thanks!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
> Can the MVS CALL macro be used to call a C function with "value" parameters 
> (rather than reference parameters)?
>
>
> --
> 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: setfacl question

[Rick Troth]

I'm not sure that's possible.
In any case, I don't know specifically how to do it.

Best practice on Unix is for /tmp to be set as 'chmod 1777'. That way, 
anyone can write to /tmp but they can then only delete or rename or move 
files which they own. But if you then created a sub-directory like 
/tmp/mything it would not necessarily inherit the same permissions.


Now ... you *could* run a cron job to 'chmod a+rw /foo/bar'. That's 
inelegant, but would give the desired effect (if you can tolerate the 
race condition between cron runs).


All of this is about 'chmod' and you mention 'setfacl'.
I've used 'setfacl' to great effect, but not used the "default" options. 
So this is the limit of my knowledge on the subject, but I didn't see 
anyone else reply.


-- R; <><



On 3/27/23 08:11, Mark Jacobs wrote:

I want a directory that anyone can write to/read from and for any files or 
directories created under it also to be world readable/writable by default.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key 
-https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Monday, March 27th, 2023 at 8:05 AM, Rick Troth  wrote:



I started a longer reply, but got stuck in the weeds.

Can you describe what you're trying to do?

-- R; <><



On 3/27/23 07:10, Mark Jacobs wrote:


I’ve never been able to get the setfacl command to do what I’m trying to do. 
Any assistance would be appreciated. I’m trying to set the default ACL for any 
new files or directories created in /foo/bar to be world readable/writable, in 
short I’m looking for the permissions set to 666 for those newly created 
files/directories.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key 
-https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

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


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: A question or two on zOS issues

[Steve Thompson]

"And, we're not gaining the full benefit because we can't allow 
it to use vector packed instructions until all sites where the 
code can run are on compatible hardware."


Welcome to the developer's heart burn.

Steve Thompson


On 3/27/2023 1:43 PM, Schmitt, Michael wrote:

I didn't mention that because I consider it to be self-inflicted.

We believed that we were consistently using correct signs, so we changed from 
NUMPROC(MIG) to (PFD) in 2015.

We're STILL running into issues with this, in fact I hit some just last week. 
But not enough to give up and downgrade to NOPFD. Some of the bad signs are 
originating from other languages.

For binary, we've always compiled TRUNC(OPT).


Some of our programmers believe that a numeric field with spaces should be 
processed as zero, just because before it worked!


Also, we do know that recompiling with COBOL z/OS 6 dramatically improves 
performance, but we're not recompiling just to gain that, as recompiling is 
always a risk. And, we're not gaining the full benefit because we can't allow 
it to use vector packed instructions until all sites where the code can run are 
on compatible hardware.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, March 27, 2023 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:

The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
to VS COBOL II in 1992. Since then we've migrated our 7 million lines of COBOL 
code...

- 1998 Language Environment
- 2000 COBOL for MVS & VM
- 2003 COBOL for OS/390 & VM
- 2004 COBOL for z/OS & OS/390 3.2
- 2005  3.3
- 2006  3.4
- 2011  4.2
- 2020  6.2

By doing... nothing.

The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
requirement for load modules.


So, in my experience, we don't need to know when our COBOL programs were last 
used. And we already have tools that give us the compile date and version, both 
from IBM and home grown.

We still have a large number of programs that haven't been recompiled since the 
VS COBOL II migration. They coexist just fine.

(You may have to *relink* to pick up the Language Environment bootstrap 
programs)


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Pryor
Sent: Friday, March 24, 2023 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A question or two on zOS issues

There are a couple of pressing issues in z/OS that I'm sure many folks are 
aware of but about which there doesn't seem to be much being done. I'm curious 
as to what other IBM-MAINer's thoughts might be. Specifically, I'm talking 
about:

1.) migration to IBM's latest COBOL release, and

2.) the not-really-that-far-off issue of Year 2042

I've been asked several times recently whether we (a z/OS ISV) should consider 
developing products to address these issues. Frankly, though, I live in an 
ivory tower and while I sometime *think* I know what installations problems and 
needs are, I'm usually surprised to find that reality is quite different. So 
I'd like to throw a couple of questions out to the list for comment:

1.) Would a reporting utility that determined which COBOL programs were 
executed (and which ones weren't), and what release and options they were 
compiled with be significantly helpful in a COBOL migration? What other 
features would be nice to have? Or is this a low priority for most 
installations, who are perhaps trying to justify keeping the mainframe alive 
and/or conducting business as usual, let alone doing a COBOL migration project?

2.) It's rather shocking that 2042 is so close and not much seems to be 
happening. We are one of the vendors that have a date-simulation utility, but 
we don’t know if data centers have any near-term plans for 2042. Would it be 
worthwhile to have a 2042 date-simulation product now, or is everyone going to 
cross their fingers and try to use a test LPAR once the operating system fully 
supports 2042 dates?

Thanks for any comments and insight the IBM-MAIN hive mind might have.

Steve Pryor
CTO
DTS Software, LLC

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

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send 

Anyone Running / Experienced with ZOS Tectia Product / SFTP Transmissions

[Steve Estle]

All,

We have Tectia ZOS (https://www.ssh.com/products/mainframe-security-software) 
product running in our installation and need to setup for allowing public / 
private key SFTP transmissions related to EDI application / product used 
internally.  Tectia Product manuals while quite verbose do not give much 
guidance in how to create / generate / public / private key certificates in 
allowing this to occur.  Anyone with knowledge / experience in this world (of 
course highly "open systems" / Unix / Linux centric) would be much appreciated.

I'm giving two contact methods should you want to talk offline:

Steve Estle
sest...@gmail.com
303-604-0925.

TIA to all.

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

Re: setfacl question

[Mark Jacobs]

It's interesting you mentioned /tmp. That's what started this entire exercise. 
We migrated our /tmp filesystem from a ZFS to TFS and ran into a problem with 
our scheduling product. Turned out that it's documented that the product 
doesn't support TFS event triggering. So if batch job put a file in /tmp when 
it was a ZFS the scheduling product would see it and kick off a job.

Once we migrated /tmp to a TFS, the triggering didn't occur. Trying to simulate 
that behavior with a ZFS file system.  

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Monday, March 27th, 2023 at 1:56 PM, Rick Troth  wrote:


> I'm not sure that's possible.
> In any case, I don't know specifically how to do it.
> 
> Best practice on Unix is for /tmp to be set as 'chmod 1777'. That way,
> anyone can write to /tmp but they can then only delete or rename or move
> files which they own. But if you then created a sub-directory like
> /tmp/mything it would not necessarily inherit the same permissions.
> 
> Now ... you could run a cron job to 'chmod a+rw /foo/bar'. That's
> inelegant, but would give the desired effect (if you can tolerate the
> race condition between cron runs).
> 
> All of this is about 'chmod' and you mention 'setfacl'.
> I've used 'setfacl' to great effect, but not used the "default" options.
> So this is the limit of my knowledge on the subject, but I didn't see
> anyone else reply.
> 
> -- R; <><
> 
> 
> 
> 
> On 3/27/23 08:11, Mark Jacobs wrote:
> 
> > I want a directory that anyone can write to/read from and for any files or 
> > directories created under it also to be world readable/writable by default.
> > 
> > Mark Jacobs
> > 
> > Sent from ProtonMail, Swiss-based encrypted email.
> > 
> > GPG Public Key 
> > -https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > 
> > --- Original Message ---
> > On Monday, March 27th, 2023 at 8:05 AM, Rick trothtro...@gmail.com wrote:
> > 
> > > I started a longer reply, but got stuck in the weeds.
> > > 
> > > Can you describe what you're trying to do?
> > > 
> > > -- R; <><
> > > 
> > > On 3/27/23 07:10, Mark Jacobs wrote:
> > > 
> > > > I’ve never been able to get the setfacl command to do what I’m trying 
> > > > to do. Any assistance would be appreciated. I’m trying to set the 
> > > > default ACL for any new files or directories created in /foo/bar to be 
> > > > world readable/writable, in short I’m looking for the permissions set 
> > > > to 666 for those newly created files/directories.
> > > > 
> > > > Mark Jacobs
> > > > 
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > 
> > > > GPG Public Key 
> > > > -https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > > > 
> > > > --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > 
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email tolists...@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

Lebanon fully starts DST on Wednesday.

[Mike Schwab]

https://apnews.com/article/lebanon-daylight-saving-time-a85575b650af7fcc419e3fdb1b2090e8

Mostly started Sunday but a last minute delay was issued but mostly
not followed.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: ASM call by value

[Frank Swarbrick]

I think you are explaining what, in COBOL terms, is CALL BY CONTENT, not CALL 
BY VALUE.  CALL BY CONTENT seems to be similar (same?) as what Bernd is 
describing in PL/I with the placement of parentheses around the argument.  CALL 
BY CONTENT (in COBOL) creates a "dummy" variable, copies the "content" of the 
original variable to the dummy variable, and passes the address of the dummy 
variable.

CALL BY VALUE (in COBOL) does not do this.  CBV places the actual value 
(generally, if maybe not always) in the parameter list (where CALL BY REFERENCE 
and CALL BY CONTENT would place an address).

On the CALLEE side you also must (*) specify BY VALUE when the caller argument 
is passed BY VALUE, so that the CALLEE knows there is a value rather than an 
address in that parameter.
(*) The "exception" being that you COULD have the caller do
CALL XXX BY VALUE ADDRESS OF MY-FIELD
and have the CALLER "receive" the parameter by reference (the default) to be 
able to address the callers MY-FIELD variable.  Not generally recommended, but 
can work.

In C you always "call by value", but sometimes the value is an address 
(reference)., e.g. (as has been shown by others),
xxx(a, &b)
This passes the value of a and THE VALUE OF THE ADDRESS of b.  So rather, in 
COBOL this would be
call 'xxx' using by value a, by value address of b.

When invoking program 'xxx', regardless of if it is written in C, COBOL, PL/I 
or assembler, there is no other way for a COBOL program to call it passing the 
VALUE of a other than using the BY VALUE clause as shown previously.  If you 
attempted to pass BY REFERENCE (default) or BY CONTENT then the corresponding 
parameter in xxx would be the address of a, not the value of a, and would not 
work as desired. I think Bernd has shown in PL/I how to use BYVALUE or 
something like that.

Prior to BY VALUE being added to COBOL (pre-1985, I believe) you could not 
properly call a C routine that expected a value parameter.  Only C routines 
that had pointer arguments was possible.

Clear as mud?


From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Monday, March 27, 2023 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

All you really need to do a "call by value" in ASM is a special Call
macro (say maybe VCALL)  that allocates "hidden" space for a copy of the
variable value, copies the original variable, and somehow passes that to
the called program, and a programming rule that says you only invoke
that particular subroutine using the intended interface.  You can even
add a special Subroutine entry macro and employ some "tricks" so that
attempts to reference the subroutine name by an ordinary Call macro or
direct reference will fail.

If your only allowed interfaces to the subroutine allows it so see the
value of a variable passed by the caller but not change the
corresponding variable known to the caller, then that IS call by value,
no matter what the underlying implementation in low-level code.

Native machine instructions and standard subroutine linkages may only
support call by reference, but the advantage of a macro assembler is
that you can extend the language through macros and create an enhanced
language that can do so much more. Some notable examples of this are
various implementations using macros that allow use of
structured-programming control constructs and recursive procedures with
dynamic variable storage in Assembly programs.

 Joel C Ewing

On 3/27/23 09:13, Bernd Oppolzer wrote:
>DCL X BIN FIXED (31);
>CALL SUB ((X));
>
> SUB: PROC (P);
>DCL P BIN FIXED (31);
>
>END SUB;
>
> The statement CALL SUB ((X));
> creates a dummy argument for X (that is, a copy of variable X).
> The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
> This is NOT call by value.
>
> The subroutine cannot change X, because it gets the address of the
> copy of X
> and not the address of X. That is:
>
> call by reference of a dummy argument
> and not
> call by value
>
> The types of X and P may be different; if so, the dummy argument gets
> the type of P.
> In this case, no parantheses are required (but a warning message is
> issued, if there are
> no parentheses). But the mechanism is the same, regardless if the
> types match (with parantheses)
> or if the types don't match (without parantheses). Only in the case
> when the types match and
> there are no parantheses, you have a real call by reference where the
> subroutine can change
> the value of the caller.
>
> This is PL/1 ... other languages don't behave this way. With other
> languages, you will get a
> problem at runtime, if the types don't match.
>
> Kind regards
>
> Bernd
>
>
>
> Am 27.03.2023 um 16:03 schrieb Seymour J Metz:
>> Why is it important to you that an address not be passed and why do
>> you believe that a PL/I dummy variable means that the argument was
>> not passed by value? Languages specify black box behavior, not how
>> you enfo

Re: A question or two on zOS issues

[Frank Swarbrick]

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don’t know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

--
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: A question or two on zOS issues

[Schmitt, Michael]

You're right, and fortunately we were saved from that pain because we 
procrastinated so long. And we skipped v5 completely.

We procrastinated because it took me a long time to rewrite our load module 
analyzer, as well as other PDS-dependencies.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, March 27, 2023 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don't know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

--

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bob Bridges]

I definitely get having enough of it, old/cranky/ornery or not.  And you'll 
notice (or maybe you didn't) that I said nothing about ragging on COBOL 
programmers.  There I'm much more inclined to agree with you.

While I'm making disclaimers, I don't need much in the way of respect when 
you're disagreeing.  Or let's say I don't need ~professions~ of respect; I take 
it for granted that two people can disagree without flinging insults.  If I 
disagree with you (which I'm about to), please assume that disagreement is 
~all~ it is.  I don't have to think you're stupid for disagreeing with me; heck 
you may even be right and I wrong.  (Don't laugh, it's technically possible.)

What I'm really thinking is that if you take offense, it harms you - maybe just 
a little, maybe a lot depending on what you do with it - and harms the other 
guy not at all.  Yes, the other guy should be polite, and so should I; I'm not 
disagreeing with that.  But I'm not talking about the folks who aren't polite 
(and there'll always be those who aren't), I'm talking about how I should 
receive it.  If I resent it when the offense is unintentional, that's pretty 
dumb.  And if I resent it when resentment is what the speaker wanted from me, 
to me that seems even dumber.

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

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

I swear this used to be in my tagline file, but I went looking for it the other 
day and couldn't find it.  I must have deleted it accidentally.  I had to go 
look it up on the web (I didn't remember who said it) and put it back in.

Who is Erasmus, anyway?  Here he is: "Dutch philosopher and Catholic theologian 
who is considered one of the greatest scholars of the northern Renaissance".

When I was a traveling contractor I would take a job in some far-off city.  I'd 
pack up the car with my stuff (if I couldn't put everything I owned into the 
trunk and back seat, I figured I owned too much stuff), drive to Phoenix or 
Minneapolis or Philly or wherever, and live there for the duration of the 
contract, flying home some weekends to visit.  Most of my books went into 
long-term storage during this phase of my life - that is, two of my daughters 
and one of my sons now have them and the arrangement is probably more or less 
permanent - but three or four boxes of books always went with me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 12:03

Respectfully, I disagree.  It isn't a waste of time or energy to be offended by 
patent insults, however slyly delivered or with whatever level of snigger 
behind the words.

I did not used to support any of the campaigns against "micro-aggressions" so 
popular in recent years on university and college campuses across the country, 
but I have come to see that they are not entirely wrong-headed or petty or 
overblown.  Taken too far at times, yes, I see that too.  But they are not 
wrong at the base.

This particular one just "got to me".  The proverbial straw on that poor 
camel's back.

I'm old and cranky and ornery, so I say things when they happen to hit me 
because time is not on my side.  I do try very hard not to impugn anyone else's 
character or capabilities, because that's just wrong.  There is solid advice in 
the old adage to say nothing if you cannot say something good.

I am also reminded of some pithy advice from Robert Heinlein's character 
Lazarus Long about the absolute necessity of maintaining consistent politeness 
in order to sustain a functioning and loving family, and in the broader sense 
to maintain a functioning and civil society.

P.S. -- I love your Erasmus tagline and agree wholeheartedly.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 9:44 AM

Peter!  I don't think I've heard from you recently; maybe I just wasn't paying 
attention until I read this one.

I myself dislike COBOL for the very simple and personal reason that it's so 
WORDY.  But even when I had to use it a lot (I was a COBOL developer for about 
15 years), I was aware that it's a powerful language with good organizational 
features for what we used to call top-down programming, and I enjoy sneering (a 
nasty, superior smirk) at claims that it's a dinosaur and will soon die an 
unmourned death as other languages supplant it.  Not gonna happen, not in my 
lifetime anyway.  Maybe in the Millennium, though I'm doubtful.

Not true, though, that it's "not acceptable" to rag on COBOL.  Obviously it is. 
 Don't waste your time and energy taking offense; we haven't enough of either 
to throw about to no benefit.

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 01

Re: A question or two on zOS issues

[Frank Swarbrick]

Sometimes the worm that the early bird gets is diseased.  :-)

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Monday, March 27, 2023 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

You're right, and fortunately we were saved from that pain because we 
procrastinated so long. And we skipped v5 completely.

We procrastinated because it took me a long time to rewrite our load module 
analyzer, as well as other PDS-dependencies.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, March 27, 2023 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don't know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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

--
Regards,
Steve Thompson
VS Strategies

Re: [EXTERNAL] Re: A question or two on zOS issues

[Pommier, Rex]

We did...  Had several discussions on TRUNC and various other options in the 
compiler/runtime.  Plenty of heartburn.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, March 27, 2023 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that, unannounced COBOL 5+ 
didn't cause you packed decimal problems with Truncation and the like. Or same 
thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment 
> bootstrap programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don’t know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
For IBM-MAIN sub

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Farley, Peter]

In one of those cases we can agree: dumber to provide resentment when that was 
the OP's intent.  Trolls should simply be ignored.

"Unintentional" is a different case.  Once is no problem - even perhaps a few 
times.  When it becomes more regular or even expected is when it becomes 
unacceptable, whether from just one speaker or from more than one.  I have come 
to believe that persistent "unintentional" ones need to be called out and 
challenged, because they are (or can be) hurtful, intended or not.

In this particular instance, I suspect the disrespect was not intentional, but 
it rankled anyway because it felt to me like it had been used too frequently 
here in the recent past (note - FELT like, whether actually true or not).  I 
suspect my cranky was turned up a notch more than it needed to be, but there it 
is.

I've done what my cranky believed needed to be done, and won't harp on it again.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]



What I'm really thinking is that if you take offense, it harms you - maybe just 
a little, maybe a lot depending on what you do with it - and harms the other 
guy not at all.  Yes, the other guy should be polite, and so should I; I'm not 
disagreeing with that.  But I'm not talking about the folks who aren't polite 
(and there'll always be those who aren't), I'm talking about how I should 
receive it.  If I resent it when the offense is unintentional, that's pretty 
dumb.  And if I resent it when resentment is what the speaker wanted from me, 
to me that seems even dumber.

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

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 12:03

Respectfully, I disagree.  It isn't a waste of time or energy to be offended by 
patent insults, however slyly delivered or with whatever level of snigger 
behind the words.

I did not used to support any of the campaigns against "micro-aggressions" so 
popular in recent years on university and college campuses across the country, 
but I have come to see that they are not entirely wrong-headed or petty or 
overblown.  Taken too far at times, yes, I see that too.  But they are not 
wrong at the base.

This particular one just "got to me".  The proverbial straw on that poor 
camel's back.

I'm old and cranky and ornery, so I say things when they happen to hit me 
because time is not on my side.  I do try very hard not to impugn anyone else's 
character or capabilities, because that's just wrong.  There is solid advice in 
the old adage to say nothing if you cannot say something good.

I am also reminded of some pithy advice from Robert Heinlein's character 
Lazarus Long about the absolute necessity of maintaining consistent politeness 
in order to sustain a functioning and loving family, and in the broader sense 
to maintain a functioning and civil society.

P.S. -- I love your Erasmus tagline and agree wholeheartedly.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 9:44 AM

Peter!  I don't think I've heard from you recently; maybe I just wasn't paying 
attention until I read this one.

I myself dislike COBOL for the very simple and personal reason that it's so 
WORDY.  But even when I had to use it a lot (I was a COBOL developer for about 
15 years), I was aware that it's a powerful language with good organizational 
features for what we used to call top-down programming, and I enjoy sneering (a 
nasty, superior smirk) at claims that it's a dinosaur and will soon die an 
unmourned death as other languages supplant it.  Not gonna happen, not in my 
lifetime anyway.  Maybe in the Millennium, though I'm doubtful.

Not true, though, that it's "not acceptable" to rag on COBOL.  Obviously it is. 
 Don't waste your time and energy taking offense; we haven't enough of either 
to throw about to no benefit.

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 01:56

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to u

Re: Stop the ragging on COBOL please

[Schmitt, Michael]

Is it OK to rag on languages with no redeeming qualities?  




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

Re: Stop the ragging on COBOL please

[Farley, Peter]

 Maybe . . . 😊

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, March 27, 2023 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

Is it OK to rag on languages with no redeeming qualities?  
--

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: Stop the ragging on COBOL please

[zMan]

Now we get to argue over whether JCL is a language! (Despite the "L" in the
name, I'm 100% sure there are folks who will argue that it is not, just as
there are folks who argue that HTML isn't a language. I'm not one of them,
don't throw things at me!)

On Mon, Mar 27, 2023 at 3:43 PM Farley, Peter <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

>  Maybe . . . 😊
>

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

Re: Stop the ragging on COBOL please

[Mike Schwab]

https://jol.oscar-jol.com/about-jol  JCL On Line

On Mon, Mar 27, 2023 at 2:43 PM Farley, Peter
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
>  Maybe . . . 😊
>

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

Re: Stop the ragging on COBOL please

[Pommier, Rex]

Using my most basic definition of a computer language - it's a list of commands 
that can be saved to run it multiple times just by invoking the list name, then 
both JCL and CLIST are languages (as is HTML), and both have redeeming 
qualities.  How many of you (hypothetically) are running JCL "decks" (and I 
used that term on purpose) that were first built on punch cards with little to 
no change since they were first built?   JOL anybody?  I would say a redeeming 
value of JCL is that there's nothing out there to easily replace it.

Same with CLISTs.  Can you rewrite the CLIST in a newer language?  Sure.  Is it 
worth it?  Probably not.  Thus its longevity is probably a redeeming quality.  

I'll go back to my corner now.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

 Maybe . . . 😊

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, March 27, 2023 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

Is it OK to rag on languages with no redeeming qualities?  
--

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Pommier, Rex]

Sorry, I'm going to "rag" on a language...  :-)  Admittedly I know next to 
nothing about it.  My exposure to it consists of reading an article where 
somebody took a 14 line JCL job and converted it to JOL and the JOL code ended 
up somewhere around 70+ lines plus comments to explain what the program was 
doing.   It appears that JOL now does a lot more than it used to do the last 
time I actually looked at it.  However, in JCL's defense, how many people 
actually build jobs (especially more complex multi-step jobs with IF/THEN, 
conditional execution, etc. from scratch?  Same as with a typical Cobol 
program, you take an existing program or JCL member and modify it to fit your 
needs.  

How many people here use JCL (whether you like it or hate it) on a regular 
basis?   It's ubiquitous. 

How many use JOL?  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Monday, March 27, 2023 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

https://urldefense.com/v3/__https://jol.oscar-jol.com/about-jol__;!!KjMRP1Ixj6eLE0Fj!vGAo09RSRyegMrA-_z-guiaGvhkdNPyxpge54CfqCQvUuwDKJzELN2R4OZtsAhm19487HzuIfdXymkh3cCArALgCDA$
   JCL On Line

On Mon, Mar 27, 2023 at 2:43 PM Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
>  Maybe . . . 😊
>

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: Stop the ragging on COBOL please

[Steve Thompson]

I fine it interesting that a person by the name of Rex is bashing 
CLIST. Yep


And yes, I do write JCL from scratch (answer the next post) 
because I right now, I'm working on migration code and need 
examples of certain constructs so I can make sure the migration 
code handles it correctly. Notice I did not say conversion (which 
I used to do DOS to MVS up to VSE-ESA to z/OS 1.2).


Oh, I haven't had to deal with it for a while, but as I recall 
there is a function that CLIST can do that REXX couldn't (well 
back in the 1990s). I wonder if that is still true.


Back to enjoying this thread.  :)

Steve Thompson


On 3/27/2023 4:17 PM, Pommier, Rex wrote:

Using my most basic definition of a computer language - it's a list of commands that can 
be saved to run it multiple times just by invoking the list name, then both JCL and CLIST 
are languages (as is HTML), and both have redeeming qualities.  How many of you 
(hypothetically) are running JCL "decks" (and I used that term on purpose) that 
were first built on punch cards with little to no change since they were first built?   
JOL anybody?  I would say a redeeming value of JCL is that there's nothing out there to 
easily replace it.

Same with CLISTs.  Can you rewrite the CLIST in a newer language?  Sure.  Is it 
worth it?  Probably not.  Thus its longevity is probably a redeeming quality.

I'll go back to my corner now.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

 Maybe . . . 😊

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, March 27, 2023 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

Is it OK to rag on languages with no redeeming qualities?  
--

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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


--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bob Bridges]

Oh, calling it out is fine.  I was talking only about resenting it, which harms 
you and does no balancing benefit.  You can do the one without the other.  Me, 
I'm more likely to ignore it, or at least to ignore it longer, but that's a 
personal choice.

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

/* It would be nice to spend billions on schools and roads, but right now that 
money is desperately needed for political ads.  -Andy Borowitz */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 15:31

In one of those cases we can agree: dumber to provide resentment when that was 
the OP's intent.  Trolls should simply be ignored.

"Unintentional" is a different case.  Once is no problem - even perhaps a few 
times.  When it becomes more regular or even expected is when it becomes 
unacceptable, whether from just one speaker or from more than one.  I have come 
to believe that persistent "unintentional" ones need to be called out and 
challenged, because they are (or can be) hurtful, intended or not.

In this particular instance, I suspect the disrespect was not intentional, but 
it rankled anyway because it felt to me like it had been used too frequently 
here in the recent past (note - FELT like, whether actually true or not).  I 
suspect my cranky was turned up a notch more than it needed to be, but there it 
is.

I've done what my cranky believed needed to be done, and won't harp on it again.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 3:02 PM

What I'm really thinking is that if you take offense, it harms you - maybe just 
a little, maybe a lot depending on what you do with it - and harms the other 
guy not at all.  Yes, the other guy should be polite, and so should I; I'm not 
disagreeing with that.  But I'm not talking about the folks who aren't polite 
(and there'll always be those who aren't), I'm talking about how I should 
receive it.  If I resent it when the offense is unintentional, that's pretty 
dumb.  And if I resent it when resentment is what the speaker wanted from me, 
to me that seems even dumber.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 12:03

Respectfully, I disagree.  It isn't a waste of time or energy to be offended by 
patent insults, however slyly delivered or with whatever level of snigger 
behind the words.

I did not used to support any of the campaigns against "micro-aggressions" so 
popular in recent years on university and college campuses across the country, 
but I have come to see that they are not entirely wrong-headed or petty or 
overblown.  Taken too far at times, yes, I see that too.  But they are not 
wrong at the base.

This particular one just "got to me".  The proverbial straw on that poor 
camel's back.

I'm old and cranky and ornery, so I say things when they happen to hit me 
because time is not on my side.  I do try very hard not to impugn anyone else's 
character or capabilities, because that's just wrong.  There is solid advice in 
the old adage to say nothing if you cannot say something good.

I am also reminded of some pithy advice from Robert Heinlein's character 
Lazarus Long about the absolute necessity of maintaining consistent politeness 
in order to sustain a functioning and loving family, and in the broader sense 
to maintain a functioning and civil society.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 9:44 AM

Peter!  I don't think I've heard from you recently; maybe I just wasn't paying 
attention until I read this one.

I myself dislike COBOL for the very simple and personal reason that it's so 
WORDY.  But even when I had to use it a lot (I was a COBOL developer for about 
15 years), I was aware that it's a powerful language with good organizational 
features for what we used to call top-down programming, and I enjoy sneering (a 
nasty, superior smirk) at claims that it's a dinosaur and will soon die an 
unmourned death as other languages supplant it.  Not gonna happen, not in my 
lifetime anyway.  Maybe in the Millennium, though I'm doubtful.

Not true, though, that it's "not acceptable" to rag on COBOL.  Obviously it is. 
 Don't waste your time and energy taking offense; we haven't enough of either 
to throw about to no benefit.

/* When I have a little money, I buy books; and if I have any left, I buy food 
and clothes.  -Erasmus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, March 27, 2023 01:56

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL,

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Pommier, Rex]

Steve, no, no, no, no.  I'm not bashing Rexx or CLISTS or JCL.  I'm trying to 
do just the opposite.  Another poster (read:Michael) was (I'm presuming 
tongue-in-cheek) bashing CLISTs and I came to CLIST's defense by pointing out 
that it still does what it was intended to do, and it's probably not worth 
taking all the CLISTs sitting around your shop and rewriting them into Rexx or 
anything else.   :-)

Rex (with only 1 'x')

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, March 27, 2023 3:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

I fine it interesting that a person by the name of Rex is bashing CLIST. Yep

And yes, I do write JCL from scratch (answer the next post) because I right 
now, I'm working on migration code and need examples of certain constructs so I 
can make sure the migration code handles it correctly. Notice I did not say 
conversion (which I used to do DOS to MVS up to VSE-ESA to z/OS 1.2).

Oh, I haven't had to deal with it for a while, but as I recall there is a 
function that CLIST can do that REXX couldn't (well back in the 1990s). I 
wonder if that is still true.

Back to enjoying this thread.  :)

Steve Thompson


On 3/27/2023 4:17 PM, Pommier, Rex wrote:
> Using my most basic definition of a computer language - it's a list of 
> commands that can be saved to run it multiple times just by invoking the list 
> name, then both JCL and CLIST are languages (as is HTML), and both have 
> redeeming qualities.  How many of you (hypothetically) are running JCL 
> "decks" (and I used that term on purpose) that were first built on punch 
> cards with little to no change since they were first built?   JOL anybody?  I 
> would say a redeeming value of JCL is that there's nothing out there to 
> easily replace it.
>
> Same with CLISTs.  Can you rewrite the CLIST in a newer language?  Sure.  Is 
> it worth it?  Probably not.  Thus its longevity is probably a redeeming 
> quality.
>
> I'll go back to my corner now.  :-)
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Farley, Peter
> Sent: Monday, March 27, 2023 2:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Stop the ragging on COBOL please
>
>  Maybe . . . 😊
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Schmitt, Michael
> Sent: Monday, March 27, 2023 3:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Stop the ragging on COBOL please
>
> Is it OK to rag on languages with no redeeming qualities?   CLIST>
> --
>
> 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
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclos

Re: Stop the ragging on COBOL please

[Phil Smith III]

Steve Thompson wrote, in part:
>Oh, I haven't had to deal with it for a while, but as I recall
>there is a function that CLIST can do that REXX couldn't (well
>back in the 1990s). I wonder if that is still true.

Perhaps easily parsing a typical TSO command:
verb arg1(value1) arg2(value2a,value2b)
? You can certainly do it in Rexx, but (and I've never written a CLIST in my
life) ISTR that CLIST makes it much easier.


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

Re: SMPe securing zones

[Matthew Stitt]

I've found that GIMSMP opens the datasets in UPDATE mode, so the user will 
still need UPDATE or higher access.  READ access fails when the program starts.

I've growled that GIMSMP needs to open in READ mode, then close/open in the 
desired UPDATE mode if needed.

Matthew

On Mon, 27 Mar 2023 13:50:28 +, Mark Jacobs  
wrote:

>If you have those zones in their own CSI datasets, you can use your security 
>system just to allow READ access.
>
>Mark Jacobs 
>
>
>Sent from ProtonMail, Swiss-based encrypted email.
>
>GPG Public Key - 
>https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
>
>
>--- Original Message ---
>On Monday, March 27th, 2023 at 9:46 AM, Bill Giannelli 
> wrote:
>
>
>> I want to create another TARGET and DLIB zone for another level of 
>> maintenance.
>> I am currently, showing "newbie" offshore folks our SMPe environment.
>> Is there a way to "secure" the newly created TARGET and DLIB zones so they 
>> are not inadvertently updated?
>> thanks
>> Bill

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

Re: Stop the ragging on COBOL please

[Bob Bridges]

Chiming in here because of the overwhelming popular demand for my unsolicited 
opinions: I ~mostly~ agree with your definition of "programming language", but 
I usually add that it has to have at least some primitive sort of if-then 
construction.  JCL didn't use to make the grade, but it does now.  So yeah, 
when I'm listing the programming languages I can use I sometimes include JCL 
... barely.

Lacking if-then, the language is simply a list of programs or commands to be 
run one after the other, like MS .bat language was at first and as QMF is now 
(or was when I last used it).  I call instructions written in those languages 
"scripts", and decline to use that word for programs written in REXX, VBA, 
CLIST and the like, which are full-scale programming languages.

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

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, March 27, 2023 16:18

Using my most basic definition of a computer language - it's a list of commands 
that can be saved to run it multiple times just by invoking the list name, then 
both JCL and CLIST are languages (as is HTML), and both have redeeming 
qualities.  How many of you (hypothetically) are running JCL "decks" (and I 
used that term on purpose) that were first built on punch cards with little to 
no change since they were first built?   JOL anybody?  I would say a redeeming 
value of JCL is that there's nothing out there to easily replace it.

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

Re: Stop the ragging on COBOL please

[Schmitt, Michael]

CLIST has nested variables, REXX doesn't. And CLIST has keyword style parms, 
while REXX arguments are strictly positional. And, in REXX you can't turn off 
first level substitution of &Variables when sending commands to ISREDIT, which 
makes it tricky to do Edit macros, such as "change all &TEMPDSN to &TEMPDSN2".

But CLIST gets negative points for the way it wants to evaluate EVERYTHING, 
recursively.


REXX is so much better but I want to ask Mike Cowlishaw what he was thinking in 
making uninitialized variables default to their own name.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Monday, March 27, 2023 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

Steve Thompson wrote, in part:
>Oh, I haven't had to deal with it for a while, but as I recall
>there is a function that CLIST can do that REXX couldn't (well
>back in the 1990s). I wonder if that is still true.

Perhaps easily parsing a typical TSO command:
verb arg1(value1) arg2(value2a,value2b)
? You can certainly do it in Rexx, but (and I've never written a CLIST in my
life) ISTR that CLIST makes it much easier.


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

separate SMPe environments

[Bill Giannelli]

Another stupid SMPe question.
Currently, we have one CSI with one target and one dlib. (I inherited this). I 
want to setup at least another target and dlib zones for a "before" maintenance 
level.
Might you ever consider creating a whole new csi for that or just as normal 
have different zones under 1 csi?
thanks
Bill

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

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Bob Bridges]

Ok, I'll ask:  What ~is~ JOL?  Never heard of it.

I'm repeatedly surprised at the number of mainframers who never learned JCL 
past the ability to modify a job by replacing a DSN or two.  Yet somehow they 
manage to function, sometimes by asking someone else to help fix their JCL.  A 
new employer put me through a Deltak course in JCL when I started with them in 
1980, and I've been using it ever since, usually on a daily or weekly basis.  
I'd hate to have to work without it.

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

/* It is not always the same thing to be a good man and a good citizen.  
-Aristotle, "Nicomachean Ethics" (325 BC) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, March 27, 2023 16:29

Sorry, I'm going to "rag" on a language...  :-)  Admittedly I know next to 
nothing about it.  My exposure to it consists of reading an article where 
somebody took a 14 line JCL job and converted it to JOL and the JOL code ended 
up somewhere around 70+ lines plus comments to explain what the program was 
doing.   It appears that JOL now does a lot more than it used to do the last 
time I actually looked at it.  However, in JCL's defense, how many people 
actually build jobs (especially more complex multi-step jobs with IF/THEN, 
conditional execution, etc. from scratch?  Same as with a typical Cobol 
program, you take an existing program or JCL member and modify it to fit your 
needs.  

How many people here use JCL (whether you like it or hate it) on a regular 
basis?   It's ubiquitous. 

How many use JOL?  

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

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Pommier, Rex]

It's a scripting language that originally built JCL but apparently has been 
enhanced to actually "do" JCL functions like dynamically allocating datasets 
and running jobs.

Another poster supplied the following URL.

https://jol.oscar-jol.com/

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Stop the ragging on COBOL please

Ok, I'll ask:  What ~is~ JOL?  Never heard of it.

I'm repeatedly surprised at the number of mainframers who never learned JCL 
past the ability to modify a job by replacing a DSN or two.  Yet somehow they 
manage to function, sometimes by asking someone else to help fix their JCL.  A 
new employer put me through a Deltak course in JCL when I started with them in 
1980, and I've been using it ever since, usually on a daily or weekly basis.  
I'd hate to have to work without it.

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

/* It is not always the same thing to be a good man and a good citizen.  
-Aristotle, "Nicomachean Ethics" (325 BC) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, March 27, 2023 16:29

Sorry, I'm going to "rag" on a language...  :-)  Admittedly I know next to 
nothing about it.  My exposure to it consists of reading an article where 
somebody took a 14 line JCL job and converted it to JOL and the JOL code ended 
up somewhere around 70+ lines plus comments to explain what the program was 
doing.   It appears that JOL now does a lot more than it used to do the last 
time I actually looked at it.  However, in JCL's defense, how many people 
actually build jobs (especially more complex multi-step jobs with IF/THEN, 
conditional execution, etc. from scratch?  Same as with a typical Cobol 
program, you take an existing program or JCL member and modify it to fit your 
needs.  

How many people here use JCL (whether you like it or hate it) on a regular 
basis?   It's ubiquitous. 

How many use JOL?  

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

CLIST but not REXX

[Bob Bridges]

Three things:

1) As Phil says, more-or-less automatic parsing of keyword and positional
arguments.  I get around that in REXX by using a standard opening paragraph
that for most purposes works just fine with a minimum of customization.  But
mostly I prefer to use one-word arguments without any particular order and
let REXX figure out what each one means, which simplifies the logic.  For
example, if it's got a period in it it's probably a DSN; if it's numeric and
less than 20 it's one argument, if numeric and greater than 100 it's
another, if it's "ACC" it's a keyword and so on.  Sometimes I have to work
harder, but not more often than every few years.

2) The ability to interact live with subsystems.  In CLIST I can start an
FTP session and interact with it, grabbing FTP's responses and deciding on
the fly what command to issue next.  In REXX I have to queue up an entire
session, then call FTP and decide afterward how it went, just like a batch
job.  I've never found a way around this.

3) The WRITENR command, enabling CLIST to issue a prompt and pull the
operator's response on the same line.  REXX's SAY command types out a line
and then goes to the next line for the response.  This isn't hard to get
around:  I just wrote a CLIST named WRITENR which receives the prompt from a
calling program and uses WRITENR to display it - then a SAYNR exec in REXX
that receives the prompt from a calling program and calls WRITENR.  So in my
REXX execs, if I want to do this (not often), I can call SAYNR as an
external procedure.

If you write your REXXes for execution in OMVS, I guess there are other
features that are easier, CHAROUT maybe?

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

/* I willingly believe that the damned are, in one sense, successful, rebels
to the end -- that the doors of hell are locked on the inside.  I do not
mean that the ghosts may not ~wish~ to come out of hell, in the vague
fashion wherein an envious man "wishes" to be happy; but they certainly do
not will even the first preliminary stages of that self-abandonment through
which alone the soul can reach any good.  They enjoy forever that horrible
freedom they have demanded, and are therefore self-enslaved -- just as the
blessed, forever submitting to obedience, become through all eternity more
and more free.  -CS Lewis, "The Problem of Pain" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Monday, March 27, 2023 17:32

Perhaps easily parsing a typical TSO command:
verb arg1(value1) arg2(value2a,value2b)
? You can certainly do it in Rexx, but (and I've never written a CLIST in my
life) ISTR that CLIST makes it much easier.

--- Steve Thompson wrote, in part:
>Oh, I haven't had to deal with it for a while, but as I recall there is 
>a function that CLIST can do that REXX couldn't (well back in the 
>1990s). I wonder if that is still true.

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

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Pommier, Rex]

That's why I said "most basic".  :-)  And if you want to get pedantic, COND= 
logic (as backwards as it started out, everybody remember "if it's true you're 
through"?) was a REALLY primitive if/then construct.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

Chiming in here because of the overwhelming popular demand for my unsolicited 
opinions: I ~mostly~ agree with your definition of "programming language", but 
I usually add that it has to have at least some primitive sort of if-then 
construction.  JCL didn't use to make the grade, but it does now.  So yeah, 
when I'm listing the programming languages I can use I sometimes include JCL 
... barely.

Lacking if-then, the language is simply a list of programs or commands to be 
run one after the other, like MS .bat language was at first and as QMF is now 
(or was when I last used it).  I call instructions written in those languages 
"scripts", and decline to use that word for programs written in REXX, VBA, 
CLIST and the like, which are full-scale programming languages.

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

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, March 27, 2023 16:18

Using my most basic definition of a computer language - it's a list of commands 
that can be saved to run it multiple times just by invoking the list name, then 
both JCL and CLIST are languages (as is HTML), and both have redeeming 
qualities.  How many of you (hypothetically) are running JCL "decks" (and I 
used that term on purpose) that were first built on punch cards with little to 
no change since they were first built?   JOL anybody?  I would say a redeeming 
value of JCL is that there's nothing out there to easily replace it.

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: Stop the ragging on COBOL please

[Phil Smith III]

Michael Schmitt wrote, in part:
>REXX is so much better but I want to ask Mike Cowlishaw 
>what he was thinking in making uninitialized variables
>default to their own name.

While as a programmer I agree with you, I'm pretty sure I know the answer:
Rexx was designed to be usable by non-programmers, who would not be expected
to understand what's a variable and what's not. In this model, a Rexx EXEC
is closer to a list of commands (hmm, whatever could we call such a
language?) than a program. Remember, VM was the original personal computing
environment, long before PCs.

As for whether he ultimately regretted the decision or not, I could ask him
but I suspect the existence of SIGNAL ON NOVALUE is an answer of sorts. And
SIGNAL ON NOVALUE-especially with the ability to trap it and report what the
variable was-is a perfect programmer-y answer, no? And thus fits the model
of non-programmers being the target/default user. 


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

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Mike Schwab]

JCL COND is similar to an assembler branch, skip if true.

On Mon, Mar 27, 2023 at 5:01 PM Pommier, Rex  wrote:
>
> That's why I said "most basic".  :-)  And if you want to get pedantic, COND= 
> logic (as backwards as it started out, everybody remember "if it's true 
> you're through"?) was a REALLY primitive if/then construct.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bob Bridges
> Sent: Monday, March 27, 2023 4:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Stop the ragging on COBOL please
>
> Chiming in here because of the overwhelming popular demand for my unsolicited 
> opinions: I ~mostly~ agree with your definition of "programming language", 
> but I usually add that it has to have at least some primitive sort of if-then 
> construction.  JCL didn't use to make the grade, but it does now.  So yeah, 
> when I'm listing the programming languages I can use I sometimes include JCL 
> ... barely.
>
> Lacking if-then, the language is simply a list of programs or commands to be 
> run one after the other, like MS .bat language was at first and as QMF is now 
> (or was when I last used it).  I call instructions written in those languages 
> "scripts", and decline to use that word for programs written in REXX, VBA, 
> CLIST and the like, which are full-scale programming languages.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Every year, on April 15, all members of Congress would be placed in 
> individual prison cells with the necessary tax forms and a copy of the Tax 
> Code. They would remain locked in the cells, without food or water, until 
> they had completed their tax returns and successfully undergone a full IRS 
> audit. Of course this system would probably result in a severe shortage of 
> congresspersons. But there might also be some drawbacks. -Dave Barry's plan 
> to simplify the tax code, 2000-04-09 */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Pommier, Rex
> Sent: Monday, March 27, 2023 16:18
>
> Using my most basic definition of a computer language - it's a list of 
> commands that can be saved to run it multiple times just by invoking the list 
> name, then both JCL and CLIST are languages (as is HTML), and both have 
> redeeming qualities.  How many of you (hypothetically) are running JCL 
> "decks" (and I used that term on purpose) that were first built on punch 
> cards with little to no change since they were first built?   JOL anybody?  I 
> would say a redeeming value of JCL is that there's nothing out there to 
> easily replace it.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: [EXTERNAL] separate SMPe environments

[Pommier, Rex]

Bill,

I've done both and for myself personally, I found it easier to have them 
completely separate.  One reason for this is that I can easily clone my system 
and SMP/E environment onto a separate set of volumes and play with it.  If I 
completely hork up the install I can just restore the volumes and my SMP/E 
environment comes back automagically with the system.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Monday, March 27, 2023 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] separate SMPe environments

Another stupid SMPe question.
Currently, we have one CSI with one target and one dlib. (I inherited this). I 
want to setup at least another target and dlib zones for a "before" maintenance 
level.
Might you ever consider creating a whole new csi for that or just as normal 
have different zones under 1 csi?
thanks
Bill 

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: Stop the ragging on COBOL please

[Seymour J Metz]

Well, I'm a programmer, and I believe that the behavior of uninitialized 
variables makes pefect sense when using REXX as a CMS scripting language. The 
things that I would change are:

 1. Not matching the operand of an end against the label of a DO.
and, no, matching it against the control variable is not the same thing.

 2. Not allowing optional DECLARE statements.

 3. The exception model.

 4. Lexical scope.

That said, it's still my preferred scripting language, although these days that 
means orexx everywhere but z/OS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Monday, March 27, 2023 6:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

Michael Schmitt wrote, in part:
>REXX is so much better but I want to ask Mike Cowlishaw
>what he was thinking in making uninitialized variables
>default to their own name.

While as a programmer I agree with you, I'm pretty sure I know the answer:
Rexx was designed to be usable by non-programmers, who would not be expected
to understand what's a variable and what's not. In this model, a Rexx EXEC
is closer to a list of commands (hmm, whatever could we call such a
language?) than a program. Remember, VM was the original personal computing
environment, long before PCs.

As for whether he ultimately regretted the decision or not, I could ask him
but I suspect the existence of SIGNAL ON NOVALUE is an answer of sorts. And
SIGNAL ON NOVALUE-especially with the ability to trap it and report what the
variable was-is a perfect programmer-y answer, no? And thus fits the model
of non-programmers being the target/default user.


--
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: CLIST but not REXX

[Phil Smith III]

Bob Bridges wrote, in part:
>2) The ability to interact live with subsystems.  In CLIST I can start an>
FTP session and interact with it, grabbing FTP's responses and deciding on>
the fly what command to issue next.  In REXX I have to queue up an entire>
session, then call FTP and decide afterward how it went, just like a batch>
job.  I've never found a way around this.

The Rexx answer to that would be a subcommand environment, but of course
that requires the thing it's calling to work with such an environment,
whereas it sounds like CLIST is just better-integrated into the OS, which
makes sense.


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

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Pommier, Rex]

Which without going into macros is about as close to IF/THEN as you are going 
to find in assembler, not?  And I don't think anybody on here (at least in 
their right mind) would argue that assembler is not a programming language.  :-)



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Monday, March 27, 2023 5:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Stop the ragging on COBOL please

JCL COND is similar to an assembler branch, skip if true.

On Mon, Mar 27, 2023 at 5:01 PM Pommier, Rex  wrote:
>
> That's why I said "most basic".  :-)  And if you want to get pedantic, COND= 
> logic (as backwards as it started out, everybody remember "if it's true 
> you're through"?) was a REALLY primitive if/then construct.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Bob Bridges
> Sent: Monday, March 27, 2023 4:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Stop the ragging on COBOL please
>
> Chiming in here because of the overwhelming popular demand for my unsolicited 
> opinions: I ~mostly~ agree with your definition of "programming language", 
> but I usually add that it has to have at least some primitive sort of if-then 
> construction.  JCL didn't use to make the grade, but it does now.  So yeah, 
> when I'm listing the programming languages I can use I sometimes include JCL 
> ... barely.
>
> Lacking if-then, the language is simply a list of programs or commands to be 
> run one after the other, like MS .bat language was at first and as QMF is now 
> (or was when I last used it).  I call instructions written in those languages 
> "scripts", and decline to use that word for programs written in REXX, VBA, 
> CLIST and the like, which are full-scale programming languages.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Every year, on April 15, all members of Congress would be placed in 
> individual prison cells with the necessary tax forms and a copy of the 
> Tax Code. They would remain locked in the cells, without food or 
> water, until they had completed their tax returns and successfully 
> undergone a full IRS audit. Of course this system would probably 
> result in a severe shortage of congresspersons. But there might also 
> be some drawbacks. -Dave Barry's plan to simplify the tax code, 
> 2000-04-09 */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Pommier, Rex
> Sent: Monday, March 27, 2023 16:18
>
> Using my most basic definition of a computer language - it's a list of 
> commands that can be saved to run it multiple times just by invoking the list 
> name, then both JCL and CLIST are languages (as is HTML), and both have 
> redeeming qualities.  How many of you (hypothetically) are running JCL 
> "decks" (and I used that term on purpose) that were first built on punch 
> cards with little to no change since they were first built?   JOL anybody?  I 
> would say a redeeming value of JCL is that there's nothing out there to 
> easily replace it.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken 

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Bob Bridges]

Right, I forgot about that.  Gotta give you that one.

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

/* I think what happens to toddlers is that they suddenly realize their parents 
have essentially been lying to them their whole lives.  We represent the world 
as this wonderful place where you are free to do as you please, not even 
stopping to use the bathroom if you don’t feel like it, and everyone keeps 
bringing you toys and your food comes from breasts.  We keep it up until you 
are far too big to climb back in the womb, and then, surprise!  Broccoli!  -W 
Bruce Cameron on the Terrible Twos, May 2006 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, March 27, 2023 18:02

That's why I said "most basic".  :-)  And if you want to get pedantic, COND= 
logic (as backwards as it started out, everybody remember "if it's true you're 
through"?) was a REALLY primitive if/then construct.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, March 27, 2023 4:41 PM

I ~mostly~ agree with your definition of "programming language", but I usually 
add that it has to have at least some primitive sort of if-then construction.  
JCL didn't use to make the grade, but it does now.  So yeah, when I'm listing 
the programming languages I can use I sometimes include JCL ... barely.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, March 27, 2023 16:18

Using my most basic definition of a computer language - it's a list of commands 
that can be saved to run it multiple times just by invoking the list name, then 
both JCL and CLIST are languages (as is HTML), and both have redeeming 
qualities.  How many of you (hypothetically) are running JCL "decks" (and I 
used that term on purpose) that were first built on punch cards with little to 
no change since they were first built?   JOL anybody?  I would say a redeeming 
value of JCL is that there's nothing out there to easily replace it.

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

Re: CLIST but not REXX

[Seymour J Metz]

There is a REXX function for parsing;it's either XPARSE or XPROC.

Yes, REXX isn't as well integrated with the TSO stack as XLIST is.

What happens if you do CHAROUT with no terminating LF or NL?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Monday, March 27, 2023 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CLIST but not REXX

Three things:

1) As Phil says, more-or-less automatic parsing of keyword and positional
arguments.  I get around that in REXX by using a standard opening paragraph
that for most purposes works just fine with a minimum of customization.  But
mostly I prefer to use one-word arguments without any particular order and
let REXX figure out what each one means, which simplifies the logic.  For
example, if it's got a period in it it's probably a DSN; if it's numeric and
less than 20 it's one argument, if numeric and greater than 100 it's
another, if it's "ACC" it's a keyword and so on.  Sometimes I have to work
harder, but not more often than every few years.

2) The ability to interact live with subsystems.  In CLIST I can start an
FTP session and interact with it, grabbing FTP's responses and deciding on
the fly what command to issue next.  In REXX I have to queue up an entire
session, then call FTP and decide afterward how it went, just like a batch
job.  I've never found a way around this.

3) The WRITENR command, enabling CLIST to issue a prompt and pull the
operator's response on the same line.  REXX's SAY command types out a line
and then goes to the next line for the response.  This isn't hard to get
around:  I just wrote a CLIST named WRITENR which receives the prompt from a
calling program and uses WRITENR to display it - then a SAYNR exec in REXX
that receives the prompt from a calling program and calls WRITENR.  So in my
REXX execs, if I want to do this (not often), I can call SAYNR as an
external procedure.

If you write your REXXes for execution in OMVS, I guess there are other
features that are easier, CHAROUT maybe?

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

/* I willingly believe that the damned are, in one sense, successful, rebels
to the end -- that the doors of hell are locked on the inside.  I do not
mean that the ghosts may not ~wish~ to come out of hell, in the vague
fashion wherein an envious man "wishes" to be happy; but they certainly do
not will even the first preliminary stages of that self-abandonment through
which alone the soul can reach any good.  They enjoy forever that horrible
freedom they have demanded, and are therefore self-enslaved -- just as the
blessed, forever submitting to obedience, become through all eternity more
and more free.  -CS Lewis, "The Problem of Pain" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Monday, March 27, 2023 17:32

Perhaps easily parsing a typical TSO command:
verb arg1(value1) arg2(value2a,value2b)
? You can certainly do it in Rexx, but (and I've never written a CLIST in my
life) ISTR that CLIST makes it much easier.

--- Steve Thompson wrote, in part:
>Oh, I haven't had to deal with it for a while, but as I recall there is
>a function that CLIST can do that REXX couldn't (well back in the
>1990s). I wonder if that is still true.

--
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: SMPe securing zones

[Mark Jacobs]

That's disappointing. It's not being done now, but another good way to handle 
that problem is to enhance the GIM.* Facility class profiles to include zone 
support for commands. User can run certain zone altering SMP/e commands against 
TZONE1, but not TZONE2. Something like that. 

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


--- Original Message ---
On Monday, March 27th, 2023 at 5:39 PM, Matthew Stitt 
 wrote:


> I've found that GIMSMP opens the datasets in UPDATE mode, so the user will 
> still need UPDATE or higher access. READ access fails when the program starts.
> 
> I've growled that GIMSMP needs to open in READ mode, then close/open in the 
> desired UPDATE mode if needed.
> 
> Matthew
> 
> On Mon, 27 Mar 2023 13:50:28 +, Mark Jacobs markjac...@protonmail.com 
> wrote:
> 
> > If you have those zones in their own CSI datasets, you can use your 
> > security system just to allow READ access.
> > 
> > Mark Jacobs
> > 
> > Sent from ProtonMail, Swiss-based encrypted email.
> > 
> > GPG Public Key - 
> > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > 
> > --- Original Message ---
> > On Monday, March 27th, 2023 at 9:46 AM, Bill Giannelli 
> > billgianne...@gmail.com wrote:
> > 
> > > I want to create another TARGET and DLIB zone for another level of 
> > > maintenance.
> > > I am currently, showing "newbie" offshore folks our SMPe environment.
> > > Is there a way to "secure" the newly created TARGET and DLIB zones so 
> > > they are not inadvertently updated?
> > > thanks
> > > Bill
> 
> 
> --
> 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: separate SMPe environments

[Mark Zelden]

On Mon, 27 Mar 2023 16:43:46 -0500, Bill Giannelli  
wrote:

>Another stupid SMPe question.
>Currently, we have one CSI with one target and one dlib. (I inherited this). I 
>want to setup at least another target and dlib zones for a "before" 
>maintenance level.
>Might you ever consider creating a whole new csi for that or just as normal 
>have different zones under 1 csi?
>thanks
>Bill
>

I have always kept separate target zones that match each sysres set.   So I 
clone the zone and sysres at the same time.  The SMP/E zones and maintenance 
sysres set are shared, but each sysplex has it's own run time sysres sets that 
get used for cloning.  So I can tell you at any point of time what maintenance 
level or specific PTFs are IPLed into any number of systems in a large 
environment with different sysplexes and while I can't remember having to do it 
"forever", you can also apply an emergency fix to a zone that matches a running 
sysres set in an emergency.For one client I have 2 separate maintenance 
target zones that support different usermods for different companies, but still 
a single global zone.  So I do have apply maintenance twice and accept it 
twice, but I only have to receive it once.  Still, each cloned sysres set gets 
a cloned target zone with it.   

At one time I also cloned the DLIB zones when I was in a smaller environment 
but there really is no need to do that and I haven't done that for years.  
Typically I don't accept maintenance until it has been running in production 
for 9-12 months and it would just be a lot of extra DASD allocated for that 
purpose that I don't need.  ACCEPT doesn't apply to the running systems, so I 
don't see any advantage nor reason to have a bunch of cloned DLIB zones and 
DLIB volumes matching all those zones.  One DLIB zone per maintenance target 
zone is enough.   


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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

Re: separate SMPe environments

[Seymour J Metz]

I prefer a shared global zone, but that's problematical if you have to rework 
sysmods.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Giannelli [billgianne...@gmail.com]
Sent: Monday, March 27, 2023 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: separate SMPe environments

Another stupid SMPe question.
Currently, we have one CSI with one target and one dlib. (I inherited this). I 
want to setup at least another target and dlib zones for a "before" maintenance 
level.
Might you ever consider creating a whole new csi for that or just as normal 
have different zones under 1 csi?
thanks
Bill

--
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: CLIST but not REXX

[Seymour J Metz]

A subcommand environment is certainly important, but it doesn't provide an 
eauivalent to DATA/DATA PROMPT.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Monday, March 27, 2023 6:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CLIST but not REXX

Bob Bridges wrote, in part:
>2) The ability to interact live with subsystems.  In CLIST I can start an>
FTP session and interact with it, grabbing FTP's responses and deciding on>
the fly what command to issue next.  In REXX I have to queue up an entire>
session, then call FTP and decide afterward how it went, just like a batch>
job.  I've never found a way around this.

The Rexx answer to that would be a subcommand environment, but of course
that requires the thing it's calling to work with such an environment,
whereas it sounds like CLIST is just better-integrated into the OS, which
makes sense.


--
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: Stop the ragging on COBOL please

[Seymour J Metz]

Actually, REXX does have nested variables; that's one of the things that you 
can doo with the VALUE() BIF.

There's no such thing as an &variable in REXX. As for turning off substitution 
of variables, if you want a constant than use a constant, as in SAY 'foo='foo

address isredit 'change all' tempdsn1 tempdsn2


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Schmitt, Michael [michael.schm...@dxc.com]
Sent: Monday, March 27, 2023 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

CLIST has nested variables, REXX doesn't. And CLIST has keyword style parms, 
while REXX arguments are strictly positional. And, in REXX you can't turn off 
first level substitution of &Variables when sending commands to ISREDIT, which 
makes it tricky to do Edit macros, such as "change all &TEMPDSN to &TEMPDSN2".

But CLIST gets negative points for the way it wants to evaluate EVERYTHING, 
recursively.


REXX is so much better but I want to ask Mike Cowlishaw what he was thinking in 
making uninitialized variables default to their own name.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Monday, March 27, 2023 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stop the ragging on COBOL please

Steve Thompson wrote, in part:
>Oh, I haven't had to deal with it for a while, but as I recall
>there is a function that CLIST can do that REXX couldn't (well
>back in the 1990s). I wonder if that is still true.

Perhaps easily parsing a typical TSO command:
verb arg1(value1) arg2(value2a,value2b)
? You can certainly do it in Rexx, but (and I've never written a CLIST in my
life) ISTR that CLIST makes it much easier.


--
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: [EXTERNAL] Re: Stop the ragging on COBOL please

[Seymour J Metz]

For that matter, there were a couple of things that EXEC had but EXEC2 didn't.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Monday, March 27, 2023 5:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Stop the ragging on COBOL please

Steve, no, no, no, no.  I'm not bashing Rexx or CLISTS or JCL.  I'm trying to 
do just the opposite.  Another poster (read:Michael) was (I'm presuming 
tongue-in-cheek) bashing CLISTs and I came to CLIST's defense by pointing out 
that it still does what it was intended to do, and it's probably not worth 
taking all the CLISTs sitting around your shop and rewriting them into Rexx or 
anything else.   :-)

Rex (with only 1 'x')

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, March 27, 2023 3:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

I fine it interesting that a person by the name of Rex is bashing CLIST. Yep

And yes, I do write JCL from scratch (answer the next post) because I right 
now, I'm working on migration code and need examples of certain constructs so I 
can make sure the migration code handles it correctly. Notice I did not say 
conversion (which I used to do DOS to MVS up to VSE-ESA to z/OS 1.2).

Oh, I haven't had to deal with it for a while, but as I recall there is a 
function that CLIST can do that REXX couldn't (well back in the 1990s). I 
wonder if that is still true.

Back to enjoying this thread.  :)

Steve Thompson


On 3/27/2023 4:17 PM, Pommier, Rex wrote:
> Using my most basic definition of a computer language - it's a list of 
> commands that can be saved to run it multiple times just by invoking the list 
> name, then both JCL and CLIST are languages (as is HTML), and both have 
> redeeming qualities.  How many of you (hypothetically) are running JCL 
> "decks" (and I used that term on purpose) that were first built on punch 
> cards with little to no change since they were first built?   JOL anybody?  I 
> would say a redeeming value of JCL is that there's nothing out there to 
> easily replace it.
>
> Same with CLISTs.  Can you rewrite the CLIST in a newer language?  Sure.  Is 
> it worth it?  Probably not.  Thus its longevity is probably a redeeming 
> quality.
>
> I'll go back to my corner now.  :-)
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Farley, Peter
> Sent: Monday, March 27, 2023 2:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Stop the ragging on COBOL please
>
>  Maybe . . . 😊
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Schmitt, Michael
> Sent: Monday, March 27, 2023 3:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Stop the ragging on COBOL please
>
> Is it OK to rag on languages with no redeeming qualities?   CLIST>
> --
>
> 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
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.u

Re: [EXTERNAL] Re: Stop the ragging on COBOL please

[Seymour J Metz]

What I hate are people who take one of my jobs, modify it, and bomplain about 
it when their changes don't work' "Which part of as-is don't you understand?"


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Monday, March 27, 2023 4:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Stop the ragging on COBOL please

Sorry, I'm going to "rag" on a language...  :-)  Admittedly I know next to 
nothing about it.  My exposure to it consists of reading an article where 
somebody took a 14 line JCL job and converted it to JOL and the JOL code ended 
up somewhere around 70+ lines plus comments to explain what the program was 
doing.   It appears that JOL now does a lot more than it used to do the last 
time I actually looked at it.  However, in JCL's defense, how many people 
actually build jobs (especially more complex multi-step jobs with IF/THEN, 
conditional execution, etc. from scratch?  Same as with a typical Cobol 
program, you take an existing program or JCL member and modify it to fit your 
needs.

How many people here use JCL (whether you like it or hate it) on a regular 
basis?   It's ubiquitous.

How many use JOL?

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Monday, March 27, 2023 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Stop the ragging on COBOL please

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fjol.oscar-jol.com%2Fabout-jol__%3B!!KjMRP1Ixj6eLE0Fj!vGAo09RSRyegMrA-_z-guiaGvhkdNPyxpge54CfqCQvUuwDKJzELN2R4OZtsAhm19487HzuIfdXymkh3cCArALgCDA%24&data=05%7C01%7Csmetz3%40gmu.edu%7Cc6e09dc387a445d6cec508db2f01ecba%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638155457553099336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2R9ROb0jlSx2Hdb%2BGMDO3NdZo8bxhgVq2w%2FQHCKSAkQ%3D&reserved=0
   JCL On Line

On Mon, Mar 27, 2023 at 2:43 PM Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
>  Maybe . . . 😊
>

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
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: A question or two on zOS issues

[Seymour J Metz]

Remember, the early worm gets the bird.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Schmitt, Michael [michael.schm...@dxc.com]
Sent: Monday, March 27, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

You're right, and fortunately we were saved from that pain because we 
procrastinated so long. And we skipped v5 completely.

We procrastinated because it took me a long time to rewrite our load module 
analyzer, as well as other PDS-dependencies.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, March 27, 2023 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don't know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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 lis

Re: A question or two on zOS issues

[Seymour J Metz]

AIF is your friend. That's especially true if you distribute source.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Thompson [ste...@wkyr.net]
Sent: Monday, March 27, 2023 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

"And, we're not gaining the full benefit because we can't allow
it to use vector packed instructions until all sites where the
code can run are on compatible hardware."

Welcome to the developer's heart burn.

Steve Thompson


On 3/27/2023 1:43 PM, Schmitt, Michael wrote:
> I didn't mention that because I consider it to be self-inflicted.
>
> We believed that we were consistently using correct signs, so we changed from 
> NUMPROC(MIG) to (PFD) in 2015.
>
> We're STILL running into issues with this, in fact I hit some just last week. 
> But not enough to give up and downgrade to NOPFD. Some of the bad signs are 
> originating from other languages.
>
> For binary, we've always compiled TRUNC(OPT).
>
>
> Some of our programmers believe that a numeric field with spaces should be 
> processed as zero, just because before it worked!
>
>
> Also, we do know that recompiling with COBOL z/OS 6 dramatically improves 
> performance, but we're not recompiling just to gain that, as recompiling is 
> always a risk. And, we're not gaining the full benefit because we can't allow 
> it to use vector packed instructions until all sites where the code can run 
> are on compatible hardware.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Thompson
> Sent: Monday, March 27, 2023 12:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: A question or two on zOS issues
>
> Glad to hear that someone followed all the rules so that,
> unannounced COBOL 5+ didn't cause you packed decimal problems
> with Truncation and the like. Or same thing with binary.
>
> Steve Thompson
>
> On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
>> The last time we mass-converted and recompiled our COBOL was from OS/VS 
>> COBOL to VS COBOL II in 1992. Since then we've migrated our 7 million lines 
>> of COBOL code...
>>
>> - 1998 Language Environment
>> - 2000 COBOL for MVS & VM
>> - 2003 COBOL for OS/390 & VM
>> - 2004 COBOL for z/OS & OS/390 3.2
>> - 2005  3.3
>> - 2006  3.4
>> - 2011  4.2
>> - 2020  6.2
>>
>> By doing... nothing.
>>
>> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
>> requirement for load modules.
>>
>>
>> So, in my experience, we don't need to know when our COBOL programs were 
>> last used. And we already have tools that give us the compile date and 
>> version, both from IBM and home grown.
>>
>> We still have a large number of programs that haven't been recompiled since 
>> the VS COBOL II migration. They coexist just fine.
>>
>> (You may have to *relink* to pick up the Language Environment bootstrap 
>> programs)
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Steve Pryor
>> Sent: Friday, March 24, 2023 1:39 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: A question or two on zOS issues
>>
>> There are a couple of pressing issues in z/OS that I'm sure many folks are 
>> aware of but about which there doesn't seem to be much being done. I'm 
>> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
>> talking about:
>>
>> 1.) migration to IBM's latest COBOL release, and
>>
>> 2.) the not-really-that-far-off issue of Year 2042
>>
>> I've been asked several times recently whether we (a z/OS ISV) should 
>> consider developing products to address these issues. Frankly, though, I 
>> live in an ivory tower and while I sometime *think* I know what 
>> installations problems and needs are, I'm usually surprised to find that 
>> reality is quite different. So I'd like to throw a couple of questions out 
>> to the list for comment:
>>
>> 1.) Would a reporting utility that determined which COBOL programs were 
>> executed (and which ones weren't), and what release and options they were 
>> compiled with be significantly helpful in a COBOL migration? What other 
>> features would be nice to have? Or is this a low priority for most 
>> installations, who are perhaps trying to justify keeping the mainframe alive 
>> and/or conducting business as usual, let alone doing a COBOL migration 
>> project?
>>
>> 2.) It's rather shocking that 2042 is so close and not much seems to be 
>> happening. We are one of the vendors that have a date-simulation utility, 
>> but we don’t know if data centers have any near-term plans for 2042. Would 
>> it be worthwhile to have a 2042 date-simulation product now, or is everyone 
>> going to cross their fingers and try to use a test LPAR once the operating 
>> system fully supports 2042 dates?
>>
>> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>>
>> Steve Pryor
>> CTO
>>

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

I think it was flippant Edsger W. Dijkstra  quote:

    “The use of COBOL cripples the mind; its teaching should, 
therefore, be regarded as a criminal offense.”


I use programming languages that I don't like all the time. C, in 
particular, I dislike a lot. That doesn't mean they're not useful.


No COBOL, no mainframe! Simple as that.

On 27/3/23 13:55, Farley, Peter wrote:

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:




In COBOL, for example, the following end up doing the same thing.


Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[David Crayford]

On 27/3/23 22:07, Bill Johnson wrote:

+1
About a year or so ago I posted about the number of lines of COBOL code in use 
worldwide and stated COBOL was going to be the language of choice for many 
decades to come. Estimates say 800 billion lines (and growing) in use today. As 
usual, I was attacked for my fact based opinion. 
https://www.zdnet.com/article/programming-languages-how-much-cobol-code-is-out-there-the-answer-might-surprise-you/


Facts! You've quoted an article from the internet!

"The study, commissioned by IT company Micro Focus and conducted by 
research and analysis firm Vanson Bourne"


Micro Focus is a vendor who hawks COBOL compilers and IDE's. It's a bit 
like McDonalds commissioning research on the health benefits of Big Mac's.







Sent from Yahoo Mail for iPhone


On Monday, March 27, 2023, 1:56 AM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:




In COBOL, for example, the following end up doing the same thing.


Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Bill Johnson]

You said internet banking was going to destroy large banks. How’s that working 
out?
Microfocus COBOL isn’t regular COBOL. And is a tiny fraction of the COBOL 
market.


Sent from Yahoo Mail for iPhone


On Monday, March 27, 2023, 11:26 PM, David Crayford  wrote:

On 27/3/23 22:07, Bill Johnson wrote:
> +1
> About a year or so ago I posted about the number of lines of COBOL code in 
> use worldwide and stated COBOL was going to be the language of choice for 
> many decades to come. Estimates say 800 billion lines (and growing) in use 
> today. As usual, I was attacked for my fact based opinion. 
> https://www.zdnet.com/article/programming-languages-how-much-cobol-code-is-out-there-the-answer-might-surprise-you/

Facts! You've quoted an article from the internet!

"The study, commissioned by IT company Micro Focus and conducted by 
research and analysis firm Vanson Bourne"

Micro Focus is a vendor who hawks COBOL compilers and IDE's. It's a bit 
like McDonalds commissioning research on the health benefits of Big Mac's.


>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, March 27, 2023, 1:56 AM, Farley, Peter 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> I am getting increasingly tired of snide or outright dismissive references to 
> COBOL and by extension to COBOL programmers.
>
> Programmers like me.
>
> Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
> SORT (at least as far as knowing and using JOIN's), SQL, JCL and various 
> other z/OS utilities, MetalC, and lately python and bash scripting.  I even 
> remember some of the PL/I and Fortran and Pascal I used in college and my 
> early employment days.  I even remember some SNOBOL, which I actually got to 
> use productively at a then-major NY bank very early in my career.
>
> COBOL pays my bills and keeps my employer operating successfully and 
> profitably.
>
> COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
> substances can, in fact, do that.  Intelligently devising business solutions 
> to business problems in ANY computer language does NOT rot the brain.
>
> It is not funny or acceptable to say so.  It never was.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Paul Gilmartin
> Sent: Sunday, March 26, 2023 8:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASM call by value
>
> On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:
>
> 
>
>> In COBOL, for example, the following end up doing the same thing.
>>
> Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
> brain.
>
> --
>
> 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




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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Tony Harminc]

On Mon, 27 Mar 2023 at 23:22, David Crayford  wrote:
>
> I think it was flippant Edsger W. Dijkstra  quote:
>
>  “The use of COBOL cripples the mind; its teaching should,
> therefore, be regarded as a criminal offense.”

Dijkstra wasn't hot on a lot of languages:

"If Fortran has been called an infantile disorder, PL/I must be
classified as a fatal disease."
-Edsger Dijkstra in Introduction to the Art of Computer Programming

Which prompted, or at least provided a juicy quote for, Ric Holt's
1972 paper "Teaching the Fatal Disease (or) Introductory Computer
Programming Using PL/I".

> I use programming languages that I don't like all the time. C, in
> particular, I dislike a lot. That doesn't mean they're not useful.

Whew! And I thought you were a C fanatic. Thanks for disabusing me of that.

Tony H.

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

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Wayne Bickerdike]

During my early training we were sent to learn Michael Jackson structured
programming. MJ quotes Dijkstra a lot, however, I didn't realise that he
was a PL/I hater. That was the first language I learned and still think it
was a masterpiece. I encountered COBOL after I left IBM and it happened to
be Microfocus COBOL, a very odd variant designed for Z80/CPM based
microcomputers. It barely did the job since it only supported a rudimentary
ISAM file system. A couple of years later as our software house was going
broke, I went for an interview for a DOS/VSE COBOL role. The customer was
doubtful that my MF COBOL would translate to a mainframe role. It didn't
prove to be a problem but oh how I wished it had been a PL/I shop.

Inverted programs in COBOL? Blech..

On Tue, Mar 28, 2023 at 4:27 PM Tony Harminc  wrote:

> On Mon, 27 Mar 2023 at 23:22, David Crayford  wrote:
> >
> > I think it was flippant Edsger W. Dijkstra  quote:
> >
> >  “The use of COBOL cripples the mind; its teaching should,
> > therefore, be regarded as a criminal offense.”
>
> Dijkstra wasn't hot on a lot of languages:
>
> "If Fortran has been called an infantile disorder, PL/I must be
> classified as a fatal disease."
> -Edsger Dijkstra in Introduction to the Art of Computer Programming
>
> Which prompted, or at least provided a juicy quote for, Ric Holt's
> 1972 paper "Teaching the Fatal Disease (or) Introductory Computer
> Programming Using PL/I".
>
> > I use programming languages that I don't like all the time. C, in
> > particular, I dislike a lot. That doesn't mean they're not useful.
>
> Whew! And I thought you were a C fanatic. Thanks for disabusing me of that.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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