What about a JSON output option?
-------- Original message -------- From: "van Sleeuwen, Berry" <[email protected]> Date: 8/4/20 18:04 (GMT+10:00) To: [email protected] Subject: Re: [LINUX-390] VM system name 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&data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7C991fdad0d7724869c05d08d8383b5db1%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637321174909186781&sdata=j1Q%2Ba2kLrzED%2BoxpX%2BGwUVIcJsPNV2OpIOCHxHGg5gU%3D&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 ---------------------------------------------------------------------- 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
