The Monitoring of a DB2 batch job results in the "Monitor Dataset Empty" message. Why?

Products

• Mainframe Application Tuner

Issue/Introduction

Short running processes, like some batch jobs, can sometimes finish so quickly that the Monitor does not have a chance to create sampling records. In cases such as these, one will attempt to Analyze the Monitor and will receive a "Monitor Dataset Empty" message.

Environment

Release:
Component: MATUNE

Resolution

Sometimes Monitoring Datasets will display the "Monitor Dataset Empty" message when one attempts to Analyze them.

If you receive that message than you can look in several areas to determine why. Let's use an example of a DB2 batch job.

Look at the DB2 batch job output. How long did it run? Make note of the start time and the end time. Was it's total run time less than one second clock time? Was the total run time less than any delay that you might have specified when you set up the Monitoring Criteria? In this case, the job "ran too quickly". CA Mainframe Application Tuner needs time in the beginning to set up it's storage areas and whatever resources it needs to start it's sampling. If the job runs too quickly, than CA MAT will clean up without creating any sampling records. The Monitor Dataset will still be created, but it will be "empty".

You can verify that the Monitor Dataset was created successfully by looking at the messages generated in the MAT LOG. If you do not see any error messages associated with that invocation of a MAT Monitoring session, then you can continue to believe that the job ran too quickly.

When MAT is saying that "Monitor Dataset Empty", it's not really empty per se. There are records in the dataset, records of various data types. What CA MAT is saying is that there are no record types in the Monitor that match those that would be used to do the "A" analysis.

In a real example, a client was attempting to Monitor a DB2 batch IVP. It started at 15:16:30 and ended at 15:16:30 based on the TYPE=37 sample started record and the TYPE=2 termination record respectively. So it ran in no time at all. We were able to initialize a DB2 packet for DB2 8.1, we requested 8 observations, ended up with an 11 count for observations meaning 3 times the die rescheduled itself because the job was gone. So the job ran in about 120 milli-seconds and there wasn't a TCB anywhere that we could do anything with.