The documentation that I read explicitly states that only one file is actually sent at a time, regardless of the number of streams defined. From Section "A.37 PARM Statement for a TCPNJE-Type Link" of the RSCS Planning and Installation manual:
"2. RSCS cannot actually send more than one file at a time. When several files are active on different streams, RSCS sends the file with the smallest number of blocks and credits the other files for having to wait. After the file is transmitted, RSCS subtracts the credits from the number of blocks left to send for each active file. RSCS then chooses the file with the lowest number to send. The longer a large file has to wait, the more credits it will accumulate. When the difference between the accumulated credits and the actual file size becomes small enough, RSCS transmits the large file." However, that appears to be irrelevant to the problem. With 2 streams, the default, the second was always rejected. With 4 streams, apparently the same number as JES, the data flowed for an indeterminate time until stream 1 was eventually rejected, at which point the link froze. Both sides of the link show the same error message when it happens. There are defaults for TA and TAPARM. (TA=1, TAPARM according to a table.) Are they not usable? If anybody (Mike, are you reading this?) has a working TCPNJE connection between z/VM and z/OS, I would appreciate it if you would either post your definitions or send them to me in a plain brown envelope, electronic of course. We are on z/VM 5.2, if that makes a difference. Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Thursday, May 17, 2007 6:56 PM To: [email protected] Subject: Re: Message DMTNTR930E >Flash!!! > >After restarting 2 or 3 times without the STREAMS= and getting nowhere >(an immediate DMTNTR930E message and no file transfer activity), with a >rapidly expanding queue, the MVS guy said that JES was configured for 4 >streams. I tried STREAMS=4 and got immediate action. The queue of over >100 jobs was reduced to 1 before another DMTNTR930E struck and, once >again, froze the link. > >Why STREAMS=4 did anything at all to get the link to work is beyond >me. >That may have been happenstance; maybe the link thawed out for some >other reason. According to the documentation, having a number higher >than 1 does not cause files to be transferred concurrently; it merely >affects the order in which files are sent under some circumstances. They >are still sent one at a time. > >The key is the DMTNTR930E. The question is, "What can we do to determine >the cause of the error?" > Streams indicates to RSCS how many file streams can be in progress simultaneously. How many files can be sent at once. There must be a corresponding stream on the JES side defined or you will receive errors such as this. For example, if RSCS has defined 4 streams but JES only 3 then when RSCS requests to send a file on stream 4 JES will reject the request. This is irregardless of the link type, NJE, SNANJE, or TCPNJE. You also need to setup the TA= and TAPARM= parms accordingly. This tells RSCS what size files to send on each stream Best Regards, Les Geer IBM z/VM and Linux Development
