Re: APF authorization and AC(00)

[CM Poncelet]

A REFR program's page can be stolen (without having to save it first) by
the RSM if it has a higher UIC than other pages. If it then hits a page
fault, the ASM reloads the missing page from the paging dataset so the
program can continue executing. AFAIK It reloads only stolen pages, not
the whole module, while it is in the middle of being executed.

Chris Poncelet (retired sysprog)



On 12/06/2017 07:44, Binyamin Dissen wrote:
> On Mon, 12 Jun 2017 00:31:28 -0400 Randy Hudson  wrote:
> 
> :>In article <2376347398828975.wa.paulgboulderaim@listserv.ua.edu> you 
> write:
> :>
> :>> Point taken.  But it's not clear why the designers chose to allow a 
> program
> :>> to be both modifyable and reloadable.  This leads to dreadful 
> unpredictability:
> :>> Behavior may differ depending on whether the program has been reloaded.
> :>> OK.  Initialization code may set a flag (in each page?) that will be 
> cleared by
> :>> a reload.  Critical code paths may check (before and after) that the flag 
> remains
> :>> set and re-initialize if it's found cleared.  And the documentation should
> :>> conscientiously mention the need to do this.  Ugh!
> 
> :>The REFR attribute has existed since MVT version 19 or so.  Core storage
> :>then was really core storage... toroidal ferrite cores threaded on wires, at
> :>a cost of a dollar a bit, or more.
> 
> :>Saving a few bytes is sneered at as false economy, now.  It wasn't, then.
> 
> :>A refreshable load module might have inititalization code that needs to be
> :>run only once per time it's loaded, with that init code overwritten for
> :>scratch storage afterward.  If the module's space is needed, the whole thing
> :>gets overwritten.  Later it can be refreshed, and the initialization re-run.
> 
> :>Or, a module might contain a dynamically reorganized search table, such as a
> :>move-to-front table.  That's storage modification, and it's hard to make it
> :>re-entrant on a 360/65 with only TS as a locking mechanism.  But it can be
> :>refreshable, reloading the initial configuration each time.
> 
> That would only allow the refreshable module to be reloaded if it is started
> at the entry point. It cannot be refreshed while it is in the middle of being
> executed. 
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
> 
> --
> 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 authorization and AC(00)

[Paul Gilmartin]

On Mon, 12 Jun 2017 13:53:23 -0400, Tony Harminc wrote:
>
>> Name-token services does something related.  I understand it performs
>> no costly locking during searches, but tests a flag after a search to
>> detect that the data structure has been modified in-progress, and
>> re-drive the search, with less expected cost than locking for every search.
>>
>I've been waiting for IBM to convert this to use Transactional Execution.
>Well for all I know perhaps they have.
>
What performance cost does TE incur (there must be some)?  It's possible
that the existing cleverly recherché design, optimized for searches rather
than updates is better.  If it ain't broke ...

Of course, the update process is so designed that an unserialized search
never risks following an invalid pointer nor falling into an endless loop.

-- gil

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

Re: APF authorization and AC(00)

[Tony Harminc]

On 12 June 2017 at 12:35, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> Name-token services does something related.  I understand it performs
> no costly locking during searches, but tests a flag after a search to
> detect that the data structure has been modified in-progress, and
> re-drive the search, with less expected cost than locking for every search.
>

I've been waiting for IBM to convert this to use Transactional Execution.
Well for all I know perhaps they have.

Tony H.

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

REFR protection (was: APF authorization and AC(00)

[David W Noon]

On Mon, 12 Jun 2017 11:35:33 -0500, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: APF
authorization and AC(00)" (in
<3613995808381310.wa.paulgboulderaim@listserv.ua.edu>):

[snip]
> Earlier, I said that REFRPROT could be made the default because load
> modules erroneously marked REFR could be re-linked.  OK. Not in
> every case.  So make REFRPROT the default except for load modules
> marked non-editable, because they can't be repaired.

The PDS utility and/or File-Aid can remove the REFR attribute, so there
is no need to re-link. The attribute is in the directory entry.

> REFRPROT should be made a JOB statement option rather than a system
> parm option, for flexibility in testing.

More granular than that, it should also be available on the EXEC
statement so that it can be selected on a step-by-step basis.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: APF authorization and AC(00)

[Paul Gilmartin]

On Mon, 12 Jun 2017 09:44:02 +0300, Binyamin Dissen wrote:

>On Mon, 12 Jun 2017 00:31:28 -0400 Randy Hudson wrote:
>
>:>Saving a few bytes is sneered at as false economy, now.  It wasn't, then.
>
Alas, code designed according to that criterion remains in use today (if it
weren't, REFRPROT could be made the default), with resulting lack of
robustness.  Programs that might then to be used thousands of times during
their lifetimes now run millions of times in an hour, magnifying the exposure
of flaws.

>:>A refreshable load module might have inititalization code that needs to be
>:>run only once per time it's loaded, with that init code overwritten for
>:>scratch storage afterward.  If the module's space is needed, the whole thing
>:>gets overwritten.  Later it can be refreshed, and the initialization re-run.
>
The coding requirements are onerous.  The program must be able to:
o detect that it's been refreshed and re-run the initialization.
o tolerate a refresh at any point within a critical code section with
  no misbehavior such as a wild STore.
o be tested to verify the above are true.

>:>Or, a module might contain a dynamically reorganized search table, such as a
>:>move-to-front table.  That's storage modification, and it's hard to make it
>:>re-entrant on a 360/65 with only TS as a locking mechanism.  But it can be
>:>refreshable, reloading the initial configuration each time.
>
And such a move-to-front table ought not span a page boundary, lest a
refresh of one page but not both during the move operation cause an
entry to be lost or duplicated, and that a refresh during a search result
in an entry's being bypassed.  And while the original design may have
the table in a single page it may grow with a design revision.

>That would only allow the refreshable module to be reloaded if it is started
>at the entry point. It cannot be refreshed while it is in the middle of being
>executed.
>
Name-token services does something related.  I understand it performs
no costly locking during searches, but tests a flag after a search to
detect that the data structure has been modified in-progress, and
re-drive the search, with less expected cost than locking for every search.

Earlier, I said that REFRPROT could be made the default because load
modules erroneously marked REFR could be re-linked.  OK. Not in
every case.  So make REFRPROT the default except for load modules
marked non-editable, because they can't be repaired.

REFRPROT should be made a JOB statement option rather than a system
parm option, for flexibility in testing.

-- gil

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

Re: APF authorization and AC(00)

[Gary Weinhold]

It could be practical when writing high-performance code to modify a RENT 
module if it is not in key 0 (or use a PC to make the modification if in key 
0).  An example would be if an extensive chain of indirect pointers (or  the 
NAME/TOKEN service), is used to locate life of IPL memory allocated for an 
application.  If a location in the RENT module is zero, it locates the memory 
and stores the address (using CS) in the RENT module; if it's non-zero, it uses 
the value as the address.  If CS fails, check for zero again.  Since all 
executions would  store the same value, no other serialization is needed.  I'm 
not sure CS is needed if it's a fullword on a word boundary.

Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone:  +1.613.523.5500 x216
Email:  weinh...@dkl.com

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]

Visit us online at www.DKL.com

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



__


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

Re: APF authorization and AC(00)

[Walt Farrell]

On Sun, 11 Jun 2017 20:52:10 -0400, Steve Thompson  wrote:

>Question: Wasn't REFR for a program where, say a double-bit
>parity error could occur, and it would then get loaded to a new page?

I can't comment on the double-bit parity error, but I think that someone 
(Peter, Jim?) mentioned earlier in this thread that REFR was intended to help 
recover from storage-related machine checks.

-- 
Walt

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

Re: APF authorization and AC(00)

[Walt Farrell]

On Mon, 12 Jun 2017 02:24:30 +, Jesse 1 Robinson  
wrote:

>I got tired of guessing. I wrote a little program that saves registers into 
>itself via STM. I linked it with AC(1) and RENT. Did not specify  >either REUS 
>or REFR. The result according to StarTool is 

>--  ATTRIBUTES   - APF  
>RENT REUS   AC

>As suggested in the KC doc, REUS is set automatically as a subordinate of 
>RENT, but REFR is not set. Result at execution:

>If the module is executed from my personal non-APF library, it runs fine.

>If the module is executed from an APF library, it get S0C4. 

>I was dubious about 'RENT OK if execution is serialized'. This is a single 
>execution in batch. No competition. It abends. I don't see how  >it could be 
>otherwise. 

No one has said that a RENT program could modify itself, with serialziation, if 
it's loaded from an authorized library. However, it can do that if it's loaded 
from a non-authorized library (assuming it is not also REFR, or that REFRPROT 
is off).

-- 
Walt

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

Re: APF authorization and AC(00)

[John Eells]

Paul Gilmartin wrote:

On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:


REFRPROT extends this to programs that are not loaded from an
APF authorized library.


Actually, REFRPROT extends this to programs that are bound with the REFR
option regardless of module authorization or library authorization.
And it goes further because it page-protects, which would cause the
program to blow up even if were running key 0 if it attempted to store
into itself.


I remain mystified,  Why was not the REFRPROT behavior the default
(or only) behavior ever since the inception of the REFR attribute?
o Is there a performance penalty for REFRPROT that developers
   wanted to circumvent for problem programs?  Contrariwise, it seems
   that coding a test for the authorized status of the load library was
   needless effort.
o Did the developers assume, very incorrectly IMO, that they were
   extending a courtesy to application programmers by permitting
   programs that modified themselves to be marked REFR?


z/OS was not created out of whole cloth in a single release, nor was the 
hardware architecture on which it runs.  In particular, page protection 
was not there when REFR was first implemented.  A quick search indicates 
the latter was new in the 3090 announcement.


REFR was implemented quite some time before that.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: APF authorization and AC(00)

[Elardus Engelbrecht]

Binyamin Dissen wrote:

>But if you lie to zOS and assert that a non-reentrant program is reentrant, 
>zOS will not stop you from walking off the roof.

Indeed. You will get burned badly. I once coded a SMF exit which modified 
itself in a macro's MF=L instead of modified that marco's copy in a GETMAINed 
area...  ps 

Result ... after one execution of that exit, the z/OS system automatically 
removed that exit from SMF. Re-enable it via T SMF=xx resulted in the same 
removal until I fixed it.

Groete / Greetings
Elardus Engelbrecht

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

Re: APF authorization and AC(00)

[Binyamin Dissen]

On Mon, 12 Jun 2017 00:31:28 -0400 Randy Hudson  wrote:

:>In article <2376347398828975.wa.paulgboulderaim@listserv.ua.edu> you 
write:
:>
:>> Point taken.  But it's not clear why the designers chose to allow a program
:>> to be both modifyable and reloadable.  This leads to dreadful 
unpredictability:
:>> Behavior may differ depending on whether the program has been reloaded.
:>> OK.  Initialization code may set a flag (in each page?) that will be 
cleared by
:>> a reload.  Critical code paths may check (before and after) that the flag 
remains
:>> set and re-initialize if it's found cleared.  And the documentation should
:>> conscientiously mention the need to do this.  Ugh!

:>The REFR attribute has existed since MVT version 19 or so.  Core storage
:>then was really core storage... toroidal ferrite cores threaded on wires, at
:>a cost of a dollar a bit, or more.

:>Saving a few bytes is sneered at as false economy, now.  It wasn't, then.

:>A refreshable load module might have inititalization code that needs to be
:>run only once per time it's loaded, with that init code overwritten for
:>scratch storage afterward.  If the module's space is needed, the whole thing
:>gets overwritten.  Later it can be refreshed, and the initialization re-run.

:>Or, a module might contain a dynamically reorganized search table, such as a
:>move-to-front table.  That's storage modification, and it's hard to make it
:>re-entrant on a 360/65 with only TS as a locking mechanism.  But it can be
:>refreshable, reloading the initial configuration each time.

That would only allow the refreshable module to be reloaded if it is started
at the entry point. It cannot be refreshed while it is in the middle of being
executed. 

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

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: APF authorization and AC(00)

[Binyamin Dissen]

The attributes are to allow the system to take care of the infrastructure,
such as loading a new copy if a program is non-reentrant and serializing use
if the program is described as reusable.

But if you lie to zOS and assert that a non-reentrant program is reentrant,
zOS will not stop you from walking off the roof. 

On Mon, 12 Jun 2017 02:24:30 + Jesse 1 Robinson <jesse1.robin...@sce.com>
wrote:

:>I got tired of guessing. I wrote a little program that saves registers into 
itself via STM. I linked it with AC(1) and RENT. Did not specify either REUS or 
REFR. The result according to StarTool is 
:>
:>--  ATTRIBUTES   - APF 
:>RENT REUS   AC
:>
:>As suggested in the KC doc, REUS is set automatically as a subordinate of 
RENT, but REFR is not set. Result at execution:
:>
:>If the module is executed from my personal non-APF library, it runs fine.
:>
:>If the module is executed from an APF library, it get S0C4. 
:>
:>I was dubious about 'RENT OK if execution is serialized'. This is a single 
execution in batch. No competition. It abends. I don't see how it could be 
otherwise. 
:>
:>.
:>.
:>.
:>J.O.Skip Robinson
:>Southern California Edison Company
:>Electric Dragon Team Paddler 
:>SHARE MVS Program Co-Manager
:>323-715-0595 Mobile
:>626-543-6132 Office ?=== NEW
:>robin...@sce.com
:>
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Clark Morris
:>Sent: Sunday, June 11, 2017 5:15 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: (External):Re: APF authorization and AC(00)
:>
:>[Default] On 11 Jun 2017 13:39:47 -0700, in bit.listserv.ibm-main 
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:
:>
:>>On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:
:>>
:>>>A refreshable program cannot modify itself (or if it can, it would be 
:>>>a very interesting and perhaps self-limiting testcase).
:>>>
:>>I believe that if a program is marked REFR but loaded from a 
:>>non-authorized library and REFRPROT is not in effect, no error is 
:>>reported at that time.  Behavior is unpredictable when a refresh may 
:>>actually occur.
:>>
:>>>... A reentrant program
:>>>can, if written carefully, modify itself, although it is rarely a good idea.
:>>>LPA modules are generally, in effect, refreshable.
:>>> 
:>>Does this mean that REFRPROT "in effect" applies to LPA modules?
:>>
:>>>As to "why", think about it.
:>>>Page protection did not even exist at the time RENT and REFR were defined.
:>>>And over those 20-30 years, many many programs were incorrectly bound 
:>>>with "RENT,REFR" when in fact they were RENT but not REFR. But they 
:>>>worked fine given the way the system processed.
:>>>The combination was used indiscriminately, and often thought of as a pair.
:>>>Making it the default would be horribly incompatible.
:>>>
:>>It's like a child whining about a distasteful medicine: in the end it's 
:>>good for him and should be done, even as user key CSA has been disabled 
:>>(I think).
:>>
:>>Programmers who didn't RTFM deserve what they get; it's easy enough to 
:>>relink with NO REFR.
:>
:>Unfortunately at this late date, it probably will be a mission critical 
program last modified ten years ago by someone who has left the organization.  
The program or module in question may be even older.  Also it may be from an 
ISV that distributes object code only.
:>The using organization can be in a world of hurt.  Is there a bit available 
that could be used to denote REFRPROT ready?
:>
:>Clark Morris
:>>
:>>>Thus we made it an option and encouraged IBM code and ISV code to fix 
:>>>their binder attributes so that REFR could be used in this way, with 
:>>>the new processing enabled by use of REFRPROT.
:>>>
:>>Code residing authorized llibraries was strongly "encouraged", 
:>>regardless of the REFRPROT setting.  I suppose that's true additionaly 
:>>for end-user code.
:>>
:>>In the Program Management UG and Ref, I see:
:>>RENT
:>>... A reenterable module is ordinarily expected not to modify
:>>its own code. In some cases, MVS protects the reentrant module's
:>>virtual storage so that it cannot be modified except by a
:>>program running in key 0. These cases include programs which
:>>the system treats as having been loaded from an authorized
:>>library, ...
:>>
:>>Is that right?  It seems to be describing REFR, not RENT.  And the 
:>>"treats as" waffling?  Is that referring to LPA, regardless of

Re: APF authorization and AC(00)

[Randy Hudson]

In article <2376347398828975.wa.paulgboulderaim@listserv.ua.edu> you write:

> Point taken.  But it's not clear why the designers chose to allow a program
> to be both modifyable and reloadable.  This leads to dreadful 
> unpredictability:
> Behavior may differ depending on whether the program has been reloaded.
> OK.  Initialization code may set a flag (in each page?) that will be cleared 
> by
> a reload.  Critical code paths may check (before and after) that the flag 
> remains
> set and re-initialize if it's found cleared.  And the documentation should
> conscientiously mention the need to do this.  Ugh!

The REFR attribute has existed since MVT version 19 or so.  Core storage
then was really core storage... toroidal ferrite cores threaded on wires, at
a cost of a dollar a bit, or more.

Saving a few bytes is sneered at as false economy, now.  It wasn't, then.

A refreshable load module might have inititalization code that needs to be
run only once per time it's loaded, with that init code overwritten for
scratch storage afterward.  If the module's space is needed, the whole thing
gets overwritten.  Later it can be refreshed, and the initialization re-run.

Or, a module might contain a dynamically reorganized search table, such as a
move-to-front table.  That's storage modification, and it's hard to make it
re-entrant on a 360/65 with only TS as a locking mechanism.  But it can be
refreshable, reloading the initial configuration each time.

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

Re: APF authorization and AC(00)

[Jesse 1 Robinson]

I got tired of guessing. I wrote a little program that saves registers into 
itself via STM. I linked it with AC(1) and RENT. Did not specify either REUS or 
REFR. The result according to StarTool is 

--  ATTRIBUTES   - APF 
RENT REUS   AC

As suggested in the KC doc, REUS is set automatically as a subordinate of RENT, 
but REFR is not set. Result at execution:

If the module is executed from my personal non-APF library, it runs fine.

If the module is executed from an APF library, it get S0C4. 

I was dubious about 'RENT OK if execution is serialized'. This is a single 
execution in batch. No competition. It abends. I don't see how it could be 
otherwise. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Sunday, June 11, 2017 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: APF authorization and AC(00)

[Default] On 11 Jun 2017 13:39:47 -0700, in bit.listserv.ibm-main 
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:
>
>>A refreshable program cannot modify itself (or if it can, it would be 
>>a very interesting and perhaps self-limiting testcase).
>>
>I believe that if a program is marked REFR but loaded from a 
>non-authorized library and REFRPROT is not in effect, no error is 
>reported at that time.  Behavior is unpredictable when a refresh may 
>actually occur.
>
>>... A reentrant program
>>can, if written carefully, modify itself, although it is rarely a good idea.
>>LPA modules are generally, in effect, refreshable.
>> 
>Does this mean that REFRPROT "in effect" applies to LPA modules?
>
>>As to "why", think about it.
>>Page protection did not even exist at the time RENT and REFR were defined.
>>And over those 20-30 years, many many programs were incorrectly bound 
>>with "RENT,REFR" when in fact they were RENT but not REFR. But they 
>>worked fine given the way the system processed.
>>The combination was used indiscriminately, and often thought of as a pair.
>>Making it the default would be horribly incompatible.
>>
>It's like a child whining about a distasteful medicine: in the end it's 
>good for him and should be done, even as user key CSA has been disabled 
>(I think).
>
>Programmers who didn't RTFM deserve what they get; it's easy enough to 
>relink with NO REFR.

Unfortunately at this late date, it probably will be a mission critical program 
last modified ten years ago by someone who has left the organization.  The 
program or module in question may be even older.  Also it may be from an ISV 
that distributes object code only.
The using organization can be in a world of hurt.  Is there a bit available 
that could be used to denote REFRPROT ready?

Clark Morris
>
>>Thus we made it an option and encouraged IBM code and ISV code to fix 
>>their binder attributes so that REFR could be used in this way, with 
>>the new processing enabled by use of REFRPROT.
>>
>Code residing authorized llibraries was strongly "encouraged", 
>regardless of the REFRPROT setting.  I suppose that's true additionaly 
>for end-user code.
>
>In the Program Management UG and Ref, I see:
>RENT
>... A reenterable module is ordinarily expected not to modify
>its own code. In some cases, MVS protects the reentrant module's
>virtual storage so that it cannot be modified except by a
>program running in key 0. These cases include programs which
>the system treats as having been loaded from an authorized
>library, ...
>
>Is that right?  It seems to be describing REFR, not RENT.  And the 
>"treats as" waffling?  Is that referring to LPA, regardless of load 
>module attributes?  And "include" hints at other cases, not mentioned.
>
>>And, yes, it is a performance consideration. Not a huge one, but one 
>>nevertheless.
>
>-- gil


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

Re: APF authorization and AC(00)

[J R]

Another question:  Wasn't REFR for SVC type 3/4 modules so that they could be 
refreshed in the transient area following preemption without fear that they may 
have been modified prior to being preempted?  

Sent from my iPhone

> On Jun 11, 2017, at 20:52, Steve Thompson  wrote:
> 
> Question: Wasn't REFR for a program where, say a double-bit parity error 
> could occur, and it would then get loaded to a new page?

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

Re: APF authorization and AC(00)

[J R]

Another question:  Wasn't REFR for SVC type 3/4 modules so that they could be 
refreshed in the transient area following preemption without fear that they may 
have been modified prior to being preempted?  

Sent from my iPhone

> On Jun 11, 2017, at 20:52, Steve Thompson  wrote:
> 
>> On 06/11/2017 05:33 PM, Walt Farrell wrote:
>>> On Sun, 11 Jun 2017 15:40:49 -0500, Paul Gilmartin  
>>> wrote:
>>> In the Program Management UG and Ref, I see:
>>> RENT
>>>... A reenterable module is ordinarily expected not to modify
>>>its own code. In some cases, MVS protects the reentrant module's
>>>virtual storage so that it cannot be modified except by a
>>>program running in key 0. These cases include programs which
>>>the system treats as having been loaded from an authorized
>>>library, ...
>>> 
>>> Is that right?  It seems to be describing REFR, not RENT.  And
>>> the "treats as" waffling?  Is that referring to LPA, regardless of
>>> load module attributes?  And "include" hints at other cases, not
>>> mentioned.
>> It's descibing RENT, because for programs linked as RENT MVS places the load 
>> module into key 0 storage if the program was loaded from a library treated 
>> as APF-authorized. Such programs can modify themselves if running in key 0.
>> If they were REFR, and REFRPROT were in effect, they would be in key 0 
>> storage and page-protected, and could not modify themselves.
> 
> 
> 
> Question: Wasn't REFR for a program where, say a double-bit parity error 
> could occur, and it would then get loaded to a new page?
> 
> Regards,
> Steve Thompson
> 
> --
> 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 authorization and AC(00)

[Steve Thompson]

On 06/11/2017 05:33 PM, Walt Farrell wrote:

On Sun, 11 Jun 2017 15:40:49 -0500, Paul Gilmartin  wrote:


In the Program Management UG and Ref, I see:
RENT
... A reenterable module is ordinarily expected not to modify
its own code. In some cases, MVS protects the reentrant module's
virtual storage so that it cannot be modified except by a
program running in key 0. These cases include programs which
the system treats as having been loaded from an authorized
library, ...

Is that right?  It seems to be describing REFR, not RENT.  And
the "treats as" waffling?  Is that referring to LPA, regardless of
load module attributes?  And "include" hints at other cases, not
mentioned.


It's descibing RENT, because for programs linked as RENT MVS places the load 
module into key 0 storage if the program was loaded from a library treated as 
APF-authorized. Such programs can modify themselves if running in key 0.

If they were REFR, and REFRPROT were in effect, they would be in key 0 storage 
and page-protected, and could not modify themselves.




Question: Wasn't REFR for a program where, say a double-bit 
parity error could occur, and it would then get loaded to a new page?


Regards,
Steve Thompson

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

Re: APF authorization and AC(00)

[Clark Morris]

[Default] On 11 Jun 2017 13:39:47 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:
>
>>A refreshable program cannot modify itself (or if it can, it would be a 
>>very interesting and perhaps self-limiting testcase).
>>
>I believe that if a program is marked REFR but loaded from a
>non-authorized library and REFRPROT is not in effect, no error
>is reported at that time.  Behavior is unpredictable when
>a refresh may actually occur.
>
>>... A reentrant program 
>>can, if written carefully, modify itself, although it is rarely a good idea.
>>LPA modules are generally, in effect, refreshable.
>> 
>Does this mean that REFRPROT "in effect" applies to LPA modules?
>
>>As to "why", think about it.
>>Page protection did not even exist at the time RENT and REFR were defined.
>>And over those 20-30 years, many many programs were incorrectly bound with 
>>"RENT,REFR" when in fact they were RENT but not REFR. But they worked fine 
>>given the way the system processed.
>>The combination was used indiscriminately, and often thought of as a pair.
>>Making it the default would be horribly incompatible.
>>
>It's like a child whining about a distasteful medicine: in the
>end it's good for him and should be done, even as user key
>CSA has been disabled (I think).
>
>Programmers who didn't RTFM deserve what they get; it's easy
>enough to relink with NO REFR.

Unfortunately at this late date, it probably will be a mission
critical program last modified ten years ago by someone who has left
the organization.  The program or module in question may be even
older.  Also it may be from an ISV that distributes object code only.
The using organization can be in a world of hurt.  Is there a bit
available that could be used to denote REFRPROT ready?

Clark Morris
>
>>Thus we made it an option and encouraged IBM code and ISV code to fix 
>>their binder attributes so that REFR could be used in this way, with the 
>>new processing enabled by use of REFRPROT.
>>
>Code residing authorized llibraries was strongly "encouraged",
>regardless of the REFRPROT setting.  I suppose that's true
>additionaly for end-user code.
>
>In the Program Management UG and Ref, I see:
>RENT
>... A reenterable module is ordinarily expected not to modify
>its own code. In some cases, MVS protects the reentrant module's
>virtual storage so that it cannot be modified except by a
>program running in key 0. These cases include programs which
>the system treats as having been loaded from an authorized
>library, ...
>
>Is that right?  It seems to be describing REFR, not RENT.  And
>the "treats as" waffling?  Is that referring to LPA, regardless of
>load module attributes?  And "include" hints at other cases, not
>mentioned.
>
>>And, yes, it is a performance consideration. Not a huge one, but one 
>>nevertheless.
>
>-- 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: APF authorization and AC(00)

[Walt Farrell]

On Sun, 11 Jun 2017 15:40:49 -0500, Paul Gilmartin  wrote:

>In the Program Management UG and Ref, I see:
>RENT
>... A reenterable module is ordinarily expected not to modify
>its own code. In some cases, MVS protects the reentrant module's
>virtual storage so that it cannot be modified except by a
>program running in key 0. These cases include programs which
>the system treats as having been loaded from an authorized
>library, ...
>
>Is that right?  It seems to be describing REFR, not RENT.  And
>the "treats as" waffling?  Is that referring to LPA, regardless of
>load module attributes?  And "include" hints at other cases, not
>mentioned.

It's descibing RENT, because for programs linked as RENT MVS places the load 
module into key 0 storage if the program was loaded from a library treated as 
APF-authorized. Such programs can modify themselves if running in key 0.

If they were REFR, and REFRPROT were in effect, they would be in key 0 storage 
and page-protected, and could not modify themselves.

(In general, I think that programs that are REFR should also be RENT, but I 
don't know if the binder enforces that.)

LPA is certainly one case where the "treated as authorized" applies for 
libraries. I don't recall if there are others, but Peter or Jim will probably 
know :)

-- 
Walt

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

Re: APF authorization and AC(00)

[Steve Smith]

RENT means only one copy of a module needs to be loaded for a job.
REFR means the module doesn't need to be paged out.

All else is implications and assumptions.  Note that neither of the above
strictly require a non-modifiable module.  The idea is that the results are
always the same regardless of simultaneous execution, or refreshing,
respectively.

Both the key-0 protection and the REFRPROT facility *assume* those
attributes imply non-modifiability.  Sure, they usually do, but why they
didn't just create a new "NMOD" (say) attribute and squelch the confusion?

And the scientific definition of reentrancy can be (fairly easily) violated
by by a program that never modifies itself.  All it takes is naive or
careless use of a common resource.

sas

On Sun, Jun 11, 2017 at 3:40 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:
>
> >A refreshable program cannot modify itself (or if it can, it would be a
> >very interesting and perhaps self-limiting testcase).
> >
> I believe that if a program is marked REFR but loaded from a
> non-authorized library and REFRPROT is not in effect, no error
> is reported at that time.  Behavior is unpredictable when
> a refresh may actually occur.
>
> >... A reentrant program
> >can, if written carefully, modify itself, although it is rarely a good
> idea.
> >LPA modules are generally, in effect, refreshable.
> >
> Does this mean that REFRPROT "in effect" applies to LPA modules?
>
> >As to "why", think about it.
> >Page protection did not even exist at the time RENT and REFR were defined.
> >And over those 20-30 years, many many programs were incorrectly bound with
> >"RENT,REFR" when in fact they were RENT but not REFR. But they worked fine
> >given the way the system processed.
> >The combination was used indiscriminately, and often thought of as a pair.
> >Making it the default would be horribly incompatible.
> >
> It's like a child whining about a distasteful medicine: in the
> end it's good for him and should be done, even as user key
> CSA has been disabled (I think).
>
> Programmers who didn't RTFM deserve what they get; it's easy
> enough to relink with NO REFR.
>
> >Thus we made it an option and encouraged IBM code and ISV code to fix
> >their binder attributes so that REFR could be used in this way, with the
> >new processing enabled by use of REFRPROT.
> >
> Code residing authorized llibraries was strongly "encouraged",
> regardless of the REFRPROT setting.  I suppose that's true
> additionaly for end-user code.
>
> In the Program Management UG and Ref, I see:
> RENT
> ... A reenterable module is ordinarily expected not to modify
> its own code. In some cases, MVS protects the reentrant module's
> virtual storage so that it cannot be modified except by a
> program running in key 0. These cases include programs which
> the system treats as having been loaded from an authorized
> library, ...
>
> Is that right?  It seems to be describing REFR, not RENT.  And
> the "treats as" waffling?  Is that referring to LPA, regardless of
> load module attributes?  And "include" hints at other cases, not
> mentioned.
>
> >And, yes, it is a performance consideration. Not a huge one, but one
> >nevertheless.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: APF authorization and AC(00)

[Paul Gilmartin]

On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:

>A refreshable program cannot modify itself (or if it can, it would be a 
>very interesting and perhaps self-limiting testcase).
>
I believe that if a program is marked REFR but loaded from a
non-authorized library and REFRPROT is not in effect, no error
is reported at that time.  Behavior is unpredictable when
a refresh may actually occur.

>... A reentrant program 
>can, if written carefully, modify itself, although it is rarely a good idea.
>LPA modules are generally, in effect, refreshable.
> 
Does this mean that REFRPROT "in effect" applies to LPA modules?

>As to "why", think about it.
>Page protection did not even exist at the time RENT and REFR were defined.
>And over those 20-30 years, many many programs were incorrectly bound with 
>"RENT,REFR" when in fact they were RENT but not REFR. But they worked fine 
>given the way the system processed.
>The combination was used indiscriminately, and often thought of as a pair.
>Making it the default would be horribly incompatible.
>
It's like a child whining about a distasteful medicine: in the
end it's good for him and should be done, even as user key
CSA has been disabled (I think).

Programmers who didn't RTFM deserve what they get; it's easy
enough to relink with NO REFR.

>Thus we made it an option and encouraged IBM code and ISV code to fix 
>their binder attributes so that REFR could be used in this way, with the 
>new processing enabled by use of REFRPROT.
>
Code residing authorized llibraries was strongly "encouraged",
regardless of the REFRPROT setting.  I suppose that's true
additionaly for end-user code.

In the Program Management UG and Ref, I see:
RENT
... A reenterable module is ordinarily expected not to modify
its own code. In some cases, MVS protects the reentrant module's
virtual storage so that it cannot be modified except by a
program running in key 0. These cases include programs which
the system treats as having been loaded from an authorized
library, ...

Is that right?  It seems to be describing REFR, not RENT.  And
the "treats as" waffling?  Is that referring to LPA, regardless of
load module attributes?  And "include" hints at other cases, not
mentioned.

>And, yes, it is a performance consideration. Not a huge one, but one 
>nevertheless.

-- gil

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

Re: APF authorization and AC(00)

[Peter Relson]

A refreshable program cannot modify itself (or if it can, it would be a 
very interesting and perhaps self-limiting testcase). A reentrant program 
can, if written carefully, modify itself, although it is rarely a good 
idea.
LPA modules are generally, in effect, refreshable.

As to "why", think about it.
Page protection did not even exist at the time RENT and REFR were defined.
And over those 20-30 years, many many programs were incorrectly bound with 
"RENT,REFR" when in fact they were RENT but not REFR. But they worked fine 
given the way the system processed.
The combination was used indiscriminately, and often thought of as a pair.
Making it the default would be horribly incompatible.

Thus we made it an option and encouraged IBM code and ISV code to fix 
their binder attributes so that REFR could be used in this way, with the 
new processing enabled by use of REFRPROT.

And, yes, it is a performance consideration. Not a huge one, but one 
nevertheless.

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: APF authorization and AC(00)

[Binyamin Dissen]

They are not technically the same.

A REFR program can be reloaded at any time. Therefore it cannot self modify as
it cannot know if it has been reloaded. But if it uses common/global areas
without serialization it is not reentrant.

A RENT program is one that can be executed concurrently by multiple thread. It
can self modify as long as a semaphore is used to block the critical section
that self modifies.

REFR+RENT is the commonly understood MVS instantiation of reentrant.

On Sun, 11 Jun 2017 16:59:23 + Jesse 1 Robinson 
wrote:

:>I was very surprised by Chris Poncelet's post, so I used Goggle to find this 
doc:

:>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/iea3b1_Module_reusability.htm

:>Blew me away. I knew the definition of RENT and REFR, but I believed that 
both attributes were set in combination if either one was specified. So what is 
the difference *in practice* between RENT and REUS? Both seem to imply that a 
module can be executed successively by multiple callers. Furthermore, in 
practice, who in the world would bother with ENQ/DEQ rigmarole to serialize 
execution of a RENT module instead of just coding it REFR in the first place? 
REFR is not that difficult if you set out to do it from the get-go. 

:>And last, what would happen if a self-modifying RENT module were in fact 
executed concurrently by multiple callers without ENQ/DEQ? Incorrect result? 
Abend? I'm verklempt. 

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

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: APF authorization and AC(00)

[Jesse 1 Robinson]

I was very surprised by Chris Poncelet's post, so I used Goggle to find this 
doc:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/iea3b1_Module_reusability.htm

Blew me away. I knew the definition of RENT and REFR, but I believed that both 
attributes were set in combination if either one was specified. So what is the 
difference *in practice* between RENT and REUS? Both seem to imply that a 
module can be executed successively by multiple callers. Furthermore, in 
practice, who in the world would bother with ENQ/DEQ rigmarole to serialize 
execution of a RENT module instead of just coding it REFR in the first place? 
REFR is not that difficult if you set out to do it from the get-go. 

And last, what would happen if a self-modifying RENT module were in fact 
executed concurrently by multiple callers without ENQ/DEQ? Incorrect result? 
Abend? I'm verklempt. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Saturday, June 10, 2017 7:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: APF authorization and AC(00)

Not AFAIK. In theory, a RENT program may modify one of its sections provided 
that this section is preceded by an ENQ, then modified, then restored to its 
original value and then DEQ'd - to ensure that only one user can execute the 
modifying section of code at any one time. It is a REFR program that may never 
modify itself in any way.

(The "RENT" just means it can be executed concurrently by multiple users
- although some might have to wait for a DEQ. The "REFR" means it can be 
reloaded exactly asis from DASD at any time whilst it is still being executed, 
e.g. back into the PLPA after a page-steal by the RSM.)

Chris Poncelet (retired sysprog)



On 11/06/2017 00:41, Charles Mills wrote:
> A refreshable program may modify itself, right? REFR does not say "I don't 
> modify myself" it says "you can reload me if you want." Almost the same 
> thing, but not quite.
> 
> Granted, modifying program storage is a bad idea -- in any event.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Saturday, June 10, 2017 7:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
> 
> On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:
> 
>>> REFRPROT extends this to programs that are not loaded from an APF 
>>> authorized library.
>>
>> Actually, REFRPROT extends this to programs that are bound with the 
>> REFR option regardless of module authorization or library authorization.
>> And it goes further because it page-protects, which would cause the 
>> program to blow up even if were running key 0 if it attempted to 
>> store into itself.
>>
> I remain mystified,  Why was not the REFRPROT behavior the default (or only) 
> behavior ever since the inception of the REFR attribute?
> o Is there a performance penalty for REFRPROT that developers
>   wanted to circumvent for problem programs?  Contrariwise, it seems
>   that coding a test for the authorized status of the load library was
>   needless effort.
> o Did the developers assume, very incorrectly IMO, that they were
>   extending a courtesy to application programmers by permitting
>   programs that modified themselves to be marked REFR?


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

Re: APF authorization and AC(00)

[Jim Mulder]

  Your mystification is apparently due to poor memory.  I suggest
that you review the archives for the subject::  REFRPROT History Question,
a thread which you started on March 1, 2013.

  In particular, see my answers in 

https://listserv.ua.edu/cgi-bin/wa?A2=ind1303=IBM-MAIN=R2798=-3=-=d10jhm1%40us.ibm.com=No+Match%3BMatch%3BMatches

  And there is a performance cost for the page-protecting aspect
of REFRPROT.  Turning on the protection bit in the PTE
for a page that is already valid requires some type of broadcast TLB 
purging operation.  We accomplish this by doing an IPTE to invalidate 
the page before turn on the protection bit. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
06/10/2017 10:54:15 AM:

> From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/10/2017 09:55 PM
> Subject: Re: APF authorization and AC(00)
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:
> 
> >>REFRPROT extends this to programs that are not loaded from an 
> >>APF authorized library.
> >
> >Actually, REFRPROT extends this to programs that are bound with the 
REFR 
> >option regardless of module authorization or library authorization.
> >And it goes further because it page-protects, which would cause the 
> >program to blow up even if were running key 0 if it attempted to store 
> >into itself.
> > 
> I remain mystified,  Why was not the REFRPROT behavior the default
> (or only) behavior ever since the inception of the REFR attribute?
> o Is there a performance penalty for REFRPROT that developers
>   wanted to circumvent for problem programs?  Contrariwise, it seems
>   that coding a test for the authorized status of the load library was
>   needless effort.
> o Did the developers assume, very incorrectly IMO, that they were
>   extending a courtesy to application programmers by permitting
>   programs that modified themselves to be marked REFR?
> 
> -- gil



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

Re: APF authorization and AC(00)

[Paul Gilmartin]

On Sat, 10 Jun 2017 19:15:11 -0500, Walt Farrell wrote:

>On Sat, 10 Jun 2017 16:41:16 -0700, Charles Mills wrote:
>
>>A refreshable program may modify itself, right? REFR does not say "I don't 
>>modify myself" it says "you can reload me if you want." Almost >the same 
>>thing, but not quite.
>
>The key, I think, is that the system may reload the program at _any_ time, 
>even on the instruction immediately after it modifies itself. Therefore, there 
>is no _safe_ way for a refreshable program to do such a modification, as it 
>cannot make any assumptions about how long the modification will survive. At 
>least a RENT program can use serialization to allow safe modifications (FSVO 
>"safe"), but a REFR program doesn't have that ability.
> 
Yet, until the advent of REFRPROT (still not the default!), REFR programs were
allowed to modify themselves.

Repeating my earlier suggestion:  set a flag in initialization (would CS 
suffice?)
test the flag before and after critical code sections; re-initialize if 
necessary.
I'm not saying it's worth it, nor that I recommend it, only that IBM allows it.
At least REFRPROT should be the default.

-- gil

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

Re: APF authorization and AC(00)

[Paul Gilmartin]

On Sat, 10 Jun 2017 16:41:16 -0700, Charles Mills wrote:

>A refreshable program may modify itself, right? REFR does not say "I don't 
>modify myself" it says "you can reload me if you want." Almost the same thing, 
>but not quite.
> 
Point taken.  But it's not clear why the designers chose to allow a program
to be both modifyable and reloadable.  This leads to dreadful unpredictability:
Behavior may differ depending on whether the program has been reloaded.
OK.  Initialization code may set a flag (in each page?) that will be cleared by
a reload.  Critical code paths may check (before and after) that the flag 
remains
set and re-initialize if it's found cleared.  And the documentation should
conscientiously mention the need to do this.  Ugh!

>Granted, modifying program storage is a bad idea -- in any event.
>
Yes.

Conceivably, a program could be REFR but not RENT.  z/OS components
no longer support this.

>-Original Message-
>From: Of Paul Gilmartin
>Sent: Saturday, June 10, 2017 7:54 AM
>
>On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:
>
>>>REFRPROT extends this to programs that are not loaded from an APF 
>>>authorized library.
>>
>>Actually, REFRPROT extends this to programs that are bound with the 
>>REFR option regardless of module authorization or library authorization.
>>And it goes further because it page-protects, which would cause the 
>>program to blow up even if were running key 0 if it attempted to store 
>>into itself.
>> 
>I remain mystified,  Why was not the REFRPROT behavior the default (or only) 
>behavior ever since the inception of the REFR attribute?
>o Is there a performance penalty for REFRPROT that developers
>  wanted to circumvent for problem programs?  Contrariwise, it seems
>  that coding a test for the authorized status of the load library was
>  needless effort.
>o Did the developers assume, very incorrectly IMO, that they were
>  extending a courtesy to application programmers by permitting
>  programs that modified themselves to be marked REFR?

-- gil

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

Re: APF authorization and AC(00)

[Charles Mills]

A refreshable program may modify itself, right? REFR does not say "I don't 
modify myself" it says "you can reload me if you want." Almost the same thing, 
but not quite.

Granted, modifying program storage is a bad idea -- in any event.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, June 10, 2017 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:

>>REFRPROT extends this to programs that are not loaded from an APF 
>>authorized library.
>
>Actually, REFRPROT extends this to programs that are bound with the 
>REFR option regardless of module authorization or library authorization.
>And it goes further because it page-protects, which would cause the 
>program to blow up even if were running key 0 if it attempted to store 
>into itself.
> 
I remain mystified,  Why was not the REFRPROT behavior the default (or only) 
behavior ever since the inception of the REFR attribute?
o Is there a performance penalty for REFRPROT that developers
  wanted to circumvent for problem programs?  Contrariwise, it seems
  that coding a test for the authorized status of the load library was
  needless effort.
o Did the developers assume, very incorrectly IMO, that they were
  extending a courtesy to application programmers by permitting
  programs that modified themselves to be marked REFR?

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

Re: APF authorization and AC(00)

[scott Ford]

Wow a seal team 6 member ...

On Sat, Jun 10, 2017 at 10:54 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:
>
> >>REFRPROT extends this to programs that are not loaded from an
> >>APF authorized library.
> >
> >Actually, REFRPROT extends this to programs that are bound with the REFR
> >option regardless of module authorization or library authorization.
> >And it goes further because it page-protects, which would cause the
> >program to blow up even if were running key 0 if it attempted to store
> >into itself.
> >
> I remain mystified,  Why was not the REFRPROT behavior the default
> (or only) behavior ever since the inception of the REFR attribute?
> o Is there a performance penalty for REFRPROT that developers
>   wanted to circumvent for problem programs?  Contrariwise, it seems
>   that coding a test for the authorized status of the load library was
>   needless effort.
> o Did the developers assume, very incorrectly IMO, that they were
>   extending a courtesy to application programmers by permitting
>   programs that modified themselves to be marked REFR?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: APF authorization and AC(00)

[Paul Gilmartin]

On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote:

>>REFRPROT extends this to programs that are not loaded from an 
>>APF authorized library.
>
>Actually, REFRPROT extends this to programs that are bound with the REFR 
>option regardless of module authorization or library authorization.
>And it goes further because it page-protects, which would cause the 
>program to blow up even if were running key 0 if it attempted to store 
>into itself.
> 
I remain mystified,  Why was not the REFRPROT behavior the default
(or only) behavior ever since the inception of the REFR attribute?
o Is there a performance penalty for REFRPROT that developers
  wanted to circumvent for problem programs?  Contrariwise, it seems
  that coding a test for the authorized status of the load library was
  needless effort.
o Did the developers assume, very incorrectly IMO, that they were
  extending a courtesy to application programmers by permitting
  programs that modified themselves to be marked REFR?

-- gil

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

Re: APF authorization and AC(00)

[Peter Relson]

>REFRPROT extends this to programs that are not loaded from an 
>APF authorized library.

Actually, REFRPROT extends this to programs that are bound with the REFR 
option regardless of module authorization or library authorization.
And it goes further because it page-protects, which would cause the 
program to blow up even if were running key 0 if it attempted to store 
into itself.

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

was Re: APF authorization and AC(00)n now 0 dark thirty call

[Edward Gould]

> On Jun 9, 2017, at 4:25 PM, Jesse 1 Robinson  wrote:
> 
> One of my very first oh dark thirty wake up calls. I had tested thoroughly 
> using a public test library. All good. Copied the module carefully to the 
> production counterpart. Went home. Boom. 
> 
> The lessons you learn earliest are the ones you remember best. ;-)
> ——_SNIP—

I think my first in private sector 0 dark 30 call was the application people 
decided that they wanted their files in VBS format (to save tape?) .
After much research the compiler didn’t support it (a LONG time ago).
After some JCL changes . The tape was created and then read successfully by a 
later program. 
I suggested to the application people RTFM before doing something like this in 
the future.

Ed

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

Re: APF authorization and AC(00)

[Jesse 1 Robinson]

One of my very first oh dark thirty wake up calls. I had tested thoroughly 
using a public test library. All good. Copied the module carefully to the 
production counterpart. Went home. Boom. 

The lessons you learn earliest are the ones you remember best. ;-)

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: APF authorization and AC(00)

Yup, I'm sure you are right. Lying to the binder didn't (obviously) matter when 
the program object was in a non-APF-authorized library, but it did matter when 
it was in an authorized library for the reasons discussed below.

In any event, lying to the binder is a terrible practice, and I'll correct this 
by (probably) telling the compiler to emit reentrant code - or by telling the 
binder it's not reentrant after all.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dan Little
Sent: Friday, June 09, 2017 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

I think you need RENT on your PL/1 compile because otherwise there is no 
guaranteed the generated code will be re-entrant.

General rule is if RENT on bind/LinkedIn then you must have RENT on high level 
language compile.

Dan

On Jun 9, 2017, 16:26 -0400, Leonardo Vaz <leonardo@cn.ca>, wrote:
> Ow, I missed the source, sorry.
>
> Ok, so I believe a program loaded from an authorized library, even if it's 
> not AC=1, will be loaded by contents supervisor with KEY=0 if it's reentrant, 
> but with KEY=8 if it's non-reentrant, so that's why you got the S0C4 
> originally.
>
> Regards,
> Leo
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Problem solved, per the suggestions below!!
>
> In particular, the program is apparently NOT reentrant, yet the binder was 
> being told it was.
>
> For some reason, this doesn't seem to matter (in this case) when the library 
> isn't APF-autorized, yet results in a S0C4 when it is.
>
> That part is still a bit of a puzzle.
>
> But removing RENT from the bind step gets me past this.
>
> Thanks again
>
> Rich Wa
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 1:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> The source code is actually below - it's just a "hello world". But agreed I 
> need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
> debug it, but was the ONLY difference between the version that worked and the 
> version that didn't - and I confirmed that by revoking and reinstating APF 
> auth on the library.
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Right, without the source code we can only guess, but the program might be 
> issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" 
> "Authorized library" bit to try and do something it wouldn't do if that bit 
> was off, maybe they forgot to check the "Authorized program" bit as well.
>
> That is, considering the only variable is the library being APF'd or not.
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Thanks, but it's a simple
>
> //XYZ EXEC PGM=ZPXPLIA
>
> So, yeah, it's a jobstep task. And while I can see how NOT having 
> authorization might cause a problem (specifically, an S047), I don't see why 
> *having* authorization would cause a problem...
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 12:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> As far as I understand, AC=0 would o

Re: APF authorization and AC(00)

[Way, Richard]

Yup, I'm sure you are right. Lying to the binder didn't (obviously) matter when 
the program object was in a non-APF-authorized library, but it did matter when 
it was in an authorized library for the reasons discussed below.

In any event, lying to the binder is a terrible practice, and I'll correct this 
by (probably) telling the compiler to emit reentrant code - or by telling the 
binder it's not reentrant after all.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dan Little
Sent: Friday, June 09, 2017 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

I think you need RENT on your PL/1 compile because otherwise there is no 
guaranteed the generated code will be re-entrant.

General rule is if RENT on bind/LinkedIn then you must have RENT on high level 
language compile.

Dan

On Jun 9, 2017, 16:26 -0400, Leonardo Vaz <leonardo@cn.ca>, wrote:
> Ow, I missed the source, sorry.
>
> Ok, so I believe a program loaded from an authorized library, even if it's 
> not AC=1, will be loaded by contents supervisor with KEY=0 if it's reentrant, 
> but with KEY=8 if it's non-reentrant, so that's why you got the S0C4 
> originally.
>
> Regards,
> Leo
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Problem solved, per the suggestions below!!
>
> In particular, the program is apparently NOT reentrant, yet the binder was 
> being told it was.
>
> For some reason, this doesn't seem to matter (in this case) when the library 
> isn't APF-autorized, yet results in a S0C4 when it is.
>
> That part is still a bit of a puzzle.
>
> But removing RENT from the bind step gets me past this.
>
> Thanks again
>
> Rich Wa
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 1:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> The source code is actually below - it's just a "hello world". But agreed I 
> need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
> debug it, but was the ONLY difference between the version that worked and the 
> version that didn't - and I confirmed that by revoking and reinstating APF 
> auth on the library.
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Right, without the source code we can only guess, but the program might be 
> issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" 
> "Authorized library" bit to try and do something it wouldn't do if that bit 
> was off, maybe they forgot to check the "Authorized program" bit as well.
>
> That is, considering the only variable is the library being APF'd or not.
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Thanks, but it's a simple
>
> //XYZ EXEC PGM=ZPXPLIA
>
> So, yeah, it's a jobstep task. And while I can see how NOT having 
> authorization might cause a problem (specifically, an S047), I don't see why 
> *having* authorization would cause a problem...
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 12:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> As far as I understand, AC=0 would only prevent authorization of the JSCB if 
> it is the program being attached as a jobstep task, if this program is being 
> called by an already-existing authorized task, it would run authorized.
>
> The question is: How is control passed to program ZPXPLIA?
>
> Regards,
> Leo
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 3:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: APF authorization and AC(00)
>
> Simple question, but the behavior I am seeing flies in the face of what I 
> *thought* I knew about APF authorizati

Re: APF authorization and AC(00)

[Tom Marchant]

On Fri, 9 Jun 2017 16:10:28 -0400, Don Poitras wrote:

>I don't see what 0C4 is telling you vis-a-vis APF authorization. I think it's
>more likely that you've told the binder that the program is RENT and it's
>not. If you have REFRPROT set in your PROGxx parmlib member, then it's going
>to get loaded into read-only storage and when it tries to modify itself, it
>gets the 0C4. i.e. I'd debug the 0C4 rather than randomly changing link
>options or library locations.

Programs that are marked RENT and loaded from an APF authorized library 
are loaded into key zero strorage that is not fetch protected. As a result, 
a problem program running in key 8 will S0C4 if it tries to modify it.

REFRPROT extends this to programs that are not loaded from an APF 
authorized library.

-- 
Tom Marchant

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

Re: APF authorization and AC(00)

[Dan Little]

I think you need RENT on your PL/1 compile because otherwise there is no 
guaranteed the generated code will be re-entrant.

General rule is if RENT on bind/LinkedIn then you must have RENT on high level 
language compile.

Dan

On Jun 9, 2017, 16:26 -0400, Leonardo Vaz <leonardo@cn.ca>, wrote:
> Ow, I missed the source, sorry.
>
> Ok, so I believe a program loaded from an authorized library, even if it's 
> not AC=1, will be loaded by contents supervisor with KEY=0 if it's reentrant, 
> but with KEY=8 if it's non-reentrant, so that's why you got the S0C4 
> originally.
>
> Regards,
> Leo
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Problem solved, per the suggestions below!!
>
> In particular, the program is apparently NOT reentrant, yet the binder was 
> being told it was.
>
> For some reason, this doesn't seem to matter (in this case) when the library 
> isn't APF-autorized, yet results in a S0C4 when it is.
>
> That part is still a bit of a puzzle.
>
> But removing RENT from the bind step gets me past this.
>
> Thanks again
>
> Rich Wa
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 1:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> The source code is actually below - it's just a "hello world". But agreed I 
> need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
> debug it, but was the ONLY difference between the version that worked and the 
> version that didn't - and I confirmed that by revoking and reinstating APF 
> auth on the library.
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Right, without the source code we can only guess, but the program might be 
> issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" 
> "Authorized library" bit to try and do something it wouldn't do if that bit 
> was off, maybe they forgot to check the "Authorized program" bit as well.
>
> That is, considering the only variable is the library being APF'd or not.
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Thanks, but it's a simple
>
> //XYZ EXEC PGM=ZPXPLIA
>
> So, yeah, it's a jobstep task. And while I can see how NOT having 
> authorization might cause a problem (specifically, an S047), I don't see why 
> *having* authorization would cause a problem...
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 12:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> As far as I understand, AC=0 would only prevent authorization of the JSCB if 
> it is the program being attached as a jobstep task, if this program is being 
> called by an already-existing authorized task, it would run authorized.
>
> The question is: How is control passed to program ZPXPLIA?
>
> Regards,
> Leo
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 3:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: APF authorization and AC(00)
>
> Simple question, but the behavior I am seeing flies in the face of what I 
> *thought* I knew about APF authorization.
>
> The crux of it is - I have a program object that is linked AC(00). When this 
> program is executed out of an APF-authorized library, it S0C4s. When I revoke 
> the authorization on the library and re-run the test, it works.
>
> I had been under the (maybe-mistaken) impression that if you didn't have 
> *both* AC(1) *and* be running out of an APF-authed library, you wouldn't get 
> APF authorization - so I thought that the AC(00) version should work just 
> fine out of the APF-authorized library - but it doesn't.
>
> Any help would be appreciated.
>
> Additional facts: program is PL/I (LE), chopped 

Re: APF authorization and AC(00)

[Leonardo Vaz]

Ow, I missed the source, sorry.

Ok, so I believe a program loaded from an authorized library, even if it's not 
AC=1, will be loaded by contents supervisor with KEY=0 if it's reentrant, but 
with KEY=8 if it's non-reentrant, so that's why you got the S0C4 originally.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Problem solved, per the suggestions below!! 

In particular, the program is apparently NOT reentrant, yet the binder was 
being told it was.

For some reason, this doesn't seem to matter (in this case) when the library 
isn't APF-autorized, yet results in a S0C4 when it is.

That part is still a bit of a puzzle.

But removing RENT from the bind step gets me past this.

Thanks again

Rich Wa

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

The source code is actually below - it's just a "hello world". But agreed I 
need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
debug it, but was the ONLY difference between the version that worked and the 
version that didn't - and I confirmed that by revoking and reinstating APF auth 
on the library.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Right, without the source code we can only guess, but the program might be 
issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" "Authorized 
library" bit to try and do something it wouldn't do if that bit was off, maybe 
they forgot to check the "Authorized program" bit as well.

That is, considering the only variable is the library being APF'd or not.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Thanks, but it's a simple

//XYZ EXEC PGM=ZPXPLIA

So, yeah, it's a jobstep task. And while I can see how NOT having authorization 
might cause a problem (specifically, an S047), I don't see why *having* 
authorization would cause a problem...

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = gen

Re: APF authorization and AC(00)

[Way, Richard]

Oh duh - re-reading Don's note and this isn't even a puzzle any more.

Thanks again, Don and others.

Rich Way

-Original Message-
From: Way, Richard 
Sent: Friday, June 09, 2017 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: APF authorization and AC(00)

Problem solved, per the suggestions below!! 

In particular, the program is apparently NOT reentrant, yet the binder was 
being told it was.

For some reason, this doesn't seem to matter (in this case) when the library 
isn't APF-autorized, yet results in a S0C4 when it is.

That part is still a bit of a puzzle.

But removing RENT from the bind step gets me past this.

Thanks again

Rich Wa

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

The source code is actually below - it's just a "hello world". But agreed I 
need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
debug it, but was the ONLY difference between the version that worked and the 
version that didn't - and I confirmed that by revoking and reinstating APF auth 
on the library.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Right, without the source code we can only guess, but the program might be 
issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" "Authorized 
library" bit to try and do something it wouldn't do if that bit was off, maybe 
they forgot to check the "Authorized program" bit as well.

That is, considering the only variable is the library being APF'd or not.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Thanks, but it's a simple

//XYZ EXEC PGM=ZPXPLIA

So, yeah, it's a jobstep task. And while I can see how NOT having authorization 
might cause a problem (specifically, an S047), I don't see why *having* 
authorization would cause a problem...

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SH

Re: APF authorization and AC(00)

[Steve Smith]

RENT modules are loaded into protected storage only when from an authorized
library.  N.B> not "if authorized", not if "AC=1".  Exactly as stated.

Now you know everything :-)

sas

On Fri, Jun 9, 2017 at 3:23 PM, Way, Richard <richard@hpe.com> wrote:

> Problem solved, per the suggestions below!!
>
> In particular, the program is apparently NOT reentrant, yet the binder was
> being told it was.
>
> For some reason, this doesn't seem to matter (in this case) when the
> library isn't APF-autorized, yet results in a S0C4 when it is.
>
> That part is still a bit of a puzzle.
>
> But removing RENT from the bind step gets me past this.
>
> Thanks again
>
> Rich Wa
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 1:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> The source code is actually below - it's just a "hello world". But agreed
> I need to dig into the S0C4. The APF issue wasn't the result of an attempt
> to debug it, but was the ONLY difference between the version that worked
> and the version that didn't - and I confirmed that by revoking and
> reinstating APF auth on the library.
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Right, without the source code we can only guess, but the program might be
> issuing a CSVQUERY to verify its state and relying on ",OUTATTR2="
> "Authorized library" bit to try and do something it wouldn't do if that bit
> was off, maybe they forgot to check the "Authorized program" bit as well.
>
> That is, considering the only variable is the library being APF'd or not.
>
> Regards,
> Leo
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 4:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> Thanks, but it's a simple
>
> //XYZ EXEC PGM=ZPXPLIA
>
> So, yeah, it's a jobstep task. And while I can see how NOT having
> authorization might cause a problem (specifically, an S047), I don't see
> why *having* authorization would cause a problem...
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Leonardo Vaz
> Sent: Friday, June 09, 2017 12:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APF authorization and AC(00)
>
> As far as I understand, AC=0 would only prevent authorization of the JSCB
> if it is the program being attached as a jobstep task, if this program is
> being called by an already-existing authorized task, it would run
> authorized.
>
> The question is: How is control passed to program ZPXPLIA?
>
> Regards,
> Leo
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Way, Richard
> Sent: Friday, June 09, 2017 3:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: APF authorization and AC(00)
>
> Simple question, but the behavior I am seeing flies in the face of what I
> *thought* I knew about APF authorization.
>
> The crux of it is - I have a program object that is linked AC(00).  When
> this program is executed out of an APF-authorized library, it S0C4s. When I
> revoke the authorization on the library and re-run the test, it works.
>
> I had been under the (maybe-mistaken) impression that if you didn't have
> *both* AC(1) *and* be running out of an APF-authed library, you wouldn't
> get APF authorization - so I thought that the AC(00) version should work
> just fine out of the APF-authorized library - but it doesn't.
>
> Any help would be appreciated.
>
> Additional facts:  program is PL/I (LE), chopped the source way back to
> just this:
>
>   ZPXPLIA:
>
> Proc Options(Main);
> Put skip list("Hello, world!");
>
>   end ZPXPLIA;
>
> The compile and bind are done with:
>
> 
> //PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
> // PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
> //'LIST,AG,A,X,C')
> // MAP = print info from compile for use when reading dumps.
> // LC(80) = LINECOUNT(80) = number of lines per page on listing.
> // NEST = listing indicates nest level and block level.
> // S = SOURCE = print the source on the compiler listin

Re: APF authorization and AC(00)

[Way, Richard]

Problem solved, per the suggestions below!! 

In particular, the program is apparently NOT reentrant, yet the binder was 
being told it was.

For some reason, this doesn't seem to matter (in this case) when the library 
isn't APF-autorized, yet results in a S0C4 when it is.

That part is still a bit of a puzzle.

But removing RENT from the bind step gets me past this.

Thanks again

Rich Wa

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

The source code is actually below - it's just a "hello world". But agreed I 
need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
debug it, but was the ONLY difference between the version that worked and the 
version that didn't - and I confirmed that by revoking and reinstating APF auth 
on the library.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Right, without the source code we can only guess, but the program might be 
issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" "Authorized 
library" bit to try and do something it wouldn't do if that bit was off, maybe 
they forgot to check the "Authorized program" bit as well.

That is, considering the only variable is the library being APF'd or not.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Thanks, but it's a simple

//XYZ EXEC PGM=ZPXPLIA

So, yeah, it's a jobstep task. And while I can see how NOT having authorization 
might cause a problem (specifically, an S047), I don't see why *having* 
authorization would cause a problem...

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SHR,DSN=
//SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DDDISP=(OLD,DELETE),DSN=&
//SYSLIN   DD*
   INCLUDE TEMP
   NAME ZPXPLIA(R)
/*


Thanks in advance- I am sure I must be misunderstanding something...

Rich Way
HPE Security - Data Security
HPE S

Re: APF authorization and AC(00)

[Way, Richard]

The source code is actually below - it's just a "hello world". But agreed I 
need to dig into the S0C4. The APF issue wasn't the result of an attempt to 
debug it, but was the ONLY difference between the version that worked and the 
version that didn't - and I confirmed that by revoking and reinstating APF auth 
on the library.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Right, without the source code we can only guess, but the program might be 
issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" "Authorized 
library" bit to try and do something it wouldn't do if that bit was off, maybe 
they forgot to check the "Authorized program" bit as well.

That is, considering the only variable is the library being APF'd or not.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Thanks, but it's a simple

//XYZ EXEC PGM=ZPXPLIA

So, yeah, it's a jobstep task. And while I can see how NOT having authorization 
might cause a problem (specifically, an S047), I don't see why *having* 
authorization would cause a problem...

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SHR,DSN=
//SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DDDISP=(OLD,DELETE),DSN=&
//SYSLIN   DD*
   INCLUDE TEMP
   NAME ZPXPLIA(R)
/*


Thanks in advance- I am sure I must be misunderstanding something...

Rich Way
HPE Security - Data Security
HPE Software | Enterprise Security Products
1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]<http://www.hpe.com/>


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

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

--
Fo

Re: APF authorization and AC(00)

[Leonardo Vaz]

Right, without the source code we can only guess, but the program might be 
issuing a CSVQUERY to verify its state and relying on ",OUTATTR2=" "Authorized 
library" bit to try and do something it wouldn't do if that bit was off, maybe 
they forgot to check the "Authorized program" bit as well.

That is, considering the only variable is the library being APF'd or not.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

Thanks, but it's a simple

//XYZ EXEC PGM=ZPXPLIA

So, yeah, it's a jobstep task. And while I can see how NOT having authorization 
might cause a problem (specifically, an S047), I don't see why *having* 
authorization would cause a problem...

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SHR,DSN=
//SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DDDISP=(OLD,DELETE),DSN=&
//SYSLIN   DD*
   INCLUDE TEMP
   NAME ZPXPLIA(R)
/*


Thanks in advance- I am sure I must be misunderstanding something...

Rich Way
HPE Security - Data Security
HPE Software | Enterprise Security Products
1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]<http://www.hpe.com/>


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

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

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

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

Re: APF authorization and AC(00)

[Don Poitras]

I don't see what 0C4 is telling you vis-a-vis APF authorization. I think it's
more likely that you've told the binder that the program is RENT and it's
not. If you have REFRPROT set in your PROGxx parmlib member, then it's going
to get loaded into read-only storage and when it tries to modify itself, it
gets the 0C4. i.e. I'd debug the 0C4 rather than randomly changing link
options or library locations.
 

In article 

 you wrote:
> Simple question, but the behavior I am seeing flies in the face of what I 
> *thought* I knew about APF authorization.

> The crux of it is - I have a program object that is linked AC(00).  When this 
> program is executed out of an APF-authorized library, it S0C4s. When I revoke 
> the authorization on the library and re-run the test, it works.

> I had been under the (maybe-mistaken) impression that if you didn't have 
> *both* AC(1) *and* be running out of an APF-authed library, you wouldn't get 
> APF authorization - so I thought that the AC(00) version should work just 
> fine out of the APF-authorized library - but it doesn't.

> Any help would be appreciated.

> Additional facts:  program is PL/I (LE), chopped the source way back to just 
> this:

>   ZPXPLIA:

> Proc Options(Main);
> Put skip list("Hello, world!");

>   end ZPXPLIA;

> The compile and bind are done with:

> 
> //PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
> // PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
> //'LIST,AG,A,X,C')
> // MAP = print info from compile for use when reading dumps.
> // LC(80) = LINECOUNT(80) = number of lines per page on listing.
> // NEST = listing indicates nest level and block level.
> // S = SOURCE = print the source on the compiler listing.
> // SYSTEM(MVS) = this is an ordinary batch program.
> // LIST = product the pseudo-assembler listing.
> // AG = AGGREGATE = produce a table of sizes of items in the listing.
> // A = ATTRIBUTES = produce a table of attributes in the listing.
> // X = XREF = create a cross-reference in the listing.
> // C = COMPILE = generate code unless there is a severe error.
> //SYSINDD  DISP=SHR,DSN=(ZPXPLIA)
> 
> //LKED EXEC PGM=IEWBLINK,COND=(4,LT),
> // PARM='LIST,MAP,LET,RENT'
> //SYSPRINT DDSYSOUT=*
> //SYSLIB   DDDISP=SHR,DSN=
> //SYSLMOD  DDDISP=SHR,DSN=
> //SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
> //TEMP DDDISP=(OLD,DELETE),DSN=&
> //SYSLIN   DD*
>INCLUDE TEMP
>NAME ZPXPLIA(R)
> /*
> 

> Thanks in advance- I am sure I must be misunderstanding something...

> Rich Way
> HPE Security - Data Security
> HPE Software | Enterprise Security Products
> 1140 Enterprise Way, Mail Stop 3048
> Sunnyvale, CA 94089

> [HPE logo]

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: APF authorization and AC(00)

[Way, Richard]

Thanks, but it's a simple

//XYZ EXEC PGM=ZPXPLIA

So, yeah, it's a jobstep task. And while I can see how NOT having authorization 
might cause a problem (specifically, an S047), I don't see why *having* 
authorization would cause a problem...

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SHR,DSN=
//SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DDDISP=(OLD,DELETE),DSN=&
//SYSLIN   DD*
   INCLUDE TEMP
   NAME ZPXPLIA(R)
/*


Thanks in advance- I am sure I must be misunderstanding something...

Rich Way
HPE Security - Data Security
HPE Software | Enterprise Security Products
1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]<http://www.hpe.com/>


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

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

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

Re: APF authorization and AC(00)

[Leonardo Vaz]

As far as I understand, AC=0 would only prevent authorization of the JSCB if it 
is the program being attached as a jobstep task, if this program is being 
called by an already-existing authorized task, it would run authorized.

The question is: How is control passed to program ZPXPLIA?

Regards,
Leo

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APF authorization and AC(00)

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SHR,DSN=
//SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DDDISP=(OLD,DELETE),DSN=&
//SYSLIN   DD*
   INCLUDE TEMP
   NAME ZPXPLIA(R)
/*


Thanks in advance- I am sure I must be misunderstanding something...

Rich Way
HPE Security - Data Security
HPE Software | Enterprise Security Products
1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]<http://www.hpe.com/>


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

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

APF authorization and AC(00)

[Way, Richard]

Simple question, but the behavior I am seeing flies in the face of what I 
*thought* I knew about APF authorization.

The crux of it is - I have a program object that is linked AC(00).  When this 
program is executed out of an APF-authorized library, it S0C4s. When I revoke 
the authorization on the library and re-run the test, it works.

I had been under the (maybe-mistaken) impression that if you didn't have *both* 
AC(1) *and* be running out of an APF-authed library, you wouldn't get APF 
authorization - so I thought that the AC(00) version should work just fine out 
of the APF-authorized library - but it doesn't.

Any help would be appreciated.

Additional facts:  program is PL/I (LE), chopped the source way back to just 
this:

  ZPXPLIA:

Proc Options(Main);
Put skip list("Hello, world!");

  end ZPXPLIA;

The compile and bind are done with:


//PLI  EXEC PGM=IBMZPLI,REGION=0K,TIME=999,
// PARM=('MAP,LC(80),NEST,S',SYSTEM(MVS),
//'LIST,AG,A,X,C')
// MAP = print info from compile for use when reading dumps.
// LC(80) = LINECOUNT(80) = number of lines per page on listing.
// NEST = listing indicates nest level and block level.
// S = SOURCE = print the source on the compiler listing.
// SYSTEM(MVS) = this is an ordinary batch program.
// LIST = product the pseudo-assembler listing.
// AG = AGGREGATE = produce a table of sizes of items in the listing.
// A = ATTRIBUTES = produce a table of attributes in the listing.
// X = XREF = create a cross-reference in the listing.
// C = COMPILE = generate code unless there is a severe error.
//SYSINDD  DISP=SHR,DSN=(ZPXPLIA)

//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DDSYSOUT=*
//SYSLIB   DDDISP=SHR,DSN=
//SYSLMOD  DDDISP=SHR,DSN=
//SYSUT1   DDUNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DDDISP=(OLD,DELETE),DSN=&
//SYSLIN   DD*
   INCLUDE TEMP
   NAME ZPXPLIA(R)
/*


Thanks in advance- I am sure I must be misunderstanding something...

Rich Way
HPE Security - Data Security
HPE Software | Enterprise Security Products
1140 Enterprise Way, Mail Stop 3048
Sunnyvale, CA 94089

[HPE logo]


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