Re: VM RSCS as RJP to JES3, replace current process and last 3745.
Thank you to all who have made suggestions to Mark. I have shared a lot of additional researhc with him. I have discussed this on a couple of different occassions with RSCS development teams. The only RSCS link that meets the current requirements is the MRJE link. An SNARJE link will not work because the RSCS support is designed to be the host end of the connection. It cannot act as the client end of an SNANJE connection. NJE connections are also currently being used but do not provide the capability to modify the disposition that is supported by the Bi-Sync RJE workstation support in JES. Rick Barlow Sr. z/VM Systems Programmer Nationwide Services Co., Technology Solutions, z/VM and System z Linux Support One Nationwide Plaza MB-02-201 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213Fax: (614) 249-3912 mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 09/28/2008 01:37:09 AM: IBMVM@LISTSERV.UARK.EDU On Friday, 09/26/2008 at 10:02 EDT, Mark T. Regan, K8MTR [EMAIL PROTECTED] wrote: Since we have VM/RSCS appearing as a RJP workstation to JES3 using EP and a 3745, can it do the same using the SNA protocol to look like a 3770 device, but minus the 3745? Your best bet is to try it. Create another RSCS link defined as SNARJE and create another JES3 link that talks to it. Leave your existing connections alone. I *think* the SNARJE link will be treated as local SNA-attached RJE terminal. Alan Altmark z/VM Development IBM Endicott
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
On Friday, 09/26/2008 at 10:02 EDT, Mark T. Regan, K8MTR [EMAIL PROTECTED] wrote: Since we have VM/RSCS appearing as a RJP workstation to JES3 using EP and a 3745, can it do the same using the SNA protocol to look like a 3770 device, but minus the 3745? Your best bet is to try it. Create another RSCS link defined as SNARJE and create another JES3 link that talks to it. Leave your existing connections alone. I *think* the SNARJE link will be treated as local SNA-attached RJE terminal. Alan Altmark z/VM Development IBM Endicott
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
Doesn't JES3 speak TCP/IP these days? If so, use the TCP/IP NJE driver to connect RSCS to JES3. I think it does (or it's trivial to use our NJE Bridge to provide an impedance matcher), but it sounds like the original setup has some kind of modified RJE exit on the JES3 side that sets the default for output to the JES system, not the originator of the job. In that case, you'd have to apply those mods to the NJE driver in JES3, which is not trivial. I think they are going to have to make some changes in the job stream to tell JES to dump the output locally, or make the mod to the NJE driver if they want the same functionality. It's not clear to me whether the specialized commands he's talking about are on the JES side or on the RSCS side, but in either case, they're looking at some refit.
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
On Fri, Sep 26, 2008 at 12:27 AM, Mark T. Regan, K8MTR [EMAIL PROTECTED] wrote: Our VM systems are already connected to JES3 using NJE via SNA. The problem is that when the jobs are submitted via NJE they are considered remote jobs. When they are submitted via the Bisync RJP connection, they are considered a locally submitted job. We want the JES3 system to keep thinking the jobs are submitted locally, even when coming over NJE. To do that, we've been told that a JES3 NJE command exit (IATUX35) has to be written. At the risk of showing my very thin z/OS skills, I believe we achieved this by submitting a job that would punch to the JES internal reader. That job would then appear to be a local one. It does require a change to the JCL, but if you set a REROUTE in RSCS, you can have a service machine on VM pick up the spool file, wrap it in an IEBGENER job and submit it for real. -Rob
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
Since we have VM/RSCS appearing as a RJP workstation to JES3 using EP and a 3745, can it do the same using the SNA protocol to look like a 3770 device, but minus the 3745? Thanks. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) From:The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark T. Regan, K8MTR Sent: Thursday, September 25, 2008 12:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM RSCS as RJP to JES3, replace current process and last 3745. We have an old process that is used to support submitting jobs from VM to JES3. The current process uses a 3745 running EP on it. Here's the EP configuration for them: The RSCS Side: *## EPNCPAB GROUP DIAL=NO, X LNCTL=BSC, X SPEED=9600, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=3277, X TYPE=EP RSCSB1 LINE ADDRESS=(196,32-0),TERM=3135 RSCS 43B #1 RSCS1 LINE ADDRESS=(197,32-2),TERM=3135 RSCS 43C #1 *## The JES3 side: *## RJE GROUP DIAL=NO, X LNCTL=BSC, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=2020, X TYPE=EP LNE2 LINE ADDRESS=(321,3D-3,3D-1),TERM=3135 RSCSB LNE3 LINE ADDRESS=(322,23-3,23-1),TERM=3135 RSCSC ** The VM side is using RSCS (TYPE is MRJE) to appear to JES3 as a RJP workstation. In JES3 it's defined as T=S370, with a console and three devices: RJPLINE,N=LNE2,A=(SYX,03D,SYY,03D,SYZ,03D),S=9600 * RJPTERM,N=VMX02,T=S370,RD=1,PR=2,PU=1,B=400,O=BFIX,G=VMX CONSOLE,TYPE=RJP,DEST=NONE,LEVEL=14,LL=79,JNAME=VMX02 DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR1, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR2, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT2540P,JNAME=VMX02PU1,DGROUP=VMX * Since our goal is to eliminate this last 3745, we would like to keep the impact to the users as minimal as possible. There are hundreds of jobs that are submitted from our two z/VM systems, a lot of them out of their scheduler systems. We have found that a lot of these jobs were set up ages ago, so there is no original author support for them anymore. In addition to using the RSCS to JES3 lines to submit jobs, the users also use a JQ function to requeue jobs as needed. The resulting console commands go across the RJP connection to JES3 too. The users also use a JL function that allows them to view the JES3 job output by accessing the JES spool directly. We have heard about Visara's FEP-4600 Communications Controller product, which supposedly supports EP connectivity, and we will be looking at it. Is the Visara product the only one out there? Are there any other options that we could pursue that will entail not having to force the application support people to make changes? I'm sure they would prefer something that would require them not to make any changes at all. We have a NJE connection between the z/VM and JES3 systems, but what we have heard is that without a JES3 mod, the incoming jobs are flagged as remote jobs and not local jobs. Therefore any resulting output can go back to VM by default. Supposedly the JES3 mod would somehow flag the job as being local to the JES3 system. Thanks. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You.
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
I'm not sure what the 'JL' command is but it sounds like you want your job sysout, jesmsg, etc. to stay over on the JES3 side. You might try editing the jcl on the VM side to include a //*MAIN ORG statement to override the origin similar to //*MAIN ORG=jes3node.LOCAL where jes3node is your zOS BDT node name. You can use OUTPUT or FORMAT statements as well but //*MAIN ORG might be best. I don't know what 'JL' is but we send jobs and data from zVM to zOS sendimng output to various vendor softcopy and output storage products. Some need special output classes. But if your current jcl works from VM with RJE then NJE may work fine if you try options with //*MAIN ORG. Always glad to see someone else using JES3. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark T. Regan, K8MTR Sent: Thursday, September 25, 2008 1:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM RSCS as RJP to JES3, replace current process and last 3745. We have an old process that is used to support submitting jobs from VM to JES3. The current process uses a 3745 running EP on it. Here's the EP configuration for them: The RSCS Side: *## EPNCPAB GROUP DIAL=NO, X LNCTL=BSC, X SPEED=9600, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=3277, X TYPE=EP RSCSB1 LINE ADDRESS=(196,32-0),TERM=3135 RSCS 43B #1 RSCS1 LINE ADDRESS=(197,32-2),TERM=3135 RSCS 43C #1 *## The JES3 side: *## RJE GROUP DIAL=NO, X LNCTL=BSC, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=2020, X TYPE=EP LNE2 LINE ADDRESS=(321,3D-3,3D-1),TERM=3135 RSCSB LNE3 LINE ADDRESS=(322,23-3,23-1),TERM=3135 RSCSC ** The VM side is using RSCS (TYPE is MRJE) to appear to JES3 as a RJP workstation. In JES3 it's defined as T=S370, with a console and three devices: RJPLINE,N=LNE2,A=(SYX,03D,SYY,03D,SYZ,03D),S=9600 * RJPTERM,N=VMX02,T=S370,RD=1,PR=2,PU=1,B=400,O=BFIX,G=VMX CONSOLE,TYPE=RJP,DEST=NONE,LEVEL=14,LL=79,JNAME=VMX02 DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR1, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR2, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT2540P,JNAME=VMX02PU1,DGROUP=VMX * Since our goal is to eliminate this last 3745, we would like to keep the impact to the users as minimal as possible. There are hundreds of jobs that are submitted from our two z/VM systems, a lot of them out of their scheduler systems. We have found that a lot of these jobs were set up ages ago, so there is no original author support for them anymore. In addition to using the RSCS to JES3 lines to submit jobs, the users also use a JQ function to requeue jobs as needed. The resulting console commands go across the RJP connection to JES3 too. The users also use a JL function that allows them to view the JES3 job output by accessing the JES spool directly. We have heard about Visara's FEP-4600 Communications Controller product, which supposedly supports EP connectivity, and we will be looking at it. Is the Visara product the only one out there? Are there any other options that we could pursue that will entail not having to force the application support people to make changes? I'm sure they would prefer something that would require them not to make any changes at all. We have a NJE connection between the z/VM and JES3 systems, but what we have heard is that without a JES3 mod, the incoming jobs are flagged as remote jobs and not local jobs. Therefore any resulting output can go back to VM by default. Supposedly the JES3 mod would somehow flag the job as being local to the JES3 system. Thanks. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
That would probably work for output, but if they're used to job progress messages on VM from JES via NJE msgs, that would break message routing, I think. Worth a try, though. Rob's idea is intriguing; the approach of letting a service machine mung the JCL into IEBGENR and submitting it via the internal rdr is clever (and gets the text processing work out of assembler and into REXX and Pipes, which would be double-plus good in terms of easy maintainability as well as getting rid of a JES exit or mod). If the //*MAIN ORG idea works, that'd be the way to implement it. Whatever they do, though, I think those custom commands are probably toast. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Smith, Ann (ISD, IT) Sent: Friday, September 26, 2008 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM RSCS as RJP to JES3, replace current process and last 3745. I'm not sure what the 'JL' command is but it sounds like you want your job sysout, jesmsg, etc. to stay over on the JES3 side. You might try editing the jcl on the VM side to include a //*MAIN ORG statement to override the origin similar to //*MAIN ORG=jes3node.LOCAL where jes3node is your zOS BDT node name. You can use OUTPUT or FORMAT statements as well but //*MAIN ORG might be best. I don't know what 'JL' is but we send jobs and data from zVM to zOS sendimng output to various vendor softcopy and output storage products. Some need special output classes. But if your current jcl works from VM with RJE then NJE may work fine if you try options with //*MAIN ORG. Always glad to see someone else using JES3.
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
Since we have VM/RSCS appearing as a RJP workstation to JES3 using EP and a 3745, can it do the same using the SNA protocol to look like a 3770 device, but minus the 3745? If I'm reading the RSCS docs correctly, no. The RJE drivers really do expect a physical line, as far as I can tell. The exit customization guide also seems to point that way.
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
We have NJE connections between our VSE guests and RSCS connected via Virtual CTCA as VSE runs as a guest under VM. Does you JES system run under VM? If so a virtual CTCA will work or if not, an emulated CTCA connection. Ray Waters From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark T. Regan, K8MTR Sent: Thursday, September 25, 2008 12:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM RSCS as RJP to JES3, replace current process and last 3745. We have an old process that is used to support submitting jobs from VM to JES3. The current process uses a 3745 running EP on it. Here's the EP configuration for them: The RSCS Side: *## EPNCPAB GROUP DIAL=NO, X LNCTL=BSC, X SPEED=9600, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=3277, X TYPE=EP RSCSB1 LINE ADDRESS=(196,32-0),TERM=3135 RSCS 43B #1 RSCS1 LINE ADDRESS=(197,32-2),TERM=3135 RSCS 43C #1 *## The JES3 side: *## RJE GROUP DIAL=NO, X LNCTL=BSC, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=2020, X TYPE=EP LNE2 LINE ADDRESS=(321,3D-3,3D-1),TERM=3135 RSCSB LNE3 LINE ADDRESS=(322,23-3,23-1),TERM=3135 RSCSC ** The VM side is using RSCS (TYPE is MRJE) to appear to JES3 as a RJP workstation. In JES3 it's defined as T=S370, with a console and three devices: RJPLINE,N=LNE2,A=(SYX,03D,SYY,03D,SYZ,03D),S=9600 * RJPTERM,N=VMX02,T=S370,RD=1,PR=2,PU=1,B=400,O=BFIX,G=VMX CONSOLE,TYPE=RJP,DEST=NONE,LEVEL=14,LL=79,JNAME=VMX02 DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR1, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR2, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT2540P,JNAME=VMX02PU1,DGROUP=VMX * Since our goal is to eliminate this last 3745, we would like to keep the impact to the users as minimal as possible. There are hundreds of jobs that are submitted from our two z/VM systems, a lot of them out of their scheduler systems. We have found that a lot of these jobs were set up ages ago, so there is no original author support for them anymore. In addition to using the RSCS to JES3 lines to submit jobs, the users also use a JQ function to requeue jobs as needed. The resulting console commands go across the RJP connection to JES3 too. The users also use a JL function that allows them to view the JES3 job output by accessing the JES spool directly. We have heard about Visara's FEP-4600 Communications Controller product, which supposedly supports EP connectivity, and we will be looking at it. Is the Visara product the only one out there? Are there any other options that we could pursue that will entail not having to force the application support people to make changes? I'm sure they would prefer something that would require them not to make any changes at all. We have a NJE connection between the z/VM and JES3 systems, but what we have heard is that without a JES3 mod, the incoming jobs are flagged as remote jobs and not local jobs. Therefore any resulting output can go back to VM by default. Supposedly the JES3 mod would somehow flag the job as being local to the JES3 system. Thanks. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You.
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
Doesn't JES3 speak TCP/IP these days? If so, use the TCP/IP NJE driver to connect RSCS to JES3. 2008/9/25 Ray Waters [EMAIL PROTECTED] We have NJE connections between our VSE guests and RSCS connected via Virtual CTCA as VSE runs as a guest under VM. Does you JES system run under VM? If so a virtual CTCA will work or if not, an emulated CTCA connection. Ray Waters -- *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On Behalf Of *Mark T. Regan, K8MTR *Sent:* Thursday, September 25, 2008 12:43 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* VM RSCS as RJP to JES3, replace current process and last 3745. We have an old process that is used to support submitting jobs from VM to JES3. The current process uses a 3745 running EP on it. Here's the EP configuration for them: The RSCS Side: *## EPNCPAB GROUP DIAL=NO, X LNCTL=BSC, X SPEED=9600, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=3277, X TYPE=EP RSCSB1 LINE ADDRESS=(196,32-0),TERM=3135 RSCS 43B #1 RSCS1 LINE ADDRESS=(197,32-2),TERM=3135 RSCS 43C #1 *## The JES3 side: *## RJE GROUP DIAL=NO, X LNCTL=BSC, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=2020, X TYPE=EP LNE2 LINE ADDRESS=(321,3D-3,3D-1),TERM=3135 RSCSB LNE3 LINE ADDRESS=(322,23-3,23-1),TERM=3135 RSCSC ** The VM side is using RSCS (TYPE is MRJE) to appear to JES3 as a RJP workstation. In JES3 it's defined as T=S370, with a console and three devices: RJPLINE,N=LNE2,A=(SYX,03D,SYY,03D,SYZ,03D),S=9600 * RJPTERM,N=VMX02,T=S370,RD=1,PR=2,PU=1,B=400,O=BFIX,G=VMX CONSOLE,TYPE=RJP,DEST=NONE,LEVEL=14,LL=79,JNAME=VMX02 DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR1, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR2, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT2540P,JNAME=VMX02PU1,DGROUP=VMX * Since our goal is to eliminate this last 3745, we would like to keep the impact to the users as minimal as possible. There are hundreds of jobs that are submitted from our two z/VM systems, a lot of them out of their scheduler systems. We have found that a lot of these jobs were set up ages ago, so there is no original author support for them anymore. In addition to using the RSCS to JES3 lines to submit jobs, the users also use a JQ function to requeue jobs as needed. The resulting console commands go across the RJP connection to JES3 too. The users also use a JL function that allows them to view the JES3 job output by accessing the JES spool directly. We have heard about Visara's FEP-4600 Communications Controller product, which supposedly supports EP connectivity, and we will be looking at it. Is the Visara product the only one out there? Are there any other options that we could pursue that will entail not having to force the application support people to make changes? I'm sure they would prefer something that would require them not to make any changes at all. We have a NJE connection between the z/VM and JES3 systems, but what we have heard is that without a JES3 mod, the incoming jobs are flagged as remote jobs and not local jobs. Therefore any resulting output can go back to VM by default. Supposedly the JES3 mod would somehow flag the job as being local to the JES3 system. Thanks. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) -- NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: VM RSCS as RJP to JES3, replace current process and last 3745.
Our VM systems are already connected to JES3 using NJE via SNA. The problem is that when the jobs are submitted via NJE they are considered remote jobs. When they are submitted via the Bisync RJP connection, they are considered a locally submitted job. We want the JES3 system to keep thinking the jobs are submitted locally, even when coming over NJE. To do that, we've been told that a JES3 NJE command exit (IATUX35) has to be written. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) - Original Message From: Kris Buelens [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, September 25, 2008 4:35:36 PM Subject: Re: VM RSCS as RJP to JES3, replace current process and last 3745. Doesn't JES3 speak TCP/IP these days? If so, use the TCP/IP NJE driver to connect RSCS to JES3. 2008/9/25 Ray Waters [EMAIL PROTECTED] We have NJE connections between our VSE guests and RSCS connected via Virtual CTCA as VSE runs as a guest under VM. Does you JES system run under VM? If so a virtual CTCA will work or if not, an emulated CTCA connection. Ray Waters From:The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark T. Regan, K8MTR Sent: Thursday, September 25, 2008 12:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM RSCS as RJP to JES3, replace current process and last 3745. We have an old process that is used to support submitting jobs from VM to JES3. The current process uses a 3745 running EP on it. Here's the EP configuration for them: The RSCS Side: *## EPNCPAB GROUP DIAL=NO, X LNCTL=BSC, X SPEED=9600, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=3277, X TYPE=EP RSCSB1 LINE ADDRESS=(196,32-0),TERM=3135 RSCS 43B #1 RSCS1 LINE ADDRESS=(197,32-2),TERM=3135 RSCS 43C #1 *## The JES3 side: *## RJE GROUP DIAL=NO, X LNCTL=BSC, X CLOCKNG=EXT, X CODE=EBCDIC, X CU=2701, X DUPLEX=FULL, X TERM=2020, X TYPE=EP LNE2 LINE ADDRESS=(321,3D-3,3D-1),TERM=3135 RSCSB LNE3 LINE ADDRESS=(322,23-3,23-1),TERM=3135 RSCSC ** The VM side is using RSCS (TYPE is MRJE) to appear to JES3 as a RJP workstation. In JES3 it's defined as T=S370, with a console and three devices: RJPLINE,N=LNE2,A=(SYX,03D,SYY,03D,SYZ,03D),S=9600 * RJPTERM,N=VMX02,T=S370,RD=1,PR=2,PU=1,B=400,O=BFIX,G=VMX CONSOLE,TYPE=RJP,DEST=NONE,LEVEL=14,LL=79,JNAME=VMX02 DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR1, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR2, FORMS=(NO,),DGROUP=VMX DEVICE,DTYPE=RMT2540P,JNAME=VMX02PU1,DGROUP=VMX * Since our goal is to eliminate this last 3745, we would like to keep the impact to the users as minimal as possible. There are hundreds of jobs that are submitted from our two z/VM systems, a lot of them out of their scheduler systems. We have found that a lot of these jobs were set up ages ago, so there is no original author support for them anymore. In addition to using the RSCS to JES3 lines to submit jobs, the users also use a JQ function to requeue jobs as needed. The resulting console commands go across the RJP connection to JES3 too. The users also use a JL function that allows them to view the JES3 job output by accessing the JES spool directly. We have heard about Visara's FEP-4600 Communications Controller product, which supposedly supports EP connectivity, and we will be looking at it. Is the Visara product the only one out there? Are there any other options that we could pursue that will entail not having to force the application support people to make changes? I'm sure they would prefer something that would require them not to make any changes at all. We have a NJE connection between the z/VM and JES3 systems, but what we have heard is that without a JES3 mod, the incoming jobs are flagged as remote jobs and not local jobs. Therefore any resulting output can go back to VM by default. Supposedly the JES3 mod would somehow flag the job as being local to the JES3 system. Thanks. Mark T. Regan, K8MTR CTO1 USNR-Retired (1969-1991) NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed
