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,QQQQ),DGROUP=VMX
> DEVICE,DTYPE=RMT3211,TRAIN=(NO,RN),HEADER=YES,JNAME=VMX02PR2,
>      FORMS=(NO,QQQQ),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

Reply via email to