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