Moving SYS1.PARMLIB
Neal Eckhardt
get a job at a new company (for a lot less money of course). Over the last
few months I have been trying to implement some things that I had done in
the past to make things easier to maintain. One of the things was the ability
to share SYS1.PARMLIB among all of the systems. I have now run into the
same problem that I vaguely remember running into 6 or 7 years ago, and
looking at the datasets that I bought with me, it looks like PARMLIB cannot be
moved off of the IPL volume if you need to use a system symbol to resolve
the VOLSER for SYS1.PARMLIB.
The LOADxx member allows you to specify the volume where SYS1.PARMLIB is
located, but it appears to immediately go to the Master Catalog and stops
when it finds the VOLSER there is a system symbol.
What is the point of allowing a VOLSER in LOADxx if you aren't going to use
that volser until the point in the IPL where the symbols in the catalog (except
******) can be resolved?
Neal
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Veilleux, Jon L
Neal
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
Tom Marchant
>... it looks like PARMLIB cannot be
>moved off of the IPL volume if you need to use a system symbol to resolve
>the VOLSER for SYS1.PARMLIB.
Why do you want to move SYS1.PARMLIB? SYS1.PARMLIB is one of your
SMP/E maintained data sets and should not contain anything except what
is distributed by IBM. You should use a PARMLIB concatenation with all of
your modified members in an different data set.
Why do you need to catalog your parmlib with a symbolic volser? One
solution is to put your installation parmlib on your IODF volume.
--
Tom Marchant
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Veilleux, Jon L
> Sent: Friday, October 08, 2010 8:56 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Moving SYS1.PARMLIB
>
> Wouldn't it be easier to create a SYS1.PARMLIB.SHARED to
> house members you want to share and leave the IBM default
> members in SYS1.PARMLIB?
I use SYS1.PARMLIB.PLEX&SYSPLEX and SYS1.PARMLIB.SYS&SYSNAME. With the latter in front of the former.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Guy Gardoit
SMP/E and the PARMLIB DDDEF should point to it. A sample SYS1.PARMLIB is
supplied as part of the installation of z/OS but is not maintained by SMP/E.
Simply take your SYS1.PARMLIB data set off of the system residence volume
unless, of course, that is where you keep your LOADxx member. Personally, I
keep the LOADxx member in SYS0.IPLPARM (on the same volume as the IODF data
sets) instead of in SYS1.PARMLIB to give me the freedom of putting
SYS1.PARMLIB anywhere I choose.
--
Guy Gardoit
z/OS Systems Programming
Mark Zelden
>>moved off of the IPL volume if you need to use a system symbol to resolve
>>the VOLSER for SYS1.PARMLIB.
>
SYS1.PARMLIB can be moved off the sysres and shared. Don't indirectly
catalog it if you are. There does need to be a SYS1.PARMLIB somewhere
in the parmlib concatenation. If you want some other parmlib in the
concatenation to go along with your sysres set that you can use a
system symbol with, don't call it SYS1.PARMLIB.
>Why do you want to move SYS1.PARMLIB? SYS1.PARMLIB is one of your
>SMP/E maintained data sets and should not contain anything except what
>is distributed by IBM. You should use a PARMLIB concatenation with all of
>your modified members in an different data set.
>
>Why do you need to catalog your parmlib with a symbolic volser? One
>solution is to put your installation parmlib on your IODF volume.
>
No, SYS1.PARMLIB is not SMP/E maintained and distributed by IBM. It is
a local data set. IBM changed their parmlib to IBM.PARMLIB a long time
ago (or SYS1.IBM.PARMLIB in many shops). That is what the PARMLIB
DDDEF points to in SMP/E as distributed by ServerPac. Of course you
should include that parmlib in your parmlib concatenation so any changes
made from applying maintenance (that you are taking the defaults for)
are picked up. Even with IBM distributed their own SYS1.PARMLIB, I
never used it. SMP/E pointed to it on the sysres for maintenance, but that
wasn't the one that was cataloged / in-use.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark Zelden
>No, SYS1.PARMLIB is not SMP/E maintained and distributed by IBM. It is
>a local data set. IBM changed their parmlib to IBM.PARMLIB a long time
>ago (or SYS1.IBM.PARMLIB in many shops). That is what the PARMLIB
>DDDEF points to in SMP/E as distributed by ServerPac. Of course you
>should include that parmlib in your parmlib concatenation so any changes
>made from applying maintenance (that you are taking the defaults for)
>are picked up. Even with IBM distributed their own SYS1.PARMLIB, I
>never used it. SMP/E pointed to it on the sysres for maintenance, but that
>wasn't the one that was cataloged / in-use.
>
Ditto for "PROCLIB" (IBM.PROCLIB) - although there is no requirement to
have any SYS1.PROCLIB data set on your system (I have some systems
with no SYS1.PROCLIB).
Neal Eckhardt
wrote:
>Wouldn't it be easier to create a SYS1.PARMLIB.SHARED to house members
you want to share and leave the IBM default members in SYS1.PARMLIB?
>
>-----Original Message-----
I'm trying to cut down on the number of datasets in the PARMLIB
concatenation. I don't like having different datasets for each system since
having to go look for things just makes the task take longer and more error
prone. Having a single SYS1.PARMLIB and using system symbols to pick up the
correct members for each system makes maintenance of the members much
easier. Additionally, when moving to a new level of z/OS you know what
PARMLIB members were changed by looking is SYS1.PARMLIB, and different
z/OS versions can find the proper SYS1.PARMLIB by using the system symbol
defined.
My original question was what good is allowing the specification of a VOLSER
for SYS1.PARMLIB in LOADxx if the OS immediately goes to the catalog and
the IPL fails because it can't resolve the indirect VOLSER in the catalog? It
should use the LOADxx specified VOLSER until the correct VOLSER can be
resolved from the catalog. It just seems to me that allowing the specification
of the VOLSER in LOADxx has no useful purpose as it is currently implemented.
Neal
Dennis Trojak
location in the Mastercat of each system. The VOLSER specified in LOADxx
is for an "additional" SYS1.PARMLIB to be concatenated since it will
always include "SYS1.PARMLIB, as cataloged in the Master Catalog, is
added at the end of the concatenation " as noted in the manual.
Dennis
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Neal Eckhardt
Sent: Friday, October 08, 2010 12:45 PM
To: IBM-...@bama.ua.edu
Subject: Re: Moving SYS1.PARMLIB
Neal Eckhardt
<DENNIS...@RADIOSHACK.COM> wrote:
>So if you only want a single SYS1.PARMLIB then point to the correct
>location in the Mastercat of each system. The VOLSER specified in LOADxx
>is for an "additional" SYS1.PARMLIB to be concatenated since it will
>always include "SYS1.PARMLIB, as cataloged in the Master Catalog, is
>added at the end of the concatenation " as noted in the manual.
>Dennis
And the end of the sentence says:
is added at the end of the concatenation, unless it was specified in a
parmlib.
So this holds some hope.....
But, Example 2 shows:
Example 2: The following example shows the definition of a parmlib
concatenation consisting of MYDSN1.PARMLIB, MYDSN2.PARMLIB,
SYS1.PARMLIB on volume VOL234, MYDSN3.PARMLIB and, additionally,
SYS1.PARMLIB, as cataloged in the master catalog, which will be concatenated
as the last data set in the parmlib concatenation.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
PARMLIB MYDSN1.PARMLIB
PARMLIB MYDSN2.PARMLIB VOL123
PARMLIB SYS1.PARMLIB VOL234
PARMLIB MYDSN3.PARMLIB VOL456
It appears that specifying the VOLSER for SYS1.PARMLIB in this way requires
TWO SYS1.PARMLIB datasets. One on the volume where the PARMLIB
ststement points, and one that is pointed to by the Master Catalog (if they
are not the same). It would make more sense to use the PARMLIB VOLSER
UNTIL there is enough of an operating system available to utilize the system
symbols in the master catalog.
Tom Marchant
>
>My original question was what good is allowing the specification of a VOLSER
>for SYS1.PARMLIB in LOADxx if the OS immediately goes to the catalog and
>the IPL fails because it can't resolve the indirect VOLSER in the catalog? It
>should use the LOADxx specified VOLSER until the correct VOLSER can be
>resolved from the catalog. It just seems to me that allowing the specification
>of the VOLSER in LOADxx has no useful purpose as it is currently implemented.
It doesn't "immediately" go to the catalog.
SYS1.PARMLIB, as cataloged in the master catalog, is always part of
the PARMLIB concatenation. If it has not been specified that way, it
is added to the end of the PARMLIB concatenation. If you have specified
a SYS1.PARMLIB on a specific volume, that one is used (if it can be
found). In addition, SYS1.PARMLIB as cataloged in the master catalog
is used. This is clearly documented.
"Indirect volume serial support can only be used for data sets residing on
SYSRES and its logical extensions."
What symbol were you trying to use to catalog SYS1.PARMLIB? Is it one
that is defined in IEASYMxx?
--
Tom Marchant
Tom Marchant
>It appears that specifying the VOLSER for SYS1.PARMLIB in this way requires
>TWO SYS1.PARMLIB datasets. One on the volume where the PARMLIB
>ststement points, and one that is pointed to by the Master Catalog (if they
>are not the same). It would make more sense to use the PARMLIB VOLSER
>UNTIL there is enough of an operating system available to utilize the system
>symbols in the master catalog.
The system symbols that are defined where? In PARMLIB?
Perhaps you want to change the PARMLIB concatenation after the IPL
using SETLOAD. I wouldn't want to do it routinely, but it's not my dog.
You might want to reevaluate your parmlib naming conventions
Neal Eckhardt
ibm...@YAHOO.COM> wrote:
>
>It doesn't "immediately" go to the catalog.
>
>SYS1.PARMLIB, as cataloged in the master catalog, is always part of
>the PARMLIB concatenation. If it has not been specified that way, it
>is added to the end of the PARMLIB concatenation. If you have specified
>a SYS1.PARMLIB on a specific volume, that one is used (if it can be
>found). In addition, SYS1.PARMLIB as cataloged in the master catalog
>is used. This is clearly documented.
>
>"Indirect volume serial support can only be used for data sets residing on
>SYSRES and its logical extensions."
>
>What symbol were you trying to use to catalog SYS1.PARMLIB? Is it one
>that is defined in IEASYMxx?
>
>--
>Tom Marchant
>
Yea, I got that from the Example. &SYSC1, defined in PARMLIB.
Neal
Neal Eckhardt
ibm...@YAHOO.COM> wrote:
>The system symbols that are defined where? In PARMLIB?
>
>Perhaps you want to change the PARMLIB concatenation after the IPL
>using SETLOAD. I wouldn't want to do it routinely, but it's not my dog.
>
>You might want to reevaluate your parmlib naming conventions
>
>--
>Tom Marchant
I certainly don't want to go through all that trouble. In my old life, each
system (each = 2) had it's own Master catalog, so all systems could point to
a single PARMLIB dataset easily, and each z/OS version had a different Master
Catalog. Here, one Master Catalog is used for all systems (not my favorite
configuration, but that's for another time). Since all systems will use the same
Master Catalog entry, the system symbol is necessary to get different z/OS
levels to use a different SYS1.PARMLIB dataset.
What would make sense to me is to use the SYS1.PARMLIB dataset pointed to
by the PARMLIB statement in LOADxx. If one is specified with a volser, use it.
If somebody wants the extra SYS1.PARMLIB from the catalog they can put a
second statement in with no VOLSER. The way it is now (forcing a
SYS1.PARMLIB dataset resolvable in the Master Catalog without the use of
system symbols), or forcing the use of a second SYS1.PARMLIB dataset just
makes it difficult to have a flexible configuration.
Gibney, Dave
volume. I gave up on system symbols in LOADxx members. I only have a
handful. 4 monoplex LPARs. But, I like the flexibility of several
libraries in the concatenation.
SYS1.WSUMVS1.PARMLIB.ZOS111
SYS1.WSUMVS1.PARMLIB.OVERRIDE
SYS1.WSUMVS1.PARMLIB
SYS1.WSU.PARMLIB
SYS1.IBM.PARMLIB
SYS1.PARMLIB
For LPAR WSUMVS1 at ZOS111
Dennis Trojak
it gets resolved to the correct IPL volume.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Neal Eckhardt
Sent: Friday, October 08, 2010 3:04 PM
To: IBM-...@bama.ua.edu
Subject: Re: Moving SYS1.PARMLIB
Tom Marchant
>
>What would make sense to me is to use the SYS1.PARMLIB dataset pointed to
>by the PARMLIB statement in LOADxx. If one is specified with a volser, use it.
>If somebody wants the extra SYS1.PARMLIB from the catalog they can put a
>second statement in with no VOLSER. The way it is now (forcing a
>SYS1.PARMLIB dataset resolvable in the Master Catalog without the use of
>system symbols), or forcing the use of a second SYS1.PARMLIB dataset just
>makes it difficult to have a flexible configuration.
A cataloged SYS1.PARMLIB has always been required to IPL. For a
long time there was only SYS1.PARMLIB. There were requirements to
allow more flexibility and the PARMLIB concatenation was invented.
There are many ways of doing it, but you are focused on doing it in
a way that is not allowed. Several people have offered suggestions.
Here is another. Change the name of your SYS1.PARMLIB (with the
volume specified) and create an empty SYS1.PARMLIB that is
cataloged in all your master catalogs.
The PARMLIB concatenation provides considerable flexibility. It does,
however, require planning. It also requires an understanding of the
rules to get it right.
The change you are suggesting would break systems that expect the
cataloged SYS1.PARMLIB to be added to the concatenation as
documented.
--
Tom Marchant
Ed Gould
From: Neal Eckhardt <neck...@CNYRIC.ORG>
Subject: Moving SYS1.PARMLIB
To: IBM-...@bama.ua.edu
Date: Friday, October 8, 2010, 7:44 AM
When my old employer went bankrupt and closed down, I was lucky enough to
get a job at a new company (for a lot less money of course). Over the last
few months I have been trying to implement some things that I had done in
the past to make things easier to maintain. One of the things was the ability
to share SYS1.PARMLIB among all of the systems. I have now run into the
same problem that I vaguely remember running into 6 or 7 years ago, and
looking at the datasets that I bought with me, it looks like PARMLIB cannot be
moved off of the IPL volume if you need to use a system symbol to resolve
the VOLSER for SYS1.PARMLIB.
The LOADxx member allows you to specify the volume where SYS1.PARMLIB is
located, but it appears to immediately go to the Master Catalog and stops
when it finds the VOLSER there is a system symbol.
What is the point of allowing a VOLSER in LOADxx if you aren't going to use
that volser until the point in the IPL where the symbols in the catalog (except
******) can be resolved?
----------------SNIp-------------------
Neal:At one place I worked we did something similar. I did not implement it and frankly I never got use to it. Of course the anal retentive people had every member backed up 10 or so times. You know 0 -1 -2 -3 etc etc..The place was just made for finger pointing it was that political.Frankly their meothodolgy was just plain complicated. It was also prone to error as a slight finger check got you into trouble and you got so deep into renaming that in reality there was more finger pointing over that than what the contents were.WHile I guess I could see that *MAYBE* if other groups could update it, in our case nobody could.
An environment that I was used to did it simply and you did not have to keep a long history (current & Previous) was good enough. We had one rule though that a member could not be updated for 1 week and of course the IPL. The backout was simple and nobody had to get involved. We did have an ex systems guy that got promoted over to a new group and security didn't changed his settings and one day he changed parmlib and screwed it up and I had to end up coming in to figure out what had happened. I screamed bloody murder when I found out that his security had not been altered. He got away with it as he was under special orders (long story best left untold). His boss ended up being canned (2 years later) for what was rumored taking a bribe from one of the vendors involved in this. I was happy to see him go.
Ed
Bruce Hewson
column. The VOLSER must start in column 55...if not it would be ignored!
55-60
A optional valid volume name.
If a volume name is specified, IPL processing will attempt to locate the
specified data set on the specified volume.
If '******' or '&SYSR1' is specified, IPL processing will attempt to locate the
specified data set on the system residence volume.
If '*MCAT*' is specified, IPL processing will attempt to locate the specified
data set on the master catalog volume.
If nothing is specified, IPL processing will attempt to locate the specified data
set first in the master catalog and, if it is not located there, on the system
residence volume.
Note:
&SYSR1 is the only system symbol that can be specified in the logical parmlib
concatenation.
On Fri, 8 Oct 2010 13:54:25 -0500, Neal Eckhardt <neck...@CNYRIC.ORG>
wrote:
><SNIP>
>Example 2: The following example shows the definition of a parmlib
>concatenation consisting of MYDSN1.PARMLIB, MYDSN2.PARMLIB,
>SYS1.PARMLIB on volume VOL234, MYDSN3.PARMLIB and, additionally,
>SYS1.PARMLIB, as cataloged in the master catalog, which will be
concatenated
>as the last data set in the parmlib concatenation.
>----+----1----+----2----+----3----+----4----+----5----+----6----+----7-
-
>PARMLIB MYDSN1.PARMLIB
>PARMLIB MYDSN2.PARMLIB VOL123
>PARMLIB SYS1.PARMLIB VOL234
>PARMLIB MYDSN3.PARMLIB VOL456
>
>
<snip>
Regards
Bruce Hewson
Shmuel Metz , Seymour J.
at 07:44 AM, Neal Eckhardt <neck...@CNYRIC.ORG> said:
>What is the point of allowing a VOLSER in LOADxx if you aren't going
>to use that volser until the point in the IPL where the symbols in
>the catalog (except ******) can be resolved?
Why does the sun have stripes? Your question has an assumption
contrary to fact.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
at 08:55 AM, Tom Marchant <m42tom-...@YAHOO.COM> said:
>Why do you want to move SYS1.PARMLIB? SYS1.PARMLIB is one of your
>SMP/E maintained data sets and should not contain anything except
>what is distributed by IBM.
Not when the target library is SYS1.IBM.PARMLIB.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------