25 Dec
2021
25 Dec
'21
9:21 p.m.
I do not see that problem and I posted it here somewhat earlier:
Swbx04> att -f tu0 simh g:\temp\bb-d867e-bm_tops20_v41_2020_instl.tap-1
Swbx04> b tu0
And on console:
MTBOOT>
The first must be MTBOOT else you cannot load de monitor with /L and ?G143, so no skipping
filemarks are needed as the monitor is the first file.
Mark well, it is format simh=tps!
The tap-1 extension is because 7-Zip found another file .tap was already there (the old
one).
However I could not run dumper from the tape when trying it in install mode, so after
DLUSER I got no further, but I did not test that any further for lack of need.
Reindert
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Thomas DeBellis
Sent: Saturday, 25 December, 2021 20:47
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH TOPS-20 question --> recipe for handling Tops20 install
tapes
Try skipping forwarding one or two file marks. There was some kind of stuff at the
beginning of the tape that I didn't recognize. The monitor was after two file marks.
So do a rewind then skip forward one file mark and maybe mtboot will be there.
On 12/25/21 2:20 PM, Paul Koning wrote:
On Dec 25, 2021, at 5:29 AM, R. Voorhorst <R.Voorhorst at swabhawat.com
<mailto:R.Voorhorst at swabhawat.com> > wrote:
I think Paul cannot get these files loaded on his Tops20 V4.1 system from hecnet, being
barred by lacking decnet and/or Kermit functionality.
In the end (!) the tape recipe works as follows:
Get a FRESH copy of tape BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 (after unzip) from Pdp10
archive into a host directory.
In simh when the monitor Tops20 V4.1 has been fired up or before:
ATT ?F TU0 SIMH G:\TEMP\BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 or your favorite
location
I found that SIMH is happy attaching it with -f tpc -- previously I had misread the
messages printed by that command and thought it had an error.
So according to the installation manual, that tape is the "install" tape and is
supposed to be bootable. But if I mount it and issue "boot tu0", nothing
happens. When I stop simh it tells me PC is 0.
paul
25 Dec
25 Dec
10:04 p.m.
That's fine; great actually.? I didn't want to get into decoding the
data between the file marks so much as I wanted to pull the DUMPER
savesets, being very interested in the UETP stuff.
I am very hesitant to speak to MTBOOT.? I believe we only built our
first KL with MTBOOT.? The other five machines got built directly from
disk; that is, we used CHECKD to create the PS: (or BS:) structure and
then copied over what we needed, changing appropriate configuration
files, etc.
What I do remember was a foolish mistake we made in understanding
MTBOOT.? One time when a PS: went down, we speculated that we might be
able to be boot from tape and then use that monitor to join the cluster
and allow sign-ons to the login structure.? So we did that, but we still
couldn't do much of anything because there was no swap space to be had
anywhere.? A bunch of other things didn't work, either (like the
configuration settings!).? Oh well, the monitor person wasn't around for
that one.
I think we could have probably eventually gotten close to what we
wanted, but that would have had a fair amount of exclusive use for
booting, testing, etc.? That kind of time wasn't there to be had.
I skipped all the DLUSER stuff to get right to the save sets.? I had
assumed that I hadn't set the record size to the right thing or
something.? It would be in the system manager document as I recall, but
again, I just wanted the date.
On 12/25/21 3:21 PM, R. Voorhorst wrote:
I do not see that problem and I posted it here somewhat earlier:
Swbx04> att -f tu0 simh g:\temp\bb-d867e-bm_tops20_v41_2020_instl.tap-1
Swbx04> b tu0
And on console:
MTBOOT>
The first must be MTBOOT else you cannot load de monitor with /L and
?G143, so no skipping filemarks are needed as the monitor is the first
file.
Mark well, it is format simh=tps!
The tap-1 extension is because 7-Zip found another file .tap was
already there (the old one).
However I could not run dumper from the tape when trying it in install
mode, so after DLUSER I got no further, but I did not test that any
further for lack of need.
Reindert
*From:*owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
*On Behalf Of *Thomas DeBellis
*Sent:* Saturday, 25 December, 2021 20:47
*To:* hecnet at Update.UU.SE
*Subject:* Re: [HECnet] SIMH TOPS-20 question --> recipe for handling
Tops20 install tapes
Try skipping forwarding one or two file marks.? There was some kind of
stuff at the beginning of the tape that I didn't recognize.? The
monitor was after two file marks.? So do a rewind then skip forward
one file mark and maybe mtboot will be there.
On 12/25/21 2:20 PM, Paul Koning wrote:
On Dec 25, 2021, at 5:29 AM, R. Voorhorst
<R.Voorhorst at swabhawat.com> wrote:
I think Paul cannot get these files loaded on his Tops20 V4.1
system from hecnet, being barred by lacking decnet and/or
Kermit functionality.
In the end (!) the tape recipe works as follows:
Get a FRESH ?copy of tape
BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 (after unzip) from
Pdp10 archive into a host directory.
In simh when the monitor Tops20 V4.1 has been fired up or before:
ATT ?F TU0 SIMH
G:\TEMP\BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 or your
favorite location
I found that SIMH is happy attaching it with -f tpc -- previously
I had misread the messages printed by that command and thought it
had an error.
So according to the installation manual, that tape is the
"install" tape and is supposed to be bootable. ?But if I mount it
and issue "boot tu0", nothing happens. ?When I stop simh it tells
me PC is 0.
paul
10:23 p.m.
On Dec 25, 2021, at 3:21 PM, R. Voorhorst
<R.Voorhorst at swabhawat.com> wrote:
I do not see that problem and I posted it here somewhat earlier:
Swbx04> att -f tu0 simh g:\temp\bb-d867e-bm_tops20_v41_2020_instl.tap-1
Swbx04> b tu0
And on console:
MTBOOT>
The first must be MTBOOT else you cannot load de monitor with /L and ?G143, so no
skipping filemarks are needed as the monitor is the first file.
Mark well, it is format simh=tps!
So it is, interesting.
What's strange is that -f tpc reports success, while -f simh reports an error:
After processing 1159680 bytes of tape data (453 records, 5 tapemarks)
Read Tape Record Returned Unexpected Status: invalid record length
19827814 bytes of unexamined data remain in the tape image file
but indeed in this format I can boot the tape.
paul
1102
days inactive
1102
days old
2 comments
3 participants
participants (3)
-
paulkoning＠comcast.net -
R.Voorhorst＠swabhawat.com -
tommytimesharing＠gmail.com