Re: How to find current tape length programatically
On Mon, 4 Feb 2008 11:58:22 -0700, David Logan [EMAIL PROTECTED] wrote: Yes, I'm writing to 3490E cartridges, afaik. I didn't know that they were being discontinued. I'm going to have to find documentation on that. Hi David, On this page: http://www.imation.com/products/data_center_tape/3480_3490E_tape_cartrid ges.html 3490E BlackWatch End of Life Imation is announcing the end of life on 3490E BlackWatch cartridges. This product is being discontinued and will only be available while supplies last. Please use 3490E Royal Guard product for all future 3490E requirements. An E-mail I received from Imation also said: The website will be updated shortly to reflect that 3490E and 3480 will be end of life. (Royal Guard and Black Watch) There may be other manufacturers; although Imation owns Memorex and picked up the remains of EMTEC (BASF). Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
... Please use 3490E Royal Guard product for all future 3490E requirements. ... Doesn't this mean that they are only discontinuing a particular type of 3490E? The way I read this, they are not discontinuing making this type of tape, just that make. David Logan -Original Message- From: Mike Baldwin [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 8:28 AM To: IBM-MAIN@BAMA.UA.EDU; David Logan Cc: Mike Baldwin Subject: Re: How to find current tape length programatically On Mon, 4 Feb 2008 11:58:22 -0700, David Logan [EMAIL PROTECTED] wrote: Yes, I'm writing to 3490E cartridges, afaik. I didn't know that they were being discontinued. I'm going to have to find documentation on that. Hi David, On this page: http://www.imation.com/products/data_center_tape/3480_3490E_tape_cartrid ges.html 3490E BlackWatch End of Life Imation is announcing the end of life on 3490E BlackWatch cartridges. This product is being discontinued and will only be available while supplies last. Please use 3490E Royal Guard product for all future 3490E requirements. An E-mail I received from Imation also said: The website will be updated shortly to reflect that 3490E and 3480 will be end of life. (Royal Guard and Black Watch) There may be other manufacturers; although Imation owns Memorex and picked up the remains of EMTEC (BASF). Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
On Wed, 6 Feb 2008 08:33:14 -0700, David Logan [EMAIL PROTECTED] wrote: ... Please use 3490E Royal Guard product for all future 3490E requirements. ... Doesn't this mean that they are only discontinuing a particular type of 3490E? The way I read this, they are not discontinuing making this type of tape, just that make. David Logan Hi David, Yes, it does, and that is inconsistent with what I recently heard. Therefore, I contacted Imation and: An E-mail I received from Imation also said: The website will be updated shortly to reflect that 3490E and 3480 will be end of life. (Royal Guard and Black Watch) That means all 3490E (and 3480). Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
Yes, I'm writing to 3490E cartridges, afaik. I didn't know that they were being discontinued. I'm going to have to find documentation on that. The requirements are easy. We ship tapes to a hardware duplication service. That means they mount our tape on one side, and a stack of tapes on the other side, and push a button. Thus, the data on the source tape must be under the guaranteed tape length, otherwise some of the target tapes won't be long enough. So, I can have multi-volume datasets, BUT, the portion of each file must be under the guaranteed minimum length. What our other office does is this: They write files to tape. When they hit a file that causes a tape switch, they back off, rerun the job with one less file, and start another tape with that file. Very crude. I want a better way. I want to be able to write X number of IDRC compressed (bytes/blocks) to a tape, and know for a fact that I am up to the point of guaranteed tape length, and then switch tapes. On a 3480 without IDRC compression, it's easy. I write 8,139 blocks if 24,576 bytes. Then I switch tapes. On a drive with compression, it's not that easy. And I don't like the way my other shop does it. It's hokey, manual and error prone. David Logan -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Baldwin Sent: Monday, February 04, 2008 10:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How to find current tape length programatically On Fri, 1 Feb 2008 07:09:04 -0700, David Logan [EMAIL PROTECTED] wrote: I'll start hunting down the block ID value in the 3490 commands today. I think I'm going to have to issue my own EXCPs though. Hi David, The Read Block ID command (x'22') is documented in IBM 3490E Hardware Reference, e.g. GA32-0219. If you wish to avoid EXCP, you might be able to use the NOTE macro with TYPE=ABS operand. See z/OS DFSMS Macro Instructions for Data Sets, SC26- 7408. I wonder about your requirements though. - Are you writing to real 3490E cartridges? The same ones that I believe will no longer be manufactured in only a few weeks from now? (If so, I know where there are 10,000 still shrink-wrapped on a raised floor...let me know!) - Isn't tape duplication that cannot have multi-file tapes (or did you mean multi-volume) of limited value? I respectfully disagree with Mr. Witt that this is easier with 3590 and above, because AFAIK you must first obtain a licence from IBM for 3590 S/390 Hardware Interface Information, or reverse engineer the new commands. If you already have the licence, then yes it's easier. (I suppose someone could accidentally give you the information, but that doesn't happen). Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
On Fri, 1 Feb 2008 07:09:04 -0700, David Logan [EMAIL PROTECTED] wrote: I'll start hunting down the block ID value in the 3490 commands today. I think I'm going to have to issue my own EXCPs though. Hi David, The Read Block ID command (x'22') is documented in IBM 3490E Hardware Reference, e.g. GA32-0219. If you wish to avoid EXCP, you might be able to use the NOTE macro with TYPE=ABS operand. See z/OS DFSMS Macro Instructions for Data Sets, SC26- 7408. I wonder about your requirements though. - Are you writing to real 3490E cartridges? The same ones that I believe will no longer be manufactured in only a few weeks from now? (If so, I know where there are 10,000 still shrink-wrapped on a raised floor...let me know!) - Isn't tape duplication that cannot have multi-file tapes (or did you mean multi-volume) of limited value? I respectfully disagree with Mr. Witt that this is easier with 3590 and above, because AFAIK you must first obtain a licence from IBM for 3590 S/390 Hardware Interface Information, or reverse engineer the new commands. If you already have the licence, then yes it's easier. (I suppose someone could accidentally give you the information, but that doesn't happen). Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
On Mon, 4 Feb 2008 11:58:22 -0700, David Logan [EMAIL PROTECTED] wrote: Yes, I'm writing to 3490E cartridges, afaik. I didn't know that they were being discontinued. I'm going to have to find documentation on that. The requirements are easy. We ship tapes to a hardware duplication service. That means they mount our tape on one side, and a stack of tapes on the other side, and push a button. Thus, the data on the source tape must be under the guaranteed tape length, otherwise some of the target tapes won't be long enough. So, I can have multi-volume datasets, BUT, the portion of each file must be under the guaranteed minimum length. What our other office does is this: They write files to tape. When they hit a file that causes a tape switch, they back off, rerun the job with one less file, and start another tape with that file. Very crude. I want a better way. I want to be able to write X number of IDRC compressed (bytes/blocks) to a tape, and know for a fact that I am up to the point of guaranteed tape length, and then switch tapes. On a 3480 without IDRC compression, it's easy. I write 8,139 blocks if 24,576 bytes. Then I switch tapes. On a drive with compression, it's not that easy. And I don't like the way my other shop does it. It's hokey, manual and error prone. When I wrote a tape stacking program (REXX) a long time ago I just assumed a certain amount of compression based on IDRC or LZ-1 and I also set a fudge factor for when I would consider the tape full. I had a few clients that used my program and I got excellent results. After the customization values were set (after some test runs) we never ran into problems with a tape switch. I had a client that ran the stacking program every couple of months so all their media could fit in their automated library. Here is an example of the values set in the customization section of my program: MAXHOLD = 8/* 3490E 36 track tape will hold 800M*/ TAPEFULL = 75000/* start new tape if at least 750M */ SKIPAMT = 15000/* if tape has 150M or more, skip it it */ COMPRESS = 50 /* assume 50% compression for IDRC tapes */ MAXVB= 90 /* assume 90% of vb records are max */ Here is a some more of the code that showed how I calculated how full the tape was: /* */ /* Calculate approximate amount of tape used. */ /* */ TAPEUSED = BLKSIZE * BLKCOUNT /* */ /* */ /* If variable records - assume MAXVB% are the max lrecl */ /* */ If VARBIT = 'ON' then TAPEUSED = TAPEUSED * (MAXVB /100) /* */ /* If compacted tape (IDRC) - assume COMPRESS% compaction - or */ /* if uncompacted tape and the output will be compacted*/ /* assume COMPRESS% compaction */ /* */ If TMDEN = '38KC' | IDRC = 'YES' then , TAPEUSED = TAPEUSED * (1-(COMPRESS/100)) /* */ /* Add in the Inter Block Gaps (IBG) */ /* */ /* The density of a 3480 cartrige is: */ /* 1491 characters per millimeter American National Standard */ /* */ /* 1 inch = 2.54 centimeters or 25.4 millimeters */ /* 1 character = 1 byte*/ /* 1491 * 25.4 = 37871 bytes per inch (38K BPI) */ /* */ /* The IBG is .08 inches */ /* 37871 * .08 = 3030 bytes */ /* */ If TMDEN '3590' then , /* 3590 IBG is always compressed*/ TAPEUSED = TAPEUSED + (BLKCOUNT * 3030) /* add in IBGs*/ /* */ You can see the entire program called TAPESTAK on CBT file 434 or my web site in the programs section. URL below. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Re: How to find current tape length programatically
I believe (I can be wrong here), that DFSMShsm do it in the following way: it writes data until end of volume, then it moves back a number of blocks. The number is counted as percentage of the tape. You can followe this way or simply use ABARS. BTW: Do you really need to create the TAPES ? 3490E is really obsolete, it will become more and more exotic and expensive. The same amount of data can be easily written on DVD media. DVD burner is approx. $50, you can make two copies at once, DVD media is less than for peanuts. Every mainframe can transmit the data to locally-attached PC. It's easier and cheaper to attach PC, than 3490E. Why bother with tapes ? BTW: Real story. I had to install some software at customer site. The software was distributed on few CD's and one piece was on 3490E. It took me almost *all the day* to read data from tape (unit name, free drive, contact with operators, proper authorizations, etc.), while the CDs were uploaded within half an hour. -- Radoslaw Skorupka Lodz, Poland David Logan wrote: Yes, I'm writing to 3490E cartridges, afaik. I didn't know that they were being discontinued. I'm going to have to find documentation on that. The requirements are easy. We ship tapes to a hardware duplication service. That means they mount our tape on one side, and a stack of tapes on the other side, and push a button. Thus, the data on the source tape must be under the guaranteed tape length, otherwise some of the target tapes won't be long enough. So, I can have multi-volume datasets, BUT, the portion of each file must be under the guaranteed minimum length. What our other office does is this: They write files to tape. When they hit a file that causes a tape switch, they back off, rerun the job with one less file, and start another tape with that file. Very crude. I want a better way. I want to be able to write X number of IDRC compressed (bytes/blocks) to a tape, and know for a fact that I am up to the point of guaranteed tape length, and then switch tapes. On a 3480 without IDRC compression, it's easy. I write 8,139 blocks if 24,576 bytes. Then I switch tapes. On a drive with compression, it's not that easy. And I don't like the way my other shop does it. It's hokey, manual and error prone. David Logan -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
Thanks Mark! I will look at this as a possible solution. David Logan -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, February 04, 2008 1:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How to find current tape length programatically On Mon, 4 Feb 2008 11:58:22 -0700, David Logan [EMAIL PROTECTED] wrote: Yes, I'm writing to 3490E cartridges, afaik. I didn't know that they were being discontinued. I'm going to have to find documentation on that. The requirements are easy. We ship tapes to a hardware duplication service. That means they mount our tape on one side, and a stack of tapes on the other side, and push a button. Thus, the data on the source tape must be under the guaranteed tape length, otherwise some of the target tapes won't be long enough. So, I can have multi-volume datasets, BUT, the portion of each file must be under the guaranteed minimum length. What our other office does is this: They write files to tape. When they hit a file that causes a tape switch, they back off, rerun the job with one less file, and start another tape with that file. Very crude. I want a better way. I want to be able to write X number of IDRC compressed (bytes/blocks) to a tape, and know for a fact that I am up to the point of guaranteed tape length, and then switch tapes. On a 3480 without IDRC compression, it's easy. I write 8,139 blocks if 24,576 bytes. Then I switch tapes. On a drive with compression, it's not that easy. And I don't like the way my other shop does it. It's hokey, manual and error prone. When I wrote a tape stacking program (REXX) a long time ago I just assumed a certain amount of compression based on IDRC or LZ-1 and I also set a fudge factor for when I would consider the tape full. I had a few clients that used my program and I got excellent results. After the customization values were set (after some test runs) we never ran into problems with a tape switch. I had a client that ran the stacking program every couple of months so all their media could fit in their automated library. Here is an example of the values set in the customization section of my program: MAXHOLD = 8/* 3490E 36 track tape will hold 800M*/ TAPEFULL = 75000/* start new tape if at least 750M */ SKIPAMT = 15000/* if tape has 150M or more, skip it it */ COMPRESS = 50 /* assume 50% compression for IDRC tapes */ MAXVB= 90 /* assume 90% of vb records are max */ Here is a some more of the code that showed how I calculated how full the tape was: /* */ /* Calculate approximate amount of tape used. */ /* */ TAPEUSED = BLKSIZE * BLKCOUNT /* */ /* */ /* If variable records - assume MAXVB% are the max lrecl */ /* */ If VARBIT = 'ON' then TAPEUSED = TAPEUSED * (MAXVB /100) /* */ /* If compacted tape (IDRC) - assume COMPRESS% compaction - or */ /* if uncompacted tape and the output will be compacted*/ /* assume COMPRESS% compaction */ /* */ If TMDEN = '38KC' | IDRC = 'YES' then , TAPEUSED = TAPEUSED * (1-(COMPRESS/100)) /* */ /* Add in the Inter Block Gaps (IBG) */ /* */ /* The density of a 3480 cartrige is: */ /* 1491 characters per millimeter American National Standard */ /* */ /* 1 inch = 2.54 centimeters or 25.4 millimeters */ /* 1 character = 1 byte*/ /* 1491 * 25.4 = 37871 bytes per inch (38K BPI) */ /* */ /* The IBG is .08 inches */ /* 37871 * .08 = 3030 bytes */ /* */ If TMDEN '3590' then , /* 3590 IBG is always compressed*/ TAPEUSED = TAPEUSED + (BLKCOUNT * 3030) /* add in IBGs*/ /* */ You can see the entire program called TAPESTAK on CBT file 434 or my web site in the programs section
Re: How to find current tape length programatically
I've been scouring the device and control unit commands for IDRC compression ratio, and have found nothing whatsoever. I am going to have to try this solution I think. I'm a bit worried though, because I'm not yet sure how this solution will actually tell me that I am within the minimum guaranteed length on a 3490/3490E. For example, with 3480's, our tape duplication service says that if I write 8139 blocks of 24576 each, they guarantee it will fit on any 3480 they are writing to. If I'm counting block ID, I presume this would be physically written block, and not my IDRC compressed block? In other words, say I wrote 300MB of horribly compressed data, and 800MB of greatly compressed data to the exact same tape: Block ID would still progress to the exact same block id #, then decrease? I'll start hunting down the block ID value in the 3490 commands today. I think I'm going to have to issue my own EXCPs though. It doesn't appear that I get any useful information (yet) from the UCB. David Logan -Original Message- From: Russell Witt [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 7:14 AM To: 'IBM Mainframe Discussion List' Cc: 'David Logan'; [EMAIL PROTECTED] Subject: RE: How to find current tape length programatically David, For the older 3480/3490 with IDRC, it is much harder. With 3490/E, it is much easier to determine by looking at the block-id. The logical block-ID increases as the physical blocks of data are written out; and then decreases as the second set of tracks are written coming back to the load-point (with a bit on to indicate that it is on the returning set of tracks). As the block-ID approaches zero with this bit on; you are getting closer and closer to the load-point (physical-end-of-tape). Remember, you have one set of tracks going out and one set of tracks coming back. For 3590 and above it is even easier. There is another value that can be obtained that contains a 1-byte x'yy' value. The yy is the fraction of the tape that has been used with 256 as the factor. So, if this 1-byte value is 128; then the tape is 128/256 full, or one-half full. And this is the PHYSICAL measure of how full the tape is. This value can be obtained from the device as well, though it is not in the sense information (can't remember if it is device characteristics or media characteristics); but it is available as well. In both cases, you must do something (read blockid, read device characteristics) to get the information back. Counting blocks of data written won't help at all with IDRC of course. Russell Witt CA Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of David Logan Sent: Friday, January 18, 2008 8:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: How to find current tape length programatically If I was to a tape, is there a way to programmatically know when I am nearing, or have hit, the end of the guaranteed tape length? I forget if it's 3480 or 3490E tape that guarantees 1100 feet, but if I were writing to a tape, is there a way to find out that I was still under this value? Our tape duplication service does a tape-to-tape hardware copy, so we cannot have multi-file tapes, so we cannot simply write to EOT and switch to the next tape. We need a way to write EOT within the minimum tape length specification. In particular, I am questioning whether or not I will ever be able to find out if I am still within my minimum specification when I am using IDRC compression. Admittedly, I know very little about what the actual tape looks like when I use compression. Maybe there is a better way to stay within the minimum tape length than to find out how much tape I have written. Any ideas? On either knowing tape length, or my root problem, knowing when to stop writing compressed data to stay within the specification? Thanks! David Logan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
David Logan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... If I was to a tape, is there a way to programmatically know when I am nearing, or have hit, the end of the guaranteed tape length? I forget if it's 3480 or 3490E tape that guarantees 1100 feet, but if I were writing to a tape, is there a way to find out that I was still under this value? Our tape duplication service does a tape-to-tape hardware copy, so we cannot have multi-file tapes, so we cannot simply write to EOT and switch to the next tape. We need a way to write EOT within the minimum tape length specification. In particular, I am questioning whether or not I will ever be able to find out if I am still within my minimum specification when I am using IDRC compression. Admittedly, I know very little about what the actual tape looks like when I use compression. Maybe there is a better way to stay within the minimum tape length than to find out how much tape I have written. Any ideas? On either knowing tape length, or my root problem, knowing when to stop writing compressed data to stay within the specification? Thanks! David Logan I know how our Dasd Management product does it: It gets the tape code from the control unit and decides from its own internal table the real tapelength. I suppose you have this value for a given tape. Then it writes to the tape, asks the IDRC compression ratio from the control unit and calculated the number of feet consumed by the written blocks and their interblock gaps. It then knows how much tape is left and if more data will fit. Hope this helps. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
How to find current tape length programatically
If I was to a tape, is there a way to programmatically know when I am nearing, or have hit, the end of the guaranteed tape length? I forget if it's 3480 or 3490E tape that guarantees 1100 feet, but if I were writing to a tape, is there a way to find out that I was still under this value? Our tape duplication service does a tape-to-tape hardware copy, so we cannot have multi-file tapes, so we cannot simply write to EOT and switch to the next tape. We need a way to write EOT within the minimum tape length specification. In particular, I am questioning whether or not I will ever be able to find out if I am still within my minimum specification when I am using IDRC compression. Admittedly, I know very little about what the actual tape looks like when I use compression. Maybe there is a better way to stay within the minimum tape length than to find out how much tape I have written. Any ideas? On either knowing tape length, or my root problem, knowing when to stop writing compressed data to stay within the specification? Thanks! David Logan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
Two great answers right away, thanks! I *love* the get the compression ratio solution, it sounds perfect so far. I have an obvious question on the 3490E though. You say there is a set of tracks going AND coming. Since actual tape length isn't a specification, just a minimum is, how would a hardware duplication device handle a 3490E? In theory it wouldn't be able to, would it? David Logan -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM Sent: Friday, January 18, 2008 7:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How to find current tape length programatically David Logan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... If I was to a tape, is there a way to programmatically know when I am nearing, or have hit, the end of the guaranteed tape length? I forget if it's 3480 or 3490E tape that guarantees 1100 feet, but if I were writing to a tape, is there a way to find out that I was still under this value? Our tape duplication service does a tape-to-tape hardware copy, so we cannot have multi-file tapes, so we cannot simply write to EOT and switch to the next tape. We need a way to write EOT within the minimum tape length specification. In particular, I am questioning whether or not I will ever be able to find out if I am still within my minimum specification when I am using IDRC compression. Admittedly, I know very little about what the actual tape looks like when I use compression. Maybe there is a better way to stay within the minimum tape length than to find out how much tape I have written. Any ideas? On either knowing tape length, or my root problem, knowing when to stop writing compressed data to stay within the specification? Thanks! David Logan I know how our Dasd Management product does it: It gets the tape code from the control unit and decides from its own internal table the real tapelength. I suppose you have this value for a given tape. Then it writes to the tape, asks the IDRC compression ratio from the control unit and calculated the number of feet consumed by the written blocks and their interblock gaps. It then knows how much tape is left and if more data will fit. Hope this helps. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Addendum: How to find current tape length programatically
I hate it when I forget words and my brain fills them in. If I was WRITING to a tape... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Logan Sent: Friday, January 18, 2008 7:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: How to find current tape length programatically If I was to a tape, is there a way to programmatically know when I am nearing, or have hit, the end of the guaranteed tape length? I forget if it's 3480 or 3490E tape that guarantees 1100 feet, but if I were writing to a tape, is there a way to find out that I was still under this value? ... snip ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
David, For the older 3480/3490 with IDRC, it is much harder. With 3490/E, it is much easier to determine by looking at the block-id. The logical block-ID increases as the physical blocks of data are written out; and then decreases as the second set of tracks are written coming back to the load-point (with a bit on to indicate that it is on the returning set of tracks). As the block-ID approaches zero with this bit on; you are getting closer and closer to the load-point (physical-end-of-tape). Remember, you have one set of tracks going out and one set of tracks coming back. For 3590 and above it is even easier. There is another value that can be obtained that contains a 1-byte x'yy' value. The yy is the fraction of the tape that has been used with 256 as the factor. So, if this 1-byte value is 128; then the tape is 128/256 full, or one-half full. And this is the PHYSICAL measure of how full the tape is. This value can be obtained from the device as well, though it is not in the sense information (can't remember if it is device characteristics or media characteristics); but it is available as well. In both cases, you must do something (read blockid, read device characteristics) to get the information back. Counting blocks of data written won't help at all with IDRC of course. Russell Witt CA Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of David Logan Sent: Friday, January 18, 2008 8:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: How to find current tape length programatically If I was to a tape, is there a way to programmatically know when I am nearing, or have hit, the end of the guaranteed tape length? I forget if it's 3480 or 3490E tape that guarantees 1100 feet, but if I were writing to a tape, is there a way to find out that I was still under this value? Our tape duplication service does a tape-to-tape hardware copy, so we cannot have multi-file tapes, so we cannot simply write to EOT and switch to the next tape. We need a way to write EOT within the minimum tape length specification. In particular, I am questioning whether or not I will ever be able to find out if I am still within my minimum specification when I am using IDRC compression. Admittedly, I know very little about what the actual tape looks like when I use compression. Maybe there is a better way to stay within the minimum tape length than to find out how much tape I have written. Any ideas? On either knowing tape length, or my root problem, knowing when to stop writing compressed data to stay within the specification? Thanks! David Logan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find current tape length programatically
Someone wrote: I have an obvious question on the 3490E though. You say there is a set of tracks going AND coming. Since actual tape length isn't a specification, just a minimum is, how would a hardware duplication device handle a 3490E? In theory it wouldn't be able to, would it? If one wanted to build a hardware device that could copy a tape, it would probably be possible to write all the tracks at once. As an example, analog cassette tapes can be duplicated in one pass writing both directions at the same time. I don't know the specific encoding for the 3490E, but most likely it is possible. Otherwise, one might copy one side from the beginning as far as it went, skip to the physical EOT, then start writing the other side from the end. Even easier might be for the tape duplicator to find tape stock sufficiently longer than others to guarantee that it will fit. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
