Exactly. The only thing that simh adds to this process is the "set cr reset" command to prompt the card reader (driver?).

So on simh, the flow control would be:

1. get your "card deck" in a file on the host
2. boot simh with the cr device attached to said file
3. boot your VAX
4. log in, then CTRL/E out to the simh prompt, and issue "set cr reset"
5. issue "continue" to the simh prompt to resume the VAX
6. observe that your job has run, and the file (if not deleted, which
   is the default) is now a DCL file in your default login directory,
   default name is "INPBATCH.COM". Name may be overridden by the /NAME
   qualifier on the job card.

/Wilm


Jeremy Begg schreef op 14-2-2016 om 23:42:
Hi Bill,

Your suggestion on the simh list looks just like what I need. I use simh
3.9 and the vax has a cr device. I attached a file and everything is good.
When I login to vms nothing understands job.
    I've tried job
@sys$system:job and so on and can't get job or find it anywhere. The help
list doesn't list a noprint qualifier but there is /keep and /name. Where is
"job" that's what I can't seem to find out. This is from the list. >"
So this is your "card" file?

   $JOB SYSTEM /NOPRINT /KEEP /NAME=WilmTest
   $PASSWORD xxxxxxx
   $! some ASCII text
   $ show time
   $EOJ"

That should work fine, and here's what would happen on a real VAX:

1. User loads card deck into card reader and hits the start button.
2. VMS reads each card in turn and creates a temporary file somewhere
    (my guess is that it would be in the login directory for the user
    specified in the JOB statement on the first card).
3. VMS submits the file to the batch queue specified by the /QUEUE
    qualifier on the JOB statement, or to SYS$BATCH if the /QUEUE has
    not been specified.
4. The job runs and creates log file, which will be printed and/or
    deleted unless other qualifiers on the JOB statement specify otherwise.

To summarise: card readers create batch jobs which run without the user
having to log in via an interactive terminal.  The JOB command itself is not
actually a valid VMS command in the usual way: it's not part of
DCLTABLES.EXE and is instead implemented (I think) by the VMS JOB_CONTROL
process.

Regards,

         Jeremy Begg

   +---------------------------------------------------------+
   |            VSM Software Services Pty. Ltd.              |
   |                 http://www.vsm.com.au/                  |
   |---------------------------------------------------------|
   | P.O.Box 402, Walkerville, |  E-Mail:  [email protected] |
   | South Australia 5081      |   Phone:  +61 8 8221 5188   |
   |---------------------------|  Mobile:  0414 422 947      |
   |  A.C.N. 068 409 156       |     FAX:  +61 8 8221 7199   |
   +---------------------------------------------------------+
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to