And I want data interchange with IBM and Broadcom, both of which accept .AWS files based on z/VSE's VTAPE implementation (which uses AWS). Currently, I just take an .AWS tape off my VTA and FTP it to them and they can read it. I really don't want to have to convert files before sending them.

HET looks promising.

Tony Thigpen

Jay Maynard wrote on 8/1/22 10:04:
I think Tony was looking for a way to do it transparently, so that no
changes were needed to the programs reading or writing what they see as a
real tape. Your approach requires modifying the host program or jobstream.

On Mon, Aug 1, 2022 at 8:58 AM Joe Monk <[email protected]> wrote:

I dont even understand what the problem is.

AWS is simply a disk format for a sequential file of tape blocks. What is
inside those blocks are for the program that reads/writes them to decide...
AWS does not decide that. You can easily compress, slice into blocks, and
write to AWS.

Sam Golobs article on AWSTAPE makes that pretty clear ...
https://www.cbttape.org/awstape.htm

Joe

On Mon, Aug 1, 2022 at 7:59 AM Seymour J Metz <[email protected]> wrote:

Why is IDRC compatibility an issue when you're not using a physical
cartridge or physical drive that supports IDRC? If you modify AWS to
support compression, use whatever format that gives you the best results.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [[email protected]] on behalf
of Tony Thigpen [[email protected]]
Sent: Saturday, July 30, 2022 12:45 PM
To: [email protected]
Subject: Re: AWS and IDRC/compression

I am working with my VTA vendor to reduce storage usage on the
appliance. Currently, they can compress after the unmount and uncompress
before the mount. But, this takes time, especially when servicing the
mount request if the tape is large.

I was thinking that doing an IDRC implementation, which is stream based
and performed during write/read, it might be faster even if it's not
compresses as much as with their current method.

But, if the AWS file is not compatible with IBM's implementation, then
it's going to add a step to send them the file. The current compressed
files can be uncompressed using standard linux tools.

Tony Thigpen

Jay Maynard wrote on 7/29/22 22:44:
I'm curious. What are you trying to accomplish with it? If it's just a
matter of faster transmission of entire tape images, AWS tapes compress
very well.

On Fri, Jul 29, 2022 at 8:38 PM Tony Thigpen <[email protected]> wrote:

Yes. But, it sounds like nobody else will support it as a data
interchange, so it may be unusable for us.

I will go look at it.

Tony Thigpen

Jay Maynard wrote on 7/29/22 06:38:
Are you talking about the tape data being compressed inside the AWS
image?
Hercules has a format that does this, upwardly compatible with AWS,
called
HET (Hercules Emulated Tape), but I don't know of any other
implementations
of it. Each block is compressed after being received from the program
writing the tape but before being written to the file and
uncompressed
after being read but before being returned to the program reading the
tape.

On Fri, Jul 29, 2022 at 3:56 AM Tony Thigpen <[email protected]>
wrote:

Does anyone know of any 'standard' for stream based (during file
creation) compression of AWS tapes?

Tony Thigpen


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO
IBM-MAIN



--
Jay Maynard


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO
IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO
IBM-MAIN



--
Jay Maynard

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN



--
Jay Maynard

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to