id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
263	Proposed Printer Plan.	canthony	Eric Swenson	"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':

   1. 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.

   2. Start of job body: this command indicates that the head sheet is finished and the actual job is to be printed next.

   3. End of job body; this command marks the end of the job body and the start of the tail sheet, if any

   4. 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.
"	enhancement	new	major		Answering Service