Forwarded message:
>From shoppa Tue Oct 10 12:55:15 1995
Subject: Access to tape drive from Fortran
To: alpha-osf-managers_at_orl.gov
Date: Tue, 10 Oct 1995 12:55:15 -0800 (PDT)
From: "Tim Shoppa" <shoppa_at_altair.krl.caltech.edu>
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2139
Hi Folks,
We're trying to adapt some fortran codes for tape-reading
from VMS to OSF/1. In particular, the tapes (8mm Exabytes) have
records of varying lengths on them, and we don't know the lengths beforehand.
For example, a file might have 10 512-byte records, a 80-byte record,
20 more 512-byte records, a 80-byte record, etc. There is no way
of knowing the length of the upcoming record until we read
it. There are even filemarks (i.e. end-of-files) interspersed
throughout the tape. The end of the tape is marked by a double filemark.
In the past, we've read these tapes under VMS with something
similar to the following code fragment:
CHARACTER*512 BUFFER
OPEN(UNIT=11,FILE='MUA0:',STATUS='OLD',FORM='FORMATTED',
1 CARRIAGECONTROL='NONE')
READ(11,101) ISIZE,BUFFER(1:SIZE)
101 FORMAT(Q,A<ISIZE>)
The "Q" in the format list is a nonstandard DEC extension to F77
that returns the length (in this case, in characters) of the
record. We need to know the length of the record that we have
read in, and (without resorting to QIO's, which only work under VMS)
using the "Q" qualifier seems to do this fine under VMS.
The same code under f77 on OSF/1 compiles
just fine (well, we change 'MUA0:' to '/dev/rmt0h', of course), but
at run-time we get back this singularly unhelpful error message,
after five to ten seconds of tape repositioning:
forrtl: severe (39): error during read, unit 11, file /dev/rmt0h
I know the tape is readable, as we can do "dd" and "od" from it and
see that the data is there. "dd" and "od" seem to have little
concept of variable record-lengths and seem to run all the records right
up against each other, while we need the record lengths.
I have tried adding different RECL=nnn qualifiers to the open statement,
thinking perhaps that a buffer was overflowing, but these don't seem to help.
Is there any way to do the read and determine the record
lengths from Fortran under OSF/1? If not, what other approaches should
we think about using? Unfortunately, for political reasons we
cannot move the Exabyte drive back to the VMS machine :-(
Tim Shoppa (shoppa_at_altair.krl.caltech.edu)
Received on Tue Oct 10 1995 - 21:15:19 NZDT