Discussion:
APF authorization and AC(00)
(too old to reply)
Way, Richard
2017-06-09 19:49:19 UTC
Permalink
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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Leonardo Vaz
2017-06-09 19:57:39 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-***@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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-06-09 20:02:19 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-***@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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Leonardo Vaz
2017-06-09 20:14:35 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-***@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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-06-09 20:17:21 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-***@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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-06-09 20:22:56 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 1:18 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-***@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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Way, Richard
2017-06-09 20:25:07 UTC
Permalink
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-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 1:18 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
To: IBM-***@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:

<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Don Poitras
2017-06-09 20:09:28 UTC
Permalink
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.
Post by 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.
Proc Options(Main);
Put skip list("Hello, world!");
end ZPXPLIA;
<snip>
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip>
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED
//SYSLMOD DD DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1))
//TEMP DD DISP=(OLD,DELETE),DSN=&&TEMP
//SYSLIN DD *
INCLUDE TEMP
NAME ZPXPLIA(R)
/*
<snip>
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/>
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
***@sas.com (919) 531-5637 Cary, NC 27513

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-06-09 20:31:21 UTC
Permalink
Post by 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.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-06-09 21:24:51 UTC
Permalink
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 1:33 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Dan Little
Sent: Friday, June 09, 2017 1:27 PM
To: IBM-***@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
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-----
On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 4:24 PM
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-----
On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 1:18 PM
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-----
On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 1:16 PM
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-----
On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 4:03 PM
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-----
On Behalf Of Leonardo Vaz
Sent: Friday, June 09, 2017 12:59 PM
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-----
On Behalf Of Way, Richard
Sent: Friday, June 09, 2017 3:49 PM
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.
Proc Options(Main);
Put skip list("Hello, world!");
end ZPXPLIA;
<snip
//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.
//SYSIN DD DISP=SHR,DSN=&SAMPLIB..SAMPLIB(ZPXPLIA)
<snip
//LKED EXEC PGM=IEWBLINK,COND=(4,LT),
// PARM='LIST,MAP,LET,RENT'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=&LECEEHLQ..SCEELKED //SYSLMOD DD
DISP=SHR,DSN=&LOAD
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(3,1)) //TEMP DD
DISP=(OLD,DELETE),DSN=&&TEMP //SYSLIN DD * INCLUDE TEMP NAME
ZPXPLIA(R)
/*
<snip
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-06-10 07:39:07 UTC
Permalink
Post by 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. ;-)
——————————_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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-06-10 11:26:26 UTC
Permalink
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-06-10 14:53:12 UTC
Permalink
Post by Peter Relson
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-06-10 14:58:54 UTC
Permalink
Wow a seal team 6 member ...

On Sat, Jun 10, 2017 at 10:54 AM Paul Gilmartin <
Post by Paul Gilmartin
Post by Peter Relson
Post by Tom Marchant
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,
--
Scott Ford
IDMWORKS
z/OS Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-06-10 23:40:17 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Saturday, June 10, 2017 7:54 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: APF authorization and AC(00)
Post by Peter Relson
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
CM Poncelet
2017-06-11 02:02:25 UTC
Permalink
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)
Post by 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-----
Sent: Saturday, June 10, 2017 7:54 AM
Subject: Re: APF authorization and AC(00)
Post by Peter Relson
Post by Tom Marchant
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,
.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2017-06-11 02:11:23 UTC
Permalink
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&L=IBM-MAIN&P=R2798&I=-3&X=-&Y=d10jhm1%40us.ibm.com&d=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
Date: 06/10/2017 09:55 PM
Subject: Re: APF authorization and AC(00)
Post by Peter Relson
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2017-06-12 10:38:42 UTC
Permalink
Post by Paul Gilmartin
Post by Peter Relson
Post by Tom Marchant
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
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-06-11 00:05:15 UTC
Permalink
Post by 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.
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!
Post by Charles Mills
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.
Post by Charles Mills
-----Original Message-----
From: Of Paul Gilmartin
Sent: Saturday, June 10, 2017 7:54 AM
Post by Peter Relson
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Randy Hudson
2017-06-12 04:30:28 UTC
Permalink
Post by Paul Gilmartin
Point taken. But it's not clear why the designers chose to allow a program
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-06-12 06:43:01 UTC
Permalink
On Mon, 12 Jun 2017 00:31:28 -0400 Randy Hudson <***@PANIX.COM> wrote:

:>In article <***@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 <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
CM Poncelet
2017-06-13 02:36:53 UTC
Permalink
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)
Post by Binyamin Dissen
:>
:>> Point taken. But it's not clear why the designers chose to allow a program
:>> 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.
--
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,
.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-06-11 00:14:08 UTC
Permalink
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.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-06-11 00:28:26 UTC
Permalink
Post by Walt Farrell
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-06-11 16:58:41 UTC
Permalink
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of CM Poncelet
Sent: Saturday, June 10, 2017 7:04 PM
To: IBM-***@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)
Post by 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-----
On Behalf Of Paul Gilmartin
Sent: Saturday, June 10, 2017 7:54 AM
Subject: Re: APF authorization and AC(00)
Post by Peter Relson
Post by Tom Marchant
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-06-11 17:54:41 UTC
Permalink
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 +0000 Jesse 1 Robinson <***@SCE.COM>
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 <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-06-11 18:12:27 UTC
Permalink
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-06-11 20:39:47 UTC
Permalink
Post by Peter Relson
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.
Post by Peter Relson
... 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?
Post by Peter Relson
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.
Post by Peter Relson
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.
Post by Peter Relson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-06-11 21:18:26 UTC
Permalink
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 <
Post by Paul Gilmartin
Post by Peter Relson
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.
Post by Peter Relson
... A reentrant program
can, if written carefully, modify itself, although it is rarely a good
idea.
Post by Peter Relson
LPA modules are generally, in effect, refreshable.
Does this mean that REFRPROT "in effect" applies to LPA modules?
Post by Peter Relson
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.
Post by Peter Relson
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.
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.
Post by Peter Relson
And, yes, it is a performance consideration. Not a huge one, but one
nevertheless.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-06-12 00:13:34 UTC
Permalink
[Default] On 11 Jun 2017 13:39:47 -0700, in bit.listserv.ibm-main
Post by Paul Gilmartin
Post by Peter Relson
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.
Post by Peter Relson
... 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?
Post by Peter Relson
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
Post by Paul Gilmartin
Post by Peter Relson
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.
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.
Post by Peter Relson
And, yes, it is a performance consideration. Not a huge one, but one
nevertheless.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-06-11 21:32:47 UTC
Permalink
Post by Paul Gilmartin
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Thompson
2017-06-12 00:51:11 UTC
Permalink
Post by Walt Farrell
Post by Paul Gilmartin
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.
<snippage>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
J R
2017-06-12 01:45:01 UTC
Permalink
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
Post by Steve Thompson
Post by Walt Farrell
Post by Paul Gilmartin
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.
<snippage>
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
J R
2017-06-12 01:51:24 UTC
Permalink
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
Post by Steve Thompson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-06-12 02:24:32 UTC
Permalink
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Clark Morris
Sent: Sunday, June 11, 2017 5:15 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: APF authorization and AC(00)
Post by Paul Gilmartin
Post by Peter Relson
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.
Post by Peter Relson
... 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?
Post by Peter Relson
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
Post by Paul Gilmartin
Post by Peter Relson
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.
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.
Post by Peter Relson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-06-12 06:40:19 UTC
Permalink
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 +0000 Jesse 1 Robinson <***@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
:>***@sce.com
:>
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Clark Morris
:>Sent: Sunday, June 11, 2017 5:15 PM
:>To: IBM-***@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 0000000433f07816-dmarc-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-06-12 10:33:33 UTC
Permalink
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... oooooooops ....

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-06-12 12:29:38 UTC
Permalink
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
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-06-12 12:31:19 UTC
Permalink
Post by Steve Thompson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gary Weinhold
2017-06-12 13:14:39 UTC
Permalink
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<tel:+1.613.523.5500%20x216>
Email: ***@dkl.com<mailto:***@dkl.com>

[Loading Image...]<http://www.dkl.com/>

Visit us online at www.DKL.com<http://www.dkl.com/>

[Loading Image...]<http://www.dkl.com/mailsig>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-06-12 16:34:30 UTC
Permalink
Post by Binyamin Dissen
:>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.
Post by Binyamin Dissen
:>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.
Post by Binyamin Dissen
:>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.
Post by Binyamin Dissen
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2017-06-12 16:59:54 UTC
Permalink
On Mon, 12 Jun 2017 11:35:33 -0500, Paul Gilmartin
(0000000433f07816-dmarc-***@LISTSERV.UA.EDU) wrote about "Re: APF
authorization and AC(00)" (in
<***@listserv.ua.edu>):

[snip]
Post by Paul Gilmartin
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.
Post by Paul Gilmartin
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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-06-12 17:52:24 UTC
Permalink
On 12 June 2017 at 12:35, Paul Gilmartin <
Post by Paul Gilmartin
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-06-12 19:03:45 UTC
Permalink
Post by Tony Harminc
Post by Paul Gilmartin
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...