ZDATE_LARGE_TIME_DIFF
As per OSS Notes :
369370
Symptom
You want to operate
the SAP system in a specific time zone. All the application servers and the
database must be running on the same time zone. To do this the time zone of the
SAP Oracle database may need to be changed. This is usually done on UNIX by setting
the TZ environment variables in the environment of Oracle and SAP operating
system user (ora<sid> und <sid>adm). Even though the TZ environment
variable is correct for both users and agree with each other, you nonetheless
get the following error message when you log onto R/3: ZDATE_LARGE_TIME_DIFF.
Cause and prerequisites
If the Oracle TNS
listener is started under a different user than (ora<sid> und
<sid>adm), the TZ variable must also be correctly set in the environment
of these other users:
The R/3
kernel compares the time on the application server (by using the UNIX date command) with database time. If there is a big difference
between these time stamps, the error ZDATE_LARGE_TIME_DIFF is triggered.
The database
time is determined by the R/3 on Oracle by
SELECT
TO_CHAR (SYSDATE, 'YYYYMMDDHH24MISS') FROM DUAL;
The statement
above is in this case executed by an Oracle shadow process on the database
server. The result is the internal time of
the Oracle shadow processes, which executed the statement. The shadow process is forked by
the Oracle TNS listener for connection requests. It inherits the environment of
the listener, therefore it also inherits the time zone environment variable.
One special case is when several databases which are physically located in
various time zones are being operated on the same database server:
If several
databases in various time zones are being run on the same data base server,
then a separate listener with the respective, correct TZ environment variable
must be started for each database. Solution
The TZ environment variable must also be set correctly in the environment of
the user who starts the Oracle TNS listener.
SOLUTION:
Large time difference
between application server and database.The R/3 System
synchronizes the times of the database and applicationserver regularly. As a result, a very
large time difference was detected between these two systems.
The error probably occurred
when installing the
SAP System.
DBIF_RSQL_SQL_ERROR
As per OSS Notes :
136791
Symptom
With certain database
systems you find the system sometimes generates the runtime error
DBIF_RSQL_SQL_ERROR (due to an SQL error) in the generated program
GP$GLX$<table name>, where <table name> is the name of a profit center
table or an FI-SL table.
With ADABAS, the system outputs SQL error "-1013".
Cause and prerequisites
In a SELECT statement
a "GROUP BY" or "ORDER BY" addition with more than 16
fields is entered in the database. However, in certain cases the aggregation
with "GROUP BY" is not required (for example if the complete primary
key is specified in the field list).
Solution
Implement the
corrections set out in the attachment.
The R/3 kernel compares the time on the application server (by using the UNIX date command) with database time. If there is a big difference between these time stamps, the error ZDATE_LARGE_TIME_DIFF is triggered.
The database time is determined by the R/3 on Oracle by
SELECT TO_CHAR (SYSDATE, 'YYYYMMDDHH24MISS') FROM DUAL;
The statement above is in this case executed by an Oracle shadow process on the database server. The result is the internal time of the Oracle shadow processes, which executed the statement. The shadow process is forked by the Oracle TNS listener for connection requests. It inherits the environment of the listener, therefore it also inherits the time zone environment variable.
One special case is when several databases which are physically located in various time zones are being operated on the same database server:
If several databases in various time zones are being run on the same data base server, then a separate listener with the respective, correct TZ environment variable must be started for each database. Solution
The TZ environment variable must also be set correctly in the environment of the user who starts the Oracle TNS listener.
The error probably occurred when installing the
With ADABAS, the system outputs SQL error "-1013".
|
SYSTEM_CORE_DUMPED
Process terminated by signal " ".
What happened?
The current ABAP
program had to be terminated because the
ABAP processor
detected an internal system error.
The current ABAP
program "????????????????????????????????????????" had to be
terminated
because the ABAP
processor discovered
an invalid system state.
Error analysis
An SAP System process
was terminated by an operating system signal.
Possible reasons for
this are:
1. Internal SAP System
error.
2. Process was
terminated externally (by the system administrator).
.
You may able to find
an interim solution to the problem
in the SAP note
system. If you have access to the note system
OSS NOTES : 685625
Symptom
While you were activating ABAP programs, the work process terminated (either with an ABAP SYSTEM_CORE_DUMPED runtime error or with a "The work process was restarted" dialog message).
The active calls of the C functions in the SAP kernel which you can display in the long text of the ABAP SYSTEM_CORE_DUMPED runtime error using transaction ST22 or in the work process trace file using transaction SM50 are as follows:
[...]
addIDENT
addDATA
collect_data
addDATAPARAMS
addDATA
collect_data
collect_meth_event
collect_components
collect_class
sc_generatePreHdr
[...]
OSS NOTES : 685625
Symptom
While you were activating ABAP programs, the work process terminated (either with an ABAP SYSTEM_CORE_DUMPED runtime error or with a "The work process was restarted" dialog message).
The active calls of the C functions in the SAP kernel which you can display in the long text of the ABAP SYSTEM_CORE_DUMPED runtime error using transaction ST22 or in the work process trace file using transaction SM50 are as follows:
[...]
addIDENT
addDATA
collect_data
addDATAPARAMS
addDATA
collect_data
collect_meth_event
collect_components
collect_class
sc_generatePreHdr
[...]
Reason and Prerequisites
This is a program
error in the Precompiled header function of the ABAP compiler.
Solution
If the error mentioned
above applies to your system, install a new kernel which contains the kernel
patch with the following text, "SYSTEM_CORE_DUMPED in addIDENT
(gen/scsymbc.c)".
You have this kernel patch if the kernel has, depending on your Release, at least the following patch level:
Kernel release 6.20: 1371
Kernel release 6.40: 5
You have this kernel patch if the kernel has, depending on your Release, at least the following patch level:
Kernel release 6.20: 1371
Kernel release 6.40: 5
DYNPRO_SEND_IN_BACKGROUND
Error analysis
Error analysis
During background
processing, the system attempted to send a
screen to a user.
Screen output without
connection to user.
As per the OSS Notes :
434054
Symptom
During the document
processing via function modules, a program termination occurs.
The system generates dump DYNPRO_SEND_IN_BACKGROUND.
The system generates dump DYNPRO_SEND_IN_BACKGROUND.
Cause and prerequisites
The problem is caused
by a program error.
Solution
Implement the attached
correction.
Corrections Instructions
|
As per the OSS
NOTES : 717442
Symptom
The dump analysis
contains the following dump, which states:
DYNPRO_SEND_IN_BACKGROUND
The current "RSORACMP" ABAP program had to be interrupted, because it encountered a statement that, unfortunately, cannot be executed.
During background processing, an attempt was made to send a screen to a user.
Current screen: "RSORACMP" 0020.
DYNPRO_SEND_IN_BACKGROUND
The current "RSORACMP" ABAP program had to be interrupted, because it encountered a statement that, unfortunately, cannot be executed.
During background processing, an attempt was made to send a screen to a user.
Current screen: "RSORACMP" 0020.
Other terms
DYNPRO_SEND_IN_BACKGROUND
RSORACMP Oracle RAC OPS
Reason and Prerequisites
The dump may occur
when you use Oracle RAC (Real Application Cluster).
The dump occurs when the performance collector generates snapshot data. The RSORASNP report that causes the dump is called when the RSDBPREV report is scheduled.
The dump occurs when the performance collector generates snapshot data. The RSORASNP report that causes the dump is called when the RSDBPREV report is scheduled.
Solution
Import the relevant
Support Package.
Highest Implemented
Support Package
|
GETWA_TOO_MANY_SEGMENTS
No more data segments
available.
Error analysis
The system attempted
to create a new data segment, but this
exceeded the capacity
limit of 32767 data segments per roll area.
As per the OSS Notes :
509950
Symptom
The GETWA_TOO_MANY_SEGMENTS dump occurs.
Reason and Prerequisites
Technical description
(R/3 Release 4.0B - 4.6D)
Cause of error
You can manage a maximum of 32,768 global data segments in an internal mode. The administration occurs using the DSEG global segment table. If this limit is exceeded, the GETWA_TOO_MANY_SEGMENTS runtime error is triggered.
The upper limit of 32,768 global data segments for each internal mode is determined on a technical basis. You cannot change this limit via the profile parameter.
Importance of the DSEG table and explanation of the limit
The ABAP runtime uses global data segments to address (global and static) data. Simply expressed, a global data segment corresponds to an associated memory area. For instance, examples for these types of memory areas are the memory area for the global variables of a program or a table work area.
There is an entry in the DSEG global segment table for each global data segment. A global data segment can be addressed through the index of its entry in the DSEG (global segment index).
Each ABAP program (report, function group, module pool, global class, subroutine pool, EXCEPTIONS: global interface and TYPE POOL) requires global data segments. When the program is being loaded into the internal mode, the global data segments required from this program are allocated immediately in the DSEG (an exception creates data segments for text pools, which we will not deal with in more detail here). That is, an associated area of entries is assigned to each program in the DSEG. Therefore, the global data segments of a program can be addressed relatively at the beginning of this associated area (relative segment index).
Relative segment indexes are almost always used to address data in the ABAP. These are stored in a field of 15-bits in length. Unfortunately, in a few locations, absolute segment indexes must be placed in these 15 bits. Since a maximum of 32,768 global data segments can be addressed with 15 bits, no more than 32,768 data segments can be administered in a roll area.
The field in which segment indexes are stored could, of course, be extended to 32 bits. However, this would involve an unacceptable increase in the ABAP load.
Global data segments of a program
Each program (with the exception of global interfaces and TYPE POOLs) has the following six global data segments:
(1) A global data segment to address all global data of a program. The global data of a program includes all data objects declared with DATA outside FORM/FUNCTION/METHOD.
(2) A global data segment for all constants declared in the program (CONSTANTS declarations).
(3) A global data segment for addressing literals used in the program.
(4) A global data segment used for processing unassigned field symbols.
(5) A global data segment for the SY data area.
(6) A global data segment for the SYST data area.
Every program loaded in the internal mode therefore consumes at least six entries in the DSEG. A program also has other global data segments in addition to these six standard segments.
(7) Table work areas (TABLES ABAP statement)
Each table work area declared globally or locally with TABLES requires its own global data segment and consequently an entry in the DSEG. While the actual memory for the table work area is only allocated during the access, the related entry in the DSEG is created even if the table work area is not accessed at all later. In short: Every TABLES declaration in a program consumes an entry in the DSEG.
(8) COMMON PARTs (DATA BEGIN OF COMMON PART... ABAP statement). Each COMMON PART requires its own global data segment and therefore an entry in the DSEG
(9) Global field symbols (for example, FIELD-SYMBOLS ABAP statement). Each global field symbol requires its own global data segment and consequently an entry in the DSEG. You notice that global field symbols can also be declared implicitly, for instance, when you use global interfaces of function modules or when you call a functional method.
(10) Controls (CONTROLS ABAP statement)
Each control requires its own global data segment and consequently an entry in the DSEG.
(11) Database tables (SELECT, INSRET, UPDATE, MODIFY, DELETE)
A separate entry is required in the DSEG for each database table that is accessed.
(12) Statements between MODULE and ENDMODULE
Since these statements do not open a local area in the ABAP, the definitions there are global. This has an effect on statements that create actual local field symbols.
These field symbols are also global if these statements are used between MODULE and ENDMODULE. The following statements are affected:
(a) Functional Method Calls - As many field symbols are required as the maximum number of functional method calls within an expression.
(b) Internal table commands with WHERE condition A minimum of a field symbol is required for each of these statements, including a field symbol for each variable within the WHERE condition.
This does not apply to constants and literals in the WHERE condition.
(c) Perform parameter with offset/length - A field symbol is created for each actual parameter with an offset/length.
Displaying DSEG in the ABAP debugger
You can view the global segment table in the ABAP debugger as follows:
(1) Goto -> System areas -> Internal areas
(2) Enter DSEG
Below is a section of the debugger display of a DSEG. A more detailed description of the debugger is given below.
Index Segment Program name
...
3 DATA global data ZBGTEST (all ZBGTEST global data)
4 LITL constant data ZBGTEST (all ZBGTEST constants)
5 LITL constant data ZBGTEST (all ZBGTEST literals)
6 INVL not assigned ZBGTEST
7 TABL SYST ZBGTEST
8 TABL SY ZBGTEST
9 TABL RSJOBINFO ZBGTEST
10 COMM /%_SYS%% ZBGTEST
11 COMM /%_SSCR ZBGTEST
12 TABL VARI ZBGTEST
13 TABL SFLIGHT ZBGTEST (TABLES SFLIGHT)
14 TABL SBOOK ZBGTEST (TABLES SBOOK)
15 FSYM field symbol ZBGTEST (F1 field symbols)
16 FSYM field symbol ZBGTEST (F2 field symbols)
17 FSYM field symbol ZBGTEST (F3 field symbols)
18 COMM /TEST1 ZBGTEST (Common Part Test1)
19 COMM /TEST2 ZBGTEST (Common Part Test2)
20 TABL VBMOD ZBGTEST
21 DATA global data SAPMSSY0 ... Declarations of the next
22 LITL constant data SAPMSSY0 ... programs
23 LITL constant data SAPMSSY0
...
You can manage a maximum of 32,768 global data segments in an internal mode. The administration occurs using the DSEG global segment table. If this limit is exceeded, the GETWA_TOO_MANY_SEGMENTS runtime error is triggered.
The upper limit of 32,768 global data segments for each internal mode is determined on a technical basis. You cannot change this limit via the profile parameter.
Importance of the DSEG table and explanation of the limit
The ABAP runtime uses global data segments to address (global and static) data. Simply expressed, a global data segment corresponds to an associated memory area. For instance, examples for these types of memory areas are the memory area for the global variables of a program or a table work area.
There is an entry in the DSEG global segment table for each global data segment. A global data segment can be addressed through the index of its entry in the DSEG (global segment index).
Each ABAP program (report, function group, module pool, global class, subroutine pool, EXCEPTIONS: global interface and TYPE POOL) requires global data segments. When the program is being loaded into the internal mode, the global data segments required from this program are allocated immediately in the DSEG (an exception creates data segments for text pools, which we will not deal with in more detail here). That is, an associated area of entries is assigned to each program in the DSEG. Therefore, the global data segments of a program can be addressed relatively at the beginning of this associated area (relative segment index).
Relative segment indexes are almost always used to address data in the ABAP. These are stored in a field of 15-bits in length. Unfortunately, in a few locations, absolute segment indexes must be placed in these 15 bits. Since a maximum of 32,768 global data segments can be addressed with 15 bits, no more than 32,768 data segments can be administered in a roll area.
The field in which segment indexes are stored could, of course, be extended to 32 bits. However, this would involve an unacceptable increase in the ABAP load.
Global data segments of a program
Each program (with the exception of global interfaces and TYPE POOLs) has the following six global data segments:
(1) A global data segment to address all global data of a program. The global data of a program includes all data objects declared with DATA outside FORM/FUNCTION/METHOD.
(2) A global data segment for all constants declared in the program (CONSTANTS declarations).
(3) A global data segment for addressing literals used in the program.
(4) A global data segment used for processing unassigned field symbols.
(5) A global data segment for the SY data area.
(6) A global data segment for the SYST data area.
Every program loaded in the internal mode therefore consumes at least six entries in the DSEG. A program also has other global data segments in addition to these six standard segments.
(7) Table work areas (TABLES ABAP statement)
Each table work area declared globally or locally with TABLES requires its own global data segment and consequently an entry in the DSEG. While the actual memory for the table work area is only allocated during the access, the related entry in the DSEG is created even if the table work area is not accessed at all later. In short: Every TABLES declaration in a program consumes an entry in the DSEG.
(8) COMMON PARTs (DATA BEGIN OF COMMON PART... ABAP statement). Each COMMON PART requires its own global data segment and therefore an entry in the DSEG
(9) Global field symbols (for example, FIELD-SYMBOLS ABAP statement). Each global field symbol requires its own global data segment and consequently an entry in the DSEG. You notice that global field symbols can also be declared implicitly, for instance, when you use global interfaces of function modules or when you call a functional method.
(10) Controls (CONTROLS ABAP statement)
Each control requires its own global data segment and consequently an entry in the DSEG.
(11) Database tables (SELECT, INSRET, UPDATE, MODIFY, DELETE)
A separate entry is required in the DSEG for each database table that is accessed.
(12) Statements between MODULE and ENDMODULE
Since these statements do not open a local area in the ABAP, the definitions there are global. This has an effect on statements that create actual local field symbols.
These field symbols are also global if these statements are used between MODULE and ENDMODULE. The following statements are affected:
(a) Functional Method Calls - As many field symbols are required as the maximum number of functional method calls within an expression.
(b) Internal table commands with WHERE condition A minimum of a field symbol is required for each of these statements, including a field symbol for each variable within the WHERE condition.
This does not apply to constants and literals in the WHERE condition.
(c) Perform parameter with offset/length - A field symbol is created for each actual parameter with an offset/length.
Displaying DSEG in the ABAP debugger
You can view the global segment table in the ABAP debugger as follows:
(1) Goto -> System areas -> Internal areas
(2) Enter DSEG
Below is a section of the debugger display of a DSEG. A more detailed description of the debugger is given below.
Index Segment Program name
...
3 DATA global data ZBGTEST (all ZBGTEST global data)
4 LITL constant data ZBGTEST (all ZBGTEST constants)
5 LITL constant data ZBGTEST (all ZBGTEST literals)
6 INVL not assigned ZBGTEST
7 TABL SYST ZBGTEST
8 TABL SY ZBGTEST
9 TABL RSJOBINFO ZBGTEST
10 COMM /%_SYS%% ZBGTEST
11 COMM /%_SSCR ZBGTEST
12 TABL VARI ZBGTEST
13 TABL SFLIGHT ZBGTEST (TABLES SFLIGHT)
14 TABL SBOOK ZBGTEST (TABLES SBOOK)
15 FSYM field symbol ZBGTEST (F1 field symbols)
16 FSYM field symbol ZBGTEST (F2 field symbols)
17 FSYM field symbol ZBGTEST (F3 field symbols)
18 COMM /TEST1 ZBGTEST (Common Part Test1)
19 COMM /TEST2 ZBGTEST (Common Part Test2)
20 TABL VBMOD ZBGTEST
21 DATA global data SAPMSSY0 ... Declarations of the next
22 LITL constant data SAPMSSY0 ... programs
23 LITL constant data SAPMSSY0
...
Solution
As of kernel Release 6.10, the 32K limit for
the maximum line capacity of the DSEG no longer applies. As of this release the
line capacity practically has no limit. (32K per program instead of per
internal mode).
For all kernel releases < Release 6.10 (R/3 < 4.7), it is not possible to change this 32K limit. Therefore, you must try to reduce the number of global data segments consumed in the internal mode. The following options are available:
Use several internal modes
The number of global data segments can be reduced by using several internal modes. The required functions can be stored in a separate internal mode using CALL TRANSACTION, CALL DIALOG or SUBMIT REPORT.
Frequently, working in a transaction for hours, in combination with lots of navigations to different application areas, results in the DSEG overflowing. In this case, the simplest option is to close the current transaction using "/n" and to call the transaction again. (For example, by calling /nva01 you open a new DSEG.
Relocate less used functions into separate programs
Large programs should be split into several programs so that seldomly required functions are stored in separate programs. These programs and their global data segments are only loaded into the internal mode if the function implemented by them is actually needed.
Reduction of the number of table work areas
Every table work area declared with TABLES occupies an entry in the DSEG. You should first check which table work areas are actually used in the program. You should then delete declarations for unused table work areas.
Table work areas that are only used for some local programs, not used for all programs, and particularly those that are not used in any screen should be replaced with normal global variables. The "TABLES TABLE." declaration is replaced with "DATA TABLE TYPE TABLE". SELECT statements that use this table work area must be replaced with an explicit "INTO TABLE". Since work areas shared by several programs are part of the most complex and error-prone ABAP features, this conversion allows you to reduce the complexity of the affected programs as well as the number of DSEG entries. Naturally, this also facilitates maintenance of the affected programs.
Reducing global field symbols
As of Release 46D, you can replace global field symbols with date references. To do this, you replace the declaration of the global field symbol "FIELD-SYMBOLS <FS> TYPE T." with the declaration of a global data reference DATA FS_DREF TYPE REF TO DATA.". The assignment of the field symbol ASSIGN FIELD TO <FS>." is replaced with "GET REFERENCE OF FIELD INTO FS_DREF.". Uses of the global field symbol <FS> are transformed as follows: you declare a local work field symbol <FS> which does not need an entry in the global DSEG, and add the statement "ASSIGN FS_DREF->* TO <FS>" before the use or uses.
Since global function module interfaces are implemented by means of global field symbols, global function module interfaces represent a further source for saving global field symbols. However, you should note that no global field symbols, but rather global variables are used for fully typed value parameters in global interfaces. In other words, only reference parameters and incompletely typed value parameters are candidates for saving global field symbols. This gives rise to the following options for saving global field symbols:
(1) Global interface -> Local interface
Global interfaces can be completely converted to local interfaces. For this, parameters of the function module used globally in subroutines (forms) must be explicitly passed on to the subroutines. This procedure is useful if the call hierarchy of the subroutines is flat and clear within the function module.
(2) Completely type value parameters
If there are incompletely typed value parameters you should check whether you actually need this generosity. If not, you should completely type the value parameter.
(3) Reference parameter -> Value parameter
"Narrow" completely typed reference parameters, for instance of the category INT4, should be converted to value parameters. While this makes the parameter transfer fractionally slower, a global field symbol is saved.
Summarizing COMMON PART declarations
Several COMMON PART declarations in a program can be grouped together to form ONE COMMON PART declaration. TABLES work areas that are used across programs can be replaced by DATA statements within a COMMON PART declaration and can also be optimized as a result. An explicit "INTO WA" must be added to SELECT statements that use these TABLES work areas.
Global registration of programs involved in a transaction
With transactions there are often times, for instance INITIALIZE/CLEANUP, where corresponding callback routines must be called on the programs involved in the transaction. With complex transactions you often have the problem that you no longer know exactly which programs have actually been involved up to now in the transaction. These callback routines can therefore also be called for programs which were not involved at all in the transaction. As a result, programs are loaded unnecessarily into the roll area, where they consume global data segments. You can avoid the loading of unrequired programs if the programs required by the transaction that have such callback routines register on a global event at the time LOAD-OF-PROGRAM. The callback routines can then be called on the actual programs involved in the transaction for the times, via Events.
For all kernel releases < Release 6.10 (R/3 < 4.7), it is not possible to change this 32K limit. Therefore, you must try to reduce the number of global data segments consumed in the internal mode. The following options are available:
Use several internal modes
The number of global data segments can be reduced by using several internal modes. The required functions can be stored in a separate internal mode using CALL TRANSACTION, CALL DIALOG or SUBMIT REPORT.
Frequently, working in a transaction for hours, in combination with lots of navigations to different application areas, results in the DSEG overflowing. In this case, the simplest option is to close the current transaction using "/n" and to call the transaction again. (For example, by calling /nva01 you open a new DSEG.
Relocate less used functions into separate programs
Large programs should be split into several programs so that seldomly required functions are stored in separate programs. These programs and their global data segments are only loaded into the internal mode if the function implemented by them is actually needed.
Reduction of the number of table work areas
Every table work area declared with TABLES occupies an entry in the DSEG. You should first check which table work areas are actually used in the program. You should then delete declarations for unused table work areas.
Table work areas that are only used for some local programs, not used for all programs, and particularly those that are not used in any screen should be replaced with normal global variables. The "TABLES TABLE." declaration is replaced with "DATA TABLE TYPE TABLE". SELECT statements that use this table work area must be replaced with an explicit "INTO TABLE". Since work areas shared by several programs are part of the most complex and error-prone ABAP features, this conversion allows you to reduce the complexity of the affected programs as well as the number of DSEG entries. Naturally, this also facilitates maintenance of the affected programs.
Reducing global field symbols
As of Release 46D, you can replace global field symbols with date references. To do this, you replace the declaration of the global field symbol "FIELD-SYMBOLS <FS> TYPE T." with the declaration of a global data reference DATA FS_DREF TYPE REF TO DATA.". The assignment of the field symbol ASSIGN FIELD TO <FS>." is replaced with "GET REFERENCE OF FIELD INTO FS_DREF.". Uses of the global field symbol <FS> are transformed as follows: you declare a local work field symbol <FS> which does not need an entry in the global DSEG, and add the statement "ASSIGN FS_DREF->* TO <FS>" before the use or uses.
Since global function module interfaces are implemented by means of global field symbols, global function module interfaces represent a further source for saving global field symbols. However, you should note that no global field symbols, but rather global variables are used for fully typed value parameters in global interfaces. In other words, only reference parameters and incompletely typed value parameters are candidates for saving global field symbols. This gives rise to the following options for saving global field symbols:
(1) Global interface -> Local interface
Global interfaces can be completely converted to local interfaces. For this, parameters of the function module used globally in subroutines (forms) must be explicitly passed on to the subroutines. This procedure is useful if the call hierarchy of the subroutines is flat and clear within the function module.
(2) Completely type value parameters
If there are incompletely typed value parameters you should check whether you actually need this generosity. If not, you should completely type the value parameter.
(3) Reference parameter -> Value parameter
"Narrow" completely typed reference parameters, for instance of the category INT4, should be converted to value parameters. While this makes the parameter transfer fractionally slower, a global field symbol is saved.
Summarizing COMMON PART declarations
Several COMMON PART declarations in a program can be grouped together to form ONE COMMON PART declaration. TABLES work areas that are used across programs can be replaced by DATA statements within a COMMON PART declaration and can also be optimized as a result. An explicit "INTO WA" must be added to SELECT statements that use these TABLES work areas.
Global registration of programs involved in a transaction
With transactions there are often times, for instance INITIALIZE/CLEANUP, where corresponding callback routines must be called on the programs involved in the transaction. With complex transactions you often have the problem that you no longer know exactly which programs have actually been involved up to now in the transaction. These callback routines can therefore also be called for programs which were not involved at all in the transaction. As a result, programs are loaded unnecessarily into the roll area, where they consume global data segments. You can avoid the loading of unrequired programs if the programs required by the transaction that have such callback routines register on a global event at the time LOAD-OF-PROGRAM. The callback routines can then be called on the actual programs involved in the transaction for the times, via Events.
Attachment: Analysis of
the Current DSEG (Information for Technical Experts)
If you have to adjust
the programs, it may be helpful to know which programs require the most DSEG
entries.
For this it must be possible to be able to read the DSEG in the current process (debugger), or a post mortem in the dump.
Debugger (start using /h)
To display the table DSEG in the ABAP Debugger, proceed as follows:
For this it must be possible to be able to read the DSEG in the current process (debugger), or a post mortem in the dump.
Debugger (start using /h)
To display the table DSEG in the ABAP Debugger, proceed as follows:
·
In the debugger menu,
select Goto -> System -> System areas
·
Area = DSEG (then
select Return)
·
All DSEG lines are
displayed.
By entering the "SAFI" function code, you can write the current system area display on file into the standard application server directory (DIR_HOME profile parameter). The BC_DSEG_ANALYSIS program provides you with an overview of the TABLES segments (see above) that are marked with "TABL" in the display.
Dump Analysis (transaction ST22)
You can reconstruct the DSEG start index of all involved programs at the time of the termination:
·
Navigate to the long
text view of the /h runtime error in the ok field -> Select any function to
access the debugger (for example, overview: F6)
·
In the debugger,
display the internal table FT[]
·
Menu: Select Go
to-> Display data object -> Structure editor or display the table
contents directly.
·
The lines with ID =
'PG' (loaded programs) are relevant
·
The Value column
contains entries such as:
------------Program name-------------------------------- DSEG Index
0: Prg ZBGTEST 20020408160013 65535 D 26802 3 X 0
1: Prg SAPMSSY0 20020211150614 65535 D 14882 21 1
2: Prg SAPMSSYD 20020211150614 65535 D 14389 36 1
-----------------------------------------------------------^^^
Therefore, the ZBGTEST program starts at DSEG index 3 and ends at index 20. ZBGTEST therefore needs 18 DSEG entries.
STORAGE_PARAMETERS_WRONG_SET
Installation error.
What happened?
The current program
had to be terminated because of an
error when installing
the R/3 System.
The program had
already requested 72889680 bytes from the operating
system with 'malloc'
when the operating system reported after a
further memory request
that there was no more memory space
available.
What can you do?
Restart the SAP
System.
Error analysis
When the program was
running, it was established that more
memory was needed than
the operating system is able safely
to provide. To avoid a
system crash, you must prevent this
situation from
occurring.
How to correct the error
Report the error to
the group responsible for installing your
R/3 System.
As per OSS Notes:
51959
Symptom
Runtime error
STORAGE_PARAMETERS_WRONG_SET
Additional key words
Memory Management 3.0
Cause and prerequisites
The SAP System
attempts to allocate memory areas from the memory area 'HEAP'. However, this
memory is exhausted, although
1. one of the
following profile parameters has not yet been reached.
- abap/heap_area_dia (Memory that a single dialog process ..)
- abap/heap_area_nondia (.. a single non-dialog process ..)
(.. can allocate (maximum) )
These profile parameters are obviously not checked against the available SWAP memory on the application server. You can determine this memory with the SAP program 'memlimits', which can be found in the exe directory of your application server.
- abap/heap_area_dia (Memory that a single dialog process ..)
- abap/heap_area_nondia (.. a single non-dialog process ..)
(.. can allocate (maximum) )
These profile parameters are obviously not checked against the available SWAP memory on the application server. You can determine this memory with the SAP program 'memlimits', which can be found in the exe directory of your application server.
Solution
1. 1. Note the value
that is given as the allocated memory under 'What happened' in the short dump,
and subtract 10000000.
2. 2. Set the system
profile parameter ABAP/heap_area_nondia to this value. If the parameter
ABAP/heap_area_dia is now larger than ABAP/heap_area_nondia, set this parameter
to the noted value as well.
3. 3. Restart the SAP
System.
4. 4. If a short dump
occurs again, but with a different text, there is an infinite loop in
application that probably fills a table using APPENDs.
As per the OSS Notes :
44528
Symptom
The ABAP program terminates with short dump
STORAGE_PARAMETERS_WRONG_SET.
Reason and Prerequisites
The session terminates
because the maximum permitted or technically possible amount of memory (or,
more exact: address space) has been exceeded.
·
On 64-bit platforms,
the address space that can technically be used is sufficient. This termination
usually occurs if operating system quotas or SAP system quotas have been
exceeded.
·
On 32-bit platforms,
the maximum address space that is technically possible is severely restricted.
Here, the termination usually occurs because the technical limits of the
operating system, which are usually below set quotas, have been exceeded The
maximum address space available to an ABAP session is limited to a few 100 MB in
the standard setting. Under certain circumstances, the space can be increased
by a few 100 MB using special parameter settings; however, this will affect
buffer sizes and therefore performance negatively.
Quotas are used to terminate sessions with unreasonably high address space and memory requirements in time to prevent other programs or the actual operating system from being negatively affected by resource bottlenecks.
If the error mentioned above occurred, you must determine if the terminated session exceeded a reasonable size, if the operating system limits or quotas have been exceeded, or whether higher quotas can be set.
The following explains how to determine the size of a session:
·
While the session is
active:
SM50->
Details: Size of the session while it is processed in a work process
SM04-> Memory: Total size of all sessions within a log on, and sizes of the individual subsessions
SM04-> Memory: Total size of all sessions within a log on, and sizes of the individual subsessions
·
After the session
ended:
ST22:
Size at the time of termination
STAT,STAD: Consumption at roll-out in the various process steps
ST02-> Memory: Consumption of extended memory and process-local memory (heap)
The actual consumed address space may in some cases be larger than the size displayed. The reasons for this are:
STAT,STAD: Consumption at roll-out in the various process steps
ST02-> Memory: Consumption of extended memory and process-local memory (heap)
The actual consumed address space may in some cases be larger than the size displayed. The reasons for this are:
·
The alignment data and
administration data requires further bytes for each allocated memory portion.
Depending on the average size of the allocated memory portions, an additional
requirement of 10 % or more may result.
·
A fragmented address
space may, in problematic cases, result in the problem that the memory can no
longer be allocated, although sufficient address space is available.
Fragmentation means that the free areas of the address space have, due to
repeated allocation and release of space with unfavorable portion sizes, become
too small to meet the requirement for a large, contiguous portion of memory
space.
·
The session size at
the end of the processing step is displayed in the overview of the statistic
records. A temporary maximum size that occurred within the processing step is
only displayed in the detail view. The maximum size provides more information
especially for long-running steps such as batch jobs.
Memory classes
There are several
strategies according to which address space is allocated in sessions depending
on the platform and configuration. The goal is to optimally use all available
resources.
Three different memory classes can be used.
Three different memory classes can be used.
·
Roll:
is located in the local address space of the work process, and is copied to or from the rollfile or roll buffer at the start and end of a processing step.
is located in the local address space of the work process, and is copied to or from the rollfile or roll buffer at the start and end of a processing step.
·
Extended Memory (EM):
is located in the shared address space, and is made available or unavailable to the address space of the work process at the start and the end of a processing step by mapping or memory protection mechanisms.
is located in the shared address space, and is made available or unavailable to the address space of the work process at the start and the end of a processing step by mapping or memory protection mechanisms.
·
Heap (process-local
memory):
is located in the local address space of the work process and cannot be separated from the work process.
is located in the local address space of the work process and cannot be separated from the work process.
Allocation strategies:
1. Strategy: First
minimal roll, then EM, then rest roll, then heap.
This strategy is used in sessions that do not require a work process at the moment, for example, dialog sessions. As long as a heap is not used, you can free-up the previously used work process for other sessions.
This strategy is also used for sessions that occupy a work process continuously (for example, batch) on platforms where the total amount of EM could be very large due to the implementation (for example, Windows, Linux, special EM implementation for AIX).
This strategy is used in sessions that do not require a work process at the moment, for example, dialog sessions. As long as a heap is not used, you can free-up the previously used work process for other sessions.
This strategy is also used for sessions that occupy a work process continuously (for example, batch) on platforms where the total amount of EM could be very large due to the implementation (for example, Windows, Linux, special EM implementation for AIX).
2. Strategy: First
complete roll, then heap, then EM
This strategy is used in sessions if the total amount of EM is subject to tight limits, and the session occupies the work process continuously, so that the work process is not required to be freed for other sessions (for example, batch).
This strategy is used in sessions if the total amount of EM is subject to tight limits, and the session occupies the work process continuously, so that the work process is not required to be freed for other sessions (for example, batch).
Settings for individual
memory classes:
·
Roll:
ztta/roll_area: Size of the area in the work process
ztta/roll_first: Roll section used in strategy 1 before EM is used.
rdisp/ROLL_MAXFS: Size of the total swap area for roll for all sessions (rollfile).
rdisp/ROLL_SHM: Size of the part of the rollfile buffered in the memory.
ztta/roll_area: Size of the area in the work process
ztta/roll_first: Roll section used in strategy 1 before EM is used.
rdisp/ROLL_MAXFS: Size of the total swap area for roll for all sessions (rollfile).
rdisp/ROLL_SHM: Size of the part of the rollfile buffered in the memory.
·
Extended Memory EM:
ztta/roll_extension: Quota for the maximum EM amount that a session can use.
Different parameters exist for setting the EM total amount of an instance, which depend on the platform-specific implementation.
ztta/roll_extension: Quota for the maximum EM amount that a session can use.
Different parameters exist for setting the EM total amount of an instance, which depend on the platform-specific implementation.
·
Unix standard
implementation:
em/initial_size_MB
em/initial_size_MB
·
Windows, Linux:
em/initial_size_MB, em/max_size_MB, em/address_space_MB
em/initial_size_MB, em/max_size_MB, em/address_space_MB
·
Special implementation
for AIX:
ES/SHM_SEG_COUNT, ES/SHM_SEG_SIZE, ES/PROC_SEG_COUNT, EM/TOTAL_SIZE_MB
ES/SHM_SEG_COUNT, ES/SHM_SEG_SIZE, ES/PROC_SEG_COUNT, EM/TOTAL_SIZE_MB
·
Heap: Quota for the
maximum heap amount that a session can use.
abap/heap_area_dia, abap/heap_area_nondia, abap/heap_area_total
abap/heap_area_dia, abap/heap_area_nondia, abap/heap_area_total
Operating system limits:
You can use the
memlimits test program to assess the limits of the address space on a certain
platform, and check the correct settings and operation of the operating system.
Caution:
In extreme cases, this program could set the server to be tested to a status that requires a restart of the server.
Example:
memlimits -h ...issues help text
memlimits -l 40000 assess address space up to 40 GB
Caution:
In extreme cases, this program could set the server to be tested to a status that requires a restart of the server.
Example:
memlimits -h ...issues help text
memlimits -l 40000 assess address space up to 40 GB
Solution
Determine the memory
consumption of the application program or the session and compare it to the
existing limits.
Determine whether you want to make more address space available to the session, and increase the relevant settings if required or possible.
Decide whether the session size of the application program could be kept smaller, for example, by reducing the data amount processed.
Determine whether the application program requires too much memory, and whether you could decrease it. See Note 185185 to analyze the memory requirement.
Determine whether you want to make more address space available to the session, and increase the relevant settings if required or possible.
Decide whether the session size of the application program could be kept smaller, for example, by reducing the data amount processed.
Determine whether the application program requires too much memory, and whether you could decrease it. See Note 185185 to analyze the memory requirement.
Documentation
A detailed description
of SAP Memory Management and all relevant profile parameters is available in
the documentation at:
http://help.sap.com/saphelp_nw2004s/helpdata/de/02/96253c538111d1891b0000e8322f96/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/de/02/96253c538111d1891b0000e8322f96/frameset.htm
TIME_OUT
Time limit exceeded.
Error analysis
After a certain time,
the program terminates to free the work process
for other users who are
waiting.
This is to stop work
processes being blocked for too long by
- Endless loops (DO,
WHILE, ...),
- Database acceses
with large result sets,
- Database accesses
without an apporpriate index (full table scan)
- database accesses
producing an excessively large result set,
The maximum runtime of
a program is set by the profile parameter
"rdisp/max_wprun_time".
The current setting is
7200 seconds. After this, the system gives the
program a second
chance. During the first half (>= 7200 seconds), a
call that is blocking
the work process (such as a long-running SQL
statement) can occur.
While the statement is being processed, the
database layer will
not allow it to be interrupted. However, to
stop the program
terminating immediately after the statement has been
successfully
processed, the system gives it another 7200 seconds.
Hence the maximum
runtime of a program is at least twice the value of
the system profile
parameter "rdisp/max_wprun_time".
As per OSS Notes:
505585
Symptom
The purchase orders
mass maintenance terminates with
ABAP runtime error TIME_OUT. Other terms
MASS, MEMASSPO, BUS2012, MASS_CHANGE_PURCHASE_ORD,
TIME_OUT, PERFORMANCE, long runtime, NAST,
/1BCDWB/DBNAST, /1BCDWB/DBNAST,
SELECT_COUNT_STAR
ABAP runtime error TIME_OUT. Other terms
MASS, MEMASSPO, BUS2012, MASS_CHANGE_PURCHASE_ORD,
TIME_OUT, PERFORMANCE, long runtime, NAST,
/1BCDWB/DBNAST, /1BCDWB/DBNAST,
SELECT_COUNT_STAR
Reason and Prerequisites
The problem is caused
by a program error.
Before posting, the mass maintenance examines whether there are any notifications for the purchase order. The selection of notifications for a purchase order of table NAST terminates with ABAP runtime error TIME_OUT since the selection is only restricted to object key ekpo-ebeln.
The correction provides the selection of notifications for a purchase order in the mass maintenance with condition NAST-KAPPL = 'EF' (application for notification conditions).
Before posting, the mass maintenance examines whether there are any notifications for the purchase order. The selection of notifications for a purchase order of table NAST terminates with ABAP runtime error TIME_OUT since the selection is only restricted to object key ekpo-ebeln.
The correction provides the selection of notifications for a purchase order in the mass maintenance with condition NAST-KAPPL = 'EF' (application for notification conditions).
Solution
Implement the attached
advance correction.
Corrections Instructions
|
TSV_TNEW_PAGE_ALLOC_FAILED
ShrtText
No
storage space available for extending an internal table.
What happened?
You
attempted to extend an internal table, but the required space was
not
available.
What can you do?
To resolve the
problem, contact your SAP system administrator.
You can use
transaction ST22 (ABAP Dump Analysis) to view and administer
termination
messages, especially those beyond their normal deletion
date.
Try to find out
(e.g. by targetted data selection) whether the
transaction will
run with less main memory.
If there is a
temporary bottleneck, execute the transaction again.
-
If the error
persists, ask your system administrator to check the
following
profile parameters:
o
ztta/roll_area
(1.000.000 - 15.000.000)
Classic roll area per user and internal mode
usual amount of roll area per user and internal mode
o
ztta/roll_extension (10.000.000 -
500.000.000)
Amount of memory per user in extended memory (EM)
o
abap/heap_area_total (100.000.000 -
1.500.000.000)
Amount of memory (malloc) for all users of an application
server. If several background processes are running on
one server, temporary bottlenecks may occur.
Of course, the amount of memory (in bytes) must also be
available on the machine (main memory or file system swap).
Caution:
The operating system must be set up so that there is also
enough memory for each process. Usually, the maximum address
space is too small.
Ask your hardware manufacturer or your competence center
about this.
In this case, consult your hardware vendor
abap/heap_area_dia: (10.000.000 -
1.000.000.000)
Restriction of memory allocated to the heap with malloc
for each dialog process.
Parameters for background processes:
abap/heap_area_nondia: (10.000.000 -
1.000.000.000)
Restriction of memory allocated to the heap with malloc
for each background process.
Other
memory-relevant parameters are:
em/initial_size_MB: (35-1200)
Extended memory area from which all users of an
application server can satisfy their memory requirement.
As per OSS Notes:
600176
Symptom
When you execute
Transaction GD13 (FI-SL Display Totals Records), the system generates a
termination with runtime error TSV_TNEW_PAGE_ALLOC_FAILED because of a shortage
of main memory.
Reason and Prerequisites
Poor performance of
programming, not enough main memory
Solution
Implement the attached
corrections or import the appropriate Support Package.
If you implement the corrections manually, afterwards you have to adjust the following function module parameters using Transaction SE37 (only with IMPORT):
If you implement the corrections manually, afterwards you have to adjust the following function module parameters using Transaction SE37 (only with IMPORT):
1. Function module
G_GLU1_ACCUMULATE_FOR_GD13:
Import
parameters:
Parameter
Name
|
Optional
|
Pass
value
|
I_FIELDS
|
X
|
|
I_FIELDS_KEY
|
||
I_T_TABLE
|
||
I_PERIOD_AGG
|
X
|
2. Function module
G_GLU1_C_TAB_MODIFY_WITH_RANGE:
Import
parameters:
Parameter
Name
|
Optional
|
Pass
value
|
I_SELECTION
|
||
I_GLU1_CUM_IN
|
3. Function module
G_GLU1_WORKAREA_LIST_TO_RANGE:
Import
parameters:
Parameter
Name
|
Optional
|
Pass
value
|
I_TABLEAREA
|
||
I_LIST
|
||
I_TABLEAREA_CUM
|
X
|
If the termination with TSV_TNEW_PAGE_ALLOC_FAILED still occurs, then the physical memory of your application server is no longer sufficient for the selection criteria entered. In this case, the only thing that helps is a further restriction of the selections; however, an optimization of memory management may also be possible (see Note 103747).
Corrections Instructions
|
CONNE_IMPORT_WRONG_COMP_TYPE
ShrtText
Error when attempting to IMPORT object "P_FCTPAR".
What happened?
Error in ABAP application program.
The
current ABAP program "PPIO_ENTRY" had to be terminated because one of
the
statements could not be executed.
This is probably due to an error in the ABAP program.
When attempting to import data, it was discovered that the data
type of the stored data was not the same as that specified in the
program.
Error analysis
An
exception occurred. This exception is dealt with in more detail below
.
The exception, which is assigned to the class 'CX_SY_IMPORT_MISMATCH_ERROR',
was neither
caught nor passed along using a RAISING clause, in the procedure
"%_IMPORT_VARI_CLNT" "(FORM)"
.
Since the caller of the procedure could not have expected this exception
to occur, the running program was terminated.
The
reason for the exception is:
When importing the object "P_FCTPAR", the component no. 1 in the
dataset has a different type from the corresponding component
of
the target object in the program "PPIO_ENTRY".
The
data type is "C" in the dataset, but "y" in the program.
As per the OSS Notes :
734223
Symptom
During the revaluation
run via Transaction OKQ3 the job terminates. Termination
CONNE_IMPORT_WRONG_COMP_TYPE occurs in program RKKRMERK in form
MERKMALE_NACHBEWERTEN.
Reason and Prerequisites
The problem is caused
by a program error.
Solution
Implement the attached
correction instructions.
Corrections Instructions
|
Runtime
Error CONVT_NO_NUMBER
Except.
CX_SY_CONVERSION_NO_NUMBER
ShrtText
Unable to interpret "4.40UPLOADFEB2
" as a number.
As per OSS Notes
: 1006304
Symptom
You want to call a
transaction of the extended evaluation (for example, transaction CM50) in
ALV-mode. In the process, the system displays the runtime error
CONVT_NO_NUMBER, CX_SY_CONVERSION_NO_NUMBER, "*****" cannot be
interpreted as a number.
Reason and Prerequisites
This problem is caused
by a program error.
The error occurs if you want to display the capacity utilization percentage in a period with an available capacity of zero and if the capacity load of this period is greater than zero.
The error occurs if you want to display the capacity utilization percentage in a period with an available capacity of zero and if the capacity load of this period is greater than zero.
Solution
Implement the attached
correction.
Corrections Instructions
|
MESSAGE_TYPE_X
The current
application triggered a termination with a short dump.
What happened?
The current
application program detected a situation which really
should not occur.
Therefore, a termination with a short dump was
triggered on purpose
by the key word MESSAGE (type X).
How to correct the error
Probably the only way
to eliminate the error is to correct the programyourself,
use the following
search criteria:
"MESSAGE_TYPE_X"
C
"SAPLRSM2 "
or "LRSM2F16 "
"ODS_EINBUCHEN"
As per the OSS NOTES:
940654
Symptom
Open any hyperlink
from a Winword document via SE38. The relevant document would be openedin Word.
Here, when you select the 'BACK' option, a short dump occurs with error
MESSAGE_TYPE_X, in SAPLCNTL.
Other terms
Document, Link,
winword, BACK, short dump, MESSAGE_TYPE_X,SAPLCNTL
Reason and Prerequisites
This dump occurs due
to some problem while releasing GUI containers/controls. Please also check the
OSS note 815686 for more information.
Solution
Please apply the
corrections in the note via SNOTE, or import the relevant Support Package.
Highest Implemented
Support Package
|
SPOOL_INTERNAL_ERROR
ShrtText
Internal error in the spool system.
What happened?
The
current ABAP program had to be terminated because the
ABAP processor detected an internal system error.
The
current ABAP program "ZRSALERTDISP" had to be terminated because the
ABAP
processor discovered an invalid system state.
Error analysis
When calling the SAP spool system, an (unspecified) internal
error occurred.
As per the OSS Notes :
16534
Symptom
Batch job terminates
due to errors in the spooler
SysLog F82: Invalid writer count
No handle for an open TemSe object
(magic==X'4f444f23')
Some error in TemSe management
Runtime error "SPOOL_INTERNAL_ERROR" occurred
Transaction termination 00671
SysLog F82: Invalid writer count
No handle for an open TemSe object
(magic==X'4f444f23')
Some error in TemSe management
Runtime error "SPOOL_INTERNAL_ERROR" occurred
Transaction termination 00671
Other terms
Spool, RSPO0043,
RSPO1043
Reason and Prerequisites
Spooler consistency
check RSPO0043 or RSPO1043 is used in the productive system with a
"lock-delete duration" that is too low.
The problem can arise both during online checks in the SPAD and in the batch.
To date, there has been no other definitive cause.
Important: RSPO0043 is obsolete. Use only RSPO1043 for the spooler TemSe consistency check.
The spooler consistency check RSPO1043 deletes the write locks on spool requests that are older than a certain duration. This duration (the "age" of the write locks) is specified as the parameter "Release locks after...minutes".
The standard value for RSPO1043 is 10080 minutes, or seven days. The problem cannot occur with this standard value, since there are normally no batch jobs that have a runtime up to seven days.
(RSPO0043 has a standard value of thirty minutes, RSPO0043 should no longer be used, see above)
The problem can arise both during online checks in the SPAD and in the batch.
To date, there has been no other definitive cause.
Important: RSPO0043 is obsolete. Use only RSPO1043 for the spooler TemSe consistency check.
The spooler consistency check RSPO1043 deletes the write locks on spool requests that are older than a certain duration. This duration (the "age" of the write locks) is specified as the parameter "Release locks after...minutes".
The standard value for RSPO1043 is 10080 minutes, or seven days. The problem cannot occur with this standard value, since there are normally no batch jobs that have a runtime up to seven days.
(RSPO0043 has a standard value of thirty minutes, RSPO0043 should no longer be used, see above)
Solution
Select the parameter
"Release locks after ... minutes" so that it is large enough so that
no write locks of spool requests of current batch jobs are affected during the
daily execution of RSPO1043.
OBJECTS_OBJREF_NOT_ASSIGNED_NO
CX_SY_REF_IS_INITIAL
Short text
Access via 'NULL' object reference not possible.
Error analysis
An
exception occurred that is explained in detail below.
The
exception, which is assigned to class 'CX_SY_REF_IS_INITIAL', was not
caught in
procedure "ACTION_001" "(FORM)", nor was it propagated by a
RAISING clause.
Since the caller of the procedure could not have anticipated that the
exception would occur, the current program is terminated.
The
reason for the exception is:
You
attempted to use a 'NULL' object reference (points to 'nothing')
access a component.
An
object reference must point to an object (an instance of a class)
before it can be used to access components.
Either the reference was never set or it was set to 'NULL' using the
CLEAR statement.
As per the OSS Notes:
554303
Symptom
Runtime error OBJECTS_OBJREF_NOT_ASSIGNED_NO
exception CX_SY_REF_IS_INITIAL in CL_UG_MD_CHAR->IF_UG_MD_CHAR~COUNT-VALUE.
Reason and Prerequisites
The object reference
was not assigned.
Solution
Implement the note.
Corrections Instructions
|
As per the OSS Notes :
867606
Symptom
In the program
/BA1/SAPLB1_EACC_SERVICES, the runtime error
OBJECTS_OBJREF_NOT_ASSIGNED_NO occurs when you access an object reference that was not referenced (zero).
OBJECTS_OBJREF_NOT_ASSIGNED_NO occurs when you access an object reference that was not referenced (zero).
Other terms
CX_SY_REF_IS_INITIAL
Reason and Prerequisites
The problem is due to
a program error.
Solution
Implement the
correction.
Corrections
Instructions
|
DDIC_TYPES_INCONSISTENT
As per the OSS Notes:
595069
Symptom
·
An ABAP program
terminates with one of the following runtime errors:
·
DDIC_STRUCLENG_INCONSISTENT
·
DDIC_TYPES_INCONSISTENT
·
other runtime errors
of the format DDIC_..._INCONSISTENT
·
An error occurs that
was apparently caused by an inconsistency of a DDIC runtime object, that is,
the ABAP program does not work with the correct type description of a DDIC
object.
However, when checking
the runtime object in transaction SE11, the system reports that the runtime
object is consistent.
The object is of a nested data type, that is, a DDIC object with Includes.
The object is of a nested data type, that is, a DDIC object with Includes.
Reason and Prerequisites
A runtime object (also
called NAMETAB object) is created from the description of a data type in the
ABAP dictionary (DDIC). The ABAP runtime uses this runtime object if the
relevant DDIC object is used in an ABAP program.
Inconsistencies may occur during the generation of the DDIC runtime object, that is, the header or the field list differ from the current source of the DDIC object. If such an inconsistent runtime object is used in an ABAP program, the system may issue the above-mentioned runtime errors. This may also cause various other errors, for example, when internal tables or structures are accessed.
When checking a runtime object in transaction SE11, the system only performs a consistency check on the highest level of an object. However, if the object is a nested structure with Includes, the check in SE11 will not directly find inconsistencies in the Includes.
Inconsistencies may occur during the generation of the DDIC runtime object, that is, the header or the field list differ from the current source of the DDIC object. If such an inconsistent runtime object is used in an ABAP program, the system may issue the above-mentioned runtime errors. This may also cause various other errors, for example, when internal tables or structures are accessed.
When checking a runtime object in transaction SE11, the system only performs a consistency check on the highest level of an object. However, if the object is a nested structure with Includes, the check in SE11 will not directly find inconsistencies in the Includes.
Solution
As of Release 6.20 of
the SAP Web Application Server, the standard version contains a RSDDCHECK
report. The report allows you to check DDIC runtime objects in a recursive way,
that is, to perform a complete check that also comprises all included data
types of a nested DDIC object.
You can check individual DDIC objects but also all dependent objects of an ABAP program or a class.
By importing the Support Packages listed below, the report is also made available in Basis Releases 4.5B to 6.10 (AS Web).
The source code of the report is attached to this note so that you can implement it if required if the relevant Support Package was not yet imported. A separate version exists for Release 4.5B. The version attached for Release 4.6X can also be used in Release 6.10/6.20.
An extended version of the report for Releases 4.6B until 6.40 extends the checks for (1) incorrect length of table types and (2) existing DDIC runtime objects without a source. To do this, import the corresponding Support Packages, which are also listed.
Description of the functions of the RSDDCHECK report
You can check individual DDIC objects but also all dependent objects of an ABAP program or a class.
By importing the Support Packages listed below, the report is also made available in Basis Releases 4.5B to 6.10 (AS Web).
The source code of the report is attached to this note so that you can implement it if required if the relevant Support Package was not yet imported. A separate version exists for Release 4.5B. The version attached for Release 4.6X can also be used in Release 6.10/6.20.
An extended version of the report for Releases 4.6B until 6.40 extends the checks for (1) incorrect length of table types and (2) existing DDIC runtime objects without a source. To do this, import the corresponding Support Packages, which are also listed.
Description of the functions of the RSDDCHECK report
1. Selecting the
objects to be checked
You
can either select the objects to be checked directly on the selection screen of
the report or you can specify a program or class. In this case, the report
determines all DDIC objects that are used in the program and then checks this
object set.
2. Display options:
By
default, only inconsistent runtime objects are displayed in the list of
results. However, you can also display a complete list of all objects checked.
This view also displays the hierarchical structure of nested objects.
As of Release 6.20 of the Web Application Server, DDIC structures have an enhancement category. You can display the enhancement category for all structures checked. The display also shows if the implicit enhancement category corresponds to the explicit enhancement category (inconsistencies may occur in this case with nested structures).
As of Release 6.20 of the Web Application Server, DDIC structures have an enhancement category. You can display the enhancement category for all structures checked. The display also shows if the implicit enhancement category corresponds to the explicit enhancement category (inconsistencies may occur in this case with nested structures).
3. List of results
If
the check finds inconsistent DDIC runtime objects, they are listed in the
following format:
[Action][number]...name (internal type) header/field
[Action] or [number] represent two icons you can use to activate the DDIC object directly or to display the runtime object.
The number of dots before the object name specifies the maximum nesting depth used to include the inconsistent object in other objects.
The internal type shows if the object is, for example, a data element, a structure, and so on.
The end of the line shows if the header or the field list of the runtime object is inconsistent.
Caution: Bear in mind that when activating a central DDIC object, the system must also activate and generate a large number of additional DDIC objects and dependent ABAP programs. This may cause considerable performance problems. You should, therefore, only perform this step with caution in a production system.
[Action][number]...name (internal type) header/field
[Action] or [number] represent two icons you can use to activate the DDIC object directly or to display the runtime object.
The number of dots before the object name specifies the maximum nesting depth used to include the inconsistent object in other objects.
The internal type shows if the object is, for example, a data element, a structure, and so on.
The end of the line shows if the header or the field list of the runtime object is inconsistent.
Caution: Bear in mind that when activating a central DDIC object, the system must also activate and generate a large number of additional DDIC objects and dependent ABAP programs. This may cause considerable performance problems. You should, therefore, only perform this step with caution in a production system.
Highest Implemented
Support Package
|
As per the OSS Notes :
507808
Symptom
The user menu of the
Easy Access allows to start transactions in a system
via a Trusted/Trusting connection. By default, the transactions are
started via synchronous RFC in the same window. Unfortunately, this leads to some problems.
If user enters "/n" in Command-field of the target system (server),the
transaction is cancelled and the remote system is closed. Although this
works as designed many customers complain about this behavior.
Some transactions use the instruction "leave to transaction sy-tcode" to return to the initial screen. When these transactions are called remotely the system returns to the calling system and tries to start the transaction there. This behavior is undesired but unavoidable when synchronous RFC is used.
via a Trusted/Trusting connection. By default, the transactions are
started via synchronous RFC in the same window. Unfortunately, this leads to some problems.
If user enters "/n" in Command-field of the target system (server),the
transaction is cancelled and the remote system is closed. Although this
works as designed many customers complain about this behavior.
Some transactions use the instruction "leave to transaction sy-tcode" to return to the initial screen. When these transactions are called remotely the system returns to the calling system and tries to start the transaction there. This behavior is undesired but unavoidable when synchronous RFC is used.
Other terms
RFC, TRANSACTION,
CALL_FUNCTION_OPEN_ERROR
Solution
By setting a
customizing flag, it is now possible to start remote transaction in a separate
window using asynchronous RFC. To enable asynchronous RFC, the entry
ASYNC_RFC=YES has to be added to table SSM_CUST. Please note: The new window
flag is ignored if asynchronous RFC is turned on (for remote transactions
only).
Corrections Instructions
|
As per the OSS Notes:
493396
Symptom
The following error is
displayed when you process a transactional RFC:CALL_FUNCTION_OPEN_ERROR
Protocol error when communicating with SAP GUI
The termination occurred in the ABAP/4 program "SAPLOLEA" in "AC_FLUSH_CALL_INTERNAL".
Protocol error when communicating with SAP GUI
The termination occurred in the ABAP/4 program "SAPLOLEA" in "AC_FLUSH_CALL_INTERNAL".
Other terms
Error in middleware
Reason and Prerequisites
This is a side effect
of a program correction contained in the SAP kernel.
The error occurs in Release 4.6D after you import patch level 944.
The error occurs in Release 4.6D after you import patch level 944.
Solution
The error is corrected
with patch level 956. You have to import the new kernel. A short-term solution
for the error (workaround) is to comment out the GET PARAMETER ID 'GUI_IS_ON'
FIELD GUI_IS_ON command in the GUI_IS_AVAILABLE function module.
If the error still occurs, this is most likely due to an incorrect GUI installation.
Install the GUI again.
If the error still occurs, this is most likely due to an incorrect GUI installation.
Install the GUI again.
DATASET_CANT_OPEN
As per the OSS Notes:
777057
Symptom
BCA_ALIAS is terminated with dump
DATASET_CANT_OPEN because the error file cannot be opened.
Reason and Prerequisites
The problem is caused
by a program error.
Solution
Implement the attached
source code correction.
Corrections Instructions
|
SPOOL_I/O_ERROR
As per the OSS Notes:
379482
Symptom
You start the RFDOPR10
report as a background job with a large dataset. The job terminates with the
following error message: ABAP-processor: SPOOL_I/O_ERROR.
Other terms
RFAUSZ00, RFDAPO00,
RFDEPL00, RFDOFW00, RFDOPO00, RFDOPO10, RFDOPR00 RFDOPR20, RFKAPO00, RFKEPL00,
RFKOFW00, RFKOPO00, RFKOPR00, RFKLBU10, RFKLETT00, reporting, block table
Reason and Prerequisites
The block table with
large datasets overflows.
Solution
Implement the
modification note to solve the problem. Implement the source code corrections
specified below.
Corrections Instructions
|
OPEN_DATASET_NO_AUTHORITY
As per the OSS NOTES :
927564
Symptom
When you terminate a
measurement with the ABAP runtime analysis, the system generates the
OPEN_DATASET_NO_AUTHORITY runtime error in the CL_ABAP_TRACE_SWITCH=>OFF( )
method.
Other terms
ABAP, runtime
analysis, switch=>off
Reason and Prerequisites
The runtime
measurement terminates with an error. When you attempt to determine the error
cause from the header of the performance data file, the above-mentioned short
dump occurs due to missing S_DATASET authorization.
Solution
If the user does not
have the mentioned authorization, the system does not read the header of the
performance data file. As a result, you cannot determine the exact error cause
for the termination of the runtime measurement. The system then issues the
following status message:
"Measurement could not be completed ()"
A respective Support Package and correction instruction are available.
"Measurement could not be completed ()"
A respective Support Package and correction instruction are available.
Highest Implemented
Support Package
|
|
Runtime
Errors PERFORM_NOT_FOUND
Except.
CX_SY_DYN_CALL_ILLEGAL_FORM
Symptom
In Release ERP 2004
(ECC 5.00), when you select an entry in the hit list of the missing parts
information system (transaction CO24) and choose the 'Refresh -> Selected
objects' function, the PERFORM_NOT_FOUND short dump occurs with the
CX_SY_DYN_CALL_ILLEGAL_FORM exception.
In Release ERP 2005 (ECC 6.00), when you select an entry and choose the 'Read -> Selected objects' function, the above short dump occurs as well.
In Release ERP 2005 (ECC 6.00), when you select an entry and choose the 'Read -> Selected objects' function, the above short dump occurs as well.
Other terms
CO24, PPCMP000,
missing parts information system, MissingPartsInfoSyst
Reason and Prerequisites
This problem is caused
by a program error.
Solution
Implement the relevant
correction for your release.
Corrections Instructions
|
Posts
No comments:
Post a Comment