8 Aug
2015
8 Aug
'15
5:57 p.m.
A couple of weeks ago, I offered to share the source and executable for
a SCSI tape-to-SIMH .TAP file utility for MSDOS.
To run it, you'll need an ASPI driver for your SCSI adapter.
It was compiled using MSC 8.00C.
Find it here:
https://www.dropbox.com/s/x6qiudlpyitgxom/STP2T02.ZIP?dl=0
Enjoy,
Chuck
-------------------------------------------------------------
"The first thing we do, let's kill all the spammers."
8 Aug
8 Aug
8:14 p.m.
If anyone is interested, I have code for a Linux SCSI tape to AWSTAPE
program, and a program that translates aws format to a raw byte stream.
Not sure if I have one that translates to the SimH .tap format, though.
GNU C.
JRJ
On 8/8/2015 7:57 PM, Chuck Guzis wrote:
A couple of weeks ago, I offered to share the source
and executable for
a SCSI tape-to-SIMH .TAP file utility for MSDOS.
To run it, you'll need an ASPI driver for your SCSI adapter.
It was compiled using MSC 8.00C.
Find it here:
https://www.dropbox.com/s/x6qiudlpyitgxom/STP2T02.ZIP?dl=0
Enjoy,
Chuck
-------------------------------------------------------------
"The first thing we do, let's kill all the spammers."
9:16 p.m.
On 08/08/2015 08:14 PM, Jay Jaeger wrote:
If anyone is interested, I have code for a Linux SCSI
tape to
AWSTAPE program, and a program that translates aws format to a raw
byte stream. Not sure if I have one that translates to the SimH .tap
format, though. GNU C.
I've got a Linux utility to translate SIMH .tap to raw binary, if that's
interesting to anyone. I would have thought that such utilities existed
already.
--Chuck
9 Aug
9 Aug
8:08 a.m.
On 8/8/15 9:16 PM, Chuck Guzis wrote:
On 08/08/2015 08:14 PM, Jay Jaeger wrote:
this bursts a tape into raw sequentially numbered files
#include <stdio.h>
FILE *fp;
main()
{
unsigned int len, len2;
unsigned int i;
unsigned int filenum = 0;
char fname[20];
sprintf(fname,"%05d",filenum++);
fp = fopen(fname,"w");
do{
len = getchar();
if(feof(stdin)) exit(1);
len = len | (getchar()<<8);
len = len | (getchar()<<16);
len = len | (getchar()<<24);
if(len == -1){
fprintf(stderr,"65535 byte record in file %d\n",filenum);
getchar();getchar();getchar();getchar();
continue;
}
if(len == 0){
fprintf(stderr,"Tape Mark\n");
fclose(fp);
sprintf(fname,"%05d",filenum++);
fp = fopen(fname,"w");
continue;
}
for(i = len; i; i--)
fputc(getchar(), fp);
len2 = getchar();
len2 = len2 | (getchar()<<8);
len2 = len2 | (getchar()<<16);
len2 = len2 | (getchar()<<24);
if(len != len2){
fprintf(stderr, "front and back lengths differ!\n");
exit(1);
}
} while(!feof(stdin));
}
If anyone is interested, I have code for a Linux
SCSI tape to
AWSTAPE program, and a program that translates aws format to a raw
byte stream. Not sure if I have one that translates to the SimH .tap
format, though. GNU C.
I've got a Linux utility to translate SIMH .tap to raw binary, if that's
interesting to anyone. I would have thought that such utilities existed already.
--Chuck
9:46 a.m.
I've got a version that looks for label records and names and dates the
parts appropriately.
Probably not of any interest to UNIX-ers as the tape handling of that
system was abysmally primitive, compared to other mainframe systems.
--Chuck
On 08/09/2015 08:08 AM, Al Kossow wrote:
On 8/8/15 9:16 PM, Chuck Guzis wrote:
--
--Chuck
-------------------------------------------------------------
"The first thing we do, let's kill all the spammers."
On 08/08/2015 08:14 PM, Jay Jaeger wrote:
this bursts a tape into raw sequentially numbered files
#include <stdio.h>
FILE *fp;
main()
{
unsigned int len, len2;
unsigned int i;
unsigned int filenum = 0;
char fname[20];
sprintf(fname,"%05d",filenum++);
fp = fopen(fname,"w");
do{
len = getchar();
if(feof(stdin)) exit(1);
len = len | (getchar()<<8);
len = len | (getchar()<<16);
len = len | (getchar()<<24);
if(len == -1){
fprintf(stderr,"65535 byte record in file %d\n",filenum);
getchar();getchar();getchar();getchar();
continue;
}
if(len == 0){
fprintf(stderr,"Tape Mark\n");
fclose(fp);
sprintf(fname,"%05d",filenum++);
fp = fopen(fname,"w");
continue;
}
for(i = len; i; i--)
fputc(getchar(), fp);
len2 = getchar();
len2 = len2 | (getchar()<<8);
len2 = len2 | (getchar()<<16);
len2 = len2 | (getchar()<<24);
if(len != len2){
fprintf(stderr, "front and back lengths differ!\n");
exit(1);
}
} while(!feof(stdin));
}
If anyone is interested, I have code for a Linux
SCSI tape to
AWSTAPE program, and a program that translates aws format to a raw
byte stream. Not sure if I have one that translates to the SimH .tap
format, though. GNU C.
I've got a Linux utility to translate SIMH .tap to raw binary, if
that's interesting to anyone. I would have thought that such
utilities existed already.
--Chuck
10:19 a.m.
On Aug 9, 2015, at 12:46 PM, Chuck Guzis <cclist at
sydex.com> wrote:
I've got a version that looks for label records and names and dates the parts
appropriately.
Probably not of any interest to UNIX-ers as the tape handling of that system was
abysmally primitive, compared to other mainframe systems.
More primitive than OS/360, which lets you put names on tape files but can?t find files by
name? That?s hard to imagine.
paul
10:36 a.m.
On 08/09/2015 10:19 AM, Paul Koning wrote:
More primitive than OS/360, which lets you put names
on tape files
but can?t find files by name? That?s hard to imagine.
You haven't lived until you get a pile of tapes (some mixed-density)
with no identifying labels at all, from an archivist who wants to know
what's on them, but can't provide any information as to where they came
from, much less what operating system wrote them.
I still think that OS/360 was miles ahead of UNIX.
Good OS-es allowed an operator to mount tapes for his next few jobs,
without paying attention to paper labels and have the OS automatically
locate and assign tapes to the proper job.
Can UNIX do that?
--Chuck
10:45 a.m.
On 8/9/2015 12:36 PM, Chuck Guzis wrote:
Good OS-es allowed an operator to mount tapes for his
next few jobs,
without paying attention to paper labels and have the OS automatically
locate and assign tapes to the proper job.
Can UNIX do that?
--Chuck
Seems dangerous to me: duplicate data set names on different tapes would
confuse it (plus, if the DSN is long, the entire DSN does not actually
appear in the tape label). I worked with OS/360 and MVS in my career
and we never did anything like that with it.
Certainly one could imagine writing a process in Unix (or most any OS,
for that matter) to do something like that where a separate process
managed the tape drives, and then processes could connect to it to ask
for tape data based on the label. I just can't imagine anyone WANTING
to do that.
JRJ
11:13 a.m.
On 08/09/2015 10:45 AM, Jay Jaeger wrote:
Seems dangerous to me: duplicate data set names on
different tapes would
confuse it (plus, if the DSN is long, the entire DSN does not actually
appear in the tape label). I worked with OS/360 and MVS in my career
and we never did anything like that with it.
So you'd trust your job to a 9-5 operator who really didn't care what
the machine was doing to make tape assignments?
Wow. Good thing that tapes have write-enable rings.
--Chuck
11:27 a.m.
If you had a tape master file then typically that had the same dataset name on the master
in and out....
Dave
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck
Guzis
Sent: 09 August 2015 19:13
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>
Subject: Re: SCSI Tape to TAP utility
On 08/09/2015 10:45 AM, Jay Jaeger wrote:
Seems dangerous to me: duplicate data set names
on different tapes
would confuse it (plus, if the DSN is long, the entire DSN does not
actually appear in the tape label). I worked with OS/360 and MVS in
my career and we never did anything like that with it.
So you'd trust your job to a 9-5 operator who really didn't care what the
machine was doing to make tape assignments?
Wow. Good thing that tapes have write-enable rings.
--Chuck
12:39 p.m.
On 08/09/2015 11:27 AM, Dave G4UGM wrote:
If you had a tape master file then typically that had
the same
dataset name on the master in and out....
But obviously, not the same VSN...
There's (potentially) a lot of information in a set of labels,
particularly if any of the user labels are used.
See, for example, this CERN document:
https://it-dep-fio-ds.web.cern.ch/it-dep-fio-ds/documentation/tapedrive/lab…
--Chuck
1:25 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck
Guzis
Sent: 09 August 2015 20:40
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>
Subject: Re: SCSI Tape to TAP utility
On 08/09/2015 11:27 AM, Dave G4UGM wrote:
On the Honeywell we had a Tape Management System that managed the tapes. All the tapes
were filed by tape number, and the system knew which file was on which tape. It would tell
the operators which tape number to mount. It would also manage the scratch pool of expired
tapes and tell them which tapes to have ready for new outputs. It also managed off site
storage. We trusted it and never removed a write ring. If you mounted a tape with current
data the system read the label and dis-mounted the tape....
Dave Wade
If you had a tape master file then typically that
had the same dataset
name on the master in and out....
But obviously, not the same VSN...
There's (potentially) a lot of information in a set of labels, particularly if any
of
the user labels are used.
See, for example, this CERN document:
https://it-dep-fio-ds.web.cern.ch/it-dep-fio-
ds/documentation/tapedrive/labels.html
--Chuck
2:40 p.m.
On 08/09/2015 01:25 PM, Dave G4UGM wrote:
On the Honeywell we had a Tape Management System that
managed the
tapes. All the tapes were filed by tape number, and the system knew
which file was on which tape. It would tell the operators which tape
number to mount. It would also manage the scratch pool of expired
tapes and tell them which tapes to have ready for new outputs. It
also managed off site storage. We trusted it and never removed a
write ring. If you mounted a tape with current data the system read
the label and dis-mounted the tape....
I think that most large mainframe OSs eventually had a similar feature.
When you had operators who were barely trained, it was best to leave
it to the system.
On the CDC 60x and 65x, my tapes never had a write ring in them (what
else are you going to play ring-toss with while waiting for your job to
complete?). I always kept a few cards in my shirt pocked to stick
behind the mounted reel and trip the write-enable mechanism (which
latched). When the autoloading 66x drives came in, part of my world
disappeared. I've never tried to see if that trick works on minicomputer
reel-to-reel drives.
--Chuck
9:57 p.m.
I always kept a few cards in my shirt pocked to stick
behind the mounted reel and trip the write-enable mechanism (which
latched). When the autoloading 66x drives came in, part of my world
disappeared. I've never tried to see if that trick works on minicomputer
reel-to-reel drives.
It should do. The few minicomputer magtape drives I've been inside have
a solenoid on the write-enable pin. If it is pushed in part way, a microswtich
operated and the solenoid pulls it in further to keep it away from the
write enable ring. Otherwise, I think there would be tremendous wear on
said ring.
-tony
3:03 p.m.
No, the OS did the drive assignments, and then prompted the operator to
do the mount of the appropriate VolSer on a given drive. The label was
of course checked as part of the OS/360 open process, and if there was a
label, and it was not expired, one could not write over it, or, whether
reading or writing, that the label matched the requested DSN.
(Remember that OS/360 never heard of the 3480 tapes and their
autoloaders - things presumably changed then, along with tape library
management software, but by then I had moved on from mainframes, and
what little I did with them didn't involve tape).
The operators I worked with almost never mismounted a tape.
JRJ
On 8/9/2015 1:13 PM, Chuck Guzis wrote:
On 08/09/2015 10:45 AM, Jay Jaeger wrote:
Seems dangerous to me: duplicate data set names
on different tapes would
confuse it (plus, if the DSN is long, the entire DSN does not actually
appear in the tape label). I worked with OS/360 and MVS in my career
and we never did anything like that with it.
So you'd trust your job to a 9-5 operator who really didn't care what
the machine was doing to make tape assignments?
Wow. Good thing that tapes have write-enable rings.
--Chuck
5:57 p.m.
On 08/09/2015 03:03 PM, Jay Jaeger wrote:
No, the OS did the drive assignments, and then
prompted the operator
to do the mount of the appropriate VolSer on a given drive. The
label was of course checked as part of the OS/360 open process, and
if there was a label, and it was not expired, one could not write
over it, or, whether reading or writing, that the label matched the
requested DSN.
(Remember that OS/360 never heard of the 3480 tapes and their
autoloaders - things presumably changed then, along with tape
library management software, but by then I had moved on from
mainframes, and what little I did with them didn't involve tape).
The operators I worked with almost never mismounted a tape.
I'd pretty much left the 360 world after DOS/360 (that really dates me),
so I couldn't comment--except that I never trusted an operator to mount
tapes, if I could do anything about it. A lot of the tapes came from
customers who supplied them to demonstrate a problem. Losing one meant
a lot of apologies and begging.
Much of my big-iron days were spent in operating system work, so I
needed the machine all to myself in any case---you know,
middle-of-the-night block time, after the CEs were through. Build a
tape, deadstart it, watch the machine crash, get a dump, punch some
cards, lather, rinse, repeat. Come home to grab a shower and dinner and
be back in time for the 9AM status meeting.
Those years have affected my sleep habits all the way to my "golden
years". They didn't do much for my social life either.
--Chuck
10 Aug
10 Aug
8:39 a.m.
On 8/9/2015 7:57 PM, Chuck Guzis wrote:
On 08/09/2015 03:03 PM, Jay Jaeger wrote:
I'd pretty much left the 360 world after DOS/360 (that really dates me),
so I couldn't comment--except that I never trusted an operator to mount
tapes, if I could do anything about it. A lot of the tapes came from
customers who supplied them to demonstrate a problem. Losing one meant
a lot of apologies and begging.
Isn't that what removed write rings were for? ;)
Much of my big-iron days were spent in operating
system work, so I
needed the machine all to myself in any case---you know,
middle-of-the-night block time, after the CEs were through. Build a
tape, deadstart it, watch the machine crash, get a dump, punch some
cards, lather, rinse, repeat. Come home to grab a shower and dinner and
be back in time for the 9AM status meeting.
Been there, done that, though not with OS/360 - but with VMS.
Those years have affected my sleep habits all the way to my "golden
years". They didn't do much for my social life either.
--Chuck
Chuckle.
JRJ
8:50 a.m.
Reminds me of James Ellwood from one of my favorite TZ episode ?From Agnes, With Love?
https://en.wikipedia.org/wiki/From_Agnes?With_Love
On Aug 9, 2015, at 8:57 PM, Chuck Guzis <cclist at
sydex.com> wrote:
They didn't do much for my social life either.
--Chuck
9 Aug
9 Aug
10:54 a.m.
Good OS-es allowed an operator to mount tapes for his
next few jobs,
without paying attention to paper labels and have the OS automatically
locate and assign tapes to the proper job.
Even the old Operators Exec (and thus George 1 and 2) could do that
on the ICL 1900 - I think it was referred-to as "AVR" (Automatic Volume
Recognition)
I took it so much for granted that I did not even think of mentioning
it in the operational requirement for the replacement system.
Quite a shock to discover its absence in GCOS on the Level 66.
(The reason for its absence on big multi-tasking machines was probably to do with
the scheduling on such being done by the OS, not the operators. Typically there
was an extra console by the tape decks which told the operators which tapes to load
for the next couple of jobs and didn't even schedule the job until the appropriate
device was ready.)
5:29 p.m.
On 2015-08-09 19:54, ANDY HOLT wrote:
You should look at the operator interface in TOPS-20... It's a marvel of
beauty in this area.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Good OS-es
allowed an operator to mount tapes for his next few jobs,
without paying attention to paper labels and have the OS automatically
locate and assign tapes to the proper job.
Even the old Operators Exec (and thus George 1 and 2) could do that
on the ICL 1900 - I think it was referred-to as "AVR" (Automatic Volume
Recognition)
I took it so much for granted that I did not even think of mentioning
it in the operational requirement for the replacement system.
Quite a shock to discover its absence in GCOS on the Level 66.
(The reason for its absence on big multi-tasking machines was probably to do with
the scheduling on such being done by the OS, not the operators. Typically there
was an extra console by the tape decks which told the operators which tapes to load
for the next couple of jobs and didn't even schedule the job until the appropriate
device was ready.) 
10 Aug
10 Aug
1:39 a.m.
On Sat, 8 Aug 2015, Chuck Guzis wrote:
I've got a Linux utility to translate SIMH .tap to
raw binary, if that's
interesting to anyone. I would have thought that such utilities existed
already.
They probably do, but I have written my own set of tools for reading and
writing TAP and AWS files, as probably most who do tape archiving.
Christian
3373
days inactive
3374
days old
20 comments
10 participants
participants (10)
-
aek＠bitsavers.org -
andy.holt＠tesco.net -
ard＠p850ug1.demon.co.uk -
bqt＠update.uu.se -
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
cube1＠charter.net -
dave.g4ugm＠gmail.com -
paulkoning＠comcast.net -
pete＠pski.net