On the other hand, if you are referring to the user being forced as the one who hangs, any condition that hangs it when it is forced will likely hang it in logoff.
I presume that you are using RETRIEVE as the retrieval tool in DISKACNT. If so, use (iirc) SEND CP DISKACNT EXT followed by SEND DISKACNT END to terminate the retrieval process cleanly. Then it can be forced or logged off without the hang. I, as do many others, use a pipeline to retrieve the accounting and erep records. It responds to SMSG commands and can be ended cleanly by a single command. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Wednesday, March 26, 2008 8:20 AM > To: [email protected] > Subject: Re: Logoff vs. Force > > On Wednesday, 03/26/2008 at 10:46 EDT, "Wandschneider, Scott" > <[EMAIL PROTECTED]> wrote: > > Does anybody have a trick on how to LOGOFF disconnected users like > > DISKACNT instead of using FORCE. Sometimes FORCE will > cause a user to > > hang and it requires the forcing user to have class A. I know that > > the FORCE command can be change to another class, but would rather > > stay away from FORCE altogether. > > If I am the SECUSER of DISKACNT, I can use class G SEND CP > DISKACNT LOGOFF. There is also a class C version of SEND > that doesn't require you to be the SECUSER, but giving > someone class C SEND is more dangerous than FORCE. SEND lets > you issue (e.g. Linux) commands in the guest as well as CP > commands. FORCE just gives you the ability to get the user > off the system. In a choice between the two, FORCE is preferred. > > In a previous discussion here, I asked about pairing FORCE > authority with XAUTOLOG authority so that a class G user > could FORCE any user he or she was authorized to XAUTOLOG. > That suggestion was shot down in flames. > > As an alternative I can envision a change to CP to enable ESM > protection of a new class G FORCE command so that you can > control XAUTOLOG and FORCE separately. > > Alan Altmark > z/VM Development > IBM Endicott >
