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 [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Art Gutowski > Sent: Wednesday, February 3, 2016 01:08 PM > To: [email protected] > Subject: [Bulk] Re: Manipulating system symbols > > On Sun, 31 Jan 2016 08:50:43 -0800, Skip Robinson > <[email protected]> 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- > [email protected]] > >> On Behalf Of Bruce Hewson > >> Sent: Saturday, January 30, 2016 09:43 PM > >> To: [email protected] > >> 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...<emphasis>once we > knew what to look for</emphasis>. > > It vexes me that the default is SYSSYM(YES). I was at a shop that used > &OSLEVEL. 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 [email protected] with the message: INFO IBM-MAIN
