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.
