Re: Manipulating system symbols

[Skip Robinson]

My suggestion for using the SHARE code as prefix goes back to the 1980s when
IBM made a similar recommendation for the (then new) mainframe networking
function (MSNF?) that provided for world-wide peer-to-peer connections. The
idea was to establish a naming convention that, if everyone followed it,
would keep all the disparate critters in their own cages. SHARE members have
always been guaranteed a unique two- or three-character installation code.
Non-members of course are on their own. As non-members so often are. ;-)

As for the practicality of living with only five 'meaningful' characters in
an eight-character name, we have since the 90s maintained a stable of over
60 installation defined system symbols. Amazing how much significance you
can pack into one character if you plan carefully. These symbols needless to
say are not 'self-documenting'. ;-) 

An expanded name is certainly welcome, but one poster pointed out,
conversion is more or less painful. 

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Relson
> Sent: Tuesday, February 16, 2016 06:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> As with a huge number of things, the best thing for any "owner" is to use
a 3-
> character prefix that they own. This is necessary for avoiding conflicts,
> whether in part names, messages, name/token names, data space names,
> ENQ qnames/rnames, etc.
> 
> I'm not sure how a customer's Share installation code fits into that
scheme.
> We probably all have heard of the general situation that IBM "owns" names
> beginning A through I and SYS. There are some exceptions (mostly due to
> "grandfathering").
> 
> Going forward, any future IBM-created system symbol(s) would begin with
SYS
> (at least as long as I'm involved), unless (perhaps) the symbol is created
> conditionally under control of some (non-default) customer-specified
option.
> 
> For example, if we ever make the LPAR name into a system symbol, it won't
be
> 
> 
> Peter Relson
> z/OS Core Technology Design

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

Re: Manipulating system symbols

[Peter Relson]

As with a huge number of things, the best thing for any "owner" is to use 
a 3-character prefix that they own. This is necessary for avoiding 
conflicts, whether in part names, messages, name/token names, data space 
names, ENQ qnames/rnames, etc.

I'm not sure how a customer's Share installation code fits into that 
scheme. We probably all have heard of the general situation that IBM 
"owns" names beginning A through I and SYS. There are some exceptions 
(mostly due to "grandfathering").

Going forward, any future IBM-created system symbol(s) would begin with 
SYS (at least as long as I'm involved), unless (perhaps) the symbol is 
created conditionally under control of some (non-default) 
customer-specified option.

For example, if we ever make the LPAR name into a system symbol, it won't 
be 

Peter Relson
z/OS Core Technology Design


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

Re: Manipulating system symbols

[Mike Schwab]

I would suggest they use the 3 character message prefix.

On Mon, Feb 15, 2016 at 10:08 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 15 Feb 2016 03:33:36 -0600, Art Gutowski wrote:

 Please note that with z/OS 2.2 the length of system symbols names has
 increased from 8 to 16, and may include the underscore character.

 -Original Message-
 On Behalf Of Paul Gilmartin
 Sent: Thursday, 4 February 2016 12:03 PM
 >
 The namespace is too small in this 21st century.
>>
>>I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
>>names, as they do for SYSMOD IDs, that are off-limits, or 
>>use-at-your-own-risk.  They can further set up a registry, as they do for 
>>module names, and while this registry is voluntary, we can certainly 
>>encourage vendors to participate.
>>
> Such a registry shouldn't be the province of any single supplier; it should be
> global.  The prefix an ISV uses for z/OS should likewise apply to Linux,
> OS X, Windows, ...  There's a nascent convention of using a registered domain
> name, wrtten big-endian, as a qualifier, such as com.gm or edu.ua.listserv.
> That convention should be embraced more widely.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Manipulating system symbols

[Paul Gilmartin]

On Mon, 15 Feb 2016 03:33:36 -0600, Art Gutowski wrote:
>>> 
>>> Please note that with z/OS 2.2 the length of system symbols names has
>>> increased from 8 to 16, and may include the underscore character.
>>> 
>>> -Original Message-
>>> On Behalf Of Paul Gilmartin
>>> Sent: Thursday, 4 February 2016 12:03 PM
>>> >
>>> The namespace is too small in this 21st century.
>
>I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
>names, as they do for SYSMOD IDs, that are off-limits, or 
>use-at-your-own-risk.  They can further set up a registry, as they do for 
>module names, and while this registry is voluntary, we can certainly encourage 
>vendors to participate.
>
Such a registry shouldn't be the province of any single supplier; it should be
global.  The prefix an ISV uses for z/OS should likewise apply to Linux,
OS X, Windows, ...  There's a nascent convention of using a registered domain
name, wrtten big-endian, as a qualifier, such as com.gm or edu.ua.listserv.
That convention should be embraced more widely.

-- gil

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

Re: Manipulating system symbols

[Art Gutowski]

On Wed, 3 Feb 2016 19:53:48 -0800, Skip Robinson  
wrote:

>Sweet. Did not pick up on that. All the more reason to prefix symbols with a 
>unique string. 
>
>> -Original Message-
>> On Behalf Of Anthony Thompson
>> Sent: Wednesday, February 3, 2016 07:48 PM
>> 
>> Please note that with z/OS 2.2 the length of system symbols names has
>> increased from 8 to 16, and may include the underscore character.
>> 
>> Ant.
>> 
>> -Original Message-
>> On Behalf Of Paul Gilmartin
>> Sent: Thursday, 4 February 2016 12:03 PM
>> 
>> On 2016-02-03 19:27, Skip Robinson wrote:
>> > This is why I strongly recommend that installation-defined symbols be
>> prefixed with a unique string, which I also recommend be the SHARE
>> installation code. It reduces the number of meaningful character to 5 or 6 
>> but
>> pretty much rules out stepping on toes. Debugging problems caused by
>> symbol 'overlays' could be excruciating.
>> >
>> The namespace is too small in this 21st century.
>> 
>> -- gil

In the meantime, we still have the 8-character limitation.  And whether we try 
to convert existing symbols to use a site prefix now or wait until we have 16 
characters available, that's no small feat.  Naming conventions of any kind, 
once they take hold, are time-consuming to change.  What if the installation is 
not a SHARE member?

We already use meaningful (to us) prefixes to make symbols intuitive to us 
without stepping on IBM symbols, let alone other vendors.  Further, in the case 
I pointed out previously, the vendor decided to use symbol names that conflict 
with IBM filter criterion, and could conflict with IBM symbols.  We have no 
control over such situations.  

Even if they don't conflict, should the installation be JES3, the changes won't 
get picked up, unless the product is issuing a *S ,CONNECT under the 
covers...more shenanigans.  I understand that with the advent of SETLOAD 
IEASYM, this has changed a little, but at z/OS 1.13, the vendor clearly is not 
using this facility to effect the change.

I stand by my earlier statement, no supplier should be dynmically inserting 
symbols into the table without express consent of the installation.  In other 
words, there should be a configuration switch for which the default setting 
should be OFF.  Better to document any symbols and have the customer define 
them explicitly at IPL via IEASYMxx.

I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
names, as they do for SYSMOD IDs, that are off-limits, or use-at-your-own-risk. 
 They can further set up a registry, as they do for module names, and while 
this registry is voluntary, we can certainly encourage vendors to participate.

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

Re: Manipulating system symbols

[Art Gutowski]

On Sun, 31 Jan 2016 08:50:43 -0800, Skip Robinson <jo.skip.robin...@att.net> 
wrote:

>We run several CA products, which means CA90S (name?) early in IPL. I don't 
>know CAMASTER, but on a running system I can find no evidence of the symbols 
>you name. I'm not sure that the point of CA initialization would be early 
>enough for our needs.
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Bruce Hewson
>> Sent: Saturday, January 30, 2016 09:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: Manipulating system symbols
>> 
>> one point, if you are running CA products, these days some extra symbols get
>> populated by CA code - one of which is LPARNAME.
>> 
>> at CAMASTER initialization these symbols get added.
>> 
>> VMUSER
>> LPARNAME
>> HRDWNAME
>> SMFID
>> OSLEVEL
>> 
>> been this way at least since 2013

Probably not, Skip.  It sounds like you need these symbols to determine other 
PARMLIB members and parameter values. CAMaster comes up during subsystem 
initialization...much too late.

We noticed CAMaster with our latest Common Services upgrades...either 14.0 or 
14.1...and the symbols Bruce describes do exist.  We came from 12.0, but now we 
see CAMaster is active on our sole 12.0 instance, but the symbols in question 
do not exist.  Looks like this started with 14.0?

I'm glad to see that this is conspicously documented...once we knew 
what to look for.  

It vexes me that the default is SYSSYM(YES).  I was at a shop that used 
 for its own purposes, and I can imagine the level of havoc wrought if 
CAMASTER changed the value of this symbol (the way the documentation is worded, 
I gather if left to default, this is the result).  Compound that with the 
complications of propagating symbol table updates in a JES3 MAS, and you've got 
a migraine brewing.  Thankfully, we don't have any of these symbols in use here 
(yet).

Bottom line:  not a big fan, and we will probably set up CAIMST00 with 
SYSSYM(NO) asap.  Who knows what new symbols will be added in 14.next.  I would 
rather see the symbols required (tho this seems a strong word in this case) by 
the product and let systems programmers define and document them to our 
standards in the symbol table.  We can then identify and resolve potential 
conflicts.  I don't like surprises, and this was a surprise to a couple of us 
here.

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

Re: Manipulating system symbols

[Anthony Thompson]

Please note that with z/OS 2.2 the length of system symbols names has increased 
from 8 to 16, and may include the underscore character.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, 4 February 2016 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Manipulating system symbols

On 2016-02-03 19:27, Skip Robinson wrote:
> This is why I strongly recommend that installation-defined symbols be 
> prefixed with a unique string, which I also recommend be the SHARE 
> installation code. It reduces the number of meaningful character to 5 or 6 
> but pretty much rules out stepping on toes. Debugging problems caused by 
> symbol 'overlays' could be excruciating. 
>  
The namespace is too small in this 21st century.

-- gil

--
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: Manipulating system symbols

[Skip Robinson]

Sweet. Did not pick up on that. All the more reason to prefix symbols with a 
unique string. 

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Anthony Thompson
> Sent: Wednesday, February 3, 2016 07:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> Please note that with z/OS 2.2 the length of system symbols names has
> increased from 8 to 16, and may include the underscore character.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Thursday, 4 February 2016 12:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Manipulating system symbols
> 
> On 2016-02-03 19:27, Skip Robinson wrote:
> > This is why I strongly recommend that installation-defined symbols be
> prefixed with a unique string, which I also recommend be the SHARE
> installation code. It reduces the number of meaningful character to 5 or 6 but
> pretty much rules out stepping on toes. Debugging problems caused by
> symbol 'overlays' could be excruciating.
> >
> The namespace is too small in this 21st century.
> 
> -- gil

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

Re: Manipulating system symbols

[Paul Gilmartin]

On 2016-02-03 19:27, Skip Robinson wrote:
> This is why I strongly recommend that installation-defined symbols be 
> prefixed with a unique string, which I also recommend be the SHARE 
> installation code. It reduces the number of meaningful character to 5 or 6 
> but pretty much rules out stepping on toes. Debugging problems caused by 
> symbol 'overlays' could be excruciating. 
>  
The namespace is too small in this 21st century.

-- gil

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

Re: Manipulating system symbols

[Skip Robinson]

This is why I strongly recommend that installation-defined symbols be prefixed 
with a unique string, which I also recommend be the SHARE installation code. It 
reduces the number of meaningful character to 5 or 6 but pretty much rules out 
stepping on toes. Debugging problems caused by symbol 'overlays' could be 
excruciating. 

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

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Art Gutowski
> Sent: Wednesday, February 3, 2016 01:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> On Sun, 31 Jan 2016 08:50:43 -0800, Skip Robinson
> <jo.skip.robin...@att.net> wrote:
> 
> >We run several CA products, which means CA90S (name?) early in IPL. I don't
> know CAMASTER, but on a running system I can find no evidence of the
> symbols you name. I'm not sure that the point of CA initialization would be
> early enough for our needs.
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of Bruce Hewson
> >> Sent: Saturday, January 30, 2016 09:43 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: [Bulk] Re: Manipulating system symbols
> >>
> >> one point, if you are running CA products, these days some extra
> >> symbols get populated by CA code - one of which is LPARNAME.
> >>
> >> at CAMASTER initialization these symbols get added.
> >>
> >> VMUSER
> >> LPARNAME
> >> HRDWNAME
> >> SMFID
> >> OSLEVEL
> >>
> >> been this way at least since 2013
> 
> Probably not, Skip.  It sounds like you need these symbols to determine other
> PARMLIB members and parameter values. CAMaster comes up during
> subsystem initialization...much too late.
> 
> We noticed CAMaster with our latest Common Services upgrades...either 14.0
> or 14.1...and the symbols Bruce describes do exist.  We came from 12.0, but
> now we see CAMaster is active on our sole 12.0 instance, but the symbols in
> question do not exist.  Looks like this started with 14.0?
> 
> I'm glad to see that this is conspicously documented...once we
> knew what to look for.
> 
> It vexes me that the default is SYSSYM(YES).  I was at a shop that used
>  for its own purposes, and I can imagine the level of havoc wrought
> if CAMASTER changed the value of this symbol (the way the documentation is
> worded, I gather if left to default, this is the result).  Compound that with 
> the
> complications of propagating symbol table updates in a JES3 MAS, and you've
> got a migraine brewing.  Thankfully, we don't have any of these symbols in use
> here (yet).
> 
> Bottom line:  not a big fan, and we will probably set up CAIMST00 with
> SYSSYM(NO) asap.  Who knows what new symbols will be added in 14.next.  I
> would rather see the symbols required (tho this seems a strong word in this
> case) by the product and let systems programmers define and document them
> to our standards in the symbol table.  We can then identify and resolve
> potential conflicts.  I don't like surprises, and this was a surprise to a 
> couple of
> us here.
> 
> 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

Re: Manipulating system symbols

[Paul Gilmartin]

On Wed, 3 Feb 2016 19:53:48 -0800, Skip Robinson wrote:

>Sweet. Did not pick up on that. All the more reason to prefix symbols with a 
>unique string. 
> 
Will they be accessible in JCL?

Expanding the name space is apt to break existing art.

>> -Original Message-
>> From: Anthony Thompson
>> Sent: Wednesday, February 3, 2016 07:48 PM
>> 
>> Please note that with z/OS 2.2 the length of system symbols names has
>> increased from 8 to 16, and may include the underscore character.

-- gil

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

Re: Manipulating system symbols

[Skip Robinson]

We run several CA products, which means CA90S (name?) early in IPL. I don't 
know CAMASTER, but on a running system I can find no evidence of the symbols 
you name. I'm not sure that the point of CA initialization would be early 
enough for our needs.

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

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bruce Hewson
> Sent: Saturday, January 30, 2016 09:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> one point, if you are running CA products, these days some extra symbols get
> populated by CA code - one of which is LPARNAME.
> 
> at CAMASTER initialization these symbols get added.
> 
> VMUSER
> LPARNAME
> HRDWNAME
> SMFID
> OSLEVEL
> 
> 
> been this way at least since 2013
> 
> Regards
> Bruce Hewson

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

Re: Manipulating system symbols

[Skip Robinson]

Alas, all sysres packs all have the same name. Either mirrored for remote DR or 
the same physical volumes for local DR. Different Load Profile names on the HMC 
for a small measure of sanity, but same VOLSERs. So we're in the same 
(life)boat as you. 

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jerry Whitteridge
> Sent: Saturday, January 30, 2016 11:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> Can you derive the value from your IPL Packs ? Something like:
> 
> SYSDEF SYMDEF(='(1:5).1')
>  SYSDEF SYMDEF(='(1:5).2')
>  SYSDEF SYMDEF(='(1:5).1')
>  SYSDEF SYMDEF(='(1:5).2')
> 
> 
> Otherwise we have been forced to keep multiple sets of SYSDEF based on the
> LPARNAME like :
> 
> SYSDEF LPARNAME(SY01) SYSCLONE(T1)
>LPARNAME(SY01) SYMDEF(='CCA4')
>LPARNAME(SY01) SYMDEF(='CCA5')
>LPARNAME(SY01) SYMDEF(='CCA6')
> 
> And yes - When building new LPARS we have to ensure all the new Symbolics
> are setup
> 
> 
> 
> 
> 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: Saturday, January 30, 2016 11:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Manipulating system symbols
> 
> I have LPAR-derived symbols--all set via the same clumsy tests I showed
> earlier. I created that schema 20 years ago and would like to simplify and
> sleeken (is that a word?) it. Here's why I need the function.
> 
> I run system SYSKIP on three different CECs for business reasons. The
> underlying LPAR names are different based on CEC--LPSKIP1, LPSKIP2, and
> LPSKIP3. All three systems are internally  SYSKIP and look nearly
> identical as necessary for 99% of user function. But some resources like 
> TCP/IP
> and VTAM values need to be unique because I cannot have duplicates in the
> network. I would like to be able to set symbols like  and 
> by simply extracting SKIP1/SKIP2/SKIP3 from the LPAR name. Unfortunately
> the 'variable' LPARNAME provided for filtering is not actually a system symbol
> and cannot parsed into substrings.
> 
> This would be so easy in even a rudimentary programming language. I've
> considered doing it in a Rexx that would set symbols via the new z/OS V2
> mechanism, but all this needs to happen very early in a serialized, primal 
> state
> such as IEASYMxx before anything else kicks off. For the record, the LPARs on
> the various CECs are used for production or some flavor of disaster recovery.
> That's why each system needs to 'look the same' in each LPAR.
> .
> .
> 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
> 
> 
> > -----Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Steve Horein
> > Sent: Saturday, January 30, 2016 10:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [Bulk] Re: Manipulating system symbols
> >
> > Are your LPARs related to other things such that you could then take
> > advantage of Symbol substring?
> > http://www-
> >
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae2
> > 00/usesubs.htm
> >
> >
> > On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson
> > <jo.skip.robin...@att.net>
> > wrote:
> >
> > > For the first time in ages we are in the process of enhancing our
> > > inventory of user defined system symbols (IEASYMxx). I jumped out
> > > half-cocked and attempted to set a symbol equal to the name of the
> > > current LPAR. That sounds easy, but I cannot find an simple way to
> > > do it. Even pored over the V2R1 doc, which looks much as I remember
> > > it from 1995.
> > >
> > >
> > >
> > > There are three names that can be used in SYSDEF statements: HWNAME,
> > > LPARNAME, and VMUSERID. However, these are available only for
> 'filtering'.
> > > That is, I can do something like
> > >
> > >
> > >
> > > SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */

Re: Manipulating system symbols

[Skip Robinson]

I have LPAR-derived symbols--all set via the same clumsy tests I showed 
earlier. I created that schema 20 years ago and would like to simplify and 
sleeken (is that a word?) it. Here's why I need the function.

I run system SYSKIP on three different CECs for business reasons. The 
underlying LPAR names are different based on CEC--LPSKIP1, LPSKIP2, and 
LPSKIP3. All three systems are internally  SYSKIP and look nearly 
identical as necessary for 99% of user function. But some resources like TCP/IP 
and VTAM values need to be unique because I cannot have duplicates in the 
network. I would like to be able to set symbols like  and  by 
simply extracting SKIP1/SKIP2/SKIP3 from the LPAR name. Unfortunately the 
'variable' LPARNAME provided for filtering is not actually a system symbol and 
cannot parsed into substrings. 

This would be so easy in even a rudimentary programming language. I've 
considered doing it in a Rexx that would set symbols via the new z/OS V2 
mechanism, but all this needs to happen very early in a serialized, primal 
state such as IEASYMxx before anything else kicks off. For the record, the 
LPARs on the various CECs are used for production or some flavor of disaster 
recovery. That's why each system needs to 'look the same' in each LPAR. 
.
.
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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Horein
> Sent: Saturday, January 30, 2016 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> Are your LPARs related to other things such that you could then take
> advantage of Symbol substring?
> http://www-
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae2
> 00/usesubs.htm
> 
> 
> On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson <jo.skip.robin...@att.net>
> wrote:
> 
> > For the first time in ages we are in the process of enhancing our
> > inventory of user defined system symbols (IEASYMxx). I jumped out
> > half-cocked and attempted to set a symbol equal to the name of the
> > current LPAR. That sounds easy, but I cannot find an simple way to do
> > it. Even pored over the V2R1 doc, which looks much as I remember it
> > from 1995.
> >
> >
> >
> > There are three names that can be used in SYSDEF statements: HWNAME,
> > LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
> > That is, I can do something like
> >
> >
> >
> > SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
> >
> >   SYMDEF(='LPARSKIP')   /* Then set user symbol to this */
> >
> >
> >
> > The problem is that I have to have a separate pair of statements for
> > every LPAR in the Enterprise. If a new LPAR gets created, I have to
> > clone a new pair of statements.
> >
> >
> >
> > What I would like is to be able to set  directly to the name
> > of the current LPAR whatever it is. One statement that would serve
> > everywhere and never need cloning. Am I missing something obvious?
> >
> >

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

Re: Manipulating system symbols

[Jerry Whitteridge]

Can you derive the value from your IPL Packs ? Something like:

SYSDEF SYMDEF(='(1:5).1')
 SYSDEF SYMDEF(='(1:5).2')
 SYSDEF SYMDEF(='(1:5).1')
 SYSDEF SYMDEF(='(1:5).2')


Otherwise we have been forced to keep multiple sets of SYSDEF based on the 
LPARNAME like :

SYSDEF LPARNAME(SY01) SYSCLONE(T1)
   LPARNAME(SY01) SYMDEF(='CCA4')
   LPARNAME(SY01) SYMDEF(='CCA5')
   LPARNAME(SY01) SYMDEF(='CCA6')

And yes - When building new LPARS we have to ensure all the new Symbolics are 
setup




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: Saturday, January 30, 2016 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Manipulating system symbols

I have LPAR-derived symbols--all set via the same clumsy tests I showed 
earlier. I created that schema 20 years ago and would like to simplify and 
sleeken (is that a word?) it. Here's why I need the function.

I run system SYSKIP on three different CECs for business reasons. The 
underlying LPAR names are different based on CEC--LPSKIP1, LPSKIP2, and 
LPSKIP3. All three systems are internally  SYSKIP and look nearly 
identical as necessary for 99% of user function. But some resources like TCP/IP 
and VTAM values need to be unique because I cannot have duplicates in the 
network. I would like to be able to set symbols like  and  by 
simply extracting SKIP1/SKIP2/SKIP3 from the LPAR name. Unfortunately the 
'variable' LPARNAME provided for filtering is not actually a system symbol and 
cannot parsed into substrings.

This would be so easy in even a rudimentary programming language. I've 
considered doing it in a Rexx that would set symbols via the new z/OS V2 
mechanism, but all this needs to happen very early in a serialized, primal 
state such as IEASYMxx before anything else kicks off. For the record, the 
LPARs on the various CECs are used for production or some flavor of disaster 
recovery. That's why each system needs to 'look the same' in each LPAR.
.
.
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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Horein
> Sent: Saturday, January 30, 2016 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
>
> Are your LPARs related to other things such that you could then take
> advantage of Symbol substring?
> http://www-
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae2
> 00/usesubs.htm
>
>
> On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson <jo.skip.robin...@att.net>
> wrote:
>
> > For the first time in ages we are in the process of enhancing our
> > inventory of user defined system symbols (IEASYMxx). I jumped out
> > half-cocked and attempted to set a symbol equal to the name of the
> > current LPAR. That sounds easy, but I cannot find an simple way to do
> > it. Even pored over the V2R1 doc, which looks much as I remember it
> > from 1995.
> >
> >
> >
> > There are three names that can be used in SYSDEF statements: HWNAME,
> > LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
> > That is, I can do something like
> >
> >
> >
> > SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
> >
> >   SYMDEF(='LPARSKIP')   /* Then set user symbol to this */
> >
> >
> >
> > The problem is that I have to have a separate pair of statements for
> > every LPAR in the Enterprise. If a new LPAR gets created, I have to
> > clone a new pair of statements.
> >
> >
> >
> > What I would like is to be able to set  directly to the name
> > of the current LPAR whatever it is. One statement that would serve
> > everywhere and never need cloning. Am I missing something obvious?
> >
> >

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

Re: Manipulating system symbols

[Steve Horein]

Are your LPARs related to other things such that you could then take
advantage of Symbol substring?
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/usesubs.htm


On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson 
wrote:

> For the first time in ages we are in the process of enhancing our inventory
> of user defined system symbols (IEASYMxx). I jumped out half-cocked and
> attempted to set a symbol equal to the name of the current LPAR. That
> sounds
> easy, but I cannot find an simple way to do it. Even pored over the V2R1
> doc, which looks much as I remember it from 1995.
>
>
>
> There are three names that can be used in SYSDEF statements: HWNAME,
> LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
> That is, I can do something like
>
>
>
> SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
>
>   SYMDEF(='LPARSKIP')   /* Then set user symbol to this */
>
>
>
> The problem is that I have to have a separate pair of statements for every
> LPAR in the Enterprise. If a new LPAR gets created, I have to clone a new
> pair of statements.
>
>
>
> What I would like is to be able to set  directly to the name of
> the
> current LPAR whatever it is. One statement that would serve everywhere and
> never need cloning. Am I missing something obvious?
>
>
>
>
>
>
>
> .
>
> .
>
> .
>
> 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
>
>
>
>
> --
> 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: Manipulating system symbols

[Bruce Hewson]

one point, if you are running CA products, these days some extra symbols get 
populated by CA code - one of which is LPARNAME.

at CAMASTER initialization these symbols get added.

VMUSER
LPARNAME
HRDWNAME
SMFID
OSLEVEL


been this way at least since 2013

Regards
Bruce Hewson

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