[Simh] attaching a tape virtual file without stopping simulation

[David Holland]

If the images are running Unix host could you kludge up something auto-magic
with some shell scripts, screen, and expect?

Run the images under screen at boot..

Have a shell script that gets all the relevant bits of information, and then
spits out an expect script that
1) attaches to the session.
2) types control-e
3) types the relevant attach commands
4) types cont
5) detaches from the screen session.

Now, not having tried writing something like this, I'm not certain it'll
work.. but it does sound plausible in theory...(Of course, everything sounds
plausible there.  :)  )

David


On Jan 22, 2008 2:09 PM, Boucher, François <boucher.francois at uqam.ca> wrote:

>  >>* How can I attach a tape virtual file to the TQ0 simulated device in simh *
>
> >>* without stopping simulation with CTRL-E ?*
>
>
>
> >You can't, but you do have 20 seconds to do it before the system(s) will
>
> >crash with a CLUEXIT bugcheck. When I was doing some experiments, I was
>
> >able to unload and load tapes in the SIMH console within the 20 second
>
> >period.
>
>
>
> >You can also change the SYSGEN parameter RECNXINTERVAL to have a larger
>
> >timeout.
>
>
>
> >--Marc
>
>
>
>
>
> Marc, you are great!
>
>
>
> I knew i had a bit of time to do the job before the crash happens. This
> 20s time frame is about the
>
> same also about disks that are being attached/detached in SIMH while
> stopping simh.  The major drawback is that it implies
>
> a human has to mount the tape file, and that human has a limited amount of
> time before the crash will happen.
>
> In the place where I work, where we still have computer operators,  I
> would prefer an automated attach
>
> process…
>
>
>
> I will try the solution of modifying RECNXINTERVAL anyway to increase it's
> time.  Thanks for your suggestion.
>
>
>
> I am also inclined of checking if I can get simh by changing source code
> to automatically always
>
> attach itself to a given file name, but when it detaches itself, to make
> it rename the virtual tape file,
>
> so the tape file does not get overwritten.
>
>
>
> In pseudo-code, this would be my idea:
>
> Let's say tape.tap is the virtual tape file. And let's create a simh
> variable say sim_auto_attach wich could
>
> be TRUE (tape will always have a virtual file in it) or FALSE (actual
> behaviour).
>
>
>
> In sim_detach(),
>
> Run function as usual, detach tape metafile from tape device.
>
> If simh parameter sim_auto_attach == TRUE, then
>
> Rename tape.tap to tape#.tap where # is a unique number (date and time?)
>
> call  sim_attach() with the tape.tap file as the target file argument.
>
> Return()
>
>
>
>
>
> It could also be possible to create a parameter with the auto-attach file
> name, instead of the tape.tap constant.
>
>
>
> A little auto-critic on my above solution is that this is good for WRITING
> backup savesets to the tape.
>
> It is not usable for restoring.  Another virtual tape drive has to stay
> manually controllable to attach/detach
>
> the virtual tape file.
>
>
>
> Brian Knittel also makes a very interesting solution, to have at long time
> intervals (ie .1sec) the simh check
>
> for the existence of a command file that contains commands to
> attach/detach files.  This command file could be written
>
> With the same syntax as vax.ini for example, and it contents be executed
> by the do_cmd() function from simh.
>
>
>
> This would be a great solution to my RESTORATION process, when one would
> need to have a tape attached
>
> for reading purposes.  Brian's solution is more universally applicable,
> but might need more human interventions,
>
> than the auto_attach modification.
>
>
>
> Thanks again, Marc and Brian, I value your inputs very much!
>
>
>
> Best regards,
>
>
>
> Francois Boucher ing.
>
>
>
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20080122/d7bff870/attachment-0003.html>