Re: pipe question?
Thank you..ok, but I want to know when it already finishes processing the guests list, to be able to send a message that all were processed As Berry he comments, I use Operations Manager to detect the exits of the consoles of the guests and to reformat the messages and to send them to the operator console, and for this reason I need to know when it already finishes processing all the guests in the list and to send a termination message All the guests linux was processed. Thank you for all the contributions, I am revising each one of them and making tests Regards ATTN Victor Hugo 2010/8/8 Kyle Black bigbl...@gmail.com Victor, If I were going to do something like this, I would just build the commands in the pipe and send them to CP. 'pipe guest list a', '| spec /send/ 1 w1 nw /start-stop.sh/ nw ', '| cp' For each guest in the list a seperate cp command will be sent. So no need to manually parse the list. Verify the output by replacing the CP stage with CONS. If you need to run the commands staggered by some time limit you could do this... 'pipe guest list a', '| spec /send/ 1 w1 nw /start-stop.sh/ nw ', '| stem comms.' do i=1 to comms.0 'cp' comms.i 'wakeup +00:00:10' end Kyle Black On Sun, Aug 8, 2010 at 7:42 AM, Berry van Sleeuwen berry.vansleeu...@xs4all.nl wrote: We run such a process but not within one pipeline. The rexx exec runs in a PROP user that monitors the linux guests. I do like PIPE so there are some pipelines inside the exec. 1. When our CMS scheduler sends command KICK_LINUX the exec will build a list of commands. Basically your step 1. 2. When a Linuxguest issues KICK_LINUX the command for that user is removed from the list. Basically your step 3. 3. Everytime KICK_LINUX is called the first line of the list is send to the linuxuser in that line. This way the exec doesn't have to wait for a script to end. And during that time PROP has control so any message, either related to KICK_LINUX or not, will still be processed by PROP. The only problem is that we can't tell if the sequence has stalled. If guest3 doesn't return the KICK_LINUX message guest4 will never be triggered. I guess your step 4 will tell you if it has stalled (or rather when it doesn't tell you...). Since we run automatically I would prefer the other way: 'Your sequence has stalled. Please call System support.' but I haven't figured out how to detect a stall. Regards, Berry. Op 08-08-10 10:31, Victor Ochoa Avila schreef: Thanks by the answers, but specifically this is what I want 1.- first I obtain the list of guests active. pipe cp q n| split /,/ | specs w1 1 | locate /CMP/ | GUESTS LISTS A Note: CMP is my pattern for guests in production mode in this partition. For example: CMPWAPE1, CMPWSPE1, CMPDBPE1 My lists is CMPWAPE1 CMPWSPE1 CMPDBPE1 2.- I am going to send this command to each guests linux of this list cp send CMPWAPE1 start-stop.sh 3.- When this script finalize I need to erase this guets of the file GUESTS LISTS A AND count the elements, to know if file is empty. 4.- if file is empty then I finish to the process and sent a message All the guets were process 5.- If file isn't empty take the next guest name in file and return to step 2. I do not know I can realise this loop with a pipe ? Thanks to all by your help ATTE VIctor Hugo 2010/8/7 Hughes, Jim jim.hug...@doit.nh.gov Nice catch. My brain didn't get engaged while the fingers were typing. _ Jim Hughes x5586 It is fun to do the impossible. Quote from Walt Disney From: The IBM z/VM Operating System on behalf of Rob van der Heij Sent: Sat 8/7/2010 8:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: pipe question? On Sat, Aug 7, 2010 at 12:43 PM, Hughes, Jim jim.hug...@doit.nh.gov wrote: pipe (endchar ?) , ? guests list a , | bld: take 1, | guests list a , ? bld: , your process follows You meant to drop rather than take to leave all but the first record in the file. But it's an elegant style to divert the record to process towards the end of the pipeline (so you don't forget to keep the remainder). And real plumbing would be to handle them all, not just one of them (but that's beyond the question). | Rob -- Victor Hugo Ochoa Avila z/OS z/VM systems programmer Mexico, City. -- Victor Hugo Ochoa Avila z/OS z/VM systems programmer Mexico, City.
Re: pipe question?
Berry, You need a Watchdog DVM that gets a msg about which guest has been kicked and how long to wait for a response before reporting 'stalled'. It then generates its own WAKEUP event looking for the COMPLETED msg from PROP. A counter can be kept to time-slice events so that more than one can be monitored. With a little thought, you can let the Watchdog DVM check for activity for all your other DVMs, which is what I did for some 15 DVMs across 4 systems before I retired. Technically, of course, you also need a Watchdog watcher. For me, that was me on our Development system in Tampa. This technique was even published in one of the Journals by someone from YKT, iirc, but it was a lot of years ago! Les Berry van Sleeuwen wrote: We run such a process but not within one pipeline. The rexx exec runs in a PROP user that monitors the linux guests. I do like PIPE so there are some pipelines inside the exec. 1. When our CMS scheduler sends command KICK_LINUX the exec will build a list of commands. Basically your step 1. 2. When a Linuxguest issues KICK_LINUX the command for that user is removed from the list. Basically your step 3. 3. Everytime KICK_LINUX is called the first line of the list is send to the linuxuser in that line. This way the exec doesn't have to wait for a script to end. And during that time PROP has control so any message, either related to KICK_LINUX or not, will still be processed by PROP. The only problem is that we can't tell if the sequence has stalled. If guest3 doesn't return the KICK_LINUX message guest4 will never be triggered. I guess your step 4 will tell you if it has stalled (or rather when it doesn't tell you...). Since we run automatically I would prefer the other way: 'Your sequence has stalled. Please call System support.' but I haven't figured out how to detect a stall. Regards, Berry. Op 08-08-10 10:31, Victor Ochoa Avila schreef: Thanks by the answers, but specifically this is what I want 1.- first I obtain the list of guests active. pipe cp q n| split /,/ | specs w1 1 | locate /CMP/ | GUESTS LISTS A Note: CMP is my pattern for guests in production mode in this partition. For example: CMPWAPE1, CMPWSPE1, CMPDBPE1 My lists is CMPWAPE1 CMPWSPE1 CMPDBPE1 2.- I am going to send this command to each guests linux of this list cp send CMPWAPE1 start-stop.sh 3.- When this script finalize I need to erase this guets of the file GUESTS LISTS A AND count the elements, to know if file is empty. 4.- if file is empty then I finish to the process and sent a message All the guets were process 5.- If file isn't empty take the next guest name in file and return to step 2. I do not know I can realise this loop with a pipe ? Thanks to all by your help ATTE VIctor Hugo 2010/8/7 Hughes, Jim jim.hug...@doit.nh.gov mailto:jim.hug...@doit.nh.gov Nice catch. My brain didn't get engaged while the fingers were typing. _ Jim Hughes x5586 It is fun to do the impossible. Quote from Walt Disney From: The IBM z/VM Operating System on behalf of Rob van der Heij Sent: Sat 8/7/2010 8:48 AM To: IBMVM@LISTSERV.UARK.EDU mailto:IBMVM@LISTSERV.UARK.EDU Subject: Re: pipe question? On Sat, Aug 7, 2010 at 12:43 PM, Hughes, Jim jim.hug...@doit.nh.gov mailto:jim.hug...@doit.nh.gov wrote: pipe (endchar ?) , ? guests list a , | bld: take 1, | guests list a , ? bld: , your process follows You meant to drop rather than take to leave all but the first record in the file. But it's an elegant style to divert the record to process towards the end of the pipeline (so you don't forget to keep the remainder). And real plumbing would be to handle them all, not just one of them (but that's beyond the question). | Rob -- Victor Hugo Ochoa Avila z/OS z/VM systems programmer Mexico, City.
Re: z/OS 1.4 on a z/10
I figured, but I had to make sure. Thank you. Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Post Sent: Sunday, August 08, 2010 2:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/OS 1.4 on a z/10 On 8/8/2010 at 01:56 PM, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: z/OS 1.4 will not run natively on a z/10. But does anybody know if z/OS 1.4 will run as a guest under z/VM 5.4 on a z/10. The z/VM developers that hang out here have repeatedly stated that z/VM has no magic in that regard. Mark Post Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
SLES11 PARMFILE entries not being read correctly
I'm posting here since the initial execution of the SLES 11 upgrade happe ns in a z/VM virtual machine prior to establishing a Linux session. Apologies if this is inappropriate; I will post to the Linux 390 list if needed (I'm having major difficulties posting to ANY list, so I'm not even going to attempt cross/multiple postings g) So, on to the issue... I saw in an earlier post(sometime last year) someone having a *similar* problem as I am : The user was supplying values for Portname and NameServer, but still gett ing prompts during the install. The response to the user was to supply a null value in the PARMFILE for t he two parameters in question, and to supply 0 (or 1 depending on the configuration of the card) for Portno= as this could possibly suppress the prompt for the DNS server. My issue is that I'm supplying a null value for portname as it is not defined on the card, and I am supplying an address for NameServer and sti ll receiving prompts. I'm reading through Section 4.4 The parmfile - Automating the System Configuration in the SLES 11 Deployment Guide, and not seeing anything ab out how to supply null values. This isn't a show-stopper, but I'm looking to completely automate this portion of the SLES 11 install. If it doesn't happen, c'est le vie. Thanks! -Tom
Re: SLES11 PARMFILE entries not being read correctly
I did encounter similar problem installing RedHat Linux 5.4. The installer was not reading the Conf/PARM(?) file and was prompting for the values to be entered. The installer bug, apparently, shows up when the guest had only one virtual CPU defined and the work around, at least for me, was to define 2 virtual CPUs just for the installation. If this work around solves your issue then do remember to take off unnecessary virtual CPU after the installation/upgrade. Regards, Ashwin Bhemidhi -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duggan Sent: Monday, August 09, 2010 10:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SLES11 PARMFILE entries not being read correctly I'm posting here since the initial execution of the SLES 11 upgrade happe= ns in a z/VM virtual machine prior to establishing a Linux session. Apologies if this is inappropriate; I will post to the Linux 390 list if needed (I'm having major difficulties posting to ANY list, so I'm not even going to attempt cross/multiple postings g) So, on to the issue... I saw in an earlier post(sometime last year) someone having a *similar* problem as I am : The user was supplying values for Portname and NameServer, but still gett= ing prompts during the install. The response to the user was to supply a null value in the PARMFILE for t= he two parameters in question, and to supply 0 (or 1 depending on the configuration of the card) for Portno= as this could possibly suppress = the prompt for the DNS server. My issue is that I'm supplying a null value for portname as it is not defined on the card, and I am supplying an address for NameServer and sti= ll receiving prompts. I'm reading through Section 4.4 The parmfile - Automating the System Configuration in the SLES 11 Deployment Guide, and not seeing anything ab= out how to supply null values. This isn't a show-stopper, but I'm looking to completely automate this portion of the SLES 11 install. If it doesn't happen, c'est le vie. Thanks! -Tom
Re: SLES11 PARMFILE entries not being read correctly
Depending on the missing Parameter, you may then get prompted for many more parms. I believe that the offending parm was PortNum or Macaddress. On Mon, Aug 9, 2010 at 12:42 PM, Bhemidhi, Ashwin ashw...@ti.com wrote: I did encounter similar problem installing RedHat Linux 5.4. The installer was not reading the Conf/PARM(?) file and was prompting for the values to be entered. The installer bug, apparently, shows up when the guest had only one virtual CPU defined and the work around, at least for me, was to define 2 virtual CPUs just for the installation. If this work around solves your issue then do remember to take off unnecessary virtual CPU after the installation/upgrade. Regards, Ashwin Bhemidhi -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duggan Sent: Monday, August 09, 2010 10:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SLES11 PARMFILE entries not being read correctly I'm posting here since the initial execution of the SLES 11 upgrade happe= ns in a z/VM virtual machine prior to establishing a Linux session. Apologies if this is inappropriate; I will post to the Linux 390 list if needed (I'm having major difficulties posting to ANY list, so I'm not even going to attempt cross/multiple postings g) So, on to the issue... I saw in an earlier post(sometime last year) someone having a *similar* problem as I am : The user was supplying values for Portname and NameServer, but still gett= ing prompts during the install. The response to the user was to supply a null value in the PARMFILE for t= he two parameters in question, and to supply 0 (or 1 depending on the configuration of the card) for Portno= as this could possibly suppress = the prompt for the DNS server. My issue is that I'm supplying a null value for portname as it is not defined on the card, and I am supplying an address for NameServer and sti= ll receiving prompts. I'm reading through Section 4.4 The parmfile - Automating the System Configuration in the SLES 11 Deployment Guide, and not seeing anything ab= out how to supply null values. This isn't a show-stopper, but I'm looking to completely automate this portion of the SLES 11 install. If it doesn't happen, c'est le vie. Thanks! -Tom -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Re: SLES11 PARMFILE entries not being read correctly
On 8/9/2010 at 11:26 AM, Tom Duggandugg...@emigrant.com wrote: I saw in an earlier post(sometime last year) someone having a *similar* problem as I am : The user was supplying values for Portname and NameServer, but still getting prompts during the install. The response to the user was to supply a null value in the PARMFILE for the two parameters in question, and to supply 0 (or 1 depending on the configuration of the card) for Portno= as this could possibly suppress the prompt for the DNS server. I don't believe the parser understands null values. For portname, I use None. For DNS server, use 127.0.0.1. Mark Post
Interesting OSA problem
We are running a z9BC with z/VM 5.4. Prior to the microcode upgrade a week ago Saturday, our OS/390 guest used native OSA addresses and our z/OS guests (1.4 1.5) used a VSWITCH. After the microcode upgrade, our OS/390 guest (using native OSA addresses) was communicating very slowly with a TN3270 terminal. We also tested one of our z/OS (1.4) guests using native OSA addresses and communication with a TN3270 terminal was also very slow. When I put the z/OS (1.4) guest back to using the VSWITCH, everything is fine. The microcode level is 67. Over a year ago, we replaced the OSA card because of another problem. Is the OSA card having problems ? Is the VSWITCH doing something to make older operating systems work ?
Re: Interesting OSA problem
Hmm -- seemed to start with the microcode update ... Have you rechecked your OSA values at the HMC since the microcode update? Make sure they are right speed, mtu - etc... You didn't say if your vswitch is connected to a different OSA, but am assuming it is?Doesn't make sense at first glance ... but it all depends on what the 'bad OSA' is connected to -- any chance there were also network changes to switches/routers/etc that might explain? Things like MTU size difference can cause slowness and hangs.. Scott Rohling On Mon, Aug 9, 2010 at 3:50 PM, Daniel Allen dal...@serena.com wrote: We are running a z9BC with z/VM 5.4. Prior to the microcode upgrade a week ago Saturday, our OS/390 guest used native OSA addresses and our z/OS guests (1.4 1.5) used a VSWITCH. After the microcode upgrade, our OS/390 guest (using native OSA addresses) was communicating very slowly with a TN3270 terminal. We also tested one of our z/OS (1.4) guests using native OSA addresses and communication with a TN3270 terminal was also very slow. When I put the z/OS (1.4) guest back to using the VSWITCH, everything is fine. The microcode level is 67. Over a year ago, we replaced the OSA card because of another problem. Is the OSA card having problems ? Is the VSWITCH doing something to make older operating systems work ?
Re: Interesting OSA problem
For the native OSA addresses, we were using 104, 105 and 103. For our VSWITCH we used 109, 10A and 10B. z/VM TCPIP uses 10C, 10D and 10E. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, August 09, 2010 3:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Interesting OSA problem Hmm -- seemed to start with the microcode update ... Have you rechecked your OSA values at the HMC since the microcode update? Make sure they are right speed, mtu - etc... You didn't say if your vswitch is connected to a different OSA, but am assuming it is?Doesn't make sense at first glance ... but it all depends on what the 'bad OSA' is connected to -- any chance there were also network changes to switches/routers/etc that might explain? Things like MTU size difference can cause slowness and hangs.. Scott Rohling On Mon, Aug 9, 2010 at 3:50 PM, Daniel Allen dal...@serena.commailto:dal...@serena.com wrote: We are running a z9BC with z/VM 5.4. Prior to the microcode upgrade a week ago Saturday, our OS/390 guest used native OSA addresses and our z/OS guests (1.4 1.5) used a VSWITCH. After the microcode upgrade, our OS/390 guest (using native OSA addresses) was communicating very slowly with a TN3270 terminal. We also tested one of our z/OS (1.4) guests using native OSA addresses and communication with a TN3270 terminal was also very slow. When I put the z/OS (1.4) guest back to using the VSWITCH, everything is fine. The microcode level is 67. Over a year ago, we replaced the OSA card because of another problem. Is the OSA card having problems ? Is the VSWITCH doing something to make older operating systems work ?
Re: Interesting OSA problem
Well - if you're willing to swap around OSA addresses -- you should be able to pinpoint if it's that particular OSA. I'm assuming you have no issues with the z/VM access (which uses native)? There may be clues in the microcode update notes as well shrug.. I would start with verifying the OSA is configured correctly at the HMC ... if all the OSA's are defined the same -- and only the one performs bad -- guess it's time for a CE to check out the OSA. Does seem suspicious it coincides with a microcode update though. Scott Rohling On Mon, Aug 9, 2010 at 4:16 PM, Daniel Allen dal...@serena.com wrote: For the native OSA addresses, we were using 104, 105 and 103. For our VSWITCH we used 109, 10A and 10B. z/VM TCPIP uses 10C, 10D and 10E. *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Scott Rohling *Sent:* Monday, August 09, 2010 3:02 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: Interesting OSA problem Hmm -- seemed to start with the microcode update ... Have you rechecked your OSA values at the HMC since the microcode update? Make sure they are right speed, mtu - etc... You didn't say if your vswitch is connected to a different OSA, but am assuming it is?Doesn't make sense at first glance ... but it all depends on what the 'bad OSA' is connected to -- any chance there were also network changes to switches/routers/etc that might explain? Things like MTU size difference can cause slowness and hangs.. Scott Rohling On Mon, Aug 9, 2010 at 3:50 PM, Daniel Allen dal...@serena.com wrote: We are running a z9BC with z/VM 5.4. Prior to the microcode upgrade a week ago Saturday, our OS/390 guest used native OSA addresses and our z/OS guests (1.4 1.5) used a VSWITCH. After the microcode upgrade, our OS/390 guest (using native OSA addresses) was communicating very slowly with a TN3270 terminal. We also tested one of our z/OS (1.4) guests using native OSA addresses and communication with a TN3270 terminal was also very slow. When I put the z/OS (1.4) guest back to using the VSWITCH, everything is fine. The microcode level is 67. Over a year ago, we replaced the OSA card because of another problem. Is the OSA card having problems ? Is the VSWITCH doing something to make older operating systems work ?
Re: Interesting OSA problem
In testing the z/OS (1.4) guest, I used native OSA addresses 104, 105 and 103 for one test. For other test, I used 114, 115 and 113. The results were the same. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, August 09, 2010 3:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Interesting OSA problem Well - if you're willing to swap around OSA addresses -- you should be able to pinpoint if it's that particular OSA. I'm assuming you have no issues with the z/VM access (which uses native)? There may be clues in the microcode update notes as well shrug.. I would start with verifying the OSA is configured correctly at the HMC ... if all the OSA's are defined the same -- and only the one performs bad -- guess it's time for a CE to check out the OSA. Does seem suspicious it coincides with a microcode update though. Scott Rohling On Mon, Aug 9, 2010 at 4:16 PM, Daniel Allen dal...@serena.commailto:dal...@serena.com wrote: For the native OSA addresses, we were using 104, 105 and 103. For our VSWITCH we used 109, 10A and 10B. z/VM TCPIP uses 10C, 10D and 10E. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDUmailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Monday, August 09, 2010 3:02 PM To: IBMVM@LISTSERV.UARK.EDUmailto:IBMVM@LISTSERV.UARK.EDU Subject: Re: Interesting OSA problem Hmm -- seemed to start with the microcode update ... Have you rechecked your OSA values at the HMC since the microcode update? Make sure they are right speed, mtu - etc... You didn't say if your vswitch is connected to a different OSA, but am assuming it is?Doesn't make sense at first glance ... but it all depends on what the 'bad OSA' is connected to -- any chance there were also network changes to switches/routers/etc that might explain? Things like MTU size difference can cause slowness and hangs.. Scott Rohling On Mon, Aug 9, 2010 at 3:50 PM, Daniel Allen dal...@serena.commailto:dal...@serena.com wrote: We are running a z9BC with z/VM 5.4. Prior to the microcode upgrade a week ago Saturday, our OS/390 guest used native OSA addresses and our z/OS guests (1.4 1.5) used a VSWITCH. After the microcode upgrade, our OS/390 guest (using native OSA addresses) was communicating very slowly with a TN3270 terminal. We also tested one of our z/OS (1.4) guests using native OSA addresses and communication with a TN3270 terminal was also very slow. When I put the z/OS (1.4) guest back to using the VSWITCH, everything is fine. The microcode level is 67. Over a year ago, we replaced the OSA card because of another problem. Is the OSA card having problems ? Is the VSWITCH doing something to make older operating systems work ?
Re: SLES11 PARMFILE entries not being read correctly
Multiple virtual CPUs didn't work, but making the PortName value noneand the NameServer value to loopback (127.0.0.1) did the trick!Much thanks to all!-Tom Tom Duggan (914) 785-1412 On 8/9/2010 at 11:26 AM, Tom Duggandugg...@emigrant.com wrote: I saw in an earlier post(sometime last year) someone having a *similar* problem as I am : The user was supplying values for Portname and NameServer, but still getting prompts during the install. The response to the user was to supply a null value in the PARMFILE for the two parameters in question, and to supply 0 (or 1 depending on the configuration of the card) for Portno= as this could possibly suppress the prompt for the DNS server. I don't believe the parser understands null values. For portname, I use None. For DNS server, use 127.0.0.1. Mark Post _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
