> I still seem to remember a program from long ago, and it may have been a
VSE program, that would tell you how many bytes would go to the tape, in
fact I think it told you how many feet of tape (2400/3400) would be used..
Is there any chance that you might be thinking of the public domain
TAPEMAP utility? It is run *after* the tape has been created, and
displays the estimated footage used. It's a very old utility, so I
suspect that the estimated footage has not been updated to support the
plethora of new hardware and software developed since then.
The output (with carriage control character) looks something like:
1TapeMap 3.066 z/VM Conversational Monitor System
07/12/10 18:03 z/VM CMS JQPUBLIC TAPEMAP
Page 1
Options specified: DISK TERM MAP LABELS
0The input tape is on a 3490-01 7-track tape drive at address 0181.
The tape was recorded at 38K bpi and is in IBM labeled format.
The tape was recorded with odd parity.
0Volume Owner Data
+______ ______________
123456
0File Dataset Name RecFm BlkSize LRecL Density Created Expires
+____ _________________ _____ _______ _____ _______ ________ ________
0001 QTRSTMTS.Q22010JM FB 16458 16458 200P 07/12/10 01/08/11
This is part 0002 of a file that begins on volume 504658.
This file is continued on another volume.
Block count: 745,677
0**** Logical End-of-Tape
0TapeMap read 745,682 blocks containing under 1K bytes. There
were 1 files. About 1072 feet of tape was used.
0End of TapeMap execution.
Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.
"Tom Huegel" <tehue...@gmail.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
03/30/2011 10:36 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: DDR Question
Slight brain fart, I didn't even think of hardware compression duh! I
guess the only real way to to do it is just experimentation.
I still seem to remember a program from long ago, and it may have been a
VSE program, that would tell you how many bytes would go to the tape, in
fact I think it told you how many feet of tape (2400/3400) would be used..
Thanks guys.
On Wed, Mar 30, 2011 at 5:14 PM, Tom Duerbusch <duerbus...@stlouiscity.com
> wrote:
If you are doing software compression, then, perhaps use the Pipe DDR
stage and route it to the "count" stage.
But knowing how much compression the hardware will do....not obvious to
me.
However, once you do have a compressed tape, DITTO TMP will tell you how
much tape the compressed dataset took on the media.
Tom Duerbusch
THD Consulting
>>> Rich Greenberg <ric...@panix.com> 3/30/2011 4:55 PM >>>
On: Wed, Mar 30, 2011 at 11:37:00AM -0700,Tom Huegel Wrote:
} That doesn't show the compressed byte count is (would be). The goal here
is
} to be able to predict how many tapes I will need to do backups.
If you are doing hardware compression in the tape drive, I don't think
there is any way for DDR to know the compressed byte count. Software
compression, yes it would.
I suspect that the easiest way to determine the tape counts will be
experimentally.
--
Rich Greenberg Sarasota, FL, USA richgr atsign panix.com + 1 941 378
2097
Eastern time. N6LRT I speak for myself & my dogs only. VM'er since
CP-67
Canines: Val, Red, Shasta, Zero & Casey (At the bridge)
Owner:Chinook-L
Canines: Red & Cinnar (Siberians) Retired at the beach Asst
Owner:Sibernet-L
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.
