A new function, Database Monitoring, has been added to QMessage Monitor to allow you to monitor specific database activity on files in libraries.
This new feature monitors:
The feature interfaces with QMessage Monitor in the same way as Audit Journal Monitoring in that it sends messages to a special queue (MM/MMDBMON) giving details of database server activity.
As this monitor relies on the File Open exit program, support is restricted to V5R3 and above, and the following libraries are not covered by this monitor, as they are not covered by the aforementioned Exit Program:
As the IFS is not considered part of the database it cannot be monitored using this feature.
Database server client lists allow the user to identify single, or a range of, IP addresses that can be used when setting up Database Server rules.
The following screens show how we can set up a list to identify users within a specific IP address range:
The database server filter maintenance allows the rules, which govern whether or not to log database operations, to be defined.
A good example of this is shown below:
This rule allows the user to log any updates (Add/Update/Delete) to any file in a *PROD library on the production system by any support personnel coming in from the IP addresses 10.1.1.200 to 10.1.1.250 (as defined previously in the client list maintenance).
The MMDBMSET command allows the user to pause/restart database monitoring, either locally, if on a remote system, or for a remote system if running from the central system.
You may indicate whether to pause or resume monitoring on the selected system, by entering *PAUSE, to stop generating messages for database operations, or *RESUME to resume generating messages.
From this command the user may also enter the maximum number of messages to send to the MMDBMONQ message queue before automatically pausing monitoring on the selected system. The recommended value for this is 25000.
CCSS supply two exit programs to assist with the Database Monitoring, namely MM0590B and MM0580B. These programs need to be added as exit programs to the respective exit points as shown below:-
ADDEXITPGM EXITPNT(QIBM_QDB_OPEN) FORMAT(DBOP0100) PGMNBR(1) PGM(MM/MM0590B) REPLACE(*NO)
ADDEXITPGM EXITPNT(QIBM_QZDA_NDB1) FORMAT(ZDAD0100) PGMNBR(1) PGM(MM/MM0580B) REPLACE(*NO)
ADDEXITPGM EXITPNT(QIBM_QZDA_NDB1) FORMAT(ZDAD0200) PGMNBR(1) PGM(MM/MM0580B) REPLACE(*NO)
ADDEXITPGM EXITPNT(QIBM_QZDA_ROI1) FORMAT(ZDAR0100) PGMNBR(1) PGM(MM/MM0580B) REPLACE(*NO)
ADDEXITPGM EXITPNT(QIBM_QZDA_ROI1) FORMAT(ZDAR0200) PGMNBR(1) PGM(MM/MM0580B) REPLACE(*NO)
Tip: To avoid the possibility of this new function monitoring itself, the two new programs will not report on files that exist in the same library as the programs. A useful command is WRKREGINF.
Once the exit programs have been added all the user has to do to start the monitoring is to add message queue MMDBMONQ in library MM to the list of message queues monitored as shown below:
Note: We have used library MMDEMO in this example.
Below you can see an example of the type of message that can be received with this new monitoring. In this example a user has used SQL to select all the records in the PAYROLL file:-
Note: the SQL Statement parameter in the second level text, together with the top three programs in the call stack.
This feature allows you to be able to monitor access to sensitive files at a much more granular level than you were ever able to before.
It is possible to obtain similar information from the Security Audit Journal monitoring, however this feature enables you to be able to pinpoint the exact files/libraries/users/IP addresses that you are interested in (or more importantly, that the auditors are interested in).
Still have questions? We can help. Submit a case to Technical Support.