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 On Wed, 14 Dec 2005 12:15:33 -0500, David Boyes <[EMAIL PROTECTED]> wrote: > snipped... >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.
