No, Mike that is not it. Although TAPEMAP is nice, it is after the fact. Now I am thinking it may have been part of CA's CMS-EPIC or their VM backup/restore product... It may have made more sense when CPU speeds were slow and sw compression was costly. Thanks anyway.
On Thu, Mar 31, 2011 at 7:11 AM, Mike Walter <mike.wal...@aonhewitt.com>wrote: > > 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. >
