Re: View ASCII Command inUSS

[Hank Oerlemans]

For better or worse BROWSE is a different beastie.

https://www.ibm.com/docs/en/zos/2.5.0?topic=commands-displaycontrol-display

DISPLAY ASCII is what you want but it does't deal with the CR, LF, NL etc
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

View ASCII Command inUSS

[Michael Babcock]

Anyone else find this annoying?   When viewing an ASCII file in USS using
ISPF 3.4 and placing a VA command next to the file, if the file is too big,
it substitutes browse but defaults to EBCDIC?It should substitute
“browse ASCII” but I know of no such command.

RFE?  Or am I missing something?
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: How to monitor all red messages

[Steve Horein]

Something like this should do what you want:
IF LINEPRES(2 1) = '2'
THEN ...
https://www.ibm.com/docs/en/z-netview/6.2.0?topic=table-condition-items (a
description of LINEPRES is in there).


To add that to SA Policy, you would need to use "TOP" message placement
(AC) in addition to tweaking the override (AO):
https://www.ibm.com/docs/en/z-system-automation/4.2.0?topic=definitions-specifying-entry-conditions

https://www.ibm.com/docs/en/z-system-automation/4.2.0?topic=definitions-specifying-override

On Wed, Mar 30, 2022 at 8:19 PM Jason Cai  wrote:

> If we want to monitor a special message, we could specify the message-id
> in SA. Could you tell us how to define all red messages in SA?
>
> Any suggestions are highly appreciated!
>
> Thanks a lot!
>
> --
> 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

How to monitor all red messages

[Jason Cai]

If we want to monitor a special message, we could specify the message-id in SA. 
Could you tell us how to define all red messages in SA?

Any suggestions are highly appreciated!

Thanks a lot!

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

Re: Specialized list versus wide audience

[Grant Taylor]

On 3/30/22 5:33 PM, Rich Smrcina wrote:
Exactly. Some of us are here to learn, not listen to politics and 
ancient history.


I believe there is value in the history.  Especially the "why" and "how" 
to various questions.


If listserv supports it, I'd advocate for topics on a singular mailing 
list.  --  I've done this with Mailman a number of times.  Well, more 
precisely, Mailman and mail filters that skimmed for a large list of 
keywords to specify the topics for a message (if not already done so).




--
Grant. . . .
unix || die

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

Re: Specialized list versus wide audience

[Gibney, Dave]

Standard purpose of the delete key

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Rich Smrcina
> Sent: Wednesday, March 30, 2022 4:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Specialized list versus wide audience
> 
> Exactly. Some of us are here to learn, not listen to politics and ancient 
> history.
> 
> Rich Smrcina
> 
> 
> > On Mar 30, 2022, at 7:26 PM, Gord Tomlin
>  wrote:
> >
> > On 2022-03-30 17:58 PM, Paul Gilmartin wrote:
> >> Should there be a list for rants, insults, pedantry, advocacy, and politics
> > Yes, please! The signal to noise ratio on IBM-MAIN is horrible.
> >
> > --
> >
> > --
> >
> > Regards, Gord Tomlin
> > Action Software International
> > (a division of Mazda Computer Corporation)
> > Tel: (905) 470-7113, Fax: (905) 470-6507
> > Support:
> https://urldefense.com/v3/__https://actionsoftware.com/support/__;!!Jm
> PEgBY0HMszNaDT!9y3WieRcgvPH0SDfX0-
> wzvNUFaSfkyzDKAsH9WMNN7f0I6k0V4A2oIdNfJ9dLw$
> >
> > --
> > 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: Specialized list versus wide audience

[Rich Smrcina]

Exactly. Some of us are here to learn, not listen to politics and ancient 
history.

Rich Smrcina


> On Mar 30, 2022, at 7:26 PM, Gord Tomlin  
> wrote:
> 
> On 2022-03-30 17:58 PM, Paul Gilmartin wrote:
>> Should there be a list for rants, insults, pedantry, advocacy, and politics
> Yes, please! The signal to noise ratio on IBM-MAIN is horrible.
> 
> -- 
> 
> --
> 
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/
> 
> --
> 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: Specialized list versus wide audience

[Gord Tomlin]

On 2022-03-30 17:58 PM, Paul Gilmartin wrote:

Should there be a list for rants, insults, pedantry, advocacy, and politics

Yes, please! The signal to noise ratio on IBM-MAIN is horrible.

--

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: Specialized list versus wide audience

[Paul Gilmartin]

On Wed, 30 Mar 2022 20:44:33 +, Seymour J Metz  wrote:

>Yes, I consider both specialized lists, and I consider it legitimate to 
>cross-post messages to those lists and IBM-MAIN. My questions would be "Am I 
>more likely to get a timely and useful response on IBM-MAIN or LINUX-390?", 
>"Am I more likely to get a timely and useful response on IBM-MAIN or IBMVM?" 
>and "Will cross-posting increase the odds significantly?".
> 
Wouldn't it be nice to be able to cross-post a reply cross-posted
message with no need to copy-paste addresses?

Should there be a list for rants, insults, pedantry, advocacy, and politics,
or is IBM-MAIN sufficiently weakly moderated too meet the need?

-- 
gil

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

Re: Specialized list versus wide audience

[Seymour J Metz]

Yes, I consider both specialized lists, and I consider it legitimate to 
cross-post messages to those lists and IBM-MAIN. My questions would be "Am I 
more likely to get a timely and useful response on IBM-MAIN or LINUX-390?", "Am 
I more likely to get a timely and useful response on IBM-MAIN or IBMVM?" and 
"Will cross-posting increase the odds significantly?".


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Dave Jones [d...@vsoft-software.com]
Sent: Wednesday, March 30, 2022 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Specialized list versus wide audience

Well, us VM-ers and zLinux folks have two very active lists, here;
IBM VM List 
and here:
Linux on 390 Port ,
You might consider them specialized lists.
DJ

--
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: Specialized list versus wide audience

[Paul Gilmartin]

On Wed, 30 Mar 2022 20:12:04 +, Seymour J Metz wrote:

>Periodically, someone will post an on topic question here and be directed to a 
>more specialized list for, e.g., assembler, ISPF, JES2, TSO. Does anybody have 
>a feel for the relative value of more specialized respondents versus more 
>responents?
>
Sometimes a hard question.

o Should a question about RISBG go to ASSEMBLER-LIST
  because it's an assembler mnemonic (software, even though
  those mnemonics appear in the PoOps) or here?

o MVS-OE is languishing, but one very valuable IBM emplloyee
  appears to monitor it closely.  (Did you argue against the
  initial proposal of MVS-OE?)

o I receive periodic "Subscription Probes" for VM-UTIL, which
  otherwise appears to be defunct.

o Much ISPF traffic seems to come to IBM-MAIN.

-- 
gil

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

Re: Specialized list versus wide audience

[Dave Jones]

Well, us VM-ers and zLinux folks have two very active lists, here;
IBM VM List 
and here:
Linux on 390 Port ,
You might consider them specialized lists.
DJ

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

Specialized list versus wide audience

[Seymour J Metz]

Periodically, someone will post an on topic question here and be directed to a 
more specialized list for, e.g., assembler, ISPF, JES2, TSO. Does anybody have 
a feel for the relative value of more specialized respondents versus more 
responents?

Note: whether there is still an active specialized list or not, it is always 
legitimate to post IBM mainframe questions here. I'm simply asking about 
efficacy.



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

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

Re: AFP confusion

[Seymour J Metz]

>From that, BCMDEL itself requires authorization, not just LISTBC.


--
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: Wednesday, March 30, 2022 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

Here's the code snippet with the call (LINK), starting at the MODESET that 
caused the 047 abend.

KZ   MODESET KEY=ZERO
BATCHCNT MVC   PSCBUSER(7),NEWID   SET USERID TO PARAMETER VALUE
 LAR8,1(,R8)   BUMP REG BACK TO WHERE IT WAS
 STC   R8,PSCBUSRL PUT USERID LENGTH INTO PSCB
 MVC   0(4,R11),=A(BPARM)  MOVE PARM POINTER TO CPPL.
 LRR1,R11  POINT R1 TO CPPL.
 LINK  EP=LISTBC   DO LISTBC COMMAND.
 MVC   PSCBUSER(7),OLDID   RESTORE OLD USERID TO PSCB
 MVC   PSCBUSRL(1),OLDPSCBL  RESTORE SAVED USERID LENGTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, March 30, 2022 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

How does it call LISTBC?


--
Shmuel (Seymour J.) Metz
https://secure-web.cisco.com/1vlBNMj33k8Ocddx7M2tZDQI_Mtvqm1IvQlyQ5OO9foQoBqGEhSPi8NsagDmt-Ub5vbqLvv4vuAbKccLImzNWKtCv78I5Gq7-1wD1rEH2eWZZreGe97oVuUTQgSYUT9tFtZhLTg9ham1q17jn-9xuejxtRQ8dBYnSITQgO_rhyBdEWCxwmAh7_Ejyj3FjGjnbA_ZrK9KH6tEaFQwBMjseXfM9wcFmGRwBXdfCbCihQwCVvttm1y-86tkqcZSWF8vrOxCXxk7RKYDsrFToWw81PF2OfzcjnjMOPvIexUreD-_-KxYPqU-aD0wROo8yCKmYxFNwLzBtVa-utgjRJTlKvcajHixzKfV_dNBvliMj7TorAmefyCsuSFkUuJbJgZNa0MyRoPwhgF8qI74vliaDnYCyrxw2pjEEIBQr4gzxS_mjXt89DkxDLClhevl9y7d-rOw6OybTV1OJYLsg38mcTg/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F%2Asmetz3__%3Bfg%21%21KjMRP1Ixj6eLE0Fj%2160bZRdMVQPaLWj0zGktKKr0LLnm8_fZ3P3OocoySdJ09B-hSJ5_gpvMWVL9flvKaSg%24


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Wednesday, March 30, 2022 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

Thanks, Carmen.

I forgot to mention that part.  My library is the only one in the STEPLIB.   
And the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion 
of IKJTSOxx.  Same on the working LPARs.  If I run the LISTBC command by itself 
it runs fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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

Re: PL/I

[Seymour J Metz]

That's how I view it. But then I'm paranoid about such matters. There are 
others who don't agree.

Cheap, fast or correct: pick one.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Wednesday, March 30, 2022 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

On Wed, 30 Mar 2022 at 12:26, Seymour J Metz  wrote:
>
> Yes, range checking carries a performance penalty, and there have been 
> arguments in the past about performance versus safety. I'm in the camp that 
> believes that they should be enabled in any program where incorrect output 
> would cause a problem or where there are security issues.

So basically you don't need checking if it doesn't matter what your
program does...

Tony H.

--
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: AFP confusion

[Pommier, Rex]

Here's the code snippet with the call (LINK), starting at the MODESET that 
caused the 047 abend.

KZ   MODESET KEY=ZERO   
BATCHCNT MVC   PSCBUSER(7),NEWID   SET USERID TO PARAMETER VALUE
 LAR8,1(,R8)   BUMP REG BACK TO WHERE IT WAS
 STC   R8,PSCBUSRL PUT USERID LENGTH INTO PSCB  
 MVC   0(4,R11),=A(BPARM)  MOVE PARM POINTER TO CPPL.   
 LRR1,R11  POINT R1 TO CPPL.
 LINK  EP=LISTBC   DO LISTBC COMMAND.   
 MVC   PSCBUSER(7),OLDID   RESTORE OLD USERID TO PSCB   
 MVC   PSCBUSRL(1),OLDPSCBL  RESTORE SAVED USERID LENGTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, March 30, 2022 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

How does it call LISTBC?


--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1Ixj6eLE0Fj!60bZRdMVQPaLWj0zGktKKr0LLnm8_fZ3P3OocoySdJ09B-hSJ5_gpvMWVL9flvKaSg$
 


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Wednesday, March 30, 2022 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

Thanks, Carmen.

I forgot to mention that part.  My library is the only one in the STEPLIB.   
And the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion 
of IKJTSOxx.  Same on the working LPARs.  If I run the LISTBC command by itself 
it runs fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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

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

Re: AFP confusion

[Seymour J Metz]

How does it call LISTBC?


--
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: Wednesday, March 30, 2022 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

Thanks, Carmen.

I forgot to mention that part.  My library is the only one in the STEPLIB.   
And the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion 
of IKJTSOxx.  Same on the working LPARs.  If I run the LISTBC command by itself 
it runs fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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

--
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: [EXTERNAL] Re: APF (not AFP) confusion

[Pommier, Rex]

And I just realized that I accidentally said AFP instead of APF in the subject 
line.  At least I got it right in the body of the e-mail.  D'oh.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 2:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

oh, ok got ya! thanks for the update Rex

Carmen

On 3/30/2022 2:28 PM, Pommier, Rex wrote:
> Actually I think it is the same thing.  BCMDEL calls LISTBC to do the actual 
> deletes.  Standalone LISTBC allows me to delete my own records from BRODCAST. 
>  BCMDEL changes users as needed to be able to call LISTBC to delete records 
> for all the users it finds.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Carmen Vitullo
> Sent: Wednesday, March 30, 2022 2:09 PM To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: AFP confusion
>
> ok, this is prolly a different iteration of the BMCUTIL program I was using 
> long ago, it had nothing to do with LISTBC.
> as far as APF, If I read Rex's post correctly he did APF the loadlib and is 
> not relying on link list from Rex 
>The program is linked AC=1 and is residing in 2 APF authorized libraries.
>   One of them is my private library where I initially assembled the code 
> which I added to the  APF list and verified it is there.
> 
> I myself have APF'd a library for testing and steplib'd to a program 
> for product testing with the expected results Carmen Vitullo
>
> 
>
> -Original Message-
>
> From: Rex
> To: IBM-MAIN
> Date: Wednesday, 30 March 2022 1:35 PM CDT
> Subject: Re: AFP confusion
>
> Thanks, Carmen.
>
> I forgot to mention that part. My library is the only one in the STEPLIB. And 
> the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion 
> of IKJTSOxx. Same on the working LPARs. If I run the LISTBC command by itself 
> it runs fine.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Carmen Vitullo
> Sent: Wednesday, March 30, 2022 1:29 PM To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: AFP confusion
>
> if steplib I'd still check and make sure any concatenated libraries 
> are also APF'd IIRC the Broadcast program also requires an entry in 
> the IKJTSOxx member, AUTHPGM section
>
> Carmen Vitullo
>
>
>
> -Original Message-
>
> From: Rex
> To: IBM-MAIN
> Date: Wednesday, 30 March 2022 1:22 PM CDT
> Subject: AFP confusion
>
> Hello list,
>
> I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
> Golob's Broadcast dataset maintenance CBT package). It's running successfully 
> on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
> program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
> them is my private library where I initially assembled the code which I added 
> to the APF list and verified it is there. I tried accessing this thru a 
> STEPLIB. The other is a general library where several of our third party 
> products reside, others of which need and have APF authorization through this 
> library. This is accessed through the linklist and I did perform an LLA 
> refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
> running on other LPARs.
>
> Here's the line of code it is choking on:
>
> KZ MODESET KEY=ZERO
>
> I can copy the load module to one of the other LPARs and it runs fine there 
> so the module appears correct. Other APF programs are running fine from the 
> library on this LPAR where I copied the code so the library appears correct. 
> Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as 
> well. It's looking like it has to be something in the environment but we 
> can't determine what.
>
> TIA,
>
> Rex
>
> --
> 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 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 

Re: AFP confusion

[Seymour J Metz]

They are if every library in the concatenation is APF authorized.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Wednesday, March 30, 2022 2:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.3.0%3Ftopic%3Dfunctions-apf-authorized-librariesdata=04%7C01%7Csmetz3%40gmu.edu%7C294518b00feb40f579c008da127f6a7d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637842635705121437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=sav7hEQuRDQQNZNtMtP88%2Bxl1kldbJiqeHwSOCzdxmg%3Dreserved=0

Libraries accessed through STEPLIB/JOBLIB are not APF authorized.

On Wed, Mar 30, 2022 at 7:35 PM Pommier, Rex  wrote:
>
> Thanks, Carmen.
>
> I forgot to mention that part.  My library is the only one in the STEPLIB.   
> And the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD 
> portion of IKJTSOxx.  Same on the working LPARs.  If I run the LISTBC command 
> by itself it runs fine.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Carmen Vitullo
> Sent: Wednesday, March 30, 2022 1:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: AFP confusion
>
> if steplib I'd still check and make sure any concatenated libraries are also 
> APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx 
> member, AUTHPGM section
>
> Carmen Vitullo
>
>
>
> -Original Message-
>
> From: Rex 
> To: IBM-MAIN 
> Date: Wednesday, 30 March 2022 1:22 PM CDT
> Subject: AFP confusion
>
> Hello list,
>
> I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
> Golob's Broadcast dataset maintenance CBT package). It's running successfully 
> on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
> program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
> them is my private library where I initially assembled the code which I added 
> to the APF list and verified it is there. I tried accessing this thru a 
> STEPLIB. The other is a general library where several of our third party 
> products reside, others of which need and have APF authorization through this 
> library. This is accessed through the linklist and I did perform an LLA 
> refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
> running on other LPARs.
>
> Here's the line of code it is choking on:
>
> KZ MODESET KEY=ZERO
>
> I can copy the load module to one of the other LPARs and it runs fine there 
> so the module appears correct. Other APF programs are running fine from the 
> library on this LPAR where I copied the code so the library appears correct. 
> Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as 
> well. It's looking like it has to be something in the environment but we 
> can't determine what.
>
> TIA,
>
> Rex
>
> --
> 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
>
> --
> 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 

Re: AFP confusion

[Seymour J Metz]

The devil is in the details.

If any library in the [JOB|STEP]LIB is not APF authorized then the jobstep is 
not APF authorized.

AC(1) is only relevant for a program attached by a privileged jobstep task with 
RSAPF=YES:
Initiator
TMP

Authorized calls and commands, in addition to requiring AC(1) from an 
authorized concatenation, must also be defined to TSO as authorized. Do a 
PARMLIB LIST(ALL) to see what is defined where and whether it is the same in 
each LPAR.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Carmen Vitullo [cvitu...@hughes.net]
Sent: Wednesday, March 30, 2022 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

ok, this is prolly a different iteration of the BMCUTIL program I was using 
long ago, it had nothing to do with LISTBC.
as far as APF, If I read Rex's post correctly he did APF the loadlib and is not 
relying on link list
from Rex

  The program is linked AC=1 and is residing in 2 APF authorized libraries.
 One of them is my private library where I initially assembled the code which I 
added to the
 APF list and verified it is there.

I myself have APF'd a library for testing and steplib'd to a program for
product testing with the expected results
Carmen Vitullo



-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: AFP confusion

Thanks, Carmen.

I forgot to mention that part. My library is the only one in the STEPLIB. And 
the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion of 
IKJTSOxx. Same on the working LPARs. If I run the LISTBC command by itself it 
runs fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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

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

Re: [EXTERNAL] Re: AFP confusion

[Pommier, Rex]

Hi David,

Actually Jay is correct.  Jay's comment was in light of a library being 
accessed via JOBLIB/STEPLIB.  In that case it doesn't matter if the library is 
in the linklist.  It must be in the APF list to be authorized.  You are correct 
with the LNKAUTH if the library is accessed via the linklist.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Wednesday, March 30, 2022 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

Hi Jay,
If you code LNKAUTH=APFTAB in IEASYSxx, then you're correct.
If you code LNKAUTH=LNKLST, then your assertion is incorrect.

Regards,
David

On 2022-03-30 15:01, Jay Maynard wrote:
> Libraries accessed through STEPLIB/JOBLIB aren't APF-authorized simply 
> by virtue of being listed on the link list. THey can be authorized by 
> being specifically listed in the APF list, though. This has been the case 
> forever.
>
> On Wed, Mar 30, 2022 at 1:59 PM Mike Schwab  wrote:
>
>> https://urldefense.com/v3/__https://nam12.safelinks.protection.outloo
>> k.com/?url=https*3A*2F*2Fwww.ibm.com*2Fdocs*2Fen*2Fzos*2F2.3.0*3Ftopi
>> c*3Dfunctions-apf-authorized-librariesdata=04*7C01*7C*7C5f168b8e
>> 3f904490675208da127fc9b0*7C84df9e7fe9f640afb435*7C1*7C0*7
>> C637842637369156999*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
>> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000sdata=seQJYDCvz6
>> Z85GiUfUEjKAfvK*2BLwettVtqWOoaUl1rY*3Dreserved=0__;JSUlJSUlJSUlJ
>> SUlJSUlJSUlJSUlJQ!!KjMRP1Ixj6eLE0Fj!9E1JNwbkcLPARYLG3TTPrNWPO3r5jG3kZ
>> HZVbF5dd4QExH5MPFcPRMv4UaDG4rGi8w$
>>
>> Libraries accessed through STEPLIB/JOBLIB are not APF authorized.
>>
>> On Wed, Mar 30, 2022 at 7:35 PM Pommier, Rex 
>> 
>> wrote:
>>> Thanks, Carmen.
>>>
>>> I forgot to mention that part.  My library is the only one in the
>> STEPLIB.   And the LISTBC part of TSO that BCMDEL calls is actually in the
>> AUTHCMD portion of IKJTSOxx.  Same on the working LPARs.  If I run 
>> the LISTBC command by itself it runs fine.
>>> Rex
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On
>> Behalf Of Carmen Vitullo
>>> Sent: Wednesday, March 30, 2022 1:29 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: [EXTERNAL] Re: AFP confusion
>>>
>>> if steplib I'd still check and make sure any concatenated libraries 
>>> are
>> also APF'd IIRC the Broadcast program also requires an entry in the 
>> IKJTSOxx member, AUTHPGM section
>>> Carmen Vitullo
>>>
>>>
>>>
>>> -Original Message-
>>>
>>> From: Rex 
>>> To: IBM-MAIN 
>>> Date: Wednesday, 30 March 2022 1:22 PM CDT
>>> Subject: AFP confusion
>>>
>>> Hello list,
>>>
>>> I'm stumped on this one. I have a small assembler program (BCMDEL 
>>> from
>> Sam Golob's Broadcast dataset maintenance CBT package). It's running 
>> successfully on 2 of my LPARs but the third is giving me a 047 abend 
>> trying to run. The program is linked AC=1 and is residing in 2 APF 
>> authorized libraries. One of them is my private library where I 
>> initially assembled the code which I added to the APF list and 
>> verified it is there. I tried accessing this thru a STEPLIB. The 
>> other is a general library where several of our third party products 
>> reside, others of which need and have APF authorization through this 
>> library. This is accessed through the linklist and I did perform an 
>> LLA refresh. The program is a TSO-in-batch program if that matters. 
>> Identical JCL running on other LPARs.
>>> Here's the line of code it is choking on:
>>>
>>> KZ MODESET KEY=ZERO
>>>
>>> I can copy the load module to one of the other LPARs and it runs 
>>> fine
>> there so the module appears correct. Other APF programs are running 
>> fine from the library on this LPAR where I copied the code so the 
>> library appears correct. Any thoughts as to what I've overlooked? I 
>> have my 2 coworkers stumped as well. It's looking like it has to be 
>> something in the environment but we can't determine what.
>>> TIA,
>>>
>>> Rex
>>>
>>> 
>>> -- 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 
>>> 

Re: PL/I

[Tony Harminc]

On Wed, 30 Mar 2022 at 12:26, Seymour J Metz  wrote:
>
> Yes, range checking carries a performance penalty, and there have been 
> arguments in the past about performance versus safety. I'm in the camp that 
> believes that they should be enabled in any program where incorrect output 
> would cause a problem or where there are security issues.

So basically you don't need checking if it doesn't matter what your
program does...

Tony H.

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

Re: AFP confusion

[Carmen Vitullo]

oh, ok got ya! thanks for the update Rex

Carmen

On 3/30/2022 2:28 PM, Pommier, Rex wrote:

Actually I think it is the same thing.  BCMDEL calls LISTBC to do the actual 
deletes.  Standalone LISTBC allows me to delete my own records from BRODCAST.  
BCMDEL changes users as needed to be able to call LISTBC to delete records for 
all the users it finds.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 2:09 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

ok, this is prolly a different iteration of the BMCUTIL program I was using 
long ago, it had nothing to do with LISTBC.
as far as APF, If I read Rex's post correctly he did APF the loadlib and is not 
relying on link list from Rex 
   The program is linked AC=1 and is residing in 2 APF authorized libraries.
  One of them is my private library where I initially assembled the code which 
I added to the  APF list and verified it is there.

I myself have APF'd a library for testing and steplib'd to a program for
product testing with the expected results
Carmen Vitullo




-Original Message-

From: Rex
To: IBM-MAIN
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: AFP confusion

Thanks, Carmen.

I forgot to mention that part. My library is the only one in the STEPLIB. And 
the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion of 
IKJTSOxx. Same on the working LPARs. If I run the LISTBC command by itself it 
runs fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section
   
Carmen Vitullo




-Original Message-

From: Rex
To: IBM-MAIN
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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

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

Re: AFP confusion

[Pommier, Rex]

Actually I think it is the same thing.  BCMDEL calls LISTBC to do the actual 
deletes.  Standalone LISTBC allows me to delete my own records from BRODCAST.  
BCMDEL changes users as needed to be able to call LISTBC to delete records for 
all the users it finds.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

ok, this is prolly a different iteration of the BMCUTIL program I was using 
long ago, it had nothing to do with LISTBC. 
as far as APF, If I read Rex's post correctly he did APF the loadlib and is not 
relying on link list from Rex 
  The program is linked AC=1 and is residing in 2 APF authorized libraries.
 One of them is my private library where I initially assembled the code which I 
added to the  APF list and verified it is there. 

I myself have APF'd a library for testing and steplib'd to a program for 
product testing with the expected results 
Carmen Vitullo 

   

-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: AFP confusion

Thanks, Carmen. 

I forgot to mention that part. My library is the only one in the STEPLIB. And 
the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion of 
IKJTSOxx. Same on the working LPARs. If I run the LISTBC command by itself it 
runs fine. 

Rex 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion 

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section 
  
Carmen Vitullo 



-Original Message- 

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion 

Hello list, 

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs. 

Here's the line of code it is choking on: 

KZ MODESET KEY=ZERO 

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what. 

TIA, 

Rex 

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

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

Re: APF (not AFP) confusion

[Carmen Vitullo]

Glad you found it and I could help

Carmen

On 3/30/2022 2:25 PM, Pommier, Rex wrote:

Yaay Carmen!

That was it.  Somewhere before my time somebody had added BCMDEL to IKJTSO00 on 
one of my LPARs but not the other one.  I actually added it to the AUTHCMD 
section which is where it resides on the other LPAR and the command now works.  
If it was documented in the package, I sure didn't find it.

Thank you all, especially Carmen since his response was the first I saw with 
the answer.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:48 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: APF (not AFP) confusion

I've used the BCMDEL which is part of the BCMUTIL to manage broadcast messages, 
IIRC part of the instructions, are to place BCMDEL, maybe some other programs 
in the AUTHPGM entry in IKJTSOxx.
been a long time since I've used it and I don't have the utility any longer 
that maybe one of Rex's problems
   

Carmen Vitullo





-Original Message-

From: Robert<01c91f408b9e-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: APF (not AFP) confusion

I don’t have it in AUTHPGM but do have entries in SEND. YMMV:

SEND /* SEND COMMAND DEFAULTS */ +
OPERSEND(ON) /* */ +
USERSEND(ON) /* */ +
SAVE(ON) /* */ +
CHKBROD(ON) /* */ +
USEBROD(OFF) /* USER BRODCAST */ +
MSGPROTECT(OFF) /* NO EXTRA SECURITY REQUIRED*/ +
SYSPLEXSHR(ON) /* BRODCAST SHARED IN SYSPLEX*/ +
OPERSEWAIT(OFF) /* DONT WAIT FOR OPER SEND RESP. */ +
LOGNAME(ULOG.BRODCAST) /* userid.BRODCAST */ + BROADCAST 
(DATASET(SYS1.BRODCAST))

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 2:29 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex mailto:rpomm...@sfgmembers.com>>
To: IBM-MAIN mailto:IBM-MAIN@LISTSERV.UA.EDU>>
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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

Re: APF (not AFP) confusion

[Pommier, Rex]

Yaay Carmen!  

That was it.  Somewhere before my time somebody had added BCMDEL to IKJTSO00 on 
one of my LPARs but not the other one.  I actually added it to the AUTHCMD 
section which is where it resides on the other LPAR and the command now works.  
If it was documented in the package, I sure didn't find it.  

Thank you all, especially Carmen since his response was the first I saw with 
the answer.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: APF (not AFP) confusion

I've used the BCMDEL which is part of the BCMUTIL to manage broadcast messages, 
IIRC part of the instructions, are to place BCMDEL, maybe some other programs 
in the AUTHPGM entry in IKJTSOxx. 
been a long time since I've used it and I don't have the utility any longer 
that maybe one of Rex's problems 
  
   
Carmen Vitullo 

   

-Original Message-

From: Robert <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: APF (not AFP) confusion

I don’t have it in AUTHPGM but do have entries in SEND. YMMV: 

SEND /* SEND COMMAND DEFAULTS */ +
OPERSEND(ON) /* */ +
USERSEND(ON) /* */ +
SAVE(ON) /* */ +
CHKBROD(ON) /* */ +
USEBROD(OFF) /* USER BRODCAST */ +
MSGPROTECT(OFF) /* NO EXTRA SECURITY REQUIRED*/ +
SYSPLEXSHR(ON) /* BRODCAST SHARED IN SYSPLEX*/ +
OPERSEWAIT(OFF) /* DONT WAIT FOR OPER SEND RESP. */ +
LOGNAME(ULOG.BRODCAST) /* userid.BRODCAST */ + BROADCAST 
(DATASET(SYS1.BRODCAST)) 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 2:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion 

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section 

Carmen Vitullo 



-Original Message- 

From: Rex mailto:rpomm...@sfgmembers.com>>
To: IBM-MAIN mailto:IBM-MAIN@LISTSERV.UA.EDU>>
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion 

Hello list, 

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs. 

Here's the line of code it is choking on: 

KZ MODESET KEY=ZERO 

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what. 

TIA, 

Rex 

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


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

Re: AFP confusion

[David Spiegel]

Hi Jay,
If you code LNKAUTH=APFTAB in IEASYSxx, then you're correct.
If you code LNKAUTH=LNKLST, then your assertion is incorrect.

Regards,
David

On 2022-03-30 15:01, Jay Maynard wrote:

Libraries accessed through STEPLIB/JOBLIB aren't APF-authorized simply by
virtue of being listed on the link list. THey can be authorized by being
specifically listed in the APF list, though. This has been the case forever.

On Wed, Mar 30, 2022 at 1:59 PM Mike Schwab  wrote:


https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.3.0%3Ftopic%3Dfunctions-apf-authorized-librariesdata=04%7C01%7C%7C5f168b8e3f904490675208da127fc9b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637842637369156999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=seQJYDCvz6Z85GiUfUEjKAfvK%2BLwettVtqWOoaUl1rY%3Dreserved=0

Libraries accessed through STEPLIB/JOBLIB are not APF authorized.

On Wed, Mar 30, 2022 at 7:35 PM Pommier, Rex 
wrote:

Thanks, Carmen.

I forgot to mention that part.  My library is the only one in the

STEPLIB.   And the LISTBC part of TSO that BCMDEL calls is actually in the
AUTHCMD portion of IKJTSOxx.  Same on the working LPARs.  If I run the
LISTBC command by itself it runs fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On

Behalf Of Carmen Vitullo

Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are

also APF'd IIRC the Broadcast program also requires an entry in the
IKJTSOxx member, AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from

Sam Golob's Broadcast dataset maintenance CBT package). It's running
successfully on 2 of my LPARs but the third is giving me a 047 abend trying
to run. The program is linked AC=1 and is residing in 2 APF authorized
libraries. One of them is my private library where I initially assembled
the code which I added to the APF list and verified it is there. I tried
accessing this thru a STEPLIB. The other is a general library where several
of our third party products reside, others of which need and have APF
authorization through this library. This is accessed through the linklist
and I did perform an LLA refresh. The program is a TSO-in-batch program if
that matters. Identical JCL running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine

there so the module appears correct. Other APF programs are running fine
from the library on this LPAR where I copied the code so the library
appears correct. Any thoughts as to what I've overlooked? I have my 2
coworkers stumped as well. It's looking like it has to be something in the
environment but we can't determine what.

TIA,

Rex

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

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

Re: AFP confusion

[Carmen Vitullo]

ok, this is prolly a different iteration of the BMCUTIL program I was using 
long ago, it had nothing to do with LISTBC. 
as far as APF, If I read Rex's post correctly he did APF the loadlib and is not 
relying on link list 
from Rex  
 
  The program is linked AC=1 and is residing in 2 APF authorized libraries.
 One of them is my private library where I initially assembled the code which I 
added to the
 APF list and verified it is there. 
 
I myself have APF'd a library for testing and steplib'd to a program for 
product testing with the expected results 
Carmen Vitullo 

   

-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: AFP confusion

Thanks, Carmen. 

I forgot to mention that part. My library is the only one in the STEPLIB. And 
the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion of 
IKJTSOxx. Same on the working LPARs. If I run the LISTBC command by itself it 
runs fine. 

Rex 

-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo 
Sent: Wednesday, March 30, 2022 1:29 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: AFP confusion 

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section 
  
Carmen Vitullo 



-Original Message- 

From: Rex  
To: IBM-MAIN  
Date: Wednesday, 30 March 2022 1:22 PM CDT 
Subject: AFP confusion 

Hello list, 

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs. 

Here's the line of code it is choking on: 

KZ MODESET KEY=ZERO 

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what. 

TIA, 

Rex 

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

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

Re: AFP confusion

[Jay Maynard]

Libraries accessed through STEPLIB/JOBLIB aren't APF-authorized simply by
virtue of being listed on the link list. THey can be authorized by being
specifically listed in the APF list, though. This has been the case forever.

On Wed, Mar 30, 2022 at 1:59 PM Mike Schwab  wrote:

>
> https://www.ibm.com/docs/en/zos/2.3.0?topic=functions-apf-authorized-libraries
>
> Libraries accessed through STEPLIB/JOBLIB are not APF authorized.
>
> On Wed, Mar 30, 2022 at 7:35 PM Pommier, Rex 
> wrote:
> >
> > Thanks, Carmen.
> >
> > I forgot to mention that part.  My library is the only one in the
> STEPLIB.   And the LISTBC part of TSO that BCMDEL calls is actually in the
> AUTHCMD portion of IKJTSOxx.  Same on the working LPARs.  If I run the
> LISTBC command by itself it runs fine.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Carmen Vitullo
> > Sent: Wednesday, March 30, 2022 1:29 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: AFP confusion
> >
> > if steplib I'd still check and make sure any concatenated libraries are
> also APF'd IIRC the Broadcast program also requires an entry in the
> IKJTSOxx member, AUTHPGM section
> >
> > Carmen Vitullo
> >
> >
> >
> > -Original Message-
> >
> > From: Rex 
> > To: IBM-MAIN 
> > Date: Wednesday, 30 March 2022 1:22 PM CDT
> > Subject: AFP confusion
> >
> > Hello list,
> >
> > I'm stumped on this one. I have a small assembler program (BCMDEL from
> Sam Golob's Broadcast dataset maintenance CBT package). It's running
> successfully on 2 of my LPARs but the third is giving me a 047 abend trying
> to run. The program is linked AC=1 and is residing in 2 APF authorized
> libraries. One of them is my private library where I initially assembled
> the code which I added to the APF list and verified it is there. I tried
> accessing this thru a STEPLIB. The other is a general library where several
> of our third party products reside, others of which need and have APF
> authorization through this library. This is accessed through the linklist
> and I did perform an LLA refresh. The program is a TSO-in-batch program if
> that matters. Identical JCL running on other LPARs.
> >
> > Here's the line of code it is choking on:
> >
> > KZ MODESET KEY=ZERO
> >
> > I can copy the load module to one of the other LPARs and it runs fine
> there so the module appears correct. Other APF programs are running fine
> from the library on this LPAR where I copied the code so the library
> appears correct. Any thoughts as to what I've overlooked? I have my 2
> coworkers stumped as well. It's looking like it has to be something in the
> environment but we can't determine what.
> >
> > TIA,
> >
> > Rex
> >
> > --
> > 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
> >
> > --
> > 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?
>
> 

Re: AFP confusion

[Mike Schwab]

https://www.ibm.com/docs/en/zos/2.3.0?topic=functions-apf-authorized-libraries

Libraries accessed through STEPLIB/JOBLIB are not APF authorized.

On Wed, Mar 30, 2022 at 7:35 PM Pommier, Rex  wrote:
>
> Thanks, Carmen.
>
> I forgot to mention that part.  My library is the only one in the STEPLIB.   
> And the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD 
> portion of IKJTSOxx.  Same on the working LPARs.  If I run the LISTBC command 
> by itself it runs fine.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Carmen Vitullo
> Sent: Wednesday, March 30, 2022 1:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: AFP confusion
>
> if steplib I'd still check and make sure any concatenated libraries are also 
> APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx 
> member, AUTHPGM section
>
> Carmen Vitullo
>
>
>
> -Original Message-
>
> From: Rex 
> To: IBM-MAIN 
> Date: Wednesday, 30 March 2022 1:22 PM CDT
> Subject: AFP confusion
>
> Hello list,
>
> I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
> Golob's Broadcast dataset maintenance CBT package). It's running successfully 
> on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
> program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
> them is my private library where I initially assembled the code which I added 
> to the APF list and verified it is there. I tried accessing this thru a 
> STEPLIB. The other is a general library where several of our third party 
> products reside, others of which need and have APF authorization through this 
> library. This is accessed through the linklist and I did perform an LLA 
> refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
> running on other LPARs.
>
> Here's the line of code it is choking on:
>
> KZ MODESET KEY=ZERO
>
> I can copy the load module to one of the other LPARs and it runs fine there 
> so the module appears correct. Other APF programs are running fine from the 
> library on this LPAR where I copied the code so the library appears correct. 
> Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as 
> well. It's looking like it has to be something in the environment but we 
> can't determine what.
>
> TIA,
>
> Rex
>
> --
> 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
>
> --
> 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: APF (not AFP) confusion

[Carmen Vitullo]

I've used the BCMDEL which is part of the BCMUTIL to manage broadcast messages, 
IIRC part of the instructions, are to place BCMDEL, maybe some other programs 
in the AUTHPGM entry in IKJTSOxx. 
been a long time since I've used it and I don't have the utility any longer 
that maybe one of Rex's problems 
  
   
Carmen Vitullo 

   

-Original Message-

From: Robert <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:35 PM CDT
Subject: Re: APF (not AFP) confusion

I don’t have it in AUTHPGM but do have entries in SEND. YMMV: 

SEND /* SEND COMMAND DEFAULTS */ + 
OPERSEND(ON) /* */ + 
USERSEND(ON) /* */ + 
SAVE(ON) /* */ + 
CHKBROD(ON) /* */ + 
USEBROD(OFF) /* USER BRODCAST */ + 
MSGPROTECT(OFF) /* NO EXTRA SECURITY REQUIRED*/ + 
SYSPLEXSHR(ON) /* BRODCAST SHARED IN SYSPLEX*/ + 
OPERSEWAIT(OFF) /* DONT WAIT FOR OPER SEND RESP. */ + 
LOGNAME(ULOG.BRODCAST) /* userid.BRODCAST */ + 
BROADCAST (DATASET(SYS1.BRODCAST)) 

-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo 
Sent: Wednesday, March 30, 2022 2:29 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: AFP confusion 

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section 

Carmen Vitullo 



-Original Message- 

From: Rex mailto:rpomm...@sfgmembers.com>> 
To: IBM-MAIN mailto:IBM-MAIN@LISTSERV.UA.EDU>> 
Date: Wednesday, 30 March 2022 1:22 PM CDT 
Subject: AFP confusion 

Hello list, 

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs. 

Here's the line of code it is choking on: 

KZ MODESET KEY=ZERO 

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what. 

TIA, 

Rex 

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


-- 
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: APF (not AFP) confusion

[Richards, Robert B. (CTR)]

I don’t have it in AUTHPGM but do have entries in SEND. YMMV:

SEND/* SEND COMMAND DEFAULTS */  +
   OPERSEND(ON) /*   */ +
   USERSEND(ON) /*   */ +
   SAVE(ON) /*   */ +
   CHKBROD(ON)  /*   */ +
   USEBROD(OFF) /*   USER BRODCAST   */ +
   MSGPROTECT(OFF)  /* NO EXTRA SECURITY REQUIRED*/ +
   SYSPLEXSHR(ON)   /* BRODCAST SHARED IN SYSPLEX*/ +
   OPERSEWAIT(OFF)  /* DONT WAIT FOR OPER SEND RESP.  */ +
   LOGNAME(ULOG.BRODCAST)/* userid.BRODCAST  */ +
   BROADCAST (DATASET(SYS1.BRODCAST))

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 2:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section

Carmen Vitullo



-Original Message-

From: Rex mailto:rpomm...@sfgmembers.com>>
To: IBM-MAIN mailto:IBM-MAIN@LISTSERV.UA.EDU>>
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list,

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs.

Here's the line of code it is choking on:

KZ MODESET KEY=ZERO

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

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


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

Re: AFP confusion

[Pommier, Rex]

Thanks, Carmen.  

I forgot to mention that part.  My library is the only one in the STEPLIB.   
And the LISTBC part of TSO that BCMDEL calls is actually in the AUTHCMD portion 
of IKJTSOxx.  Same on the working LPARs.  If I run the LISTBC command by itself 
it runs fine. 

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Wednesday, March 30, 2022 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: AFP confusion

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section 
   
Carmen Vitullo 

   

-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list, 

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs. 

Here's the line of code it is choking on: 

KZ MODESET KEY=ZERO 

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what. 

TIA, 

Rex 

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

--
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: AFP confusion

[Carmen Vitullo]

if steplib I'd still check and make sure any concatenated libraries are also 
APF'd  
IIRC the Broadcast program also requires an entry in the IKJTSOxx member, 
AUTHPGM section 
   
Carmen Vitullo 

   

-Original Message-

From: Rex 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 1:22 PM CDT
Subject: AFP confusion

Hello list, 

I'm stumped on this one. I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package). It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run. The 
program is linked AC=1 and is residing in 2 APF authorized libraries. One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there. I tried accessing this thru a 
STEPLIB. The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library. This is accessed through the linklist and I did perform an LLA 
refresh. The program is a TSO-in-batch program if that matters. Identical JCL 
running on other LPARs. 

Here's the line of code it is choking on: 

KZ MODESET KEY=ZERO 

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct. Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct. 
Any thoughts as to what I've overlooked? I have my 2 coworkers stumped as well. 
It's looking like it has to be something in the environment but we can't 
determine what. 

TIA, 

Rex 

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

AFP confusion

[Pommier, Rex]

Hello list,

I'm stumped on this one.  I have a small assembler program (BCMDEL from Sam 
Golob's Broadcast dataset maintenance CBT package).  It's running successfully 
on 2 of my LPARs but the third is giving me a 047 abend trying to run.  The 
program is linked AC=1 and is residing in 2 APF authorized libraries.  One of 
them is my private library where I initially assembled the code which I added 
to the APF list and verified it is there.  I tried accessing this thru a 
STEPLIB.  The other is a general library where several of our third party 
products reside, others of which need and have APF authorization through this 
library.  This is accessed through the linklist and I did perform an LLA 
refresh.   The program is a TSO-in-batch program if that matters.  Identical 
JCL running on other LPARs.

Here's the line of code it is choking on:

KZ   MODESET KEY=ZERO   

I can copy the load module to one of the other LPARs and it runs fine there so 
the module appears correct.  Other APF programs are running fine from the 
library on this LPAR where I copied the code so the library appears correct.  
Any thoughts as to what I've overlooked?  I have my 2 coworkers stumped as 
well.  It's looking like it has to be something in the environment but we can't 
determine what.

TIA,

Rex

--
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: PL/I question

[zMan]

Kids, kids...take it outside. Or at least to a thread that can be ignored.
Some of us are interested in the original question.

On Wed, Mar 30, 2022 at 12:58 PM Seymour J Metz  wrote:

> Whoosh!
>
> In this case it walks like a dog, purrs like a cat and is definitely not a
> duck.
>
> Don't try to teach your grandmother to suck eggs.
>
> You seem to be willfully ignoring what I actually wrote as well. I made
> specific claims and specific contexts and you seem to be criticizing claims
> that I never made, yet again.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Robin Vowels [robi...@dodo.com.au]
> Sent: Wednesday, March 30, 2022 12:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-31 02:38, Seymour J Metz wrote:
> >> Who does that leave?
> >
> > The obvious; your claim is untrue and it is you.
>
> Looks like you have egg on your face again.
>
> >> Put up or shut up.
> >
> > PL/I does not have computed GO TO.
>
> If it looks like a duck, quacks like a duck, it probably is a duck.
>
> Try:
>GO TO X(I);
>
> X(1): A = B;
> ...
> X(2): A = C;
> ...
> X(3): A = D;
> ...
>
> and try:
>
> GOTO (1, 2, 3), K
>
> 1 A = B
>...
> 2 A = B
>...
> 3 A = C
>...
>
> Guess which one is FORTRAN and which is PL/I.
>
> > It has LABEL arrays, which are more
> > useful. There may be cases where a computed GO TO would be clearer if
> > it exiasted, but good or bad, PL/I doesn't have it.
>
> >> Read what I wrote.
> >
> > I did; it's BS.
>
> More egg on your face.
>
> >>  White space has noting to do with it.
> >
> > That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an
> > assignment statement because the blanks are not significant. In PL/I,
> > DO I=1.10; is still a DO statement, because spaces are not allowed
> > inside a variable name.
>
> That is irrelevant to whether the DO statement in PL/I was taken
> from FORTRAN.
>
>
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Robin Vowels 
> > Sent: Tuesday, March 29, 2022 9:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I question
> >
> > On 2022-03-30 00:06, Seymour J Metz wrote:
> >> It's obvious that one of us doesn't know what he's talking about,
> >
> > And it's not me.  Who does that leave?
> >
> >> especially as you cited things that don't even exist in PL/I as being
> >> derived from FORTRAN.
> >
> > Put up or shut up.
> >
> >> And you still haven't answered whether you
> >> seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
> >> than the ALGOL FOR statement does.
> >
> > Read what I wrote.
> >
> >> Your purported explanation of the difference in DO between FORTRAN and
> >> PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
> >> PL/I are very different.
> >
> > White space has noting to do with it.
>
> --
> 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
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Contributions to CBT snce 02/22/22

[Seymour J Metz]

Yes, there are a lot of People named Shmuel. I appear to be named after a 
deceased great grandfather, and I suspect that Shmuel Golob, may he be well, is 
also named after a deceased relative, but I know of no documented family 
connection between us.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, March 30, 2022 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Contributions to CBT snce 02/22/22

Different Samuel/Shmuel!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Spiegel
Sent: Wednesday, March 30, 2022 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Contributions to CBT snce 02/22/22

Hi R'Shmuel AMV"SH,
"... laid up ..."? In case this involves something health-related,
R'fuoh Sh'leimoh.
If you want a MeShebeirach, please give me your full Jewish name and you
mother's full Jewish name.

Hatzlochoh!

Regards,
David

On 2022-03-30 10:09, Sam Golob wrote:
> Dear Folks,
>
>I have been laid up since Feb 22,2022 and did not have access to my
> emals (which are overloaded with Spam).  If you have sent any CBT
> contributions between then and now, please resend them, if you want
> them to be posted.  Thanks.  Sorry for any inconvenience.
>
>All the best of everything to you and your families.
>
> Sincerely,   Sam
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .

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

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

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

Re: PL/I

[Seymour J Metz]

I see that you don't know what "e.g." means. STRINGSIZE is the appropriate 
condition for assignment. It is not the appropriate condition for SUBSTR; 
STRINGRANGE. For that matter, neither is the correct condition for an array of 
strings, SUBSCRIPTRANGE is. Any of the three would have been appropriate after 
the "e.g.".

I would recommend enabling all three, but then I'm paranoid. YMMV.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Wednesday, March 30, 2022 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

On 2022-03-31 01:42, Seymour J Metz wrote:
> However, buffer overruns are characteristic of languages with no range
> checking. Of course, you can write C in PL/I with, e.g,
> (NOSTRINGRANGE) prefixes.

No, the appropriate condition is STRINGSIZE.
And that is disabled by default.
STRINGRANGE is disabled by default also.

It is always recommended to enable the STRINGSIZE condition.

> 
> From: IBM Mainframe Discussion List  on
> behalf of Paul Gilmartin
> Sent: Wednesday, March 30, 2022 10:31 AM
> Subject: Re: PL/I question
>
> On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:
>
>> That's a common problem, certainly, but if we include the wider world
>> of
>> micros and minis, I'd bet that buffer overuns related to
>> null-teminated
>> strings (BLEAH!) are in the lead :-)
>>
> Buffer overruns are hardly peculiar to null-temniated strinigs.
> Rather,
> they result from indolent programmers' neglecting to check the length
> before the move or the status after; using strcat() and sprinitf()
> instead of strncat and snprintf(); etc.
>
> What should be done in HLASM?  Use unprotected MVCL, or define
> data types with explicit lengths and rely on macros to move data with
> protection?
>
> Should an attempted buffer overrun throw an exception?

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

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

Re: PL/I question

[Seymour J Metz]

Whoosh!

In this case it walks like a dog, purrs like a cat and is definitely not a duck.

Don't try to teach your grandmother to suck eggs.

You seem to be willfully ignoring what I actually wrote as well. I made 
specific claims and specific contexts and you seem to be criticizing claims 
that I never made, yet again. 


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Wednesday, March 30, 2022 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-31 02:38, Seymour J Metz wrote:
>> Who does that leave?
>
> The obvious; your claim is untrue and it is you.

Looks like you have egg on your face again.

>> Put up or shut up.
>
> PL/I does not have computed GO TO.

If it looks like a duck, quacks like a duck, it probably is a duck.

Try:
   GO TO X(I);

X(1): A = B;
...
X(2): A = C;
...
X(3): A = D;
...

and try:

GOTO (1, 2, 3), K

1 A = B
   ...
2 A = B
   ...
3 A = C
   ...

Guess which one is FORTRAN and which is PL/I.

> It has LABEL arrays, which are more
> useful. There may be cases where a computed GO TO would be clearer if
> it exiasted, but good or bad, PL/I doesn't have it.

>> Read what I wrote.
>
> I did; it's BS.

More egg on your face.

>>  White space has noting to do with it.
>
> That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an
> assignment statement because the blanks are not significant. In PL/I,
> DO I=1.10; is still a DO statement, because spaces are not allowed
> inside a variable name.

That is irrelevant to whether the DO statement in PL/I was taken
from FORTRAN.


> 
> From: IBM Mainframe Discussion List  on
> behalf of Robin Vowels 
> Sent: Tuesday, March 29, 2022 9:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-30 00:06, Seymour J Metz wrote:
>> It's obvious that one of us doesn't know what he's talking about,
>
> And it's not me.  Who does that leave?
>
>> especially as you cited things that don't even exist in PL/I as being
>> derived from FORTRAN.
>
> Put up or shut up.
>
>> And you still haven't answered whether you
>> seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
>> than the ALGOL FOR statement does.
>
> Read what I wrote.
>
>> Your purported explanation of the difference in DO between FORTRAN and
>> PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
>> PL/I are very different.
>
> White space has noting to do with it.

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

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

Re: PL/I

[Robert Prins]

On Wed, 30 Mar 2022 at 16:26, Seymour J Metz  wrote:

> Yes, range checking carries a performance penalty, and there have been
> arguments in the past about performance versus safety. I'm in the camp that
> believes that they should be enabled in any program where incorrect output
> would cause a problem or where there are security issues.


While working at a client in the late 1990'ies development compiles used
all checking prefixes, production compiles used SUBSCRIPTRANGE, and that
was occasionally triggered in CICS, users always manage to outsmart the
most fool-proof code. Of course in PL/I you should never ever used
hardcoded array bounds in DO-loops, but rather the "LBOUND()", "HBOUND()"
and "DIM()" builtins!

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: PL/I

[Robin Vowels]

On 2022-03-31 03:25, Seymour J Metz wrote:

Yes, range checking carries a performance penalty, and there have been
arguments in the past about performance versus safety. I'm in the camp
that believes that they should be enabled in any program where
incorrect output would cause a problem or where there are security
issues.


An overrun is dangerous, since it can result in other data being 
destroyed

without warning, and if those corrupted data are then used or printed,
the results will be wrong -- again without warning.

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

Re: PL/I

[Robin Vowels]

On 2022-03-31 03:06, Jay Maynard wrote:
ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, 
though
it's been a very long time since I did PL/I. I would expect that the 
hit is

small but measurable, and generally worth it.


The overhead for STRINGSIZE is usually small, small enough to be 
trivial,

since it requires a comparison between the declared length and the
length of the string to be assigned.  Typically that requires
one each of L, C, and BC instructions.

The overhead for SUBSTR requires more checking, since there are now
two integer arguments that need to be tested.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  
wrote:



On 2022-03-31 01:42, Seymour J Metz wrote:
> However, buffer overruns are characteristic of languages with no range
> checking. Of course, you can write C in PL/I with, e.g,
> (NOSTRINGRANGE) prefixes.

No, the appropriate condition is STRINGSIZE.
And that is disabled by default.
STRINGRANGE is disabled by default also.

It is always recommended to enable the STRINGSIZE condition.


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

Re: PL/I question

[Robin Vowels]

On 2022-03-31 02:38, Seymour J Metz wrote:

Who does that leave?


The obvious; your claim is untrue and it is you.


Looks like you have egg on your face again.


Put up or shut up.


PL/I does not have computed GO TO.


If it looks like a duck, quacks like a duck, it probably is a duck.

Try:
  GO TO X(I);

X(1): A = B;
...
X(2): A = C;
...
X(3): A = D;
...

and try:

GOTO (1, 2, 3), K

1 A = B
  ...
2 A = B
  ...
3 A = C
  ...

Guess which one is FORTRAN and which is PL/I.


It has LABEL arrays, which are more
useful. There may be cases where a computed GO TO would be clearer if
it exiasted, but good or bad, PL/I doesn't have it.



Read what I wrote.


I did; it's BS.


More egg on your face.


 White space has noting to do with it.


That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an
assignment statement because the blanks are not significant. In PL/I,
DO I=1.10; is still a DO statement, because spaces are not allowed
inside a variable name.


That is irrelevant to whether the DO statement in PL/I was taken
from FORTRAN.




From: IBM Mainframe Discussion List  on
behalf of Robin Vowels 
Sent: Tuesday, March 29, 2022 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-30 00:06, Seymour J Metz wrote:

It's obvious that one of us doesn't know what he's talking about,


And it's not me.  Who does that leave?


especially as you cited things that don't even exist in PL/I as being
derived from FORTRAN.


Put up or shut up.


And you still haven't answered whether you
seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
than the ALGOL FOR statement does.


Read what I wrote.


Your purported explanation of the difference in DO between FORTRAN and
PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
PL/I are very different.


White space has noting to do with it.


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

Re: PL/I

[Seymour J Metz]

Yes, range checking carries a performance penalty, and there have been 
arguments in the past about performance versus safety. I'm in the camp that 
believes that they should be enabled in any program where incorrect output 
would cause a problem or where there are security issues.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay 
Maynard [jaymayn...@gmail.com]
Sent: Wednesday, March 30, 2022 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though
it's been a very long time since I did PL/I. I would expect that the hit is
small but measurable, and generally worth it.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  wrote:

> On 2022-03-31 01:42, Seymour J Metz wrote:
> > However, buffer overruns are characteristic of languages with no range
> > checking. Of course, you can write C in PL/I with, e.g,
> > (NOSTRINGRANGE) prefixes.
>
> No, the appropriate condition is STRINGSIZE.
> And that is disabled by default.
> STRINGRANGE is disabled by default also.
>
> It is always recommended to enable the STRINGSIZE condition.
>
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Paul Gilmartin
> > Sent: Wednesday, March 30, 2022 10:31 AM
> > Subject: Re: PL/I question
> >
> > On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:
> >
> >> That's a common problem, certainly, but if we include the wider world
> >> of
> >> micros and minis, I'd bet that buffer overuns related to
> >> null-teminated
> >> strings (BLEAH!) are in the lead :-)
> >>
> > Buffer overruns are hardly peculiar to null-temniated strinigs.
> > Rather,
> > they result from indolent programmers' neglecting to check the length
> > before the move or the status after; using strcat() and sprinitf()
> > instead of strncat and snprintf(); etc.
> >
> > What should be done in HLASM?  Use unprotected MVCL, or define
> > data types with explicit lengths and rely on macros to move data with
> > protection?
> >
> > Should an attempted buffer overrun throw an exception?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Jay Maynard

--
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: Contributions to CBT snce 02/22/22

[A T & T Management]

 
What's going on this time there Sam?   I am not well as well besides my 
humor... :-)
Scott
On Wednesday, March 30, 2022, 12:16:22 PM EDT, David Spiegel 
 wrote:  
 
 Hi Charles,
They're both Sh'muel.
(Some people give names that are direct translations, others give names 
that sound like the Hebrew counterpart (i.e. Seymour sounds something 
like Samuel/Sh'muel).
Another factor is that some people thought that giving their children 
American/Canadian/British etc. first names would help them integrate 
better into society, even if the name only shared one or 2 characters. 
For example, I know guys who are named Michael/Moshe.)

On 2022-03-30 12:08, Charles Mills wrote:
> I know, but Samuel Golob is not a translation of Shmuel Metz.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David Spiegel
> Sent: Wednesday, March 30, 2022 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Contributions to CBT snce 02/22/22
>
> Hi Charles,
> Samuel is a "translation" of Sh'muel (based upon the Septuagint's Bible
> translation (Hebrew->Greek->English).
>
> --
> 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: Contributions to CBT snce 02/22/22

[David Spiegel]

Hi Charles,
They're both Sh'muel.
(Some people give names that are direct translations, others give names 
that sound like the Hebrew counterpart (i.e. Seymour sounds something 
like Samuel/Sh'muel).
Another factor is that some people thought that giving their children 
American/Canadian/British etc. first names would help them integrate 
better into society, even if the name only shared one or 2 characters. 
For example, I know guys who are named Michael/Moshe.)


On 2022-03-30 12:08, Charles Mills wrote:

I know, but Samuel Golob is not a translation of Shmuel Metz.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Spiegel
Sent: Wednesday, March 30, 2022 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Contributions to CBT snce 02/22/22

Hi Charles,
Samuel is a "translation" of Sh'muel (based upon the Septuagint's Bible
translation (Hebrew->Greek->English).

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


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

Re: PL/I

[PINION, RICHARD W.]

I know the COBOL team/manuals published numbers for things like this, with the 
option turned on and with the option turned off.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jay 
Maynard
Sent: Wednesday, March 30, 2022 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

[External Email. Exercise caution when clicking links or opening attachments.]

ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though it's 
been a very long time since I did PL/I. I would expect that the hit is small 
but measurable, and generally worth it.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  wrote:

> On 2022-03-31 01:42, Seymour J Metz wrote:
> > However, buffer overruns are characteristic of languages with no 
> > range checking. Of course, you can write C in PL/I with, e.g,
> > (NOSTRINGRANGE) prefixes.
>
> No, the appropriate condition is STRINGSIZE.
> And that is disabled by default.
> STRINGRANGE is disabled by default also.
>
> It is always recommended to enable the STRINGSIZE condition.
>
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of Paul Gilmartin
> > Sent: Wednesday, March 30, 2022 10:31 AM
> > Subject: Re: PL/I question
> >
> > On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:
> >
> >> That's a common problem, certainly, but if we include the wider 
> >> world of micros and minis, I'd bet that buffer overuns related to 
> >> null-teminated strings (BLEAH!) are in the lead :-)
> >>
> > Buffer overruns are hardly peculiar to null-temniated strinigs.
> > Rather,
> > they result from indolent programmers' neglecting to check the 
> > length before the move or the status after; using strcat() and 
> > sprinitf() instead of strncat and snprintf(); etc.
> >
> > What should be done in HLASM?  Use unprotected MVCL, or define data 
> > types with explicit lengths and rely on macros to move data with 
> > protection?
> >
> > Should an attempted buffer overrun throw an exception?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: Contributions to CBT snce 02/22/22

[Charles Mills]

I know, but Samuel Golob is not a translation of Shmuel Metz.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Spiegel
Sent: Wednesday, March 30, 2022 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Contributions to CBT snce 02/22/22

Hi Charles,
Samuel is a "translation" of Sh'muel (based upon the Septuagint's Bible 
translation (Hebrew->Greek->English).

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

Re: PL/I

[Jay Maynard]

ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though
it's been a very long time since I did PL/I. I would expect that the hit is
small but measurable, and generally worth it.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  wrote:

> On 2022-03-31 01:42, Seymour J Metz wrote:
> > However, buffer overruns are characteristic of languages with no range
> > checking. Of course, you can write C in PL/I with, e.g,
> > (NOSTRINGRANGE) prefixes.
>
> No, the appropriate condition is STRINGSIZE.
> And that is disabled by default.
> STRINGRANGE is disabled by default also.
>
> It is always recommended to enable the STRINGSIZE condition.
>
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Paul Gilmartin
> > Sent: Wednesday, March 30, 2022 10:31 AM
> > Subject: Re: PL/I question
> >
> > On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:
> >
> >> That's a common problem, certainly, but if we include the wider world
> >> of
> >> micros and minis, I'd bet that buffer overuns related to
> >> null-teminated
> >> strings (BLEAH!) are in the lead :-)
> >>
> > Buffer overruns are hardly peculiar to null-temniated strinigs.
> > Rather,
> > they result from indolent programmers' neglecting to check the length
> > before the move or the status after; using strcat() and sprinitf()
> > instead of strncat and snprintf(); etc.
> >
> > What should be done in HLASM?  Use unprotected MVCL, or define
> > data types with explicit lengths and rely on macros to move data with
> > protection?
> >
> > Should an attempted buffer overrun throw an exception?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

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

Re: PL/I

[Robin Vowels]

On 2022-03-31 01:42, Seymour J Metz wrote:

However, buffer overruns are characteristic of languages with no range
checking. Of course, you can write C in PL/I with, e.g,
(NOSTRINGRANGE) prefixes.


No, the appropriate condition is STRINGSIZE.
And that is disabled by default.
STRINGRANGE is disabled by default also.

It is always recommended to enable the STRINGSIZE condition.



From: IBM Mainframe Discussion List  on
behalf of Paul Gilmartin
Sent: Wednesday, March 30, 2022 10:31 AM
Subject: Re: PL/I question

On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:

That's a common problem, certainly, but if we include the wider world 
of
micros and minis, I'd bet that buffer overuns related to 
null-teminated

strings (BLEAH!) are in the lead :-)

Buffer overruns are hardly peculiar to null-temniated strinigs.  
Rather,

they result from indolent programmers' neglecting to check the length
before the move or the status after; using strcat() and sprinitf()
instead of strncat and snprintf(); etc.

What should be done in HLASM?  Use unprotected MVCL, or define
data types with explicit lengths and rely on macros to move data with
protection?

Should an attempted buffer overrun throw an exception?


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

Re: Contributions to CBT snce 02/22/22

[David Spiegel]

Hi Charles,
Samuel is a "translation" of Sh'muel (based upon the Septuagint's Bible 
translation (Hebrew->Greek->English).


Regards,
David

On 2022-03-30 11:32, Charles Mills wrote:

Different Samuel/Shmuel!

Charles





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

Re: PL/I question

[Seymour J Metz]

> Who does that leave?

The obvious; your claim is untrue and it is you.

> Put up or shut up.

PL/I does not have computed GO TO. It has LABEL arrays, which are more useful. 
There may be cases where a computed GO TO would be clearer if it exiasted, but 
good or bad, PL/I doesn't have it.

> Read what I wrote.

I did; it's BS.

>  White space has noting to do with it. 

That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an assignment 
statement because the blanks are not significant. In PL/I, DO I=1.10; is still 
a DO statement, because spaces are not allowed inside a variable name.




From: IBM Mainframe Discussion List  on behalf of 
Robin Vowels 
Sent: Tuesday, March 29, 2022 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-30 00:06, Seymour J Metz wrote:
> It's obvious that one of us doesn't know what he's talking about,

And it's not me.  Who does that leave?

> especially as you cited things that don't even exist in PL/I as being
> derived from FORTRAN.

Put up or shut up.

> And you still haven't answered whether you
> seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
> than the ALGOL FOR statement does.

Read what I wrote.

> Your purported explanation of the difference in DO between FORTRAN and
> PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
> PL/I are very different.

White space has noting to do with it.

--
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: Contributions to CBT snce 02/22/22

[Charles Mills]

Different Samuel/Shmuel!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Spiegel
Sent: Wednesday, March 30, 2022 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Contributions to CBT snce 02/22/22

Hi R'Shmuel AMV"SH,
"... laid up ..."? In case this involves something health-related, 
R'fuoh Sh'leimoh.
If you want a MeShebeirach, please give me your full Jewish name and you 
mother's full Jewish name.

Hatzlochoh!

Regards,
David

On 2022-03-30 10:09, Sam Golob wrote:
> Dear Folks,
>
>I have been laid up since Feb 22,2022 and did not have access to my 
> emals (which are overloaded with Spam).  If you have sent any CBT 
> contributions between then and now, please resend them, if you want 
> them to be posted.  Thanks.  Sorry for any inconvenience.
>
>All the best of everything to you and your families.
>
> Sincerely,   Sam
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .

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

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

Re: PL/I question

[Seymour J Metz]

A pedantic compiler would not flag code that violated no rules. Paranoid 
compilers might flag the FORTRAN "DO 500 I=1.10" and the PL/I "DO I=1.10" as 
possibly unintended, but pedantic compilers would quietly accept both. Note 
that only the FORTRAN is an assignment statement.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 29, 2022 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Tue, 29 Mar 2022 09:22:10 -0400, David Spiegel wrote:
>
>You said: "... BTW, the change in format of the DO was essential
>in preventing the flaw in FORTRAN (which still exists)
>by which a period instead of the first comma
>changes the DO statement into an assignment statement.  ..."
>
Do pedantic compilers warn of that?  But it might be inicidental
to warning of unused variables.

Most languages have such pitfalls.  A favorite is the ALGOL-60
implied comment.  Pedantic compilers warn of that.

>Have you ever read the Datamation article regarding the comma which cost
>$15,00,000 (in the '60s)?
>
Did you just supply  an example ("$15,00.000")?  If not, cite.

In IT or in law?

--
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: Contributions to CBT snce 02/22/22

[David Spiegel]

Hi R'Shmuel AMV"SH,
"... laid up ..."? In case this involves something health-related, 
R'fuoh Sh'leimoh.
If you want a MeShebeirach, please give me your full Jewish name and you 
mother's full Jewish name.


Hatzlochoh!

Regards,
David

On 2022-03-30 10:09, Sam Golob wrote:

Dear Folks,

   I have been laid up since Feb 22,2022 and did not have access to my 
emals (which are overloaded with Spam).  If you have sent any CBT 
contributions between then and now, please resend them, if you want 
them to be posted.  Thanks.  Sorry for any inconvenience.


   All the best of everything to you and your families.

Sincerely,   Sam

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


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

Re: PL/I question

[Seymour J Metz]

> REXX ==? Unix shell script.

Not what I wrote.  "IBM does support ANSI REXX stream I/O within a Unix shell 
script." does not mean *every* shell script, only those written in REXX.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, March 30, 2022 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Wed, 30 Mar 2022 14:13:56 +, Seymour J Metz  wrote:

>To be fair, IBM does support ANSI REXX stream I/O within a Unix shell script.
>
To be fair, it lacks SIGNAL ON NOTREADY.

Yes, I know it's an external function package.

REXX ==? Unix shell script.

--
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: PL/I question

[Paul Gilmartin]

On Wed, 30 Mar 2022 14:13:56 +, Seymour J Metz  wrote:

>To be fair, IBM does support ANSI REXX stream I/O within a Unix shell script.
>
To be fair, it lacks SIGNAL ON NOTREADY.

Yes, I know it's an external function package.

REXX ==? Unix shell script.

-- 
gil

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

Re: PL/I question

[Seymour J Metz]

However, buffer overruns are characteristic of languages with no range 
checking. Of course, you can write C in PL/I with, e.g, (NOSTRINGRANGE) 
prefixes.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, March 30, 2022 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:

>That's a common problem, certainly, but if we include the wider world of
>micros and minis, I'd bet that buffer overuns related to null-teminated
>strings (BLEAH!) are in the lead :-)
>
Buffer overruns are hardly peculiar to null-temniated strinigs.  Rather,
they result from indolent programmers' neglecting to check the length
before the move or the status after; using strcat() and sprinitf()
instead of strncat and snprintf(); etc.

What should be done in HLASM?  Use unprotected MVCL, or define
data types with explicit lengths and rely on macros to move data with
protection?

Should an attempted buffer overrun throw an exception?

--
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: PL/I question

[Seymour J Metz]

> although FORTRAN is very special,
because it allows spaces even in the middle of identifiers

Exactly. Were "DO I=1,10" a valid PL/I DO statement, typing a period 
instead of a comma might make it the wrong DO statement, but could not make it 
an assignment statement.

>  IF 9 < ZZ < 20 THEN DO;

Yes, there are languages that allow what was intended.



From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, March 29, 2022 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

As it seems from other posts, the story is not completely true;
there was indeed such an error somewhere sometime with NASA,
but the error that destroyed the Mariner spacecraft was different (a
missing hyphen on
a hand-written variable specification, which had not been translated
correctly to computer code).

I believe that there are similar pitfalls in other languages, too,
although FORTRAN is very special,
because it allows spaces even in the middle of identifiers (and
numbers), such as

DO  3  I=   1 . 10

which in every other programming language would disqualify as an
assignment statement
because of the spaces around the DO symbol.

My favorite PL/1 example from a real world program is this:

IF 9 < ZZ < 20 THEN DO; ...

someone with a math background obviously coded this :-)
the expectation was, that the statement be executed if ZZ is in the
range 10 to 19.

Unfortunately, this is translated by PL/1 as follows:

IF (9 < ZZ) < 20 THEN DO;

9 < ZZ is a result of type BIT(1) and yields '0'B or '1'B, depending on ZZ;
this result is converted to decimal, so that it can be compared to the
decimal constant 20
and the result therefore is ALWAYS FALSE.

This is clearly not what the coder had intended.

We detected this luckily, using a site-written PL/1 diagnosing tool,
which complained because of the
implied type conversion (BIT(1) to decimal). About 2 percent of the
total PL/1 code base
had similar logic errors, which were undetected before we scanned all
the source codes with our
new tool in 2007. After that, we changed the deployment processes, so
that the new tool
runs with every software deployment.

Kind regards

Bernd


Am 29.03.2022 um 17:03 schrieb David Spiegel:
> Hi gil,
> I remember reading the article approximately 40 years ago.
> It was in Datamation, which was an IT magazine.
> You've never heard of Datamation before? ... How many years have you
> been in this business?
>
> The story was related to an unmanned spaceship (i.e. Venus Probe)
> whose trajectory was calculated by a FORTRAN program
> with the following statements:
> DO 3  I=1.3
> .
> .
> 3
>
> Since there was a period between "1" and "3" (instead of a comma), the
> loop ran precisely once
> and assigned 1.3 to DO3I (FORTRAN removes blanks before compile) a
> variable which is automatically declared REAL, because its first letter
> is outside the INTEGER Range I-N.
>
> Here is another reference (not Datamation) (which does not mention the
> financial loss)
> Please see:
> IEEE Xplore Full-Text PDF:
> 
> Page 58
>
> Regards,
> David
>

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

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

Re: PL/I question

[Paul Gilmartin]

On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:

>That's a common problem, certainly, but if we include the wider world of
>micros and minis, I'd bet that buffer overuns related to null-teminated
>strings (BLEAH!) are in the lead :-)
> 
Buffer overruns are hardly peculiar to null-temniated strinigs.  Rather,
they result from indolent programmers' neglecting to check the length
before the move or the status after; using strcat() and sprinitf()
instead of strncat and snprintf(); etc.

What should be done in HLASM?  Use unprotected MVCL, or define
data types with explicit lengths and rely on macros to move data with
protection?

Should an attempted buffer overrun throw an exception?

-- 
gil

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

Re: PL/I question

[Seymour J Metz]

Yes, the original PL/I inherited the original I-N rule as a default, and IBM 
later changed that.

Yes, Algol 58, 60 and 68 were all stronger in Europe than in US, although there 
were two Algol 58 based languages developed in the US. 


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, March 29, 2022 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

In the context of the error mentioned in this thread with the FORTRAN
variable DO3I etc.,
(a statement looks like a loop control statement, but is in fact a
simple assignment,
because of a period instead of a comma),
it is important to notice that PL/1 indeed inherited some
significant "bad habits" from FORTRAN, for example the idea of implicit
definitions
of variables depending on the first letter of the name ... the DEFAULT,
AFAIK,
for PL/1 was that variables starting with I to N have the BIN FIXED(15)
attribute etc.,
all others are FLOAT. This was done for FORTRAN compatibility;
IIRC, when IBM introduced PL/1, there was indeed the idea that the
scientific community which used heavily FORTRAN at that time should
convert to PL/1.
So IBM tried to make the migration as easy as possible.

Other languages, like Pascal for example, requested that all variables
be declared;
this is common today (and the error mentioned above could not occur).
The FORTRAN-PL/1-approach turned out to be an error. Later versions of PL/1
tried to resolve this.

Algol was an European effort, and it took some time for IBM to accept
(some of)
the ideas and concepts of Algol for their new language.

Kind regards

Bernd


Am 29.03.2022 um 23:05 schrieb CM Poncelet:
> +1
>
> ... and the GUIDE group then insisted that the new PL/I language should
> also support COBOL's I/O processing as well as Fortran, at a 1962-64
> conference (whenever it was.)
>
>
> On 28/03/2022 10:43, Seymour J Metz wrote:
>> I'm fully aware of the initial name; the fact remains that IBM and SHARE 
>> looked at three languages, and that FORTRAN had the least influence of the 
>> three. Most of the language derives from Algol 60 and COBOL, and the most 
>> obvious feature from FORTRAN has gone by the wayside.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7C085a100ae1a647ad927a08da11ca1a78%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637841856970331813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TzkDFWU87cTIP2E%2BeIKGdIWLjOIYJKU0dcOCymUjCCM%3Dreserved=0
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Robin Vowels [robi...@dodo.com.au]
>> Sent: Monday, March 28, 2022 4:53 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I question
>>
>> On 2022-03-28 19:10, Seymour J Metz wrote:
>>> Exaclly, especially since Algol 60 was one of the three languages
>>> folded into PL/I.
>> FORTRAN, not Algol, was the starting-point for PL/I.
>> It was even called FORTRAN VI.
>> Features of both Algol and COBOL were incorporated into
>> the language.
>>
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>>> behalf of David Spiegel [dspiegel...@hotmail.com]
>>> Sent: Sunday, March 27, 2022 11:38 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: PL/I question
>>>
>>> Hi R'Shmuel AMV"SH,
>>> Like ALGOL and Pascal?
>>>
>>> Regards,
>>> David
>>>
>>> On 2022-03-27 22:52, Seymour J Metz wrote:
 Personally, I wish that IBM had chosen ":=" for assignment.
>> --
>> 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: PL/I question

[Seymour J Metz]

To be fair, IBM does support ANSI REXX stream I/O within a Unix shell script.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 29, 2022 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Tue, 29 Mar 2022 15:41:14 -0700, Charles Mills  wrote:

>I wrote a commercial product in Borland Turbo Pascal somewhere around 1988. We 
>ended up re-writing it in C. Some combination of the greater availability of 
>developers and/or an inability to do certain things* in Pascal that we could 
>do in C. I don't recall exactly.
>
I once wrote an RTF to Script translator in Apple Pascal.  A co-worker
asked fora copy, then diiscovered Borland couldn't deal with it.
II had used IEEE standard I/O which Borland shunned.

Kinida like IBM Rexx vs. ANSI standard Rexx I/O.

I/O may be hard, but vendors are too eager to shirk it.

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

Contributions to CBT snce 02/22/22

[Sam Golob]

Dear Folks,

   I have been laid up since Feb 22,2022 and did not have access to my 
emals (which are overloaded with Spam).  If you have sent any CBT 
contributions between then and now, please resend them, if you want them 
to be posted.  Thanks.  Sorry for any inconvenience.


   All the best of everything to you and your families.

Sincerely,   Sam

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

Re: PL/I question

[Seymour J Metz]

It is easy to recognize that "if (foo=constant)" is probably meant to be "if 
(foo == constant)", but "if (foo = expression)" might actually be what was 
meant.


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Tuesday, March 29, 2022 6:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Well, while we are digressing ...

There was discussion earlier of the use of the equal sign for assignment versus 
comparison.

I am going to guess that THE most common cause of C/C++ program errors is the 
mis-use of = for comparison. (The comparison operator in C and C++ is ==.) In C 
if you code

if (foo = 3) bar = 5;

Then the compiler generates code to assign 3 to foo, test the result (3) for 
truth (not 0) and then execute the conditional statement. The above has the 
same effect as

foo = 3;
bar = 5;

If I am recalling the story correctly, a malicious programmer *almost* 
succeeded in inserting code into the Linux kernel of the form

if (uid = 0) ...

The code appears to be testing the uid for 0, but in reality is making the uid 
0. Someone who know how to get to the code path could make themselves into 
superuser.

I like := for assignment, but I believe C eliminated the ambiguity of = by 
choosing == for comparison, by analogy to all of the other 2-character 
comparison operators (>=, !=, etc.).=

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Tuesday, March 29, 2022 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

As it seems from other posts, the story is not completely true;
there was indeed such an error somewhere sometime with NASA,
but the error that destroyed the Mariner spacecraft was different (a
missing hyphen on
a hand-written variable specification, which had not been translated
correctly to computer code).

I believe that there are similar pitfalls in other languages, too,
although FORTRAN is very special,
because it allows spaces even in the middle of identifiers (and
numbers), such as

DO  3  I=   1 . 10

which in every other programming language would disqualify as an
assignment statement
because of the spaces around the DO symbol.

My favorite PL/1 example from a real world program is this:

IF 9 < ZZ < 20 THEN DO; ...

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

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

Re: PL/I question

[Charles Mills]

I would certainly suspect that for *security* problems buffer overruns are far 
and away the biggest problem. You see it all the time: the programmer declares 
a 50-byte buffer for reading-in an 8 byte value, and then just assumes that is 
"big enough" and does not limit or check the read.

For problems as a whole, I'm still going with =. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rupert Reynolds
Sent: Wednesday, March 30, 2022 6:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

That's a common problem, certainly, but if we include the wider world of
micros and minis, I'd bet that buffer overuns related to null-teminated
strings (BLEAH!) are in the lead :-)

I once saw a report quoting Microsoft that half of all vulnerabilities were
buffer overruns.

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

Re: PL/I question

[Rupert Reynolds]

That's a common problem, certainly, but if we include the wider world of
micros and minis, I'd bet that buffer overuns related to null-teminated
strings (BLEAH!) are in the lead :-)

I once saw a report quoting Microsoft that half of all vulnerabilities were
buffer overruns.

I also saw a Dave Plummer YT (Dave's Garage) video recently, in which he
said that MS programmers tended to coypu pasty code, rather than reuse.

Do I spot a pattern? :-)

On Tue., Mar. 29, 2022, 23:10 Charles Mills,  wrote:

> Well, while we are digressing ...
>
> There was discussion earlier of the use of the equal sign for assignment
> versus comparison.
>
> I am going to guess that THE most common cause of C/C++ program errors is
> the mis-use of = for comparison. (The comparison operator in C and C++ is
> ==.) In C if you code
>
> if (foo = 3) bar = 5;
>
> Then the compiler generates code to assign 3 to foo, test the result (3)
> for truth (not 0) and then execute the conditional statement. The above has
> the same effect as
>
> foo = 3;
> bar = 5;
>
> If I am recalling the story correctly, a malicious programmer *almost*
> succeeded in inserting code into the Linux kernel of the form
>
> if (uid = 0) ...
>
> The code appears to be testing the uid for 0, but in reality is making the
> uid 0. Someone who know how to get to the code path could make themselves
> into superuser.
>
> I like := for assignment, but I believe C eliminated the ambiguity of = by
> choosing == for comparison, by analogy to all of the other 2-character
> comparison operators (>=, !=, etc.).=
>
> Charles
>
>
>
>

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

ASCII was RE: PL/I question

[Seymour J Metz]

An early version of ASCII had some code points with dual assignments of 
characters, and included left and up arrows.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 30, 2022 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Wed, 30 Mar 2022 19:50:12 +0800, David Crayford wrote:
>>
>> That may well be. I stand by my claim that it is a common source of errors.
>
>I agree. Which is why a lot of C programmers used to used to code if 
>statements with no lvalues:
>
>if (3 = foo) ...
>
A similar practice applies to Shell test.  Code:
if [ 3 = $foo ] ...
rather than:
if [ $foo = 3 ] ...
lest $foo evaluate to a unary operator.  The habit of writing the constant on 
the
right may come from natural languages where "is" can denote either identity
or set membership.

I favor ":=", a typographically asymmetric operator for a semantically
asymmetric operation.

It's unfortunate that ASCII doesn't contain "←".  Some languages assign
rightward -- "GIVING or "→".

--
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: Resize SMF MAN without IPL

[Allan Staller]

Classification: Confidential

Yes. Switch to an alternate dataset and delete/define the original.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Tuesday, March 29, 2022 11:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resize SMF MAN without IPL

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello

Is it possible to resize the SMF Man dataset on fly without an IPL ? Will there 
be any impact ? Or it is doable without a disruption.

Jake

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Resize SMF MAN without IPL

[Carmen Vitullo]

 

IIRC you need to remove the dataset you intend to delete from the SMFPRMxx 
member, set that member as active T SMF=xx then you can delete and redefine, 
I've done this a couple of time, works well that way, I have 3 SMFPRMxx members 
still setup to do this. We're using log streams now but the SMF MAN datasets 
are still defined in the member for backup  

Carmen  
   
Carmen Vitullo 

   

-Original Message-

From: Jake 
To: IBM-MAIN 
Date: Wednesday, 30 March 2022 12:58 AM CDT
Subject: Re: Resize SMF MAN without IPL

The only challenge I can see is that I can't resize an existing one as it 
gives me message as 'In use'. 





On Wed, Mar 30, 2022, 9:30 AM Jake Anderson  
wrote: 

> Thanks Mike 
> 
> So just pick the non-active one.(with zero %),. Delete them. Then Define a 
> new SMF MAN and preformat and do /T SMF=00. 
> 
> 
> Is it correct? 
> 
> On Wed, Mar 30, 2022, 8:38 AM Mike Schwab  wrote: 
> 
>> You can define and init a SYSn.MANx dataset and it will be picked up 
>> after updating the parmlib SMFPRMxx member. If the dataset is not in 
>> use, you can delete, define, and init an existing SYSn.MANx dataset. 
>> However, you will need to have at least 2 available datasets to allow 
>> swapping, unloading, and init the inactive dataset. 
>> 
>> 
>> https://www.ibm.com/docs/en/zos/2.3.0?topic=sets-using-define-create-smf-data
>>  
>> 
>> https://www.ibm.com/docs/en/zos/2.3.0?topic=sets-switching-smf-data 
>> When the SMF data set that is currently being recording on becomes 
>> full, SMF does the following: 
>> Automatically closes the full data set, making it available for dumping. 
>> Locates the new data set to open by starting at the top of the list of 
>> data sets specified on the DSNAME parameter of the SMFPRMxx member and 
>> looking for the first completely empty data set. 
>> 
>> Of course the trend is to switch to logstreams. 
>> 
>> https://www.ibm.com/docs/en/zos/2.3.0?topic=sums-switching-between-smf-logging-smf-data-set-recording
>>  
>> 
>> On Wed, Mar 30, 2022 at 5:00 AM Jake Anderson  
>> wrote: 
>> > 
>> > Hello 
>> > 
>> > Is it possible to resize the SMF Man dataset on fly without an IPL ? 
>> Will 
>> > there be any impact ? Or it is doable without a disruption. 
>> > 
>> > Jake 
>> > 
>> > -- 
>> > 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 
>> 
> 

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

  

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

Re: PL/I question

[Paul Gilmartin]

On Wed, 30 Mar 2022 19:50:12 +0800, David Crayford wrote:
>>
>> That may well be. I stand by my claim that it is a common source of errors.
>
>I agree. Which is why a lot of C programmers used to used to code if 
>statements with no lvalues:
>
>if (3 = foo) ...
>
A similar practice applies to Shell test.  Code:
if [ 3 = $foo ] ...
rather than:
if [ $foo = 3 ] ...
lest $foo evaluate to a unary operator.  The habit of writing the constant on 
the
right may come from natural languages where "is" can denote either identity
or set membership.

I favor ":=", a typographically asymmetric operator for a semantically
asymmetric operation.

It's unfortunate that ASCII doesn't contain "←".  Some languages assign
rightward -- "GIVING or "→".

-- 
gil

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

Re: PL/I question

[David Crayford]

On Tue, 2022-03-29 at 20:35 -0700, Charles Mills wrote:
> > Almost all modern C/C++ compilers will flag that as a warning
> 
> That may well be. I stand by my claim that it is a common source of errors.

I agree. Which is why a lot of C programmers used to used to code if statements 
with no lvalues:

if (3 = foo) ...

> 
> I am not sure if z/OS XLC flags it. I am also not sure whether z/OS XLC is a 
> modern C/C++ compiler. 

xlclang does. In fact it goes further and will validate that printf() arguments 
match the format specifiers and will also check for buffer overflows. But it's 
64bit only so can can't be used with
legacy code without jumping through AMODE switching hoops. The new LLVM/clang 
compiler currently in beta solves those problems and is bang up to date as IBM 
have joined the LLVM open source commnunity
and are committing z/OS patches. It supports 31bit and C++20 with all the nice 
stuff like modules and concepts. We're hanging out for it to GA!

> 
> The intentional use of = in a condition is a favorite of old-style "how few 
> keystrokes can I use" C programmers, for example in the formulation
> 
> if (myfile = fopen(...)) ...  // executes code if fopen is successful
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David Crayford
> Sent: Tuesday, March 29, 2022 7:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
> 
> On Tue, 2022-03-29 at 15:10 -0700, Charles Mills wrote:
> > Well, while we are digressing ...
> > 
> > There was discussion earlier of the use of the equal sign for assignment 
> > versus comparison.
> > 
> > I am going to guess that THE most common cause of C/C++ program errors is 
> > the mis-use of = for comparison. (The comparison operator in C and C++ is 
> > ==.) In C if you code
> > 
> > if (foo = 3) bar = 5;
> > 
> > Then the compiler generates code to assign 3 to foo, test the result (3) 
> > for truth (not 0) and then execute the conditional statement. The above has 
> > the same effect as
> 
> Almost all modern C/C++ compilers will flag that as a warning. And there are 
> options to promote warnings to errors. For example:
> 
> --
> 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: Resize SMF MAN without IPL

[Mike Schwab]

Try changing parmlib to remove it then swap to a new data set.  It
might deallocate the dataset.
Or just create a new one of the desired size and update parmlib then
delete the old one after a swap or IPL.

On Wed, Mar 30, 2022 at 6:58 AM Jake Anderson  wrote:
>
> The only challenge I can see is that I can't resize an existing one as it
> gives me message as 'In use'.
>
>
>
>
>
> On Wed, Mar 30, 2022, 9:30 AM Jake Anderson 
> wrote:
>
> > Thanks Mike
> >
> > So just pick the non-active one.(with zero %),. Delete them. Then Define a
> > new SMF MAN and preformat and do /T SMF=00.
> >
> >
> > Is it correct?
> >
> > On Wed, Mar 30, 2022, 8:38 AM Mike Schwab  wrote:
> >
> >> You can define and init a SYSn.MANx dataset and it will be picked up
> >> after updating the parmlib SMFPRMxx member.  If the dataset is not in
> >> use, you can delete, define, and init an existing SYSn.MANx dataset.
> >> However, you will need to have at least 2 available datasets to allow
> >> swapping, unloading, and init the inactive dataset.
> >>
> >>
> >> https://www.ibm.com/docs/en/zos/2.3.0?topic=sets-using-define-create-smf-data
> >>
> >> https://www.ibm.com/docs/en/zos/2.3.0?topic=sets-switching-smf-data
> >> When the SMF data set that is currently being recording on becomes
> >> full, SMF does the following:
> >> Automatically closes the full data set, making it available for dumping.
> >> Locates the new data set to open by starting at the top of the list of
> >> data sets specified on the DSNAME parameter of the SMFPRMxx member and
> >> looking for the first completely empty data set.
> >>
> >> Of course the trend is to switch to logstreams.
> >>
> >> https://www.ibm.com/docs/en/zos/2.3.0?topic=sums-switching-between-smf-logging-smf-data-set-recording
> >>
> >> On Wed, Mar 30, 2022 at 5:00 AM Jake Anderson 
> >> wrote:
> >> >
> >> > Hello
> >> >
> >> > Is it possible to resize the SMF Man dataset on fly without an IPL ?
> >> Will
> >> > there be any impact ? Or it is doable without a disruption.
> >> >
> >> > Jake
> >> >
> >> > --
> >> > 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
> >>
> >
>
> --
> 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