> I have been working for quite a long time on systems that DO > NOT have directly attached printers. All real printing has > been through RSCS to another system (MVS) or to IP attached > printers. Our default is to leave print/punch output in CP > SPOOL with appropriate aging. Real outputs take extra effort.
You'd still get that behavior by either spooling the user's printer as HOLD or as class that the RSCS handler didn't start by default. > I would disapprove of the default PRINT command sending > output to RSCS. I do however approve of ALL printer control > being through an RSCS-like server. OK. I was thinking RSCS would be the logical candidate, as it is a) already preinstalled so everyone has it, b) already has all the necessary multitasking support and c) already supports the concept of pseudolinks that do some programmatic function (the control interface for CP-driven printers could be implemented as pseudolinks for each CP-driven printer, and all the other logic is already there in RSCS to do the rest of the management). Minimal development time, and you need it anyway to drive non-CP/non-PSF printers. Wrt to default print commmand -- it'd have to send it *somewhere*; I used RSCS in my example, but something would need to decide what device to schedule it on (or ignore it as appropriate). Or were you thinking that the proposed virtual machine would sort through spool periodically, find things that needed to be printed (according to local rules), and then schedule them on the appropriate devices? > I am not sure if that > server should also control all storage allocations necessary > for real printing and temporary (spool-like) storage. I don't want to lose the existing spooling model -- that works pretty well, and if we start getting fancy with that, it'll be hard to integrate stuff like VSE and MVS guests. I just want one control interface for output management. > If it > does control all the storage then inter-user spool control > and browsing like VM:Spool would be a nice enhancement. One thing at a time...8-) But, yes, that would be a nice enhancement. Hmm... that gives me an idea. 8-) -- db
