On Wed, 14 Dec 2005 11:42:47 -0600, Thomas Kern wrote: >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. >I can see segregating NSS/DCSS and DUMP allocations from those used (owned) >by the RSCS server and all user-spooled data going into the RSCS areas. > >If the default processing could be to just hold the data, allowing for user >overrides to other destinations, that would be okay. But to turn control of >the file over to another process that complicates the retrieval/purge of the >file is not good. I know we are losing more and more end-users, but not all >of the remainder are greybearded sysprogs who remember all the commands and >all the options. This is where a VM:Spool like interface to user spool files >can mask all of the background complexity > >So, if you can streamline the system management of printing resources, the >utilization of DASD storage for printing services, and the end-user >interface to their printing data, I'd love it, in RSCS or in a linux appliance. > >/Tom Kern >
Well, if any of this were to be implemented, the first thing that we would have to do is disable the SYSPROF part. We want to control OUR print files, not some other virtual machine. We are a development shop, and use spooling to contain listings and console files to refer too. Yes, they go away after seven or ten or whatever days unless we hold them. However, almost none of my spool files EVER get printed. They get referred to, but they stay in spool until I don't need them or they get deleted by the spool daemon. I don't have a problem with RSCS being enhanced to control channel attached printers (how many of those still exist?), but I DO NOT like the idea of RSCS controlling ALL spool/ Lloyd Fuller Select Business Solutions [EMAIL PROTECTED] (203)383-4692
