Would PIPSTOP cancel the SFS command (or any CP/CMS command for that matter)? If so then you could use PIPSTOP to end the pipeline. Just a theory, not tested in any way...
'PIPE (end \) command LISTDIR ...', /* execute command */ '| stem', /* store */ '\ literal +60', /* 60 seconds */ '| delay', /* wait for it */ '| pipstop' /* cancel command */ Regards, Berry. Op 24-12-10 01:09, Alan Ackerman schreef: > Moving this question from CMS-PIPELINES to IBMVM, since I am assured by > John Hartmann that it cannot be done with CMS Pipelines. Anyone figured > out how to get it to time out? > > Sender: CMSTSO Pipelines Discussion List <CMS- > pipeli...@vm.marist.edu> > From: "Ackerman, Alan" <alan.acker...@bankofamerica.com> > Subject: Time out a CMS command > > Is there a PIPELINE idiom to force a CMS command to timeout after a > certain length of time? > > I am issuing: > > 'PIPE command LISTDIR SFSLNB00:SFSADMIN.GETSMTP | stem emsg.' > > Occasionally (about once a week), this hangs for a long time (18 hours > the last time) and then returns with RC = 55. > > I can live with RC=55, but not with my virtual machine being tied up for > 18 hours. (There are other VMSCHED jobs it should be running.) > > From: "Schuh, Richard" <rsc...@visa.com> > Subject: Re: Time out a CMS command > > Look at the beat stage. It may work for this problem. > > From: "John P. Hartmann" <jphartm...@gmail.com> > Subject: Re: Time out a CMS command > > The pipeline is dead in the water while the CMS command is executing; > no way it can force a timeout. If you have two virtual machines to > play with, the situation is different. Then you can send the command > and wait for a response with STARMSG and send HX when it times out. > Whether CMS reacts to the HX is another matter. > > From: Rob van der Heij <rvdh...@gmail.com> > Subject: Re: Time out a CMS command > > Some SFS commands have the ability to hang forever and prevent any > recovery. I recall we did some check right before these, just to make > sure the remote file pool is actually alive. But I don't remember > which check it was, maybe Bruce or Rod can fill in the blanks... > > From: "Ackerman, Alan" <alan.acker...@bankofamerica.com> > Subject: Re: Time out a CMS command > > I suppose I can just CP FORCE the hung userid. I'm not sure what state > that would leave SFS in, though. > > Date: Tue, 21 Dec 2010 20:16:34 -0500 > From: Rich Greenberg <ric...@panix.com> > Subject: Re: Time out a CMS command > > If you don't find a fix, instead of running it from VMSCHED, have > VMSCHED autolog another service machine for the actual LISTDIR. It > wouldn't be a problem if the extra SVM gets hung. > > Date: Wed, 22 Dec 2010 12:09:49 +0100 > From: Rod Furey <bent...@gmail.com> > Subject: Re: Time out a CMS command > > Methinks Holger did it this way: > > start up a thread or two via multitasking CMS > set up a timer on one thread > set up the access (or whatever) on the other thread > if the access completes before the time ticks, kill the timer thread > if the timer thread ticks before the access completes, kill the access > thread > > Don't ask me about the ramifications of doing this and what happens > about cleanup. Multitasking CMS was never an area I hit before I went > in search of other work. > > I do recall that the dev group did discover some problems in the mtCMS > area at the time. > I would hope that they've been fixed by now. > > Date: Wed, 22 Dec 2010 08:07:34 -0500 > From: Bruce Hayden <bjhay...@gmail.com> > Subject: Re: Time out a CMS command > > I haven't looked at this in years! But, looking at the code, you have > it essentially correct. The only sticky part is that the code doesn't > attempt to do an access, but tries to simulate some kind of SFS > communication via APPC, which I'm sure is not a documented interface > (it is coded in the exec as a long hex string.) > > Anyway, the best approach for the rest of us to this problem would be > to use 2 userids, as was already suggested. I doubt it would have any > affect on SFS. If this happened to my own id, I just enter #CP IPL > CMS to cancel the APPC wait and recover and there was never a problem > in SFS after the communication was fixed or reset. > > >
