Re: How to stop PIPE STARMON
'STREAMSTATE INPUT' should not be required here...
My guess is that process has set the returncode to 0, so your
do-loop condition check is not testing the return code of READTO.
The pseudocode also suggests your stage does delay the record. You
should code it like this:
'PEEKTO INPUT' /* Get first record, without consuming it */
Do while rc=0
process
'READTO' /* consume the handled record */
'PEEKTO INPUT' /* get next record or stop */
end
2008/6/9 Berry van Sleeuwen [EMAIL PROTECTED]:
Hello Rob,
It looks like you are right. When testing, all stages end except the
colltest stage. Even more so, when gate severs the connections colltest
gets into a loop.
The stage reads:
Do while rc=0
readto input
process
end
When the gate stage kicks in, STARMON ends and so do the other stages.
Colltest however keeps on reading the input and very fast I must add (99%
cpu, 8000+ IO).
So I had to add a bit to the rexx stage:
Do while rc=0
streamstate input 0
if find('12 -4', rc) then rc = '12'
Else do
Readto input
process
end
end
Now the streamstate detects there is no inputstream, either not present o
r
no longer connected and sets rc to 12 if it is not already. Otherwise the
stage will process it's data. Now, when gate severs the inputstream the
colltest stage will end and so does the pipeline itself.
Thanks for your help.
Regards, Berry.
--
Kris Buelens,
IBM Belgium, VM customer support
Re: Unsupported Devices
Thanks, Alan. We may need that mod too. We are getting ready to extend our channels, but aren't quite there yet. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Monday, June 02, 2008 10:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Unsupported Devices On Mon, 2 Jun 2008 12:22:47 -0700, Schuh, Richard [EMAIL PROTECTED] wrote= : We have some devices from a vendor that are not tape drives, but which respond to Sense Id and Read Device Characteristics as though they are 3480-04s. This works fine for the older model of the device; however, the newer versions respond very badly to any legitimate tape command that is not included in a list of 5 CCW Op codes that they need. Unfortunately, Rewind and Unload is not a supported command. Because of this, CP gets a CE/DE/UC with Command Reject whenever one of these devices is detached from a user or a user logs off. This is not a good thing because it boxes the device. I can include RDEVICE statements in SYSTEM CONFIG to perhaps eliminate the RUN problem. My question is, what can I specify that will work? I can specify TYPE TAPE. Another possibility is TYPE UNSUPPORTED with DEVCLASS TAPE. Will CP still issue the RUN command for these devices if I include either of these potential circumventions? I would be surprised= if it did not. Is there a generic type and class I can use without fear of introducing other problems? It probably would not be much of a change= to HCPDTD to bypass the RUN for an address range; however, something is needed sooner rather than later. I have expressed an opinion to the vendor that if a device is going to tell the system that it is a 3480-04, then it ought not reject CCWs that= are legitimate for that type of device. It will probably be faster for me to modify CP than for them to modify their devices. Regards, Richard Schuh I would go with TYPE UNSUPPORTED with DEVCLASS TAPE. I doubt CP will iss= ue anything. (You or IBM will need to read the code.) IBM support came up with a revised CCW t= able for us for an UNSUPPORTED device (a channel extender) that didn't like one of the CCWs.= We carry this as a user mod. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Unsupported Devices
Mike, This is Alan's co-worker. This happened several years ago, so I could be fuzzy on the details. In our case, the devices were check sorters, not tape drives. They were bus-and-tag devices that should have been on a converted channel. Someone was trying to save channels, so they were on an ESCON channel with some other devices. The code that ran the sorters was issuing a CCW that wasn't valid for an ESCON channel, so VM was rejecting it. The correct solution would have been to put the devices on their own channel, and define the channel as a converted channel in IOCP. That would have cost money, so we changed the CCW table instead. IBM was very generous in helping us with something that wasn't really their problem. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rydberg Sent: Monday, June 09, 2008 08:49 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Unsupported Devices Alan, If your channel extender is a CNT/McDATA/Brocade product doing ESCON or FICON extension, I am curious which tape device model you have and which CCW's were not supported. Regards, Mike Rydberg Brocade Communications -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Monday, June 09, 2008 10:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Unsupported Devices Thanks, Alan. We may need that mod too. We are getting ready to extend our channels, but aren't quite there yet. Regards, Richard Schuh I would go with TYPE UNSUPPORTED with DEVCLASS TAPE. I doubt CP will iss= ue anything. (You or IBM will need to read the code.) IBM support came up with a revised CCW t= able for us for an UNSUPPORTED device (a channel extender) that didn't like one of the CCWs.= We carry this as a user mod. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Unsupported Devices
Dennis, I suspected that the problem may have involved B/T to ESCON conversion. You were likely using the CNT USD for ESCON extension with an Optica B/T convertor (which CNT re-sold as the NSBT). We provided UIMs that added custom device types such as B/T Tape models connected to ESCON channels, but I don't recall that we provided anything specific for VM or Check sorters. Most use NOCHECK in there IOCP these days. Thanks for the clarification, you satisfied my curiosity :) Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Monday, June 09, 2008 11:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Unsupported Devices Mike, This is Alan's co-worker. This happened several years ago, so I could be fuzzy on the details. In our case, the devices were check sorters, not tape drives. They were bus-and-tag devices that should have been on a converted channel. Someone was trying to save channels, so they were on an ESCON channel with some other devices. The code that ran the sorters was issuing a CCW that wasn't valid for an ESCON channel, so VM was rejecting it. The correct solution would have been to put the devices on their own channel, and define the channel as a converted channel in IOCP. That would have cost money, so we changed the CCW table instead. IBM was very generous in helping us with something that wasn't really their problem. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rydberg Sent: Monday, June 09, 2008 08:49 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Unsupported Devices Alan, If your channel extender is a CNT/McDATA/Brocade product doing ESCON or FICON extension, I am curious which tape device model you have and which CCW's were not supported. Regards, Mike Rydberg Brocade Communications -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Monday, June 09, 2008 10:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Unsupported Devices Thanks, Alan. We may need that mod too. We are getting ready to extend our channels, but aren't quite there yet. Regards, Richard Schuh I would go with TYPE UNSUPPORTED with DEVCLASS TAPE. I doubt CP will iss= ue anything. (You or IBM will need to read the code.) IBM support came up with a revised CCW t= able for us for an UNSUPPORTED device (a channel extender) that didn't like one of the CCWs.= We carry this as a user mod. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
The other data center is ours, just not a twin of the center where VM resides. Contractual first rights are not a consideration. The idea of two different VM:Backup machines and jobs might not be so far fetched. There is no requirement that the two backups be identical or nearly so. The requirement is that each backup must be a complete logical backup. Twinning tapes does this, but it is not the only solution. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Friday, June 06, 2008 5:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit We're doing similarly with a Sun/STK peered VTS for VM:Archiver. It creates the duplicate virtual volsers in the other campus without any work by VM:Backup (which does VM:Archiver tape I/O). Makes tape access for D.R. painlessly automatic. VM:Backup tapes are still twinned to external 3590 magStar carts in both data centers because z/OS has primary rights to the dual, peered VTS's. BTW, one thing to consider is dual data centers. It *is* costly to set up, but if you have nearly equal development/test vs production resource requirements, the cost justification becomes much simpler given that there is no D.R. provider cost, and recovery (assuming mirrored DASD) is very, very quick. Our z/VM system is ready for use about 15 minutes after we have the LPAR. The myriad z/OS systems are up in a few hours (DB2 recovery slows that down). Compare that to restore at a D.R. provider - presuming that it's just your data center that's lost. If it's a regional disaster and you're not first to declare the disaster, or the others have a contractual first dibbs - well, it could be 'a while'. Food for thought. Mike Walter Hewitt Associates - Original Message - From: Marcy Cortes [EMAIL PROTECTED] Sent: 06/06/2008 06:44 PM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Another option would be a peered VTS. At the moment that's how we're getting all the linux volumes there (although z/OS is doing the dumping and restoring of those w/DFDSS and not us using vm utilities). Marcy 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. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Friday, June 06, 2008 4:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This was actually our first option - remote shadow imaging. The high cost involved and the fundamental requirements of an actual disaster recovery eliminated the proposal. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson Sent: Friday, June 06, 2008 1:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Thinking laterally about this, there is always another solution. Have you thought about long-distance remote PPRC for your DASD. I am not sure if the official IBM PPRC-XD product can cope with 3000 miles but there are solutions that can. Colin Allinson Amadeus Data Processing GmbH The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: How to stop PIPE STARMON
On Mon, Jun 9, 2008 at 3:08 PM, Kris Buelens [EMAIL PROTECTED] wrote: 'STREAMSTATE INPUT' should not be required here... In most cases the suitable approach is to use signal on error do forever peekto .. process.. readto streamstate output end error: return rc * ( rc 12 ) The 'streamstate output' is something that I recently started to ensure backward propagation of eof into the stage (when the pipeline on my output has terminated, this also terminates the rexx stage).
Re: Backup: Twinning Tapes to Remote Tape Unit
Perhaps by measuring the amount of tape left on the spindle? A light, possibly laser, shining on a tangent to the spindle at a specified height could be detected only when the tape remaining is not thick enough to block the light. This would remove any dependence on stickers which are supposed to be x feet or x inches from the physical end of the tape. There are other possibilities. For example, compare the speed in RPM of the two spindles. When the take-up spindle is over half full, it moves at a slower RPM than the other in order to keep the same linear rate for the tape. This could be used to determine the EOT. I would hope that the use of stickers to denote EOT would have gone out way back in my career. We used stickers in pre-S/360 days and they were fraught with problems then. Have you ever had to clean the heads and capstans of a tape drive that had become fouled with a sticker that did not stay stuck? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Friday, June 06, 2008 8:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, June 06, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
DDR Minidisk Restore Problem.
Hello all, I’m having a problem restoring minidisks which I backed up using DDR. Backing them up all on one tape. I batched up a bunch of minidisks, a quick sample is below: SYSPRINT CONS PROMPTS OFF INPUT 12C4 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 1191 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 12A2 3390 OUTPUT 181 3590 (LEAVE DUMP ALL All are going to the same tape. The first mini at 12C4 is empty. But, this didn’t create any error during the dump process and all the other DDR Dumps complete with problems. However during the restore: SYSPRINT CONS PROMPTS OFF INPUT 181 3590 OUTPUT 12C4 3390 RESTORE ALL INPUT 181 3590 OUTPUT 1191 3390 RESTORE ALL INPUT 181 3590 OUTPUT 12A2 3390 RESTORE ALL Just the first minidisk restores to 12C4, which by the way there isn’t any records. Then I get an endless stream of CCW errors on the 181 tape. The minidisks to be restored are all R/W as an example indicates below: DASD 111F 3390 VPDPS1 R/W 8 CYL ON DASD 04B8 SUBCHANNEL = 0039 DASD 1191 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 002C DASD 129D 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 0032 To get to the first minidisk I did a: CP LINK USERA 11F 111F MW Links are all O.K. no errors on any of the links. Any thoughts on this would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: DDR Minidisk Restore Problem.
Hi Howard. Use the “( LEAVE” option as you did on the dump example. The default is to unload tape after the command completes. The first restore all will unload the tape so the other will try to run with and unloaded tape drive. Hans From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: June 9, 2008 4:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR Minidisk Restore Problem. Hello all, I’m having a problem restoring minidisks which I backed up using DDR. Backing them up all on one tape. I batched up a bunch of minidisks, a quick sample is below: SYSPRINT CONS PROMPTS OFF INPUT 12C4 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 1191 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 12A2 3390 OUTPUT 181 3590 (LEAVE DUMP ALL All are going to the same tape. The first mini at 12C4 is empty. But, this didn’t create any error during the dump process and all the other DDR Dumps complete with problems. However during the restore: SYSPRINT CONS PROMPTS OFF INPUT 181 3590 OUTPUT 12C4 3390 RESTORE ALL INPUT 181 3590 OUTPUT 1191 3390 RESTORE ALL INPUT 181 3590 OUTPUT 12A2 3390 RESTORE ALL Just the first minidisk restores to 12C4, which by the way there isn’t any records. Then I get an endless stream of CCW errors on the 181 tape. The minidisks to be restored are all R/W as an example indicates below: DASD 111F 3390 VPDPS1 R/W 8 CYL ON DASD 04B8 SUBCHANNEL = 0039 DASD 1191 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 002C DASD 129D 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 0032 To get to the first minidisk I did a: CP LINK USERA 11F 111F MW Links are all O.K. no errors on any of the links. Any thoughts on this would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: DDR Minidisk Restore Problem.
Howard, You might want to try using the SKIP parm on the INPUT statement to bypass the first file. My guess is that would allow you to restore the subsequent disks without issue. Ed Zell Illinois Mutual Life (309) 636-0107 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Monday, June 09, 2008 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR Minidisk Restore Problem. Hello all, I'm having a problem restoring minidisks which I backed up using DDR. Backing them up all on one tape. I batched up a bunch of minidisks, a quick sample is below: SYSPRINT CONS PROMPTS OFF INPUT 12C4 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 1191 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 12A2 3390 OUTPUT 181 3590 (LEAVE DUMP ALL All are going to the same tape. The first mini at 12C4 is empty. But, this didn't create any error during the dump process and all the other DDR Dumps complete with problems. However during the restore: SYSPRINT CONS PROMPTS OFF INPUT 181 3590 OUTPUT 12C4 3390 RESTORE ALL INPUT 181 3590 OUTPUT 1191 3390 RESTORE ALL INPUT 181 3590 OUTPUT 12A2 3390 RESTORE ALL Just the first minidisk restores to 12C4, which by the way there isn't any records. Then I get an endless stream of CCW errors on the 181 tape. The minidisks to be restored are all R/W as an example indicates below: DASD 111F 3390 VPDPS1 R/W 8 CYL ON DASD 04B8 SUBCHANNEL = 0039 DASD 1191 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 002C DASD 129D 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 0032 To get to the first minidisk I did a: CP LINK USERA 11F 111F MW Links are all O.K. no errors on any of the links. Any thoughts on this would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: DDR Minidisk Restore Problem.
The first minidisk being empty has nothing whatsoever to do with it. That is not an error condition unless the disk has not been initialized and had the Track Capacity Record, R0, written on each track. If that is the case, there is no r0 on any track and no volume serial on the disk. DDR happily copies a track that has no data on it. All it requires is R0. The copies go very quickly. If the mdisk that was dumped has been formatted, then there is an FST and the remainder of the disk is comprised of blocks of zeros. DDR is also happy with that. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Monday, June 09, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR Minidisk Restore Problem. Howard, You might want to try using the SKIP parm on the INPUT statement to bypass the first file. My guess is that would allow you to restore the subsequent disks without issue. Ed Zell Illinois Mutual Life (309) 636-0107 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Monday, June 09, 2008 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR Minidisk Restore Problem. Hello all, I'm having a problem restoring minidisks which I backed up using DDR. Backing them up all on one tape. I batched up a bunch of minidisks, a quick sample is below: SYSPRINT CONS PROMPTS OFF INPUT 12C4 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 1191 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 12A2 3390 OUTPUT 181 3590 (LEAVE DUMP ALL All are going to the same tape. The first mini at 12C4 is empty. But, this didn't create any error during the dump process and all the other DDR Dumps complete with problems. However during the restore: SYSPRINT CONS PROMPTS OFF INPUT 181 3590 OUTPUT 12C4 3390 RESTORE ALL INPUT 181 3590 OUTPUT 1191 3390 RESTORE ALL INPUT 181 3590 OUTPUT 12A2 3390 RESTORE ALL Just the first minidisk restores to 12C4, which by the way there isn't any records. Then I get an endless stream of CCW errors on the 181 tape. The minidisks to be restored are all R/W as an example indicates below: DASD 111F 3390 VPDPS1 R/W 8 CYL ON DASD 04B8 SUBCHANNEL = 0039 DASD 1191 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 002C DASD 129D 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 0032 To get to the first minidisk I did a: CP LINK USERA 11F 111F MW Links are all O.K. no errors on any of the links. Any thoughts on this would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. Confidentiality: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, please notify the sender and delete this e-mail from your system.
Re: DDR Minidisk Restore Problem.
Agreed. It would appear that Hans was right on when he mentioned using the (LEAVE parm on the restores so that the tape does not unload. I was just taking a guess based on what I knew at the time. Ed From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Monday, June 09, 2008 4:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR Minidisk Restore Problem. The first minidisk being empty has nothing whatsoever to do with it. That is not an error condition unless the disk has not been initialized and had the Track Capacity Record, R0, written on each track. If that is the case, there is no r0 on any track and no volume serial on the disk. DDR happily copies a track that has no data on it. All it requires is R0. The copies go very quickly. If the mdisk that was dumped has been formatted, then there is an FST and the remainder of the disk is comprised of blocks of zeros. DDR is also happy with that. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Monday, June 09, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR Minidisk Restore Problem. Howard, You might want to try using the SKIP parm on the INPUT statement to bypass the first file. My guess is that would allow you to restore the subsequent disks without issue. Ed Zell Illinois Mutual Life (309) 636-0107 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Monday, June 09, 2008 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR Minidisk Restore Problem. Hello all, I'm having a problem restoring minidisks which I backed up using DDR. Backing them up all on one tape. I batched up a bunch of minidisks, a quick sample is below: SYSPRINT CONS PROMPTS OFF INPUT 12C4 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 1191 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 12A2 3390 OUTPUT 181 3590 (LEAVE DUMP ALL All are going to the same tape. The first mini at 12C4 is empty. But, this didn't create any error during the dump process and all the other DDR Dumps complete with problems. However during the restore: SYSPRINT CONS PROMPTS OFF INPUT 181 3590 OUTPUT 12C4 3390 RESTORE ALL INPUT 181 3590 OUTPUT 1191 3390 RESTORE ALL INPUT 181 3590 OUTPUT 12A2 3390 RESTORE ALL Just the first minidisk restores to 12C4, which by the way there isn't any records. Then I get an endless stream of CCW errors on the 181 tape. The minidisks to be restored are all R/W as an example indicates below: DASD 111F 3390 VPDPS1 R/W 8 CYL ON DASD 04B8 SUBCHANNEL = 0039 DASD 1191 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 002C DASD 129D 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 0032 To get to the first minidisk I did a: CP LINK USERA 11F 111F MW Links are all O.K. no errors on any of the links. Any thoughts on this would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. Confidentiality: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, please notify the sender and delete this e-mail from your system. . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
CP Directory, profiles, and COMMAND: Could someone verify this for me...
We started with vSwitch grants in SYSTEM CONFIG, then moved to reading lists of Linux guests and dynamically granting them to the vSwitch. We then switched (no pun inteneded) to COMMAND statements in each CP Directory to grant the vSwitch and couple the NIC to the vSwitch. This seemed to be the most consistent and least intrusive method of emulating an open vSwitch, and reduced the need for adding users or config lines to other files. Except for one slight drawback: If the two COMMAND lines are in the user¹s CP Directory entry, then the grant is done, followed by the couple, and everything is happy. If the same two COMMAND lines are in a profile, included in the user¹s CP Directory entry, then it appears that either the commands are executed in the wrong order, the grant never gets executed, the grant executes but with the wrong or no userid, or the system doesn¹t allow the grant to complete before attempting the couple. In any case, the user does not get a working NIC coupled to the vSwitch. Could someone verify this behavior on their system? I¹m getting ready to open an ETR with IBM, but I¹d like verification that I¹m not overlooking something else... The minimal entries needed to recreate this are: TSTDFLT DIRECT: PROFILE TSTDFLT COMMAND SET VSWITCH VSWG GRANT USERID COMMAND COUPLE 8200 TO SYSTEM VSWG * MACH XA CONSOLE 0009 3215 T NICDEF 8200 TYPE QDIO LAN SYSTEM VSWG - TESTUSER DIRECT: USER TESTUSER 1G 2G G INCLUDE TSTDFLT * * * COMMAND SET VSWITCH VSWG GRANT USERID * COMMAND COUPLE 8200 TO SYSTEM VSWG * * CONSOLE 0009 3215 T * NICDEF 8200 TYPE QDIO LAN SYSTEM VSWG Try them this way; The user seems to never get granted. Then comment out the INCLUDE and uncomment the other four lines. The user gets granted the first attempt. Any comments or ideas? -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different.
Re: DDR Minidisk Restore Problem.
Thanks all. We will take a closer look at the source disks. Schuh, Richard [EMAIL PROTECTED] 6/9/2008 5:21 PM The first minidisk being empty has nothing whatsoever to do with it. That is not an error condition unless the disk has not been initialized and had the Track Capacity Record, R0, written on each track. If that is the case, there is no r0 on any track and no volume serial on the disk. DDR happily copies a track that has no data on it. All it requires is R0. The copies go very quickly. If the mdisk that was dumped has been formatted, then there is an FST and the remainder of the disk is comprised of blocks of zeros. DDR is also happy with that. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Monday, June 09, 2008 1:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR Minidisk Restore Problem. Howard, You might want to try using the SKIP parm on the INPUT statement to bypass the first file. My guess is that would allow you to restore the subsequent disks without issue. Ed Zell Illinois Mutual Life (309) 636-0107 From:The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Monday, June 09, 2008 3:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR Minidisk Restore Problem. Hello all, I’m having a problem restoring minidisks which I backed up using DDR. Backing them up all on one tape. I batched up a bunch of minidisks, a quick sample is below: SYSPRINT CONS PROMPTS OFF INPUT 12C4 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 1191 3390 OUTPUT 181 3590 (LEAVE DUMP ALL INPUT 12A2 3390 OUTPUT 181 3590 (LEAVE DUMP ALL All are going to the same tape. The first mini at 12C4 is empty. But, this didn’t create any error during the dump process and all the other DDR Dumps complete with problems. However during the restore: SYSPRINT CONS PROMPTS OFF INPUT 181 3590 OUTPUT 12C4 3390 RESTORE ALL INPUT 181 3590 OUTPUT 1191 3390 RESTORE ALL INPUT 181 3590 OUTPUT 12A2 3390 RESTORE ALL Just the first minidisk restores to 12C4, which by the way there isn’t any records. Then I get an endless stream of CCW errors on the 181 tape. The minidisks to be restored are all R/W as an example indicates below: DASD 111F 3390 VPDPS1 R/W 8 CYL ON DASD 04B8 SUBCHANNEL = 0039 DASD 1191 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 002C DASD 129D 3390 VPDPS1 R/W 9 CYL ON DASD 04B8 SUBCHANNEL = 0032 To get to the first minidisk I did a: CP LINK USERA 11F 111F MW Links are all O.K. no errors on any of the links. Any thoughts on this would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. Confidentiality: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, please notify the sender and delete this e-mail from your system. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
SFS Control Data Backup
Is there a way to change the threshold for initiation of a CDB dynamically or is it only in the start-up? Searching the File Pool Planning, Administration and Operation manual has so far turned up a blank. Regards, Richard Schuh
Re: Backup: Twinning Tapes to Remote Tape Unit
On Monday, 06/09/2008 at 04:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I would hope that the use of stickers to denote EOT would have gone out way back in my career. Reflective stickers went away with the 3480. It introduced a servo track that the drive uses to know the position of the tape at all times. EOT is at a certain physical block number, x. Every time. Bigger tape? Then you have a bigger value for x. The tape may be skipping bad data blocks on the tape, but they are at known locations and EOT still occurs at x, so the effective length will be less than the physical length. This is why degaussing today's tape cartridges results in a useless tape: the servo track is destroyed in the process. If you look at the sense data for today's drives, you'll see that it contains tons of block counters AND a [fuzzy] tape length indication. Alan Altmark z/VM Development IBM Endicott
Re: Backup: Twinning Tapes to Remote Tape Unit
I just knew that you (IBM) had to have done something about those stickers. They were a PITA. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, June 09, 2008 3:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit On Monday, 06/09/2008 at 04:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I would hope that the use of stickers to denote EOT would have gone out way back in my career. Reflective stickers went away with the 3480. It introduced a servo track that the drive uses to know the position of the tape at all times. EOT is at a certain physical block number, x. Every time. Bigger tape? Then you have a bigger value for x. The tape may be skipping bad data blocks on the tape, but they are at known locations and EOT still occurs at x, so the effective length will be less than the physical length. This is why degaussing today's tape cartridges results in a useless tape: the servo track is destroyed in the process. If you look at the sense data for today's drives, you'll see that it contains tons of block counters AND a [fuzzy] tape length indication. Alan Altmark z/VM Development IBM Endicott
