Re: Keeping SSN init modules current

[R.S.]

In fact I don't understand the problem.
What's so specific in SSN init module which cause a need for special 
treatment?
I used to apply service or upgrade various subsystems (including STK 
software) and don't remeber anything special.
Of course there ways and philosiphies of servicing software, with their 
ddvantages and drawbacks... as ususal.



Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Keeping SSN init modules current

[John Eells]

John Eells wrote:



For DIY, a ++MOVE usermod will get it on the books so you don't forget
to update the module at system build time, but if the vendor ships JCLIN
to change the module structure, SMP/E will, quite obligingly and without
any fanfare, "put it back where it belongs" on your behalf, and the copy
you are using will be downlevel again.




Kurt tells me I got this wrong (sorry, folks).  A PTF wtih JCLIN will 
add the LMOD back to its original library, but you wind up with two 
copies.  Both will be maintained, one in the original, and one in the 
++MOVE target.  However, if the module is deleted and added back in via 
PTFs, the copy in the ++MOVE target library will evaporate (which must 
have been what I was thinking of), and this will happen without any 
fanfare because none of the RMIDs for the LMOD are changed by ++MOVE.


I'm still a fan of making the module available by other means, though, 
if feasible.


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

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

Re: Keeping SSN init modules current

[Tom Marchant]

On Thu, 21 Sep 2017 20:24:15 +, Jesse 1 Robinson wrote:

>Here is an example of an SCLM module 'moved' from LPA to 
>link list by usermod ISPF003:

Moving an SCLM module to SYS1.LINKLIB is one thing. I thought 
that the OP was talking about an ISV product. IMO, that would 
be quite another matter entirely. And moving the module is 
probably ok if it's part of z/OS.

But if it is part of a third-party product, I would be reluctant to 
move it to SYS1.LINKLIB. If you want a copy of it in SYS1.LINKLIB, 
that's ok, but I would want it to stay in the product's load library 
as well.

SMP/E allows this. You can have an LMOD that goes to two target 
libraries. John Eells described how to do that. Otherwise, when you 
install a new ServerPac, you could end up losing the load module.

-- 
Tom Marchant

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

Re: Keeping SSN init modules current

[Rob Schramm]

The SMP/E method helps keep it on your "radar".  Each OS upgrade will force
the issue... unless your shop is frozen like a few on this list.

Rob

On Fri, Sep 22, 2017 at 8:37 AM John McKown 
wrote:

> On Thu, Sep 21, 2017 at 5:42 PM, Jesse 1 Robinson  >
> wrote:
>
> > 'Override' libraries give me the willies. War story. Shortly after I
> > started here, VTAM would not come up one Sunday after a maintenance IPL.
> > Turned out that some modified VTAM module(s) had been placed
> 'temporarily'
> > into an override library for testing and promptly forgotten about. The
> perp
> > had a note *in plain sight* on his wall to remind him of this maneuver.
> It
> > had been there so long that he no longer saw it (!). Willies, I tell you.
> >
>
> ​I can see that. But, then again, how is that any different from forcing
> this person to put the module into the "regular" library "for testing"? I
> don't put "for testing" modules into my system specific "override"
> libraries.
>
> If I had some sort of "for testing" library, I would manage it like we do
> our "quick fix" libraries. These are "production" load libraries to which
> the programmers have WRITE access. If a production problem occurs over
> night and they need to put in a "patch", they do it by linking into one of
> these libraries. And at noon every day (even weekends), we clean out
> _everything_ from these libraries. This may result in another outage next
> cycle if the programmer doesn't get a fix into production in time. But that
> is the cost that we & they just need to pay.​ Nothing will stay in a "quick
> fix" library longer than 24 hours.
>
>
>
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 <(323)%20715-0595> Mobile
> > 626-543-6132 <(626)%20543-6132> Office ⇐=== NEW
> > robin...@sce.com
> >
>
>
> --
> *L'Shanah Tovah Tikatevu*
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: Keeping SSN init modules current

[John McKown]

On Thu, Sep 21, 2017 at 5:42 PM, Jesse 1 Robinson 
wrote:

> 'Override' libraries give me the willies. War story. Shortly after I
> started here, VTAM would not come up one Sunday after a maintenance IPL.
> Turned out that some modified VTAM module(s) had been placed 'temporarily'
> into an override library for testing and promptly forgotten about. The perp
> had a note *in plain sight* on his wall to remind him of this maneuver. It
> had been there so long that he no longer saw it (!). Willies, I tell you.
>

​I can see that. But, then again, how is that any different from forcing
this person to put the module into the "regular" library "for testing"? I
don't put "for testing" modules into my system specific "override"
libraries.

If I had some sort of "for testing" library, I would manage it like we do
our "quick fix" libraries. These are "production" load libraries to which
the programmers have WRITE access. If a production problem occurs over
night and they need to put in a "patch", they do it by linking into one of
these libraries. And at noon every day (even weekends), we clean out
_everything_ from these libraries. This may result in another outage next
cycle if the programmer doesn't get a fix into production in time. But that
is the cost that we & they just need to pay.​ Nothing will stay in a "quick
fix" library longer than 24 hours.



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


-- 
*L'Shanah Tovah Tikatevu*

Maranatha! <><
John McKown

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

Re: Keeping SSN init modules current

[Jesse 1 Robinson]

'Override' libraries give me the willies. War story. Shortly after I started 
here, VTAM would not come up one Sunday after a maintenance IPL. Turned out 
that some modified VTAM module(s) had been placed 'temporarily' into an 
override library for testing and promptly forgotten about. The perp had a note 
*in plain sight* on his wall to remind him of this maneuver. It had been there 
so long that he no longer saw it (!). Willies, I tell you.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, September 21, 2017 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping SSN init modules current

On Thu, Sep 21, 2017 at 11:16 AM, Tom Marchant < 
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 21 Sep 2017 02:29:11 +, Jesse 1 Robinson wrote:
>
> >What if we created something like this:
> >
> >++USERMOD (HSC) REWORK(date) .
> >++VER (Z038)  FMID (hsc-fmid) .
> >++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD .
> >
> >where LINKLIB is SYS1.LINKLIB.
>
> I don't like it. Which SYS1.LINKLIB? The one on your current IPL 
> volume? Or do you have a single target zone where you always apply 
> maintenance, with a VOLSER that never changes?
>
> A better choice, IMO, is a new data set that you create for this 
> purpose. Or perhaps you have an installation library that makes sense 
> to add to LNKLST.
>
> Also, rather than ++MOVE, you can add a second SYSLIB for that module.
>
> I don't see the disadvantage of adding the load library to LNKLST.
> Are you approaching the 255 extent limit for LNKLST? I believe that 
> with LLA and VLF it is no longer necessary to be concerned about the 
> performance of LNKLST with a large concatenation.
>
> --
> Tom Marchant
>

​What I have in my linklist PROGnn member starts like:

SYSLIB LINKLIB(SYS1.)
SYSLIB MIGLIB(SYS1.MIGLIB)
SYSLIB CSSLIB(SYS1.CSSLIB)
SYSLIB LPALIB(SYS1.)
/*
   START THE ACTUAL LINK LIST
*/
LNKLST DEFINE NAME(LNKLST00) /* GIVE THE LINK LIST A NAME */ LNKLST ADD 
NAME(LNKLST00) DSN(SYS1.) LNKLST ADD NAME(LNKLST00) 
DSN(SYS1.LINKLIB)​


​My LPALSTnn starts with:

SYS1.,
SYS1.LPALIB,
ISF.SISFLPA,​


​Each z/OS image has it's own, "private", LPALIB & LINKLIB which are the very 
first in their respective lists. I keep _all_ the vendor LPALIB resident 
modules in the SYS1. library. I keep all the "override" and "in 
house" LINKLIST members in SYS1. By "override", I mean when I 
or a vendor wants to "replace" an IBM module.​


--
*L'Shanah Tovah Tikatevu*

Maranatha! <><
John McKown


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

Re: Keeping SSN init modules current

[Jesse 1 Robinson]

Here is an example of an SCLM module 'moved' from LPA to link list by usermod 
ISPF003:

Entry Type:  LMOD 
Entry Name:  FLMIO24  
RETURN CODE: 0   LASTUPD: ISPF003   TYPE=MOV  
Link-edit Parameters: 
RENT,REUS,NCAL  

  LINK-EDIT CONTROL STATEMENTS 
---
  ENTRY FLM$CP 
   ORDER FLM$CP,FLMCOPYR   
   ALIAS FLM$CP
   ALIAS FLM$DE
   ALIAS FLM$DT
   ALIAS FLM$99
   ALIAS FLMCXCPD  
   ALIAS FLMCXCPM  
   ALIAS FLMCXCTN  
   ALIAS FLMCXCMD  
   ALIAS FLMCSLNK  
   ALIAS FLMCXGPD  
   ALIAS FLMCXPLS  
   ALIAS FLMCXRDI  
   ALIAS FLMCXSLM  
   ALIAS FLMCXSSR  
   ALIAS FLMCXUDI  
   ALIAS FLMCXXDD  
   ALIAS FLMCXTPT  
  MODE AMODE(24),RMODE(24)

It seems to have all the expected properties, just in a different load library. 
I'm thinking that moving the HSC SSN module to (SYS1.)LINKLIB would achieve 
similar results. This LINKLIB is an SMPE install-only library on a target 
sysres that gets migrated all around the enterprise. Currently the module must 
be copied manually to an off-sysres linklist library on every system where HSC 
runs in five different sysplexes, likely months apart. 

A usermod would be applied once at product install and cover all current (and 
future, if any) tape-handling systems. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, September 21, 2017 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping SSN init modules current

Jesse 1 Robinson wrote:
> Looking for a life hack to manage subsystem initialization modules. We 
> recently discovered that our tape management (HSC/Oracle) SSN init routine 
> was 12 years out of date. The problem is that the load library itself does 
> not need to be in link list as it is STEPLIBed to in the HSC proc. But the 
> SSN init routine needs to be found at IPL time, so we copy it into a link 
> list library. And then forget about it. One solution it to put the whole load 
> library into link list, but that seems a bit extreme for all similar products.
>
> Does anyone have a fairly foolproof technique for keeping the SSN init module 
> up to date short of depending on doc-which will surely get missed somewhere 
> down the road.

What does the vendor recommend?

My rambling thoughts are these:

For DIY, a ++MOVE usermod will get it on the books so you don't forget to 
update the module at system build time, but if the vendor ships JCLIN to change 
the module structure, SMP/E will, quite obligingly and without any fanfare, 
"put it back where it belongs" on your behalf, and the copy you are using will 
be downlevel again.

You could write a usermod with JCLIN to add a part the the module (a renamed 
copy of IEFBR14 works fine and takes little or no additional
memory) and a second link step with a SYSLMOD that points where you want the 
module to go, making it resident in more than one library.  Now, SMP/E will 
happily update both copies automagically.  But such a usermod needs to be 
reworked for every release, and something nagging in the back of my head says 
there's another potential pitfall if the vendor ships service to delete and 
redefine the load module in a particular way.

You could write a usermod to "repackage" (i.e., include) all the MODs for the 
LMOD to change their RMIDs.  Future PTFs APPLYs get stopped cold until the 
usermod is removed, but you will have to rework it every time any MOD in the 
load module is serviced, and this begins to sound a lot like (*-ick-*) "work."

Any reason not to take the easy way out?  Are you short of link list extents?  
Alternatively, if it's RENT, you could put the module in MLPA or Dynamic LPA, 
if there's room for it (i.e., you're not pushing the envelope on 24- or 31-bit 
private), which is sort of drastic (LPA for a module run once per IPL is 
overkill in a way) but could be a cheap, dirty, and dur

Re: Keeping SSN init modules current

[John Eells]

Jesse 1 Robinson wrote:

Looking for a life hack to manage subsystem initialization modules. We recently 
discovered that our tape management (HSC/Oracle) SSN init routine was 12 years 
out of date. The problem is that the load library itself does not need to be in 
link list as it is STEPLIBed to in the HSC proc. But the SSN init routine needs 
to be found at IPL time, so we copy it into a link list library. And then 
forget about it. One solution it to put the whole load library into link list, 
but that seems a bit extreme for all similar products.

Does anyone have a fairly foolproof technique for keeping the SSN init module 
up to date short of depending on doc-which will surely get missed somewhere 
down the road.


What does the vendor recommend?

My rambling thoughts are these:

For DIY, a ++MOVE usermod will get it on the books so you don't forget 
to update the module at system build time, but if the vendor ships JCLIN 
to change the module structure, SMP/E will, quite obligingly and without 
any fanfare, "put it back where it belongs" on your behalf, and the copy 
you are using will be downlevel again.


You could write a usermod with JCLIN to add a part the the module (a 
renamed copy of IEFBR14 works fine and takes little or no additional 
memory) and a second link step with a SYSLMOD that points where you want 
the module to go, making it resident in more than one library.  Now, 
SMP/E will happily update both copies automagically.  But such a usermod 
needs to be reworked for every release, and something nagging in the 
back of my head says there's another potential pitfall if the vendor 
ships service to delete and redefine the load module in a particular way.


You could write a usermod to "repackage" (i.e., include) all the MODs 
for the LMOD to change their RMIDs.  Future PTFs APPLYs get stopped cold 
until the usermod is removed, but you will have to rework it every time 
any MOD in the load module is serviced, and this begins to sound a lot 
like (*-ick-*) "work."


Any reason not to take the easy way out?  Are you short of link list 
extents?  Alternatively, if it's RENT, you could put the module in MLPA 
or Dynamic LPA, if there's room for it (i.e., you're not pushing the 
envelope on 24- or 31-bit private), which is sort of drastic (LPA for a 
module run once per IPL is overkill in a way) but could be a cheap, 
dirty, and durable solution.


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

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

Re: Keeping SSN init modules current

[John McKown]

On Thu, Sep 21, 2017 at 11:16 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 21 Sep 2017 02:29:11 +, Jesse 1 Robinson wrote:
>
> >What if we created something like this:
> >
> >++USERMOD (HSC) REWORK(date) .
> >++VER (Z038)  FMID (hsc-fmid) .
> >++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD .
> >
> >where LINKLIB is SYS1.LINKLIB.
>
> I don't like it. Which SYS1.LINKLIB? The one on your current
> IPL volume? Or do you have a single target zone where you
> always apply maintenance, with a VOLSER that never changes?
>
> A better choice, IMO, is a new data set that you create for
> this purpose. Or perhaps you have an installation library that
> makes sense to add to LNKLST.
>
> Also, rather than ++MOVE, you can add a second SYSLIB
> for that module.
>
> I don't see the disadvantage of adding the load library to LNKLST.
> Are you approaching the 255 extent limit for LNKLST? I believe
> that with LLA and VLF it is no longer necessary to be concerned
> about the performance of LNKLST with a large concatenation.
>
> --
> Tom Marchant
>

​What I have in my linklist PROGnn member starts like:

SYSLIB LINKLIB(SYS1.)
SYSLIB MIGLIB(SYS1.MIGLIB)
SYSLIB CSSLIB(SYS1.CSSLIB)
SYSLIB LPALIB(SYS1.)
/*
   START THE ACTUAL LINK LIST
*/
LNKLST DEFINE NAME(LNKLST00) /* GIVE THE LINK LIST A NAME */
LNKLST ADD NAME(LNKLST00) DSN(SYS1.)
LNKLST ADD NAME(LNKLST00) DSN(SYS1.LINKLIB)​


​My LPALSTnn starts with:

SYS1.,
SYS1.LPALIB,
ISF.SISFLPA,​


​Each z/OS image has it's own, "private", LPALIB & LINKLIB which are the
very first in their respective lists. I keep _all_ the vendor LPALIB
resident modules in the SYS1. library. I keep all the
"override" and "in house" LINKLIST members in SYS1. By
"override", I mean when I or a vendor wants to "replace" an IBM module.​


-- 
*L'Shanah Tovah Tikatevu*

Maranatha! <><
John McKown

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

Re: Keeping SSN init modules current

[Tom Marchant]

On Thu, 21 Sep 2017 02:29:11 +, Jesse 1 Robinson wrote:

>What if we created something like this:
>
>++USERMOD (HSC) REWORK(date) . 
>++VER (Z038)  FMID (hsc-fmid) . 
>++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD .
>
>where LINKLIB is SYS1.LINKLIB. 

I don't like it. Which SYS1.LINKLIB? The one on your current 
IPL volume? Or do you have a single target zone where you 
always apply maintenance, with a VOLSER that never changes?

A better choice, IMO, is a new data set that you create for 
this purpose. Or perhaps you have an installation library that 
makes sense to add to LNKLST.

Also, rather than ++MOVE, you can add a second SYSLIB 
for that module.

I don't see the disadvantage of adding the load library to LNKLST. 
Are you approaching the 255 extent limit for LNKLST? I believe 
that with LLA and VLF it is no longer necessary to be concerned 
about the performance of LNKLST with a large concatenation.

-- 
Tom Marchant

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

Re: Keeping SSN init modules current

[Rob Schramm]

Another vote for usermod.

Rob Schramm

On Thu, Sep 21, 2017 at 2:26 AM Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> Making the SSI init module available at IPL time was part of our
> installation and upgrade scenario (when we had an HSC).
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Jesse 1 Robinson
> > Sent: 20 September, 2017 23:05
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Keeping SSN init modules current
> >
> > Looking for a life hack to manage subsystem initialization modules. We
> > recently discovered that our tape management (HSC/Oracle) SSN init
> > routine was 12 years out of date. The problem is that the load library
> > itself does not need to be in link list as it is STEPLIBed to in the HSC
> > proc. But the SSN init routine needs to be found at IPL time, so we copy
> > it into a link list library. And then forget about it. One solution it
> > to put the whole load library into link list, but that seems a bit
> > extreme for all similar products.
> >
> > Does anyone have a fairly foolproof technique for keeping the SSN init
> > module up to date short of depending on doc-which will surely get missed
> > somewhere down the road.
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 <(323)%20715-0595> Mobile
> > 626-543-6132 <(626)%20543-6132> Office <= NEW
> > robin...@sce.com<mailto:robin...@sce.com>
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: Keeping SSN init modules current

[Vernooij, Kees (ITOPT1) - KLM]

Making the SSI init module available at IPL time was part of our installation 
and upgrade scenario (when we had an HSC).

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 20 September, 2017 23:05
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Keeping SSN init modules current
> 
> Looking for a life hack to manage subsystem initialization modules. We
> recently discovered that our tape management (HSC/Oracle) SSN init
> routine was 12 years out of date. The problem is that the load library
> itself does not need to be in link list as it is STEPLIBed to in the HSC
> proc. But the SSN init routine needs to be found at IPL time, so we copy
> it into a link list library. And then forget about it. One solution it
> to put the whole load library into link list, but that seems a bit
> extreme for all similar products.
> 
> Does anyone have a fairly foolproof technique for keeping the SSN init
> module up to date short of depending on doc-which will surely get missed
> somewhere down the road.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com<mailto:robin...@sce.com>
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: Keeping SSN init modules current

[Anthony Thompson]

Beat me to it. I was going to suggest a ++MOVE usermod, provided the SSI module 
is SMP/E-maintained.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, 21 September 2017 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Keeping SSN init modules current

In poking around our stable of usermods, I find this usermod for ISPF:

++USERMOD (ISPF003) REWORK(20141710) . 
++VER (Z038)  FMID (HIF7N02) . 
++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD .
..

The point of this IBM-suggested usermod is to move SCLM modules from LPA to 
link list for shops that don't utilize SCLM heavily. What if we created 
something like this:

++USERMOD (HSC) REWORK(date) . 
++VER (Z038)  FMID (hsc-fmid) . 
++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD .

where LINKLIB is SYS1.LINKLIB. 

Future HSC maintenance, if any, would find the module in SYS1.LINKLIB and keep 
it up to date until the next upgrade, which would require reAPPLYing the 
usermod.


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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Wednesday, September 20, 2017 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping SSN init modules current

I was thinking of similar craziness, but I'd replace the actual HSC init 
program with my own.  Then like you implied, that code would dynamically 
allocate the DSN and do a LOAD DCB= to get the real module into memory. 
  Then deallocate, restore registers (to what they were at entry), branch, and 
"The OS will never know" (famous last words).

This method would also mean following a convention I've argued for over many 
years:  "Never use version numbers in production load library names".

Ok!  Now back to the real world and just go update the doc :)

Mark Jacobs - Listserv wrote:
> Here's a wild thought. Create your own dummy subsystem with its own 
> initialization routine that gets executed before any of the subsystems 
> you're concerned about. This initialization routine can load the other 
> modules into CSA, or even copy from one library to a linklist library.
> We have an installation defined dummy subsystem that uses the 
> initialization routine to define system level name/token pairs during 
> the IPL process.
> 


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

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

Re: Keeping SSN init modules current

[Jesse 1 Robinson]

In poking around our stable of usermods, I find this usermod for ISPF:

++USERMOD (ISPF003) REWORK(20141710) . 
++VER (Z038)  FMID (HIF7N02) . 
++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD .
..

The point of this IBM-suggested usermod is to move SCLM modules from LPA to 
link list for shops that don't utilize SCLM heavily. What if we created 
something like this:

++USERMOD (HSC) REWORK(date) . 
++VER (Z038)  FMID (hsc-fmid) . 
++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD .

where LINKLIB is SYS1.LINKLIB. 

Future HSC maintenance, if any, would find the module in SYS1.LINKLIB and keep 
it up to date until the next upgrade, which would require reAPPLYing the 
usermod.


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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Wednesday, September 20, 2017 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping SSN init modules current

I was thinking of similar craziness, but I'd replace the actual HSC init 
program with my own.  Then like you implied, that code would dynamically 
allocate the DSN and do a LOAD DCB= to get the real module into memory. 
  Then deallocate, restore registers (to what they were at entry), branch, and 
"The OS will never know" (famous last words).

This method would also mean following a convention I've argued for over many 
years:  "Never use version numbers in production load library names".

Ok!  Now back to the real world and just go update the doc :)

Mark Jacobs - Listserv wrote:
> Here's a wild thought. Create your own dummy subsystem with its own 
> initialization routine that gets executed before any of the subsystems 
> you're concerned about. This initialization routine can load the other 
> modules into CSA, or even copy from one library to a linklist library.
> We have an installation defined dummy subsystem that uses the 
> initialization routine to define system level name/token pairs during 
> the IPL process.
> 


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

Re: Keeping SSN init modules current

[Tom Brennan]

I was thinking of similar craziness, but I'd replace the actual HSC init 
program with my own.  Then like you implied, that code would dynamically 
allocate the DSN and do a LOAD DCB= to get the real module into memory. 
 Then deallocate, restore registers (to what they were at entry), 
branch, and "The OS will never know" (famous last words).


This method would also mean following a convention I've argued for over 
many years:  "Never use version numbers in production load library names".


Ok!  Now back to the real world and just go update the doc :)

Mark Jacobs - Listserv wrote:
Here's a wild thought. Create your own dummy subsystem with its own 
initialization routine that gets executed before any of the subsystems 
you're concerned about. This initialization routine can load the other 
modules into CSA, or even copy from one library to a linklist library. 
We have an installation defined dummy subsystem that uses the 
initialization routine to define system level name/token pairs during 
the IPL process.




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

Re: Keeping SSN init modules current

[Mark Jacobs - Listserv]

Here's a wild thought. Create your own dummy subsystem with its own 
initialization routine that gets executed before any of the subsystems 
you're concerned about. This initialization routine can load the other 
modules into CSA, or even copy from one library to a linklist library. 
We have an installation defined dummy subsystem that uses the 
initialization routine to define system level name/token pairs during 
the IPL process.



Jesse 1 Robinson 
September 20, 2017 at 5:04 PM
Looking for a life hack to manage subsystem initialization modules. We 
recently discovered that our tape management (HSC/Oracle) SSN init 
routine was 12 years out of date. The problem is that the load library 
itself does not need to be in link list as it is STEPLIBed to in the 
HSC proc. But the SSN init routine needs to be found at IPL time, so 
we copy it into a link list library. And then forget about it. One 
solution it to put the whole load library into link list, but that 
seems a bit extreme for all similar products.


Does anyone have a fairly foolproof technique for keeping the SSN init 
module up to date short of depending on doc-which will surely get 
missed somewhere down the road.


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


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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

Keeping SSN init modules current

[Jesse 1 Robinson]

Looking for a life hack to manage subsystem initialization modules. We recently 
discovered that our tape management (HSC/Oracle) SSN init routine was 12 years 
out of date. The problem is that the load library itself does not need to be in 
link list as it is STEPLIBed to in the HSC proc. But the SSN init routine needs 
to be found at IPL time, so we copy it into a link list library. And then 
forget about it. One solution it to put the whole load library into link list, 
but that seems a bit extreme for all similar products.

Does anyone have a fairly foolproof technique for keeping the SSN init module 
up to date short of depending on doc-which will surely get missed somewhere 
down the road.

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


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