Re: Where Do I Go From Here?
Richard:Yes, thanks - I remembered after I sent the note andwent home for the day that 370 mode is also machine dependant as well.Karl SeversonIBM VM System AdministratorRaytheon CompanyEl Segundo, California---Different Richard here, but I can tell you that your understanding isnot correct. If the underlying hardware doesn't support 370 mode,neither VM/ESA or 3.1 can give you what isn't there.
Re: Where Do I Go From Here?
Thanks to all who have responded to this post. There are many interesting ideas that I can present to the upgrade team. I know that I have brought this subject up before as someone mentioned but at that time, it was mainly for OS upgrade (where I was concerned about 370 mode) on our current platforms which are four 3006 S/390 boxes and one zFrame Flex-ES box. However now I need toreplace the unsupported 3006 boxes so theproject became one to upgrade the hardware as well.Karl SeversonIBM VM System AdministratorRaytheon CompanyEl Segundo, California
Re: Where Do I Go From Here?
Richard:We have 370 mode in V2.3 so that's no problem. My concern is it's lack of availability in the more recent versions of zVM/CMS. That's why we would need to run a guest VM/ESA or maybe zVM 3.1 partition under the latest zVM so we could keep 370 mode. At least that's my understanding. Karl SeversonIBM VM Systems AdministratorRaytheon CompanyEl Segundo, California-The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote: -To: IBMVM@LISTSERV.UARK.EDUFrom: "Schuh, Richard" [EMAIL PROTECTED]Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDUDate: 08/21/2008 03:12PMSubject: Re: Where Do I Go >From Here?Have you tried CP SET 370ACCOM ON and SET CMS370AC ON while running inan ESA mode machine?Regards, Richard Schuh
Re: TCPIP PCOMM 658 Code
I thought I'd do a follow up on this problem for anyone who might be interested and who may have a similar setupto the onewe do. I was fairly confident that VM:Operator wasn't to blame for the problem but contactedCA anyway since the only error codes we ever got were from VM:Operator. AfterCA andIdiscounted him as the culprit I decided to focus on TCPIP as I always thought he was to blame. After reading through both the Planning and Configuration manual and the User's Guide I zeroed in on the POOLSIZE part of the PROFILE TCPIP. After issuing the NETSTAT POOLSIZE command I noticed that the system was trying to useSmallDataBufferwhich we had set to zero in the #Alloc column. I say the system was trying to use it only because there was a "1" in the Permit Size column. This was without anyone being logged on via TELNET. At any rate, setting the #Alloc to 10 on my test system seems to have fixed the problem. Logging on multiple users via TELNET and issuing NETSTAT POOLSIZE shows that the numbers in all the other columns do indeed change depending on the number of remote logons I have. For any production machines the #Alloc will be set to 100 as they have many more users. This was never a problem on our 43XX or 9221 systems nor our PC Server based P/390s but for some reason, the Integrated Servers we have are a rather sensitive lot. Either that or PCOMM is more sensitive than Communications Manager/2 but my money is still on TCPIP. One day I hope to be able to work on more modernsystems but for now I'm stuck trying to support unsupported hardware and software.Karl SeversonRaytheon CompanyEl Segundo, California
Re: TCPIP PCOMM 658 Code
That's okay. I'll be checking with Computer Associates tomorrow since the error message I was getting was from VM:Operator. I checked to make sure we were running the most recent version of VM:Manager and Operator and we appear to be. Somehow though I think it's a TCPIP problem but I don't really care as long as I can fix it. Karl SeversonRaytheon CompanyEl Segundo, California-The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote: -To: IBMVM@LISTSERV.UARK.EDUFrom: Alan Altmark [EMAIL PROTECTED]Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDUDate: 07/21/2008 10:19PMSubject: Re: TCPIP PCOMM 658 CodeSorry, I can't help you. Others here are far more familiar with the day-to-day operation of the Integrated Server.Alan Altmarkz/VM DevelopmentIBM Endicott
TCPIP PCOMM 658 Code
I was happy to see that others are using PCOMM so perhaps someone will be able to figure out my plight. I use the OS/2 flavor (4.21) and promptly each Saturday, my console and any other open sessions running VM go blank and there is a 658 code on the bottom of the frame of each open session. I don't think that there is anything special about Saturdays. No one is even working. I believe it has something to do with having to reboot the system every Monday to get the sessions back. So, something "fills up" or breaks 6 daysafter rebooting OS/2 and VM. When I was finally able to find out what a 658 code meant, it said that it was the session(s) attempting to initializethe TCPIP connection to the hardware management console. This makes sense as while VM is booting I notice that the sessions beep and display the VM logo around the same time as TCPIP is brought up. The actual error that I get is VMYIOD041T Permanent I/O error on console, SCSW=0009. This problem plagues all four of my IBM servers which are, obviously, all configured exactly alike. Thanks in advance for any insight anyone may have. Karl Severson IBM System Administrator Raytheon Company El Segundo, California
Re: TCPIP PCOMM 658 Code
-The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote: -To: IBMVM@LISTSERV.UARK.EDUFrom: Alan Altmark [EMAIL PROTECTED]Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDUDate: 07/21/2008 11:45AMSubject: Re: TCPIP PCOMM 658 CodeI would guess that every weekend a firewall is rebooted. I don't understand about "reboot the system every Monday to get the sessions back". Reboot what system?PCOMM will only try to reconnect if it receives a disconnect. And that will only happen (assuming you don't shutdown TCPIP on VM) if something between your workstation and VM causes it to happen.Alan Altmarkz/VM DevelopmentIBM EndicottI guess I should have mentioned what servers I have. I have four 3006 Integrated Servers (P/390s) which run OS/2 and VM. By sessions I mean the PCOMM 3270 console screens which display VM:Operator and which can be used to log on to other VM accounts. The icons on the desktop call them Local P/390 Sessions or P/390 WS. By rebooting the system I mean that on each 3006 I have to end the P/390 session which crashes VM as I have no console to shut VM down nicely. I then start the P/390 software which brings up VM and all of the PCOMM 3270 sessions. I guess you'd have to be familiar with the P/390 to be able to picture what I'm describing but hopefully I'm giving you enough information to do so. As far as a firewall is concerned, this happens even if the system isn't hooked up to a network.Karl Severson - Raytheon Company
TCPIP PCOMM 658 Code
I was happy to see that others are using PCOMM so perhaps someone will be able to figure out my plight. I use the OS/2 flavor (4.21) and promptly each Saturday, my console and any other open sessions running VM go blank and there is a 658 code on the bottom of the frame of each open session. I don't think that there is anything special about Saturdays. No one is even working. I believe it has something to do with having to reboot the system every Monday to get the sessions back. So, something "fills up" or breaks 6 daysafter rebooting OS/2 and VM. When I was finally able to find out what a 658 code meant, it said that it was the session(s) attempting to initializethe TCPIP connection to the hardware management console. This makes sense as while VM is booting I notice that the sessions beep and display the VM logo around the same time as TCPIP is brought up. The actual error that I get is VMYIOD041T Permanent I/O error on console, SCSW=0009. This problem plagues all four of my IBM servers which are, obviously, all configured exactly alike. Thanks in advance for any insight anyone may have.Karl SeversonIBM System AdministratorRaytheon CompanyEl Segundo, California
