It may become necessary to terminate a user’s session if it becomes unstable, by deleting the row identifying that session from the Session table. For example, if a transaction abends in your session, because your session settings are saved by tablesONLINE/CICS, your session will abend again when you log into it. When the row identifying the session is deleted from the Session table, that user is returned to the application’s first screen when he/she signs on.
The functions that may be performed on the Session table are limited. You may browse the table to see what sessions are running and delete any of those sessions. It is possible to open a row in the Edit Row screen (see Figure 52) to view the help available for each field but no changes may be made to any of the fields in this screen. New sessions cannot be created using this table, only the tablesONLINE/CICS signon process can create sessions on this table. There is no mechanism for changing the user ID for a running session.
To access the Sessions table, select option 2, Delete sessions, from the Administrator menu, as shown in Figure 32. The system displays the Browse/Delete Active Users screen, as shown in Figure 53.
The Data Table library, View library, and Table Object on this screen are protected fields. If you wish to move to a particular row in the session table, enter the application ID of the user, either alone, or together with a user ID. This displays the Edit Table screen with the specified row displayed at the top of the screen. If no application ID or user ID is specified, the Session table is displayed with the first table row appearing at the top of the display.
The only operations that may be performed on this table are single row and block deletes. In the example in Figure 54, the session for USER3 is deleted.
As a safety precaution, error-checking code within tablesONLINE/CICS prevents the tableBASE system administrator from deleting his own session and will generate a message if this is attempted. In the example above, USER3 receives a message that the session has been terminated and he should speak to the tablesONLINE/CICS administrator. Following session termination, the user will be in native CICS.
If USER3 was in a menu or browsing a table at termination, all of the tablesONLINE/CICS resources are de-allocated cleanly. If they were editing a table, however, it may have been left in an open state.
To close a table that has been left open, use TBDRIVC. Set the eight character lock with the >L (Data to Lock) command so tableBASE thinks you are USER3. This requires a 19-character hex string on line one, as shown in Figure 55.
Alternatively, the lock may be set using the Master Password. For more information, see Master Password Feature. With the lock set, use the CL command on the appropriate table.