Hi,

I'm wondering if anyone has any experience with creating a valid raw tape file (i.e. not dumper or backup) from outside of the PDP os? I believe Dumper tapes can be artificially created via a program included with the Panda distribution, and maybe Backup style tapes as well. There is some documentation included with the Panda distro about what the format for the .tap and the associated metadata should be, but I am hopeful someone has more direct experience or even working but rough code I might be able to leverage get this done.

The goal: take some files created externally to TOPS-20 by shell scripts, and package them into a .tap file so they can easily be extracted by `copy mta0: filename`.

Thanks!
Steve

sbyrne007 wrote:
> I'm wondering if anyone has any experience with creating a valid raw
> tape file (i.e. not dumper or backup) from outside of the PDP os?

Yes, I have done that for WAITS. I tried to make a raw tape file and
then have it written to disk with COPY MTA0: FILENAME, in order to
boostrap a system from a blank filesystem. (I haven't succeeded yet.)
I have some tools in my increasingly misnamed repository here:

https://github.com/larsbrinkhoff/pdp10-its-disassembler

The command to use would be something like "cat36 -Xtape file1 file2..."
-Xtape says to write 9-track tape images to stdout. There will be tape
marks between files. -B specifies record size. You will probably want
-Wascii to specify the input format. Are the inputs text files?

On Sunday, September 5, 2021 at 9:16:28 AM UTC-7, lars...@nocrew.org wrote:
> sbyrne007 wrote:
> > I'm wondering if anyone has any experience with creating a valid raw
> > tape file (i.e. not dumper or backup) from outside of the PDP os?
> Yes, I have done that for WAITS. I tried to make a raw tape file and
> then have it written to disk with COPY MTA0: FILENAME, in order to
> boostrap a system from a blank filesystem. (I haven't succeeded yet.)
> I have some tools in my increasingly misnamed repository here:
>
> https://github.com/larsbrinkhoff/pdp10-its-disassembler
>
> The command to use would be something like "cat36 -Xtape file1 file2..."
> -Xtape says to write 9-track tape images to stdout. There will be tape
> marks between files. -B specifies record size. You will probably want
> -Wascii to specify the input format. Are the inputs text files?

Awesome!! Yes, the inputs will be text files, you know, the kinds of things you'd find in SYSTEM: :)

Thanks!!!! I will give this a try!
Steve

On Sunday, September 5, 2021 at 12:53:08 PM UTC-7, sbyr...@gmail.com wrote:
> On Sunday, September 5, 2021 at 9:16:28 AM UTC-7, lars...@nocrew.org wrote:
> > sbyrne007 wrote:
> > > I'm wondering if anyone has any experience with creating a valid raw
> > > tape file (i.e. not dumper or backup) from outside of the PDP os?
> > Yes, I have done that for WAITS. I tried to make a raw tape file and
> > then have it written to disk with COPY MTA0: FILENAME, in order to
> > boostrap a system from a blank filesystem. (I haven't succeeded yet.)
> > I have some tools in my increasingly misnamed repository here:
> >
> > https://github.com/larsbrinkhoff/pdp10-its-disassembler
> >
> > The command to use would be something like "cat36 -Xtape file1 file2..."
> > -Xtape says to write 9-track tape images to stdout. There will be tape
> > marks between files. -B specifies record size. You will probably want
> > -Wascii to specify the input format. Are the inputs text files?

[For anyone wondering how this turned out]

My experience is that cat36 from Lars' repo works flawlessly to write tape images that can be used under twenex via `copy mta0: foo.txt`.

The command I used to successfully write Twenex tapes was:

cat36 -Xtape -Wascii -B512 file1 [file2 ... ]

I was unable to get the panda distro tools to write valid tape images -- they would have intermittent "clear text" segments that were readable on twenex, but then others were pure binary junk -- the input files that I was trying to transfer are all plain text files. Felt like it was almost-but-not-quite alternating 512 byte blocks of clear and garbled text (my eyeballing said 446 bytes for one clear text segment, but my counting methodology may not have been sufficiently accurate.

Hope this saves someone else some trouble in the future.

Thanks Lars for creating cat36!!!
Steve

(snip)

> [For anyone wondering how this turned out]
>
> My experience is that cat36 from Lars' repo works flawlessly to write tape images that can be used under twenex via `copy mta0: foo.txt`.
>
> The command I used to successfully write Twenex tapes was:
>
> cat36 -Xtape -Wascii -B512 file1 [file2 ... ]
>
> I was unable to get the panda distro tools to write valid tape images -- they would have intermittent "clear text" segments that were readable on twenex, but then others were pure binary junk -- the input files that I was trying to transfer are all plain text files. Felt like it was almost-but-not-quite alternating 512 byte blocks of clear and garbled text (my eyeballing said 446 bytes for one clear text segment, but my counting methodology may not have been sufficiently accurate.
>
> Hope this saves someone else some trouble in the future.
>
> Thanks Lars for creating cat36!!!
> Steve

Years ago, I was transferring data between IBM OS/360 systems and TOPS-10.

Besides problems with tape and tape heads, was getting the bytes out.

I had some Fortran programs that would extract the bytes, and then do the
EBCDIC to ASCII conversion, but I don't remember now how that worked at all..

In some cases, it is necessary to read tape block boundaries. One popular format
for IBM tapes is 80 byte fixed length records in 800 byte blocks. But sometimes
larger blocks are used. 512 was not a popular number in IBM land.

sbyrne007 wrote:
> Thanks Lars for creating cat36!!!

You're welcome! I had a strong need for a suite of tools for working
with a plethora of 36-bit formats, since people are very inventive in
coming up with various way to store PDP-10 words in 8-bit files. I'm
happy to share them with others.

> The command I used to successfully write Twenex tapes was:
> cat36 -Xtape -Wascii -B512 file1 [file2 ... ]

I can explain what this does. The cat36 tool concatenates the input
files and writes the result to stdout, much like the traditional Unix
cat except it's working with 36-bit data stored in 8-bit files.

-Wascii means the input files are encoded with five 7-bit ASCII
characters (packed in the usual PDP-10 way in a 36-bit word) per 8-bit
byte, plus the remaining bit in the last byte. This works well for
transferring plain text files between 8-bit and 36-bit formats.

-Xtape means the output is a SIMH-compatible 9-track tape image. KLH10
also supports this format. Tape marks are automatically placed between
files in the output.

-B512 means to write 512-byte tape records.

gah4 <gah4@u.washington.edu> writes:
>(snip)
>
>> [For anyone wondering how this turned out]=20
>>=20
>> My experience is that cat36 from Lars' repo works flawlessly to write tap=
>e images that can be used under twenex via `copy mta0: foo.txt`.=20
>>=20
>> The command I used to successfully write Twenex tapes was:=20
>>=20
>> cat36 -Xtape -Wascii -B512 file1 [file2 ... ]=20
>>=20
>> I was unable to get the panda distro tools to write valid tape images -- =
>they would have intermittent "clear text" segments that were readable on tw=
>enex, but then others were pure binary junk -- the input files that I was t=
>rying to transfer are all plain text files. Felt like it was almost-but-not=
>-quite alternating 512 byte blocks of clear and garbled text (my eyeballing=
> said 446 bytes for one clear text segment, but my counting methodology may=
> not have been sufficiently accurate.=20
>>=20
>> Hope this saves someone else some trouble in the future.=20
>>=20
>> Thanks Lars for creating cat36!!!=20
>> Steve
>
>Years ago, I was transferring data between IBM OS/360 systems and TOPS-10.
>
>Besides problems with tape and tape heads, was getting the bytes out.
>
>I had some Fortran programs that would extract the bytes, and then do the
>EBCDIC to ASCII conversion, but I don't remember now how that worked at all=
>.
>
>In some cases, it is necessary to read tape block boundaries. One popular f=
>ormat
>for IBM tapes is 80 byte fixed length records in 800 byte blocks. But some=
>times
>larger blocks are used. 512 was not a popular number in IBM land.

The HDR2 records on the tape (ANSI labeled or standard labeled)
show the record size and the blocking factor for each dataset
on the tape.

On Thursday, September 16, 2021 at 7:02:41 AM UTC-7, Scott Lurndal wrote:

(snip, I wrote)
> >In some cases, it is necessary to read tape block boundaries.
> >One popular format for IBM tapes is 80 byte fixed length records
> > in 800 byte blocks. But sometimes
> >larger blocks are used. 512 was not a popular number in IBM land.

> The HDR2 records on the tape (ANSI labeled or standard labeled)
> show the record size and the blocking factor for each dataset
> on the tape.

They do, but that doesn't always help.

Load modules (which one isn't so likely to want to read on
a PDP-10) have RECFM=U, and the BLKSIZE is the maximum.

I have had sent to me RECFM=VB files with the block headers
removed. (It seems that ftp does that.) Virtual tape formats
usually have a way to keep track of block boundaries. On Unix
and similar systems, if you cp a tape to disk, and then back
to tape, blocking is lost.

But yes, years ago I did manage to write RECFM=DB tapes
on OS/VS2 and transfer them to VAX. That was complicated
by OS knowing about ANSI labels, but ASP did not. My first
time using deferred mounting for a tape.

And one of the other fun things about IBM systems is the
ability to write a tape with more than one density. If you
append (write a file other than the first) to a tape, it will
read through (at least the labels) on the earlier files, and
then start writing at the density you select (or default
if you forget). Multidensity drives will happily read through
data at any density they know about, and the new file
gets written at the density asked for.

Such tapes can only be read on drives that can read all
the densities. And yes it happened to me. (I am not
sure now, if that was for PDP-10 or VAX.)

Oh, also, if you mount a blank tape on OS/360 or later,
and don't specify BLP (on systems I knew, only allowed with
write ring out), the first thing the system does is read the label,
which it searches the whole tape to find, until it goes off the
reel. (EOT markers are ignored on read.)

Yes that happened to me, too.

gah4 <gah4@u.washington.edu> writes:
>On Thursday, September 16, 2021 at 7:02:41 AM UTC-7, Scott Lurndal wrote:
>
>(snip, I wrote)
>> >In some cases, it is necessary to read tape block boundaries.
>> >One popular format for IBM tapes is 80 byte fixed length records
>> > in 800 byte blocks. But sometimes
>> >larger blocks are used. 512 was not a popular number in IBM land.
>
>> The HDR2 records on the tape (ANSI labeled or standard labeled)
>> show the record size and the blocking factor for each dataset
>> on the tape.
>
>They do, but that doesn't always help.
>

True, particularly when different systems read and write the
tapes (some of which may have uncommon word sizes, or no word sizes);
not to mention the proprietary formats for executables,
object files, libraries (datasets) or differences in character
sets.

>
>But yes, years ago I did manage to write RECFM=DB tapes
>on OS/VS2 and transfer them to VAX. That was complicated
>by OS knowing about ANSI labels, but ASP did not. My first
>time using deferred mounting for a tape.

Yes, I've transferred between MVS and VAX, Burroughs
Medium Systems (EBCIDC, BCD architecture) and VAX,
and between Unix systems and all of the above on 9-track
tapes.

>
>And one of the other fun things about IBM systems is the
>ability to write a tape with more than one density. If you
>append (write a file other than the first) to a tape, it will
>read through (at least the labels) on the earlier files, and
>then start writing at the density you select (or default
>if you forget). Multidensity drives will happily read through
>data at any density they know about, and the new file
>gets written at the density asked for.

The Burroughs systems would select the density when the
tape is assigned to the program (based on FIB configuration
bits). Like the IBM systems, the hardware supported
the capability of recording at different supported densities
(although 556 was only available on 7-track drives, 800, 1600
and 6250 were supported on the higher-end drives).

I never ran into a multi-density Burroughs tape in practice,
however.

gah4 <gah4@u.washington.edu> writes:
>
>Oh, also, if you mount a blank tape on OS/360 or later,
>and don't specify BLP (on systems I knew, only allowed with
>write ring out), the first thing the system does is read the label,
>which it searches the whole tape to find, until it goes off the
>reel. (EOT markers are ignored on read.)
>

At the university, the systems software staff had disabled BLP
in MVS for all but the systems software staff.

On Friday, September 17, 2021 at 8:47:11 AM UTC-7, Scott Lurndal wrote:
> gah4 <ga...@u.washington.edu> writes:
> >
> >Oh, also, if you mount a blank tape on OS/360 or later,
> >and don't specify BLP (on systems I knew, only allowed with
> >write ring out), the first thing the system does is read the label,
> >which it searches the whole tape to find, until it goes off the
> >reel. (EOT markers are ignored on read.)

> At the university, the systems software staff had disabled BLP
> in MVS for all but the systems software staff.

It is only dangerous when writing, so systems I knew allowed it
with ring out, which guarantees no writing. Well, I suppose it
is a potential security risk otherwise, when you might accidentally
read someone else's data.

I remember a program to read the first few records on each file,
which could be labels on labeled tapes, when I had no idea what was
on a tape. That requires read-only BLP.

But yes, I suspect that many didn't go into that detail.