Colin--It's been 7-8 years since I put in a plain NJE connection between an
MVS and a VM system. We had had SNANJE connections for a long time, but
for performance reasons, wanted to add an additional NJE link, leaving the
SNANJE link in place. I don't remember any special gyrations I had to go
thru and certainly saw no problems. In reviewing the PARM statement in the
RSCS manual, it looks like you need to be careful about having matching
numbers of STREAMS on both ends.
As an aside, there is a tremendous improvement in performance in an NJE
link compared to SNANJE. If memory serves me right, we were seeing an
improvement on the order of 5-10 times, so you will gain not only in budget
savings, but also in performance.
Jim
At 07:35 AM 6/30/2006, you wrote:
This is a multipart message in MIME format.
--=_alternative 003FB230C125719D_=
Content-Type: text/plain; charset="US-ASCII"
I am not sure if anyone can give me any advice on this.
Between our VM systems we use TCPNJE for RSCS links. This leaves us with
only a few links to MVS using SNANJE. (Our MVS people expect to have
TCPNJE support installed in Q1/Q2 next year).
All terminal traffic to VM is now migrated to TCPIP so VM/VTAM is a
**VERY** expensive product for just these few remaining links to MVS.
As an interim measure for the next year we have defined some ESCON CTC
links (BCTC) between MVS & VM & are trying to get non-SNA NJE links
working.
The link is defined and connects successfully. I can also route traffic
over it successfully. However we do see a small but increasing error count
on the link.
The problem comes when I close the SNA link so that all the traffic goes
over the NJE line in both directions. After a while we get DMTNTR930E
message (reason code 0000) denying the request to start stream 1 and a
file sits blocking the link until action is taken.
Buffer sizes on both sides are the same (but a bit small at 520). It will
take some weeks to get a JES restart on the MVS side to change this.
Is there anything I can do (or any parameters I can change) to make this
more reliable - or is it just the nature of the beast?
Colin Allinson
Amadeus Data Processing
--=_alternative 003FB230C125719D_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">I am not sure if anyone can give me
any advice on this.</font>
<br>
<br><font size=2 face="sans-serif">Between our VM systems we use TCPNJE
for RSCS links. This leaves us with only a few links to MVS using SNANJE.
(Our MVS people expect to have TCPNJE support installed in Q1/Q2 next
year).</font>
<br>
<br><font size=2 face="sans-serif">All terminal traffic to VM is now migrated
to TCPIP so VM/VTAM is a **VERY** expensive product for just these few
remaining links to MVS.</font>
<br>
<br><font size=2 face="sans-serif">As an interim measure for the next year
we have defined some ESCON CTC links (BCTC) between MVS & VM &
are trying to get non-SNA NJE links working.</font>
<br>
<br><font size=2 face="sans-serif">The link is defined and connects
successfully.
I can also route traffic over it successfully. However we do see a small
but increasing error count on the link.</font>
<br>
<br><font size=2 face="sans-serif">The problem comes when I close the SNA
link so that all the traffic goes over the NJE line in both directions.
After a while we get DMTNTR930E message (reason code 0000) denying the
request to start stream 1 and a file sits blocking the link until action
is taken.</font>
<br>
<br><font size=2 face="sans-serif">Buffer sizes on both sides are the same
(but a bit small at 520). It will take some weeks to get a JES restart
on the MVS side to change this.</font>
<br>
<br><font size=2 face="sans-serif">Is there anything I can do (or any
parameters
I can change) to make this more reliable - or is it just the nature of
the beast?</font>
<br>
<br><font size=2 face="sans-serif">Colin Allinson</font>
<br><font size=2 face="sans-serif">Amadeus Data Processing</font>
<br>
<br><font size=2 face="sans-serif"> </font>
--=_alternative 003FB230C125719D_=--
Jim Bohnsack
Cornell Univ.
(607) 255-1760
