simh save/restore

[Noah Smith]

hi all, the simh code below works nice - boots tops-10, copies job.for from disk to tape, executes it, and leaves things at the 'command prompt' final state

q - is it even reasonable to try to use the simh save command to save that final state to a file. then later use simh restore and find yourself magically back at the same 'command prompt'?

set env SIM_NAME=KL-10
set env DSK=RPA
set env TAP=TUA
set env DN=kl
set env C=kl
set cpu 4096k kl10b idle
set rpa rh20
set rpb rh20
set tua rh20
set mta disable
set tua enable
set dc disable
set ni enable
at tty -U 2031
at ni tap:tap0
set dn rsx20
at lp20 -n prt.log
at %DSK%0 dsk/%DN%_dskb0.rp6
at %DSK%1 dsk/%DN%_dskb1.rp6

load -c bts/boot.exb

expect "BOOT>" send "\r"; continue
expect "Why reload:" send  "sa\r"; continue
expect "Date:" send  "03-19-86\r"; continue
expect "Time:" send  "1100\r"; continue
expect "Startup option:" send  "quick\r"; continue
expect "%TTY STOMPER - Starting" send "\3"; continue
expect "\r\n*" continue
expect "\r\n." continue
expect "\r\n." continue

expect "\r\n." send "r opr\r"; continue
expect "OPR>" send "\r"; continue
expect "OPR>" send "\r"; continue
expect "OPR>" send "set tape mta0 unavailable\r"; continue
expect "Enter text and terminate with ^Z" send "installing software\r\32"; continue
expect "OPR>" send "\r"; continue
expect "OPR>" send "exit\r"; continue

expect "\r\n." send "r backup\r"; at %TAP%0 -r job.tap;  continue
expect "\r\n/" send "tape mta0:\r"; continue
expect "\r\n/" send "rewind\r"; continue
expect "\r\n/" send "inter\r"; continue
expect "\r\n/" send "files\r"; continue
expect "\r\n/" send "rest [,]*.*=*.*\r"; continue
expect "\r\n/" send "exit\r"; continue

expect "\r\n." send "dir\r"; continue
expect "\r\n." send "exec job.for\r"; continue
continue

[steve...@gmail.com]

I can't speak specifically to save/restore but my experience with TOPS-10 is that even just halting the CPU with the front panel STOP switch then restarting a few seconds later using the CONT switch was problematic. It seems as if TOPS-10 had some internal time-checking about scheduled jobs and merely halting the CPU interfered with that. It has been a while since I tried it, but I remember that TOPS-10 did not handle it gracefully. There are other possible complications as well, for example, it's not clear to me that if you do something to add or modify the contents of any of the disk drives, it could cause issues with in-memory cached directories. In the end, it's probably worth an experiment or two to find out, but I suspect you're going to run into some troubles when you do try it.

-- steve

[Richard C]

Save/Restore feature should work. However the Operating Systems don't like it. ITS will give you a message "ITS REVIVED". Tops10 runs a lot of stuff under system time when the clock hits. It is possible after a stop on start SimH is trying to resync the clock.

Rich

[Noah Smith]

thanks steve and rich, both your answers fit with the very hazy picture i have from a few attempts. nutshell 'the operating system doesn't like it'!:) makes sense,
won't pursue that further, was just curious - am fine using the script above, it only takes like five to ten seconds for the whole thing, in any case.

cheers!

noah

[terry-...@glaver.org]

Back in the day, when I had guest accounts on actual systems, something (presumably the PDP-11 front-end) would emit messages like  "%something something something" followed by "%something something continued". Forgive the lapse in of the actual message in my 50+-year-old memory of computing in 1974. I assume the front-end thought the actual CPU had stopped running, but when the "continued" message came out, my job was still there.

I never actually saw any of the systems on the other end of the 110 baud modem and my ASR-33, except for the AMES 360/95 and that's a story best told after several drinks....

[Noah Smith]

thanks terry, haha yep sounds right - btw, rich might like this -
main them am doing right now is working on some fifties/sixties style numerical stuff in fortran iv -
firing the same source code through ibm7094 and dec10 'in parallel' - hahaha
single shot through 7094 turned out to be easy - 'card deck' written to a tape file, shoot it through ibsys and quit!
script above achieves the same for the 10 by 'faking out' the tops10 interactive session - just run the fortran and quit!:)

am looking at tops10 batch, batcon, etc - not seeming worth the effort, above achieves same thing:)

save/restore would just speed it up - hop over the booting and tape handling
cheers,

noah

[John Francini]

%DECSYSTEM-20 not running

[DECSYSTEM-20 continued]

or 

%DECsystem-10 not running

[DECsystem-10 continued]

each accompanied by 5 bells.

Most of the following is from the TOPS-10 point of view, as I never did any Monitor debugging on TOPS-20.

The front end -11 would send the message above to all DH-11 connected terminal lines when the -10 stopped incrementing the keep-alive counter in shared memory.  (Usually when this happened it meant that the -10 had taken a stopcode (TOPS-10) or a bugcheck (TOPS-20) and was processing it. - writing a crash dump to CRASH.EXE[1,4].

(To prevent RSX-20F from forcing a KAF stopcode (see below), the Monitor would enter Secondary Protocol, which didn't have the stringent keep-alive incrementing requirements)

If the stopcode/bugcheck was continuable, the Monitor would resume Primary Protocol with RSX-20F, which included incrementing the keep-alive counter, and RSX-20F would output the "...continued]" message.

If the reason for the keep-alive failure was that the Monitor was hung, RSX-20F would force a KAF (Keep-Alive Failure) stopcode and the Monitor would be reloaded after CRASH.EXE was written.

So you really, really hoped that when you saw "%DECsystem-10 not running" it would be followed in about 20-30 seconds with "[DECsystem-10 continued]". If it was followed by an INITIA run, followed by the dreaded "Please LOGIN", your job was gone.

Thanks and regards,

John

--

John Francini <fran...@mac.com>

"It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts." -- Sherlock Holmes, A Scandal in Bohemia

-- 
You received this message because you are subscribed to the Google Groups "PiDP-10" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-10+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-10/8f28a7c0-29c5-4330-9837-642ad5385d26n%40googlegroups.com.