[Simh] Making tape/disk images

Thu Apr 29 21:45:52 EDT 2010

Michael,

See the following web pages for some information on ANSI labelled tapes:

http://h71000.www7.hp.com/doc/731final/4506/4506pro_002.html

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=bks&fname=/SGI_EndUser/TMF_UG/ch02.html

Here's what a typical tape looks like, where TM is a tape mark, HDRn/ 
EOF1/EOVn are tape labels, and DATA is the data portion of a file:

VOL1 HDR1 HDR2 TM DATA TM EOF1 EOF2 TM ... HDR1 HDR2 TM DATA TM EOF1  
EOF2 TM TM

ANSI tapes have a VOL1 volume label at the beginning of the tape.   
Following that, for each file on the tape, are HDRn header labels, the  
data, and EOFn end-of-file/EOVn end-of-volume labels.  EOVn labels are  
only written when a tape volume spans multiple reels.  You will not  
have that case (I assume).  The EOFn/EOVn labels are identical to the  
corresponding HDRn labels, with fields filled in that are not yet  
known when the HDRn labels are written, such as the number of records  
and blocks in the file.  HDR1 labels have the file name.  HDR2 labels  
have the record format.  HDR3-HDR9 labels are reserved for system  
use.  VMS uses HDR3 labels for RMS metadata.  Those were optional (you  
can MOUNT an ANSI tape on VMS with the /NOHDR3 option), and are not  
understood or necessary for reading ANSI labelled tapes on RSX-11.  I  
assume RSTS is the same.

Double tape marks mark the end of the volume where the next HDR1  
labels would be.  Note: a file can be empty, that is, can contain no  
data.  Thus, it is perfectly legal for an ANSI labelled tape to have  
consecutive tape marks where the DATA would be:

VOL1 HDR1 HDR2 TM TM EOF1 EOF2 TM TM

In this case, the first set of double tape marks does not indicate the  
end of the volume.  A lot of people think double tape marks ends a  
tape, but that is not always the case.

You will have to find out how RSTS uses ANSI labelled tapes.  On VMS  
and RSX-11, text files were written in ANSI "D" format, the format for  
variable-length records.  Much like FTP "TEXT" mode, CR and LF are  
stripped, or, on Unix, the terminating NUL is removed.  The remaining  
text is prefixed with a 4 byte record control word (RCW), which is the  
count of the number of characters in the record, including the RCW.   
(Thus, a null record is written as an RCW=4 with no other characters  
following the RCW.)  Records are spliced together without any padding,  
as for example, to 16-bit or 32-bit boundaries.  The blocks, however,  
can be padded to match the requirements of the hardware.  (PDP-11's  
required even block lengths.)  ASCII circumflex characters are used  
for the padding character.  The other ANSI formats are "F", for fixed- 
length records, and "S", for spanned records (records that can span  
multiple blocks).

I have Fortran routines that I have used to write ANSI labelled tapes  
from a data acquisition system.  You can steal the code, if you like.   
However, I used fixed-length records, so I used ANSI "F" format, not  
ANSI "D" format.  I might have some code somewhere that can pack and  
unpack ANSI "D" format.  I'll have a look.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

On Apr 29, 2010, at 5:36 PM, Michael Richter wrote:

> Larry,
>
> RSTS/E v9.6 is the guest operating system.  Using another SIMH  
> simulation to do this isn't really suitable.  (To begin with I  
> haven't yet solved the problem of getting the OpenVMS CD, but that's  
> a different issue.)  I have loose files--many of them--I want to get  
> into the PDP-11without hand-typing thousands of lines of MACRO-11  
> source.  Using a SIMH VAX to do this just moves the typing problem  
> around.  It would be nice if I could manually construct a tape image  
> on the host system instead of the simulated ones.
>
> DECnetting it would be a bit of overkill, but I'll investigate if I  
> can get that working.
>
> Another possibility would be ... is the specification for ANSI- 
> labelled tapes lying around somewhere?  I could hack together a tar- 
> like program to build those from outside of the DEC world if the  
> spec is available somewhere.
>
> On 30 April 2010 01:58, Larry Baker <baker at usgs.gov> wrote:
> Michael,
>
> Which PDP-11 O/S?  Will it have DECnet access to another system  
> (e.g., a SIMH VAX or linux-decnet)?
>
> OpenVMS system can create and mount a Files-11 Level 1 disk volume,  
> which can be read/written by RSX-11M/M-Plus and IAS.  You could  
> create a virtual Files-11 Level 1 volume with a SIMH VAX and then  
> read it on a SIMH PDP-11.  The same SIMH VAX can create a SIMH  
> virtual ANSI-labelled tape, which can be read/written by those O/ 
> S's, and RSTS, I assume (I have never used RSTS).  RT-11 disk  
> volumes and DOS-11 tape volumes can be created with the OpenVMS  
> EXCHANGE utility.  Any of these can be to virtual devices that can  
> be cross-mounted on various SIMH machines, as long as the O/S  
> supports the volume format.
>
> Of course, any systems that are DECnet'ed together can exchange  
> files.  I use linux-decnet on a CentOS (Red Hat) file server to  
> store OpenVMS Backup save sets that are created using remote file  
> access (FAL) directly from the Backup command.  linux-decnet may not  
> be available for very much longer -- the people that supported the  
> DECnet code in the Linux kernel can no longer keep up with the  
> latest versions of the kernel.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov
>
> On Apr 29, 2010, at 9:00 AM, simh-request at trailing-edge.com wrote:
>
>> Message: 2
>> Date: Thu, 29 Apr 2010 14:54:50 +0800
>> From: Michael Richter <ttmrichter at gmail.com>
>> Subject: [Simh] Making tape/disk images
>> To: simh <simh at trailing-edge.com>
>> Message-ID:
>> 	<o2mee970b291004282354xbfdea62dwe8e2b8389f27a5b3 at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> Is there an easy way to take a bunch of files and turn them into  
>> either a
>> tape image or a disk image suited for attaching to a PDP-11 under  
>> SIMH?
>
>
>
>
> -- 
> "Perhaps people don't believe this, but throughout all of the  
> discussions of entering China our focus has really been what's best  
> for the Chinese people. It's not been about our revenue or profit or  
> whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil"  
> mantra.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20100429/531f6e9f/attachment-0003.html>