Reentrant Programs and Protected Storage
David Shein
it is loaded from an authorized library, it gets loaded into
protected storage. That is what the manual says, too. However, that
is not what appears to be happening.
We are on z/OS 1.10. There is a non-reentrant program which, when
executed via JCL from an authorized library, fails with a S0C4. When
the failing program is physically copied to another library and
executed from there, it runs correctly. This is entirely repeatable.
Has the rule changed? Is there a "gotcha" somewhere that we are overlooking?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Hal Merritt
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of David Shein
Sent: Wednesday, November 18, 2009 10:25 AM
To: IBM-...@bama.ua.edu
Subject: Reentrant Programs and Protected Storage
I grew up believing that if a program is link edited as reentrant AND
it is loaded from an authorized library, it gets loaded into
protected storage. That is what the manual says, too. However, that
is not what appears to be happening.
We are on z/OS 1.10. There is a non-reentrant program which, when
executed via JCL from an authorized library, fails with a S0C4. When
the failing program is physically copied to another library and
executed from there, it runs correctly. This is entirely repeatable.
Has the rule changed? Is there a "gotcha" somewhere that we are overlooking?
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
David Shein
the steplib (resubmitted the same JCL from the held queue), and the
steplib contains only application data, no MVS or other stuff. And
the application program does not do any LOADS itself; everything is
statically linked.
Good thought. Keep 'em coming, because we sure can't see what this is.
At 10:51 AM 11/18/2009 -0600, you wrote:
>I'd look at the S0C4 (an addressing exception) a little more
>closely. My first guess would be a subroutine call that is failing
>depending on the load library used.
>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
>Behalf Of David Shein
>Sent: Wednesday, November 18, 2009 10:25 AM
>To: IBM-...@bama.ua.edu
>Subject: Reentrant Programs and Protected Storage
>
>I grew up believing that if a program is link edited as reentrant AND
>it is loaded from an authorized library, it gets loaded into
>protected storage. That is what the manual says, too. However, that
>is not what appears to be happening.
>
>We are on z/OS 1.10. There is a non-reentrant program which, when
>executed via JCL from an authorized library, fails with a S0C4. When
>the failing program is physically copied to another library and
>executed from there, it runs correctly. This is entirely repeatable.
>
>Has the rule changed? Is there a "gotcha" somewhere that we are overlooking?
>
>
>NOTICE: This electronic mail message and any files transmitted with
>it are intended
>exclusively for the individual or entity to which it is addressed.
>The message,
>together with any attachment, may contain confidential and/or
>privileged information.
>Any unauthorized review, use, printing, saving, copying, disclosure
>or distribution
>is strictly prohibited. If you have received this message in error, please
>immediately advise the sender by reply email and delete all copies.
>
Edward Jaffe
> I grew up believing that if a program is link edited as reentrant AND
> it is loaded from an authorized library, it gets loaded into protected
> storage. That is what the manual says, too. However, that is not
> what appears to be happening.
>
> We are on z/OS 1.10. There is a non-reentrant program which, when
> executed via JCL from an authorized library, fails with a S0C4. When
> the failing program is physically copied to another library and
> executed from there, it runs correctly. This is entirely repeatable.
>
> Has the rule changed? Is there a "gotcha" somewhere that we are
> overlooking?
What makes you think the S0C4 is caused by the program being loaded into
subpool 252?
And, since you asked about whether the rules have changed...
The system was enhanced in z/OS 1.9 to optionally protect full pages of
modules linked with the REFR option. (I think the last time that option
had any real meaning. DAT hadn't been invented yet! :-) )
Issue D PROG,REFRPROT to see if you have this option enabled...
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Lizette Koehler
What does the PSW show?
Are there any unauthorized libraries in the concatenation?
Are you sure the code is truly reentrant? I got bit on this one a while ago. Someone made a simple change but the code became non-rent.
I seem to remember an old rule - if you have a reentrant pgm that is loaded from an authorized library and it is not reentrant, it abends with an 0C4. Though I could be mistaken.
Lizette
>
>Doubt it very much. The execution scenarios are identical except for
>the steplib (resubmitted the same JCL from the held queue), and the
>steplib contains only application data, no MVS or other stuff. And
>the application program does not do any LOADS itself; everything is
>statically linked.
>
>Good thought. Keep 'em coming, because we sure can't see what this is.
>
>
>At 10:51 AM 11/18/2009 -0600, you wrote:
>>I'd look at the S0C4 (an addressing exception) a little more
>>closely. My first guess would be a subroutine call that is failing
>>depending on the load library used.
>>
>
>>
>>I grew up believing that if a program is link edited as reentrant AND
>>it is loaded from an authorized library, it gets loaded into
>>protected storage. That is what the manual says, too. However, that
>>is not what appears to be happening.
>>
>>We are on z/OS 1.10. There is a non-reentrant program which, when
>>executed via JCL from an authorized library, fails with a S0C4. When
>>the failing program is physically copied to another library and
>>executed from there, it runs correctly. This is entirely repeatable.
>>
>>Has the rule changed? Is there a "gotcha" somewhere that we are overlooking?
>>
>
----------------------------------------------------------------------
David Shein
>into subpool 252?
Mostly the fact that the same load module (or a physical copy of it,
at any rate) works in a non-authorized library and fails in an
authorized one. But as I said, I'm open to suggestion, that's why I
made the post.
>Issue D PROG,REFRPROT to see if you have this option enabled...
Nope. That is, it isn't.
David Shein
No. Actually, tried it both ways with the same result.
>Are you sure the code is truly reentrant? I got bit on this one a
>while ago. Someone made a simple change but the code became non-rent.
No, the code is NOT reentrant, was never intended to be, and isn't
link edited with the reentrant attribute. That's the point. If it
isn't marked reentrant, running it from a different library shouldn't
make a difference.
BTW, the failure is happening in DB2 Call Attach.
Chris Craddock
> I grew up believing that if a program is link edited as reentrant AND it is
> loaded from an authorized library, it gets loaded into protected storage.
> That is what the manual says, too. However, that is not what appears to be
> happening.
>
> We are on z/OS 1.10. There is a non-reentrant program which, when executed
> via JCL from an authorized library, fails with a S0C4. When the failing
> program is physically copied to another library and executed from there, it
> runs correctly. This is entirely repeatable.
>
> Has the rule changed? Is there a "gotcha" somewhere that we are
> overlooking?
> <http://bama.ua.edu/archives/ibm-main.html>
>
Despite what the books say, reentrant programs have NEVER been placed in
protected storage UNLESS they were loaded from an APF authorized library.
And even then the "protection" was merely to load them into key zero
storage, and not into write-protected storage. But since APF programs all
start in PSW key 8 they will almost certainly fail immediately with a S0C4-4
if you try to run a NON-reentrant program in this fashion. If you run the
same program from a non-authorized library it will typically work UNLESS it
actually depends on being APF authorized.
It has ALWAYS been this way. When you link a program "RENT" you're telling
the system that the program does not modify itself. If that's not true, you
should not be surprised that things don't necessarily work out.
--
This email might be from the
artist formerly known as CC
(or not) You be the judge.
Elardus Engelbrecht
>Mostly the fact that the same load module (or a physical copy of it,
at any rate) works in a non-authorized library and fails in an authorized one.
But as I said, I'm open to suggestion, that's why I made the post.
Is the blocksize of both libraries the same?
What are the AC, AM, RM of the module in both libraries?
Is the module perhaps written so that it not expecting to be run as NON-
authorized?
If nothing else helps, then you could try a SLIP.
HTH
Groete / Greetings
Elardus Engelbrecht
Edward Jaffe
>> What makes you think the S0C4 is caused by the program being loaded
>> into subpool 252?
>
> Mostly the fact that the same load module (or a physical copy of it,
> at any rate) works in a non-authorized library and fails in an
> authorized one. But as I said, I'm open to suggestion, that's why I
> made the post.
My suggestion is debug the problem like any other abend. Get a dump and
analyze it. Find out which instruction is failing, in which storage (if
any) its operands reside, and why the program check occurs...
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Don Williams
In other words, are you sure that the S0C4 is the result of the program
being loaded into protected storage then trying to modify itself?
My following statements can/should be considered persnickety. I have never
been total comfortable with IBM's RENT option, which really seems to mean
read-only (i.e., load into protected or read-only storage). My reasoning is
that it is possible (theoretically) that a read-only program might not be
reentrant. Also, it is possible (again, theoretically) to write a reentrant
program that is not read-only.
So if many decades ago, IBM would have asked me (LOL), I would have
suggested an option like READONLY, RO, PROTECTED, or something along those
lines to cause a program to be loaded in protected storage. Then the RENT
option would mean that multiple instances of a program would be allowed
regardless of it READONLY/NONREADONLY attribute. For READONLY programs, all
execution instances could use the same physical copy; for NONREADONLY
programs, each instance would need its own physical copy (since each
instance might alter itself). For the NORENT option, only one execution
instance would be allowed regardless of its READONLY/NONREADONLY attribute.
Don Williams
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of David Shein
Sent: Wednesday, November 18, 2009 11:25 AM
To: IBM-...@bama.ua.edu
Subject: Reentrant Programs and Protected Storage
Hal Merritt
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of David Shein
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
----------------------------------------------------------------------
David Shein
It has ALWAYS been this way. When you link a program "RENT" you're telling
the system that the program does not modify itself. If that's not true, you
should not be surprised that things don't necessarily work out.
Right! That's the point! The program is NOT linked "RENT" and this
is happening anyway. Read the original post more carefully.
Is the blocksize of both libraries the same?
Yes. 6144.
What are the AC, AM, RM of the module in both libraries?
0, 31, and 24. One module is a physical copy of the other, not a re-link.
Is the module perhaps written so that it not expecting to be run as NON-
authorized?
No. It's a very "ordinary" PL/I application program.
>My suggestion is debug the problem like any other abend. Get a dump
>and analyze it. Find out which instruction is failing, in which
>storage (if any) its operands reside, and why the program check occurs...
That's essentially what we're doing. However, the failure appears to
be happening in IBM code. But only, as mentioned, when loaded from
an authorized library.
Thanks to everyone for the ideas. We appreciate your time.
Elliot, David
David Elliot
zSeries Software Support
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of David Shein
Sent: Wednesday, November 18, 2009 12:04 PM
To: IBM-...@bama.ua.edu
Subject: Re: Reentrant Programs and Protected Storage
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of David Shein
> Sent: Wednesday, November 18, 2009 12:04 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: Reentrant Programs and Protected Storage
>
>
> That's essentially what we're doing. However, the failure appears to
> be happening in IBM code. But only, as mentioned, when loaded from
> an authorized library.
>
> Thanks to everyone for the ideas. We appreciate your time.
>
If the failure is not in your program, but in IBM's program, perhaps that program is RENT and being loaded into store protected memory?
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Paul Gilmartin
>
>So if many decades ago, IBM would have asked me (LOL), I would have
>suggested an option like READONLY, RO, PROTECTED, or something along those
My understanding is that is what REFR was intended to mean. (Etym.: If
a memory page physically failed, that page could be REFReshed from a
pristine copy, perhaps in a page data set.)
>lines to cause a program to be loaded in protected storage. Then the RENT
>option would mean that multiple instances of a program would be allowed
>regardless of it READONLY/NONREADONLY attribute. For READONLY programs, all
>execution instances could use the same physical copy; for NONREADONLY
>programs, each instance would need its own physical copy (since each
>instance might alter itself). For the NORENT option, only one execution
>instance would be allowed regardless of its READONLY/NONREADONLY attribute.
>
I agree with your analysis: REFR and RENT should be independent. One can
contrive scenarios to populate each quadrant of the truth table. IBM,
with binder, however, has made the definitions hierarchial: REFR
implies RENT, and RENT implies REUS.
-- gil
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of David Shein
To: IBM-...@bama.ua.edu
Subject: Reentrant Programs and Protected Storage
I grew up believing that if a program is link edited as reentrant AND
it is loaded from an authorized library, it gets loaded into
protected storage. That is what the manual says, too. However, that
is not what appears to be happening.
We are on z/OS 1.10. There is a non-reentrant program which, when
executed via JCL from an authorized library, fails with a S0C4. When
the failing program is physically copied to another library and
executed from there, it runs correctly. This is entirely repeatable.
Has the rule changed? Is there a "gotcha" somewhere that we are
overlooking?
<SNIP>
How long have you been at 1.10?
Have you applied any maint to the PL/1 or LE components?
I have forgotten the name of it, but are you running with the DIRTY
GETMAIN option enabled?
One last thing, could the failing routine have been loaded into a KEY0
page when prior to 1.10 it was loaded into its own page? There has been
a change in storage allocation to start at the bottom of the page and go
up from there so to avoid storage fragmentation. I'm wondering if what
you are seeing is a side effect of such.
Regards,
Steve Thompson
Gerhard Postpischil
> So if many decades ago, IBM would have asked me (LOL), I would have
> suggested an option like READONLY, RO, PROTECTED, or something along those
> lines to cause a program to be loaded in protected storage.
The linkage editor started out with a "read only" option, namely
REFR (refreshable). But it was not honored by the early loaders,
that treated it as interchangeable with RENT.
Gerhard Postpischil
Bradford, VT
McKown, John
> From: IBM Mainframe Discussion List
> Sent: Wednesday, November 18, 2009 12:25 PM
> To: IBM-...@bama.ua.edu
>
<snip>
> I agree with your analysis: REFR and RENT should be
> independent. One can
> contrive scenarios to populate each quadrant of the truth table. IBM,
> with binder, however, has made the definitions hierarchial: REFR
> implies RENT, and RENT implies REUS.
>
> -- gil
>
I definitely agree that RENT and REFR are different concepts. Well, at least to me they are. RENT means that the code is reentrant. That is, it can be executed concurrently (or simultaneously on multiprocessors) by multiple tasks/threads and still work correctly. This does not mean "non-self modifying". Self modifying programs can be reentrant by proper use of ENQ/DEQ, locks, semaphores, etc. Also, a "non-self modifying" program may not be reentrant if it updates a shared area (or file!) without the proper locking.
REFR, to me, means that the code is non-self modifying (I think this was also called "pure code"). That is, if the code is running in a page frame which "fails", then the OS can simply page that code back in from the paging system to another page frame and redispatch the work with no difference in the programs processing. It could also mean that the OS could be written such that it never pages the program out to a dataset because it can simply be fetched again from the original source. Or that the frame could be stolen without doing a page-out. This is basically how LPA works.
As I recall, back in the days of OS/360 and OS/VS1, there was a "transient SVC area". This area was small (4K?). All SVCs had to be REFR because they all ran in this one area. It is also why type 3 SVCs were restricted in size. The entire SVC had to fit in the transient area. Type 4 SVCs got around this by being kept in multiple modules and one module would XCTL to the other modules which made up the SVC, each loaded into the transient area. Anyway, if an SVC were running for task A when it was preempted in order to run task B, and task B did an SVC, then task B's SVC would overlay this area and run. When task A was redispatched, the OS would reload task A's SVC from SVCLIB. End of history lession - hope I wasn't off too badly.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Don Williams
> a memory page physically failed, that page could be REFReshed from a
> pristine copy, perhaps in a page data set.)
REFR is old. In those days, physical memory could and did fail occasionally.
I just never understand why IBM forced the hierarchy. I know REFR was in MVS
3.8, but I can't remember if it was in SVS, MVT, or MFT. I'm pretty sure it
was not in PCP.
Don Williams
Kelman, Tom
truly reentrant? Are you sure it doesn't have code that modifies
storage making it a non-reentrant module?
Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of David Shein
> Sent: Wednesday, November 18, 2009 11:37 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Reentrant Programs and Protected Storage
>
*****************************************************************************
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com
NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*****************************************************************************
David Shein
reentrant. That's the point. This shouldn't be happening.
Gainsford, Allen
> the system that the program does not modify itself.
Really? I thought that was what REFR was for, not RENT. My understanding
was that RENT simply means that the module can be executed my multiple
tasks simultaneously.
I have written modules that were reentrant, but which modified themselves.
(I'm not saying it was a good idea.) They were very careful with their
modifications (using CS / CDS, etc), but the fact remains, they were
reentrant. But not refreshable.
Regards,
Allen
Martin Kline
>it is loaded from an authorized library, it gets loaded into
>protected storage. That is what the manual says, too. However, that
>is not what appears to be happening.
>We are on z/OS 1.10. There is a non-reentrant program which, when
>executed via JCL from an authorized library, fails with a S0C4. When
>the failing program is physically copied to another library and
>executed from there, it runs correctly. This is entirely repeatable.
Did you browse the load library directory and verify the program is not linked
as RENT? Based on what you've written, it sound like the system is treating
the program as if it had the RENT attribute.
BTW, One reference to how laoder handles RENT is in MVS Program
Management: User's Guide and Reference:
<quote>
RENT
The module is reenterable. It can be executed by more than one task at
a time. A task can begin executing it before a previous task has
completed execution. 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, and
also programs running under UNIX unless a debugging environment has
been specified.
</quote>
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Gainsford, Allen
> Sent: Wednesday, November 18, 2009 2:03 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: Reentrant Programs and Protected Storage
>
> you're telling
> > the system that the program does not modify itself.
>
> Really? I thought that was what REFR was for, not RENT. My
> understanding
> was that RENT simply means that the module can be executed my multiple
> tasks simultaneously.
>
> I have written modules that were reentrant, but which
> modified themselves.
> (I'm not saying it was a good idea.) They were very careful
> with their
> modifications (using CS / CDS, etc), but the fact remains, they were
> reentrant. But not refreshable.
>
> Regards,
> Allen
What you have said is generally correct. Except when a RENT module is loaded in an APF environment. Then, it is loaded into key 0 storage and so protected from modification (unless the code goes into key 0?). I have no idea why IBM did this. In a nonAPF environment, I don't know if marking a program RENT does anything at all.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Mark Zelden
>To keep the number of posts down, I'm going to respond to several in one.
>
>It has ALWAYS been this way. When you link a program "RENT" you're telling
>the system that the program does not modify itself. If that's not true, you
>should not be surprised that things don't necessarily work out.
>
>Right! That's the point! The program is NOT linked "RENT" and this
>is happening anyway. Read the original post more carefully.
>
I just did. And it certainly was not clear. You wrote:
>"There is a non-reentrant program which, when executed via JCL
> from an authorized library, fails with a S0C4."
Without an AMBLIST or at least a screen print from ISPF showing the
attributes, there is no way for any of us to know if that statement was
based on LKED attribute, or just what you think is the case from what
you know about the program.
So how about posting a AMBLIST LISTIDR of the module in question?
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Don Williams
believe he said a DB2 service call). Perhaps that subroutine is linked with
RENT and loaded into protected storage when the step is authorized. However,
when that step is not authorized, that same subroutine would not be loaded
into protected storage.
Don Williams
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Martin Kline
Sent: Wednesday, November 18, 2009 3:14 PM
To: IBM-...@bama.ua.edu
Subject: Re: Reentrant Programs and Protected Storage
Veilleux, Jon L
Jon L. Veilleux
veill...@aetna.com
(860) 636-2683
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Gainsford, Allen
Sent: Wednesday, November 18, 2009 3:03 PM
To: IBM-...@bama.ua.edu
Subject: Re: Reentrant Programs and Protected Storage
Regards,
Allen
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
John Kelly
"There is a non-reentrant program which, when executed via JCL from an
authorized library, fails with a S0C4."
As a debugging tool can you determine which subpool the module is loaded
into (that should clear up the non reentrant [et al] too) and what "reason
code" is the AB/S0C4 (4,10,11,..) ?
Jack Kelly
202-502-2390 (Office)
Gainsford, Allen
> does anything at all.
Well, it means that if multiple subtasks LINK to it simultaneously,
only one copy gets loaded. :)
David Shein
>
> >"There is a non-reentrant program which, when executed via JCL
> > from an authorized library, fails with a S0C4."
>
>Without an AMBLIST or at least a screen print from ISPF showing the
>attributes, there is no way for any of us to know if that statement was
>based on LKED attribute, or just what you think is the case from what
>you know about the program.
>
>So how about posting a AMBLIST LISTIDR of the module in question?
I stand corrected. (Well, actually I'm sitting down, but it amounts
to the same thing.) You are correct. I did not say that it was
linked non-reentrant. Mea culpa.
However, the fact is that it was linked non-reentrant. We have
proven that six ways from Sunday, including having another person
recompile and relink the program. The results do not change.
I have sought advice about posting an AMBLIST or ISPF display here
and been told that it might violate an NDA. No one is absolutely
certain, so I have been told not to do it. But trust me, many pairs
of eyes have verified that this load module, no matter how often it
is relinked, is AC(0) and has no attributes -- no RENT, no REUS, no
REFR, nothing. And the behavior is absolutely 100% repeatable. Run
it from an authorized library, it fails. Run it from an "ordinary"
library, it works. Every. Single. Time.
D
Farley, Peter x23353
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of David Shein
> Sent: Wednesday, November 18, 2009 3:53 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: Reentrant Programs and Protected Storage
> I have sought advice about posting an AMBLIST or ISPF display here
> and been told that it might violate an NDA. No one is absolutely
> certain, so I have been told not to do it. But trust me, many pairs
> of eyes have verified that this load module, no matter how often it
> is relinked, is AC(0) and has no attributes -- no RENT, no REUS, no
> REFR, nothing. And the behavior is absolutely 100% repeatable. Run
> it from an authorized library, it fails. Run it from an "ordinary"
> library, it works. Every. Single. Time.
Do you have z/XDC available? If so, you can us it to debug this program
when it is authorized (via XDCCALLA) and see exactly where things are
when the abend occurs.
If not, I think another poster suggested looking at a dump with IPCS
(which I must admit I don't know very well) and see what storage subpool
that DB2 module is located in when it abends.
Also, I think the earlier suggestion that maybe the DB2 module gets
loaded into protected storage when the top-level caller (your program)
is authorized has a hint of possibility to it. OTOH, if the DB2 module
is statically linked with your program, then it is purely a question of
into which subpool your program gets loaded. IMHO you need to nail that
down.
HTH
Peter
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Mark Zelden
>>And it certainly was not clear. You wrote:
>>
>> >"There is a non-reentrant program which, when executed via JCL
>> > from an authorized library, fails with a S0C4."
>>
>>Without an AMBLIST or at least a screen print from ISPF showing the
>>attributes, there is no way for any of us to know if that statement was
>>based on LKED attribute, or just what you think is the case from what
>>you know about the program.
>>
>>So how about posting a AMBLIST LISTIDR of the module in question?
>
>
>I stand corrected. (Well, actually I'm sitting down, but it amounts
>to the same thing.) You are correct. I did not say that it was
>linked non-reentrant. Mea culpa.
>
>However, the fact is that it was linked non-reentrant. We have
>proven that six ways from Sunday, including having another person
>recompile and relink the program. The results do not change.
>
>I have sought advice about posting an AMBLIST or ISPF display here
>and been told that it might violate an NDA. No one is absolutely
>certain, so I have been told not to do it. But trust me, many pairs
>of eyes have verified that this load module, no matter how often it
>is relinked, is AC(0) and has no attributes -- no RENT, no REUS, no
>REFR, nothing. And the behavior is absolutely 100% repeatable. Run
>it from an authorized library, it fails. Run it from an "ordinary"
>library, it works. Every. Single. Time.
>
Not sure how posting an AMBLIST would violate any NDA, but what if
you changed the member and csect names. You did say this was
z/OS 1.10 so it is not like this is an ESP or something like that.
I guess we'll just have to take your word (and the other's who have
looked at it). I assume you have looked at the AMBLIST yourself
though (which I would trust more than ISPF).
I hope you'll post the final resolution, even if it ends up being a
SUE (stupid user error).
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Scott Rowe
>>> David Shein <dsh...@POBOX.COM> 11/18/2009 3:52 PM >>>
D
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
Kirk Wolf
due to the presence of some other module in the authorized library vs
the non-authorized library. Just because your application is
statically linked, it doesn't ensure that some system service that you
are calling doesn't do a load from the current joblib/steplib
environment. For example, since you are using DB2, it would try to
load DSNHDECP.
Kirk Wolf
Dovetailed Technologies
David Shein
>Not sure how posting an AMBLIST would violate any NDA, but what if
>you changed the member and csect names.
Me neither, but the decision was made above my pay grade.
>You did say this was
>z/OS 1.10 so it is not like this is an ESP or something like that.
True. z/OS is not the sensitive spot, something else is. Can't say more.
>I guess we'll just have to take your word (and the other's who have
>looked at it). I assume you have looked at the AMBLIST yourself
>though (which I would trust more than ISPF).
So many times that it is giving me a headache. Also the PDS utility
ATTR and MAP displays. And as mentioned, we have recompiled this
thing more than once.
>I hope you'll post the final resolution, even if it ends up being a
>SUE (stupid user error).
Absolutely. And I'm sure that is what it will turn out to be,
somehow, when we finally find it. I just refuse to believe that MVS
is broken in such a fundamental way. The smart money is certainly on a SUE.
David
Hunkeler Peter , KIUP 4
offence intended). So many posts, but still neither the actual
abend including the reason, nor the PSW, nor the failing
instruction including the analysis what its operands are have
been posted.
Neither has proof been provided that the program in question
has really been loaded into SP 252 / Key 0. If that was
not the case, the whole discussion about RENT or not is
useless.
David, do you or don't you have a dump to look at?
--
Peter Hunkeler
CREDIT SUISSE AG
David Shein
as much of the explanation as I am permitted to share.
As many suspected, this was indeed a SUE (Stupid User Error).
The program being directly executed, i.e., via JCL, was not itself
failing. The S0C4 was occurring in IBM code, and was happening
because of a dynamically loaded subroutine. It was the subroutine
that was faulty.
The error occurred because the bad subroutine was where it shouldn't
have been. That, in turn, occurred because a developer (a) put it
into a library where it did not belong in the first place, and (b)
failed to clean up his garbage when his project ended several months
ago. When the bogus module was deleted, the problem went away with it.
In summary, this was an instance of Murphy taking full advantage when
someone did not follow correct procedure, and then did not clean up
after himself. We have drawn several instructive lessons from the
experience, none of which I intend to dwell on here.
Thanks to everyone who took an interest and offered constructive suggestions.
Cartier, Arthur J
----- Original Message -----
From: IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
To: IBM-...@bama.ua.edu <IBM-...@bama.ua.edu>
Sent: Wed Nov 18 15:14:23 2009
Subject: Re: Reentrant Programs and Protected Storage
----------------------------------------------------------------------
Hunkeler Peter , KIUP 4
And this means what?
--
Peter Hunkeler
Credit Suisse
David Shein
> >WWwsswWW
>
>And this means what?
>
>--
>Peter Hunkeler
>Credit Suisse
>
I was wondering the same thing.
David
John P Kalinich
s = Surprise?
David Sheen of the IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
wrote on 11/20/2009 11:27:00 AM:
> At 08:06 AM 11/20/2009 +0100, you wrote:
> > >WWwsswWW
> >
> >And this means what?
> >
> >Peter Hunkeler
> >Credit Suisse
>
> I was wondering the same thing.
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 10:03 AM, David Shein <dsh...@POBOX.COM> said:
>It has ALWAYS been this way. When you link a program "RENT" you're
>telling the system that the program does not modify itself.
No; you are telling the system to allow concurrent invocations. Even
self-modifying code that IBM shipped as part of the OS has been linked
with RENT, although over the years they've rewritten all or most of that.
Note that the Binder allows things like read-only csects that can
complicate the issue.
>Right! That's the point! The program is NOT linked "RENT" and this is
>happening anyway. Read the original post more carefully.
The original post did *not* say how it was linked.
>Is the blocksize of both libraries the same?
Irrelevant, but
>Yes. 6144.
Ouch!
>However, the failure appears to be happening in IBM code.
What IBM code? What's the reason code associated with the ABEND S0C4?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
11/18/2009
at 11:48 AM, Chris Craddock <crash...@GMAIL.COM> said:
>Despite what the books say, reentrant programs have NEVER been placed in
>protected storage UNLESS they were loaded from an APF authorized
>library.
The system was loading code marked with RENT into SP252 key 0 before there
was such a thing as APF.
>But since APF programs all start in PSW key 8
Not if the PPT assigns a key or if they are running V=R[1].
>It has ALWAYS been this way.
It used to be that the distinction was system[2] library versus user
library.
>When you link a program "RENT" you're telling
>the system that the program does not modify itself.
No, you're telling the system to allow concurrent execution of a single
copy. REFR was almost a read-only flag, and in current software it is more
of one.
[1] Moment of silence.
[2] E.g., SYS1.LINKLIB from the system linklist DCB.
Shmuel Metz , Seymour J.
at 12:24 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>My understanding is that is what REFR was intended to mean. (Etym.: If a
>memory page physically failed, that page could be REFReshed from a
>pristine copy, perhaps in a page data set.)
The original use of REFR was for the Machine Check Handler in OS/360,
which had no paging. It used a data set called SYS1.ASRLIB to back up
refreshable csects in the nucleus. It reloaded refreshable SVC routines
into the SVC transient area from SYS1.SVCLIB.
>I agree with your analysis: REFR and RENT should be independent.
Yes, at the system level. But IMHO we should be writing code that is both
refreshable and reentrant.
>One can contrive scenarios to populate each quadrant of the truth
>table.
And IBM did, more often than I liked. However, such programs are best used
as examples of what the concepts are, not as code to be moved into
production.
Shmuel Metz , Seymour J.
11/18/2009
at 12:43 PM, "McKown, John" <John....@HEALTHMARKETS.COM> said:
>As I recall, back in the days of OS/360 and OS/VS1, there was a
>"transient SVC area". This area was small (4K?).
As I recall. 1KiB in OS/360, 2KiB in OS/VS1, replaced by PLPA in OS/VS2 R1
(SVS).
Shmuel Metz , Seymour J.
at 01:35 PM, Gerhard Postpischil <ger...@VALLEY.NET> said:
>The linkage editor started out with a "read only" option, namely REFR
>(refreshable). But it was not honored by the early loaders, that treated
>it as interchangeable with RENT.
Not quite; Fetch ignored the REFR attribute. Only the MCH cared. A module
link with REFR had to behave properly if replaced with a clean copy, but
didn't have to actually be R/O.
As for modules linked with REFR, they were loaded into SP252 key 0 if they
were fetched via a system (e.g., link list, SVCLIB) DCB, or SP 251 user
key if fetched via a user or JOB/STEPLIB DCB.
Shmuel Metz , Seymour J.
<!&!AAAAAAAAAAAYAAAAAAAAAIH+nruO4exAufAxNTnNpHSCxBIAEAAAAA3ES6bzLdpOo2wt55T0jnIBAAAAAA==@gmail.com>,
on 11/18/2009
at 01:44 PM, Don Williams <don...@GMAIL.COM> said:
>REFR is old. In those days, physical memory could and did fail
>occasionally. I just never understand why IBM forced the hierarchy. I
>know REFR was in MVS 3.8, but I can't remember if it was in SVS, MVT, or
>MFT. I'm pretty sure it was not in PCP.
REFR was added for the MCH in MVT, which was not available for PCP. It was
still relevant in OS/VS1 but not in SVS or later.