Re: z/VM - z9 and zAAP
I have been following all this with great interest and still have questions. If one has a z9 that is zIIP and zAAp capable, then zVM5.3 can emulate these processors. If z9 actually has these processors, can z/OS under z/VM 5.3 actually use them ?. Any idea what the overhead is likely to be. Crispin Hugo Systems Programmer, Macro 4 This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system.
Re: z/VM - z9 and zAAP
I have been following all this with great interest and still have questions. If one has a z9 that is zIIP and zAAp capable, then zVM5.3 can emulate these processors. If z9 actually has these processors, can z/OS under z/VM 5.3 actually use them ?. Any idea what the overhead is likely to be. Yes z/OS can use real zIIP and zAAP processors if defined to the z/VM 5.3 LPAR. Initial measurements have shown very little overhead. Best Regards, Les Geer IBM z/VM and Linux Development
Re: z/VM - z9 and zAAP
Any chance this will be retro-fitted to 5.2? On 3/15/07, Les Geer (607-429-3580) [EMAIL PROTECTED] wrote: Yes z/OS can use real zIIP and zAAP processors if defined to the z/VM 5.3 LPAR. Initial measurements have shown very little overhead. -- Mark Pace Mainline Information Systems
Re: z/VM - z9 and zAAP
On Thursday, 03/15/2007 at 07:45 GMT, Crispin Hugo [EMAIL PROTECTED] wrote: I have been following all this with great interest and still have questions. If one has a z9 that is zIIP and zAAp capable, then zVM5.3 can emulate these processors. If z9 actually has these processors, can z/OS under z/VM 5.3 actually use them ? Yes, that's the virtualization. If you only have standard CPUs in the z/VM LPAR, we call it simulation. You will be able to define a virtual CPU as a zIIP or a zAAP. I should point out that, as with z/OS, if you add a zIIP or a zAAP to a z/VM LPAR, you do not owe IBM any additional z/VM license charges. Any idea what the overhead is likely to be. No more than for any other virtual CPU, but I don't think we can make any definitive statements at this point as z/VM 5.3 is still under development, and performance analysis is on-going. Alan Altmark z/VM Development IBM Endicott
Re: z/VM - z9 and zAAP
On Thursday, 03/15/2007 at 08:38 AST, Mark Pace [EMAIL PROTECTED] wrote: Any chance this will be retro-fitted to 5.2? No. Anyone with z/VM 5.2 and a SS contract can upgrade to 5.3 for free. Alan Altmark z/VM Development IBM Endicott
Re: Date Time Changes...
Paul, Suggesting TODALLOW wasn't an attempt to fix the current problem. It was a suggestion to prevent an incorrect date or time from being used in production the NEXT time that the clock is set wrong at IPL. There is alw ays a next time. No point in being annoyed at someone else for the same reason. Of course, now that you've done it yourself (pretty much everyone has; just as pretty much everyone has SHUTDOWN their production system by mistake -- or will) you won't do it again. But someone will. It's just sooo easy to do when IPLing in a hurry. :-) Install TODALLOW to prevent that next time. With TODALLOW installed properly, it takes a special effort to come up with a wildly incorrect time or date. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Paul Raulerson [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/14/2007 07:55 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Date Time Changes... Really nice try Mike ? I appreciate it. I feel pretty annoyed with myself right now. -Paul From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, March 14, 2007 5:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Date Time Changes... Actually, after our Operator's took us past Y2K, and back to 1900, too - I placed a TODALLOW package on the IBM VM Download page: http://www.vm.ibm.com/download/packages/ No problems since! ---snip--- The TODALLOW EXEC is intended to be called from the PROFILE EXEC of AUTOLOG1. It is used to prevent AUTOLOG1 from continuing with standard AUTOLOG commands and other procedures if the current date and time are outside defined limits. TODALLOW compares the current date/time to the date/time of the most recent file on a specified, accessed CMS minidisk (e.g an OPERATOR system console log file - select one that is frequently updated). If the current date/time are different by more than a specified time range (e.g. 02:00 hours) from that file, a message is issued to a specified userid (typically OPERATOR) and an reply is required from that user before the new date/time is accepted and standard procedures continue. This gives the Operator a chance to shutdown and change the TOD clock before application damage (tapes scratched, files deleted, etc.) can occur. The only pre-requisites are CMS Pipelines, and the IBM-distributed RXTOD MODULE (on MAINT's 193 disk). Updated 2000-10-13 to accept 'WNG' from OPERATOR, and reduce the time window between setting MSG/WNG/SMSG IUCV and waiting for a response, and better handle manual interrupts. ---snip--- Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Kris Buelens [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/14/2007 04:10 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Date Time Changes... I just updated the TOD at IPL time to be current with CDT If you set a correct timezone, you don't set datetime do you? Unless to adjust the time drift of the z9 clock. I did write some code to be included in AUTOLOG1 that will ask the operator to send an OK if the date differs more than 3 days with the last known date (which is saved daily by VMUTIL) -- Kris Buelens, IBM Belgium, VM customer support 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. 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.
Re: Question about source layout for HISTSUM file
I looked on all of the disk for 5VMPTK10 but could not find the FCXACLIB. Is it some place else? Paul Feller AIT Mainframe Technical Support [EMAIL PROTECTED] (319)-355-7824 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, March 14, 2007 4:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Question about source layout for HISTSUM file On Wednesday, 03/14/2007 at 03:32 EST, Feller, Paul [EMAIL PROTECTED] wrote: I am trying to find some sort of source layout for the HISTSUM file. I was hoping to write a program to read the file and either write some reports or extract part of the data into another file. This is going to be done on a z/OS (for give me) system. We are currently running z/VM 5.1. If you have FCXACLIB MACLIB, you will find HISTSEC therein. It is a COPY file. Alan Altmark z/VM Development IBM Endicott
Historical curiousity question.
This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be more akin to a partition table on a PC disk. It just seems that it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Historical curiousity question.
Perhaps an FST?
Re: Historical curiousity question.
It sounds like he is looking for something at the Volume level - more than just the contents of a single MDISK. He would like a mapping on the volume to show where all the mdisks are, owners, passwords, etc. The concept is interesting but it opens a few cans of worms, one of which being security. (Duck, I see Chuckie heading this way!!) ___ James Vincent Systems Engineering Consultant Nationwide Services Co., Technology Solutions Mainframe, z/VM and z/Linux Support One Nationwide Plaza 3-20-13 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5547Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 03/15/2007 10:46:54 AM: IBMVM@LISTSERV.UARK.EDU Perhaps an FST?
Re: Historical curiousity question.
Hmmm. I don't know the history, but can imagine some problems. 1) VOLSER=1 has n minidisks, defined in CP Object directory. 2) Now imagine that the disk is taken offline, perhaps for some DASD service. 3) And the CP Object directory is updated, re-allocating those minidisks to a new VOLSER=22 and restored from tape. 4) Now whatever was wrong with access to VOLSER=11 is fixed and it is brought back online. The VTOC on 11 reflects the old minidisks and their locations, while the CP Object directory reflects the valid locations. Confusion abounds (likely because someone was not told what ensued - how good are YOUR communications?). My questions are, what is the problem and what are you trying to solve/improve? Most questions are inspired by something that happened. What happened in this case? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. McKown, John [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/15/2007 09:42 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Historical curiousity question. This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be more akin to a partition table on a PC disk. It just seems that it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. 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.
Re: Historical curiousity question.
John, I have a PFKEY set up in MAINT to list mdisks in different ways, one of which might be what you are looking for. I actually run this every time I up date the directory and run an edit on it, I can spot an overlap on files easily this way also. PF06 DELAY DISKMAP USER#DIRMAP USER(GAPFILE INCLUDE LINKS#DIRECTXA (EDIT Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 7043 (704) 708-7043 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, March 15, 2007 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Historical curiousity question. This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be more akin to a partition table on a PC disk. It just seems that it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. - NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: Historical curiousity question.
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Thursday, March 15, 2007 10:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Historical curiousity question. Just a guess. The CP Directory has information for each user. At logon time, the information about a single user is available very quickly. This makes sense to me. IIRC, the VM directory is memory resident so all this information is instantly available, making for a very fast logon. If the information about how a disk was divided into minidisks was stored in a VTOC, do you remove it from the Directory, or do you keep the information in two places? (Since there is a small VTOC on CP volumes, it really could have been in the VTOC, probably with different DSCB formats) I guess that I was thinking that the Directory would have something like z/OS dataset name for each minidisk. For example, instead of: MDISK 191 3390 10 199 UVOL01 WR RPASS WPASS MPASS something like: MDISK 191 3390 UVOL01 LVOL WR Where LVOL is the dataset name in the VTOC of volume UVOL01 which describes the extents of this minidisk allocation. If you remove it from the directory, then you greatly slow down logon processesing, and lead to situations where if a volume is offline, the system would not know that something was missing for the user. In the above example, if UVOL01 were offline, you could do the same thing as is now done by VM. If you keep it both places, which is the authoritative source? I'd have to check the history, but I bet that the source Directory was kept by hand originally, in a flat file, leading to even more difficulties is keeping them in sync. Yes, I did that on VM/370. USER DIRECT and I had all the old tools where every volume had a pseudo-guest which owned all the unused space that could be used for minidisks. And if I needed to make a minidisk bigger - what a pain. IBM has greatly helped in this area since the 1980s. I am not having a problem at all with how things are done. I was just curious about why the original developers made DASD management such a burden on the sysprog. Especially in the early days. But performance could very well be the reason. Especially if they did not expect the system to be such a hit with users. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Question about source layout for HISTSUM file
On Thursday, 03/15/2007 at 09:35 EST, Feller, Paul [EMAIL PROTECTED] wrote: I looked on all of the disk for 5VMPTK10 but could not find the FCXACLIB. Is it some place else? Oh, and look for HISTSECT COPY on any perfkit disk. If you don't find it, I would suggest contacting the Support Center and ask for it. I don't see any value in requiring every user of HISTSECT to have to type it in or copy/paste, but there may be other reasons I'm unaware of. Alan Altmark z/VM Development IBM Endicott
Re: TCPNJE
Les, We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP definitions and have let the Inactivity Time Out Parm for the TCPNJE link default to 100, which means there will be no inactivity time out from our side. These parameters work nicely when used on VM-VM links. The timing makes it appear as though the connection is being broken from the z/OS side some time before the Keepalive interval expires. When it does expire, the Garbage packet is transmitted. There is a time out on the garbage packet, which triggers the connection time out messages and action. Does this seem a plausible scenario? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Wednesday, March 14, 2007 7:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE All of the DMTTNE083E messages from this link have been due to the connection timing out. Is this timeout something that is or can be defined in TCP/IP? I see no parameters for it in RSCS and the MVS sysprog says the same about JES. An update to the above. The timeouts are occurring at very regular intervals of between 00:22:36 to 00:22:39. The keepalive interval in our TCPIP is 20 minutes. It appears that the timeouts are related to the keepalive message. Are you using the KEEPALIVE TCPNJE link parm? Best Regards, Les Geer IBM z/VM and Linux Development
Re: Historical curiousity question.
I am not having a problem at all with how things are done. I was just curious about why the original developers made DASD management such a burden on the sysprog. Especially in the early days. But performance could very well be the reason. 1) Back then, there *wasn't* much DASD to manage. VM systems have historically been smaller and lighter, and been relatively resource-poor compared to their OS-based siblings. Consider the original purpose of VM was to be a *migration aid* from OS/360 to later releases; it wasn't intended to be a permanent thing (at least not until real customers got their hands on it) so there wouldn't have been a lot of VM disk to manage. 2) Same with memory. Building a in-core table for all the possible minidisks would have been prohibitively expensive on a 2M machine (if I remember correctly, CP-67 would run on even smaller systems than that). The disk-based approach could handle small-memory machines and bigger ones with roughly equal performance.
Re: TCPNJE
We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP definitions and have let the Inactivity Time Out Parm for the TCPNJE link default to 100, which means there will be no inactivity time out from our side. These parameters work nicely when used on VM-VM links. The timing makes it appear as though the connection is being broken from the z/OS side some time before the Keepalive interval expires. When it does expire, the Garbage packet is transmitted. There is a time out on the garbage packet, which triggers the connection time out messages and action. Does this seem a plausible scenario? I believe the garbage packet would only be set if the actual socket is defined to use keepalive, hence why I suggested to code KEEPALIVE=YES on the RSCS link parm. It is possible the this is already happening, but why then is socket on the z/OS side being broken? Best Regards, Les Geer IBM z/VM and Linux Development
Re: TCPNJE
You've gotta be kidding. That or your publications people are. The only mention of KEEPALIVE=YES in any RSCS manual is in a sample config file in Appendix B of the RSCS Planning and Installation. Is this one of those, It is so obvious we don't need to document it, things. Where is the default documented? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Thursday, March 15, 2007 9:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP definitions and have let the Inactivity Time Out Parm for the TCPNJE link default to 100, which means there will be no inactivity time out from our side. These parameters work nicely when used on VM-VM links. The timing makes it appear as though the connection is being broken from the z/OS side some time before the Keepalive interval expires. When it does expire, the Garbage packet is transmitted. There is a time out on the garbage packet, which triggers the connection time out messages and action. Does this seem a plausible scenario? I believe the garbage packet would only be set if the actual socket is defined to use keepalive, hence why I suggested to code KEEPALIVE=YES on the RSCS link parm. It is possible the this is already happening, but why then is socket on the z/OS side being broken? Best Regards, Les Geer IBM z/VM and Linux Development
Re: Historical curiousity question.
To support minidisks that already have a VTOC embedded i.e 'MDISK cuu devt 0 END volser' McKown, John wrote: This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be more akin to a partition table on a PC disk. It just seems that it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. .. For: [EMAIL PROTECTED] -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com
Re: TCPNJE
No wonder it isn't described. I can define the link with keepalive, but when I start it, I get a message that says keepaliv (note the truncation) is an invalid parameter. (And yes, keepalive=yes was spelled correctly according to the example.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Thursday, March 15, 2007 9:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP definitions and have let the Inactivity Time Out Parm for the TCPNJE link default to 100, which means there will be no inactivity time out from our side. These parameters work nicely when used on VM-VM links. The timing makes it appear as though the connection is being broken from the z/OS side some time before the Keepalive interval expires. When it does expire, the Garbage packet is transmitted. There is a time out on the garbage packet, which triggers the connection time out messages and action. Does this seem a plausible scenario? I believe the garbage packet would only be set if the actual socket is defined to use keepalive, hence why I suggested to code KEEPALIVE=YES on the RSCS link parm. It is possible the this is already happening, but why then is socket on the z/OS side being broken? Best Regards, Les Geer IBM z/VM and Linux Development
Re: TCPNJE
Isn't that ITO=100? 0 seems a special case - drop it and do not autostart it. ITO=100 implies never drop, doesn't it? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, March 15, 2007 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE On Thursday, 03/15/2007 at 09:35 MST, Schuh, Richard [EMAIL PROTECTED] wrote: Les, We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP definitions and have let the Inactivity Time Out Parm for the TCPNJE link default to 100, which means there will be no inactivity time out from our side. These parameters work nicely when used on VM-VM links. The timing makes it appear as though the connection is being broken from the z/OS side some time before the Keepalive interval expires. When it does expire, the Garbage packet is transmitted. There is a time out on the garbage packet, which triggers the connection time out messages and action. Does this seem a plausible scenario? What does the JES definition look like? Maybe its ITO is less than 20 minutes? BTW, keepalives are transparent to the applications (RSCS JES) - they don't see any traffic, even with sendgarbage true. The purpose of the keepalive is so that you can find out sooner if the remote host has died unexpected or if your communications path was lost. This is different from, say, telnet support for TimerMarks which is an app-to-app heartbeat. This means that a keepalive packet sent from VM will not prevent the partner's inactivity timer from popping. If you don't want the links to go down, both sides must have ITO=0 (or the moral equivalent). Alan Altmark z/VM Development IBM Endicott
Re: TCPNJE
If I set ITO to 0, the link is dropped immediately upon being started. If I set it to 99, I get the same 22.5 minute timeout that I got when I let ITO default to 100. The MVS folks say that their TCPNJE link between 2 MVS systems has no problem and that they let the ITO default of 100 stand. Aarrggg! I may have to dig into z/OS JES documentation to determine what should be specified where. The MVS folks here may not be willing to share their JES definitions. They sometimes are very defensive. From your description, it appears likely that TCPIP's Keepalive packet is what is discovering that the MVS side has gone away and then TCP/IP interrupts RSCS with the bad news. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, March 15, 2007 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE On Thursday, 03/15/2007 at 09:35 MST, Schuh, Richard [EMAIL PROTECTED] wrote: Les, We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP definitions and have let the Inactivity Time Out Parm for the TCPNJE link default to 100, which means there will be no inactivity time out from our side. These parameters work nicely when used on VM-VM links. The timing makes it appear as though the connection is being broken from the z/OS side some time before the Keepalive interval expires. When it does expire, the Garbage packet is transmitted. There is a time out on the garbage packet, which triggers the connection time out messages and action. Does this seem a plausible scenario? What does the JES definition look like? Maybe its ITO is less than 20 minutes? BTW, keepalives are transparent to the applications (RSCS JES) - they don't see any traffic, even with sendgarbage true. The purpose of the keepalive is so that you can find out sooner if the remote host has died unexpected or if your communications path was lost. This is different from, say, telnet support for TimerMarks which is an app-to-app heartbeat. This means that a keepalive packet sent from VM will not prevent the partner's inactivity timer from popping. If you don't want the links to go down, both sides must have ITO=0 (or the moral equivalent). Alan Altmark z/VM Development IBM Endicott
Re: Historical curiousity question.
On Thursday, 03/15/2007 at 10:55 EST, McKown, John [EMAIL PROTECTED] wrote: The CP Directory has information for each user. At logon time, the information about a single user is available very quickly. This makes sense to me. IIRC, the VM directory is memory resident so all this information is instantly available, making for a very fast logon. Actually, it isn't. When a user logs on and a VMDBK is created for them, SOME of the information in the directory is cached in memory. Other things, such as LINK, require a trip to DASD. Since reading the user's directory entry is a relatively rare event, that's ok. Alan Altmark z/VM Development IBM Endicott
FCOPY
Any known issues with FCOPY (from the VM packages on the IBM VM website) being able to list the contents of a packlib but when it extracts the members they are empty? Nice package FCOPY pity it's OCO ;-)
Re: Historical curiousity question.
2007/3/15, Alan Altmark [EMAIL PROTECTED]: On Thursday, 03/15/2007 at 10:55 EST, McKown, John [EMAIL PROTECTED] wrote: The CP Directory has information for each user. At logon time, the information about a single user is available very quickly. This makes sense to me. IIRC, the VM directory is memory resident so all this information is instantly available, making for a very fast logon. Actually, it isn't. When a user logs on and a VMDBK is created for them, SOME of the information in the directory is cached in memory. Other things, such as LINK, require a trip to DASD. Since reading the user's directory entry is a relatively rare event, that's ok. Alan Altmark z/VM Development IBM Endicott Alan, isn't the CP directory entirely stored in a CP dataspace nowadays? -- Kris Buelens, IBM Belgium, VM customer support
Re: Historical curiousity question.
um, at the risk of the wrath of Chuckie, not quite. The directory is treated as CP virtual storage. So some of it is usually resident (at least the index pages) and the rest is treated as nice preferred page i/o to the drct area. With storage sizes what they are these days, I'm thinking a lot of the directory is resident. David From: The IBM z/VM Operating System on behalf of Alan Altmark Sent: Thu 3/15/2007 4:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Historical curiousity question. On Thursday, 03/15/2007 at 10:55 EST, McKown, John [EMAIL PROTECTED] wrote: The CP Directory has information for each user. At logon time, the information about a single user is available very quickly. This makes sense to me. IIRC, the VM directory is memory resident so all this information is instantly available, making for a very fast logon. Actually, it isn't. When a user logs on and a VMDBK is created for them, SOME of the information in the directory is cached in memory. Other things, such as LINK, require a trip to DASD. Since reading the user's directory entry is a relatively rare event, that's ok. Alan Altmark z/VM Development IBM Endicott
Re: TCPNJE
You've gotta be kidding. That or your publications people are. The only mention of KEEPALIVE=3DYES in any RSCS manual is in a sample config file in Appendix B of the RSCS Planning and Installation. Is this one of those, It is so obvious we don't need to document it, things.=20 Where is the default documented? It is documented in the RSCS Planning and Installation manual although the option is KEEPALIV= (not keepalive) and the default is yes. So RSCS would have enabled keepalive for the socket session, that would probably be what is happening. From the other threads, if JES has defined an ITO= parameter, I would think they would have sent a signoff record when the link went down, not just leave the link in a 'gone' state. I bet something else is taking the link away. Is the JES side aware of the link state? Best Regards, Les Geer IBM z/VM and Linux Development
Re: Historical curiousity question.
On Thursday, 03/15/2007 at 10:01 CET, Kris Buelens [EMAIL PROTECTED] wrote: Alan, isn't the CP directory entirely stored in a CP dataspace nowadays? Well, sort of, but the parts of CP that want to read the directory don't know that. :-) The directory is memory mapped into the CP execution space (I think) and is paged in on demand, so a second reference might find the needed parts of the directory already in memory. I don't know all the gory details. Alan Altmark z/VM Development IBM Endicott
Re: TCPNJE
On Thursday, 03/15/2007 at 12:24 MST, Schuh, Richard [EMAIL PROTECTED] wrote: If I set ITO to 0, the link is dropped immediately upon being started. If I set it to 99, I get the same 22.5 minute timeout that I got when I let ITO default to 100. Sorry. I meant ITO=100. (Never timeout.) The MVS folks say that their TCPNJE link between 2 MVS systems has no problem and that they let the ITO default of 100 stand. Aarrggg! I may have to dig into z/OS JES documentation to determine what should be specified where. The MVS folks here may not be willing to share their JES definitions. They sometimes are very defensive. Do they have keepalives turned on? From your description, it appears likely that TCPIP's Keepalive packet is what is discovering that the MVS side has gone away and then TCP/IP interrupts RSCS with the bad news. Right. The jury is still out on the usefulness of keepalive packets, btw. IP was *designed* to tolerate path failures and to automatically route around them, not get all bent out of shape and start whining. It comes at the price of the application not discovering this until too late. That is, until the app actually tries to use the path. If only the network could have been repaired right *before* I needed it! Personally, I'd specify KEEPALIV=NO. Have cake. Eat cake. It's a choice. Alan Altmark z/VM Development IBM Endicott
Re: TCPNJE
Do they have keepalives turned on? I do not know whether they do or not. Whenever I ask, I get an answer befitting a lawyer; something like, I think we have allowed it to default and I think the default probably is to keep the link alive at all times. I have suggested that they look at their setup to verify it and all I get are mumbles. Have cake. Eat cake. It's a choice. Make mine chocolate fudge cake with dark chocolate icing. Now they are trying to point to APAR VM61470. If I read things correctly, it (a) has not been closed and there is no PTF, and (b) probably is not relevant to the situation at hand (the systems get signed on and can send files back and forth so long as the link is not left idle). If that is the problem, can I get the PTF before it is created? Les Geer, You must be seeing this - I have just restarted the link specifying parm host=10.205.32.89 keepaliv=yes ito=100 so we will see if that has any effect. If I were to bet on it, I would say that it will not fix the problem. keepaliv (no ending e) appears to have been accepted. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, March 15, 2007 2:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE On Thursday, 03/15/2007 at 12:24 MST, Schuh, Richard [EMAIL PROTECTED] wrote: If I set ITO to 0, the link is dropped immediately upon being started. If I set it to 99, I get the same 22.5 minute timeout that I got when I let ITO default to 100. Sorry. I meant ITO=100. (Never timeout.) The MVS folks say that their TCPNJE link between 2 MVS systems has no problem and that they let the ITO default of 100 stand. Aarrggg! I may have to dig into z/OS JES documentation to determine what should be specified where. The MVS folks here may not be willing to share their JES definitions. They sometimes are very defensive. Do they have keepalives turned on? From your description, it appears likely that TCPIP's Keepalive packet is what is discovering that the MVS side has gone away and then TCP/IP interrupts RSCS with the bad news. Right. The jury is still out on the usefulness of keepalive packets, btw. IP was *designed* to tolerate path failures and to automatically route around them, not get all bent out of shape and start whining. It comes at the price of the application not discovering this until too late. That is, until the app actually tries to use the path. If only the network could have been repaired right *before* I needed it! Personally, I'd specify KEEPALIV=NO. Have cake. Eat cake. It's a choice. Alan Altmark z/VM Development IBM Endicott
Re: Historical curiousity question.
--- McKown, John [EMAIL PROTECTED] wrote: This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be more akin to a partition table on a PC disk. It just seems that it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. I don't know the answer, but in the historical context, putting directories on the DASD starts to get complex when running VM under VM using minidisks , not full-pack dasd. Historically you didn't have many DASD so you probably needed to do this for tested etc. How could the second level VM update the master directory on the front of the pack as all it can see is the extent defined as a minidisk?. And if it couldn't but it used second level mini disks, i.e. it subdivided its mini-disks into mini-mini disk you would not be able to (easily) migrate these back to the first level VM. It used to be quit common to have L2MAINT defined in your first level system, but using the same extents as minidisks as the L2 MAINT used I hope you follow this, as I am not sure I have explained it very well Dave. Just curious. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091
[no subject]
Neale Ferguson [EMAIL PROTECTED] wrote :- Any known issues with FCOPY (from the VM packages on the IBM VM website) I have had problems using OLDD with files from the last century ( copyfile gets it right ). Not sure if I have the latest version? With best regards / mit den besten Grüßen, Colin G Allinson Technical Manager VM T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: TCPNJE
As far as I know, JES is aware of the state. Their side apparently has an autostart because whenever the link drops and RSCS restarts it from the VM side, the signs are done and the link reestablished for another 22 minutes. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Thursday, March 15, 2007 2:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE You've gotta be kidding. That or your publications people are. The only mention of KEEPALIVE=3DYES in any RSCS manual is in a sample config file in Appendix B of the RSCS Planning and Installation. Is this one of those, It is so obvious we don't need to document it, things.=20 Where is the default documented? It is documented in the RSCS Planning and Installation manual although the option is KEEPALIV= (not keepalive) and the default is yes. So RSCS would have enabled keepalive for the socket session, that would probably be what is happening. From the other threads, if JES has defined an ITO= parameter, I would think they would have sent a signoff record when the link went down, not just leave the link in a 'gone' state. I bet something else is taking the link away. Is the JES side aware of the link state? Best Regards, Les Geer IBM z/VM and Linux Development
Re: TCPNJE
As far as I know, JES is aware of the state. Their side apparently has an autostart because whenever the link drops and RSCS restarts it from the VM side, the signs are done and the link reestablished for another 22 minutes. But what is causing the JES side to drain? Is it the keepalive (like is causing RSCS to drain), or is the JES side going down first then the keepalive takes down RSCS? Best Regards, Les Geer IBM z/VM and Linux Development
Re: TCPNJE
Richard, Just curious, do you have PATHMGR=NO for your RSCS JES/2 NODE definition? HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, March 15, 2007 4:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE As far as I know, JES is aware of the state. Their side apparently has an autostart because whenever the link drops and RSCS restarts it from the VM side, the signs are done and the link reestablished for another 22 minutes. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Thursday, March 15, 2007 2:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE You've gotta be kidding. That or your publications people are. The only mention of KEEPALIVE=3DYES in any RSCS manual is in a sample config file in Appendix B of the RSCS Planning and Installation. Is this one of those, It is so obvious we don't need to document it, things.=20 Where is the default documented? It is documented in the RSCS Planning and Installation manual although the option is KEEPALIV= (not keepalive) and the default is yes. So RSCS would have enabled keepalive for the socket session, that would probably be what is happening. From the other threads, if JES has defined an ITO= parameter, I would think they would have sent a signoff record when the link went down, not just leave the link in a 'gone' state. I bet something else is taking the link away. Is the JES side aware of the link state? Best Regards, Les Geer IBM z/VM and Linux Development
Re: Historical curiousity question.
On Thu, 15 Mar 2007 12:48:15 -0400, David Boyes wrote: I am not having a problem at all with how things are done. I was just curious about why the original developers made DASD management such a burden on the sysprog. Especially in the early days. But performance could very well be the reason. 1) Back then, there *wasn't* much DASD to manage. VM systems have historically been smaller and lighter, and been relatively resource-poor compared to their OS-based siblings. Consider the original purpose of VM was to be a *migration aid* from OS/360 to later releases; it wasn't intended to be a permanent thing (at least not until real customers got their hands on it) so there wouldn't have been a lot of VM disk to manage. Was it? I was taught by some of the people that worked at Lincoln Labs that VM was a CE/SE training aid. That is why it was designed to so closely emulate a 360 Mod 50. You could break things and the CE/SE would learn how to detect what was broken and how to fix it. Lloyd User of VM and its cousin VP/CSS since 1975.
Re: PERFKIT error
Hi Guys, We are running z/VM 4.4 in one of our z9 box and we implement PERFKIT to monitor our z/VM. But when I'm running the PERFKIT after a few hours (almost a day) the PERFKIT dumps and give me an error like the one below: Dumping LOC R0979 Dumping LOC R097A Dumping LOC R097B Dumping LOC R097C Dumping LOC R097D Dumping LOC R097E Dumping LOC R097F Command complete RDR FILE 0040 SENT FROM PERFSVM PRT WAS 0040 RECS 411K CPY 001 A NOHOLD NOKEEP DMSABE141T Operation exception occurred at 80E4BCA8 in routine PERFKIT Has anyone experience this before? Thanks for your replies! Regards, Mikhael
