Re: RACFVM: ICH520I
Kris You are right ICH520i appears before a CST and a RPI message. If i execute my vmoperator script on the last standard message format, It works. If I put a sleep in my script and execute it as soon as ich520i appears, it works. I think to open a pmr for this. Alain Le 8 mars 2011 à 08:38, Kris Buelens kris.buel...@gmail.com a écrit : Alan, people using the VM:Operator software have it normally installed in the System Operator, so it is started before RACF comes up. He,ce it is indeed tempting to use a RACF message to start automated startup using VM:Operator scripts. 2011/3/8 Alan Altmark alan_altm...@us.ibm.com On Monday, 03/07/2011 at 11:10 EST, Alain Benveniste a.benveni...@free.fr wrote: ICH520I RACF x IS ACTIVE. Explanation: RACF release x has been successfully initialized. I removed xautolog autolog2 from raciplxi and I asked VM:Operator to autolog VMSERV* users prior to xautolog autolog2 when the message ICH520I is met. I got a HCP6525E External Security Manager is unavailable. ICH520I seems to lie ! :) It is in there so that we can catch people trying to cheat RACF and AUTOLOG2. The only virtual machines that are permitted to start prior to RACF are the SYSTEM_USERIDs from SYSTEM CONFIG (e.g. OPEREREP, OPERATOR, etc.). They run with their CP-given permissions until RACF is up. AUTOLOG2 should start VM:Operator, which can then bring up the rest of the system. If you want something a little cleaner: 1. Put SYSTEM_USERIDS STARTUP RACFVM in SYSTEM CONFIG 2. Change RACIPLXI EXEC to autolog AUTOLOG1. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: RACFVM: ICH520I
You should better not place a CP SLEEP in VM:Operator scripts: it will make the whole VM operator go to wait, and when many message arrive for VM:operator while it waits, CP's IUCV queue could get full and CP will then throw them at the console, instead of presenting them to IUCV, where VM:Operator will find them. With other words: the extra messages are lost for VM:Operator's automation. Better is the code a REXX script in a file with type VMOPER, and then you can code TEST WAIT (if I remember well), that will put only that script in a wait state. Maybe the keyword to start a VMOPER differs from the keyword to start an EXEC. SPAWN comes in my mind. It's all a long time ago that I played with VM:Oper automatisation. 2011/3/8 Alain Benveniste a.benveni...@free.fr Kris You are right ICH520i appears before a CST and a RPI message. If i execute my vmoperator script on the last standard message format, It works. If I put a sleep in my script and execute it as soon as ich520i appears, it works. I think to open a pmr for this. Alain er well) Le 8 mars 2011 à 08:38, Kris Buelens kris.buel...@gmail.com kris.buel...@gmail.com a écrit : Alan, people using the VM:Operator software have it normally installed in the System Operator, so it is started before RACF comes up. He,ce it is indeed tempting to use a RACF message to start automated startup using VM:Operator scripts. 2011/3/8 Alan Altmark alan_altm...@us.ibm.comalan_altm...@us.ibm.com alan_altm...@us.ibm.com On Monday, 03/07/2011 at 11:10 EST, Alain Benveniste a.benveni...@free.fr a.benveni...@free.fra.benveni...@free.fr wrote: ICH520I RACF x IS ACTIVE. Explanation: RACF release x has been successfully initialized. I removed xautolog autolog2 from raciplxi and I asked VM:Operator to autolog VMSERV* users prior to xautolog autolog2 when the message ICH520I is met. I got a HCP6525E External Security Manager is unavailable. ICH520I seems to lie ! :) It is in there so that we can catch people trying to cheat RACF and AUTOLOG2. The only virtual machines that are permitted to start prior to RACF are the SYSTEM_USERIDs from SYSTEM CONFIG (e.g. OPEREREP, OPERATOR, etc.). They run with their CP-given permissions until RACF is up. AUTOLOG2 should start VM:Operator, which can then bring up the rest of the system. If you want something a little cleaner: 1. Put SYSTEM_USERIDS STARTUP RACFVM in SYSTEM CONFIG 2. Change RACIPLXI EXEC to autolog AUTOLOG1. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training http://ibm.com/systems/services/labserviceshttp://ibm.com/systems/services/labservices ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com alan_altm...@us.ibm.com alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
Re: Contemplating upgrading 2105-800 to DS6800
Yes, we did that and it was seamless. Best advice use fibre (and as many as you can afford). I don't know if your 2105 is ESCON or Fibre attached. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Nigel Salway Sent: Monday, March 07, 2011 4:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Contemplating upgrading 2105-800 to DS6800 Dear Friends, I am considering replacing a 1 TB 2105-800 shark with a 1TB DS6800. Does anyone have experience with such an upgrade? Any warnings, tips or comments? TIA Nigel Salway _ 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: Contemplating upgrading 2105-800 to DS6800
I thought the DS6800 was withdrawn from marketing. On Tue, Mar 8, 2011 at 8:01 AM, Frank M. Ramaekers framaek...@ailife.comwrote: Yes, we did that and it was seamless. Best advice use fibre (and as many as you can afford). I don’t know if your 2105 is ESCON or Fibre attached. Frank M. Ramaekers Jr. -- *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On Behalf Of *Nigel Salway *Sent:* Monday, March 07, 2011 4:12 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Contemplating upgrading 2105-800 to DS6800 Dear Friends, I am considering replacing a 1 TB 2105-800 shark with a 1TB DS6800. Does anyone have experience with such an upgrade? Any warnings, tips or comments? TIA Nigel Salway _ 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. -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Re: Contemplating upgrading 2105-800 to DS6800
We went from Ramac to Shark to DS8100 no problem. We use FDRPAS to do the copies for us. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Nigel Salway Sent: Monday, March 07, 2011 4:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Contemplating upgrading 2105-800 to DS6800 Dear Friends, I am considering replacing a 1 TB 2105-800 shark with a 1TB DS6800. Does anyone have experience with such an upgrade? Any warnings, tips or comments? TIA Nigel Salway == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: RACFVM: ICH520I
On Tuesday, 03/08/2011 at 03:18 EST, Alain Benveniste a.benveni...@free.fr wrote: I think to open a pmr for this. ICH520I *is* somewhat misleading in a VM environment. It is from the core RACF/MVS services engine that is started by the RACF/VM shell. Only after the engine is happily running will RACF connect to CP, indicated by the message RACF AUTHORIZATION COMMUNICATIONS INTERFACE READY being sent to the RACFVM console (not the OPERATOR). Immediately after that message is issued, RACIPLXI will run. As shipped by IBM (it is a customizable exec), RACIPLXI will issue RACF initialized - begin startup procedures You can, of course, modify RACIPLXI to issue your own message. While looking at source code, I learned that RACF runs RACSVRXI EXEC when it severs its IUCV connection to CP. Yes, it's mentioned in the RACF System Programmer's Guide, but in more of a whisper. Live and learn Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Creating a Second IP Stack
On Tuesday, 03/08/2011 at 02:51 EST, Kris Buelens kris.buel...@gmail.com wrote: An OSA ICC is great, but costs real money: the price of that OSA card, it will be dedicated to its OSA ICC function. To clarify, except for 10 Gb ethernet, all OSA cards have two chpids. You assign ICC on a per-chpid basis. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Creating a Second IP Stack
Thanks Alan, I should have mentioned that too. 2011/3/8 Alan Altmark alan_altm...@us.ibm.com On Tuesday, 03/08/2011 at 02:51 EST, Kris Buelens kris.buel...@gmail.com wrote: An OSA ICC is great, but costs real money: the price of that OSA card, it will be dedicated to its OSA ICC function. To clarify, except for 10 Gb ethernet, all OSA cards have two chpids. You assign ICC on a per-chpid basis. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: RACFVM: ICH520I
Alain, The VM:Operator primitive command to cause the script to wait for a given period and/or number of messages is: PROCESS WAIT [seconds|* [messages|1] ] The 'TEST' before 'PROCESS WAIT' prevents an error if a nonzero return code is issued - which is likely, as the number of messages returned in the stack is the return code (or '24' for a 'PROCESS WAIT' parameter error). Because they are VM:Operator primitive commands (not CP, CMS, etc. commands), VM:Operator primitives must be executed from the rexx 'VMOPER' addressing environment (VMOPER is the default addressing environment for scripts with filetype VMOPER). For example: /* TEST EXEC */ trace i address COMMAND say time() ' envir='address() 'TEST PROCESS WAIT 5' say time()', rc='rc address VMOPER say time() ' envir='address() 'TEST PROCESS WAIT 5' say time()', rc='rc Exit 0 And the trace results: 4 *-* address COMMAND 5 *-* say time() ' envir='address F 09:17:08 Lenvir= O 09:17:08 envir= F COMMAND O 09:17:08 envir=COMMAND 09:17:08 envir=COMMAND 6 *-* 'TEST PROCESS WAIT 5' L TEST PROCESS WAIT 5 +++ RC(-3) +++ 7 *-* say time()', rc='rc F 09:17:08 L , rc= O 09:17:08, rc= V -3 O 09:17:08, rc=-3 09:17:08, rc=-3 9 *-* address VMOPER 11 *-* say time() ' envir='address F 09:17:08 Lenvir= O 09:17:08 envir= F VMOPER O 09:17:08 envir=VMOPER 09:17:08 envir=VMOPER 12 *-* 'TEST PROCESS WAIT 5' L TEST PROCESS WAIT 5 13 *-* say time()', rc='rc F 09:17:13 L , rc= O 09:17:13, rc= V 0 O 09:17:13, rc=0 09:17:13, rc=0 14 *-* Exit 0 Note the 5 second delay between the messages at 09:17:08 and 09:17:13. See the VM:Operator Programming Guide for more details. And... welcome to the use of VM:Operator macros! Great stuff. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Kris Buelens kris.buel...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/08/2011 04:41 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: RACFVM: ICH520I You should better not place a CP SLEEP in VM:Operator scripts: it will make the whole VM operator go to wait, and when many message arrive for VM:operator while it waits, CP's IUCV queue could get full and CP will then throw them at the console, instead of presenting them to IUCV, where VM:Operator will find them. With other words: the extra messages are lost for VM:Operator's automation. Better is the code a REXX script in a file with type VMOPER, and then you can code TEST WAIT (if I remember well), that will put only that script in a wait state. Maybe the keyword to start a VMOPER differs from the keyword to start an EXEC. SPAWN comes in my mind. It's all a long time ago that I played with VM:Oper automatisation. 2011/3/8 Alain Benveniste a.benveni...@free.fr Kris You are right ICH520i appears before a CST and a RPI message. If i execute my vmoperator script on the last standard message format, It works. If I put a sleep in my script and execute it as soon as ich520i appears, it works. I think to open a pmr for this. Alain er well) Le 8 mars 2011 à 08:38, Kris Buelens kris.buel...@gmail.com a écrit : Alan, people using the VM:Operator software have it normally installed in the System Operator, so it is started before RACF comes up. He,ce it is indeed tempting to use a RACF message to start automated startup using VM:Operator scripts. 2011/3/8 Alan Altmark alan_altm...@us.ibm.com On Monday, 03/07/2011 at 11:10 EST, Alain Benveniste a.benveni...@free.fr wrote: ICH520I RACF x IS ACTIVE. Explanation: RACF release x has been successfully initialized. I removed xautolog autolog2 from raciplxi and I asked VM:Operator to autolog VMSERV* users prior to xautolog autolog2 when the message ICH520I is met. I got a HCP6525E External Security Manager is unavailable. ICH520I seems to lie ! :) It is in there so that we can catch people trying to cheat RACF and AUTOLOG2. The only virtual machines that are permitted to start prior to RACF are the SYSTEM_USERIDs from SYSTEM CONFIG (e.g. OPEREREP, OPERATOR, etc.). They run with their CP-given permissions until RACF is up. AUTOLOG2 should start VM:Operator, which can then bring up the rest of the system. If you want something a little cleaner: 1. Put SYSTEM_USERIDS STARTUP RACFVM in SYSTEM CONFIG 2. Change RACIPLXI EXEC to autolog AUTOLOG1. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM
Different data from CCW DATA READ as guest or native.
I see this descrepency between TPF native and TPF as a z/VM guest. Has anyone else seen this behavior? Is there any explaination? I have searched high and low, but can't find an answer. TPF as z/VM guest: ztest ccws 4000 64 CSMP0097I 10.24.33 CPU-A SS-BSS SSU-BSS IS-01 CCWS0001I 10.24.33 DISPLAY OF CCW DATA READ FROM 4000 64 READ DEVICE CHARACTERISTICS 3990E933 900CDA00 FEF62032 16A8000F -à E9 E000E5A2 05940222 13090674 32321502 DFEE0001 06770803 007F4A00 1B35 END OF CCWS DISPLAY+ TPF Native LPAR: ztest ccws 4000 64 CSMP0097I 10.24.48 CPU-A SS-BSS SSU-BSS IS-01 CCWS0001I 10.24.48 DISPLAY OF CCW DATA READ FROM 4000 64 READ DEVICE CHARACTERISTICS 3990EC33 900CD800 F0F62032 16A8000F -à EC E000E5A2 05940222 13090674 32320602 DFEE0001 06770803 007F4A00 1B35 END OF CCWS DISPLAY+
Re: Different data from CCW DATA READ as guest or native.
I'm new to the z/VM arena. I need a good place to start. I'm trying to send a file from z/VM via RSCS to z/OS JES spool. Can someone point me to a good starting place? I do have an RSCS connection between z/VM z/OS. When you display it, it shows active. Thanks Scott
Re: Sending files to JES
SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. Neale On 3/8/11 12:34 PM, David Boyes dbo...@sinenomine.net wrote: SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Different data from CCW DATA READ as guest or native.
It should show Connect rather than Active You have started the connection on the VM side, make sure the corresponding CTC on the MVS side is defined to MVS as BCTC if using ESCON and then start the MVS Line Also make sure that the RSCS definition for the JES NODE name matches and the buffer is the same side on both sides. Larry Davis From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Shumate, Scott Sent: Tuesday, March 08, 2011 11:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Different data from CCW DATA READ as guest or native. I'm new to the z/VM arena. I need a good place to start. I'm trying to send a file from z/VM via RSCS to z/OS JES spool. Can someone point me to a good starting place? I do have an RSCS connection between z/VM z/OS. When you display it, it shows active. Thanks Scott
Re: Sending files to JES
Also, Active means that the link has been started but the sign-on process has not been completed. The status must be Connect before a file can be transferred. Either JES has not started the link or there is a problem in the definition on either or both ends. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 08, 2011 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. Neale On 3/8/11 12:34 PM, David Boyes dbo...@sinenomine.net wrote: SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. The user part of the process is the same, though. In both cases, the file has to end up in RSCS' virtual reader; the transport between VM and z/OS is transparent to that process. If the z/OS system was running under the same VM instance, you'd just punch the file to the z/OS system userid after making sure the zOS system had a 2540 genned at address 00C and started in the JES startup proc. There you actually WANT the header, so you'd drop the NOH. If you wanted to skip the NJE part entirely, you can use FTP to send the job to the z/OS JES spool and retrieve your output (if your admin has enabled that service), but it's not nearly as nice as the NJE way.
Virtual Lock File
I have a SVM called VDISKS the creates and initializes a virtual lock file for four VSE guest to use. After a short time, VDISKS is logged off by the system. All is fine if at least one VSE remains logged on, however if all are logged off the virtual lock file goes away also. How can I keep VDISKS from being logged off by the system? * * * Top of File * * * USER VDISKS $SECRET$ 4M 4M BG 90 *NAME: VIRTUAL_DISKS ACCOUNT SYSTEMS SUPPORT COMMAND SET RUN ON IPL CMS MACH ESA XAUTOLOG AUTOLOG1 MAINT CONSOLE 0009 3215 T OPERATOR SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 0191 3390 499 001 PKSCMS MR ALL WRITE MULTIPLE MDISK 0222 FB-512 V-DISK 6208 MWV ALL *DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC20101121 CRCc PROFILE EXEC Z1 V 130 Trunc=130 Size=14 |...+1+2+3+4.. 0 * * * Top of File * * * 1 /* */ 2 'CP SPOOL CONSOLE START MAINT CLASS M' 3 Trace I 4 'EXECIO * CP (STRING Q' USERID() 5 PULL @RESPONSE 6 PARSE VAR @RESPONSE @USERID . @TERMID 7 IF @TERMID = 'DSC' THEN DO 8EXEC INITVDSK 9SLEEP 05 SEC 00010'CP SPOOL CONSOLE CLOSE' 00011EXIT 00012 END 00013 SET PF12 RETRIEVE 00014 EXIT 00015 * * * End of File * * * INITVDSK EXEC Z1 V 130 Trunc=130 Size=8 |...+1+2+3+4 0 * * * Top of File * * * 1 /* EXEC TO INITIALIZE ALL VDISKS*/ 2 Trace I 3 ERASE DSFOUT OUTPUT A 4 PUSH 'DSFOUT' 5 PUSH 'INITV222' 6 ICKDSF 7 'CP LINK * 222 222 RR' 8 EXIT 9 * * * End of File * * * INITV222 INPUTZ1 F 80 Trunc=80 Size=1 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6 0 * * * Top of File * * * 1 INIT UNIT(222) NVFY NOMAP PURGE VOLID(VSELOK) FBAVTOC(6200,8) 2 * * * End of File * * * Thank you, Scott R Wandschneider Systems Programmer 3|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** 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.
Re: Sending files to JES
He didn't specify it was a job. That opens a whole new can of worms: JCL, pswd etc. Les David Boyes wrote: Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. The user part of the process is the same, though. In both cases, the file has to end up in RSCS' virtual reader; the transport between VM and z/OS is transparent to that process. If the z/OS system was running under the same VM instance, you'd just punch the file to the z/OS system userid after making sure the zOS system had a 2540 genned at address 00C and started in the JES startup proc. There you actually WANT the header, so you'd drop the NOH. If you wanted to skip the NJE part entirely, you can use FTP to send the job to the z/OS JES spool and retrieve your output (if your admin has enabled that service), but it's not nearly as nice as the NJE way.
Re: Virtual Lock File
Scott, Try adding the following two (2) commands to your PROFILE EXEC -- CP SET RUN ON SET AUTOREAD OFF John P. Baker Chief Software Architect HFD Technologies -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Wandschneider, Scott Sent: Tuesday, March 08, 2011 12:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Virtual Lock File I have a SVM called VDISKS the creates and initializes a virtual lock file for four VSE guest to use. After a short time, VDISKS is logged off by the system. All is fine if at least one VSE remains logged on, however if all are logged off the virtual lock file goes away also. How can I keep VDISKS from being logged off by the system? * * * Top of File * * * USER VDISKS $SECRET$ 4M 4M BG 90 *NAME: VIRTUAL_DISKS ACCOUNT SYSTEMS SUPPORT COMMAND SET RUN ON IPL CMS MACH ESA XAUTOLOG AUTOLOG1 MAINT CONSOLE 0009 3215 T OPERATOR SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 0191 3390 499 001 PKSCMS MR ALL WRITE MULTIPLE MDISK 0222 FB-512 V-DISK 6208 MWV ALL *DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC20101121 CRCc PROFILE EXEC Z1 V 130 Trunc=130 Size=14 |...+1+2+3+4.. 0 * * * Top of File * * * 1 /* */ 2 'CP SPOOL CONSOLE START MAINT CLASS M' 3 Trace I 4 'EXECIO * CP (STRING Q' USERID() 5 PULL @RESPONSE 6 PARSE VAR @RESPONSE @USERID . @TERMID 7 IF @TERMID = 'DSC' THEN DO 8EXEC INITVDSK 9SLEEP 05 SEC 00010'CP SPOOL CONSOLE CLOSE' 00011EXIT 00012 END 00013 SET PF12 RETRIEVE 00014 EXIT 00015 * * * End of File * * * INITVDSK EXEC Z1 V 130 Trunc=130 Size=8 |...+1+2+3+4 0 * * * Top of File * * * 1 /* EXEC TO INITIALIZE ALL VDISKS*/ 2 Trace I 3 ERASE DSFOUT OUTPUT A 4 PUSH 'DSFOUT' 5 PUSH 'INITV222' 6 ICKDSF 7 'CP LINK * 222 222 RR' 8 EXIT 9 * * * End of File * * * INITV222 INPUTZ1 F 80 Trunc=80 Size=1 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6 0 * * * Top of File * * * 1 INIT UNIT(222) NVFY NOMAP PURGE VOLID(VSELOK) FBAVTOC(6200,8) 2 * * * End of File * * * Thank you, Scott R Wandschneider Systems Programmer 3|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly**
Re: Virtual Lock File
On 3/8/11 12:57 PM, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: I have a SVM called VDISKS the creates and initializes a virtual lock file for four VSE guest to use. After a short time, VDISKS is logged off by the system. All is fine if at least one VSE remains logged on, however if all are logged off the virtual lock file goes away also. How can I keep VDISKS from being logged off by the system? Simplest answer: have the VDISKS userid run PROP in it's PROFILE EXEC (see Running Guest Operating Systems Under VM manual for PROP setup). If you never send it any commands or anything to act on, the VDISKS users will take up almost no resources, and PROP's always there on the basic system. The theory here is that a creator of a VDISK has to stay logged in if you want the VDISK to survive the last user of the VDISK logging off. As you've observed, the userid creates the vdisk and then other users link it. If the creator logs off, but another user has the VDISK linked, then the VDISK survives until the last user linked to it logs off, then CP destroys it. In this case PROP is a simple way to keep the VDISKS userid logged in (thus protecting the VDISK from destruction because the creator is still logged on), but PROP is well behaved enough to pretty much take no resources at all if it's not being actively used.
Re: Sending files to JES
On 3/8/11 1:00 PM, Les Koehler vmr...@tampabay.rr.com wrote: He didn't specify it was a job. That opens a whole new can of worms: JCL, pswd etc. Not the problem of the NJE transport. It's just got to get the file from system A to system B. Content and payload correctness are left as an exercise to the sender. 8-)
Re: zLinux OS disk read-only
Hi Waheb, I do not have this PTF installed. Yes we are using HYPERPAV. We have shared DASD between our z/OS and z/VM LPARs. If I turn off HYPERPAV on my z/VM LPAR via the SET command, will that also turn off HYPERPAV effectively on the z/OS side for those volumes on that CU ? I don't want it to affect the z/OS side. If it does affect z/OS then my only option would be to apply the PTF. Thanks. Steve -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Boukhemis, Waheb Sent: Wednesday, March 02, 2011 8:57 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zLinux OS disk read-only Check if you have PTF UM32790 for z/VM540. It is on the 1002 RSU. Are you using HYPERPAV? If so, removing HYPERPAV volume use from your VM LPAR should resolve the problem. We had similar problem and the applying 1002 RSU service fixed it. Example: 1. Q CU 0039 PAVMODE If it is in any kind of PAV mode then: 2. SET CU NOPAV 0039 3. RUN your test. Hope this helps! Waheb Boukhemis McJunkin Red Man Corporation Email: waheb.boukhe...@mrcpvf.com Phone: +1-304-348-1588 Fax: +1-304-348-4902 Cell: +1-304-993-6070 www.MRCPVF.com -- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Steve Perez Sent: Tuesday, March 01, 2011 3:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: zLinux OS disk read-only Hello All, Has anyone run into a situation where the zLinux OS disk has become READ- ONLY access? We are running z/Linux under z/VM 5.4 Redhat 5.4. My zLinux Admin were doing compares between the production environment versus the Test D/R environment and noticed it. He issued the following on the prod zLinux guest environment: # mount -o remount,rw /dev/VolGroup01/LogVol00 mount: block device /dev/VolGroup01/LogVol00 is write-protected, mounting read-only Since we are testing our D/R process at the moment for the z/VM LPAR we are unsure at this point whether that is a contributing factor. It should not be but we can't rule it out. We paused our PPRC/Global mirroring from the z/OS side before starting the D/R activities to perform recovery of the z/VM z/Linux. The problem was found while in the middle of verifying/comparing environments on the zLinux side. I can link to the minidisk that is used to IPL that zLinux guest and it shows R/W when I issue Q LINKS. All other minidisks owned by that zLinux guest are R/W as well. From my perspective (z/VM) all looks good. Any input would be appreciated, if anything to rule out that PPRC/GM would have contributed to this. Thanks. Steve. ** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ** CLLD
NOT RSCS QUESTION..Different data from CCW DATA READ as guest or native.
-- Forwarded message -- From: Tom Huegel tehue...@gmail.com Date: Tue, Mar 8, 2011 at 8:48 AM Subject: Different data from CCW DATA READ as guest or native. To: The IBM z/VM Operating System IBMVM@listserv.uark.edu I see this descrepency between TPF native and TPF as a z/VM guest. Has anyone else seen this behavior? Is there any explaination? I have searched high and low, but can't find an answer. TPF as z/VM guest: ztest ccws 4000 64 CSMP0097I 10.24.33 CPU-A SS-BSS SSU-BSS IS-01 CCWS0001I 10.24.33 DISPLAY OF CCW DATA READ FROM 4000 64 READ DEVICE CHARACTERISTICS 3990E933 900CDA00 FEF62032 16A8000F -à E9 E000E5A2 05940222 13090674 32321502 DFEE0001 06770803 007F4A00 1B35 END OF CCWS DISPLAY+ TPF Native LPAR: ztest ccws 4000 64 CSMP0097I 10.24.48 CPU-A SS-BSS SSU-BSS IS-01 CCWS0001I 10.24.48 DISPLAY OF CCW DATA READ FROM 4000 64 READ DEVICE CHARACTERISTICS 3990EC33 900CD800 F0F62032 16A8000F -à EC E000E5A2 05940222 13090674 32320602 DFEE0001 06770803 007F4A00 1B35 END OF CCWS DISPLAY+
Re: Creating a Second IP Stack
Also risking the wrath of Chuckie, I can tell you what the person on IBMLink told me when I opened an ETR for this same request: I added my second stack to SYSTEM DTCPARMS: :nick.TCPIP2 :type.server :class.stack :attach.0C00-0C01 I created a TCPIP2 TCPIP file, which only does TN3270. It only has port 23 open and it has its own DEVICE and LINK for the non-QDIO port pair C00-C01 from our OSA-E, its own HOME address, but same mask and gateway handed down from the mount by the Network Gods. I created a TCPIP2 DATA file on 592 with the TCPIPUSERID set to TCPIP2. And its been running that way for a couple of years. I do use the TCP TCPIP2 option on NETSTAT commands. IIRC, the TCPIP person who led me through this was musing that they really should document how to do this in the manuals, since so many people ask the same question. I have not gone to look at the recent books. Ron On Sat, Mar 5, 2011 at 10:07 AM, Jeff Gribbin jeff.grib...@gmail.com wrote: Greetings, I may be a, 'VM-Oldie' but I'm most certainly a, 'TCP/IP Newbie' and, true to form, I'm already wishing to push the envelope a little ... I'm helping to maintain a not-very-busy z/VM system which is pretty-much starting from scratch and currently has no asociated SLA's or the such to worry about. It's not quite a sandpit, but pretty close. I access the system via TN3270 and, in order to allow me to perform surgery on the main TCP/IP stack (bog-standard vanilla configuration, straight out of the box), I'm looking to place a second IP stack alongside the primary stack that will give me at-least a TN3270, 'back door' into the system. My, 'problem' is TCPIP DATA, which appears to be a unique filename. 'TCP/IP Planning and Customization' states quite categorically that TCPIP DATA defines parameters used by TCPIP -client- applications. If this is truly the case then it would seem that all I need in order to implement a second stack purely for TN3270 purposes is to create appropriate 'userid DTCPARMS' and 'userid TCPIP' files on TCPMAINT's 0198 and I'm away. Would I be correct in thinking that TCPIP DATA is, 'merely' read by the, 'client' commands in order (e.g.) to locate the servers that they need to interact with. If this is so, would it be acceptable practise (that is, behaviour that would not bring the Wrath of Chuckie upon me) to keep a second copy of TCPIP DATA, configured according to the userid(s) of the second stack, on a separate minidisk and access that minidisk in front of TCPMAINT's 592 when wishing to, 'converse' with the second stack? (For example, in order to issue a NETSTAT command without needing to specify the, 'TCP' option every time.) I can, of course, discover most of this empirically for myself - and will indeed be experimenting a little (what else to do on a wet Saturday afternoon?) - but if for no other reason that the Fear of Chuckie I would be reassured if somebody with more experience were willing to sanity-check my hypothesis and proposed, 'solution'. Thanks Jeff
Hillgang Meeting
The next meeting of the DC z/VM Linux User Group ³HILLGANG² will take place on March 16 at the CA offices in Herndon, VA. The meeting details may be found here: http://www.vm.ibm.com/events/hill0316.pdf Follow the directions in that document to RSVP. Neale
Re: Virtual Lock File
Our VSE lock file mdisk belongs to OPERATOR, which runs PROP and is disconnected shortly after IPL. All VSE guests tests the lock file in their PROFILE EXEC and if it needs to be initialized, does it. So any guest can come up first and set up the lock file. All OPERATOR does is have the mdisk entry in the DIRECT. On Tue, Mar 8, 2011 at 12:05 PM, David Boyes dbo...@sinenomine.net wrote: On 3/8/11 12:57 PM, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: I have a SVM called VDISKS the creates and initializes a virtual lock file for four VSE guest to use. After a short time, VDISKS is logged off by the system. All is fine if at least one VSE remains logged on, however if all are logged off the virtual lock file goes away also. How can I keep VDISKS from being logged off by the system? Simplest answer: have the VDISKS userid run PROP in it's PROFILE EXEC (see Running Guest Operating Systems Under VM manual for PROP setup). If you never send it any commands or anything to act on, the VDISKS users will take up almost no resources, and PROP's always there on the basic system. The theory here is that a creator of a VDISK has to stay logged in if you want the VDISK to survive the last user of the VDISK logging off. As you've observed, the userid creates the vdisk and then other users link it. If the creator logs off, but another user has the VDISK linked, then the VDISK survives until the last user linked to it logs off, then CP destroys it. In this case PROP is a simple way to keep the VDISKS userid logged in (thus protecting the VDISK from destruction because the creator is still logged on), but PROP is well behaved enough to pretty much take no resources at all if it's not being actively used.
Re: Creating a Second IP Stack
On 3/8/11 1:27 PM, Ron Schmiedge ron.schmie...@gmail.com wrote: IIRC, the TCPIP person who led me through this was musing that they really should document how to do this in the manuals, since so many people ask the same question. I have not gone to look at the recent books. Would be a nice redbook-like thing -- something like A Practical Cookbook of Networking Tasks for VM TCPIP. Adding things like getting a caching DNS server running, setting up FTP servers with RACF and other ESMs, configuring SMTP to forward all outgoing mail to a corporate gateway, etc, etc. I'll see if we can write something up. -- db
Re: Sending files to JES
That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? Thanks Scott From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of David Boyes Sent: Tuesday, March 08, 2011 12:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Different data from CCW DATA READ as guest or native.
On Tuesday, 03/08/2011 at 11:50 EST, Tom Huegel tehue...@gmail.com wrote: I see this descrepency between TPF native and TPF as a z/VM guest. Has anyone else seen this behavior? Is there any explaination? I have searched high and low, but can't find an answer. TPF as z/VM guest: 3990E933 900CDA00 FEF62032 16A8000F TPF Native LPAR: 3990EC33 900CD800 F0F62032 16A8000F What you are seeing is z/VM's simulation of a 3990 control unit mode when (1) A 2105 or 2107 storage controller is being used, and (2) The guest OS has not indicated that it understands 2105 or 2107 CU mode. Under those conditions, CP will simulate a 3990 in enhanced operation mode. It's the same thing the 2105/2107 does. I think the only difference is the length of path status on a PERFORM SUBSYSTEM FUNCTION: READ SUBSYSTEM DATA operation, the output of which is irrelevant to 2105/2107s anyway. Is this an academic question as a result of late-night studying of responses to CCWs? Or is there an issue? :-) Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Sending files to JES
On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Sending files to JES
Hi, Scott. The file you are trying to send is not too big, its record length exceeds what the PUNCH command supports. The maximum record length for the PUNCH command is 80 bytes. If what you are trying to send to z/OS (via RSCS) is a JCL file, make sure its lrecl is 80 and its recfm is fixed. Have a good one. DJ On 3/8/2011 12:56 PM, Shumate, Scott wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? Thanks Scott *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On Behalf Of *David Boyes *Sent:* Tuesday, March 08, 2011 12:34 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: Sending files to JES SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Virtual Lock File
I simply use this (at the end of the PROFILE EXEC for the user that owns the VDISKS): Do forever Say Staying alive, staying alive(99 hours)... CP SLEEP 99 HRS End Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Wandschneider, Scott Sent: Tuesday, March 08, 2011 11:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Virtual Lock File I have a SVM called VDISKS the creates and initializes a virtual lock file for four VSE guest to use. After a short time, VDISKS is logged off by the system. All is fine if at least one VSE remains logged on, however if all are logged off the virtual lock file goes away also. How can I keep VDISKS from being logged off by the system? * * * Top of File * * * USER VDISKS $SECRET$ 4M 4M BG 90 *NAME: VIRTUAL_DISKS ACCOUNT SYSTEMS SUPPORT COMMAND SET RUN ON IPL CMS MACH ESA XAUTOLOG AUTOLOG1 MAINT CONSOLE 0009 3215 T OPERATOR SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 0191 3390 499 001 PKSCMS MR ALL WRITE MULTIPLE MDISK 0222 FB-512 V-DISK 6208 MWV ALL *DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC20101121 CRCc PROFILE EXEC Z1 V 130 Trunc=130 Size=14 |...+1+2+3+4.. 0 * * * Top of File * * * 1 /* */ 2 'CP SPOOL CONSOLE START MAINT CLASS M' 3 Trace I 4 'EXECIO * CP (STRING Q' USERID() 5 PULL @RESPONSE 6 PARSE VAR @RESPONSE @USERID . @TERMID 7 IF @TERMID = 'DSC' THEN DO 8EXEC INITVDSK 9SLEEP 05 SEC 00010'CP SPOOL CONSOLE CLOSE' 00011EXIT 00012 END 00013 SET PF12 RETRIEVE 00014 EXIT 00015 * * * End of File * * * INITVDSK EXEC Z1 V 130 Trunc=130 Size=8 |...+1+2+3+4 0 * * * Top of File * * * 1 /* EXEC TO INITIALIZE ALL VDISKS*/ 2 Trace I 3 ERASE DSFOUT OUTPUT A 4 PUSH 'DSFOUT' 5 PUSH 'INITV222' 6 ICKDSF 7 'CP LINK * 222 222 RR' 8 EXIT 9 * * * End of File * * * INITV222 INPUTZ1 F 80 Trunc=80 Size=1 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6 0 * * * Top of File * * * 1 INIT UNIT(222) NVFY NOMAP PURGE VOLID(VSELOK) FBAVTOC(6200,8) 2 * * * End of File * * * Thank you, Scott R Wandschneider Systems Programmer 3|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** 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. _ This message contains information which is privileged and confidential and is solely for the
Re: Sending files to JES
Why not FTP it? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Shumate, Scott Sent: Tuesday, March 08, 2011 1:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Sending files to JES
Eventually you are going to find that files contain so many records (perhaps some with very large LRECLs) that using SENDFILE is no longer productive. Not only that, but SENDFILE (aka TRANSMIT or XMIT on TSO) and RECEIVE have significant CPU overhead, as they have to break wide files into files with records that can squeeze through your narrow 80-byte wide virtual punch, and then be reconstructed by RECEIVE at the target destination. FTP will do the trick, but it's difficult to script, and to handle bad return codes, etc. Download the free VMFTP package and you'll be on the way. The VMFTP package can be obtained from: Fran Hensler's excellent Slippery Rock University FTP site with the most recent updates as of 2009-03-13 at: http://zvm.sru.edu/~DOWNLOAD/ Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Shumate, Scott scshum...@bbandt.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/08/2011 01:15 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Sending files to JES I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Sending files to JES
Use the VM SENDFILE command: SENDFILE fn ft fm TO user AT zos On the z.OS side, use the TSO RECEIVE command to receive the file. SENDFILE takes the original file and encodes it to fit into a series of 80 byte cards, carrying enough metadata to reassemble the file in it's original form on the receiving system. This intermediate format (called NETDATA in the the NJE spec) is sent through the NJE network to the receiving system and is placed in spool. The RECEIVE command (both on VM and TSO) reads the file from spool, looks at the first 3 or 4 records and detects a flag that says I'm in NETDATA format. If that flag is present, RECEIVE reassembles the file to the original format and puts into the file you specified on the RECEIVE command. This approach might work for jobs too — older z/OS systems didn't understand NETDATA for jobs, so I gave you the VM Classic approach for that. I think newer z/Oses might understand it now; but… Jobs still have to be virtual cards on VM… Note if you have NJE code installed on your Suns or Linuxen, etc, this works great for dispatching work on them too….
Re: Different data from CCW DATA READ as guest or native.
Thanks Alan, It is an issue -when tpf sees an 3990EC – is sees the volume as a control unit that supports TPF record cache. When it sees the volume as 3990E9, TPF marks the control unit as not supporting record cache and several tpf functions are then not available. Tom On Tue, Mar 8, 2011 at 11:03 AM, Alan Altmark alan_altm...@us.ibm.comwrote: On Tuesday, 03/08/2011 at 11:50 EST, Tom Huegel tehue...@gmail.com wrote: I see this descrepency between TPF native and TPF as a z/VM guest. Has anyone else seen this behavior? Is there any explaination? I have searched high and low, but can't find an answer. TPF as z/VM guest: 3990E933 900CDA00 FEF62032 16A8000F TPF Native LPAR: 3990EC33 900CD800 F0F62032 16A8000F What you are seeing is z/VM's simulation of a 3990 control unit mode when (1) A 2105 or 2107 storage controller is being used, and (2) The guest OS has not indicated that it understands 2105 or 2107 CU mode. Under those conditions, CP will simulate a 3990 in enhanced operation mode. It's the same thing the 2105/2107 does. I think the only difference is the length of path status on a PERFORM SUBSYSTEM FUNCTION: READ SUBSYSTEM DATA operation, the output of which is irrelevant to 2105/2107s anyway. Is this an academic question as a result of late-night studying of responses to CCWs? Or is there an issue? :-) Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Sending files to JES
On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script
Re: zLinux OS disk read-only
Steve, I am afraid so! I think it will affect the z/OS DASD on the same CU. In our case, it worked out well because all our DASD for z/VM is the on same CU. Waheb Waheb Boukhemis McJunkin Red Man Corporation Email: waheb.boukhe...@mrcpvf.com Phone: +1-304-348-1588 Fax: +1-304-348-4902 Cell: +1-304-993-6070 www.MRCPVF.com -- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Perez, Steve S Sent: Tuesday, March 08, 2011 1:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zLinux OS disk read-only Hi Waheb, I do not have this PTF installed. Yes we are using HYPERPAV. We have shared DASD between our z/OS and z/VM LPARs. If I turn off HYPERPAV on my z/VM LPAR via the SET command, will that also turn off HYPERPAV effectively on the z/OS side for those volumes on that CU ? I don't want it to affect the z/OS side. If it does affect z/OS then my only option would be to apply the PTF. Thanks. Steve -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Boukhemis, Waheb Sent: Wednesday, March 02, 2011 8:57 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zLinux OS disk read-only Check if you have PTF UM32790 for z/VM540. It is on the 1002 RSU. Are you using HYPERPAV? If so, removing HYPERPAV volume use from your VM LPAR should resolve the problem. We had similar problem and the applying 1002 RSU service fixed it. Example: 1. Q CU 0039 PAVMODE If it is in any kind of PAV mode then: 2. SET CU NOPAV 0039 3. RUN your test. Hope this helps! Waheb Boukhemis McJunkin Red Man Corporation Email: waheb.boukhe...@mrcpvf.com Phone: +1-304-348-1588 Fax: +1-304-348-4902 Cell: +1-304-993-6070 www.MRCPVF.com -- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Steve Perez Sent: Tuesday, March 01, 2011 3:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: zLinux OS disk read-only Hello All, Has anyone run into a situation where the zLinux OS disk has become READ- ONLY access? We are running z/Linux under z/VM 5.4 Redhat 5.4. My zLinux Admin were doing compares between the production environment versus the Test D/R environment and noticed it. He issued the following on the prod zLinux guest environment: # mount -o remount,rw /dev/VolGroup01/LogVol00 mount: block device /dev/VolGroup01/LogVol00 is write-protected, mounting read-only Since we are testing our D/R process at the moment for the z/VM LPAR we are unsure at this point whether that is a contributing factor. It should not be but we can't rule it out. We paused our PPRC/Global mirroring from the z/OS side before starting the D/R activities to perform recovery of the z/VM z/Linux. The problem was found while in the middle of verifying/comparing environments on the zLinux side. I can link to the minidisk that is used to IPL that zLinux guest and it shows R/W when I issue Q LINKS. All other minidisks owned by that zLinux guest are R/W as well. From my perspective (z/VM) all looks good. Any input would be appreciated, if anything to rule out that PPRC/GM would have contributed to this. Thanks. Steve. ** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ** CLLD
Re: Virtual Lock File
Each of our VM systems had a minidisk on a shared pack (with CSE) that we used to test of the target VM system was still up. To assure there was always some LINK to this minidisk, we had it linked by quite a few service machines (VMUTIL, RSCS, Operator, etc). The chance that all of these service machines would be logged off at the same time were pretty small. You could do something similar. 2011/3/8 Frank M. Ramaekers framaek...@ailife.com I simply use this (at the end of the PROFILE EXEC for the user that owns the VDISKS): Do forever Say Staying alive, staying alive(99 hours)... CP SLEEP 99 HRS End Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Wandschneider, Scott Sent: Tuesday, March 08, 2011 11:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Virtual Lock File I have a SVM called VDISKS the creates and initializes a virtual lock file for four VSE guest to use. After a short time, VDISKS is logged off by the system. All is fine if at least one VSE remains logged on, however if all are logged off the virtual lock file goes away also. How can I keep VDISKS from being logged off by the system? * * * Top of File * * * USER VDISKS $SECRET$ 4M 4M BG 90 *NAME: VIRTUAL_DISKS ACCOUNT SYSTEMS SUPPORT COMMAND SET RUN ON IPL CMS MACH ESA XAUTOLOG AUTOLOG1 MAINT CONSOLE 0009 3215 T OPERATOR SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 0191 3390 499 001 PKSCMS MR ALL WRITE MULTIPLE MDISK 0222 FB-512 V-DISK 6208 MWV ALL *DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC20101121 CRCc PROFILE EXEC Z1 V 130 Trunc=130 Size=14 |...+1+2+3+4.. 0 * * * Top of File * * * 1 /* */ 2 'CP SPOOL CONSOLE START MAINT CLASS M' 3 Trace I 4 'EXECIO * CP (STRING Q' USERID() 5 PULL @RESPONSE 6 PARSE VAR @RESPONSE @USERID . @TERMID 7 IF @TERMID = 'DSC' THEN DO 8EXEC INITVDSK 9SLEEP 05 SEC 00010'CP SPOOL CONSOLE CLOSE' 00011EXIT 00012 END 00013 SET PF12 RETRIEVE 00014 EXIT 00015 * * * End of File * * * INITVDSK EXEC Z1 V 130 Trunc=130 Size=8 |...+1+2+3+4 0 * * * Top of File * * * 1 /* EXEC TO INITIALIZE ALL VDISKS*/ 2 Trace I 3 ERASE DSFOUT OUTPUT A 4 PUSH 'DSFOUT' 5 PUSH 'INITV222' 6 ICKDSF 7 'CP LINK * 222 222 RR' 8 EXIT 9 * * * End of File * * * INITV222 INPUTZ1 F 80 Trunc=80 Size=1 Line=0 Col=1 Alt=0 |...+1+2+3+4+5+6 0 * * * Top of File * * * 1 INIT UNIT(222) NVFY NOMAP PURGE VOLID(VSELOK) FBAVTOC(6200,8) 2 * * * End of File * * * Thank you, Scott R Wandschneider Systems Programmer 3|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| : 402.963.8905 || :847.849.7223 || : scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** 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. _ 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. -- Kris Buelens, IBM Belgium, VM customer support
Re: Sending files to JES
On our VM systems, we had some processes that sent a CMS file embedded in an MVS job. The MVS job started TSO in batch to receive the file. At last that single job could carry multiple CMS files. As a result, the REXX code became less than easy to read for beginners. I can dig that up, on condition that the receiver is prepared to unravel that a bit (I'm convinced I already sent that once to someone). 2011/3/8 David Boyes dbo...@sinenomine.net On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script -- Kris Buelens, IBM Belgium, VM customer support
Re: Sending files to JES
That would be great. Can I take a look at it? Thanks Scott From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Kris Buelens Sent: Tuesday, March 08, 2011 3:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On our VM systems, we had some processes that sent a CMS file embedded in an MVS job. The MVS job started TSO in batch to receive the file. At last that single job could carry multiple CMS files. As a result, the REXX code became less than easy to read for beginners. I can dig that up, on condition that the receiver is prepared to unravel that a bit (I'm convinced I already sent that once to someone). 2011/3/8 David Boyes dbo...@sinenomine.net On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script -- Kris Buelens, IBM Belgium, VM customer support
Re: Sending files to JES
I got the send file to work. I can receive it from the spool on z/OS side. Thanks for everyone's help. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Tuesday, March 08, 2011 2:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES Eventually you are going to find that files contain so many records (perhaps some with very large LRECLs) that using SENDFILE is no longer productive. Not only that, but SENDFILE (aka TRANSMIT or XMIT on TSO) and RECEIVE have significant CPU overhead, as they have to break wide files into files with records that can squeeze through your narrow 80-byte wide virtual punch, and then be reconstructed by RECEIVE at the target destination. FTP will do the trick, but it's difficult to script, and to handle bad return codes, etc. Download the free VMFTP package and you'll be on the way. The VMFTP package can be obtained from: Fran Hensler's excellent Slippery Rock University FTP site with the most recent updates as of 2009-03-13 at: http://zvm.sru.edu/~DOWNLOAD/ Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Shumate, Scott scshum...@bbandt.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/08/2011 01:15 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Sending files to JES I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Different data from CCW DATA READ as guest or native.
On Tuesday, 03/08/2011 at 02:42 EST, Tom Huegel tehue...@gmail.com wrote: It is an issue -when tpf sees an 3990EC ? is sees the volume as a control unit that supports TPF record cache. When it sees the volume as 3990E9, TPF marks the control unit as not supporting record cache and several tpf functions are then not available. Please contact the Support Center. CP may need to be sensitive to the TPF Mode state before choosing the CU type. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Writing a Systems Programmer Resume
I would really like to get a copy ! THANKS ! rpa...@tad.org or bubba...@embarqmail.com -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Joe Gallaher Sent: Tuesday, March 08, 2011 4:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Writing a Systems Programmer Resume RE: http://share.confex.com/share/116/webprogram/Session8903.html I sent sent out my Anaheim SHARE powerpoint slides today to everyone who requested them. Since there were quite a few, I could have missed somebo= dy. If you did not get them, or would like them, please let me know. Joe j...@spci.net 323-822-1569
Re: Writing a Systems Programmer Resume
Joe, I would also like a copy. Thank you, Dave Dave Hansen Eagan Software Systems Branch 651-406-1208 dave.l.han...@usps.gov Dave Hansen -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Robert Payne Sent: Tuesday, March 08, 2011 4:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Writing a Systems Programmer Resume I would really like to get a copy ! THANKS ! rpa...@tad.org or bubba...@embarqmail.com -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Joe Gallaher Sent: Tuesday, March 08, 2011 4:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Writing a Systems Programmer Resume RE: http://share.confex.com/share/116/webprogram/Session8903.html I sent sent out my Anaheim SHARE powerpoint slides today to everyone who requested them. Since there were quite a few, I could have missed somebo= dy. If you did not get them, or would like them, please let me know. Joe j...@spci.net 323-822-1569
Re: Writing a Systems Programmer Resume
Indeed. I just polished off my resume. Chris has it, so I guess he didn't think I needed to see your presentation. But if it's no trouble, I would like to see what tips you have that might improve the rascal. And thanks for SHARing. :-) On Tue, Mar 8, 2011 at 5:33 PM, Joe Gallaher j...@spci.net wrote: RE: http://share.confex.com/share/116/webprogram/Session8903.html I sent sent out my Anaheim SHARE powerpoint slides today to everyone who requested them. Since there were quite a few, I could have missed somebody. If you did not get them, or would like them, please let me know. Joe j...@spci.net 323-822-1569 On Tue, 22 Feb 2011 09:39:46 -0600, Joe Gallaher j...@spci.net wrote: I would like to invite anyone attending next week's SHARE conference in Anaheim to come to my session on How to Write a Resume for a Mainframe Systems Programmer (session 8903). It is the third time I have given this presentation at SHARE and it contains a lot of useful information and samples for the aspiring resume writer. Here is a link to my session: http://share.confex.com/share/116/webprogram/Session8903.html If you cannot attend, feel free to send me an email (or LinkedIn message) and I will send you a link to my PowerPoint slides (which will be available after Feb. 28). I look forward to seeing you Monday! Joe Gallaher j...@spci.net www.SPCI.net www.linkedin.com/in/joegallaher 323-822-1569
Is Inter-CP Quiesce time counted as CPU time?
If a z/VM guest partially or completely purges the TLB on a z10 or z196, is the time required to quiesce CPs to coordinate the requested purge counted toward total CPU time for the guest requesting the purge? If so does the guest requesting the purge get tagged for all the CPU time required to coordinate purge operations across all CPs for the z/VM or is the time apportioned by CP to the specific guest active on each CP at the time the purge was requested? If the time isn¹t counted toward CPU time for the guest requesting the purge, how is that allocated? Thanks --. .- .-. -.-- Gary Dennis required for the purge
Re: Is Inter-CP Quiesce time counted as CPU time?
On Tuesday, 03/08/2011 at 06:14 EST, Gary M. Dennis gary.den...@mantissa.com wrote: If a z/VM guest partially or completely purges the TLB on a z10 or z196, is the time required to quiesce CPs to coordinate the requested purge counted toward total CPU time for the guest requesting the purge? If so does the guest requesting the purge get tagged for all the CPU time required to coordinate purge operations across all CPs for the z/VM or is the time apportioned by CP to the specific guest active on each CP at the time the purge was requested? If the time isn?t counted toward CPU time for the guest requesting the purge, how is that allocated? When a guest causes that to happen, the the instruction that triggered it will be victimized by it as well. That means the instruction takes longer. Likewise, all the other CPUs within the LPAR will serialize and the instructions they are running take longer. So everyone else is penalized. The bottom line is that the CPU timer does not stop ticking just because the TLB has been purged. Instructions running in other LPARs are not affected since they don't access the same blocks of memory. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Creating a Second IP Stack
On Tuesday, 03/08/2011 at 01:27 EST, Ron Schmiedge ron.schmie...@gmail.com wrote: Also risking the wrath of Chuckie, I can tell you what the person on IBMLink told me when I opened an ETR for this same request: I added my second stack to SYSTEM DTCPARMS: :nick.TCPIP2 :type.server :class.stack :attach.0C00-0C01 Good. I created a TCPIP2 TCPIP file, which only does TN3270. It only has port 23 open and it has its own DEVICE and LINK for the non-QDIO port pair C00-C01 from our OSA-E, its own HOME address, but same mask and gateway handed down from the mount by the Network Gods. Good. I created a TCPIP2 DATA file on 592 with the TCPIPUSERID set to TCPIP2. OK, but it's just taking up space since there is nothing to tell the socket functions to read TCPIP2 DATA. Perhaps your TCPRUNXT is copying TCPIP DATA to the A-disk, overriding values with information from TCPIP2 DATA? And its been running that way for a couple of years. I do use the TCP TCPIP2 option on NETSTAT commands. The TCP operand overrides what is found in TCPIP DATA. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
