Discussion:
CSVDYLPA ADD question.
Add Reply
John McKown
2017-11-29 16:49:31 UTC
Reply
Permalink
Raw Message
I'm looking at example #1 here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa100/iea3a1_Description18.htm#dylpaxm

What I'm thinking of is in regards to a subsystem (SSI) initialization
which occurs after IPL (i.e. not via the IEFSSNnn member of PARMLIB). The
above seems like a decent way to add the required code from a "steplib"
into the running LPA so that it is usable, even if the initialization
address space terminates for some reason. The basic logic that I'm looking
at is to do something like (really stripped down):

1) Determine if the subsystem is already running & terminate if so.
2) Determine if the required module(s) are already in LPA & if not load
them as above.
3) Determine if the subsystem is defined & if not then use IEFSS* macros to
define it.
4) Set up the subsystem (IEFSS* macros) and continue.

Now, my question is "Will the module added with the CSVDYLPA continue to be
valid even if the initialization address space terminates?". The
documentation doesn't indicate that it will "go away", so I am hoping that
it continues to be usable even if the address space terminates. But I am
somewhat concerned due to the fact that in a Share presentation on the SSI
it had a strong emphasis that "LOADTOGLOBAL" should only be used on the
IEFSSVT macro if one can be certain that the address space will _never_
terminate.

I'm guessing that LOADTOGLOBAL literally means "LOAD GLOBAL=YES,EOM=YES" is
specified within the IEFSSVT processing. Which, of course, makes me wonder
why it doesn't do a CSVDYLPA to load the module into CSA instead.
--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-11-29 17:13:08 UTC
Reply
Permalink
Raw Message
Not super familiar with SSI but use CSVDYLPA. Lots of options, but I can tell you yes, potentially a module added with CSVDYLPA can survive the termination of the issuer of the macro.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Wednesday, November 29, 2017 8:51 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: CSVDYLPA ADD question.

I'm looking at example #1 here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa100/iea3a1_Description18.htm#dylpaxm

What I'm thinking of is in regards to a subsystem (SSI) initialization which occurs after IPL (i.e. not via the IEFSSNnn member of PARMLIB). The above seems like a decent way to add the required code from a "steplib"
into the running LPA so that it is usable, even if the initialization address space terminates for some reason. The basic logic that I'm looking at is to do something like (really stripped down):

1) Determine if the subsystem is already running & terminate if so.
2) Determine if the required module(s) are already in LPA & if not load them as above.
3) Determine if the subsystem is defined & if not then use IEFSS* macros to define it.
4) Set up the subsystem (IEFSS* macros) and continue.

Now, my question is "Will the module added with the CSVDYLPA continue to be valid even if the initialization address space terminates?". The documentation doesn't indicate that it will "go away", so I am hoping that it continues to be usable even if the address space terminates. But I am somewhat concerned due to the fact that in a Share presentation on the SSI it had a strong emphasis that "LOADTOGLOBAL" should only be used on the IEFSSVT macro if one can be certain that the address space will _never_ terminate.

I'm guessing that LOADTOGLOBAL literally means "LOAD GLOBAL=YES,EOM=YES" is specified within the IEFSSVT processing. Which, of course, makes me wonder why it doesn't do a CSVDYLPA to load the module into CSA instead.

--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
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
Jim Mulder
2017-11-29 18:36:17 UTC
Reply
Permalink
Raw Message
IEFSSVT was created in MVS/ESA SP5.2.0, before the existence of
CSVDYLPA, which was created in OS/390 2.4.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Post by John McKown
I'm guessing that LOADTOGLOBAL literally means "LOAD GLOBAL=YES,EOM=YES"
is
Post by John McKown
specified within the IEFSSVT processing. Which, of course, makes me
wonder
Post by John McKown
why it doesn't do a CSVDYLPA to load the module into CSA instead.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-11-29 18:51:46 UTC
Reply
Permalink
Raw Message
Post by Jim Mulder
IEFSSVT was created in MVS/ESA SP5.2.0, before the existence of
CSVDYLPA, which was created in OS/390 2.4.
​That makes sense. And, since it works well, there's never been any real
need to update the internals. Hum, I wonder if someone could argue that
continuing to use the LOAD instead of CVSDYLPA is some sort of "exposure",
even though it is documented.​
Post by Jim Mulder
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2017-11-30 00:34:47 UTC
Reply
Permalink
Raw Message
While there are also other advantages to CSVDYLPA (like creating a CDE,
so that SLIP and IPCS can find the module by name), we likely would
consider it incompatible to change the documented meaning of the
LOADTOGLOBAL option on the IEFSSIVT macro. Adding a new
IEFSSIVT option to use CSVDYLPA would be more palatable.
Unfortunately, the code for the dynamic SSI functions in
MVS/ESA SP5,2.0 was written in a prototype internal Object Oriented
language, which is now an effectively dead language (no longer
supported, and very few developers who speak it). So that adds to
the degree of difficulty for doing SSI enhancements.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Post by Jim Mulder
IEFSSVT was created in MVS/ESA SP5.2.0, before the existence of
CSVDYLPA, which was created in OS/390 2.4.
That makes sense. And, since it works well, there's never been any real
need to update the internals. Hum, I wonder if someone could argue that
continuing to use the LOAD instead of CVSDYLPA is some sort of
"exposure",
even though it is documented.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-11-30 02:35:13 UTC
Reply
Permalink
Raw Message
Post by Jim Mulder
While there are also other advantages to CSVDYLPA (like creating a CDE,
so that SLIP and IPCS can find the module by name), we likely would
consider it incompatible to change the documented meaning of the
LOADTOGLOBAL option on the IEFSSIVT macro. Adding a new
IEFSSIVT option to use CSVDYLPA would be more palatable.
Unfortunately, the code for the dynamic SSI functions in
MVS/ESA SP5,2.0 was written in a prototype internal Object Oriented
language, which is now an effectively dead language (no longer
supported, and very few developers who speak it). So that adds to
the degree of difficulty for doing SSI enhancements.
​I appreciate your taking the time to explain things to me. At least for
me, in the weird idea forming in my head, I think that I'm going to go with
using CSVDYLPA to load my module into CSA, if it isn't already there and
use the FUNCADDR instead of the FUNCNAME in the IEFSSVTI macro. Too bad the
only example I've found, in the book, only shows how to use FUNCNAME=. Oh,
well, there may be some hints in the comments within the macro for me.

If I get my weird idea working, the code will be generally available to all
on the CBTtape.org site, of course.​
Post by Jim Mulder
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-11-30 13:00:31 UTC
Reply
Permalink
Raw Message
To answer specifically:
-- A module added to LPA is never automatically deleted.
-- A module added by LOAD with GLOBAL=YES always has a defined
circumstance at which point it is deleted (it could be task termination,
it could be address space termination).

So we highly recommend using dynamic LPA rather than LOAD with GLOBAL=YES,
both for the diagnostic reasons that Jim Mulder mentioned and for 'safety'
or perhaps we'd say 'integrity' if your address space could ever
terminate, assuming that you have no 100% way of ensuring that no code is
executing within the module at the time of the termination.

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