>Hmm. If it truly doesn't matter which node things run on, this might be >worth trying: > >Define a link to MVS1 with 7 streams. Define links to each node of the plex >with 1 stream each. Put all the links into a group called MVSPLEX. ROUTE >(or REROUTE) MVS1 to GROUP MVSPLEX. > >What I think should happen is that the file will be queued onto the first >link in the group that has an open stream, which will normally be MVS1, and >you get the behavior you originally described. If all streams on MVS1 are >busy, RSCS should select one of the other links and queue it directly to on >e >of the execution nodes that has a open stream for transmission. > >This should get you the behavior you want most of the time, and also remove >the MVS1 front-end system as both a bottleneck and a single point of failur >e >in the configuration -- if link MVS1 fails, there are no streams available, >and the jobs will (more slowly) get distributed to the execution systems >directly. > >Admittedly, I haven't tried it, but it seems like it should work. Les, am I >totally misunderstanding how link groups work?
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. 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. Best Regards, Les Geer IBM z/VM and Linux Development
