I think the underscore would be required. If the output is processed by some 
script it's easier to select the word. If the underscore is omitted then word 5 
for instance is not always the number of IFLs.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven

-----Original Message-----
From: Linux on 390 Port <[email protected]> On Behalf Of Timothy Sipples
Sent: Tuesday, 4 August 2020 07:57
To: [email protected]
Subject: Re: VM system name

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Would this readout make better sense?

$ zhypinfo
  No    Layer               Type        Name         IFL     CP
  ------------------------------------------------------------------
  2.2   z/VM_Guest          guest       myguest        2      0
  2.1   z/VM_Resource_Pool  pool        pooltest       3      0
  2.0   z/VM                hypervisor  myzvm          8      0
  1     partition           guest       S38LP43       10      0
  0     machine             host        S38           34     10

Then you wouldn't need two columns of numbers. The levels are simply embedded 
in the sequence numbers. Counting would be consistent with the -l and -L 
outputs, of course. Omitting the second column of numbers also frees up more 
space for the text or even another column.

Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they for 
parsing?) Or maybe you don't even need the "guest"/"resource pool"
additions in the Layer column when you've already got a Type column and 
decimalized sequence numbers. And would it make sense to print the hypervisor 
release level in the Layer column, e.g. "z/VM 7.2"?

I don't like unnecessary jargon, so I highly prefer "partition" and "machine." 
I thought about "physical," but sometimes the machine/CEC/CPC isn't physical 
(zPDT, QEMU). Or use "base" if you prefer. But, honestly, we really don't need 
58 questions per month about what a CEC is, which seems inevitable, doesn't it? 
So let's avoid that. And how about a little more insight in the Type column for 
partition and machine?

What happens with SMT2 v. SMT1 in this readout? (Should something happen?)

Putting these suggestions all together except for the SMT2 one, plus some 
others, here's what you might end up with:

$ zhypinfo
  #     Layer             Type          Name        IFLs    CPs
  ----------------------------------------------------------------
  2.2   Linux 4.18        guest         myguest        2      0
  2.1   z/VM 7.2          pool          pooltest       3      0
  2.0   z/VM 7.2          hypervisor    myzvm          8      0
  1     partition         z/VM          S38LP43       10      0
  0     machine           z14           S38           34     10

I like "#" a little better as a column label (or maybe "Seq."), and I've 
pluralized IFL and CP.

"Fun" question: what should a z/OS Container Extensions readout look like?

If the machine is reporting back something beyond the known model generations, 
then you could print ">z15" or "z15+" or "z16?" until zhypinfo is updated. When 
zhypinfo is updated you then insert the model generation without the question 
mark and update the question mark to be "z17?" (for example). Loop, repeat.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: [email protected]

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO LINUX-390 or visit
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&amp;data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7C991fdad0d7724869c05d08d8383b5db1%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637321174909186781&amp;sdata=j1Q%2Ba2kLrzED%2BoxpX%2BGwUVIcJsPNV2OpIOCHxHGg5gU%3D&amp;reserved=0

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to