Disk problems running Sysplex under VM
I'm running z/VM Version 4 Release 3.0, service level 0201 on a multiprise 3000 (7060) I'm setting up a Sysplex using 3 Z/os 1.5 but I keep getting HCPVER575I I/O error add=0100, userid= ZPLEX2 on shared disks causing the systems to hang. I have WRKALL set on the minidisk that holds the control data sets and SHARED on all the full packs. There are no hits on IBM problem database has anyone come across this problem. Regards Stuart.
Re: Disk problems running Sysplex under VM
On 3/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm setting up a Sysplex using 3 Z/os 1.5 but I keep getting HCPVER575I I/O error add=0100, userid= ZPLEX2 on shared disks causing the systems to hang. So what *is* the error? Depending on your configuration they will be recorded in EREP on z/OS or z/VM. Alternatively, you could run an I/O trace to see what happens. If the MP3K is the only physical machine involved (and I believe it will since I don't think you can mix virtual machines and LPARs in a sysplex) then the SHARED is not needed. You will have your shared mini disks defined on one guest as MWV, and have the others link MW to it, right? Rob -- Rob van der Heij Velocity Software, Inc
Re: Disk problems running Sysplex under VM
On 3/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Long time since I used EREP I will see what I can remember ;-) No doubt more than what I know about the z/OS msgs... Maybe an I/O trace is at least as easy. In the z/OS virtual machine (where xxx is the virtual address to trace) #cp trace io xxx ccw printer When you are done you stop the trace and send the print file to MAINT so you can see it. #cp trace end #cp sp prt maint close I expect z/VM is just simulating the I/O error for z/OS. -- Rob van der Heij Velocity Software, Inc
3494 VTS on VM/ESA
We are trying to put a VTS on a VM/ESA 2.4 system. Yes, I know it's an old system... However, according to everything I've read, this should be possible - support for 3494 was in VM/ESA version 1.2 I believe. Has anyone out there done this? If so, can you help me get this lot going. I assume it's something I'm doing wrong ( - always assume you're doing something wrong, never blame the machines... :-) ?!? ). When I try to bring any of the addresses online, I receive a ... no channel path is available... message, HCPCPN6283I. I've done this on two different processor models - and when look at the hardware channel problem determination screens on the 2003/204 service processor, it tells me that there's a Link configuration problem - init failure - Channel/CU mismatch. The processor can 'see' the VTS because its serial number shows up and, on the VTS console service frames, the processor serial number shows up. However, there's no system generated Link Address, so I assume I have something wrong in the IOCDS. Various people have mentioned the LIBRARY-ID statement, but VM's IOCP doesn't recognise that. To begin with, the four CNTLUNIT/IODEVICE pairs in my IOCP source used to be coded thus: CNTLUNIT CUNUMBR=0700,PATH=4F,UNIT=3490, CUADD=0,UNITADD=((00,16)) IODEVICE ADDRESS=(700,16),CUNUMBR=0700,UNIT=3490,UNITADD=00 I made a couple of changes in a vain attempt to get it working - but to no avail: CNTLUNIT CUNUMBR=0700,PATH=4F,UNIT=3490, CUADD=0,UNITADD=((00,2)) IODEVICE ADDRESS=(700,2),CUNUMBR=0700,UNIT=3490,STADET=Y,UNITADD=00 Roy Harrop ** This email and any files transmitted with it are confidential. If you are not the intended recipient, please notify our Help Desk. Email [EMAIL PROTECTED] immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person. NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system and for other lawful purposes.
Re: Disk problems running Sysplex under VM
Rob O/P from erep. DEVICE NUMBER:0100REPORT: MIH EDITDAY YEAR JOB IDENTITY: ZPLEX2 SCP: VS 2 REL. 3 DATE: 067 06 E9D7D3C5E7F24040 DEVICE TYPE: 3390 CPU MODEL: 7060 HH MM SS.TH CHANNEL PATH ID: N/A CPU ID: 010BD9 TIME: 13 00 04.10 MISSING INTERRUPT: 08 - I/O TIMEOUT CONDITION SUBCHANNEL ID NUMBER: 00010002 FOR AN ACTIVE REQUEST VOLUME SERIAL: ZVMRES HH MM SS.TH UCB LEVEL BYTE:01 TIME INTERVAL: 00 00 15.00 RECOVERY ACTIONS PERFORMED BYTE: CC HALT OR CLEAR SUBCHANNEL 1 SIMULATED INTERRUPT 1 REDRIVE DEVICE0 REQUEUE I/O REQUEST 0 ISSUE MESSAGE 1 LOG THE CONDITION 1 BIT 6 0 BIT 7 0 HEX DUMP OF SUBCHANNEL INFORMATION BLOCK OFFSET00F3D7C8 289B0A84 80008080 0127FF80 0010 FDFF 0001 03C04400 0020 0030 HEX DUMP OF RECORD HEADER71831800 0006067F 13000410 1B010BD9 7060 0018 E9D7D3C5 E7F24040 00F3D7C8 289B0A84 80008080 0127FF80 FDFF 0038 0001 03C04400 F0F0F0F0 0058 F1F5F0F0 08CC 00010002 28988080 80FD FF01 0100 0078 0100 08008005 2024E9E5 D4D9C5E2 8000 0963 FF0001FF 1001 0098 DEVICE NUMBER:0100REPORT: MIH EDITDAY YEAR JOB IDENTITY: ZPLEX2 SCP: VS 2 REL. 3 DATE: 067 06 E9D7D3C5E7F24040 DEVICE TYPE: 3390 CPU MODEL: 7060 HH MM SS.TH CHANNEL PATH ID: N/A CPU ID: 010BD9 TIME: 13 00 20.08 MISSING INTERRUPT: 10 - START PENDING IN SUBCHANNEL SUBCHANNEL ID NUMBER: 00010002 VOLUME SERIAL: ZVMRES HH MM SS.TH UCB LEVEL BYTE:01 TIME INTERVAL: 00 00 15.00 RECOVERY ACTIONS PERFORMED BYTE: AC HALT OR CLEAR SUBCHANNEL 1 SIMULATED INTERRUPT 0 REDRIVE DEVICE1 REQUEUE I/O REQUEST 0 ISSUE MESSAGE 1 LOG THE CONDITION 1 BIT 6 0 BIT 7 0 HEX DUMP OF SUBCHANNEL INFORMATION BLOCK OFFSET00F3D7C8 289B0A84 80008080 0127FF80 0010 FDFF 0001 03C04400 0020 0030 HEX DUMP OF RECORD HEADER71831800 0006067F 13002008 1B010BD9 7060 0018 E9D7D3C5 E7F24040 00F3D7C8 289B0A84 80008080 0127FF80 FDFF 0038 0001 03C04400 F0F0F0F0 0058 F1F5F0F0 10BCBCAC 00010002 28988080 80FD FF01 0100 0078 0100 08008005 2024E9E5 D4D9C5E2 8000 0163 0100 1001 0098 01C06401 Stuart
Requirements for encrypting tape drives for z/VM
[Cross-posted to VMESA-L and LINUX-390] Hi, Everyone. The VM Development team needs your help once again. Back in July of last year, IBM published a Statement of Direction for encrypting tape drives (Announcement 105-241). We would like to know: - If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? If so, what are you using? - If you are not *currently* required to encrypt them, do you expect those requirements to be levied against you? If so, when? Thanks, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Requirements for encrypting tape drives for z/VM
We are currently exploring the possibility of encrypting all off-site backups. With only S/W products and the crypto engines currently available, it looks like encryption in the hardware will be our only viable option. So...we don't require it now but will in the not so distant future. Jack Jack H. Slavick Acxiom Corporation (312) 985 - 2827 [EMAIL PROTECTED] 03/08/06 3:11 PM [Cross-posted to VMESA-L and LINUX-390] Hi, Everyone. The VM Development team needs your help once again. Back in July of last year, IBM published a Statement of Direction for encrypting tape drives (Announcement 105-241). We would like to know: - If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? If so, what are you using? - If you are not *currently* required to encrypt them, do you expect those requirements to be levied against you? If so, when? Thanks, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Requirements for encrypting tape drives for z/VM
- If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? Yes. If so, what are you using? Emulated 3490 to inline SCSI encryption device to SCSI 3490-F01 on the MP3K, emulated 3490 to inline SCSI encryption device to DLT on Flex boxen. This (IMHO) is a really good reason to finish the SCSI tape device support and provide 3420/3480/3490 tape emulation for SCSI/FCP devices in CP. Encryption devices for SCSI/FCP equipment are commodity items, and are already in place for the open systems boxes. Why invent another wheel, especially since you've done it before, and existing solutions are in place and commercially available that have minimal performance impact on the zSeries side?
Re: Requirements for encrypting tape drives for z/VM
Quoting Alan Altmark [EMAIL PROTECTED]: - If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? If so, what are you using? - If you are not *currently* required to encrypt them, do you expect those requirements to be levied against you? If so, when? If you were to backup your (native) z/OS environment using these new fangled tape drives and then attempt to recover the environment while running under z/VM (disaster recovery), would that mean you'd need to have z/VM support? Or is the support just for data written directly by z/VM? Leland
Re: Requirements for encrypting tape drives for z/VM
--- Alan Altmark [EMAIL PROTECTED] wrote: Hi, Everyone. The VM Development team needs your help once again. Back in July of last year, IBM published a Statement of Direction for encrypting tape drives (Announcement 105-241). We would like to know: - If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? If so, what are you using? All of our backup/archive data should be encrypted as soon as we can find a mechanism to do it without an offsite contractor or non-mainframe attached hardware/processes. - If you are not *currently* required to encrypt them, do you expect those requirements to be levied against you? If so, when? It will probably be required as soon as we give up trying to encrypt this information. I estimate less that 12 months before such a requirement surfaces at some level in the department. /Thomas Kern /U.S. Department of Energy /301-903-2211 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Requirements for encrypting tape drives for z/VM
On Wednesday, 03/08/2006 at 03:53 CST, Leland Lucius [EMAIL PROTECTED] wrote: If you were to backup your (native) z/OS environment using these new fangled tape drives and then attempt to recover the environment while running under z/VM (disaster recovery), would that mean you'd need to have z/VM support? Yes. Alan Altmark z/VM Development IBM Endicott
Re: Vswitch problem on z/VM 5.2.0?
On Tue, 7 Mar 2006 18:00:16 -0500, Alan Altmark [EMAIL PROTECTED] wrote: In general, I recommend not sharing an OSA being used by a VSWITCH since our eventual adoption of protocols like GVRP will cause a mismatch if others are using the OSA with differe nt VLAN IDs. In your case, I recommend putting TCP/IP on a different OSA chpid (on an access port). Thanks. Since separate OSA's are scarce, would the next best thing be to put TCPIP on the VSWITCH? Are there any serious negatives to doing so? Brian Nielsen
Re: Requirements for encrypting tape drives for z/VM
Quoting Alan Altmark [EMAIL PROTECTED]: On Wednesday, 03/08/2006 at 03:53 CST, Leland Lucius [EMAIL PROTECTED] wrote: If you were to backup your (native) z/OS environment using these new fangled tape drives and then attempt to recover the environment while running under z/VM (disaster recovery), would that mean you'd need to have z/VM support? Yes. In that case, tape encryption is becoming a requirement where I work, but it will probably be done on the host until we find out it's gonna chew up too many resources and then someone will have to open up the wallet for drives. :-) So...probably...eventually. (How's that for a solid answer? ;-)) Leland
Re: Vswitch problem on z/VM 5.2.0?
On Wednesday, 03/08/2006 at 04:34 CST, Brian Nielsen [EMAIL PROTECTED] wrote: Thanks. Since separate OSA's are scarce, would the next best thing be to put TCPIP on the VSWITCH? Are there any serious negatives to doing so? That's fine. The only negative is that TCPIP cannot use a VSWITCH defined with TYPE ETHERNET. Alan Altmark z/VM Development IBM Endicott
Re: Requirements for encrypting tape drives for z/VM
We have requirements that tapes shipped out be encrypted. However, we don't ship any anymore since we've channel extended the tape drives to our own BCP center. I don't think our users ship anything anymore - but I'll check with some of them. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, March 08, 2006 1:12 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: [VMESA-L] Requirements for encrypting tape drives for z/VM [Cross-posted to VMESA-L and LINUX-390] Hi, Everyone. The VM Development team needs your help once again. Back in July of last year, IBM published a Statement of Direction for encrypting tape drives (Announcement 105-241). We would like to know: - If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? If so, what are you using? - If you are not *currently* required to encrypt them, do you expect those requirements to be levied against you? If so, when? Thanks, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: SSH for CMS could work
I didn't see any response to your post here, and only a little on the Lin ux-390 list. The catch is that fork() under CMS is not a true fork. It basically only works if fork() is followed very soon by exec(). The recommendation is that you replace fork() with s pawn(). That would be difficult if you don't have source. If you want SSH for CMS, I think you' ll need source, not modules copied from USS. If I remember correctly, a true fork() would require CP support to create a new address space for the child process -- CMS currently supports only one address space (not c ounting data spaces). From z/VM OpenExtensions Callable Services Reference Version 5 Release 1.0 Document Number SC24-6105-00 ... 2.30 fork (BPX1FRK) -- Create a New Process ... Note: The OpenExtensions implementation of the fork (BPX1FRK) service has some limitations not found in other implementations (see Characteristics and Restrictions). In certain situations, you may need to modify your application to accommodate these limitations. To avoid the limitations of fork (BPX1FRK), you should consider modifying your application to use spa wn (BPX1SPN). For information about converting fork() usage in a C/C++ program to spawn(), see the z/VM: CMS Application Development Guide. ... Characteristics and Restrictions 1. You must issue the CMS command OPENVM SET FORK ON before running an application that uses the fork() function. If the CMS FORK flag is not turned on, the application will receive a return value of -1, a return code of ENOSYS, and a reason code of JRFunct NotSupported. 2. You must run the application as a POSIX(ON) application. If this flag is not turned on, the application will receive a return value of -1, a return code of ENOSY S, and a reason code of JRFunctNotSupported. 3. The child process is not allowed to issue an exit() call or to ca ll any function that will invoke exit() before the child process issues the exec() function. Any at tempt to exit the child process before the exec() is issued will result in a X'AE5' abnormal end code. 4. The child process is not allowed to issue any function that will cause the child process to be blocked (for example, a pipe read() or a pause()), before the child issues the exec() function. Any attempt to exit the child process before the exec() is issued will re sult in a X'AE6' abnormal end code. 5. Any local variables in the application that are changed in the ch ild process before the exec() is issued will be changed in the parent process as well. This is b ecause the child and parent processes are still using the same program storage. The exec() function c auses the child process to begin using its own program storage. 6. Any global or environment variables in the application that are c hanged in the child process before the exec() is issued will be changed in the parent process as well. This is because the child and parent processes are still using the same program storage. The exec() function causes the child process to begin using its own program storage. On Thu, 23 Feb 2006 21:35:06 -0500, Rick Troth [EMAIL PROTECTED] wrote: I sent the following to the LINUX-390 list. Thought y'all here might also be interested. (And forgive me, I know there is some overlap.) I don't remember where Leland posted he experiences with z/OS (USS) binaries running on CMS (OpenVM). What it here? Because it's not all that relevant to Linux, except for the human interest ... er, uh ... academic interest of that story. PuTTY? We don't need no steenkin PuTTY! We CMSers! -- R; On Thu, 23 Feb 2006, Rick Troth wrote: Remember when Leland was compiling things on z/OS (USS) and then copying the binaries to CMS (OpenVM)? They ran without further effor t. Very nice ... some collab work betweek POK and Endicott (or maybe all LE magic? I don't know). We're in deep need of an SSH client for CMS. So I copied /usr/bin/ssh from one of our z/OS systems and dropped it into OpenVM. Lo and behold it does execute! Wants to fork, which is OFF by defau lt. SET FORK ON lets it do that, but it ABENDs immediately. Turns out it is trying to seed the pseudo random number generator and punting to a helper app which is causing crashing. (Another executable copied from USS, but does not fly.) I tried to fudge it with a quickly hacked helper (spitting out static seed content, just to get it running). This got SSH further, but still not all the way there. I'm excited!! We do need an SSH server for VM (CMS), but we need an SSH client even more: need it for automation. We also need SCP, which drives SSH under the covers and no doubt plays the fork() game. [sigh] -- R; = == ==
Re: Requirements for encrypting tape drives for z/VM
Alan, We have a requirement that media that leaves Bank premises and contains customer data must be encrypted with a Bank-approved algorithm. If the data isn't encrypted, it must be in the custody of a Bank employee while in transit (i.e. no FedEx). Our largest VM system uses channel-extended tape drives for DR backups, so it's not affected by this requirement. We briefly used the encryption feature in VM:Backup for DR backups of a smaller system, but VM:Backup uses the DES algorithm, which isn't on our approved list. We had to continue hand-carrying the tapes, so we turned off the encryption. AES is our preferred encryption algorithm, but Triple DES and a couple of others are also acceptable. Dennis O'Brien Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience. -- C.S. Lewis -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, March 08, 2006 13:12 To: VMESA-L@LISTSERV.UARK.EDU Subject: Requirements for encrypting tape drives for z/VM [Cross-posted to VMESA-L and LINUX-390] Hi, Everyone. The VM Development team needs your help once again. Back in July of last year, IBM published a Statement of Direction for encrypting tape drives (Announcement 105-241). We would like to know: - If you currently backup or archive z/VM data, does your business require that you encrypt said backups/archives? If so, what are you using? - If you are not *currently* required to encrypt them, do you expect those requirements to be levied against you? If so, when? Thanks, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development
