What I was thinking about was how VM:Spool got access to the data in spool to present to a user. It required links to ALL of the spool areas that might store files for this system. I wasn't necessarily proposing that CP stop sending inter-user spool data to its spooling areas. Lots of my automation is still based on the arrival of spoolfiles.
/Tom Kern On Wed, 14 Dec 2005 10:17:36 -0800, Schuh, Richard <[EMAIL PROTECTED]> wrote: > -----Original Message----- >From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern >Sent: Wednesday, December 14, 2005 9:43 AM >To: [email protected] >Subject: Re: Unified printing... > >Please don't take my response the wrong way. I see RSCS (or an RSCS >replacement) as THE place to handle ALL real printing to channel attached >printers, printers on other VM or MVS systems or IP-addressable printers. I >also think it should be expanded to control all-but-emergency spool storage. > >What about spool files that are destined for some user's reader? Not emergency, but not (IMHO) appropriate for a server to handle. Why try to fix what is not broken? The device emulation and, hence the storage needed for it, can (or at least should) only be handled by CP. Don't forget, spool files are being created by emulated virtual devices. Not all spool files are created by or for RSCS or whatever server you build. >========================================================================
