Re: FTP and Z/VM5.4
Cliff, I know you are running with multiple z/VM systems, each with VM:Tape and VM:Backup. Please be sure you reviewed the VMBACKUP CONFIG file from the system you are experiencing this behavior (do you see RESERVE TAPE commands being issued on all of your z/VM systems, or just this one [as opposed to RESERVE SCRATCH commands]). If you are sure your are seeing RESERVE TAPE commands issued by VM:Backup to VM:Tape (instead or RESERVE SCRATCH commands) and you are certain your VMBACKUP CONFIG states RESERVE OFF ... call the support center to open an issue because you should not. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of clifford jackson Sent: Friday, December 26, 2008 04:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP and Z/VM5.4 Hey JR I checked my VMBACKUP CONFIG and my reserve is set to off: CATDISK1B0 90 CHECKDISK 1D1 80 DIRECT 1A0 530RES POOLDISK 1C0 SYSDISK1E0 REPORTDISK 1E1 95 MAXFILES 2048 * RESERVE ON RESERVE OFF * RESTHOLD SURROGAT OFF * TAPEDISP UNLOAD * TAPEWAIT 180 1 * TAPEXPDT > Date: Fri, 26 Dec 2008 15:56:54 -0500 > From: steven.im...@ca.com > Subject: Re: FTP and Z/VM5.4 > To: IBMVM@LISTSERV.UARK.EDU > > Cliford, > > In general if you run with robotic tape interfaces with VM:Backup using VM:Tape you want to turn off RESERVE for tape drives ... the robotic systems needs to be able to choose the best available drive at the time of each mount request. RESERVE ON is the default. > > Chech your VMBACKUP CONFIG file for a RESERVE record ... again RESERVE ON is the default, so if you don't find one you are running with RESERVE ON. Add or change the record to RESERVE OFF. > > JR Imler > CA, Inc. > > > > From: The IBM z/VM Operating System on behalf of clifford jackson > Sent: Fri 12/26/2008 9:01 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FTP and Z/VM5.4 > > > Whats the work around for the following problem that i am having I am running CA's VMBACKUP and VMTAPE, I have four tape drive total when I start my daily backups VMTAPE assigns all four tape drives and looks for another and tells me there's 1 tape allocation the following is a console listing: > > VMYTAP070I There are 0 mounts and 1 allocations pending. > vmtape query alloc > VMTDRV144I Waiting for a 128track HPTC drive for VMBACKUP 0310 V10204. > VMTQRY142I There are now 1 pending drive allocation(s). > VMYINI006I 0.004 Ready; > > > Date: Thu, 25 Dec 2008 11:12:28 -0500 > > From: steven.im...@ca.com > > Subject: Re: FTP and Z/VM5.4 > > To: IBMVM@LISTSERV.UARK.EDU > > > > Jim, > > > > I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer, the authentication is done differently under z/VM 5.4. There were updates to the VM:Secure versions of these to support backward compatability that you likely do not have in place ... so accessing the older code is likely the cause of the problem. However, as you see, getting rid of them also works. > > > > JR Imler > > > > > > > > From: The IBM z/VM Operating System on behalf of Hughes, Jim > > Sent: Wed 12/24/2008 12:11 PM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: FTP and Z/VM5.4 > > > > > > > > We are experiencing abends during some of our FTP processes under Z/VM 5.4. I've discovered the source of one of them. > > > > > > > > We run some daily procedures involving ftp processes from our VMRMAINT(VMSECURE's Maint machine). All FTP processes were failing until we released the VMRAINT 194 minidisk. > > > > > > > > We were not having this problem before the upgrade to Z/VM 5.4. > > > > > > > > Perhaps the next step is to locate what is on the VMRMAINT 194 that causes FTP to blow off. > > > > > > > > Merry Christmas. > > > > > > > > > > > > Jim Hughes > > > > 603-271-5586 > > > > "It is fun to do the impossible." > > > > > > > > > > Send e-mail anywhere. No map, no compass. Get your Hotmail(r) account now. <http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_an ywhere_122008> It's the same Hotmail(r). If by "same" you mean up to 70% faster. Get your account now. <http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_bro ad1_122008>
Re: FTP and Z/VM5.4
Hey JR I checked my VMBACKUP CONFIG and my reserve is set to off: CATDISK1B0 90 CHECKDISK 1D1 80 DIRECT 1A0 530RES POOLDISK 1C0 SYSDISK1E0 REPORTDISK 1E1 95 MAXFILES 2048 * RESERVE ON RESERVE OFF * RESTHOLD SURROGAT OFF * TAPEDISP UNLOAD * TAPEWAIT 180 1* TAPEXPDT > Date: Fri, 26 Dec 2008 15:56:54 -0500> From: steven.im...@ca.com> Subject: Re: FTP and Z/VM5.4> To: IBMVM@LISTSERV.UARK.EDU> > Cliford,> > In general if you run with robotic tape interfaces with VM:Backup using VM:Tape you want to turn off RESERVE for tape drives ... the robotic systems needs to be able to choose the best available drive at the time of each mount request. RESERVE ON is the default.> > Chech your VMBACKUP CONFIG file for a RESERVE record ... again RESERVE ON is the default, so if you don't find one you are running with RESERVE ON. Add or change the record to RESERVE OFF.> > JR Imler> CA, Inc.> > > > From: The IBM z/VM Operating System on behalf of clifford jackson> Sent: Fri 12/26/2008 9:01 AM> To: IBMVM@LISTSERV.UARK.EDU> Subject: Re: FTP and Z/VM5.4> > > Whats the work around for the following problem that i am having I am running CA's VMBACKUP and VMTAPE, I have four tape drive total when I start my daily backups VMTAPE assigns all four tape drives and looks for another and tells me there's 1 tape allocation the following is a console listing:> > VMYTAP070I There are 0 mounts and 1 allocations pending. > vmtape query alloc > VMTDRV144I Waiting for a 128track HPTC drive for VMBACKUP 0310 V10204. > VMTQRY142I There are now 1 pending drive allocation(s). > VMYINI006I 0.004 Ready; > > > Date: Thu, 25 Dec 2008 11:12:28 -0500> > From: steven.im...@ca.com> > Subject: Re: FTP and Z/VM5.4> > To: IBMVM@LISTSERV.UARK.EDU> > > > Jim,> > > > I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer, the authentication is done differently under z/VM 5.4. There were updates to the VM:Secure versions of these to support backward compatability that you likely do not have in place ... so accessing the older code is likely the cause of the problem. However, as you see, getting rid of them also works.> > > > JR Imler> > > > > > > > From: The IBM z/VM Operating System on behalf of Hughes, Jim> > Sent: Wed 12/24/2008 12:11 PM> > To: IBMVM@LISTSERV.UARK.EDU> > Subject: FTP and Z/VM5.4> > > > > > > > We are experiencing abends during some of our FTP processes under Z/VM 5.4. I've discovered the source of one of them.> > > > > > > > We run some daily procedures involving ftp processes from our VMRMAINT(VMSECURE's Maint machine). All FTP processes were failing until we released the VMRAINT 194 minidisk.> > > > > > > > We were not having this problem before the upgrade to Z/VM 5.4.> > > > > > > > Perhaps the next step is to locate what is on the VMRMAINT 194 that causes FTP to blow off.> > > > > > > > Merry Christmas.> > > > > > > > > > > > Jim Hughes> > > > 603-271-5586> > > > "It is fun to do the impossible."> > > > > > > > > > Send e-mail anywhere. No map, no compass. Get your Hotmail® account now. <http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008> _ It’s the same Hotmail®. If by “same” you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008
Re: FTP and Z/VM5.4
Cliford, In general if you run with robotic tape interfaces with VM:Backup using VM:Tape you want to turn off RESERVE for tape drives ... the robotic systems needs to be able to choose the best available drive at the time of each mount request. RESERVE ON is the default. Chech your VMBACKUP CONFIG file for a RESERVE record ... again RESERVE ON is the default, so if you don't find one you are running with RESERVE ON. Add or change the record to RESERVE OFF. JR Imler CA, Inc. From: The IBM z/VM Operating System on behalf of clifford jackson Sent: Fri 12/26/2008 9:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP and Z/VM5.4 Whats the work around for the following problem that i am having I am running CA's VMBACKUP and VMTAPE, I have four tape drive total when I start my daily backups VMTAPE assigns all four tape drives and looks for another and tells me there's 1 tape allocation the following is a console listing: VMYTAP070I There are 0 mounts and 1 allocations pending. vmtape query alloc VMTDRV144I Waiting for a 128track HPTC drive for VMBACKUP 0310 V10204. VMTQRY142I There are now 1 pending drive allocation(s). VMYINI006I 0.004 Ready; > Date: Thu, 25 Dec 2008 11:12:28 -0500 > From: steven.im...@ca.com > Subject: Re: FTP and Z/VM5.4 > To: IBMVM@LISTSERV.UARK.EDU > > Jim, > > I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer, the > authentication is done differently under z/VM 5.4. There were updates to the > VM:Secure versions of these to support backward compatability that you likely > do not have in place ... so accessing the older code is likely the cause of > the problem. However, as you see, getting rid of them also works. > > JR Imler > > > > From: The IBM z/VM Operating System on behalf of Hughes, Jim > Sent: Wed 12/24/2008 12:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: FTP and Z/VM5.4 > > > > We are experiencing abends during some of our FTP processes under Z/VM 5.4. > I've discovered the source of one of them. > > > > We run some daily procedures involving ftp processes from our > VMRMAINT(VMSECURE's Maint machine). All FTP processes were failing until we > released the VMRAINT 194 minidisk. > > > > We were not having this problem before the upgrade to Z/VM 5.4. > > > > Perhaps the next step is to locate what is on the VMRMAINT 194 that causes > FTP to blow off. > > > > Merry Christmas. > > > > > > Jim Hughes > > 603-271-5586 > > "It is fun to do the impossible." > > Send e-mail anywhere. No map, no compass. Get your Hotmail® account now. <http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008>
Re: FTP and Z/VM5.4
Aside from Christy's good suggestion could it somehow be related to VM:Backup's EOV handling? When VMB hits EOV on a tape, it leaves the tapes mounted and calls for a new scratch, reading that volser and including it on the UTL (User Trailer Labels) of all the currently mounted tapes in that tape stream so that the stream can be reconstructed in the proper order in the event of a catalog loss. Not being at work, I can't look up the different VMBACKUP CONFIG setting that could affect this. Perhaps there is a setting that requires ALL tape drives (including the one needed at EOV) be allocated before the job begins. Such would keep you from getting a full tape into the backup before finding that you had overcommitted your available drives. Nonetheless, you don't want to run VM::Backups with every available drive in use (see above) unless you are 100% certain that you will NOT reach EOV - even after DASD usage increases, or skipping bad sections on tape. Now some questions for you: 1) Has this ever worked before? 2) Have you ever hit EOV on a backup tape before? 3) If so, what changed? E.g. - Smaller tape capacity, - Larger DASD allocations, - previous DASD allocations actually being used (as in CMS mdisk space getting fuller) - VMBACKUP CONFIG changes Mike Walter Hewitt Associates - Original Message - From: "clifford jackson" [cliffordjackson...@msn.com] Sent: 12/26/2008 09:01 AM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP and Z/VM5.4 Whats the work around for the following problem that i am having I am running CA's VMBACKUP and VMTAPE, I have four tape drive total when I start my daily backups VMTAPE assigns all four tape drives and looks for another and tells me there's 1 tape allocation the following is a console listing: VMYTAP070I There are 0 mounts and 1 allocations pending.vmtape query alloc VMTDRV144I Waiting for a 128track HPTC drive for VMBACKUP 0310 V10204. VMTQRY142I There are now 1 pending drive allocation(s). VMYINI006I 0.004 Ready; > Date: Thu, 25 Dec 2008 11:12:28 -0500> From: steven.im...@ca.com> Subject: Re: FTP and Z/VM5.4> To: IBMVM@LISTSERV.UARK.EDU> > Jim,> > I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer, the authentication is done differently under z/VM 5.4. There were updates to the VM:Secure versions of these to support backward compatability that you likely do not have in place ... so accessing the older code is likely the cause of the problem. However, as you see, getting rid of them also works.> > JR Imler> > > > From: The IBM z/VM Operating System on behalf of Hughes, Jim> Sent: Wed 12/24/2008 12:11 PM> To: IBMVM@LISTSERV.UARK.EDU> Subject: FTP and Z/VM5.4> > > > We are experiencing abends during some of our FTP processes under Z/VM 5.4. I've discovered the source of one of them.> > > > We run some daily procedures involving ftp processes from our VMRMAINT(VMSECURE's Maint machine). All FTP processes were failing until we released the VMRAINT 194 minidisk.> > > > We were not having this problem before the upgrade to Z/VM 5.4.> > > > Perhaps the next step is to locate what is on the VMRMAINT 194 that causes FTP to blow off.> > > > Merry Christmas.> > > > > > Jim Hughes> > 603-271-5586> > "It is fun to do the impossible."> > _ Send e-mail anywhere. No map, no compass. http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008 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: FTP and Z/VM5.4
Clifford,
You may want to check your VM:Backup console... It should show you the
information it is sending to VM:Tape.
Verify in your VM:Backup resource pools that the resource pool name (that
is being sent to VM:Tape) matches
a pool in your VM:Tape config. You may somehow be mixing tape types...?
Or, check your VM:Backup job template for your daily backup and verify how
many drives you are requesting
(which shows under 'Number of Tape Streams'). If you have more than 4 tape
streams, it will ask for more drives
than you have
Hope this helps - I'm sure there aren't many working today :-)
Christine Brogan - TPF/VM Systems Support
Information Technology Services Americas
Phone: 623-505-5366, Cell: 623-512-5883, IBM tieline 273-4647
Email: ccbro...@us.ibm.com
"The end of fear is where we begin - the moment we decided to let Love
in..." Goo Goo Dolls
clifford jackson
To
Sent by: The IBM IBMVM@LISTSERV.UARK.EDU
z/VM Operating cc
System
Re: FTP and Z/VM5.4
12/26/2008 07:01
AM
Please respond to
The IBM z/VM
Operating System
Whats the work around for the following problem that i am having I am
running CA's VMBACKUP and VMTAPE, I have four tape drive total when I start
my daily backups VMTAPE assigns all four tape drives and looks for another
and tells me there's 1 tape allocation the following is a console listing:
VMYTAP070I There are 0 mounts and 1 allocations pending.
vmtape query alloc
VMTDRV144I Waiting for a 128track HPTC drive for VMBACKUP 0310 V10204.
VMTQRY142I There are now 1 pending drive allocation(s).
VMYINI006I 0.004 Ready;
> Date: Thu, 25 Dec 2008 11:12:28 -0500
> From: steven.im...@ca.com
> Subject: Re: FTP and Z/VM5.4
> To: IBMVM@LISTSERV.UARK.EDU
>
> Jim,
>
> I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer,
the authentication is done differently under z/VM 5.4. There were updates
to the VM:Secure versions of these to support backward compatability that
you likely do not have in place ... so accessing the older code is likely
the cause of the problem. However, as you see, getting rid of them also
works.
>
> JR Imler
>
>
>
> From: The IBM z/VM Operating System on behalf of Hughes, Jim
> Sent: Wed 12/24/2008 12:11 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: FTP and Z/VM5.4
>
>
>
> We are experiencing abends during some of our FTP processes under Z/VM
5.4. I've discovered the source of one of them.
>
>
>
> We run some daily procedures involving ftp processes from our VMRMAINT
(VMSECURE's Maint machine). All FTP processes were failing until we
released the VMRAINT 194 minidisk.
>
>
>
> We were not having this problem before the upgrade to Z/VM 5.4.
>
>
>
> Perhaps the next step is to locate what is on the VMRMAINT 194 that
causes FTP to blow off.
>
>
>
> Merry Christmas.
>
>
>
>
>
> Jim Hughes
>
> 603-271-5586
>
> "It is fun to do the impossible."
>
>
Send e-mail anywhere. No map, no compass. Get your Hotmail® account now.
Re: FTP and Z/VM5.4
Whats the work around for the following problem that i am having I am running CA's VMBACKUP and VMTAPE, I have four tape drive total when I start my daily backups VMTAPE assigns all four tape drives and looks for another and tells me there's 1 tape allocation the following is a console listing: VMYTAP070I There are 0 mounts and 1 allocations pending.vmtape query alloc VMTDRV144I Waiting for a 128track HPTC drive for VMBACKUP 0310 V10204. VMTQRY142I There are now 1 pending drive allocation(s). VMYINI006I 0.004 Ready; > Date: Thu, 25 Dec 2008 11:12:28 -0500> From: steven.im...@ca.com> Subject: Re: FTP and Z/VM5.4> To: IBMVM@LISTSERV.UARK.EDU> > Jim,> > I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer, the authentication is done differently under z/VM 5.4. There were updates to the VM:Secure versions of these to support backward compatability that you likely do not have in place ... so accessing the older code is likely the cause of the problem. However, as you see, getting rid of them also works.> > JR Imler> > > > From: The IBM z/VM Operating System on behalf of Hughes, Jim> Sent: Wed 12/24/2008 12:11 PM> To: IBMVM@LISTSERV.UARK.EDU> Subject: FTP and Z/VM5.4> > > > We are experiencing abends during some of our FTP processes under Z/VM 5.4. I've discovered the source of one of them.> > > > We run some daily procedures involving ftp processes from our VMRMAINT(VMSECURE's Maint machine). All FTP processes were failing until we released the VMRAINT 194 minidisk.> > > > We were not having this problem before the upgrade to Z/VM 5.4.> > > > Perhaps the next step is to locate what is on the VMRMAINT 194 that causes FTP to blow off.> > > > Merry Christmas.> > > > > > Jim Hughes> > 603-271-5586> > "It is fun to do the impossible."> > _ Send e-mail anywhere. No map, no compass. http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008
Re: FTP and Z/VM5.4
Jim, I'ts likely RPIVAL and RPIUCMS ... they are not really needed any longer, the authentication is done differently under z/VM 5.4. There were updates to the VM:Secure versions of these to support backward compatability that you likely do not have in place ... so accessing the older code is likely the cause of the problem. However, as you see, getting rid of them also works. JR Imler From: The IBM z/VM Operating System on behalf of Hughes, Jim Sent: Wed 12/24/2008 12:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: FTP and Z/VM5.4 We are experiencing abends during some of our FTP processes under Z/VM 5.4. I've discovered the source of one of them. We run some daily procedures involving ftp processes from our VMRMAINT(VMSECURE's Maint machine). All FTP processes were failing until we released the VMRAINT 194 minidisk. We were not having this problem before the upgrade to Z/VM 5.4. Perhaps the next step is to locate what is on the VMRMAINT 194 that causes FTP to blow off. Merry Christmas. Jim Hughes 603-271-5586 "It is fun to do the impossible."
