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
