On Tue, Mar 23, 2004 at 10:31:29AM -0600, McKown, John wrote: > Given this, I would gather that the decision to not do NJE on an IFL is a > "political" decision within IBM, not a technical one. That is, it will work, > but IBM is actively discouraging its use.
I don't think it's a case of actively discouraging it, but more of a "show me how it's useful and we'll talk about it". Show IBM a way to make money, and they're happy to help -- after all, at the end of the day, they gotta keep us shareholders happy. > My question is why is z/VM NJE needed on an IFL? I don't think that z/VM on > an IFL is meant to be used by CMS users for any kind of development. And > even if it were, I personally would use ftp to send jobs to remote sites, > not NJE. FTP is a lot harder to automate. Compare: ftp mvs.foo.com userid password put foo.jcl quit to SENDFILE foo text to SYSTEM at MVSHOST You have to deal with a number of possible errors at each step in the FTP, and recover appropriately -- NJE "just works", and handles all the retries and errors and queuing due to limited capacity, etc. NJE still has a place; it's the SNA and CTC connectivity parts that are the pain. If MVS ever got TCPNJE support, it's be a lot less of a pain. IBM is putting a lot of emphasis on Linux development for IFLs, but consider this: if you could move a big chunk of your editing and interactive work off TSO and ISPF but still provide easy job submission and output management that is z/OS-friendly in terms of device management, how much CPU on the z/OS side would you save? How long would that allow you to put off a capacity upgrade to your standard engine LPAR (and the corresponding financial beating from CA, etc for your 3rd party software)?? If you can combine interactive workloads (for CMS and Linux) on the IFLs and keep the production bits on zOS, suddenly the resource requirements vs cost models for z/OS aren't quite so ugly. That's a big piece of why something like RSCS on IFLs makes sense. > What am I missing? Remote printing? Use "lpd" on the remote end. Or is this > for VSE support of some kind? I know nothing of VSE (z/VM, z/Linux, and z/OS > only at present). VSE won't run on IFLs, so it's more likely to be the above interactive processing scenario. Consider also that lpr/lpd lose a lot of functionality compared to NJE (forms, fwd/backspacing, etc -- there's a reason why IPP was invented), and that not all lpr/lpd implementations are compatible. It's probably not what IBM intended for IFLs, but since when has the VM community worried much about that?...8-) Overall, creative uses for resources have helped the environment to survive. This would be another creative use for resources that makes the overall environment better. -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
