Re: USER FORCE/Logoff pending
Figure out which device(s) are responsible (usually tape drives, but could be OSA). Then issue multiple (often, 10 or more are required) HALT commands for those devices. If tape drives, re-IML the unit. David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@listserv.uark.edu] On Behalf Of Shahin.Suleiman Sent: Monday, May 02, 2011 1:33 AM To: IBMVM@listserv.uark.edu Subject: USER FORCE/Logoff pending Hello Geeks I have a VSE Guest refusing to come down with logoff pending. Ideas.. Please! Suleiman Shahin Systems Programmer (386) 447 2552 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: USER FORCE/Logoff pending
Thanks David, It probably is an OSA. The machine is up now but with connection errors. Suleiman Shahin Systems Programmer (386) 447 2552 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Wakser, David Sent: Monday, May 02, 2011 5:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: USER FORCE/Logoff pending
Re: USER FORCE/Logoff pending
Try varying off (and then back on, in the opposite order) the devices, path, and CHPID - I believe that will reset the physical device. David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@listserv.uark.edu] On Behalf Of Shahin.Suleiman Sent: Monday, May 02, 2011 5:19 AM To: IBMVM@listserv.uark.edu Subject: Re: USER FORCE/Logoff pending Thanks David, It probably is an OSA. The machine is up now but with connection errors. Suleiman Shahin Systems Programmer (386) 447 2552 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Wakser, David Sent: Monday, May 02, 2011 5:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: USER FORCE/Logoff pending 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: USER FORCE/Logoff pending
At this time the suspect is network connection between the 2096 and other devices. I'll wait to hear their verdict then try if still a problem. Thanks. Suleiman Shahin Systems Programmer (386) 447 2552
Re: USER FORCE/Logoff pending
I tried varying the chpid off and had no response and my userid is hung. The chpid feeds a controller that someone just powered off. Suleiman Shahin Systems Programmer
Re: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
Hi, Sorry for my late response. Thanks Stephen, Les and Mike for responding! Yes, there were two linked disks that had the same exec along with the A disk where it was present too. When I remove one of the disks, it works fine. But we have had this setup for a long time i.e. apart from A disk, we have a test code disk and production code disk linked to this server. So not sure why it's happenin g now. A new thing that has happened and that I haven't mentioned so far is that earlier the rexx codes were run using rexx interpretor and now it has compiled versions on the two linked disks except A disk where it is still non-compiled version. But if I remove the non-compiled version from A disk, it still fails. I a m reluctant to conclude that its due to the compiled rexx as the same is working in other vmserve servers. Regards, Amar On Tue, 19 Apr 2011 10:02:35 -0500, Mike Walter mike.wal...@aonhewitt.co m wrote: Amar, Could you logon to the service machine running VMSERVE, stop VMSERVE, an d then run the command that was running when you experienced the failure? If it still fails the same way, you will evidence that VMSERVE is not causing the problem, and can look elsewhere. An alternative if you don't want to stop VMSERVE: from another ID, link to all the disks that VMSERVE has accessed and run the same failing command. If the same failure occurs, you can diagnose, correct, and test the solution with affecting VMSERVE, then move the fix into production. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Amar Moh amar_...@yahoo.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/19/2011 06:09 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Error : DMSITS135S Maximum SVC depth 200 has been exceeded Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CM S system. Recently, it started giving this error every time we make a program run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes an d ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SVCs to exceed ''. But not sure what can be done to fix this. Regards, Amar 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-mail s 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 deem ed to have accepted these risks if you communicate with us by e-mail. =
Re: Duplicate IPs on VSWITCHes - Feature or Defect
Are these layer 2 or layer 3? If layer 2, then they are (and should be) paying zero attention to the IP address. Layer 2 cares only about MAC addresses. Layer 3 is more subtle. Technically a real switch should attempt only to insert the address in the forwarding table and then the latest entry wins (eg it should eject the previously registered host as ARP entries expire in the communicating guests with cached info about IP to MAC mappings). So, I'd say that if you are using layer 2 switches, it is neither a bug nor a feature. It's working correctly, and it's your problem to avoid this situation. In the layer 3 case, it's arguably doing the right thing, but there is a case for it dropping the first registration when a new host registers the same address. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mark Wheeler Sent: Friday, April 29, 2011 3:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate IPs on VSWITCHes - Feature or Defect Greetings all, We've been pulling our hair out for several days trying to figure out a networking issue involving VSWITCHes. A server (LNXA1) attached to VSWITCHA on VMSYSA can connect to a server (LNXB1) attached to VSWITCHB on VMSYSB but a server (LNXC1) attached to VSWITCHC on VMSYSC cannot. We moved LNXC1 to VSWITCHA on VMSYSA and it worked. All on the same subnet, BTW. Unbeknownst to us, a server (LNXC2) had an interface on VSWITCHC that used the same IP as LNXA1. It couldn't be registered to the outside network because it was already being used, yet it was still registered to VSWITCHC. Hence, anyone else on VSWITCHC would try to connect to LNXC2 when it in fact was trying to connect to LNXA1. Q VSWITCH VSWITCHC DETAILS shows the duplicate IP, identifiable by the Local designation under the list of unicast IP address(es). The VSWITCH is able to detect the fact that this is a duplicate IP. Is this a feature or a defect? Should VSWITCHC drop the IP address when it identifies the duplicate situation? What would a real switch do? Best regards, Mark Wheeler UnitedHealth Group -- Excellence. Always. If Not Excellence, What? If Not Excellence Now, When? Tom Peters, author of The Little BIG Things
Re: Duplicate IPs on VSWITCHes - Feature or Defect
David, They're layer 3. The situation is that the IPs were registered on one VSWITCH, and passed on to real switches in the external network. Later, another host registered the same IPs on a different VSWITCH, which failed to pass them on to the external network (rejected because they were dups). The 2nd VSWITCH detected this error, but retained the IPs (for itself) anyway. The question is whether the 2nd VSWITCH should have retained them given it knew they were dups. Mark Date: Mon, 2 May 2011 10:32:30 -0500 From: dbo...@sinenomine.net Subject: Re: Duplicate IPs on VSWITCHes - Feature or Defect To: IBMVM@LISTSERV.UARK.EDU Are these layer 2 or layer 3? If layer 2, then they are (and should be) paying zero attention to the IP address. Layer 2 cares only about MAC addresses. Layer 3 is more subtle. Technically a real switch should attempt only to insert the address in the forwarding table and then the latest entry wins (eg it should eject the previously registered host as ARP entries expire in the communicating guests with cached info about IP to MAC mappings). So, I’d say that if you are using layer 2 switches, it is neither a bug nor a feature. It’s working correctly, and it’s your problem to avoid this situation. In the layer 3 case, it’s arguably doing the right thing, but there is a case for it dropping the first registration when a new host registers the same address.
Re: Duplicate IPs on VSWITCHes - Feature or Defect
The situation is that the IPs were registered on one VSWITCH, and passed on to real switches in the external network. Later, another host registered the same IPs on a different VSWITCH, which failed to pass them on to the external network (rejected because they were dups). The 2nd VSWITCH detected this error, but retained the IPs (for itself) anyway. The question is whether the 2nd VSWITCH should have retained them given it knew they were dups. I'd argue yes, because the VSWITCH has no way to determine that they are already registered in another switch. There's no existing network protocol to communicate that information between the two switches (nothing like ISL or 802.1q for layer 3). The two VSWITCHes are two separate entities that can't know that the address is already registered elsewhere. Switch to layer 2 if/when you can. It simplifies a lot of things.
Re: Duplicate IPs on VSWITCHes - Feature or Defect
On the 1st VSWITCH, Q VSWITCH ... DETAILS shows: Unicast IP Addresses: snip x.y.z.161MAC: 02-00-00-00-00-3D x.y.z.162MAC: 02-00-00-00-00-3D x.y.z.163MAC: 02-00-00-00-00-3D x.y.z.164MAC: 02-00-00-00-00-3D snip On the 2nd VSWITCH... Unicast IP Addresses: snip x.y.z.161MAC: 02-00-00-00-00-60 Local x.y.z.162MAC: 02-00-00-00-00-60 Local x.y.z.165MAC: 02-00-00-00-00-60 x.y.z.166MAC: 02-00-00-00-00-60 snip It appears that SOMEHOW the 2nd VSWITCH knows that .161 and .162 are dups. Date: Mon, 2 May 2011 10:53:54 -0500 From: dbo...@sinenomine.net Subject: Re: Duplicate IPs on VSWITCHes - Feature or Defect To: IBMVM@LISTSERV.UARK.EDU The situation is that the IPs were registered on one VSWITCH, and passed on to real switches in the external network. Later, another host registered the same IPs on a different VSWITCH, which failed to pass them on to the external network (rejected because they were dups). The 2nd VSWITCH detected this error, but retained the IPs (for itself) anyway. The question is whether the 2nd VSWITCH should have retained them given it knew they were dups. I’d argue yes, because the VSWITCH has no way to determine that they are already registered in another switch. There’s no existing network protocol to communicate that information between the two switches (nothing like ISL or 802.1q for layer 3). The two VSWITCHes are two separate entities that can’t know that the address is already registered elsewhere. Switch to layer 2 if/when you can. It simplifies a lot of things.
Re: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
Isn't this simply an EXEC that calls itself over over again. Or, dirty execs that do not use ADDRESS COMMAND and by accident call an EXEC instead of the built-in CMS command. 2011/5/2 Amar Moh amar_...@yahoo.com Hi, Sorry for my late response. Thanks Stephen, Les and Mike for responding! Yes, there were two linked disks that had the same exec along with the A disk where it was present too. When I remove one of the disks, it works fine. But we have had this setup for a long time i.e. apart from A disk, we have a test code disk and production code disk linked to this server. So not sure why it's happening now. A new thing that has happened and that I haven't mentioned so far is that earlier the rexx codes were run using rexx interpretor and now it has compiled versions on the two linked disks except A disk where it is still non-compiled version. But if I remove the non-compiled version from A disk, it still fails. I am reluctant to conclude that its due to the compiled rexx as the same is working in other vmserve servers. Regards, Amar On Tue, 19 Apr 2011 10:02:35 -0500, Mike Walter mike.wal...@aonhewitt.com wrote: Amar, Could you logon to the service machine running VMSERVE, stop VMSERVE, and then run the command that was running when you experienced the failure? If it still fails the same way, you will evidence that VMSERVE is not causing the problem, and can look elsewhere. An alternative if you don't want to stop VMSERVE: from another ID, link to all the disks that VMSERVE has accessed and run the same failing command. If the same failure occurs, you can diagnose, correct, and test the solution with affecting VMSERVE, then move the fix into production. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Amar Moh amar_...@yahoo.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/19/2011 06:09 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Error : DMSITS135S Maximum SVC depth 200 has been exceeded Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CMS system. Recently, it started giving this error every time we make a program run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes and ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SVCs to exceed ''. But not sure what can be done to fix this. Regards, Amar 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. = -- Kris Buelens, IBM Belgium, VM customer support
Re: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
It looks like something else on that linked disk has changed. Perhaps the linking process (VMLINK?) is doing something different, like EXECLOADing something that is now tripping you up. As I said before: Look at the log file and the console spool file for clues. It should be quite obvious. Les Amar Moh wrote: Hi, Sorry for my late response. Thanks Stephen, Les and Mike for responding! Yes, there were two linked disks that had the same exec along with the A disk where it was present too. When I remove one of the disks, it works fine. But we have had this setup for a long time i.e. apart from A disk, we have a test code disk and production code disk linked to this server. So not sure why it's happenin g now. A new thing that has happened and that I haven't mentioned so far is that earlier the rexx codes were run using rexx interpretor and now it has compiled versions on the two linked disks except A disk where it is still non-compiled version. But if I remove the non-compiled version from A disk, it still fails. I a m reluctant to conclude that its due to the compiled rexx as the same is working in other vmserve servers. Regards, Amar On Tue, 19 Apr 2011 10:02:35 -0500, Mike Walter mike.wal...@aonhewitt.co m wrote: Amar, Could you logon to the service machine running VMSERVE, stop VMSERVE, an d then run the command that was running when you experienced the failure? If it still fails the same way, you will evidence that VMSERVE is not causing the problem, and can look elsewhere. An alternative if you don't want to stop VMSERVE: from another ID, link to all the disks that VMSERVE has accessed and run the same failing command. If the same failure occurs, you can diagnose, correct, and test the solution with affecting VMSERVE, then move the fix into production. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Amar Moh amar_...@yahoo.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/19/2011 06:09 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Error : DMSITS135S Maximum SVC depth 200 has been exceeded Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CM S system. Recently, it started giving this error every time we make a program run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes an d ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SVCs to exceed ''. But not sure what can be done to fix this. Regards, Amar 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-mail s 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 deem ed to have accepted these risks if you communicate with us by e-mail. =
How do I assemble a CP EXIT ?
Hi all, I'm trying to assemble the JAMSAMA sample for CP EXIT 1200 (for CP DIAL), from z/VM manual 'CP EXIT CUSTOMIZATION'. I understand the assembler sourcecode from the sample, and I've made my own version with minor modifications. Now I would like to assemble it in CMS. Can anyone tell me how to do that? Do I just use the ASSEMBLE command? Do I need GLOBAL MACLIB commands, etc.? Thanks, Geert. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174
Re: How do I assemble a CP EXIT ?
Here is what I do: VMFSETUP ZVM CP VMFHLASM OITW2H01 ZVM CP where OITW2H01 is my exit's name. Good Luck. Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Dieltiens Geert Sent: Monday, May 02, 2011 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: How do I assemble a CP EXIT ? Hi all, I'm trying to assemble the JAMSAMA sample for CP EXIT 1200 (for CP DIAL), from z/VM manual 'CP EXIT CUSTOMIZATION'. I understand the assembler sourcecode from the sample, and I've made my own version with minor modifications. Now I would like to assemble it in CMS. Can anyone tell me how to do that? Do I just use the ASSEMBLE command? Do I need GLOBAL MACLIB commands, etc.? Thanks, Geert. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174
Re: How do I assemble a CP EXIT ?
You need the High Level Assembler product (extra cost) or the Dignus assembler (also extra cost) to build the module. The MACLIB statements are documented in the discussion of the exit. The old F-level ASSEMBLE command cannot build current CP modules correctly.
Re: How do I assemble a CP EXIT ?
Jim, I tried that and the assembly worked, with no errors. I'll try to use the TEXT module as a CP EXIT tomorrow. Thanks! Bye, Geert. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Hughes, Jim Sent: maandag 2 mei 2011 22:30 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How do I assemble a CP EXIT ? Here is what I do: VMFSETUP ZVM CP VMFHLASM OITW2H01 ZVM CP where OITW2H01 is my exit's name. Good Luck. Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Dieltiens Geert Sent: Monday, May 02, 2011 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: How do I assemble a CP EXIT ? Hi all, I'm trying to assemble the JAMSAMA sample for CP EXIT 1200 (for CP DIAL), from z/VM manual 'CP EXIT CUSTOMIZATION'. I understand the assembler sourcecode from the sample, and I've made my own version with minor modifications. Now I would like to assemble it in CMS. Can anyone tell me how to do that? Do I just use the ASSEMBLE command? Do I need GLOBAL MACLIB commands, etc.? Thanks, Geert. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174
Re: How do I assemble a CP EXIT ?
Hi, Geert. If Jim's instructions worked for you, that means that your site has the HLASM licensed and installed! You should be able to follow the rest of the instruction and load your CP EXITlet us know if that works. DJ On 05/02/2011 03:42 PM, Dieltiens Geert wrote: Jim, I tried that and the assembly worked, with no errors. I'll try to use the TEXT module as a CP EXIT tomorrow. Thanks! Bye, Geert. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Hughes, Jim Sent: maandag 2 mei 2011 22:30 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How do I assemble a CP EXIT ? Here is what I do: VMFSETUP ZVM CP VMFHLASM OITW2H01 ZVM CP where OITW2H01 is my exit's name. Good Luck. Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Dieltiens Geert Sent: Monday, May 02, 2011 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: How do I assemble a CP EXIT ? Hi all, I'm trying to assemble the JAMSAMA sample for CP EXIT 1200 (for CP DIAL), from z/VM manual 'CP EXIT CUSTOMIZATION'. I understand the assembler sourcecode from the sample, and I've made my own version with minor modifications. Now I would like to assemble it in CMS. Can anyone tell me how to do that? Do I just use the ASSEMBLE command? Do I need GLOBAL MACLIB commands, etc.? Thanks, Geert. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174 -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544
Re: Duplicate IPs on VSWITCHes - Feature or Defect
On Monday, 05/02/2011 at 11:48 EDT, Mark Wheeler mwheele...@hotmail.com wrote: The situation is that the IPs were registered on one VSWITCH, and passed on to real switches in the external network. Later, another host registered the same IPs on a different VSWITCH, which failed to pass them on to the external network (rejected because they were dups). The 2nd VSWITCH detected this error, but retained the IPs (for itself) anyway. The question is whether the 2nd VSWITCH should have retained them given it knew they were dups. There are two cases: 1. Connected VSWITCH. I would argue that this is a bug unless the guest has told the vNIC to suppress the ARP query (which is there specifically to allow almost-hot standby network adapters for IP takeover). When a guest registers an IP in an OSA and does NOT suppress the grat ARP, it has the expectation that the OSA will ensure no one else is actively using the indicated IP. 2. Disconnected VSWITCH. If there is no active connection to the network, CP cannot discover the existence of an in-use IP. If you subsequently connect the VSWITCH to the network, CP will register the guest IPs in the OSA and get a failure. But there is no OSA architecture to warn host of this after it has already successfully done a SETIP in the OSA. There *is* architecture to summarily revoke a host's ownership of an IP in an OSA, but in this case, we have no idea which host is wrong. So in this case, CP should use the no-in-use-IP-addy-detection option when it registers the guest IP addresses in the OSA. The gratuitous ARP *reply* that indicates to others IP ownership and interface activation SHOULD be issued so that any other host using the same IP address can pop-up Someone else is using my IP address. Here is his MAC address I've seen this happen on Windows. 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: USER FORCE/Logoff pending
On Monday, 05/02/2011 at 06:33 EDT, Shahin.Suleiman shahin.sulei...@palmcoastdata.com wrote: I tried varying the chpid off and had no response and my userid is hung. The chpid feeds a controller that someone just powered off. If possible, get a restart dump and open a PMR. Long-wait LOGOFF/FORCE PENDING conditions are not really supposed to happen and CP shouldn't get hung in a VARY. (FVVO not really and shouldn't) 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: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
On Monday, 05/02/2011 at 11:32 EDT, Amar Moh amar_...@yahoo.com wrote: But if I remove the non-compiled version from A disk, it still fails. I am reluctant to conclude that its due to the compiled rexx as the same is working in other vmserve servers. There is something else causing the problem, as CMS doesn't care if an exec is compiled or not. You can use the SVCTRACE ON command to see what's happening. HELP SVCTRACE for details. (CP SPOOL 00E TO * before you start so that you can use RDRLIST and PEEK to look at the trace.) 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: Restrictions in FCP point-to-point topology
On 4/28/2011 at 12:19 PM, Alan Ackermanalan.acker...@bankofamerica.com wrote: We are planning to use FCP disk with a z/Linux under z/VM system, running under z/VM 5.4. To reduce cost, we are planning to use the point-to-point topology. If you don't use a SAN fabric switch, discovering and configuring LUNs on your Linux guests will be entirely manual, and even less fun than usual. This is due to the fact that a number of things the discovery tools depend upon are provided by the switch itself. I know of a couple of customers that went with point-to-point. It made their life (and that of their IBM business partner and our TSS) miserable. Mark Post
