Start of Content Area

Background documentation Executing a DBA Action  Locate the document in its SAP Library structure

At the scheduled time for a DBA action, an SAP background job starts and executes the action. The action is processed depending on if you wish to have JCL uploaded or the action executed immediately:

Upload JCL

The SAP background job generates a z/OS JCL job based on a z/OS job template. The z/OS job templates are found in the JES Interface (transaction DB2J) and have the creator SAPR3.

This graphic is explained in the accompanying text

Note

If the Job name starts with UTILS: as shown for the last four entries in the picture above, then this is the utility template that will be used for stored procedure execution. Since this is no JCL, only the utility name with valid utility options can be inserted there.

These templates will only come into existence after the first job submission (not upload) in Planning Calendar.

The template is adapted to the customer specific configuration by substituting current values for several parameters. Since this implies profile parameter values, make sure that you maintain all profile parameters with the JES Interface (transaction DB2J), function Customizing  ®  Profile parameter.

This graphic is explained in the accompanying text

Once the JCL job has been generated, it is written to the file

<userid>_<application server>_<system number>_w<work process id>.jcljob01 on the application server:

Linux and UNIX:          /usr/sap/<SID>/SYS/global/JESjoblog/

Windows:                     \usr\sap\<SID>\SYS\global\JESjoblog\

Then, the stored procedure DSNACCDS is used to save the JCL Job as a partitioned data set member on the host. The stored procedure DSNACCDS uses the SAP system user ID (which therefore has to be identical to the TSO user ID) and the TSO password entered with the JES Interface (transaction DB2J) for authentication on the host.

Caution

The name of the partitioned data set (PDS) has to be maintained in JES Interface (which can be found under transaction DB2J ®  Profile parameters ® Upload ® Partitioned dataset for JCL jobs.) Make sure that all possible Stored Procedure Users have UPDATE authority for this PDS.

For each action in the DBA Planning Calendar, you can define a separate job and member name for upload in the JES Interface (transaction DB2J) at Profile parameter ® Upload.

Uploading data sets with stored procedure DSNACCDS can fail with return code 9990 Dataset in use. In this case, someone has the partitioned data set allocated that is the target of the upload. To resolve this problem, you can either organize the release of the data set in question or change the profile parameter Partitioned dataset for JCL jobs in transaction DB2J at Profile parameter ® Upload and restart transaction DB13 subsequently to reload the profile parameters.

Execute Action Immediately

DB2 online utilities are executed via the stored procedures DSNUTILS and DSNACCMO. DSNUTILS is suitable for a single utility execution, DSNACCMO executes utilities on multiple objects in an optimal parallel degree. Note that DSNACCMO utilizes DSNUTILS for the actual execution of the utilities.

Both stored procedures are slightly faster than JCL job submission, because JCL interpretation is no longer needed.

The action log shows the input and output parameters of the stored procedures on the summary page. The screenshots are for DSNACCMO, because for DSNUTILS, the action log is similar and easier to understand.

This graphic is explained in the accompanying text

 

The most interesting field on this screen is the first output parameter of DSNACCMO named Highest return code of DSNUTILS for all utilities. Since DSNACCMO executes DSNUTILS for each input object, this high water mark will tell if there were DSNUTILS executions that failed.

In this example, one DSNUTILS execution failed with return code Hex 0004E000. This is the worst case scenario, because DSNACCMO will stop further execution (contrary to a DSNUTILS return code of 8). That is the reason why the input parameter “Number of input objects to be treated by utilities” has a different number than the output parameter “Number of actual utility executions”.

If you select Output, you will be shown the output of the utility executions.

This graphic is explained in the accompanying text

 

All rows with the same Object ID belong to the same utility execution of the input object with this ID (see the Input objects button). The marked area shows the output of the utility run that has abended.

 

The bigger processes like Backup for all SAP tablespaces produce huge amounts of output that cannot be analyzed easily. If such a job returned with highest condition code 8, you can search in the output for the string CODE=8. If such a job returned with highest condition code Hex0004E000, you should search for the string ABEND. In the latter case, there can additionally be some utilities with condition code 8, so you should search for both strings.

The button Input objects will show which database objects are submitted:

This graphic is explained in the accompanying text

Note the values for Statement ID. They link the object to a utility statement for this execution. The utility statements are shown when you select Utility statements.

This graphic is explained in the accompanying text

End of Content Area