Re: NJE functionality using a linux server?
scp -q -i ~ken/.identity -B file remote:file What's so hard? FTP may be the lowest common denominator, but it's not the only solution. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Tuesday, March 23, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
Linux was NOT meant as the source or target of any of the data I wish to transfer via NJE. I was looking to use a linux server virtual machine as a replacement for RSCS/NJE functions. Do you have an SSH client and daemon running in your z/OS and CMS servers? /Thomas Kern /301-903-2211 -Original Message- From: Hall, Ken (IDS ECCS) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 08:08 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? scp -q -i ~ken/.identity -B file remote:file What's so hard? FTP may be the lowest common denominator, but it's not the only solution. -- 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
Re: NJE functionality using a linux server?
Admittedly no, which creates some conflicts for us, since we're not supposed to use insecure protocols like FTP. How about sshd for USS, IBM? Back on the topic at hand, why not use something like site submit for incoming jobs, and LPR/LPD printing for output coming back? You can set up destinations via NPF (or it's successor) on zOS. What is real NJE going to buy you? You can't RUN the jobs on the Linux node. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Kern, Thomas Sent: Wednesday, March 24, 2004 8:14 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? Linux was NOT meant as the source or target of any of the data I wish to transfer via NJE. I was looking to use a linux server virtual machine as a replacement for RSCS/NJE functions. Do you have an SSH client and daemon running in your z/OS and CMS servers? /Thomas Kern /301-903-2211 -Original Message- From: Hall, Ken (IDS ECCS) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 08:08 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? scp -q -i ~ken/.identity -B file remote:file What's so hard? FTP may be the lowest common denominator, but it's not the only solution. -- 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
I was waiting for Sir Santa to jump in and tell about Unsolicited File Transfer ? There's client and server for CMS, Linux, Windows (and probably his Palm too). How much effort would one in USS be? PS Heavy use may encourage Endicott to fix the client portion in SENDFILE ;-) Rob -- 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
Re: NJE functionality using a linux server?
How about sshd for USS, IBM? It's not supported, but see http://www-1.ibm.com/servers/eserver/zseries/zos/unix/bpxa1ty1.html#openssh -Mike MacIsaac, IBM mikemac at us.ibm.com (845) 433-7061 -- 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
Re: NJE functionality using a linux server?
Does this mean OpenSSL and OpenSSH will build under USS? I had mixed results trying to build Open Source products there, it's not exactly a high-profile platform. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Michael MacIsaac Sent: Wednesday, March 24, 2004 9:14 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? How about sshd for USS, IBM? It's not supported, but see http://www-1.ibm.com/servers/eserver/zseries/zos/unix/bpxa1ty1 .html#openssh -Mike MacIsaac, IBM mikemac at us.ibm.com (845) 433-7061 -- 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
We have gotten an SSH client to run under USS. In batch jobs, you need to use key files rather than passwords because it really is meant to be used by unix system administrators typing away at their terminals. We have not gotten SSH to work as a daemon under MVS. Again, linux was not meant to be the source or target of data simply as a third party pipe through which NJE traffic flowed. What I do not want to do is rewrite MVS jobstreams and CMS servers that ship data back and forth? There is NO budget for rewrites, NO budget for new product purchases, so it is me spending my evenings and weekends fixing other people's decisions. /Thomas Kern /301-903-2211 -Original Message- From: Hall, Ken (IDS ECCS) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 08:54 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? How about sshd for USS, IBM? Back on the topic at hand, why not use something like site submit for incoming jobs, and LPR/LPD printing for output coming back? You can set up destinations via NPF (or it's successor) on zOS. What is real NJE going to buy you? You can't RUN the jobs on the Linux node. -- 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
Re: NJE functionality using a linux server?
Ken, Does this mean OpenSSL and OpenSSH will build under USS? I had mixed results trying to build Open Source products there, it's not exactly a high-profile platform. I haven't done much with USS in a long time, so I can't promise it will build. However, on the Web site I referenced, there is an e-mail address of the developer (Raj) in POK who did the latest port. -Mike MacIsaac, IBM mikemac at us.ibm.com (845) 433-7061 -- 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
Re: NJE functionality using a linux server?
scp -q -i ~ken/.identity -B file remote:file What's so hard? FTP may be the lowest common denominator, but it's not the only solution. I agree, but... NJE support is built in to z/OS. SCP isn't, and the ssh port for USS is pretty precarious. SSH/SCP aren't supported at all on VM or VSE (w/o 3rd party tools). FTP or NJE are what you have if you have to play nice with the rest of the IBM family. . SCP also isn't integrated at all into spooling and output management. I've been toying with the idea of writing a IPP server/client for CMS and friends -- it wouldn't be too hard to expand that to support file transfer as well. IPP supports a file: class. I suppose that would be a nice enhancement request for RSCS: IPP support. Given that, most of the drawbacks of printing from the various IBM operating systems to distributed printers would just go away (and we'd regain a lot of nice function that LPR just doesn't support). -- 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
Re: NJE functionality using a linux server?
I came into the discussion a little late, so I had to read back to find out exactly what the problem was. You're right, but it seems like adding scp (or even rcp) capability to USS/zOS would make more sense than trying to back-port something like NJE to Linux just for yet another file transfer mechanism. Neither FTP nor NJE are particularly secure, which wasn't a problem using NJE over dedicated SNA links, but that world is rapidly disappearing. It's zOS that should be trying to play nice now, and while they've made some progress, USS still seems to be far enough behind the curve to keep it from being a player. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Wednesday, March 24, 2004 10:01 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? scp -q -i ~ken/.identity -B file remote:file What's so hard? FTP may be the lowest common denominator, but it's not the only solution. I agree, but... NJE support is built in to z/OS. SCP isn't, and the ssh port for USS is pretty precarious. SSH/SCP aren't supported at all on VM or VSE (w/o 3rd party tools). FTP or NJE are what you have if you have to play nice with the rest of the IBM family. . SCP also isn't integrated at all into spooling and output management. I've been toying with the idea of writing a IPP server/client for CMS and friends -- it wouldn't be too hard to expand that to support file transfer as well. IPP supports a file: class. I suppose that would be a nice enhancement request for RSCS: IPP support. Given that, most of the drawbacks of printing from the various IBM operating systems to distributed printers would just go away (and we'd regain a lot of nice function that LPR just doesn't support). -- 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
How about sshd for USS, IBM? There is a port; it's more than a little fragile, though. Back on the topic at hand, why not use something like site submit for incoming jobs, and LPR/LPD printing for output coming back? You can set up destinations via NPF (or it's successor) on zOS. Then we're back to automating FTP, and LPR/LPD don't support forms well, or a number of other useful printing features. It's not that there aren't other ways to do this, it's that the other ways are poorly integrated and really feel like what they are: afterthoughts grudgingly bolted on the side to make it work, rather than doing the extra work to make the integration seamless. What is real NJE going to buy you? You can't RUN the jobs on the Linux node. Here's a few I can think of: Access to superior (IMHO) interactive editing environments Access to industry standard source code management tools Unattended operation of file transfers Automated queuing and retry if destination host unavailble Implied sequencing of file transfers multifile parallel transfer support (possible with gridftp, but z/OS doesn't speak gridftp yet w/o my Globus port) Single auditing point for information transfer. Single connection between hosts (easier on FWs) TCPNJE is trivially SSL-wrappable Transparent output routing from batch (can be done with NPF, but w/o full forms processing capability) etc... Linux/Solaris/AIX/HPUX and even the Windows goons are already moving past LPR/LPD and SMB to IPP. Time for VM and z/OS to do the same. Easiest way to do that: put IPP support in RSCS and use NJE from z/OS and VM to deliver the goods to RSCS or a Linux guest. Zero mods on z/OS, some work on VM or Linux, everybody wins. We also need TCPNJE support on z/OS. I argued this back on the VMESA-L mailing list a while back: if channel-attached printing is really dying off, then it's time to finish the job on integrating printing and output management into RSCS and make it the de facto output manager for VM. PRINT and friends need to start being cognizant of that fact. It's the right thing to do. -- 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
Re: NJE functionality using a linux server?
It will build, but I *strongly* recommend doing the ./configure somewhere else, specifying the USS platform as a command line option, and then transferring the resulting source to USS for compilation. There is a lot of munging that happens in the configure step that uses stuff that USS make doesn't grok. There are also still a few lingering ASCII/EBCDIC conversion bugs that I haven't had time to track down. Also, take a look at the OpenCryptki mods that IBM did to allow OpenSSL to use the PCI crypto cards. There is a *dramatic* (more than 4x) improvement in SSL performance if those mods are installed (both on Linux and z/OS). Does this mean OpenSSL and OpenSSH will build under USS? I had mixed results trying to build Open Source products there, it's not exactly a high-profile platform. -- 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
Re: NJE functionality using a linux server?
Neither FTP nor NJE are particularly secure, which wasn't a problem using NJE over dedicated SNA links, but that world is rapidly disappearing. It's zOS that should be trying to play nice now, and while they've made some progress, USS still seems to be far enough behind the curve to keep it from being a player. I guess I'm a victim of too many years of we're z/OS, we make the big bucks, you have to cope with our decision to think it likely that z/OS will change before the others do. The TCPNJE requirement for JES has been active for at least 2-3 years, and we still don't have it. I also really hesitate to ask IBM to put any more dependency on USS. It really isn't something productive to work with, and I don't think it *can* catch up. TCPNJE support in JES would fix most of the things that are broken with NJE, and once that happens, then the HUJI-NJE code can take it from there. -- 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
Re: NJE functionality using a linux server?
Fragile: All the more reason for IBM to come up with an official version. I only suggested site submit and lpr/lpd as stopgap substitutes for the functionality. For printing, I can see MANY better alternatives than an NJE variation. There's no point to sending the report to a Linux system when you can print directly to an IP print server. I'll leave the issue of forms and fancy formatting as an exercise for the masochistic. I supported NPF on zOS here for some time, and it was a pain in the neck. The TCPIP addon for VPS is a little better, but VERY expensive. There are products that do AFP-to-PCL or Postscript translation, but they're also expensive and complicated. For job submission, there are also many alternatives. It wouldn't be hard to use the lpr mechanism to queue site submits, hiding the mechanics from the end user. When I read back through the original notes though, I got the (belated) impression that what he REALLY wants here is to send files via SENDFILE/XMIT, mainly because there's no other cheap/free method supported on zOS. (Am I right?) But in principle, we're in agreement here, near as I can tell. zOS and zVM should be trying harder to keep up with the rest of the world now they IBM has supposedly committed to Open Standards. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Wednesday, March 24, 2004 10:22 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? How about sshd for USS, IBM? There is a port; it's more than a little fragile, though. Back on the topic at hand, why not use something like site submit for incoming jobs, and LPR/LPD printing for output coming back? You can set up destinations via NPF (or it's successor) on zOS. Then we're back to automating FTP, and LPR/LPD don't support forms well, or a number of other useful printing features. It's not that there aren't other ways to do this, it's that the other ways are poorly integrated and really feel like what they are: afterthoughts grudgingly bolted on the side to make it work, rather than doing the extra work to make the integration seamless. What is real NJE going to buy you? You can't RUN the jobs on the Linux node. Here's a few I can think of: Access to superior (IMHO) interactive editing environments Access to industry standard source code management tools Unattended operation of file transfers Automated queuing and retry if destination host unavailble Implied sequencing of file transfers multifile parallel transfer support (possible with gridftp, but z/OS doesn't speak gridftp yet w/o my Globus port) Single auditing point for information transfer. Single connection between hosts (easier on FWs) TCPNJE is trivially SSL-wrappable Transparent output routing from batch (can be done with NPF, but w/o full forms processing capability) etc... Linux/Solaris/AIX/HPUX and even the Windows goons are already moving past LPR/LPD and SMB to IPP. Time for VM and z/OS to do the same. Easiest way to do that: put IPP support in RSCS and use NJE from z/OS and VM to deliver the goods to RSCS or a Linux guest. Zero mods on z/OS, some work on VM or Linux, everybody wins. We also need TCPNJE support on z/OS. I argued this back on the VMESA-L mailing list a while back: if channel-attached printing is really dying off, then it's time to finish the job on integrating printing and output management into RSCS and make it the de facto output manager for VM. PRINT and friends need to start being cognizant of that fact. It's the right thing to do. -- 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
On Wednesday, 03/24/2004 at 09:59 EST, Michael MacIsaac/Poughkeepsie/[EMAIL PROTECTED] wrote: I haven't done much with USS in a long time, so I can't promise it will build. However, on the Web site I referenced, there is an e-mail address of the developer (Raj) in POK who did the latest port. Be sure to read the caveats carefully. There are apparently a bunch of things that aren't working. (Hence the unsupported status.) Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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
Re: NJE functionality using a linux server?
On Mer, 2004-03-24 at 01:52, David Boyes wrote: FTP is a lot harder to automate. Compare: ftp mvs.foo.com userid password put foo.jcl quit Tools question. At leas on the unix/linux side there are handy programs like ncpftpget/ncftpput Alan -- 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
Re: NJE functionality using a linux server?
I know, but that world is disappearing fast, and IBM seems to be adapting everywhere else. I agree with you, it's long past time the printing mess should be cleaned up, and zOS and zVM should join the rest of the world. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Wednesday, March 24, 2004 10:50 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? Neither FTP nor NJE are particularly secure, which wasn't a problem using NJE over dedicated SNA links, but that world is rapidly disappearing. It's zOS that should be trying to play nice now, and while they've made some progress, USS still seems to be far enough behind the curve to keep it from being a player. I guess I'm a victim of too many years of we're z/OS, we make the big bucks, you have to cope with our decision to think it likely that z/OS will change before the others do. The TCPNJE requirement for JES has been active for at least 2-3 years, and we still don't have it. I also really hesitate to ask IBM to put any more dependency on USS. It really isn't something productive to work with, and I don't think it *can* catch up. TCPNJE support in JES would fix most of the things that are broken with NJE, and once that happens, then the HUJI-NJE code can take it from there. -- 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
True. I was thinking the same thing. It isn't hard to wrap the hard stuff to hide the details. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Alan Cox Sent: Wednesday, March 24, 2004 11:03 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] NJE functionality using a linux server? On Mer, 2004-03-24 at 01:52, David Boyes wrote: FTP is a lot harder to automate. Compare: ftp mvs.foo.com userid password put foo.jcl quit Tools question. At leas on the unix/linux side there are handy programs like ncpftpget/ncftpput Alan -- 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 == If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ == -- 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
Re: NJE functionality using a linux server?
On Wednesday, 03/24/2004 at 10:50 EST, David Boyes [EMAIL PROTECTED] wrote: I guess I'm a victim of too many years of we're z/OS, we make the big bucks, you have to cope with our decision to think it likely that z/OS will change before the others do. The TCPNJE requirement for JES has been active for at least 2-3 years, and we still don't have it. My great-grandfather told me many years ago that the universe has certain constants: - death and taxes - IBM is aware of the requirement. - Patience is a virtue. - Good things come to those who wait. Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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
Re: NJE functionality using a linux server?
I picked up a nice button at SCIDS a few years ago. If all the people who are tired of hearing (Vendor/Manager of your choice) say Soon were laid end-to-end... They'd be more comfortable. /Thomas Kern /301-903-2211 -Original Message- From: Alan Altmark [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 11:17 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? My great-grandfather told me many years ago that the universe has certain constants: - death and taxes - IBM is aware of the requirement. - Patience is a virtue. - Good things come to those who wait. Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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
Re: NJE functionality using a linux server?
Tools question. At leas on the unix/linux side there are handy programs like ncpftpget/ncftpput I like those two tools, but unless they've been updated recently, neither handle record length problems, out of spool space errors, or other things that are esoteric platform-specific errors other than spitting out unknown error and failing the transfer. Not desirable behavior in this scenario -- could be fixed, but it's a moving target and still doesn't solve the more general integration problem. I guess for me it comes down to if I don't *have* to invent a wheel, why should I? NJE isn't inherently bad at what it's designed to do, and there's no reason why it shouldn't work on Linux as well. In this case, it's a good solution for the problem. -- 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
Re: NJE functionality using a linux server?
I was waiting for Sir Santa to jump in and tell about Unsolicited File Transfer ? I was waiting for the invitation! ;-) UFT does over IP the same thing conceptually that NJE does over SNA or leased lines, and does so without the need to administer additional network topology. (While NJE over IP is great, and would be my choice for connecting VM-to-VM, you do have the burden of yet-another-network-topology to think about.) There's client and server for CMS, Linux, Windows (and probably his Palm too). How much effort would one in USS be? And there is UFT support in RSCS. UFT runs just fine on USS. I don't have access to USS resources to build it for the purpose of distribution. That is, it would not be right to use my employer's machine to generate USS executables. But otherwise the code should compile and run quite nicely. The -a flag on the 'sf' command works as intended when run under USS, converting EBCDIC plain text to ASCII plain text while sending. So maybe someone would offer to build it and contrib that back. PS Heavy use may encourage Endicott to fix the client portion in SENDFILE ;-) And that would be great. The downside to UFT is the lack of a good RDRLIST equiv on Unix/Linux. Time! Time! There's just never enough time! -- R; -- 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
Re: NJE functionality using a linux server?
On Wed, 2004-03-24 at 10:20, Kern, Thomas wrote: I picked up a nice button at SCIDS a few years ago. If all the people who are tired of hearing (Vendor/Manager of your choice) say Soon were laid end-to-end... They'd be more comfortable. Ah. Let us take a moment to savor the genius of Dorothy Parker. Her formulation was, If all the girls in Hollywood were laid end-to-end, I wouldn't be a bit surprised. Razors pain you, Adam -- 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
Re: NJE functionality using a linux server?
On Mer, 2004-03-24 at 01:52, David Boyes wrote: FTP is a lot harder to automate. Compare: ... On Wed, 24 Mar 2004, Alan Cox wrote: Tools question. At leas on the unix/linux side there are handy programs like ncpftpget/ncftpput Admin problem too. FTP assumes, by virtue of the nature of the implementations in use today, that you are signing on as some user and writing into some authorized filespace. NJE springs from a very different model: the idea is (files sent as) jobs being delivered around the network. UFT was designed to offer NJE functionality that FTP lacked. You could get the same effect with e-mail and attachments, except that e-mail is designed for correspondence (and there's the spam problem). -- R; -- 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
Re: NJE functionality using a linux server?
And there is UFT support in RSCS. Is UFT support in the included with z/VM RSCS or in the pay extra $ for RSCS license? Marcy Cortes -- 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
Re: NJE functionality using a linux server?
According to a presentation I just looked written by an IBMer but presented by a third-party called RSCS Communicates with everything (except possibly your teenagers), the UFT outbound process is part of the base RSCS functionality and the UFTD inbound process is part of the licensed part of RSCS that is not licensed for IFLs unless you can say whatever the magic words are for IBM. /Thomas Kern /301-903-2211 -Original Message- From: Marcy Cortes [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 12:48 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? And there is UFT support in RSCS. Is UFT support in the included with z/VM RSCS or in the pay extra $ for RSCS license? Marcy Cortes -- 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
Re: NJE functionality using a linux server?
Since the NJE functionality of RSCS cannot be licensed for an IFL installation, has anyone used a linux server to replace this functionality? CTC/ESCON connectivity would still be available as would TCP/IP since our MVS server does do TCPNJE to other systems. Hooray! When did MVS get TCPNJE support? You can use HUJI-NJE to connect (albeit with limited stream support) to a TCPNJE implementation. This is fairly full-function in terms of NJE processing and being able to do things like route MVS output to email and stuff like that. There's a copy for download on the RSCS page -- you may need to do a little tinkering to get it running on 2.4 due to some changes in header files. Another possibility would be to use an IPP to LPD gateway to simulate job transfer. Last: push your IBM rep a little harder. There are certainly sites that have RSCS on IFLs with full function active. It just takes a little more work on their part to get the order processed. -- 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
Re: NJE functionality using a linux server?
Okay, This is what I get for not have at least 3 mugs of coffee before listening to my MVS officemate. Our MVS system has something called Anynet SNA over IP that we use to communicate with other MVS sites. /Thomas Kern /301-903-2211 -Original Message- From: David Boyes [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:30 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? Hooray! When did MVS get TCPNJE support? You can use HUJI-NJE to connect (albeit with limited stream support) to a TCPNJE implementation. This is fairly full-function in terms of NJE processing and being able to do things like route MVS output to email and stuff like that. There's a copy for download on the RSCS page -- you may need to do a little tinkering to get it running on 2.4 due to some changes in header files. Another possibility would be to use an IPP to LPD gateway to simulate job transfer. Last: push your IBM rep a little harder. There are certainly sites that have RSCS on IFLs with full function active. It just takes a little more work on their part to get the order processed. -- 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
Re: NJE functionality using a linux server?
I would agree with David. Based on David's experience, and Alan Altmark's comments that everything is negotiable, you should be able to get a license on an IFL. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Kern, Thomas Sent: Tuesday, March 23, 2004 11:13 AM To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? Okay, This is what I get for not have at least 3 mugs of coffee before listening to my MVS officemate. Our MVS system has something called Anynet SNA over IP that we use to communicate with other MVS sites. /Thomas Kern /301-903-2211 -Original Message- From: David Boyes [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:30 To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? Hooray! When did MVS get TCPNJE support? You can use HUJI-NJE to connect (albeit with limited stream support) to a TCPNJE implementation. This is fairly full-function in terms of NJE processing and being able to do things like route MVS output to email and stuff like that. There's a copy for download on the RSCS page -- you may need to do a little tinkering to get it running on 2.4 due to some changes in header files. Another possibility would be to use an IPP to LPD gateway to simulate job transfer. Last: push your IBM rep a little harder. There are certainly sites that have RSCS on IFLs with full function active. It just takes a little more work on their part to get the order processed. -- 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 -- 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
Re: NJE functionality using a linux server?
-Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:29 AM To: [EMAIL PROTECTED] Subject: Re: NJE functionality using a linux server? I would agree with David. Based on David's experience, and Alan Altmark's comments that everything is negotiable, you should be able to get a license on an IFL. Mark Post 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. 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. 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). -- John McKown Senior Systems Programmer UICI Insurance Center Applications Solutions Team This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: NJE functionality using a linux server?
On Tuesday, 03/23/2004 at 10:31 CST, McKown, John [EMAIL PROTECTED] wrote: 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. 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). The only reasonable use I've seen for NJE on IFL is when it is part of a pre-existing systems management infrastructure that you were/are using for z/VM on standard engines. As an NJE hub or gateway? No. As an NJE print server? No. But, of course, every situation is unique and has to be judged on its own merits, not against some arbitrary standard. That's why we do special bids. Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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
Re: NJE functionality using a linux server?
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
