Opened 5 years ago
#263 new enhancement
Proposed Printer Plan.
| Reported by: | canthony | Owned by: | Eric Swenson |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Answering Service | Version: | |
| Keywords: | Cc: |
Description
The simulator's handling of spooled print jobs is incomplete and fragile (see dps8m ticket #153).
The base problem is that the simulator has no way of knowing what Multics is doing with the printer -- it does not know when a new job starts; it does not know the job and user names, it does not know when the job ends.
Currently it monitors the printer output and applies simple pattern recognition to try to track what is going on; this is feeble and fragile.
If instead we added some new device commands to the printer "hardware':
- Start of new job; it passes an i/o buffer holding the job and user name. The simulator will open a new prt file with the job and user name. The head sheet data, if any, follows this command.
- Start of job body: this command indicates that the head sheet is finished and the actual job is to be printed next.
- End of job body; this command marks the end of the job body and the start of the tail sheet, if any
- End of job. The simulator closes the prt file.
The first one is the hardest to implement on the Multics side; the job and user name string was to be wired down and sent as i/o data. but similar code exists for VFC and Print Image data, so it should be easy to copy the pertinent bits.
Either a new printer type is added and the printer daemon is fixed to send the new commands to that printer type, or the printer daemon sends the new commands to all of the printer types.
The second option violates the backward compatibility goals, but a global enable switch should allay that concern.
