> 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.
Given we've been discussing local exits in the standard SYSPROF with Endicott for a while, if you could override the SPOOL PRT TO RSCS in a local SYSPROF exit and leave the default as sending printout to RSCS, would that be OK? Inserting a SPOOL PRT OFF in the local SYSPROF exit would restore the current behavior systemwide, and the newbies wouldn't need to worry about it because they're likely to not be CMS users anyway. I don't expect the SPOOL command to stop working -- using the proposed new PRINT MODULE, you'd still be generating a spool file that would obey the settings on your virtual printer -- it's just how the defaults for handling that spool file would be managed, and the human UI to managing the despooling of that output. > 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/ Yeah, that's a little bit more than I'm after as well. I can see Tom's argument for a more sophisticated output manager being tightly integrated with a spooling manager, but I think that's a different project than I'm proposing just now. I want: 1) ONE operator interface to output management, regardless of transport or imaging method 2) ONE user command to generate output 3) Everything we have now to keep working...8-)
