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
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 ins
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
A.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
@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
, 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
> -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
> >
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 .
>
>wh
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
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
sday, 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 routin
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
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 overrid
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
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 matt
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,
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,
17 matches
Mail list logo
