Before it can govern a QMF session, the DB2 governor needs input. Input in this case is the maximum processor time. The DB2 governor gets this input from a row in a resource limit specification table.. In DB2 terminology, this table is an RLST. Such a table can be modified by anyone with appropriate DB2 authority (INSERT, UPDATE, and so on). By adding rows to one or more RLSTs, you can control the operation of the DB2 governor for your QMF users.
Consider a DB2 subsystem into which QMF is installed. When the subsystem is started, it is associated with a specific RLST. This RLST then provides the DB2 governor input for all the subsystem users, including those who begin QMF sessions.
Different RLSTs can be associated at different times with the same DB2 subsystem. For example, your installation might use different RLSTs for different shifts. The RLST for one shift makes it impossible to use QMF during that shift. Any attempt to start a QMF session ends during QMF initialization, and a message appears in the DSQDEBUG data set.
You (or someone with appropriate DB2 authority) can add rows to an RLST for your QMF users. A row contains:
For example, you might add rows for a few individual users and a row that applies to everyone else. The rows for the individual users contain their primary authorization IDs. The row for the other users contains blanks for the authorization ID.
Contact your DB2 administrator for information about what you can and cannot do with the RLSTs, and the structures of the tables. Each RLST has required columns with prescribed names and data types, but your installation might have added more columns. For general information on these tables, see the DB2 UDB for OS390 Administration Guide .
[ Previous Page | Next Page | Contents | Index ]