Re: Cloning a Sysres and ZFS

[Chambers, James]

Hi Bart,

Thanks the below is exactly what I was looking to find out. I think the reason 
the HFS are all in the master catalog is it worked and nobody thought to change 
it, now that we are converting to ZFS we need to change it.

Thanks

James


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of van der Grijn, Bart (B)
Sent: 18 January 2016 12:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cloning a Sysres and ZFS

Hi James, 

We clone our sysres (maintained in sandbox) every month to generate IPL volumes 
for the Dev and Prod LPARs. Almost all datasets on the sysres volume are in a 
user catalog on that same sysres, including the VERSION zFS. We don't have a 
single zFS in the master catalog. We're 2.1 now, but have had this setup for a 
number of releases, so I don't see any reason why you would need your zFS in 
Master for your 1.13 systems.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chambers, James
Sent: Monday, January 18, 2016 5:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cloning a Sysres and ZFS

Hi,

We use a process of cloning on our Dev lpar to create new Sysres before we 
apply maintenance, it has worked fine for Zos 1r13 but we only used HFS. We 
have started to use ZFS for 2r1 which is fine if the Sysres is for the same 
Lpar the clone process is run on but I am now cloning a Sysres for another Lpar.

I can't get the ZFS datasets accessible in both master catalogs at the same 
time, I know now that it is because they are Vsam datasets so cannot be in 2 
catalogs. I want them to be in both so I can apply maintenance on our Dev lpar 
rather than risk a mistake or accident causing a problem in production.

Can they be in a user catalog? I know they are not now because they are used 
very early on in the IPL but is it an option?

Is there an easy way to move ZFS datasets between 2 master catalogs? The only 
option I can think of at the moment is running the clone process from the 
current Sysres to a new one in the prod lpar so everything will be in the prod 
catalog.

Thanks

James

James Chambers
IT Operations & IBM Support Team Lead

56/59 St. Stephen's Green,
Dublin 2

Ph: +353 1 669 5127


"BANKEMFB" made the following annotations.
--
This is a confidential communication and is intended only for the addressee 
indicated in the message (or duly authorised to be responsible for the delivery 
of the message to such person). You are specifically prohibited from copying 
this message or delivering the same, or any part thereof, to any other person, 
whomsoever or howsoever, unless you receive written authorisation from us to 
do. 

 

If you are anyone other than the intended addressee, or person duly authorised 
and responsible for the delivery of this message to the intended addressee, you 
should destroy this message and notify us immediately. 

 

Please note that we accept no responsibility whatsoever in the event that this 
message or any other email message or any part thereof becomes known or is 
communicated to anyone other than the intended recipient or other person 
authorised in writing by us to receive it, howsoever arising and disclaim all 
liability for any losses or damage which may be sustained by any person as a 
result thereof.

 

Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied 
Assurance Agent for Irish Life Assurance plc.

 

Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 
56-59, St. Stephen?s Green, Dublin 2, Ireland.
==

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


"BANKEMFB" made the following annotations.
--
This is a confidential communication and is intended only for the addressee 
indicated in the message (or duly authorised to be responsible for the delivery 
of the message to such person). You are specifically prohibited from copying 
this message or delivering the same, or any part thereof, to any other person, 
whomsoever or howsoever, unless you receive written authorisation from us to 
do. 

 

If you are anyone other than the intended addressee, or person duly authorised 
and responsible for the delivery of this message to the intended addressee, you 
should destroy this message and notify us immediately. 

 

Please note that we accept no responsibility whatsoever in the event 

Re: Cloning a Sysres and ZFS

[Chambers, James]

Hi John,

You mention using ZONEEDIT to point the DDDEFs into Never-Never Land to stop 
production dataset being updated by accident. 

All our DDDEFs use the volume so the targets always points at the correct 
datasets but this doesn't work for our HFS or ZFS because they need to be 
mounted at /Service. We then ZONEEDIT the DDDEFs to point at /Service instead 
of /, this needs to be changed back to / when finished. This works but  when I 
was starting out applying maintenance to Zos I did make a mistake and had not 
done the ZONEEDIT to change / to /Service and mount the HFS because it wasn't 
an issue for the other products I did SMPE for at the time.

Is there a better way to deal with the HFS or ZFS DDDEFs? 

Thanks

James

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: 18 January 2016 14:05
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cloning a Sysres and ZFS

To expand on that thought a bit:

- You can name the usercatalog using the volume name.

- You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog thusly 
named in the master catalog on the production system.

- If you have more than one volume in your target volume set, you can derive 
system symbols for the other volumes from the system-provided
 symbol, given that you name them in a way that makes the volume names 
derivable (such as ZOSR1, ZOSR2, etc.).

- You can put the SMP/E CSI data set on the sysres, too, and catalog it in the 
same catalog.  This has four benefits. First, you have the inventory matching 
the data sets on the same volume, so they stay in sync.  Second, you can get 
information from the zones that match the data sets any time without worrying 
about selecting the "right" zones to match the system's level.  Third, z/OSMF's 
Software Management needs the zones for reporting to help answer questions like 
"where do I NOT have this fix" and "when do I lose support for the products I 
have deployed"? 
  Fourth, you can at need clone and install service to the production level of 
software without the need to have any other system available. 
(If you worry about updating production data sets by accident, use ZONEEDIT to 
point all the DDDEFs into Never-Never Land.)

Also, you can use a similar technique for subsystem (e.g., DB2) data sets, 
except that you will need to change the symbols yourself because the system 
will not build them for you.  Since you can use SETLOAD IEASYM and IEASYMU2 to 
update the active symbols on z/OS V2.1 and up, you can even dynamically switch 
back and forth at need.

van der Grijn, Bart , B wrote:
> Hi James,
>
> We clone our sysres (maintained in sandbox) every month to generate IPL 
> volumes for the Dev and Prod LPARs. Almost all datasets on the sysres volume 
> are in a user catalog on that same sysres, including the VERSION zFS. We 
> don't have a single zFS in the master catalog. We're 2.1 now, but have had 
> this setup for a number of releases, so I don't see any reason why you would 
> need your zFS in Master for your 1.13 systems.

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


"BANKEMFB" made the following annotations.
--
This is a confidential communication and is intended only for the addressee 
indicated in the message (or duly authorised to be responsible for the delivery 
of the message to such person). You are specifically prohibited from copying 
this message or delivering the same, or any part thereof, to any other person, 
whomsoever or howsoever, unless you receive written authorisation from us to 
do. 

 

If you are anyone other than the intended addressee, or person duly authorised 
and responsible for the delivery of this message to the intended addressee, you 
should destroy this message and notify us immediately. 

 

Please note that we accept no responsibility whatsoever in the event that this 
message or any other email message or any part thereof becomes known or is 
communicated to anyone other than the intended recipient or other person 
authorised in writing by us to receive it, howsoever arising and disclaim all 
liability for any losses or damage which may be sustained by any person as a 
result thereof.

 

Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied 
Assurance Agent for Irish Life Assurance plc.

 

Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 
56-59, St. Stephen?s Green, Dublin 2, Ireland.
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Cloning a Sysres and ZFS

[John Eells]

To expand on that thought a bit:

- You can name the usercatalog using the volume name.

- You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog 
thusly named in the master catalog on the production system.


- If you have more than one volume in your target volume set, you can 
derive system symbols for the other volumes from the system-provided 
 symbol, given that you name them in a way that makes the volume 
names derivable (such as ZOSR1, ZOSR2, etc.).


- You can put the SMP/E CSI data set on the sysres, too, and catalog it 
in the same catalog.  This has four benefits. First, you have the 
inventory matching the data sets on the same volume, so they stay in 
sync.  Second, you can get information from the zones that match the 
data sets any time without worrying about selecting the "right" zones to 
match the system's level.  Third, z/OSMF's Software Management needs the 
zones for reporting to help answer questions like "where do I NOT have 
this fix" and "when do I lose support for the products I have deployed"? 
 Fourth, you can at need clone and install service to the production 
level of software without the need to have any other system available. 
(If you worry about updating production data sets by accident, use 
ZONEEDIT to point all the DDDEFs into Never-Never Land.)


Also, you can use a similar technique for subsystem (e.g., DB2) data 
sets, except that you will need to change the symbols yourself because 
the system will not build them for you.  Since you can use SETLOAD 
IEASYM and IEASYMU2 to update the active symbols on z/OS V2.1 and up, 
you can even dynamically switch back and forth at need.


van der Grijn, Bart , B wrote:

Hi James,

We clone our sysres (maintained in sandbox) every month to generate IPL volumes 
for the Dev and Prod LPARs. Almost all datasets on the sysres volume are in a 
user catalog on that same sysres, including the VERSION zFS. We don't have a 
single zFS in the master catalog. We're 2.1 now, but have had this setup for a 
number of releases, so I don't see any reason why you would need your zFS in 
Master for your 1.13 systems.


--
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: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Charles Mills]

Depending on which of my several (G ...) IBM sign-ins I use, I either get a 
password error or a 500.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of william janulin
Sent: Monday, January 18, 2016 2:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A useful(?) RFE: Enhance the S, F and L line commands to work with 
hidden lines

link is not accessable 

On Sunday, January 17, 2016 4:16 PM, Robert Prins 
 wrote:
 

 If you consider this useful, please vote for it.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=82590

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

Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Vernooij, CP (ITOPT1) - KLM]

Could you post the text here? I am curious about you want, that is not 
available now.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 18 January, 2016 16:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A useful(?) RFE: Enhance the S, F and L line commands to work with 
hidden lines

Depending on which of my several (G ...) IBM sign-ins I use, I either get a 
password error or a 500.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of william janulin
Sent: Monday, January 18, 2016 2:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A useful(?) RFE: Enhance the S, F and L line commands to work with 
hidden lines

link is not accessable 

On Sunday, January 17, 2016 4:16 PM, Robert Prins 
 wrote:
 

 If you consider this useful, please vote for it.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=82590

--
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: Cloning a Sysres and ZFS

[Tom Marchant]

On Mon, 18 Jan 2016 09:04:53 -0500, John Eells wrote:

>- You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog
>thusly named in the master catalog on the production system.

There used to be a requirement that the alias and the data set name be in 
the same catalog. I see in Managing Catalogs that the requirement has been 
lifted in z/OS 2.2 for SYMBOLICRELATE. That's something that I hadn't 
noticed. Thanks for calling attention to it, John.

The OP is z/OS 1.13 and 2.1, though, so it doesn't help him, unless the 
requirement was lifted earlier and not documented until 2.2.

-- 
Tom Marchant

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

Re: Cloning a Sysres and ZFS

[Tom Marchant]

On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote:

>Is there a better way to deal with the HFS or ZFS DDDEFs? 

Include the SYSRES VOLSER as part of the dsname. When you 
mount it, you can use  in the mount specification.

-- 
Tom Marchant

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

Cloning a Sysres and ZFS

[Chambers, James]

Hi,

We use a process of cloning on our Dev lpar to create new Sysres before we 
apply maintenance, it has worked fine for Zos 1r13 but we only used HFS. We 
have started to use ZFS for 2r1 which is fine if the Sysres is for the same 
Lpar the clone process is run on but I am now cloning a Sysres for another Lpar.

I can't get the ZFS datasets accessible in both master catalogs at the same 
time, I know now that it is because they are Vsam datasets so cannot be in 2 
catalogs. I want them to be in both so I can apply maintenance on our Dev lpar 
rather than risk a mistake or accident causing a problem in production.

Can they be in a user catalog? I know they are not now because they are used 
very early on in the IPL but is it an option?

Is there an easy way to move ZFS datasets between 2 master catalogs? The only 
option I can think of at the moment is running the clone process from the 
current Sysres to a new one in the prod lpar so everything will be in the prod 
catalog.

Thanks

James

James Chambers
IT Operations & IBM Support Team Lead

56/59 St. Stephen's Green,
Dublin 2

Ph: +353 1 669 5127


"BANKEMFB" made the following annotations.
--
This is a confidential communication and is intended only for the addressee 
indicated in the message (or duly authorised to be responsible for the delivery 
of the message to such person). You are specifically prohibited from copying 
this message or delivering the same, or any part thereof, to any other person, 
whomsoever or howsoever, unless you receive written authorisation from us to 
do. 

 

If you are anyone other than the intended addressee, or person duly authorised 
and responsible for the delivery of this message to the intended addressee, you 
should destroy this message and notify us immediately. 

 

Please note that we accept no responsibility whatsoever in the event that this 
message or any other email message or any part thereof becomes known or is 
communicated to anyone other than the intended recipient or other person 
authorised in writing by us to receive it, howsoever arising and disclaim all 
liability for any losses or damage which may be sustained by any person as a 
result thereof.

 

Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied 
Assurance Agent for Irish Life Assurance plc.

 

Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 
56-59, St. Stephen?s Green, Dublin 2, Ireland.
==

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

Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[william janulin]

link is not accessable 

On Sunday, January 17, 2016 4:16 PM, Robert Prins 
 wrote:
 

 If you consider this useful, please vote for it.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=82590

Robert
-- 
Robert AH Prins
robert.ah.pr...@gmail.com

--
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 How to change sysplex name

[Skip Robinson]

Changing sysplex name will certainly require an XCF 'cold start'. That is,
all members must down, then IPL each member into the new sysplex. I can't
look at our CDSes at the moment, but in every case where the format control
statements contain sysplex name, you must format a new CDS with the new
name. Don't touch any of the existing CDSes in case you have to fall back.
Create new ones with new DSNs. 

You may need to try this iteratively in order to find and correct all the
places where sysplex name is embedded. This change is not merely cosmetic.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Monday, January 18, 2016 08:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] How to change sysplex name
> 
> The system is in monoplex mode, IPL is acceptable.
> How to do it?
> Replace sysplex CDS when system is down?
> What about other CDS'es?
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
AIN

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

Re: Cloning a Sysres and ZFS

[Jerry Whitteridge]

We also use a form of this strategy so there is NEVER a chance the running 
environments get impacted.
Service is applied to a static environment, and then cloned as necessary to 
form resvol sets. All running systems us indirect cataloging and symbolics to 
locate datasets as needed.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Monday, January 18, 2016 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cloning a Sysres and ZFS

Most posts in this thread seem to support the strategy of 'cloning a running 
system in order to do maintenance'. For as long as I can remember, we have 
pursued the opposite strategy: the service environment is permanent for the 
life of a ServerPac and is cloned to produce running systems to populate the 
Enterprise. DDDEFs, once defined, are never changed; hence the chance of error 
is near zero. There is no overlap between service and running systems. The 
service environment is dump/restored to create running system(s) with 
identifiers like sysplex and/or sysres name embedded in the restored objects. 
Everything is shared within a sysplex; nothing is shared across sysplex 
boundaries.

This strategy is probably incompatible with z/OSMF managed maintenance, but we 
have yet to give that a go.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Chambers, James
> Sent: Monday, January 18, 2016 08:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Cloning a Sysres and ZFS
>
> Hi Tom,
>
> We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the
> path. The below shows a DDDEF taken from the apply, it still means I need to
> make sure I got the mount right and the ZONEEDIT unlike the standard
> DDDEFs that use the volser to make sure the correct dataset is updated.
>
> DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS
> OMVS.RESDD2.ROOT
>
> Thanks
>
> James
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: 18 January 2016 15:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cloning a Sysres and ZFS
>
> On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote:
>
> >Is there a better way to deal with the HFS or ZFS DDDEFs?
>
> Include the SYSRES VOLSER as part of the dsname. When you mount it, you
> can use  in the mount specification.
>
> --
> Tom Marchant

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: How to Dynamically add SUBSYTEM

[Skip Robinson]

I'm reluctant to jump in early with disappointing news, but I think you have to 
IPL. As promising as dynamic SSI sounded when it was introduced, it soon 
exhibited limited usability because a subsystem has to be coded to allow 
dynamic management. Even most IBM subsystems at first did not support dynamic; 
some like Netview still do not.

Your current problem is that the SSI is defined but not properly initialized. 
Deleting and recreating it sounds attractive, but IEFJ036I indicates that your 
subsystem cannot be managed dynamically.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Fred Kaptein
> Sent: Monday, January 18, 2016 09:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] How to Dynamically add SUBSYTEM
> 
> Hello,
> 
> We have a subsystem that did not properly get initialized with the IPL.
> 
> In SYS1.PARMLIB(IEFSSN00) we have the following statement:
>SUBSYS SUBNAME(SSI) INITRTN(SSIPINIT) INITPARM('3') Subsystem SSI is an
> in-house written subsystem.
> 
> During the IPL, we received the following errors:
>   IEFJ004I SUBSYSTEM SSI NOT INITIALIZED - SSIPINIT NOT FOUND
>   IEFJ004I SUBSYSTEM STRP NOT INITIALIZED - STRTPSSI NOT FOUND
> 
> Modules SSIPINIT and STRTPSS  do exist in SYS1.TECH.LINKLIB.
> Data set SYS1.TECH.LINKLIB is properly in the LINKLIST.
> 
> However, SYS1.TECH.LINKLIB was not properly APF authorized during the IPL,
> where it should be.
> We have since APF authorized it.
> 
> How can I initialize this subsystem without an IPL?
> I have tried the following commands:
>SETSSI ADD,SUBNAME=SSI,INITRTN=SSIPINIT,INITPARM='3'
>And received the following response
>IEFJ023I SETSSI ADD COMMAND FOR SUBSYSTEM SSI COMPLETED WITH
> ERRORS
>IEFJ026I SUBSYSTEM SSI IS ALREADY DEFINED TO THE SSI
> 
> 
>SETSSI DEACTIVATE,SUBNAME=SSI
>And received the following response
>IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED
> WITH
>ERRORS
>IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND
> 
>SETSSI ACTIVATE,SUBNAME=SSI
>IEFJ023I SETSSI ACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED
> WITH ERRORS
>IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND
> 
> 
> Does anyone know how we can properly activate this subsystem, without an
> IPL
> 
> Any help is appreciated.
> 
> Fred

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

Re: How to Dynamically add SUBSYTEM

[Jim Mulder]

> We have a subsystem that did not properly get initialized with the IPL.
> 
> In SYS1.PARMLIB(IEFSSN00) we have the following statement:
>SUBSYS SUBNAME(SSI) INITRTN(SSIPINIT) INITPARM('3') 
> Subsystem SSI is an in-house written subsystem.
> 
> During the IPL, we received the following errors:
>   IEFJ004I SUBSYSTEM SSI NOT INITIALIZED - SSIPINIT NOT FOUND 
>   IEFJ004I SUBSYSTEM STRP NOT INITIALIZED - STRTPSSI NOT FOUND 
> 
> Modules SSIPINIT and STRTPSS  do exist in SYS1.TECH.LINKLIB.
> Data set SYS1.TECH.LINKLIB is properly in the LINKLIST.
> 
> However, SYS1.TECH.LINKLIB was not properly APF authorized during 
> the IPL, where it should be.
> We have since APF authorized it.
> 
> How can I initialize this subsystem without an IPL?
> I have tried the following commands:
>SETSSI ADD,SUBNAME=SSI,INITRTN=SSIPINIT,INITPARM='3'
>And received the following response
>IEFJ023I SETSSI ADD COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS 
>IEFJ026I SUBSYSTEM SSI IS ALREADY DEFINED TO THE SSI 
> 
> 
>SETSSI DEACTIVATE,SUBNAME=SSI
>And received the following response
>IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH 
>ERRORS 
>IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND 
> 
>SETSSI ACTIVATE,SUBNAME=SSI
>IEFJ023I SETSSI ACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH 
ERRORS 
>IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND  
> 
> 
> Does anyone know how we can properly activate this subsystem, without an 
IPL

  If you are using the most current release (z/OS 2.2), you can use

SETSSI DELETE,SUBNAME=SSI,FORCE

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY



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

How to Dynamically add SUBSYTEM

[Fred Kaptein]

Hello,

We have a subsystem that did not properly get initialized with the IPL.

In SYS1.PARMLIB(IEFSSN00) we have the following statement:
   SUBSYS SUBNAME(SSI) INITRTN(SSIPINIT) INITPARM('3')  
Subsystem SSI is an in-house written subsystem.

During the IPL, we received the following errors:
  IEFJ004I SUBSYSTEM SSI NOT INITIALIZED - SSIPINIT NOT FOUND
  IEFJ004I SUBSYSTEM STRP NOT INITIALIZED - STRTPSSI NOT FOUND

Modules SSIPINIT and STRTPSS  do exist in SYS1.TECH.LINKLIB.
Data set SYS1.TECH.LINKLIB is properly in the LINKLIST.

However, SYS1.TECH.LINKLIB was not properly APF authorized during the IPL, 
where it should be.
We have since APF authorized it.

How can I initialize this subsystem without an IPL?
I have tried the following commands:
   SETSSI ADD,SUBNAME=SSI,INITRTN=SSIPINIT,INITPARM='3'
   And received the following response
   IEFJ023I SETSSI ADD COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS 
   IEFJ026I SUBSYSTEM SSI IS ALREADY DEFINED TO THE SSI


   SETSSI DEACTIVATE,SUBNAME=SSI
   And received the following response
   IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH 
   ERRORS  
   IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND   

   SETSSI ACTIVATE,SUBNAME=SSI
   IEFJ023I SETSSI ACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS 
   IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND   


Does anyone know how we can properly activate this subsystem, without an IPL

Any help is appreciated.

Fred

  



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

Re: Cloning a Sysres and ZFS

[Skip Robinson]

Most posts in this thread seem to support the strategy of 'cloning a running 
system in order to do maintenance'. For as long as I can remember, we have 
pursued the opposite strategy: the service environment is permanent for the 
life of a ServerPac and is cloned to produce running systems to populate the 
Enterprise. DDDEFs, once defined, are never changed; hence the chance of error 
is near zero. There is no overlap between service and running systems. The 
service environment is dump/restored to create running system(s) with 
identifiers like sysplex and/or sysres name embedded in the restored objects. 
Everything is shared within a sysplex; nothing is shared across sysplex 
boundaries.

This strategy is probably incompatible with z/OSMF managed maintenance, but we 
have yet to give that a go. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Chambers, James
> Sent: Monday, January 18, 2016 08:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Cloning a Sysres and ZFS
> 
> Hi Tom,
> 
> We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the
> path. The below shows a DDDEF taken from the apply, it still means I need to
> make sure I got the mount right and the ZONEEDIT unlike the standard
> DDDEFs that use the volser to make sure the correct dataset is updated.
> 
> DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS
> OMVS.RESDD2.ROOT
> 
> Thanks
> 
> James
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: 18 January 2016 15:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cloning a Sysres and ZFS
> 
> On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote:
> 
> >Is there a better way to deal with the HFS or ZFS DDDEFs?
> 
> Include the SYSRES VOLSER as part of the dsname. When you mount it, you
> can use  in the mount specification.
> 
> --
> Tom Marchant

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

Re: How to Dynamically add SUBSYTEM

[Craig Pace]

Without changing the name the sub-system name, you cannot.


Craig


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: Monday, January 18, 2016 11:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to Dynamically add SUBSYTEM

Hello,

We have a subsystem that did not properly get initialized with the IPL.

In SYS1.PARMLIB(IEFSSN00) we have the following statement:
   SUBSYS SUBNAME(SSI) INITRTN(SSIPINIT) INITPARM('3') Subsystem SSI is an 
in-house written subsystem.

During the IPL, we received the following errors:
  IEFJ004I SUBSYSTEM SSI NOT INITIALIZED - SSIPINIT NOT FOUND
  IEFJ004I SUBSYSTEM STRP NOT INITIALIZED - STRTPSSI NOT FOUND

Modules SSIPINIT and STRTPSS  do exist in SYS1.TECH.LINKLIB.
Data set SYS1.TECH.LINKLIB is properly in the LINKLIST.

However, SYS1.TECH.LINKLIB was not properly APF authorized during the IPL, 
where it should be.
We have since APF authorized it.

How can I initialize this subsystem without an IPL?
I have tried the following commands:
   SETSSI ADD,SUBNAME=SSI,INITRTN=SSIPINIT,INITPARM='3'
   And received the following response
   IEFJ023I SETSSI ADD COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS
   IEFJ026I SUBSYSTEM SSI IS ALREADY DEFINED TO THE SSI


   SETSSI DEACTIVATE,SUBNAME=SSI
   And received the following response
   IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH
   ERRORS
   IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND

   SETSSI ACTIVATE,SUBNAME=SSI
   IEFJ023I SETSSI ACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS
   IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND


Does anyone know how we can properly activate this subsystem, without an IPL

Any help is appreciated.

Fred





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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Jon Butler]

I propose the following fix for the IBM web sites: 

'All links will work without "Deleting all IBM cookies or opening a "private" 
window on your browser." '

;-))

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

Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Charles Mills]

I propose one userid that works on all IBM technical type sites, subject only 
to one's authorization to view or download the particular material.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Butler
Sent: Monday, January 18, 2016 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A useful(?) RFE: Enhance the S, F and L line commands to work with 
hidden lines

I propose the following fix for the IBM web sites: 

'All links will work without "Deleting all IBM cookies or opening a "private" 
window on your browser." '

;-))

--
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: Cloning a Sysres and ZFS

[van der Grijn, Bart (B)]

Hi James, 

We clone our sysres (maintained in sandbox) every month to generate IPL volumes 
for the Dev and Prod LPARs. Almost all datasets on the sysres volume are in a 
user catalog on that same sysres, including the VERSION zFS. We don't have a 
single zFS in the master catalog. We're 2.1 now, but have had this setup for a 
number of releases, so I don't see any reason why you would need your zFS in 
Master for your 1.13 systems.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chambers, James
Sent: Monday, January 18, 2016 5:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cloning a Sysres and ZFS

Hi,

We use a process of cloning on our Dev lpar to create new Sysres before we 
apply maintenance, it has worked fine for Zos 1r13 but we only used HFS. We 
have started to use ZFS for 2r1 which is fine if the Sysres is for the same 
Lpar the clone process is run on but I am now cloning a Sysres for another Lpar.

I can't get the ZFS datasets accessible in both master catalogs at the same 
time, I know now that it is because they are Vsam datasets so cannot be in 2 
catalogs. I want them to be in both so I can apply maintenance on our Dev lpar 
rather than risk a mistake or accident causing a problem in production.

Can they be in a user catalog? I know they are not now because they are used 
very early on in the IPL but is it an option?

Is there an easy way to move ZFS datasets between 2 master catalogs? The only 
option I can think of at the moment is running the clone process from the 
current Sysres to a new one in the prod lpar so everything will be in the prod 
catalog.

Thanks

James

James Chambers
IT Operations & IBM Support Team Lead

56/59 St. Stephen's Green,
Dublin 2

Ph: +353 1 669 5127


"BANKEMFB" made the following annotations.
--
This is a confidential communication and is intended only for the addressee 
indicated in the message (or duly authorised to be responsible for the delivery 
of the message to such person). You are specifically prohibited from copying 
this message or delivering the same, or any part thereof, to any other person, 
whomsoever or howsoever, unless you receive written authorisation from us to 
do. 

 

If you are anyone other than the intended addressee, or person duly authorised 
and responsible for the delivery of this message to the intended addressee, you 
should destroy this message and notify us immediately. 

 

Please note that we accept no responsibility whatsoever in the event that this 
message or any other email message or any part thereof becomes known or is 
communicated to anyone other than the intended recipient or other person 
authorised in writing by us to receive it, howsoever arising and disclaim all 
liability for any losses or damage which may be sustained by any person as a 
result thereof.

 

Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied 
Assurance Agent for Irish Life Assurance plc.

 

Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 
56-59, St. Stephen?s Green, Dublin 2, Ireland.
==

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

How to change sysplex name

[R.S.]

The system is in monoplex mode, IPL is acceptable.
How to do it?
Replace sysplex CDS when system is down?
What about other CDS'es?

--
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.pl
Są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: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Robert Prins]

On 2016-01-18 15:38, Vernooij, CP - KLM , ITOPT1 wrote:

Could you post the text here? I am curious about you want, that is not
available now.


Description: The 'S', 'F' and 'L' line commands are used to reshow hidden lines,
and can only be entered on lines that are not displayed ***and*** not hidden.

It would be very useful if "doubled" ("SS", "FF" and "LL") versions could be
used on the lines immediately above and below hidden lines to display the lines
normally selected by the "single" character versions of these commands.

Use case: To display lines in a block of hidden, lines it's currently required
to first do a "reset hide" and follow that with any of 'S', 'F', or 'L' to
display the required line.

Robert
--
Robert AH Prins
robert(a)prino(d)org
No programming @ http://hitchwiki.org/prino/

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

Re: Cloning a Sysres and ZFS

[Chambers, James]

Hi Tom,

We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the path. 
The below shows a DDDEF taken from the apply, it still means I need to make 
sure I got the mount right and the ZONEEDIT unlike the standard DDDEFs that use 
the volser to make sure the correct dataset is updated.

DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS OMVS.RESDD2.ROOT 

Thanks

James
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 18 January 2016 15:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cloning a Sysres and ZFS

On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote:

>Is there a better way to deal with the HFS or ZFS DDDEFs? 

Include the SYSRES VOLSER as part of the dsname. When you mount it, you can use 
 in the mount specification.

--
Tom Marchant

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


"BANKEMFB" made the following annotations.
--
This is a confidential communication and is intended only for the addressee 
indicated in the message (or duly authorised to be responsible for the delivery 
of the message to such person). You are specifically prohibited from copying 
this message or delivering the same, or any part thereof, to any other person, 
whomsoever or howsoever, unless you receive written authorisation from us to 
do. 

 

If you are anyone other than the intended addressee, or person duly authorised 
and responsible for the delivery of this message to the intended addressee, you 
should destroy this message and notify us immediately. 

 

Please note that we accept no responsibility whatsoever in the event that this 
message or any other email message or any part thereof becomes known or is 
communicated to anyone other than the intended recipient or other person 
authorised in writing by us to receive it, howsoever arising and disclaim all 
liability for any losses or damage which may be sustained by any person as a 
result thereof.

 

Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied 
Assurance Agent for Irish Life Assurance plc.

 

Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 
56-59, St. Stephen’s Green, Dublin 2, Ireland.
==

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

Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Charles Mills]

The link in your signature is 404. Perhaps you mean prins? Also in your 
obfuscated e-mail address?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Monday, January 18, 2016 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A useful(?) RFE: Enhance the S, F and L line commands to work with 
hidden lines

On 2016-01-18 15:38, Vernooij, CP - KLM , ITOPT1 wrote:
> Could you post the text here? I am curious about you want, that is not 
> available now.

Description: The 'S', 'F' and 'L' line commands are used to reshow hidden 
lines, and can only be entered on lines that are not displayed ***and*** not 
hidden.

It would be very useful if "doubled" ("SS", "FF" and "LL") versions could be 
used on the lines immediately above and below hidden lines to display the lines 
normally selected by the "single" character versions of these commands.

Use case: To display lines in a block of hidden, lines it's currently required 
to first do a "reset hide" and follow that with any of 'S', 'F', or 'L' to 
display the required line.

Robert
--
Robert AH Prins
robert(a)prino(d)org
No programming @ http://hitchwiki.org/prino/

--
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: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Robert AH Prins]

On 2016-01-18 15:34, Charles Mills wrote:

Depending on which of my several (G ...) IBM sign-ins I use, I either get
a password error or a 500.


Deleting all IBM cookies (usually) helps, as does opening a "private" window on
your browser.

Robert
--
Robert AH Prins
robert(a)prino(d)org
No programming @ http://hitchwiki.org/prino/

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

Re: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Robert Prins]

On 2016-01-18 16:30, Charles Mills wrote:

The link in your signature is 404. Perhaps you mean prins? Also in your
obfuscated e-mail address?


Changed the link 
. My 
surname is Prins, see  for an 
explanation of "prino". ;)


Robert
--
Robert AH Prins
robert(a)prino(d)org

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

Re: How to Dynamically add SUBSYTEM

[Tom Brennan]

I remember zapping the existing subsystem block in memory to some other 
name and then running the re-init.  Probably not something I would do 
except on a test system or if we were about to IPL anyway.  But from Jim 
Mulder's note, it sounds like 2.2 provides a way to do something similar 
- nice!


Craig Pace wrote:

Without changing the name the sub-system name, you cannot.


Craig


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: Monday, January 18, 2016 11:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to Dynamically add SUBSYTEM

Hello,

We have a subsystem that did not properly get initialized with the IPL.

In SYS1.PARMLIB(IEFSSN00) we have the following statement:
   SUBSYS SUBNAME(SSI) INITRTN(SSIPINIT) INITPARM('3') Subsystem SSI is an 
in-house written subsystem.

During the IPL, we received the following errors:
  IEFJ004I SUBSYSTEM SSI NOT INITIALIZED - SSIPINIT NOT FOUND
  IEFJ004I SUBSYSTEM STRP NOT INITIALIZED - STRTPSSI NOT FOUND

Modules SSIPINIT and STRTPSS  do exist in SYS1.TECH.LINKLIB.
Data set SYS1.TECH.LINKLIB is properly in the LINKLIST.

However, SYS1.TECH.LINKLIB was not properly APF authorized during the IPL, 
where it should be.
We have since APF authorized it.

How can I initialize this subsystem without an IPL?
I have tried the following commands:
   SETSSI ADD,SUBNAME=SSI,INITRTN=SSIPINIT,INITPARM='3'
   And received the following response
   IEFJ023I SETSSI ADD COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS
   IEFJ026I SUBSYSTEM SSI IS ALREADY DEFINED TO THE SSI


   SETSSI DEACTIVATE,SUBNAME=SSI
   And received the following response
   IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH
   ERRORS
   IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND

   SETSSI ACTIVATE,SUBNAME=SSI
   IEFJ023I SETSSI ACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS
   IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND


Does anyone know how we can properly activate this subsystem, without an IPL

Any help is appreciated.

Fred





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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



--
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: A useful(?) RFE: Enhance the S, F and L line commands to work with hidden lines

[Tom Marchant]

On Mon, 18 Jan 2016 18:02:33 +, Robert Prins wrote:

>Description: The 'S', 'F' and 'L' line commands are used to reshow hidden 
>lines,
>and can only be entered on lines that are not displayed ***and*** not hidden.
>
>It would be very useful if "doubled" ("SS", "FF" and "LL") versions could be
>used on the lines immediately above and below hidden lines to display the lines
>normally selected by the "single" character versions of these commands.

I think that SS ... SS pairs would be useful whether or not excluded lines are 
hidden. 
That could allow you to show several ranges of excluded lines all at once.

Another possible implementation of what you are asking for might be to allow 
the F line 
command on the last line before the excluded lines, and the L line command on 
the first 
line before the excluded lines.

-- 
Tom Marchant

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

Re: How to Dynamically add SUBSYTEM

[Scott Ballentine]

To follow up on Jim's comment... there are actually a couple of changes in
z/OS 2.2 that makes this behave differently than older releases.
First, you can delete a subsystem using the SETSSI DELETE command as
Jim noted.
Second, in this case, on z/OS 2.2 you wouldn't even need to do that, you could
just issue SETSSI ADD.

Unfortunately, the subsystem named SSI actually got created, but the 
initialization 
routine didn't run (because of the APF authorization problem.)  So the subsystem
is there, but it's inactive, and there's no way to delete it.  You could 
probably 
write a program that initializes the subsystem (something you could run via a 
START command that more-or-less duplicates the processing in the initialization 
routine.)  You could also create a new subsystem with a different name.  Or
IPL.  (I probably can't comment on zapping control blocks.)

In z/OS 2.2, if we can't load the initialization routine (either because we 
can't find
it, or it's not APF-authorized) we don't create the subsystem.  Since that 
subsystem
named SSI won't exist, you would be able to add it using the SETSSI command.
If there's a different problem that prevents the subsystem from activating 
(maybe
the initialization routine ABENDs, as an example) then you could use the SETSSI
command to delete it and then issue a SETSSI ADD to create it.

-Scott Ballentine (sbal...@us.ibm.com), IBM z/OS Allocation

On Mon, 18 Jan 2016 11:02:47 -0800, Tom Brennan  
wrote:

>I remember zapping the existing subsystem block in memory to some other
>name and then running the re-init.  Probably not something I would do
>except on a test system or if we were about to IPL anyway.  But from Jim
>Mulder's note, it sounds like 2.2 provides a way to do something similar
>- nice!
>
>Craig Pace wrote:
>> Without changing the name the sub-system name, you cannot.
>>
>>
>> Craig
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Fred Kaptein
>> Sent: Monday, January 18, 2016 11:11
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: How to Dynamically add SUBSYTEM
>>
>> Hello,
>>
>> We have a subsystem that did not properly get initialized with the IPL.
>>
>> In SYS1.PARMLIB(IEFSSN00) we have the following statement:
>>SUBSYS SUBNAME(SSI) INITRTN(SSIPINIT) INITPARM('3') Subsystem SSI is an 
>> in-house written subsystem.
>>
>> During the IPL, we received the following errors:
>>   IEFJ004I SUBSYSTEM SSI NOT INITIALIZED - SSIPINIT NOT FOUND
>>   IEFJ004I SUBSYSTEM STRP NOT INITIALIZED - STRTPSSI NOT FOUND
>>
>> Modules SSIPINIT and STRTPSS  do exist in SYS1.TECH.LINKLIB.
>> Data set SYS1.TECH.LINKLIB is properly in the LINKLIST.
>>
>> However, SYS1.TECH.LINKLIB was not properly APF authorized during the IPL, 
>> where it should be.
>> We have since APF authorized it.
>>
>> How can I initialize this subsystem without an IPL?
>> I have tried the following commands:
>>SETSSI ADD,SUBNAME=SSI,INITRTN=SSIPINIT,INITPARM='3'
>>And received the following response
>>IEFJ023I SETSSI ADD COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS
>>IEFJ026I SUBSYSTEM SSI IS ALREADY DEFINED TO THE SSI
>>
>>
>>SETSSI DEACTIVATE,SUBNAME=SSI
>>And received the following response
>>IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH
>>ERRORS
>>IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND
>>
>>SETSSI ACTIVATE,SUBNAME=SSI
>>IEFJ023I SETSSI ACTIVATE COMMAND FOR SUBSYSTEM SSI COMPLETED WITH ERRORS
>>IEFJ036I SUBSYSTEM SSI IS NOT ENABLED FOR THE SETSSI COMMAND
>>
>>
>> Does anyone know how we can properly activate this subsystem, without an IPL
>>
>> Any help is appreciated.
>>
>> Fred
>>
>>
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email 
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>>
>> This communication contains information which is confidential and may also 
>> be privileged. It is for the exclusive use of the intended recipient(s). If 
>> you are not the intended recipient(s), please note that any distribution, 
>> copying or use of this communication or the information in it is strictly 
>> prohibited. If you have received this communication in error, please notify 
>> the sender immediately and then destroy any copies of it.
>>
>> 
>>
>> --
>> 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: Cloning a Sysres and ZFS

[John Eells]

Tom Marchant wrote:

On Mon, 18 Jan 2016 09:04:53 -0500, John Eells wrote:


- You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog
thusly named in the master catalog on the production system.


There used to be a requirement that the alias and the data set name be in
the same catalog. I see in Managing Catalogs that the requirement has been
lifted in z/OS 2.2 for SYMBOLICRELATE. That's something that I hadn't
noticed. Thanks for calling attention to it, John.

The OP is z/OS 1.13 and 2.1, though, so it doesn't help him, unless the
requirement was lifted earlier and not documented until 2.2.


SYMBOLICRELATE was originally implemented at my request to make it 
easier to do subsystem software migration when I worked in ServerPac 
Design, some time ago.


I believe the abilities to use SYMBOLICRELATE to point to a user catalog 
that itself resides on a volume other than the master catalog volume, 
and have that usercatalog point to data sets on any volume, were there 
from its inception many releases ago (well before z/OS V1.13).  Thus, 
one may have:


- A master catalog on volume MCAT, with a user catalog connector alias 
defined using SYMBOLICRELATE that points to the entry for...

- A user catalog on volume UCAT, which contains entries for...
- Data sets on volume ANYVOL.

This does not actually conflict with the requirement you mention (and 
which is documented in prior levels of Access Method Services for 
Catalogs).  The catalog entry for the user catalog and the entry for the 
catalog connector alias defined using SYMBOLICRELATE must indeed both be 
in the same catalog--namely, the master catalog.  Otherwise, Catalog 
could not find the user catalog or relate an alias to it to begin with.


I double-checked with DFSMS Catalog Development to make sure this 
remained true after it was originally implemented, and so far as they 
know, it has not changed since then.  They even tried it out on a V2.1 
system they have handy just to prove it worked.


What did change in z/OS V2.2 is whether the catalog search was 
reoriented to (start with) the master catalog for data set entries that 
use SYMBOLICRELATE when found in user catalogs, which relieves the 
previously-documented restriction for *data set aliases*.  This was the 
announcement text:


"For data set aliases with symbolic-related names, the system is 
designed to reorient the search with the master catalog or the 
appropriate user catalog."


Note that this change applies only to data set aliases, not usercatalog 
connector aliases.  For a user catalog connector alias to be resolved, 
the entry for the user catalog itself must still also be in the master 
catalog.


--
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: Cloning a Sysres and ZFS

[Art Gutowski]

On Mon, 18 Jan 2016 16:03:39 +, Chambers, James 
 wrote:
 
>We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the path. 
>The below shows a DDDEF taken from the >apply, it still means I need to make 
>sure I got the mount right and the ZONEEDIT unlike the standard DDDEFs that 
>use the >volser to make sure the correct dataset is updated. 
> 
>DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS OMVS.RESDD2.ROOT 
> 

Consider something along the lines of:
/Service/zos/RESDD2/usr/lpp/NFS/IBM/
in the DDDEFs.  As part of your cloning process, ZONEEDIT the path names so the 
new path names align with the new filesystem name.

Then, use UNIX automount to manage /Service/zos.  Map /Service/zos/ to 
OMVS..ROOT.  Provided the cloning process goes according to Hoyle, this 
will ensure consistency of maintenance between the MVS and UNIX environments.  

This approach was developed by another regular contributor of this list to 
handle a large number of target environments, but can be used in any sized 
shop.  It is proven and reliable.

Regards,
Art Gutowski
General Motors, LLC

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