We have connected our RSCS machine to a z/OS test system via TCPNJE. We keep getting this sequence of messages: 22:22:40 DMTCMY700I Activating link MVSG TCPNJE line=0000 class=* queueing=prior 22:22:40 DMTTNE181I Link MVSG ready for session initiation 22:22:40 DMTTNE182I Link MVSG session established 22:22:40 DMTNCR905I Signon of link MVSG complete, buffer size=4096 22:45:18 DMTTNE083E Socket error on link MVSG request=Recv 22:45:18 DMTTNE183I Link MVSG session terminated 22:45:18 DMTMAN002I Link MVSG deactivated
The messages above are consecutive in the console log, with no intervening messages that were deleted. Following this, the z/OS system immediately signs on again. HELP for message DMTTNE083E indicates that a return code gives further documentation. What return code? It certainly is not in the messages. The format of the message is different than the format shown in the HELP file. I know, this is a matter for an RCF. That will come later as I have a more immediate problem, the one of solving the riddle of what actually happened and stabilizing the link.. The RSCS link was defined using a command like "DEFINE MVSG TYPE TCPNJE PARM HOST=10.245.46.89" followed by a START MVSG command. Files can be sent back and forth across the link. The messages only seem to occur when there is no activity for a period that probably matches a timeout value; however, I see nothing in the documents about specifying or altering a timeout for the RSCS end of the link. It may be of interest that we have a TCPNJE link between two of our VM systems. It has no such problem, which tends to make me believe that a timeout interval, if there is one, must be an MVS thingy. How do I find out what is happening? If it is a timeout, what do I do to prevent it from happening? Regards, Richard Schuh
