I certainly am. It is time to ask the big question, "WHY ME, GOD?"
The files are anything from jobs being submitted to files being sent via SENDFILE. There are no error messages, neither before nor after, on either side of the link. As for recreation, all I have to do is to stop the link and then start it. It has been so looooong since I have taken an RSCS dump, are there any special parameters I should include? IIRC, it is something like "VMDUMP 0-END NSS FORMAT DCSS TO userid". Have I missed anything? Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Monday, August 06, 2007 6:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RSCS Gee Rich you certainly are encountering quite a few problems running TCPNJE. So is this a file local to the VM system where RSCS is not sending to the z/OS partner? in otherwords a locally originated file? Or is it a file from another node passing through this one? Are there any error messages for the link prior to the file hang? It sounds like this is recreatable for the one link so how about turning on link tracing, when you have a trace of the failure please open a ticket with the RSCS support center and we will have a look. At the same time, also obtain a dump of the RSCS machine. Best Regards, Les Geer IBM z/VM and Linux Development >I forgot to mention in my earlier post, repeated below, FLUSH does not >actually do anything to the Sending status of the file supposedly being >sent. It does not terminate the processing, if one can call hanging >around doing nothing processing, of the file. A subsequent Stop does >cause the Flushed file to be purged. > >Text of previous message > >We have several TCPNJE links between VM and z/OS systems. All are >working except 1. Even it worked for 6 days. Then it began to not send >jobs to its partner z/OS system. It receives files, sends commands and >receives responses, and receives output of jobs tagged for the VM >system, but simply refuses to send a job. Repeated QUERY FILES ON MVSSYS >commands show the same small (73 records) file being sent with an ever >increasing queue of jobs to be sent. > >VM is z/VM 5.2.0 at RSU 0701 plus reach-ahead. The entries in RSCS >CONFIG are: > > LINKDEF MVSSYS TYPE TCPNJE AST RETRY > PARM MVSSYS HOST=xx.xxx.x.xx STREAMS=2 BUFF=8192 = >KEEPALIV=NO >ITO=100 > >There are 6 other links to z/OS systems having the same definitions, >varying only in node name and IP Address. Two of them, very busy ones at >that, have been running for over a month with no problems. Even another >started at the same time as this one continues to work. The MVS folks >have rechecked their maintenance and have confirmed that this system has >all the same maintenance as the others, including fixes for TCPNJE >problems. > >II have looked at the RSCS console log and see no errors on the link. >Here are the console entries for the last jog successfully sent - the >date is today, the times GMT . > >10:56:12 DMTAXM101I File 8290 (8290) enqueued on link MVSSYS > >10:56:13 DMTNTR146I Sending file 8290 (8290) on link MVSSYS from >VMSYS(LOGPRINT), records 198 >10:56:13 DMTNTR147I Sent file 8290 (8290) on link MVSSYS to MVSSYS(JOB) > >10:56:13 DMTAXM105I File 8290 purged > > >Following that, jobs began to queue up. We continue to receive files and >job output, but cannot send a file or submit a job. Commands to the MVS >system are executed normally. There are no error messages in the logs of >either system. We have taken the link down and restarted it several >times, to no avail. I have purged several of the files that all appeared >similar to the one that was originally hung, also to no avail. > >Does anyone have any idea about what is going on? > >I would love to send a dump to someone, but I fear a dump of a system >that is doing nothing would not be very helpful :-). >Regards, >Richard Schuh >
