The spooled output should be according to user wishes. Your print file might be my reader file. Making it default to RSCS via SYSPROF, or worse yet, having CP automatically send it there, would be a mistake.
Besides, having RSCS involved in printing the CP dumps when a CP SET DUMP command has set it to a printer might not be pretty. ;-) (I know, it would not be pretty if CP were driving the printer, either.) We have no channel attached printers here. If the user wants a file to be printed, he or she must tag it properly and send it to RSCS. In a previous life, we had over 800 LAN-based printers, each denoted by a destination name. We checked the spool frequently to determine if any files were printed to of these destinations. If we found any, we tagged them appropriately and transferred them to RSCS. If a print file was not spooled to one of the defined destinations, it was left in spool for a few days. We had one channel attached printer that was shared with MVS. It saw very little action - usually only emergency print jobs in support of TPF. Big printouts were usually spooled to a destination that denoted one of several high speed, high volume, printers that were attached to MVS. In essence, this gave us what you are suggesting. -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Wednesday, December 14, 2005 8:37 AM To: [email protected] Subject: Re: Unified printing... 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?
