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. 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. I am not sure if that server should also control all storage allocations necessary for real printing and temporary (spool-like) storage. If it does control all the storage then inter-user spool control and browsing like VM:Spool would be a nice enhancement. /Tom Kern
On Wed, 14 Dec 2005 11:17:46 -0500, David Boyes <[EMAIL PROTECTED]> wrote: >This seems symptomatic of a larger question. How difficult would it be >to really get down to *one* printing interface on VM? Right now, we have >3 (CP spool, RSCS, and PSF). Could we consolidate that, probably into >RSCS (as it would take the least work IMHO)? > >If RSCS could control channel-attached printers (not necessarily drive, >but just control), I think this could be done fairly easily. A CMS >MODULE version of PPS could replace PRINT, and the default CMS user >configuration in SYSPROF EXEC could spool the user's printer to RSCS by >default. Operators would have ONE place to look for printout, and one >control interface to learn/manage. Non-CMS guests would spool their >printer to RSCS, and continue to write to CP spool as normal. That would >also enable all the nice PCL and PS support enhancements that Les and >Co. have added to RSCS for guests w/o a lot of effort or additional > >Interesting/desirable?
