It doesn't quite fit what the network designers want. When the MV1N system, the one I simply called MVS1 in the original diagram, is available, they want all MVS1 traffic to go through it. The other problem is that during our attempts to get TCPNJE to work on MVS, we found that JES2 went crazy when it had either more than or less than 2 streams defined. I don't know if that was even reported to IBM because the MVS guys were satisfied that 2 streams worked.
I guess that the best way for them to have automatic fail-over capabilities for the MVS1-plex is for them to build it into the network. Either that or have a group defined that contains the MVS1A, B, C, etc., machines defined but not the one normally handling the network for the plex. Then, if MV1N is down, they could route the traffic bound for MVS1 to the new group. It would take commands to switch, but it would work better than having all traffic just pile up until the network machine is available again. The business of the link is highly variable. Sometimes it sits idle for hours. Other times, it is busy enough to have as many as 200+ jobs pile up. Most jobs being submitted to MVS are small; some of the return traffic is quite significant (more than 10,000,000 records). Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes > Sent: Sunday, April 26, 2009 7:44 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: RSCS Connections > > On 4/26/09 9:37 PM, "Les Geer" <lg...@vnet.ibm.com> wrote: > > > > I haven't looked through the code which handles how files > are queued > > and transmitted in any great detail. However, what you describe > > sounds reasonable. In your MVSPLEX example, MVS1 must be > first in the > > group list so it will always be picked. > > Or at least checked first, which should handle most of the > cases. I think the check will count as a dispatch of the link > task, which should cause the file to be processed there if > there is an open stream on that link. > > > Keep in mind the file > > is queued on each link. The first link to be free and > dispatched will > > process the file. This may not always work as intended > based on how > > busy the MVS1 link is. > > Yes. You will get an occasional job taking the direct path > from RSCS to one of the execution nodes. If that's ok, cool. > If not, then this probably doesn't do what you want. > > Another thing -- you'll probably want to set the JES > resistance value very high for the direct RSCS->execution > node links so that they are used outbound only as a last > resort (ie when the normal link to MVS1 is not available). >
