Troubleshooting in System Administration SAP BASIS

When managing a SAP R/3 Enterprise system from a technical point of view, there are quite a few areas that need to be controlled and monitored on a regular basis in order to procure a healthy environment. Availability of resources, stability and performance of the available resources are aspects to look at. In the following topics, we will touch base on troubleshooting techniques in general system administration of SAP systems.

Troubleshooting the Update Process

The update work processes are in charge of recording changes in transactional data and send requests to the database of such changes, as users work normally in the system. The update work processes perform their functions when the ABAP applications are programmed with a statement IN UPDATE TASK. This type of updating is performed asynchronously in the system, meaning that the programs leave update records in a queue to be processed and then continue the execution. Even though the updating processes run without management intervention; nonetheless, SAP includes utilities to monitor, check, and perform management operations on the updating process, which can be very useful in case that problems arise.

To access the Update Monitor, follow the menu path Tools | Administration | Monitor | Update. Alternatively, enter transaction code SM13 in the command field. The system displays the initial Update Monitor screen, where you can select to display data according to your selection criteria. It is normal practice to check this monitor on a daily basis, though you can select a time period that includes data and time to filter.

Initial selection screen in the Update Monitor

Initial selection screen in the Update Monitor

You can select to display the type of update records of your choice, by client and user, although you can enter a wildcard (*) to select all clients and all users as well. When you click on Execute, you will display a list with the records you selected and their status, as well as the user and transaction executed. From there, it is possible to retrieve user information and repeat updates, unless there is an error and the system will display so. In such case, the user needs to post the transaction from the beginning to avoid inconsistencies.

The Update Process Administration

You may access the Update Process Administration utility by executing transaction SM14 or from the Update Monitor clicking on Administration. This tool allows you to manage more complicated features in the Update process.You can display all canceled update records, all update requests, reorganize incomplete update requests and deactivate the update process. Only when troubleshooting the update process and it rare cases you will need to deactivate the update process (if there is a stuck situation, for example).

However, it is best practice to reorganize incomplete update records, because they take space in the database (you will see table VBDATA growing). There is another way to perform this reorganization automatically, which consists on setting the parameter rdisp/vbreorg to 1, which mandates the update server to reorganize incomplete update records when the instance is restarted. This also helps you to avoid inconsistencies, because you would not be reorganizing update requests during online hours.

The tabs Update Server and Server Groups in this tool help you to define update servers and server groups for load balancing. In addition, the Parameter tab allows you to define certain parameter settings dynamically and to display all parameter settings related to the update process to function properly. Finally, click on Statistics to obtain very specific statistics on response time broken down by actions in the database by the update process, such as Delete, Insert, and Commit. Be sure to understand clearly how the updating process can affect the system before performing any management options on update records. More information on update process management can also be found in the Online Help.

Troubleshooting Lock Entries

Lock entries are system objects in charge of protecting the integrity of the data by synchronizing the access, so users cannot modify the same data at the same time. The lock objects are defined in the ABAP dictionary as a mechanism to lock data and can consist on a table, a row, or even a whole transaction, so users cannot change the same data at the same time. To display and perform some basic operations on lock entries, from the main menu, select Tools | Administration | Monitor | Lock Entries or execute transaction code SM12.

You can select lock entries specifying client, user or objects that have been locked (lock entry arguments). By entering the wildcard (*) in the client and user, the system displays all current lock entries with the users holding locks and what table is affected by the lock. Frequent monitoring of lock entries should be a common practice by either SAP R/3 administrators or operators, since unrelcased locks can block other users from working in the same transactions for updating information.

Normally, Jocks are automatically released when transactions are committed or when users are finished working on the data. Special attention must be given to locks, which are held unreleased for several hours. Although this is not always a cause of alert, because in special circumstances, such as long-running background jobs which update the database, it can be a completely normal operation. The lock monitoring functions offer the utility to manually delete unreleased locks. To manually delete a lock entry from the lock entry list, click on the line holding the lock you want to release and press delete from the application toolbar or select Lock Entry | Delete from the menu.
However, you should not delete locks directly before analyzing the reason for the lock.

As much as possible try to avoid manually deleting lock entries, and do it only when you are sure that it will not affect an update process, a background job, or an active user. Otherwise, it might lead to data inconsistencies.
Some of the most frequent reasons for unreleased locks are as follows:

  • Abnormal termination of the SAP GUI. If users shut down their PCs without logging off SAP, or if the SAP GUI terminates for other reasons, such as network or communication problems, the user session may remain active in the SAP system. If this happens while the user had lock entries, sometimes these locks remain unreleased since the user is no longer active in the system, and therefore they cannot be automatically released, In these cases you can manually release the lock either by deleting it from the lock entry list, or you can force log off the user from the User Overview Monitor executing transaction SM04 in the application server where the user was logged on. This information can be found in the lock entry details window.
  • Inactive SAP GUI. Another common reason for holding a lock for a long period of time is when users currently working on the system leave their presentation services with unfinished transactions. Before manually deleting a lock entry that is preventing other users from working in the same tasks, try to locate and directly check with the user. Otherwise, you should either manually log off the user or delete the lock if this is seriously preventing other users' work. However, make sure the lock is not coming from an important background job.
  • Problems in update processing. When there are update modules that are unprocessed by the system, these modules do not release the locks. The update process only releases the locks when either the update records have been completely processed or they have abnormally terminated with an error status.

Only update modules with status INIT or AUTO (unprocessed updates) can holdlocks. Normally, the lock entry list will highlight those entries that are held by update processes. If you press the Refresh button often on the lock entry list, you can sometimes see highlighted entries, which are released very quickly.

The System Log

SAP systems includes extensive log facilities to display and possibly correct the problems and errors occurred during system operation in the so-called system log. Each application server registers a local system log. In a distributed environment, you can configure a central system log that collects the log records of all servers, but this is not available in all operating systems. Physically, the individual application server log files (local system logs) are stored under the specific instance directory /usr/sap/<SID>/<INSTANCE_NAME>/log, with the name SLOG<INSTANCE_NUMBER>.

The log messages are written in a single circular file. When the file reaches the maximum allowable size, a log switch takes place and the system starts overwriting the file from the beginning. The maximum allowed size of a log file is specified in the system profile parameter rslg/max_diskspace/local. However, when the central system log is configured, it uses two files: an active file and an old file. The active file contains the current log. When the active file reaches the maximum length specified in the system profile parameter rslg/max_diskspace/central, the system performs a log switch.

The system deletes the old log file, copies the active file as the old log file and creates a new active log file. This process is performed transparently to the administrator and does not offer any notification when it replaces the old log. The central system log is located under the SAP-shared global directory /usr/sap/<SID>/SYS/global with the default name SLOGJ.To access the System Log from the main menu, select Tools | Administration | Monitor | System Log or execute transaction SM21.

The selection criteria to filter the display of the system log messages includes date and time, user ID, transaction code, type of work process and type of problems logged. It is important to remember that the system log records events, problems and warnings that are relevant to the kernel (work processes and such), therefore, not certain problems, such as database or operating system problems will be recorded (but if these affect the kernel, they may be recorded).

By entering DP in the SAP Process field, you will filter messages logged by the dispatcher processes. If you enter D<n> or B<n> or S<n> or V<n>, where n is the work process number, you will filler by dialog, background, spool or update work process number as displayed by the Work Process Overview screen; For example, D1, D2, and so forth. Choose MS to select messages from the message server. By selecting from the menu System Log | Choose | Central Log, you can display the central log. Other options in the same menu allow you to select the remote and local system logs. The field Instance Name appears only when you select to display the central system log where it is located.

You may also choose a maximum number of pages you want to see in the log report. No. Pages for Individual Entries and select the check box With Statistics to show statistical information of the log analysis, such as message frequency by client, user, and transaction. In order to dump the output somewhere, you can select Settings next to the Output To pushbutton. The default is the screen output and you can select other outputs, such as a printer with a certain number of pages to print. Other settings allow you to change the layout of the output (selecting additional columns in the log, for example).

Main selection screen in the system log

Main selection screen in the system log

Interpreting the System Log

The system log records all alerts sent to the kernel. Therefore, warnings and information and not only errors are also recorded. It is important to check the system log on a regular basis and to interpret the messages accurately. The column named "MNo" in the log report shows the log message codes, which are associated with a type of log event. Most of these codes have associated documentation explaining the cause of the log and, in case of errors, the possible cause of the error. To see this information, first double-click on a log entry to display the detail screen. In this screen, you can see the documentation for message codes. You can also display the short text documentation for the message code, by selecting See System Log Doc from the application toolbar. There is not always log documentation available.

You can also instruct the system to ignore certain codes by selecting Edit | Ignore Message from the menu. When you perform this function, the next time you request the log report, the system will not display messages with the ignored code. Events when a work process switches from one type to another when switching operation modes are recorded as warnings and are purely informational, unless something went wrong, which would be recorded, if so.

The best documentation for system log messages is contained in SAP Notes and a simple search with the error code and a short text will very likely retrieve a solution that suits the symptoms recorded in the system log.Pay special attention to system log messages related to operating system failures, database errors or inconsistencies, as well as printing problems that may affect users seriously.

Displaying and Troubleshooting ABAP Short Dumps

When serious program errors occur, the ABAP processor terminates the current program and the development workbench generates a so-called short dump that is presented to a user executing a program, as the program aborts without finishing successfully. An ABAP dump is a list that includes extensive information about the possible causes of the error and the guidelines to solve it. It is best practice to check your system for dumps on a regular basis, even if online users are not experiencing program terminations, since they may be due to background activity and RFC calls as well. System administrators, development personnel, or SAP specialists may access the Dump Analysis transaction ST22 or follow the menu path Tools | Administration | Monitor | Dump Analysis.

ABAP Dump Analysis in a SAP R/3 system

ABAP Dump Analysis in a SAP R/3 system

When displaying ABAP dumps, you can select the current day's dumps, or the previous day's dumps or even select a period of time. Other criteria to filter allow you to select a particular application server, a user and a dump identifier. In addition, new features allow you to filter by program name and dump exception. In addition, if you do not wish to use this type of screen or output and you are used to the look and feel of the dump analysis in previous releases, you may check the box Use Old Dump Analysis to analyze dumps in the old monitor.

When analyzing an ABAP dump, check the information provided in the dump, and you can also display the code that was being executed when the error was raised. Some of the information to be found is as follows:

  • What happened and why the program was aborted
  • What program and what line in the code where the error occurred
  • What error message keywords are useful to search for possible solutions
  • The values of the most relevant system variables are at the time of the error
  • What tables were being used at the moment
  • Management data such as user, transaction, application server, and so on
  • Whether any other programs were affected

Old dumps occupy space in the database. It is best practice to delete these entries on a regular basis by scheduling a clean up job or manually by choosing Goto | Reorganize from the main dump analysis screen and selecting how old the dumps to be deleted must be. However, you may keep dumps for further analysis. In the main selection screen you can choose to keep dumps by entering an X in the analysis list display, you can select whether there are any particular short dumps you want to keep for further analysis. Or, in the list of dumps that you selected, select the short dump to keep and click on the Keep/Release padlock-like icon or, from the menu, select Short Dump | Keep/Release.

Pay special attention to those dumps that are related to errors in the database (such as DBIF_RSQL_SQL_ERROR). Search for SAP Notes that explain the symptoms, because they will very likely contain a fix and an explanation for such dump. In addition, watch dumps related to memory management, such as SYSTEM_NO_ROLL, SYSTEM _NO _MORE _PAGING, TSV _TNEW _PAGE_ALLOC, and others. These may be due to a couple of things, either wrong parameter settings in memory management, or insufficient resources, or that the programs that dumped were too resource demanding and in regular operation they need more memory than other programs and they might need to be checked by developers for tuning potential. Sometimes, the user input in selection screens is also important and without filtering properly, they may launch a program than needs a large amount of resources and the program dumps due to insufficient resources at that time.

The System Tracing Utilities

Besides the system log and the ABAP short dumps, the R/3 system includes many facilities to debug, follow, and keep track—in other words, trace—its internal operations. The information provided by the different tracing functions is highly technical and it is primarily used for solving problems in the system or trying to optimize the performance and/or the coding of the ABAP programs. The basic tracing utilities available are

  • System traces
  • Developer traces generated by the SAP processes
  • SQL traces for analyzing the database accesses
  • ABAP program traces

This section covers the basic handling and configuration of the system traces and developer traces. Both the SQL traces and ABAP program traces are mainly used by developers and are explained in previous sections.

Using the System Trace

The system trace functions can be set up to include a very extensive group of technical information which can later be used by expert administrators, developers, or SAP specialists to solve or tune specific system problems. This section covers how to configure and set up system traces, which is not an obvious matter by navigating through the menus. Each process in a SAP instance has its own trace buffer, where it writes the tracing information before being transferred to disk, if this option is selected. Call the System trace function by selecting Tools | Administration | Monitor | Traces | System Trace from the main menu. Alternatively, enter transaction code ST01 in the command field.

Starting the system trace and options for tracing

Starting the system trace and options for tracing

Select the trace records that you want to keep track of, such as authorization checks, kernel functions, database access, table buffer trace, RFC calls, and lock operations by checking the check box next to each option. Additionally, by clicking on General Filters, you may restrict the trace to a process only by entering the work process number, for a user, transaction or program. Otherwise, without specifying this data, when you activate the system trace, you will trace everything that happens in the system.

Therefore, it is important to understand that this tool is only to be used when errors occur and it is mainly used by kernel specialists. The name of the trace file in a system is defined in the profile parameter rstr/ filename.
The default value of this profile parameter is / usr/ sap/ <SID>/ <instance name>/ log/T RACE00. Its size can be configured with the parameter rstr/ max _filesize _MB. When a file is full, it is renamed with a different ending, a number from 00 to 99 and the maximum number of files is defined by rstr/max_files.

Using Developer Traces
The system developer traces are log files that contain technical information about the SAP work processes and other programs. They are normally used by specialized personnel, especially by SAP support, when looking for problems in the SAP kernel or the runtime programs. These traces can be useful also for administrators, since some of the files sometimes contain the explicit reason and explanation for system errors. To display the list of developer traces, from the monitoring menu, select Tools | Administration | Monitor | Traces | Developer Trace from the main menu or execute transaction code ST11.

The system will display a list with the title Error Log Files. These files are actually operating system files located under the Work and Profile directories. To display the contents of any file, just double-click on them, or select Log File | Display from the menu.

The developer traces

The developer traces

When you display any of the files, look for lines beginning with the string *** ERROR => message, because they contain error information. The error lines can be useful for displaying what functions and what operations caused the error message. If any of the entries are also writing system log entries, then the line begins with ***LOG <message ID>.

The names of all the developer trace files start with the character string dev_followed by an identifier, such as the work process number, or rfc in case of an RFC call, icm for Internet Communication Manager, ms for the Message Server, and so on. You can set the trace level by setting the parameter rdisp/TRACE=<n> in the instance profile file to any of these values:

  • TRACE = 0. No trace is written to files.
  • TRACE = 1. Write error messages in the trace file.
  • TRACE = 2. Write the full trace.
  • TRACE = 3. Write the full trace including data blocks.

Troubleshooting the Background Processing System

There are several options in the SAP system for monitoring and troubleshooting the background processing system. These options include utilities that can be used from the general administration monitoring utilities to extensive CCMS analysis tools. Where to look and what functions to use depends very much on the type of errors, which can range from configuration problems to authorizations or runtime problems. In general, the order to look for background job problems can be

  • Displaying the job log and analyzing the job status
  • Analyzing the background work processes and the system log
  • Using the CCMS general analysis tools
  • Displaying the Job Log and Analysing the Job Status

To display a job log and analyse its status, you must access the job overview list from a previous job selection screen. This screen may be accessed from many different places in the SAP system. For example, directly by entering the SM37 transaction code in the command field or by selecting Tools | CCMS | Jobs | Maintenance from the main menu. Enter the criteria for restricting the jobs to analyze and then display the job or list of jobs.The first operation on a selected job will be to sec its status and check it for possible errors by using the Job | Check Status function. If the job status is OK, the system displays a message in the status bar.

If you suspect an active job is running for a longer time than normal, you can debug it for analysis by selecting it while running and then choosing Job | Capture Active Job. The system will display a debugging window where you can analyze the code of the ABAP program running in background. The running program stops and you can debug it. Re extremely careful doing this and try to avoid as much as possible to debug in a production environment. Tests of this caliber should only be done in copies of production or test systems, where the code of the program is the same and the data that it works with is similar to that in production. Prom the debugging window, you can continue to execute the job at the point it was stopped.

Analyzing the Background Work Processes

Another step in the analysis of problems with the background processing system is to display the general process overview monitor. From the main menu, select Tools | Administration | Monitor | System Monitoring | Process Overview or just execute SM50 in the instance where the job is running or SM66 to see a global view. The two types of work processes to look for are the background work processes and the dialog work processes. The Type column shows the type of work processes: BGD for background (batch) and DIA for dialog. And the Status column displays whether these processes are running, waiting, and so on.

The first column of the process overview ("No.") shows the number of the work process. This number can be very useful if you later want to analyze the system log and want to restrict the search to problems with that particular work process. The process monitor shows other interesting information such as the program it is executing at the moment, the user under which the job is running, and so forth. Selecting one of those processes, you can get further detailed information by choosing Process | Details from the menu. You can also display the developer trace file by selecting Process Trace | Display File. This will allow you to search for errors in the kernel, what happened while this background work process was executing the job, and so on.

With the system log, you can also analyze system errors, messages, or warnings regarding the background processing system. You can restrict your search just to the background work processes by entering the number in the SAP process input field.

The Job Analysis Tools

There is a set of utilities that can be used to analyze and monitor the background processing system. The utility Check Environment is used for analyzing the configuration and the status of thebackgroundenvimnment. To reach this function, select Tools | CCMS | Jobs | Check Environment or execute transaction SM65. An example of the initial screen for performing simple tests on the background system.

Checking the environment in background processing

Checking the environment in background processing

These utilities check all the necessary conditions that must be met for the background processing system to work correctly. This analysis utility is helpful in determining if all the elements of the background system are configured and if there is any missing parameter. The analysis tools include two types of tests:

  • Simple tests. These tests are used by the system to check if the profile parameters are correctly set and if the SAPCPIC user exists, because it is needed for starting external programs. These tests can be performed on a single background server or on all of them. To launch this test, from the initial screen click on the Execute button after selecting the background server of your choice or selecting of All Background Servers.
  • Additional tests. These tests perform more extensive tests on the background processing system such as authorizations, consistency of the database tables and the TemSe database, status of background servers, and whether the dispatcher of a SAP instance has any entries in the queue for background processing. To reach these expert mode functions, from the initial screen select Goto | Additional Tests.

Additional expert tests in background processing

Additional expert tests in background processing

Job information is stored internally using several R/3 tables. With these additional tests, the system can find if there are any consistency problems in those tables, such as a missing index, duplicate entries, existence of all job data, and so forth. The results of the tests can either be displayed as a list or written to the file BTCSPY in the working directory of the application server to which you are logged on. The utility Background Objects allows you to display and maintain the elements or control objects that make up the runtime environment for processing jobs. To reach this function, select Tools | CCMS | Jobs | Background Objects or execute transaction SM61. These objects are as follows:

  • Time-driven scheduler. This is the component of the background system responsible for starting jobs that have a start date and time specified. This scheduler is also responsible for starting jobs defined with a scheduled start option, such as After Event, After Job, and At Operation Mode, which could not be started at their scheduled time for some reason, for example, because there were no free background work processes. The scheduler is started by the SAP dispatcher in the period indicated by the rdisp/bdctime instance profile parameter. It is started in a dialog work process. For this reason, it is important that every instance configured for background processing must have at least one dialog work process for this task.
  • Event-driven scheduler. When the R/3 system receives any events, this scheduler is in charge of checking in the background system for any jobs that must be started after that event. If there are jobs waiting for the event, this scheduler starts them. The event-driven scheduler also runs in a free dialog work process of any server.
  • Job starter. The job started is another component of the background system in charge of starting the jobs and performing some preparatory functions for the job such as reading the needed data from the tables and starting the job steps. This object runs in a background work process.
  • Switch operation modes. This object is used to initiate the switch of operation modes in a dialog work process. This component is triggered by the time-driven scheduler, which uses an internal timetable to check if an operation mode has to take place.
  • Starter for external programs. This background object is the component that allows external programs to be started as part of a job step. An external program is started from the background work process in which the job is running.
  • Zombie cleanup. This background object is in charge of checking whether there are jobs with the wrong status after a system restart. For example, after a power down and restart of an application server, no jobs should have a ready or active status with an initial start time previous to the restart. The zombie cleanup sets the status of those jobs to either finished or canceled.

Every background control object can be maintained separately. The maintenance consists of either defining and activating any of the objects or activating the trace information for them. On the initial screen for background objects, select Maintain Objects. The left column shows an entry for each host and the right column an entry for the object. From this screen, you can create an object by clicking on the Create icon, or you can modify the control information of the object. To modify an object, select the object and click on the Change icon. The system will display a dialog box where you can activate or deactivate the object itself or activate and deactivate tracing for analysis.

Finally, with the Activity Log button, you can display when the job was last run and when the trace was last activated.

Analyzing Job Performance

Select Tools | CCMS | Jobs | Performance Analysis or execute transaction SM39 (this transaction has been replaced by SM37 with SAP Enterprise) to reach the Performance analysis tools. Here system administrators can analyze the runtime of jobs that are active, finished, or canceled. To look for additional information about a particular job, just double-click on it. It is important for everyone involved in the maintenance and care of a SAP system, as well as for everyone involved in an implementation, that jobs are analyzed for performance.

It is best practice for developers that create background jobs to execute ABAP programs to fulfill a business requirement to look at the Duration column while testing the execution of such jobs, not only the Status column. Especially when tables grow and the system ages, or when additional workload hits the system, the designed jobs are likely to have a longer runtime than before. Think of jobs like Payroll or financial reporting transactions and programs.

Developers can use the trace utilities SQL Trace and ABAP Trace. However, tracing a background job can be more complicate and tedious than an online transaction, due to its forecasted longer duration. To trace a background job with the SQL trace utility (transaction ST05), try to start and stop the trace recording "chunks" of the job, save them to a local file and analyze them individually later on. This way, you can try to avoid the trace filling up and overwriting the records that were previously recorded.

To perform an ABAP trace in a background job that is currently running in the system, execute transaction SE30 and choose Enable/Disable under In Parallel Session. This will take you to a list of work processes similar to the one of the Work Process Overview monitor. In this screen, choose Start Measurement by clicking on the matchlike icon or choose Edit| Measurement | Switch On from the menu.

Under the On column you will be able to see a symbol, first as a yellow triangle that changes to a green circle to indicate that the trace is on and the background work process is active executing a job. You can refresh the display from this screen continuously and monitor the job from the job overview monitor in SM37. This will not affect the trace. After the job is finished, simply deactivate the trace by selecting Edit | Measurement | Switch Off from the menu or by clicking in the extinguished matchlike icon.

Afterward, go back once with the green arrow to the main SE30 screen and choose Analyze to check the file that was created. As explained in the section on workload analysis, you can proceed to analyze where most of the time was spent while this job was running, the SAP system or the database. Therefore, you can proceed to analyze further the most expensive programs and the database for possible tuning actions.

Common Background Job Problems

The following list summarizes some of the typical problems that can be found in the background processing system and the check actions to perform to solve the problem. As a common practice for all of the typical problems, display the job log, the system log, and finally use the job analysis tool.

  • Job was not started. First, check the job start time definition and ensure it has a start date and that the user who defined the job has authorization to release it. If the start date has been reached, check that there are free work processes in the background servers, especially if a target host was specified. If the job was to be started after an event, define a dummy job to test the event. If there are problems with the sapevt program, check the background objects and enable a trace for the event-driven scheduler.
  • Cannot display the job log. This can indicate that the job log could not be created in the application server because of wrong permissions, the global directory is not correctly mounted on the application server where you tried to look at the job log, or there are inconsistencies in the TemSe database.
  • Job has been canceled. Jobs can be canceled for many different reasons. The first step in analyzing canceled jobs is to display the job log to see if there are any error messages. Choose Job Log from the pushbuttons. If the message text is not enough, sometimes it helps to select from the menu, Goto | Long Text. Common problems are related to runtime errors of the ABAP processors (the program aborted in an ABAP dump that you can analyze separately), authorization permissions (check the job utilities for permissions, check the authorizations of the user executing the job, etc), inaccessible operating system files when the programs read or write to external systems (check that the files and external programs are available!), and so forth.
  • An external program cannot be started or canceled. Normally, the user <SID>adm is the operating system user with authorization to run external commands and programs. Ensure that the external command or program has been correctly defined and that and the user has the proper authorizations. You may also activate the SAPXPG trace utility to trace an external program. When creating the steps of a job and defining that this job will execute an external program, click on Control Flags. This will display a pop-up window where you can select, among other utilities, activate the SAPXPG trace. Or you may be able to start the SAPXPG trace when defining an external command or program in transaction SM69, as well as by setting the environment variable sapxpg_trace in the system where the external job will be executed. To check the log files for analysis, look into the developer traces dev_cp and dev_xpg.
  • Job remains in status active. Sometimes you can find jobs with active status even after a system restart. It can also happen that there is an inconsistency between the real status of the job and the entry in the corresponding job table. In any case, you should verify the real status of the job by looking at the job overview and then selecting the Check status function. If it is an ABAP program, you can try to capture it to put it in debugging mode in case it is in an infinite loop status. In the case of an external program, you should log on at the operating system level and check whether the process is still running there; otherwise you might have a problem starting external programs. Look at the background object to see if the zombie cleanup is activated. If it is not, create or change the object so that it automatically deletes the zombie job.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status