On Tuesday, 01/25/2011 at 11:46 EST, "Schuh, Richard" <rsc...@visa.com> wrote: > Are you sure about that? Any posted read that is not responded to will get a > disconnected machine forced regardless of whether it is VM or CP read. The > forced disconnect is in response to terminal errors during I/O and is relevant > to this discussion only if a read is posted while disconnected. It is all as > documented, I do believe., and is not a bug. The reason for it is fairly > obvious. If there is no secuser for the machine, someone has to log on to > respond to the read. If nobody logs on, then the read triggers the logoff > force timer. This is nothing new to XA. > > If, whenever you logon, a CP Read is posted, it is because you do not have SET > RUN ON. That CP Read bears no relationship to the logoff timer. That goes back > to the earliest releases of VM and probably beyond to CP40 and CP67. I only > got into VM at the VM370 Release 1 level as a user, Release 2 as a sysprog., > so I cannot speak to the earlier systems.
You can have a CP READ on your console for reasons other than SET RUN OFF, such as - Prompt for AUTOLOG or minidisk password - TRACE is active - Prompt to system operator for ESM failsoft processing The description of DISCONNECT_TIMEOUT is a little vague in that it talks about "forced disconnect". That situation occurs when 1. You get an I/O error on local non-SNA 3270 device (e.g. TEST/NORMAL, chpid pull); 2. You sever a *CCS terminal connection (VTAM, linemode telnet) while it has a virtual machine logged on through it; 3. You terminate a logical device (PVM, TN3270, Yvette) while it has a virtual machine logged on through it; 4. You issue CP FORCE DISCONNECT *and* the victim currently has a console read (VM READ or CP READ) outstanding; 5. A disconnected virtual machine issues an "unresolvable" console read. By that I mean that there is no console input stacked by CP and there is no active secondary user. All of these conditions cause an I/O error to be returned to CP's terminal driver. The first 3 cases result in a 'forced disconnect' message, e.g. GRAF L0003 DISCONNECT MAINT USERS = 10 FORCED BY SYSTEM Case 4 gives you GRAF L0003 DISCONNECT MAINT USERS = 10 FORCED BY ALAN In all cases, the user is disconnected and the countdown to oblivion (DISCONNECT_TIMER) begins. SET RUN OFF/ON is a bit of a red herring. It affects what happens when you issue a CP command while you are in CP READ. With RUN ON, an implicit BEGIN is done. With RUN OFF, you remain in CP READ and the virtual processors are not dispatched. If the CP READ is "unresolvable" per the above, then the timer starts. And I personally think the CP READ v. VM READ issue is a bug. Until the introduction of class C SEND (no SECUSER), there was no hope to answer the VM READ, and so making it a CP READ didn't hurt. Now it does. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
