IBM Customer number? You would have to manually retrieve from each customer then apply to their records. And customer number may apply to the service provider and not the individual customers they support.
Stock ID on NYSE, AMEX, et? Customer abbreviation of name? On Tue, Jun 4, 2024 at 3:35 PM Matt Hogstrom <m...@hogstrom.org> wrote: > > It’s a good question. Perhaps I was too deep in my own problem. > > z/OS as an instance to me is a sysplex.sysname.smfid which would uniquely > identify that instance. It could be IPL’d on different CECs but its still > the same “instance”. So data is related to that instance of z/OS. > > z/OS does not have that kind of identifiable characteristic apart from the > sysplex.sysname.smfid and even that is a bit fungible because those names are > likely not unique. For instance, if you were a service provider you could > have two different clients with a PLEXA.SMF1.SMF1 which are actually > different instances. > > Consider > > Coke PLEXA.SMF1.SMF1 > Pepsi PLEXA.SMF1.SMF1 > > I’m interested in being able to manage telemetry data from multiple > “instances” in a single database. I can create my own discriminator to > separate them which is where I’m headed. > > Although, rather than assume that this problem is unique to me I thought I’d > ask to see if others have had issues of this nature and how they may have > addressed it. > > > Matt Hogstrom > > > On Jun 4, 2024, at 15:32, Tony Harminc <t...@harminc.net> wrote: > > > > On Tue, 4 Jun 2024 at 12:16, Matt Hogstrom <m...@hogstrom.org> wrote: > > > >> I’m looking for a way to uniquely identify a z/OS instance across multiple > >> clients/customers. I see that z/OSMF has a get UUID but it appears to be > >> for the z/OSMF instance and not for each z/OS. > >> > >> Is anyone aware of a generally accepted way to uniquely identify an > >> instance? > >> > >> I’m asking because when emitting OTel telemetry data its common to have a > >> UUID for an instance but that concept has really been foreign to z/OS > >> > > > > I'm less than clear on what you mean by "instance". Given that you have > > some kind of "instance number", under what circumstances would you expect > > it to change, and when should it stay the same? > > > > Upon IPL? > > > > Upon moving the software unchanged to a different LPAR on the same physical > > machine? > > > > Upon changing the underlying hardware (CPU) but running the same LPAR > > configuration? > > > > Upon restoring the z/OS image from backups and running it at a DR site? > > > > Upon applying maintenance to z/OS? > > > > Upon IPLing under zVM using a different VM userid? > > > > And doubtless several more situations. > > > > If none of the above cases would change your idea of the instance number, > > then you probably want something that relates to the SMP/E or z/OSMF > > database, as I see you're looking at. > > > > If some of them might change it, then one approach to look at is the STSI > > instruction. This is a privileged instruction, but z/OS provides services > > to access to much of the information it returns. There is a complex and > > comprehensive MIB-like data structure returned by STSI, but it relates more > > to the containing environment (LPAR, VM, etc.) rather then what's running > > within. > > > > Perhaps you need both kinds of information. > > > > Tony H. > > > > ---------------------------------------------------------------------- > > 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 -- 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
