AFX_MONITOR: Archiving Monitor

Share this article :



Short Text

Archiving Monitor


Monitoring and Logging Archiving Runs


The archiving monitor can display information that the archiving subprocesses (analysis, write, delete, reload and pre-step) write in the application log and the activity log.

This means you can use the monitor to monitor current archiving processes and to view their progress.

You also have the option of interrupting archiving processes that are running, in a controlled manner.


API module APPL_LOG_DISPLAY is used to depict the application log.

The lists in the activity log are depicted by the ALV Grid Display and the ALV List Display.

To depict the job overview, API modules BP_JOB_SELECT and BP_JOB_MANAGEMENT are used.


The user has read access authorization for all archiving objects.

One of the following must be running or have run: An archiving run (analysis, write, delete), reload or pre-step. The application and activity logs are being or have been filled in during the process.


The archiving monitor displays information that is logged during an archiving run. This includes the following:

• Activity log
• Application log
• Job list
• Archiving runs and archive files
• Package list

An external identification is also included in the activity log. This identification is used to group together the logs from related archiving subprocesses (analysis, write and delete). Archiving runs become related if, for example, the analysis run starts the subsequent write job or the write job starts its delete job. These run variants are dependent on the global control of archiving and the AOBJ basic settings, and are maintained there.

Since archiving runs and pre-steps are generally long-running processes, the archiving monitor has a refresh button on the display list for the activity log and the package list. When you press these buttons, the current status or package information is read from the database again and displayed immediately.

The activity log records the status of the archiving runs. The statuses are explained below:

• 0: The program/archiving run has been started.

• 10:The parallel processing for the archiving run has been started. This status indicates the start of the preliminary phase of parallel processing.

• 20: The “Generate Package Templates” phase has been completed in parallel processing and the mass run started immediately afterwards. The parallel mass runs themselves cannot update a status since the connection between the mass run and the activity log is not specified clearly in this phase. You can view the progress of the parallel mass runs in the package list.

• 30: The “Mass Run” phase has been completed within parallel processing. The point of synchronization has been reached. If the archiving run is not related to any subsequent runs, this status indicates a successful end to the run.

• 31: This status can only be given to an analysis run. It indicates that the subsequent write job has been started automatically and that the analysis run has been completed successfully.

• 32: This status can only be given to a write run. It indicates that one or more subsequent delete jobs have been started automatically and that the write run has been completed successfully.

• 40: This status indicates that parallel processing has been terminated. To analyze the errors, you can use the application log and the corresponding job logs from the job overview.

• 50: The program has been completed successfully.

During the “Generate Package Templates” phase, the system writes a status entry in the database for each generated package at the start of the parallel processing. The packages therefore initially have the status “Planned”. During the actual mass runs, individual packages are processed by the package administrators and have the status “In Processing”. The number of data records processed from the master application table continues to be updated at regular intervals. When a package is completed successfully, the status is set to “Completed”.


The selection screen is divided into three areas:

• Identification
Here you can make a selection using the activity ID. The external identification enables you to select related archiving runs.

• Object
You can use the object name to restrict the selection of an archiving object. Other options include specifying the program name and category or the application type. However, the application type is only useful for parallel processes such as the analysis or write run.

• Restrictions
In this area, you can restrict the selection by entering the user or the date and time of an archiving run. Today’s date is set as default for the date. You can make other restrictions for the archiving mode (test, simulation, productive) and the archiving run status.


The first basic list contains the data from the activity log. This includes:

• The date and time of the archiving run
• The external identification connecting the related archiving runs
• The program name of the archiving process
• The program category to identify the archiving process (pre-step, analysis, write, delete, reload or interrupt)
• The archiving object processed by the archiving run
• The application type from parallel processing
• The archiving mode (test, simulation, productive)
• The user who started the archiving run
• The status of the archiving run. For processes that are running, this is the current status. For processes that have been completed, this is the final status.
• The message object and the date of the application log. The date determines as of when the application log can be deleted by reorganization runs.

You can use the refresh button to read the current log entries from the database. This means you can monitor an archiving process continuously.


You can branch from the basic list to other list displays via the Goto menu option by selecting an activity log entry. These are as follows:

• Application log
Here you can branch to transaction Evaluate Application Log (SLG1).

• Job list
The job overview displays all the jobs belonging to an archiving run or to related runs. Here you are given the other standard functions of transaction Job Overview (SM37), such as displaying the spool or the job log.

• Archiving runs / files
This lists the files generated by the parallel jobs during a write run, along with their higher-level archiving run assignments. This shows which archiving run or group of related archiving runs has generated which files.

• Package list
Here you can display the information that the parallel jobs write in the database for each package during the mass run. The status is logged here (Planned, In Processing and Completed), as is the number of data records processed per package, the name of the job, the duration of the job and the limits used for the database selection. If you press the refresh button, you can read the current package list from the database, allowing you to monitor the progress of the package continuously.

• Interruption
An archiving process that is running can be terminated in a controlled manner. If this is done, all parallel jobs are terminated and the archiving runs generated concluded. The interruption of archiving processes is recorded in the application log.

• Archive administration
Here you can branch to transaction Archive Administration (SARA).

• Sequential read program
You can use this menu option to branch to the sequential read programs stored for the selected archiving object in the basic settings (AOBJ). If more than one read program is maintained there, you must first choose the program you want from a selection box. The archive files belonging to the archiving run are transferred to the read program immediately, meaning you do not have to make any other upstream selections.

Related posts

RSPARAGENER8: Parallel Processing of the Generation of ABAP Loads
RSGENINVLAS: Automatic Regeneration of Invalidated Loads
ADMIN SET START TRANSACTION FO: Set Start Transaction for User
BTCAUX04: Identify Periodic Jobs Scheduled More Than Once in SAP
© 2017 ITsiti. All Rights Reserved
Powered by KEEM