Subject: Re: G-ZIP test
From: Christopher Orth (corth@budoe.bu.edu)
Date: Tue Jun 20 2000 - 11:12:51 EDT
Ciao Nicola,
When you gzip the zeb file, the output isn't going to be fixed
length 21600 records anymore. I think that is what VMS is trying to
tell you here:
Issued DCL: mount/foreign/CACHE=TAPE/rec=21600/block=21600 $1$MKF300:
%COPY-E-WRITEERR, error writing $1$MKF300:[]GC011111.DST-GZ
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-BADPARAM, bad parameter value
I'll read into GZIP on VMS documentation and see what options are
suggested. Can you write a foreign tape without
fixing the record lengths and still have a tape that is easily read on
UNIX? UNIX doesn't require fixed records, it just needs the VMS record
headers stripped, which is what the "FOREIGN" spec. should do.
Chris
On Tue, 20 Jun 2000 Nicola.Zaccheo@lngs.infn.it wrote:
|
| Ciao a tutti,
|
| I tested the gzip utility for our GC DSTs runs.
|
| In a first moment I gziped a RAW GC file (run11111) and I tried to
| copy it on a 'scratch' tape without success. I received a QIO system
| error (see DISK$SCRAUSA9:[MACRODATA.RAW.TEST]test.log for detailes).
| I tried again changing the SET FILE/ATTRIB=(RFM:FIX,LRL:21600) for
| the GC file and gzipping it again w/o success (same error).
| This should be due to the Record format of a gziped file that is Stream_LF.
| Then I used the VMSTOTAR utility and I had no problems in copying the
| file so obtained (DISK$SCRAUSA9:[MACRODATA.RAW.TEST]GC011111_TAR.DST;1) on
| the tape and in recovering it (of course I had to mount the drive
| using /REC=512).
| The output file (from the tape) is
| DISK$SCRAUSA9:[MACRODATA.RAW.TEST]GC011111_TAR_TAPE.DST and it is binary
| identical to the source one.
| Then I tried to unzip the 2 *TAR* files w/o success ("unknown suffix").
| I think I should change again the Record format in Stream_LF....
| Could someone of you tell me how to do it?
|
This archive was generated by hypermail 2a24 : Tue Jun 20 2000 - 11:12:56 EDT