Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Doug Fuerst]

This will be the last thing I say on this subject.

I am NOT calling anyone "out."

I am simply asking...nicely,,, that this thread stop, and with it, the 
vituperative comments, insults, nastiness, etc. that seems to permeate 
this forum lately.

From EVERYONE!


Please, don't we have enough of this in the world these days? Can't we 
be decent and civil to each other?

Is it really THAT difficult?

Doug Fuerst



-- Original Message --

From "Jon Perryman" 

To IBM-MAIN@LISTSERV.UA.EDU
Date 10/31/2023 20:04:24 PM
Subject Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND 
ON SVC 8



On Tue, 31 Oct 2023 23:15:44 +, Doug Fuerst  wrote:


I am not OK with any of it, and after Mr. Johnson, I suspect the list is
not as well.


I'm also not ok with this but it's Crayford you should be calling out. By 
ignoring his insults the first couple of times, I showed far more respect and 
restraint to Crayford than he has shown to me. As long as Crayford is 
respectful, the problem does not exist nor would it have arose in the first 
place.

I must say that things are much better after Mr. Johnson.

--
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: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Jon Perryman]

On Tue, 31 Oct 2023 23:15:44 +, Doug Fuerst  wrote:

>I am not OK with any of it, and after Mr. Johnson, I suspect the list is 
>not as well.

I'm also not ok with this but it's Crayford you should be calling out. By 
ignoring his insults the first couple of times, I showed far more respect and 
restraint to Crayford than he has shown to me. As long as Crayford is 
respectful, the problem does not exist nor would it have arose in the first 
place. 

I must say that things are much better after Mr. Johnson.

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

Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Doug Fuerst]

I am not OK with any of it, and after Mr. Johnson, I suspect the list is 
not as well.


I'd just like it to be kept civil, and limited to real exchanges of 
technical issues.
I hope you all realize that you can take this off the forum and discuss 
amongst yourselves.

But let's try and keep this civil and professional.
Please?

Doug Fuerst


-- Original Message --

From "Jon Perryman" 

To IBM-MAIN@LISTSERV.UA.EDU
Date 10/31/2023 19:06:25 PM
Subject Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND 
ON SVC 8



On Tue, 31 Oct 2023 21:53:36 +, Doug Fuerst  wrote:


Did we just trade Bill Johnson for Jon Perryman? Are you two related? We
are back to backbiting and insults.
Can we just stop?


If I'm showing a pattern of being confused or being constantly wrong (as 
claimed by Crayford), please show me where. So you are ok with Crayford 
intentionally insulting me but my finally getting fed up with him puts me into 
the Bill Johnson classification?

My last response was not intended to be insulting. If it was, I apologize. I 
greatly respect Peter's insights but this was the perfect example for Crayford 
that demonstrated take the high road  In this case, there was no benefit in 
pursuing an obscure situation that others will never see. It was better to 
ignore it and allow others to think I was wrong.

The last response was driven by Crayford responding with "confused again" after 
I showed how wrong and confused he was on his last 3 responses to my comments. What has 
emboldened Crayford to be insulting? It certainly is not based on his real knowledge.

--
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: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Jon Perryman]

On Tue, 31 Oct 2023 21:53:36 +, Doug Fuerst  wrote:

>Did we just trade Bill Johnson for Jon Perryman? Are you two related? We 
>are back to backbiting and insults.
>Can we just stop?

If I'm showing a pattern of being confused or being constantly wrong (as 
claimed by Crayford), please show me where. So you are ok with Crayford 
intentionally insulting me but my finally getting fed up with him puts me into 
the Bill Johnson classification? 

My last response was not intended to be insulting. If it was, I apologize. I 
greatly respect Peter's insights but this was the perfect example for Crayford 
that demonstrated take the high road  In this case, there was no benefit in 
pursuing an obscure situation that others will never see. It was better to 
ignore it and allow others to think I was wrong.

The last response was driven by Crayford responding with "confused again" after 
I showed how wrong and confused he was on his last 3 responses to my comments. 
What has emboldened Crayford to be insulting? It certainly is not based on his 
real knowledge.

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

Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Doug Fuerst]

Did we just trade Bill Johnson for Jon Perryman? Are you two related? We 
are back to backbiting and insults.

Can we just stop?


Doug Fuerst



-- Original Message --

From "Jon Perryman" 

To IBM-MAIN@LISTSERV.UA.EDU
Date 10/31/2023 17:34:02 PM
Subject Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND 
ON SVC 8



On Fri, 29 Sep 2023 14:35:45 +, Peter Relson  wrote:


 As this related to a purported need to link with AC=1,
 I was perfectly sure that that was not correct. And I remain so.


Is it truly a coincidence that this group failed in 1 week to solve a simple 
SCHEDIRB and LOAD failing when shortly after my first attempt, the op solved 
his problem? The OP sent his source and the op said it failed on LOAD.

If this were not TSO involving LOAD, Peter might be correct. TSO does not 
follow conventional wisdom and rules. As a product developer, we had a LOAD 
fail in our product where (if I remember correctly) the solution was to link 
the module AC=1. Our product address space included multi-tasking TSO 
(concurrent TSO commands). Most people don't experience the quirks of TSO and 
would be surprised to learn that TSO changes many of the rules. For instance, I 
am painfully aware of JSCBAUTH because there are times it must be restored in 
TSO. Unix dubbing is also a problem.

I bring this up because clueless Crayford is now saying "you're confused AGAIN" 
which I find offensive. Clearly I was not confused in my response to his comments. 
Clearly I'm not confused here although it's possible I'm wrong about TSO AC=1. When 
exactly am I repeatedly confused? I have a different life experience than most. Just 
because I don't respond does not mean I'm wrong. It's very rare for anyone to experience 
TSO quirks when there are only a couple of products running multi-tasking TSO in their 
product address space. There are few people with vast experience in a single diverse 
address space where many products are executing concurrently. Why should I continue a 
discussion that is irrelevant for most people and not beneficial to me?

Why do people consider me confused when I make completely relevant 
recommendations that many do not understand. This is my style of problem 
solving and it clearly works.

--
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: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Jon Perryman]

On Fri, 29 Sep 2023 14:35:45 +, Peter Relson  wrote:

> As this related to a purported need to link with AC=1,
> I was perfectly sure that that was not correct. And I remain so.

Is it truly a coincidence that this group failed in 1 week to solve a simple 
SCHEDIRB and LOAD failing when shortly after my first attempt, the op solved 
his problem? The OP sent his source and the op said it failed on LOAD. 

If this were not TSO involving LOAD, Peter might be correct. TSO does not 
follow conventional wisdom and rules. As a product developer, we had a LOAD 
fail in our product where (if I remember correctly) the solution was to link 
the module AC=1. Our product address space included multi-tasking TSO 
(concurrent TSO commands). Most people don't experience the quirks of TSO and 
would be surprised to learn that TSO changes many of the rules. For instance, I 
am painfully aware of JSCBAUTH because there are times it must be restored in 
TSO. Unix dubbing is also a problem.  

I bring this up because clueless Crayford is now saying "you're confused AGAIN" 
which I find offensive. Clearly I was not confused in my response to his 
comments. Clearly I'm not confused here although it's possible I'm wrong about 
TSO AC=1. When exactly am I repeatedly confused? I have a different life 
experience than most. Just because I don't respond does not mean I'm wrong. 
It's very rare for anyone to experience TSO quirks when there are only a couple 
of products running multi-tasking TSO in their product address space. There are 
few people with vast experience in a single diverse address space where many 
products are executing concurrently. Why should I continue a discussion that is 
irrelevant for most people and not beneficial to me?

Why do people consider me confused when I make completely relevant 
recommendations that many do not understand. This is my style of problem 
solving and it clearly works.

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

Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Joseph Reichman]

Looking into it now 

> On Sep 29, 2023, at 10:36 AM, Peter Relson  wrote:
> 
> 
>> 
>> even Peter Relson wasn't sure if this correct
> 
> As this related to a purported need to link with AC=1, I was perfectly sure 
> that that was not correct. And I remain so.
> 
> Joe R: you've mentioned multiple times that you abended after the load.
> But did you ever share what abend code and abend reason code you got? Perhaps 
> I missed it...
> 
> It's never helpful to talk about getting an abend without describing what 
> that abend (or completion code because it might not have been an error from 
> the ABEND macro).
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> 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: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Peter Relson]

> even Peter Relson wasn't sure if this correct

As this related to a purported need to link with AC=1, I was perfectly sure 
that that was not correct. And I remain so.

Joe R: you've mentioned multiple times that you abended after the load.
But did you ever share what abend code and abend reason code you got? Perhaps I 
missed it...

It's never helpful to talk about getting an abend without describing what that 
abend (or completion code because it might not have been an error from the 
ABEND macro).

Peter Relson
z/OS Core Technology Design


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

Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8

[Joseph Reichman]

Jon 

Kudos to you even Peter Relson wasn’t sure if this correct   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Wednesday, September 27, 2023 10:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SCHEDIRB

On Tue, 19 Sep 2023 20:29:52 -0400, Joseph Reichman  
wrote:

> Source code below.

Sorry for chiming in so late but I've had other priorities. I think you're 
being led down the wrong path. A 30 second glance at your code shows obvious 
coding errors. SRB and IRB are the the real danger. Running key 0 and sup makes 
you the destroyer of worlds. Always make this code obvious. 

1. Labels IRBPTR and STIMER are not preceded by a "DROP ,". As exit routines, 
prior USINGs are not guaranteed. They may be using a bad reg.

2. IRBLST and TIMERLST are in a DSECT that is not obvious they have been 
initialized correctly. It's not obvious that generated eye catchers and default 
values were copied or if the area was simply zeroed.

3. Use "save (R14,R12),'exit eyecatcher' will simplify debugging when looking 
at a dump for the PSW address.

4. I believe that LOAD will abend if the module is not linked with the AC=1 
attribute when running authorized.

5. TSO does SVC screening to protect itself from SUP and non-KEY8 security 
exposures. Does TSO allow an unknown LOAD from the job step TCB.

6. Is there a reason you haven't tried IDENTIFY for the module? I've never 
tested this situation but I suspect it increments the use count to ensure the 
alternate name remains available when the TCB goes away.

7. Another possibility is STORAGE OBTAIN and LOAD to the obtained area.

8. If you need to refresh the module, using LOAD from the IKJEFT01 TCB will 
require logoff / logon or the implementation of another IRB to refresh the LOAD 
module.

I suspect there are other problems. With so many possible problems, you need to 
get familiar with IPCS because analyzing the dump would tell you quickly where 
and what abended. Since you don't have XDC, you may find IPCS useful when 
looking at the active system with the SAF BLSACTV resource permitted because 
you can view all address spaces. Alternatively, insert WTO's in you code to see 
where you are failing.


>
> STIMERM SET,  X
>   ID=TIMER,   X
>   BINTVL=NOW, X
>   ERRET=ERROR,X
>   EXIT=STIMER,X
>   PARM=TIMER_PLIST,   X
>   WAIT=NO,MF=(E,TIMERLST)
>
>
>STIMER   DS   0D
>  STM  R14,R12,12(R13)   
> *   
>  LRR4,R15   
>  DROP  R3   
>  USING STIMER,R4
>  LRR10,R13  
>  L R13,4(,R1)Get Save area  
>  DROP  R13  
>  USING TIMERSVE,R13 
>  STR10,4(R13)   
> *   
>  SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=SAVE
> *   
> *   
> *  Chain rb pointer to put this IRB as next 
> * 
>  LAR5,IRBPTR
>  O R5,=X'8000'  
>  STR5,IRBADD
>  L R6,PSATOLD   
>  USING TCB,R6   
>  L R6,TCBJSTCB   Get the Job Step tcb   
>  STR6,JSTCB 
>  SCHEDIRB EPPTR=IRBADD,X
>TCBPTR=JSTCB,   X
>SVAREA=YES, X
>MODE=SUPR,  X
>KEY=SUPR,  

Re: AC(1)

[Rob Scott]

If a field in a control block is marked as being a programming interface, it 
does not matter what language is used to reference it and REXX "STORAGE" is 
just as valid as assembler "MVC" .

What is being pointed out is that a REXX exec that uses "STORAGE" to access 
reverse-engineered or non-programming interface fields of control blocks is 
liable to break in some fashion in future releases or maintenance levels.

IPLINFO is just a REXX exec and it executes in problem state.

CSVAPF is the interface to retrieve the APF list in the same way that UCBSCAN 
is the interface to retrieve UCB info.

Are there OCO control blocks that you can access in memory to "bypass" the 
supported interface? Yes.
Is this a good idea - I would suggest not.

As stated before, my advice would be to convert the REXX usage of such non-GUPI 
fields to use some sort of external function that uses supported interfaces and 
returns the information using IRXEXCOM.

Rob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, May 9, 2018 3:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On Wed, 9 May 2018 06:23:42 -0500, Steve Horein wrote:

>On Fri, May 4, 2018 at 6:33 AM, Peter Relson wrote:
>> 
>> I believe you. The code that was shown was assembler. Regardless,
>> being an exec still means that the choice was made not to use an
>> intended programming interface.
>> 
>
>If a data area is described with "Programming Interface Information"
>and then referenced via Rexx STORAGE calls, is that considered a choice
>to not use an intended programming interface?
>...
MVC is "an intended programming interface".  A carelessly authorized program 
can do a lot of damage with MVC.

>I am an automation administrator with regrettably zero assembler
>programming skills, and tend to use such Rexx calls to alleviate the
>painful process of MVS command output parsing to get information, if
>available, when I can.
>
Might one use fork() (BPX1FRK, SYSCALL fork, ...) to run unvetted Rexx code 
such as IPLINFO safely unauthorized in a separate address space, returning 
results via a pipe or socket to an authorized caller?

(Is IPLINFO free of the constraints of TSO?)

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: AC(1)

[Paul Gilmartin]

On Wed, 9 May 2018 06:23:42 -0500, Steve Horein wrote:

>On Fri, May 4, 2018 at 6:33 AM, Peter Relson wrote:
>> 
>> I believe you. The code that was shown was assembler. Regardless, being an
>> exec still means that the choice was made not to use an intended
>> programming interface.
>> 
>
>If a data area is described with "Programming Interface Information" and
>then referenced via Rexx STORAGE calls, is that considered a choice to not
>use an intended programming interface?
>...
MVC is "an intended programming interface".  A carelessly authorized
program can do a lot of damage with MVC.

>I am an automation administrator with regrettably zero assembler
>programming skills, and tend to use such Rexx calls to alleviate the
>painful process of MVS command output parsing to get information, if
>available, when I can.
>
Might one use fork() (BPX1FRK, SYSCALL fork, ...) to run unvetted Rexx
code such as IPLINFO safely unauthorized in a separate address space,
returning results via a pipe or socket to an authorized caller?

(Is IPLINFO free of the constraints of TSO?)

-- gil

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

Re: AC(1)

[Steve Horein]

On Fri, May 4, 2018 at 6:33 AM, Peter Relson  wrote:

> 
>
> I believe you. The code that was shown was assembler. Regardless, being an
> exec still means that the choice was made not to use an intended
> programming interface.
> 


If a data area is described with "Programming Interface Information" and
then referenced via Rexx STORAGE calls, is that considered a choice to not
use an intended programming interface?
I am an automation administrator with regrettably zero assembler
programming skills, and tend to use such Rexx calls to alleviate the
painful process of MVS command output parsing to get information, if
available, when I can.
Would I use the CSVAPF service (or IOCINFO, or UCBSCAN, or ...) if it were
available as a Rexx function? In a heartbeat. Do I believe IBM will spend
time, effort, and money on such an endeavor? It seems unlikely.

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

Re: AC(1)

[John McKown]

On Fri, May 4, 2018 at 10:24 AM, Seymour J Metz  wrote:

> Why? Wouldn't it be better to put facilities requiring assembler into
> function packages so that other REXX scripts can use them? It's no rocket
> science.
>

​It's Friday. And I hit my head last night on a hard object (stumbling to
b-room). And I'm on vacation today. Three good reasons!


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: AC(1)

[Seymour J Metz]

Why? Wouldn't it be better to put facilities requiring assembler into function 
packages so that other REXX scripts can use them? It's no rocket science.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Friday, May 4, 2018 7:44 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: AC(1)

On Fri, May 4, 2018 at 6:33 AM, Peter Relson <rel...@us.ibm.com> wrote:

> ...the logic above is done on _every_ OPEN for _every_ DD
> name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
> concatenation is for libraries)?
> 
>
> I'm not sure, but since APF authorization applies only to load libraries,
> I'd imagine that the OPEN processing is done
> only for cases where it applies.
>
> 
> IPLINFO is a REXX exec.
> 
>
> I believe you. The code that was shown was assembler. Regardless, being an
> exec still means that the choice was made not to use an intended
> programming interface.
>

​I hit my head last night, as will be obvious from:

OOH! OOH! I have an idea for REXX: "embedded assembler". Followed by
"embedded ".​



>
> Peter Relson
> z/OS Core Technology Design
>


--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
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: AC(1)

[John McKown]

On Fri, May 4, 2018 at 6:33 AM, Peter Relson  wrote:

> ...the logic above is done on _every_ OPEN for _every_ DD
> name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
> concatenation is for libraries)?
> 
>
> I'm not sure, but since APF authorization applies only to load libraries,
> I'd imagine that the OPEN processing is done
> only for cases where it applies.
>
> 
> IPLINFO is a REXX exec.
> 
>
> I believe you. The code that was shown was assembler. Regardless, being an
> exec still means that the choice was made not to use an intended
> programming interface.
>

​I hit my head last night, as will be obvious from:

OOH! OOH! I have an idea for REXX: "embedded assembler". Followed by
"embedded ".​



>
> Peter Relson
> z/OS Core Technology Design
>


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

AC(1)

[Peter Relson]

...the logic above is done on _every_ OPEN for _every_ DD
name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
concatenation is for libraries)?


I'm not sure, but since APF authorization applies only to load libraries, 
I'd imagine that the OPEN processing is done 
only for cases where it applies.


IPLINFO is a REXX exec.


I believe you. The code that was shown was assembler. Regardless, being an 
exec still means that the choice was made not to use an intended 
programming interface.

Peter Relson
z/OS Core Technology Design


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

Re: AC(1)

[Rob Scott]

I believe that the "IPLINFO" rexx exec pre-dates the dynamic APF implementation 
and used to show the APF table using the rexx inbuilt storage function by 
traversing the static APF control blocks (I cannot remember if these fields 
were GUPI or not).

When dynamic APF was introduced, someone spent some time attempting to reverse 
engineer the APF control blocks to try and keep IPLINFO a pure REXX exec.

I can understand the motivation to do so, however as more things in z/OS go to 
a second level of abstraction (eg dynamic update functionality) and use OCO 
control blocks this style of reverse engineering could get very difficult to 
maintain.

If it were up to me, I would probably invest the time is composing a suite 
external REXX functions that could invoke supported problem state services like 
"CSVAPF REQUEST=LIST" and return the results in rexx stems using IRXEXCOM.

Using this technique would mean that the code was using standard interfaces for 
the information it wants to display.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, May 3, 2018 7:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On 5/3/2018 4:47 AM, Peter Relson wrote:
> ... IPLINFO itself must have been changed when dynamic APF was
> introduced but chose not to use the provided programming interface
> (CSVAPF REQUEST=LIST) to gain access to the data.

Umm... IPLINFO is a REXX exec.

As such, it cannot invoke z/OS system services unless they support a standard 
externally-callable interface.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.phoenixsoftware.com%2F=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C8783299e0c434a59727a08d5b1201feb%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636609673913772392=rOBcpTImD%2FPcDWdrVSu65A1MBpcvHjLkMlkRmn9tmEw%3D=0

This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole  use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not a intended recipient, please contact the 
sender by reply e-mail and destroy all copies of this email message  and do not 
otherwise utilize or retain this email message or any or all of the information 
contained therein. Although this email message and any attachments or appended 
messages are believed to be free of any virus or other defect that might affect 
any computer system into which it is received and opened, it is the 
responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: AC(1)

[Ed Jaffe]

On 5/3/2018 4:47 AM, Peter Relson wrote:

... IPLINFO itself must have been changed
when dynamic APF was introduced but chose not to use the provided
programming interface (CSVAPF REQUEST=LIST) to gain access to the data.


Umm... IPLINFO is a REXX exec.

As such, it cannot invoke z/OS system services unless they support a 
standard externally-callable interface.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: AC(1)

[John McKown]

On Thu, May 3, 2018 at 6:47 AM, Peter Relson  wrote:

> Whether a dataset is SMS-managed or not has no relevance to the
> information displayed by the program, but has relevance to whether or not
> there is a "match". That match is done as part of "Open" processing, for
> example.
>
> An APF list entry created by a specification such as DSN(MY.DSN) SMS will
> match a dataset named MY.DSN that is SMS-managed. It will not match a data
> set named MY.DSN that is not SMS-managed. The other side of that is that
> an APF list entry created by DSN(MY.DSN) VOLUME(V) will match a dataset
> named MY.DSN that is on VOLUME V whether or not the data set is
> SMS-managed (but if the data set is SMS-managed and moves to a different
> volume, there would no longer be a match from that APF list entry).
>
> The DEBAPFIN bit is used to determine if the concatenation is considered
> to be APF-authorized or not. It works approximately like this: initially,
> the DEBAPFIN bit is turned on. If any data set is found in the
> concatenation that is not APF-authorized, the DEBAPFIN bit is turned off.
>
> Since the code you show does not use an intended programming interface, I
> will not comment on its correctness. IPLINFO itself must have been changed
> when dynamic APF was introduced but chose not to use the provided
> programming interface (CSVAPF REQUEST=LIST) to gain access to the data.
>
> Peter Relson
> z/OS Core Technology Design
>
>
​That was very interesting. Thanks for the explanation. Just to be sure
that I understand, the logic above is done on _every_ OPEN for _every_ DD
name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
concatenation is for libraries)? It doesn't really matter, I'm just
curious. One of the reasons that I really did (and do) dislike OCO is that
my understanding is "artificially" reduced (as opposed to "inherent" due to
my own lack of capability). That's why I'm an FSF member. And a Linux (vice
Windows / MacOS) partisan. And, yes, I do sometimes "use the Source, Luke!".


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Re: AC(1)

[Peter Relson]

Whether a dataset is SMS-managed or not has no relevance to the 
information displayed by the program, but has relevance to whether or not 
there is a "match". That match is done as part of "Open" processing, for 
example.

An APF list entry created by a specification such as DSN(MY.DSN) SMS will 
match a dataset named MY.DSN that is SMS-managed. It will not match a data 
set named MY.DSN that is not SMS-managed. The other side of that is that 
an APF list entry created by DSN(MY.DSN) VOLUME(V) will match a dataset 
named MY.DSN that is on VOLUME V whether or not the data set is 
SMS-managed (but if the data set is SMS-managed and moves to a different 
volume, there would no longer be a match from that APF list entry).

The DEBAPFIN bit is used to determine if the concatenation is considered 
to be APF-authorized or not. It works approximately like this: initially, 
the DEBAPFIN bit is turned on. If any data set is found in the 
concatenation that is not APF-authorized, the DEBAPFIN bit is turned off. 

Since the code you show does not use an intended programming interface, I 
will not comment on its correctness. IPLINFO itself must have been changed 
when dynamic APF was introduced but chose not to use the provided 
programming interface (CSVAPF REQUEST=LIST) to gain access to the data.

Peter Relson
z/OS Core Technology Design


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

Re: AC(1)

[John Gateley]

Peter,

The CBT program uses code from Mark Zelden's IPLINFO to get a list of APF 
libraries (he is credited).
In assembler this is
 L R1,16 point to CVT   
 L R1,140(,R1)   point to CVTECVT   
 L R1,228(,R1)   point to CSV table 
 L R1,12(,R1)point to APFA  
 L R4,8(,R1) point to first name
 L R5,12(,R1)point to last name 

it outputs all dataset names and volumes in this list to SYSOUT

then it does RDJFCB on STEPLIB and uses ARAJFCB to get dataset name and volume 
for all concatenated datasets. It outputs the dataset name and volume and flags 
any that are not in the APF list.

this is repeated for JOBLIB

Would the dataset being SMS-managed, or not, affect this?

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

Re: AC(1)

[Ed Jaffe]

On 5/2/2018 9:29 AM, Seymour J Metz wrote:

I suppose that "No, you told me that YOU BELIEVED all libraries are 
authorized!" is not politically correct.


I would simply state that abend047 proves the job step is not 
authorized. Therefore, we must investigate every avenue to find out why...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: AC(1)

[Seymour J Metz]

I suppose that "No, you told me that YOU BELIEVED all libraries are 
authorized!" is not politically correct.


--
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: Tuesday, May 1, 2018 3:34 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: AC(1)

You overestimate some customers. If a customer says "yes, we're sure all the 
libraries are authorized" and you say "do a D PROG,APF and see if all the 
libraries are in there" the customer will quite possibly respond "WE TOLD YOU 
ALL OF THE LIBRARIES ARE AUTHORIZED."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Tuesday, May 1, 2018 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

D PROG, APF

Is a lot less work

--
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: AC(1)

[Peter Relson]

Does the CBT Tape program mentioned take into account all of
Data set name (surely it does)
Volume (very likely)
whether the data set is SMS-managed or not
?

Peter Relson
z/OS Core Technology Design


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

Re: AC(1)

[Steve Beaver]

"WE TOLD YOU ALL OF THE LIBRARIES ARE AUTHORIZED."

The reply of a novice or manager  LOL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, May 1, 2018 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

You overestimate some customers. If a customer says "yes, we're sure all the 
libraries are authorized" and you say "do a D PROG,APF and see if all the 
libraries are in there" the customer will quite possibly respond "WE TOLD YOU 
ALL OF THE LIBRARIES ARE AUTHORIZED."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Tuesday, May 1, 2018 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

D PROG, APF 

Is a lot less work

--
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: AC(1)

[Charles Mills]

You overestimate some customers. If a customer says "yes, we're sure all the 
libraries are authorized" and you say "do a D PROG,APF and see if all the 
libraries are in there" the customer will quite possibly respond "WE TOLD YOU 
ALL OF THE LIBRARIES ARE AUTHORIZED."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Tuesday, May 1, 2018 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

D PROG, APF 

Is a lot less work

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

Re: AC(1)

[Farley, Peter x23353]

But that assumes you have authority to perform a console display command.  Most 
large shops where I have been employed forbid application programmers any 
console authority at all, however innocuous Display may seem to be.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Tuesday, May 1, 2018 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

D PROG, APF 

Is a lot less work

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, May 1, 2018 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

Ha!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gateley
Sent: Tuesday, May 1, 2018 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

Hi Charles

File 953 on the CBT contains a program LISTAPF which checks every load library 
in the STEPLIB or JOBLIB against the APF list.

Regards
John
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: AC(1)

[Paul Gilmartin]

On Tue, 1 May 2018 11:33:07 -0700, Ed Jaffe wrote:
>
>It might be nice if DDLIST had an A[PF] column, with a checkbox to
>indicate APF authorized, on the data set list you see at entry -- which
>includes STEPLIB data sets. Or maybe just have APF authorized rows
>displayed in a different color.
>
>But that solves the problem only for your current TSO session. In this
>case, we're discussing a general solution for any address space
>including batch jobs, started tasks, etc.
> 
I had envisioned using TSO ALLOCATE ad hoc to make such concatenations
available in TSO.  Of course it would be nicer if TSO understood JCL DD
statements with no need to translate then to ALLOCATE, or if DDLIST could
run in batch.  (Can DDLIST run headless, under batch ISPF?)

History and risque wordplay aside, I take the first three characters of "UNIX"
to mean UNIform.  I admire that single-language philosophy.

-- gil

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

Re: AC(1)

[Ed Jaffe]

On 5/1/2018 8:21 AM, Paul Gilmartin wrote:

On Tue, 1 May 2018 08:03:03 -0700, Ed Jaffe wrote:



I usually tell customers to resolve such problems by comparing the
suspect //STEPLIB against the list of data sets shown by the "APF"
subcommand of the free-and-included ISPF "DDLIST" command, paying
careful attention to volsers as well as data set names.


It's a shame that DDLIST MEMBER doesn't supply that information directly,
simply when a given member of a given concatenation is selected.  (The
user could ALLOCATE it ad-hoc if needed.)  RFE?


It might be nice if DDLIST had an A[PF] column, with a checkbox to 
indicate APF authorized, on the data set list you see at entry -- which 
includes STEPLIB data sets. Or maybe just have APF authorized rows 
displayed in a different color.


But that solves the problem only for your current TSO session. In this 
case, we're discussing a general solution for any address space 
including batch jobs, started tasks, etc.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: AC(1)

[Steve Beaver]

D PROG, APF 

Is a lot less work

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, May 1, 2018 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

Ha!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gateley
Sent: Tuesday, May 1, 2018 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

Hi Charles

File 953 on the CBT contains a program LISTAPF which checks every load library 
in the STEPLIB or JOBLIB against the APF list.

Regards
John

--
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: AC(1)

[Charles Mills]

Ha!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gateley
Sent: Tuesday, May 1, 2018 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

Hi Charles

File 953 on the CBT contains a program LISTAPF which checks every load library 
in the STEPLIB or JOBLIB against the APF list.

Regards
John

--
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: AC(1)

[John Gateley]

Hi Charles

File 953 on the CBT contains a program LISTAPF which checks every load library 
in the STEPLIB or JOBLIB against the APF list.

Regards
John

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

Re: AC(1)

[Charles Mills]

If I have nothing better to do one of these days (ha!) I will write a program 
for the CBT that given a concatenated DD of load libraries will tell you the 
APF status of each. (Yes, the information is available via other routes, such 
as what @Ed suggests below.) 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, May 1, 2018 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On 5/1/2018 7:04 AM, Charles Mills wrote:
> Usually it turns out that "every library in the STEPLIB concatenation" means 
> "EVERY library in the STEPLIB concatenation."

Agreed. That is the problem 99% of the time.

I usually tell customers to resolve such problems by comparing the 
suspect //STEPLIB against the list of data sets shown by the "APF" 
subcommand of the free-and-included ISPF "DDLIST" command, paying 
careful attention to volsers as well as data set names.

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

Re: AC(1)

[Paul Gilmartin]

On Tue, 1 May 2018 08:03:03 -0700, Ed Jaffe wrote:

>On 5/1/2018 7:04 AM, Charles Mills wrote:
>> Usually it turns out that "every library in the STEPLIB concatenation" means 
>> "EVERY library in the STEPLIB concatenation."
>
>Agreed. That is the problem 99% of the time.
>
>I usually tell customers to resolve such problems by comparing the
>suspect //STEPLIB against the list of data sets shown by the "APF"
>subcommand of the free-and-included ISPF "DDLIST" command, paying
>careful attention to volsers as well as data set names.
> 
It's a shame that DDLIST MEMBER doesn't supply that information directly,
simply when a given member of a given concatenation is selected.  (The
user could ALLOCATE it ad-hoc if needed.)  RFE?

Even better, answer "Which catenand causes this concatenation to be
unauthorized?

-- gil

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

Re: AC(1)

[Ed Jaffe]

On 5/1/2018 7:04 AM, Charles Mills wrote:

Usually it turns out that "every library in the STEPLIB concatenation" means "EVERY 
library in the STEPLIB concatenation."


Agreed. That is the problem 99% of the time.

I usually tell customers to resolve such problems by comparing the 
suspect //STEPLIB against the list of data sets shown by the "APF" 
subcommand of the free-and-included ISPF "DDLIST" command, paying 
careful attention to volsers as well as data set names.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: AC(1)

[Charles Mills]

Yep. I have considered it. 



CharlesSent from a mobile; please excuse the brevity.
 Original message From: Seymour J Metz <sme...@gmu.edu> Date: 
5/1/18  7:55 AM  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AC(1) 
If that's a common problem, do an RDJFCB for the STEPLIB and check each entry 
in the ARL to see if the dataset is authorized, reporting any that are not.


--
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: Tuesday, May 1, 2018 10:04 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: AC(1)

I can think of one use: I have dealt with support calls from a customer or 
prospect of the form "your program reports it is running non-authorized but we 
are SURE we did everything you told us to do." It might be useful if a program 
could not only report it was non-authorized but also the possible reasons why.

Granted what @Ed says below, it would not always be possible of course, but 
usually the problem is simpler than that. Usually it turns out that "every 
library in the STEPLIB concatenation" means "EVERY library in the STEPLIB 
concatenation."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, April 30, 2018 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On 4/30/2018 6:06 PM, Walt Farrell wrote:
>
> But it's a good question, as merely wanting to know if you were linked AC(1) 
> seems not terribly useful to a running program.

Hardly useful at all since -- for the purposes of APF authorization --
even when loaded from an APF authorized library, AC(1) applies only to
the program listed on the EXEC PGM=program JCL statement.

Suppose EXEC PGM=program is AC(0) and then XCTLs to you and you are
AC(1) and residing in an APF authorized library. Now you're AC(1),
you're the job step program, and yet you're not APF authorized. Fab...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://secure-web.cisco.com/1teoL8sEXlof6V7Mr_2h3mdnwC0q5ES95iwii2ydc2j2I9t7tvlnPqPeNVPnWBHOdrVkq7MRjwNiorSlJIFzfO83gMUZScbAOUXyfGwfuynoZ2nJvSlUkIpQ03nKvk87fb_71nvMK09LDpQAVl2v00GACvQAbk84H6gON83yp1UT_sfBxonN8wme6K3FNOED03GAODU2GfkvxmiJY15p4Ha7b2ejOEan3U9LH9FuVkd8JWHLR-Qq4ApeXwM9nRI2FL6kAj-xxEDnd1S9-8Fe_RVCj6XY5JoNpiOiZ-UHBfFG5yFZFdUFrU7WnERCMw_jl_4uDfJiqDcEfMaxk-uPZ-XRdvLRlMi2bhzPyAGRHdthW5zQf7kVIOrPL48dVW9YEQg_aJXyA-UUugxo_55pYzqkKWH4B3XGD5Bx86k9rwnLTnH0Pj9Z-oJkWmFyrkNA1/http%3A%2F%2Fwww.phoenixsoftware.com%2F

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
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: AC(1)

[Seymour J Metz]

If that's a common problem, do an RDJFCB for the STEPLIB and check each entry 
in the ARL to see if the dataset is authorized, reporting any that are not.


--
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: Tuesday, May 1, 2018 10:04 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: AC(1)

I can think of one use: I have dealt with support calls from a customer or 
prospect of the form "your program reports it is running non-authorized but we 
are SURE we did everything you told us to do." It might be useful if a program 
could not only report it was non-authorized but also the possible reasons why.

Granted what @Ed says below, it would not always be possible of course, but 
usually the problem is simpler than that. Usually it turns out that "every 
library in the STEPLIB concatenation" means "EVERY library in the STEPLIB 
concatenation."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, April 30, 2018 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On 4/30/2018 6:06 PM, Walt Farrell wrote:
>
> But it's a good question, as merely wanting to know if you were linked AC(1) 
> seems not terribly useful to a running program.

Hardly useful at all since -- for the purposes of APF authorization --
even when loaded from an APF authorized library, AC(1) applies only to
the program listed on the EXEC PGM=program JCL statement.

Suppose EXEC PGM=program is AC(0) and then XCTLs to you and you are
AC(1) and residing in an APF authorized library. Now you're AC(1),
you're the job step program, and yet you're not APF authorized. Fab...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://secure-web.cisco.com/1teoL8sEXlof6V7Mr_2h3mdnwC0q5ES95iwii2ydc2j2I9t7tvlnPqPeNVPnWBHOdrVkq7MRjwNiorSlJIFzfO83gMUZScbAOUXyfGwfuynoZ2nJvSlUkIpQ03nKvk87fb_71nvMK09LDpQAVl2v00GACvQAbk84H6gON83yp1UT_sfBxonN8wme6K3FNOED03GAODU2GfkvxmiJY15p4Ha7b2ejOEan3U9LH9FuVkd8JWHLR-Qq4ApeXwM9nRI2FL6kAj-xxEDnd1S9-8Fe_RVCj6XY5JoNpiOiZ-UHBfFG5yFZFdUFrU7WnERCMw_jl_4uDfJiqDcEfMaxk-uPZ-XRdvLRlMi2bhzPyAGRHdthW5zQf7kVIOrPL48dVW9YEQg_aJXyA-UUugxo_55pYzqkKWH4B3XGD5Bx86k9rwnLTnH0Pj9Z-oJkWmFyrkNA1/http%3A%2F%2Fwww.phoenixsoftware.com%2F

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
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: AC(1)

[Charles Mills]

I can think of one use: I have dealt with support calls from a customer or 
prospect of the form "your program reports it is running non-authorized but we 
are SURE we did everything you told us to do." It might be useful if a program 
could not only report it was non-authorized but also the possible reasons why.

Granted what @Ed says below, it would not always be possible of course, but 
usually the problem is simpler than that. Usually it turns out that "every 
library in the STEPLIB concatenation" means "EVERY library in the STEPLIB 
concatenation."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, April 30, 2018 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On 4/30/2018 6:06 PM, Walt Farrell wrote:
>
> But it's a good question, as merely wanting to know if you were linked AC(1) 
> seems not terribly useful to a running program.

Hardly useful at all since -- for the purposes of APF authorization -- 
even when loaded from an APF authorized library, AC(1) applies only to 
the program listed on the EXEC PGM=program JCL statement.

Suppose EXEC PGM=program is AC(0) and then XCTLs to you and you are 
AC(1) and residing in an APF authorized library. Now you're AC(1), 
you're the job step program, and yet you're not APF authorized. Fab...

-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
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: AC(1)

[Ed Jaffe]

On 4/30/2018 6:06 PM, Walt Farrell wrote:


But it's a good question, as merely wanting to know if you were linked AC(1) 
seems not terribly useful to a running program.


Hardly useful at all since -- for the purposes of APF authorization -- 
even when loaded from an APF authorized library, AC(1) applies only to 
the program listed on the EXEC PGM=program JCL statement.


Suppose EXEC PGM=program is AC(0) and then XCTLs to you and you are 
AC(1) and residing in an APF authorized library. Now you're AC(1), 
you're the job step program, and yet you're not APF authorized. Fab...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: AC(1)

[Walt Farrell]

On Mon, 30 Apr 2018 16:54:22 -0700, Charles Mills <charl...@mcn.org> wrote:

>Do you want to query AC(1) specifically or whether you are running
>authorized, which requires AC(1) plus an all-APF-authorized STEPLIB
>concatenation?

No, running authorized does not (necessarily) require AC(1). 

Assuming consider only APF-authorization, and not forms like system key or 
supervisor state, and ignoring situations like TSO and perhaps some aspects of 
z/OS UNIX, it requires that the first program executed in the jobstep had 
AC(1). But subsequent programs run by that program don't need (and shouldn't 
have, in general) AC(1). They just need to come from an APF-authorized library 
or concatenation. So AC(1) is required only if you're the first program that 
was executed in the jobstep.

But it's a good question, as merely wanting to know if you were linked AC(1) 
seems not terribly useful to a running program.

-- 
Walt

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

Re: AC(1)

[Charles Mills]

Do you want to query AC(1) specifically or whether you are running
authorized, which requires AC(1) plus an all-APF-authorized STEPLIB
concatenation?

TESTAUTH FCTN=1 (as @Daniel writes) will give you whether or not you meet
*all* of the requirements and are actually running authorized. That is the
common test.

I've never used CSVQUERY but it looks like OUTATTR2 will split out each of
the details, including AC(1) specifically. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Daniel S. Dalby
Sent: Monday, April 30, 2018 4:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On Monday, April 30, 2018 at 5:43:52 AM UTC-7, Ernest Nachtigall wrote:
>> Can a program (ASM) determine at run time if it has been linked AC(1)?

> Looks like CSVQUERY OUTATTR2= will give you that.

How about TESTAUTH FCTN=1 ?

--
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: AC(1)

[Daniel S. Dalby]

On Monday, April 30, 2018 at 5:43:52 AM UTC-7, Ernest Nachtigall wrote:
>> Can a program (ASM) determine at run time if it has been linked AC(1)?

> Looks like CSVQUERY OUTATTR2= will give you that.

How about TESTAUTH FCTN=1 ?

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