In the remote function call, the system issues the following error message as a text for the RFC exception SYSTEM_FAILURE: Other terms
"CPIC server sends screen &P1 &P2 (termination)"
with &P1 = program name and &P2 = screen number, or, as of Release 3.0F, the error message:
"Screen output without connection to user"
or in online mode, the following message:
Maximum number of sessions reached
CALL_FUNCTION_REMOTE_ERROR (as an ABAP/4 runtime error) with the long text: CPIC server sends screen, ... (termination). Reason and Prerequisites
DYNPRO_SEND_IN_BACKGROUND (as ABAP/4 runtime error on the RFC server) with the text: Screen output without connection to user.
00213, Maximum number of sessions reached, 14411,
Screen output without connection to user
You tried to send screens or lists using an RFC connection.
These error messages appear in the following scenarios:
- During RFC communication between two R/3 systems or within the same R/3 system, the following error situations may occur:
- When you execute the calling program in a batch process, the output of screens or lists in the server program always terminates the communication, regardless of the user type used. Note that RFC server programs are always executed in dialog processes.
- When you execute the calling program in a dialog process, this action leads to the communication being terminated due to the missing user authorization. The user for the RFC connection does not have the required dialog user type. Check the user profile (transaction SU01 or using the menu Tools -> Administration -> User maintenance -> User) for the user type 'dialog'. An RFC user of type CPIC, batch or BDC would lead to a termination when outputting screens or lists in the called function module. This occurs if the target system is an R/3 system with an SAP kernel of Release 3.0E or higher. To find this information on the target system, call transaction SM51 and choose 'Release Notes'.
- In the case of RFC communication between an R/3 system and an external program (for example, C, Visual Basic or other external programs), outputting screens or lists always terminates the communication, regardless of the user type, unless the external program uses a SAPGUI (RFC with SAPGUI).
- If you use asynchronous RFC for generating modeless windows, the short dump occurs when the number of open sessions is already reached. As a result, another screen/list output as modeless screen is not possible.
Note 755912 with the patch text "CST Patch Collection 30 2004" solves the runtime error DYNPRO_SEND_IN_BACKGROUND when you use the asynchronous RFC to create modeless windows.
- If you use synchronous RFC to generate windows with modes, the short dump occurs, if the remote ABAP context is removed using ABAP language elements such as LEAVE TO statements or SUBMIT <report> or by entering the function code '/n<transaction code>' into the OK code field. When generating alternative sessions from an RFC context, the following types of entries are made in the developer tracefile (dev_w*):
M *** ERROR => ThCpicInitTermConv: no user key [thxxcpic 8066]
- Comment: Depending on the screen output, various ABAP runtime errors are logged.
If a list or screen is processed in the application transaction, this leads to ABAP runtime error DYNPRO_SEND_IN_BACKGROUND.
If an RFC function call with destination "SAPGUI" is processed in the application transaction (like the call of function module "SAPGUI_PROGRESS_INDICATOR"), this leads to ABAP runtime error CALL_FUNCTION_OPEN_ERROR.
- If the following message is displayed when you execute asynchronous RFC in online mode,
Maximum number of sessions reached (error number: 14 411)
although the maximum number of sessions has not been reached yet, a screen output was carried out in the called function module.
- If an internal mode is processed in the RFC function module using one of the ABAP language elements "SUBMIT <report> and RETURN", "CALL TRANSACTION <tcode> USING", no screen output such as list or screen processing must be carried out in this internal mode. This typical problem occurs when executing WRITE statements in a SUBMIT <report> and RETURN statement.
- Comment: Executing the WRITE statement in the RFC function module does not lead to any screen output.
You can find additional information in the form of syslog entries in transaction SM21, as well as in the error message 'Outputting screen without connection to user' and in the dump analysis in transaction ST22.
- In the case of RFC communication between two R/3 systems or within the same R/3 system, use the following alternatives:
- When you execute the calling program in a batch process, you have to modify the called R/3 function modules in a way that screens or lists are no longer output.
- When you execute the calling program in a dialog process, use an RFC user with the dialog user type.
- In the case of RFC communication between an R/3 system and an external program without function RFC with SAPGUI, the called R/3 function modules must be modified so that screens or lists are no longer output.
- In the case of screen output as modeless window, the application must determine the number of existing sessions first and initiate corresponding steps afterwards. In addition, you must ensure that the kernel contains the following patch levels including the text "aRFC: max emode reached":
For 40B kernels: Patch level 629, with patch text:
RFC: patch collection
For 45B kernels: Patch level 370, with patch text:
aRFC: max emode reached
For 46B kernels: Patch level 112, with patch text:
RFC: patch collection
- In the case of screen output as modal window, refer to Note 174306.
Here, prevent an irregular exit from the transaction in the target system by entering '/n<tcode>' in the Ok-code field. The screen output must not be a full screen including menu bar. If this cannot be prevented by the application, proceed as follows to prevent the problem:
- Use asynchronous RFC instead of synchronous RFC when executing the function module that leads to the screen output.
- Screen output must not be made on the receiver side but on the caller side. Calling the RFC modules retrieves the information from the target system only.
- If the caller system and the target system use SAP Release 620 or higher, you can make the following enhancement in the destination concerned by entering '/n<tcode>' as a temporary solution to avoid the session termination if the end solution cannot be directly realized by using asynchronous RFC or changing the screen output on the caller side (see above).
You must ensure that this destination is explicitly available for this application only and is not a generic destination that can be used by many applications, such as the internal destination (for example, destination "NONE").
The value "00000020" should be maintained in the RFC destination on the "Special Options" tab page and for the function button "RFC Bit options". This prevents the session from being terminated in the window by entering '/n <tcode>'. However, after ending the session, (for example, by closing the window), the caller receives the RFC exception "SYSTEM_FAILURE".
This option must be tested thoroughly by the application concerned before use, to ensure that the logic of the application is kept.
Comment: As of Release 700, this function is no longer available.
In general, more information about the cause of the termination is available in the section Error analysis for ADAP dump analysis. In this case, the underlying application must analyze and correct the error cause. If the application considers this to be an RFC error, the following required information on processing the problem must be added to the problem message:
1. How to reproduce the problem.
2. The corresponding RFC, ABAP/Dynpro/Taskhandler and Gateway Traces of the error situation.
3. The corresponding short dumps (among other things at least the first 15 pages of the DYNPRO_SEND_IN_BACKGROUND short dump)
4. The remote connection including logon data for the system, where the error occurs in reproducible form.