Re: Hillgang reminder
On Thu, Mar 25, 2010 at 7:47 PM, Daniel P. Martin wrote: > See, kids, this is what happens when you try to handle correspondence > under the influence of cold medicine... > > "Nothing going on in here. Please move along." > > *sigh* > I was going to say, "FSVO 'directly'".
Re: Hillgang reminder
See, kids, this is what happens when you try to handle correspondence under the influence of cold medicine... "Nothing going on in here. Please move along." *sigh* -dan. On 3/25/2010 6:46 PM, Daniel P. Martin wrote: Neale: I received the following on the IBMVM moderator in-box. Rather than pass to the list, I've opted to pass to you directly... -dan. On 3/24/2010 12:52 PM, Neale Ferguson wrote: A gentle reminder that the next meeting of Hillgang will take place on Friday 26 March, in Herndon Virginia at the CA office. The meeting¹s agenda and directions are found athttp://www.vm.ibm.com/events/hill0326.pdf. Hello, I was hoping to be added to the attendee list for this Friday's Hillgang meeting in Herndon. My contact information is listed below in my email signature. Please let me know if you require further information to process this request. Regards, Mark... Mark Lint Senior IT Specialist IBM Tivoli Software Group - Performance Automation 6755 Gray Post Court Centreville, VA 20121 Work:703-449-1477 Mobile:703-395-5688 Fax: 845-463-6330 ml...@us.ibm.com - Forwarded by Mark Lint/Bethesda/IBM on 03/25/2010 06:29 AM - |> | From: | |> >--| |Mac Holloway/Raleigh/IBM | >--| |> | To:| |> >--| |Mark Lint/Bethesda/i...@ibmus | >--| |> | Date: | |> >--| |03/24/2010 10:33 PM | >--| |> | Subject: | |> >--| |Fw: Hillgang reminder | >--| FYI I believe if you mailib...@listserv.uark.edu about attending the Hill Gang meeting you will get registered. Mac Holloway OMEGAMON for z/VM OMEGAMON for Mainframe Networks mholl...@us.ibm.com 919-224-1855 T/L 687-1855 - Forwarded by Mac Holloway/Raleigh/IBM on 03/24/2010 10:32 PM - |> | From: | |> >--| |Neale Ferguson | >--| |> | To:| |> >--| |IBMVM@LISTSERV.UARK.EDU | >--| |> | Date: | |> >--| |03/24/2010 01:55 PM | >--| |> | Subject
Re: Hillgang reminder
Neale: I received the following on the IBMVM moderator in-box. Rather than pass to the list, I've opted to pass to you directly... -dan. On 3/24/2010 12:52 PM, Neale Ferguson wrote: A gentle reminder that the next meeting of Hillgang will take place on Friday 26 March, in Herndon Virginia at the CA office. The meeting¹s agenda and directions are found at http://www.vm.ibm.com/events/hill0326.pdf. Hello, I was hoping to be added to the attendee list for this Friday's Hillgang meeting in Herndon. My contact information is listed below in my email signature. Please let me know if you require further information to process this request. Regards, Mark... Mark Lint Senior IT Specialist IBM Tivoli Software Group - Performance Automation 6755 Gray Post Court Centreville, VA 20121 Work:703-449-1477 Mobile:703-395-5688 Fax: 845-463-6330 ml...@us.ibm.com - Forwarded by Mark Lint/Bethesda/IBM on 03/25/2010 06:29 AM - |> | From: | |> >--| |Mac Holloway/Raleigh/IBM | >--| |> | To:| |> >--| |Mark Lint/Bethesda/i...@ibmus | >--| |> | Date: | |> >--| |03/24/2010 10:33 PM | >--| |> | Subject: | |> >--| |Fw: Hillgang reminder | >--| FYI I believe if you mailib...@listserv.uark.edu about attending the Hill Gang meeting you will get registered. Mac Holloway OMEGAMON for z/VM OMEGAMON for Mainframe Networks mholl...@us.ibm.com 919-224-1855 T/L 687-1855 - Forwarded by Mac Holloway/Raleigh/IBM on 03/24/2010 10:32 PM - |> | From: | |> >--| |Neale Ferguson | >--| |> | To:| |> >--| |IBMVM@LISTSERV.UARK.EDU | >--| |> | Date: | |> >--| |03/24/2010 01:55 PM | >--| |> | Subject: | |> >--| |Hillgang reminder
Re: initializing z/Linux disks
On Thursday, 03/25/2010 at 11:45 EDT, RPN01 wrote: > Another point I?ve not seen mentioned, and I?m not sure if it?s true or not... > > Given a dedicated volume to a Linux guest, won?t the guest start only one I/O > to the device at a time, and wait for it to complete? If you break up a larger > volume into several minidisks (like a mod 27 into mod 9?s) aren?t you allowing > the z/VM multipathing to do its job more efficiently, even if you give all the > smaller volumes to the same Linux guest? > > Like I said, I may be totally off base, but this is the impression I?ve had... Yes, PAV support allows CP to do (in your example) multiple to the same volume, but there will still be only one I/O per minidisk. (HyperPAVs work only on full-pack minidisks.) Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
On Thursday, 03/25/2010 at 12:11 EDT, "Schuh, Richard" wrote: > With it not being a full-pack as Mike mentioned in his post, there would always > have to be CCW translation, would there not? The question is whether that is a > significant hit compared to the full pack including Cyl 0. Considering that, in > the olden days, CP overhead was quite high compared to today, the performance > hit, while there, might not be sufficient to be a cause of concern. Mike said "minidisk rather than a dedicated full disk." Since the context of prior posts was full-pack minidisks (FPMD), I applied the same qualifier to Mike's use of "minidisk". I'm not going to try to compare the CCW translation costs of a non-FPMD to a dedicated device other than to say that it's slower as there's more to do. CCW translation is the same for FPMD as for a dedicated device. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
There is maybe some misunderstanding: (leaving out PAV a while) a device can handle only 1 IO at a time, guests know that, CP too. So indeed a linux will not send a new IO if the previous one to that disk hasn't ended yet, the guets will queue it. With several guests with minidisks on the same disk, CP will queue the requests. Multipathing doesn't change that. Multipathing helps in cases where the device is not busy, but the channel or control unit is. PAV simplified: with PAV, you make appear a single disk as if it were many disks, but for each PAV address the old rule is still valid: one IO at a time. If you guest is PAV aware, it can also avoid queuing, if not, putting many guests on the same volume and let CP exploit PAV can improve IO rates. 2010/3/25 RPN01 > Another point I’ve not seen mentioned, and I’m not sure if it’s true or > not... > > Given a dedicated volume to a Linux guest, won’t the guest start only one > I/O to the device at a time, and wait for it to complete? If you break up a > larger volume into several minidisks (like a mod 27 into mod 9’s) aren’t you > allowing the z/VM multipathing to do its job more efficiently, even if you > give all the smaller volumes to the same Linux guest? > > Like I said, I may be totally off base, but this is the impression I’ve > had... > > -- > Robert P. Nix Mayo Foundation.~. > RO-OE-5-55 200 First Street SW/V\ > 507-284-0844 Rochester, MN 55905 /( )\ > -^^-^^ > "In theory, theory and practice are the same, but > in practice, theory and practice are different." > > > > On 3/24/10 2:38 PM, "Scott Rohling" wrote: > > I would not recommend using DEDICATE -- why would you do that rather than > use minidisks? What you need to be aware of is that if you DEDICATE -- > Linux will label the DASD -- and that's what you'll see at the z/VM level -- > and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, > etc...).Also - if you dedicate - you can't use things like DIRMAINT do > manage your dasd and keep things in pools, etc -- you have to manage it all > yourself. > > On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) < > terry.mar...@cms.hhs.gov> wrote: > > Hi > > I have a question. What I have been doing up to this point for a new > z/Linux guest build is, not necessarily in this order and does not > necessarily include all steps but, > > Crave out the DASD for the z/Linux guest > > Init the DASD using CPFMTXA putting a label on the disk > > Setting up the Directory entry for the new guest, which includes specifying > the MDISK for all of the DASD for the guest. > > We back up our z/Linux guests on the z/OS side with DFDSS. > > My question is since when we Kick Start the new z/Linux guest and it > initializes the DASD during this process is there any compelling reason for > me to initialize the DASD up front before the guest is Kick Started for the > first time basically doing a double INIT? > > If not I assume then I would replace the MDISK statements in the Directory > entry with DEDICATE statements for each one of the DISKS. We do not share > DASD between guests here so what is defined to the guest belongs to that > guest only. Is there anything to be aware of by changing to DEDICATE > statements from MDISK statements? > > My only concern is with the DFDSS backups that I do on the z/OS for the > guests. I am not sure if it matters or not to DFDSS whether the pack was > initialized via CPFMTXA or z/Linux during the kick start process? > > > *Thank You, > > Terry Martin > Lockheed Martin - Citic > z/OS and z/VM Performance Tuning and Operating Systems Support > Office - 443 348-2102 > Cell - 443 632-4191 > > * > > > > -- Kris Buelens, IBM Belgium, VM customer support
Re: OSA/SF Problem
One needs to understand the syntax of a COMDIR entry. In this case, the syntax is: : nick.IOASERVR: :Luname.*USERID OSASF : tpn.IOASERV means: if a program want to create an APPC connection with "resource" IOASERVR, CP will not use AVS, nor will it look for an existing, started, server that declared itself as "IOASERVR", but it will XAUTOLOG user OSASF (not it is not logged on yet and present the APPC request to it. OSASF will then look in $SERVER$ NAMES to see who is authorized to use "transaction program name" IOASERV, and what program it must start if the authorisation is OK. So, you do indeed need a user named OSASF, but not a user named IOASERV. To use the right VM terms: "IOASERVR" is a *private resource *as opposed to more general resources like SFS (VMSYS, VMSYSU, xxx). 2010/3/23 Mario Izaguirre > > > Hi..all: > > > > We have seen that there is a file called NAMES UCOMDIR and giving it the > look that PEEK: > > : nick.IOASERVR: OSASF USERID .* >: tpn.IOASERV > > OSASF is a missing users and user IOASERV too, users only had OSADMIN1, > OSADMIN2 et .. etc. .. > > We made this way and we have OSAFS logoff users and OSADMIN1, then we tried > again to reconfigure the OSA/SF and we always had the same error with the > discs 70xx, someone has told my co-workers that must be given a clear to > debug file, to initialize. > > We have done well and it does not throw the error message and 70xx discs. now > try to make SNA communication test and see if everything worked out well. > > > > > > to end the debug log when we always get a message erorr, but at least give > the command: > > cp q CHPID c00-cff…. out that all devices are FREE. > > > > JJ > > > > Best Regards, > > > > > > *Mario Izaguirre* > > Mainframe System Programmer > > Barcelona, Spain > > Best Regards, > > > > > > > > *De:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *En > nombre de *Kris Buelens > *Enviado el:* martes, 23 de marzo de 2010 13:43 > > *Para:* IBMVM@LISTSERV.UARK.EDU > *Asunto:* Re: OSA/SF Problem > > > > The OSASF Manual, for IOAx601E > For example, if a minidisk is not properly defined to an existing userid > (OSA/SF return code of 2), CP returns a return code of 107. RC=2107 is the > return code from the message. > > Help HCP107E > HCP107Euserid vdev not linked; not in CP directory > > It means your OSASF user does not have a minidisk 70xx where "xx" is the > CHPID of the OSA. In you case 700E should be a minidisk for user OSASF. > > 2010/3/23 Mario Izaguirre > > Hi, I watch you use OSA Express, and I have OSA 1000 Base T, when we > execute the in a IOACMD: > > > > option 5 (debugging) to made a log file. > > > > displays the following message to us: > > > > IOAV601E Minidisk I-O problem. Devnum=700E, RC=2107 > > > > The minidisk 70XX have a 5 cyls of space per one unit. > > > > > > Wath is happening .. L > > > > > > > > Best Regards, > > > > > > *Mario Izaguirre* > > Mainframe System Programmer > > Barcelona, Spain > > > > *De:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *En > nombre de *Kris Buelens > *Enviado el:* martes, 23 de marzo de 2010 8:16 > > > *Para:* IBMVM@LISTSERV.UARK.EDU > *Asunto:* Re: OSA/SF Problem > > > > I entered 5 (OSA Express), 24 (chpid), and N (QDIO). I'll send the control > files I used to Mario. > > 2010/3/23 ASIFF AMAHED > > Mario, > > did you do option 2 and then 5, i see in your example you do 2 and 7. > > you want OSE non-qdio. if its not working maybe you should call IBM > support. > > > > > On Mon, Mar 22, 2010 at 4:45 PM, Mario Izaguirre > wrote: > > Hi Asiff: > > > > The problem is that it gives the error when setting the first configuration > file, never comes to me for the second. > > > > > > Best Regards, > > > > > > *Mario Izaguirre* > > Mainframe System Programmer > > Barcelona, Spain > > > > > > > > > > *De:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *En > nombre de *ASIFF AMAHED > *Enviado el:* lunes, 22 de marzo de 2010 21:10 > > > *Para:* IBMVM@LISTSERV.UARK.EDU > *Asunto:* Re: OSA/SF Problem > > > > Mario, > > IOACMD > > 2 > 5 > > 0E > > QDIO= NO > > CHPID0E CFG A (configure file name) > > CHPID0E AOT A (AOT file name) > > in your AOT file NAME add something like this. > > > > > Image 0.0 (N/A) > 00(N/A) SNA 00 S OSA > > > Image 0.1 (PROD) > 00( 1400) SNA 00 S ALL > > 01(1401) N/AN/A CSS > 02(1402) N/AN/A CSS > 03(1403) N/AN/A CSS > 04(1404) N/A
Re: Friday gift - Perfkit ULOG
Actually, the REDISP log has contained this information since day zero .. (shift right) Eginhard - Original Message - From: Kris Buelens To: IBMVM@LISTSERV.UARK.EDU Sent: Friday, March 12, 2010 4:24 PM Subject: Friday gift - Perfkit ULOG Those with RTM/ESA experience may just like me have liked the ULOG display: it listed the user consuming most CPU (by default that was). If the system was slow, I displayed it to see who was since how long hogging the CPU. With PERFKIT, such a report no longer exists.
Re: VMLINK behavior
Bad news... Our IBM support that is not IBM... has not the IBM contract to open a PMR for me... Don't laugh... If someone here could do it for me...for the community... I would appreciate... Alain Benveniste Le 23 mars 2010 à 18:56, Mary Hottenstein a écrit : > I have recreated the reported behavior, and it's definitely the result of a > bug in VMLINK code. If you'd like to pursue, open a PMR, and I'll take a > look at it. > > Regards, > Mary Hottenstein > (IBM VM/CMS Support)
Re: initializing z/Linux disks
> You know the old virtualization saying, "Never depend on the kindness > of > guests." > > Alan Altmark One might be entertaining angels unaware...8-)
Re: Moderator comment Re: [IBMVM] z/VM/ Linux Systems Programmer Opportunity ...
And you need to bear in mind that the rules, silly or not, are probably mandated by state law in this case. Dan's suggestion about the automated FAQ sent to new subscribers is a good starting point, and Mike's reminder (or one like it) when there is an occasional breach of conduct is perfectly appropriate. Has this thread run its course? Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of IBMVM Moderator > Sent: Wednesday, March 24, 2010 9:18 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Moderator comment Re: [IBMVM] z/VM/ Linux Systems > Programmer Opportunity ... > > It's not just an issue of narrow-minded corporate management > on theoretical remote systems. Please bear in mind that we > are hosted, for free, by a state-run, tax-supported > institution. For better or ill, UARK has a long-standing > policy about not using their infrastructure for that type of > traffic. It happens rarely enough that the occasional > "trivial, though potentially conspicuous" breach of protocol > hasn't caused us any grief. I am, understandably, motivated > to ensure that it does not become a point of pain for our > gracious hosts. > > I don't pretend to understand why the rules are there, nor do > I care to engage in debate on the topic. It's UARK's > hardware, their network, and their rules. Silly-seeming > policies at third-party organizations are my favorite kind of > problem: Problems for other people. > > Admittedly, this isn't necessarily clear at present to "drive-by" > subscribers like the individual who posted the announcement. > It's not feasible to put the list on full moderation. I > don't have the bandwidth available to eyeball-inspect every > single post and bounce the rare exceptional case back to the sender. > > However, here's what I *can* do: Another list hosted by U. > Arkansas (SAG-L -- Software AG products discussion) has a > long-standing FAQ which includes policy statements regarding > this sort of posting. I'm acquainted with the list owner, > and will obtain his permission to grab a copy of that FAQ as > a starting template -- and then I'll file off the serial > numbers, strip out the stuff that's specific to ADABAS / > NATURAL / etc, and adapt the rest for use on IBMVM. While I > can't force anybody to actually *read* it, LISTSERV provides > a way to deliver an FAQ to all new subscribers. > > Interested parties are welcome to send me suggestions for > VM-specific FAQ items - but please bear in mind that much of > the heavy lifting on this matter is already addressed via > http://www.vm.ibm.com, and it seems pointless to duplicate > the resources already available there. > > -dan. >
Re: initializing z/Linux disks
Alan, With it not being a full-pack as Mike mentioned in his post, there would always have to be CCW translation, would there not? The question is whether that is a significant hit compared to the full pack including Cyl 0. Considering that, in the olden days, CP overhead was quite high compared to today, the performance hit, while there, might not be sufficient to be a cause of concern. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Wednesday, March 24, 2010 8:08 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: initializing z/Linux disks > > On Wednesday, 03/24/2010 at 04:51 EDT, "Ward, Mike S" > > wrote: > > I thought there was overhead in specifying it as a minidisk rather > > than a dedicated full disk. The overhead would be in the > translation > > of the I/O addresses and such. You know like linux reading > cyl 0 when > > it's really cyl 1 etc Is there still that type of > overhead in VM? > > Back in the native-mode days, there would be I/O assist for > dedicated devices that wouldn't be provided to a full-pack > minidisk. In an LPAR, the I/O assist isn't available to CP > (LPAR is using it), so CP is already handling the guest I/O. > Eric or Steve will have the definitive answer, but I > speculate that full-pack minidisks and dedicated dasd > generally take the same shortcuts for geometry issues. E.g. > no need to modify cylinder numbers. > > I'm guessing one of big differences, however, is the lack of > minidisk cache (MDC) for dedicated devices. In some cases > that's a help and others a hinderance. If it hurts, we give > you the ability to turn off MDC for a minidisk. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: initializing z/Linux disks
Another point I¹ve not seen mentioned, and I¹m not sure if it¹s true or not... Given a dedicated volume to a Linux guest, won¹t the guest start only one I/O to the device at a time, and wait for it to complete? If you break up a larger volume into several minidisks (like a mod 27 into mod 9¹s) aren¹t you allowing the z/VM multipathing to do its job more efficiently, even if you give all the smaller volumes to the same Linux guest? Like I said, I may be totally off base, but this is the impression I¹ve had... -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/24/10 2:38 PM, "Scott Rohling" wrote: > I would not recommend using DEDICATE -- why would you do that rather than use > minidisks? What you need to be aware of is that if you DEDICATE -- Linux > will label the DASD -- and that's what you'll see at the z/VM level -- and are > likely to see duplicate labels. (to things like 0x0200 and 0x0300, > etc...). Also - if you dedicate - you can't use things like DIRMAINT do > manage your dasd and keep things in pools, etc -- you have to manage it all > yourself. > > On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) > wrote: >> Hi >> >> I have a question. What I have been doing up to this point for a new z/Linux >> guest build is, not necessarily in this order and does not necessarily >> include all steps but, >> >> Crave out the DASD for the z/Linux guest >> >> Init the DASD using CPFMTXA putting a label on the disk >> >> Setting up the Directory entry for the new guest, which includes specifying >> the MDISK for all of the DASD for the guest. >> >> We back up our z/Linux guests on the z/OS side with DFDSS. >> >> My question is since when we Kick Start the new z/Linux guest and it >> initializes the DASD during this process is there any compelling reason for >> me to initialize the DASD up front before the guest is Kick Started for the >> first time basically doing a double INIT? >> >> If not I assume then I would replace the MDISK statements in the Directory >> entry with DEDICATE statements for each one of the DISKS. We do not share >> DASD between guests here so what is defined to the guest belongs to that >> guest only. Is there anything to be aware of by changing to DEDICATE >> statements from MDISK statements? >> >> My only concern is with the DFDSS backups that I do on the z/OS for the >> guests. I am not sure if it matters or not to DFDSS whether the pack was >> initialized via CPFMTXA or z/Linux during the kick start process? >> >> >> Thank You, >> >> Terry Martin >> Lockheed Martin - Citic >> z/OS and z/VM Performance Tuning and Operating Systems Support >> Office - 443 348-2102 >> Cell - 443 632-4191 >> >> > >
Re: initializing z/Linux disks
On Wednesday, 03/24/2010 at 04:31 EDT, David Boyes wrote: > On 3/24/10 3:40 PM, "Alan Altmark" wrote: > > > When giving guests access to real cyl 0, I suggest: > > 1. If using a full-pack mindisk, use the DEVNO version instead of volser. > > That way it doesn't matter if the guest changes the label. > > Doesn't that also bind you to specific device addresses? Yes, and that's the point; the guest is tied to a specific spinning entity. It's a Good Thing. If you want to change the association, change it. If the guest changes the volser, then MDISK won't be created the next time the user logs on. You know the old virtualization saying, "Never depend on the kindness of guests." Alan Altmark z/VM Development IBM Endicott
Re: Capping info
I wrote REXX functions B2C, B2D, B2X, C2B, D2B, and X2B years ago. For example:
/*
C2B
++
||
| C2B(string)|
||
++
Character to Binary. Converts a character string to its binary
representation. The data may be of any length.
Here are some examples:
C2B('72s') +'0111001010100010'
C2B('0123'x) +'000100100011'
*/
if arg() ^= 1 then /* Only one argument is valid */
return /* Incorrect call to routine */
arg chars
return x2b(c2x(chars))
If I had it to do over again, I'd probably imbed a PIPE command per Bruce's
example:
/* C2B EXEC */
arg chars
'PIPE VAR CHARS | SPECS 1-* C2B 1 | VAR BINARY'
return binary
Mark Wheeler
> Date: Thu, 25 Mar 2010 09:48:58 -0400
> From: bjhay...@gmail.com
> Subject: Re: Capping info
> To: IBMVM@LISTSERV.UARK.EDU
>
> Ahh... Forgot that "c2b" was only in the internal Rexx functions
> package. So, use Pipes instead:
> 'PIPE var result | specs 36.1 c2b 1 | var lparchar'
>
> On Thu, Mar 25, 2010 at 9:38 AM, Frank M. Ramaekers
> wrote:
> > C2B?
> >
> >20 +++ lparchar=c2b(substr(result,36,1))
> > DMSREX478E Error 43 running STSIX EXEC, line 20: Routine not found
> >
> >
> > Frank M. Ramaekers Jr.
> >
> >
> >
> > -Original Message-
> > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
> > Behalf Of Bruce Hayden
> > Sent: Thursday, March 25, 2010 7:33 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Capping info
> >
> > STSI can tell you if you are capped, but it can't tell you the weight.
> > Borrowing from the STSIUSE SAMPEXEC on MAINT 193:
> >
> > /*
> > * Logical-partition CPUs*
> > */
> > say 'STSI(2,2,2)2.2.2.'
> > result = stsi(2,2,2)
> > address command 'PIPE',
> > '| var result',
> > '| specs',
> > '/LPAR Number:/ 1 33.2 c2x nw write',
> > '/LCPUC: / 1 36.1 c2x nw write',
> > '/Total LCPU Count: / 1 37.2 c2d nw left write',
> > '/Conf. LCPU Count: / 1 39.2 c2d nw left write',
> > '/SB LCPU Count: / 1 41.2 c2d nw left write',
> > '/Resv. LCPU Count: / 1 43.2 c2d nw left write',
> > '/Logical-Partition Name: / 1 45.8 nw write',
> > '/Logical-Partition CAF: / 1 53.4 c2d nw left write',
> > '/Ded. LCPU Count:/ 1 73.2 c2d nw left write',
> > '/Shr. LCPU Count:/ 1 75.2 c2d nw left write',
> > '| cons'
> > lparchar=c2b(substr(result,36,1))
> > say 'LPAR characteristics:' lparchar
> > If substr(lparchar,1,1)=1 then say 'CPUs are dedicated'
> > If substr(lparchar,2,1)=1 then say 'CPUs are shared'
> > If substr(lparchar,3,1)=1 then say 'CPUs are limited'
> >
> >
> >
> > --
> > Bruce Hayden
> > z/VM and Linux on System z ATS
> > IBM, Endicott, NY
> >
> > _
>
> --
> Bruce Hayden
> z/VM and Linux on System z ATS
> IBM, Endicott, NY
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/210850552/direct/01/
Re: Capping info
I just used X2B(C2X(substr(result,36,1))) Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bruce Hayden Sent: Thursday, March 25, 2010 8:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Capping info Ahh... Forgot that "c2b" was only in the internal Rexx functions package. So, use Pipes instead: 'PIPE var result | specs 36.1 c2b 1 | var lparchar' On Thu, Mar 25, 2010 at 9:38 AM, Frank M. Ramaekers wrote: > C2B? > > 20 +++ lparchar=c2b(substr(result,36,1)) > DMSREX478E Error 43 running STSIX EXEC, line 20: Routine not found > > > Frank M. Ramaekers Jr. > > > > -Original Message- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Bruce Hayden > Sent: Thursday, March 25, 2010 7:33 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Capping info > > STSI can tell you if you are capped, but it can't tell you the weight. > Borrowing from the STSIUSE SAMPEXEC on MAINT 193: > > /* > * Logical-partition CPUs * > */ > say 'STSI(2,2,2)2.2.2.' > result = stsi(2,2,2) > address command 'PIPE', > '| var result', > '| specs', > '/LPAR Number: / 1 33.2 c2x nw write', > '/LCPUC: / 1 36.1 c2x nw write', > '/Total LCPU Count: / 1 37.2 c2d nw left write', > '/Conf. LCPU Count: / 1 39.2 c2d nw left write', > '/SB LCPU Count: / 1 41.2 c2d nw left write', > '/Resv. LCPU Count: / 1 43.2 c2d nw left write', > '/Logical-Partition Name: / 1 45.8 nw write', > '/Logical-Partition CAF: / 1 53.4 c2d nw left write', > '/Ded. LCPU Count: / 1 73.2 c2d nw left write', > '/Shr. LCPU Count: / 1 75.2 c2d nw left write', > '| cons' > lparchar=c2b(substr(result,36,1)) > say 'LPAR characteristics:' lparchar > If substr(lparchar,1,1)=1 then say 'CPUs are dedicated' > If substr(lparchar,2,1)=1 then say 'CPUs are shared' > If substr(lparchar,3,1)=1 then say 'CPUs are limited' > > > > -- > Bruce Hayden > z/VM and Linux on System z ATS > IBM, Endicott, NY > > _ -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Capping info
Ahh... Forgot that "c2b" was only in the internal Rexx functions package. So, use Pipes instead: 'PIPE var result | specs 36.1 c2b 1 | var lparchar' On Thu, Mar 25, 2010 at 9:38 AM, Frank M. Ramaekers wrote: > C2B? > > 20 +++ lparchar=c2b(substr(result,36,1)) > DMSREX478E Error 43 running STSIX EXEC, line 20: Routine not found > > > Frank M. Ramaekers Jr. > > > > -Original Message- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Bruce Hayden > Sent: Thursday, March 25, 2010 7:33 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Capping info > > STSI can tell you if you are capped, but it can't tell you the weight. > Borrowing from the STSIUSE SAMPEXEC on MAINT 193: > > /* > * Logical-partition CPUs * > */ > say 'STSI(2,2,2)2.2.2.' > result = stsi(2,2,2) > address command 'PIPE', > '| var result', > '| specs', > '/LPAR Number: / 1 33.2 c2x nw write', > '/LCPUC: / 1 36.1 c2x nw write', > '/Total LCPU Count: / 1 37.2 c2d nw left write', > '/Conf. LCPU Count: / 1 39.2 c2d nw left write', > '/SB LCPU Count: / 1 41.2 c2d nw left write', > '/Resv. LCPU Count: / 1 43.2 c2d nw left write', > '/Logical-Partition Name: / 1 45.8 nw write', > '/Logical-Partition CAF: / 1 53.4 c2d nw left write', > '/Ded. LCPU Count: / 1 73.2 c2d nw left write', > '/Shr. LCPU Count: / 1 75.2 c2d nw left write', > '| cons' > lparchar=c2b(substr(result,36,1)) > say 'LPAR characteristics:' lparchar > If substr(lparchar,1,1)=1 then say 'CPUs are dedicated' > If substr(lparchar,2,1)=1 then say 'CPUs are shared' > If substr(lparchar,3,1)=1 then say 'CPUs are limited' > > > > -- > Bruce Hayden > z/VM and Linux on System z ATS > IBM, Endicott, NY > > _ -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Re: Capping info
C2B? 20 +++ lparchar=c2b(substr(result,36,1)) DMSREX478E Error 43 running STSIX EXEC, line 20: Routine not found Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bruce Hayden Sent: Thursday, March 25, 2010 7:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Capping info STSI can tell you if you are capped, but it can't tell you the weight. Borrowing from the STSIUSE SAMPEXEC on MAINT 193: /* * Logical-partition CPUs* */ say 'STSI(2,2,2)2.2.2.' result = stsi(2,2,2) address command 'PIPE', '| var result', '| specs', '/LPAR Number:/ 1 33.2 c2x nw write', '/LCPUC: / 1 36.1 c2x nw write', '/Total LCPU Count: / 1 37.2 c2d nw left write', '/Conf. LCPU Count: / 1 39.2 c2d nw left write', '/SB LCPU Count: / 1 41.2 c2d nw left write', '/Resv. LCPU Count: / 1 43.2 c2d nw left write', '/Logical-Partition Name: / 1 45.8 nw write', '/Logical-Partition CAF: / 1 53.4 c2d nw left write', '/Ded. LCPU Count:/ 1 73.2 c2d nw left write', '/Shr. LCPU Count:/ 1 75.2 c2d nw left write', '| cons' lparchar=c2b(substr(result,36,1)) say 'LPAR characteristics:' lparchar If substr(lparchar,1,1)=1 then say 'CPUs are dedicated' If substr(lparchar,2,1)=1 then say 'CPUs are shared' If substr(lparchar,3,1)=1 then say 'CPUs are limited' On Wed, Mar 24, 2010 at 5:28 PM, Kris Buelens wrote: > No CP command as far as I know, STSI: I don't think so. > > But, performance monitors report this in their LPAR reports. If you've got > Perfkit: PIPE VMC PERFSVM |. > > Hence you could use a PIPE to listen to the monitor records and analyse it > yourself. You must be prepared to unravel raw monitor records > > 2010/3/24 Alain Benveniste >> >> Is there a way to get the info if my VM lpar is capped or not and what is >> weight ? >> >> Could be great to see these info with the indicate cmd...? >> >> This info is needed for us to avoid to run licenced products with more >> power than we pay for >> using them...not to be lawfull... >> >> Alain Benveniste > > > > -- > Kris Buelens, > IBM Belgium, VM customer support > -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Capping info
STSI can tell you if you are capped, but it can't tell you the weight. Borrowing from the STSIUSE SAMPEXEC on MAINT 193: /* * Logical-partition CPUs* */ say 'STSI(2,2,2)2.2.2.' result = stsi(2,2,2) address command 'PIPE', '| var result', '| specs', '/LPAR Number:/ 1 33.2 c2x nw write', '/LCPUC: / 1 36.1 c2x nw write', '/Total LCPU Count: / 1 37.2 c2d nw left write', '/Conf. LCPU Count: / 1 39.2 c2d nw left write', '/SB LCPU Count: / 1 41.2 c2d nw left write', '/Resv. LCPU Count: / 1 43.2 c2d nw left write', '/Logical-Partition Name: / 1 45.8 nw write', '/Logical-Partition CAF: / 1 53.4 c2d nw left write', '/Ded. LCPU Count:/ 1 73.2 c2d nw left write', '/Shr. LCPU Count:/ 1 75.2 c2d nw left write', '| cons' lparchar=c2b(substr(result,36,1)) say 'LPAR characteristics:' lparchar If substr(lparchar,1,1)=1 then say 'CPUs are dedicated' If substr(lparchar,2,1)=1 then say 'CPUs are shared' If substr(lparchar,3,1)=1 then say 'CPUs are limited' On Wed, Mar 24, 2010 at 5:28 PM, Kris Buelens wrote: > No CP command as far as I know, STSI: I don't think so. > > But, performance monitors report this in their LPAR reports. If you've got > Perfkit: PIPE VMC PERFSVM |. > > Hence you could use a PIPE to listen to the monitor records and analyse it > yourself. You must be prepared to unravel raw monitor records > > 2010/3/24 Alain Benveniste >> >> Is there a way to get the info if my VM lpar is capped or not and what is >> weight ? >> >> Could be great to see these info with the indicate cmd...? >> >> This info is needed for us to avoid to run licenced products with more >> power than we pay for >> using them...not to be lawfull... >> >> Alain Benveniste > > > > -- > Kris Buelens, > IBM Belgium, VM customer support > -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Re: on job postings
On Thu, Mar 25, 2010 at 4:19 AM, Gabe Goldberg wrote: > More people likely see these notices here than would on Velocity's Web site, > so this seems a better place for them. A better solution seems to be for > people working at companies which think they can censor information their > employees see to read the list on home computers. The same holds for showing your nipples during Superbowl. Many people will see it, but that was not why they were watching the game. Even though I may find it silly, there are people who would not want to watch the game when they could be confronted with the bonus (and I would not even want to watch the game even when I knew the bonus would be there, but that's something else..) In a former life when mailing lists were getting more popular, I suggested my manager to give guidance on what we do with it. His response was "my staff should not waste time looking into problems of other companies: not allowed." And we did anyway, just never told him our problem was fixed next day because of that type of exchange. Which means he was never told that policy was wrong and counter productive... So the rule remained in place. But I think it's unfair to force a peer to unsubscribe from the list because we think his employer should see things otherwise. Most likely that peer needs the technical contacts on the list more than others because they may live a sheltered live and not go to conferences (or even have a phone with published number ;-). Back then, Tony used to post a monthly reminder notice with a link to the jobs posted on the Velocity Software pages. I suspect the amount of vacancies was too low to justify doing that. How about sending such a reminder when a new job is posted? I think it could even include function/location in the subject without going over the edge. Rob
