> David, there is no IBM Director for CMS. What we have is an > IBM Director extension (read: priced) that can manipulate > virtual machines, but it has nothing to do with CMS, per se.
Ah. Yes, that's what I meant. Sorry for the confusion -- it's been an interesting week. > I'm not sure what it gains to send CMS output meant for a > system printer to be sent to RSCS. 1) Single point of operator control, single operator UI regardless of printer type or communications method. Right now, depending on the printer type, you use either: A) CP START/STOP B) SMSG RSCS START <printername> <options> C) some PSF incantation I don't remember that autologs the PSF printer service machine depending on what kind of printer you have. This shouldn't be. This is the kind of thing that computers should worry about, not humans. 2) Single, no-surprises user behavior. PRINT should be the way printer files are generated, and it should behave the same for every printer, period. I shouldn't have to use different commands for different printers, and it shouldn't do something different if I use printer B rather than printer A. > If anything, *SPL support > (a la PSF) could be added to RSCS to allow it to pick up > system queue print files and dispose of them. Then you don't > care whether the virtual machine is CMS, Linux, VSE, or > whatever. If a virtual machine wants to use LPR to talk to > RSCS LPD, that's ok, too. And did I mention adding SAMBA? :-) That would be OK with me -- sounds like more work, though. Also, at least PSF depended on setting the DEST parameter, which not all guests support. I suppose the RSCS implementation could be made smarter, ie any combination of class, form, etc as a start parm to the channel-attached printer driver, and just let it slurp out matching files. That's the reason for this discussion -- to find out what makes most sense. > And I think you could use a "wrapped" NJE link to let RSCS > drive a system printer, I'm not sure you need an RSCS > channel-attached printer driver. > That's what you get when you tag a file for "YOURNODE SYSTEM". That would get the output delivered to spool with the right tag info, but it assumes the system printer has already been started via CP START to actually get it scheduled on a device. The operator would still need to know the difference between a network printer and a channel-attached printer and have already started the printer. You'd still need code in RSCS to let it actually control the startup/stop of the CP printer itself, and (IMHO), that would need to be a new link type, example: LINKDEF 01A TYPE CPPRT LINKPARM 01A CLASS=* OPERFORM=xyzz USERFORM=xyzz CHARS=S0U1 and then SMSG RSCS START 01A would issue the appropriate CP commands. Ditto for PSF printers. Then, no matter what type of printer it is, the UI is the same.
