I don't know why the mdisk works and the attached disk doesn't. If the label is still "SCRTCH", then nothing was written on the disk. That seems like the TCP/IP connection wasn't established correctly. We should take this offline to work on it further.
On Tue, Apr 5, 2011 at 4:27 PM, Brian Nielsen <bniel...@sco.idaho.gov> wrote: > On Tue, 5 Apr 2011 22:15:31 +0200, Rob van der Heij <rvdh...@gmail.com> > wrote: > >>On Tue, Apr 5, 2011 at 10:07 PM, Brian Nielsen <bniel...@sco.idaho.gov> > wrote: >> >>> PIPTCQ1015E ERRNO 54: ECONNRESET. >>> PIPMSG004I ... Issued from stage 3 of pipeline 3 name "iprestore". >>> PIPMSG001I ... Running "tcpdata". >>> PIPUPK072E Last record not complete. >>> PIPMSG003I ... Issued from stage 2 of pipeline 1. >>> PIPMSG001I ... Running "unpack". >>> Data restore failed. >>> Ready(01015); T=0.01/0.02 13:39:17 >> >>Sounds like PIPEDDR is not properly handling the termination of the >>TCP/IP connection (like the sender going AWOL while the last piece of >>data is still in transit). If the pipe leaks, subtle timing changes >>may get your feet wet. I never looked at what PIPEDDR does for flow >>control, but I do recall that I had to master similar things when I >>did mine... > > Perhaps, but it's curious that it works for a full pack MDISK but not for > an attached DASD. > > Could it be a VM service level related issue?? > > q cplevel > z/VM Version 5 Release 4.0, service level 0802 (64-bit) > Generated at 02/19/09 10:50:42 MDT > IPL at 02/28/09 11:15:51 MDT > Ready; T=0.01/0.01 14:22:24 > > netstat > VM TCP/IP Netstat Level 540 TCP/IP Server Name: TCPIP > > > Both sides are at the same level, and yes, the last time my main VM was > IPL'd was over 2 years ago. > > Brian Nielsen > -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
