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. On Wed, Dec 22, 2010 at 6:09 AM, Rod Furey <[email protected]> wrote: >> 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... > > 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. > > Gr., > > Rod > -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
