Display of RFC logon screen in SM51

[] [] [] [] [] [] [] [] [] []

Related:

  1. BIA 7.00: BI Accelerator High AvailabilitySymptom You have installed BI Accelerator (BIA). Other terms high...
  2. SAPShortcut: Default logon languageSymptom You want to use an SAP shortcut to logon...
  3. DB2-z/OS: Install MS Cluster solutionSymptom You want to install a high availability system for...

Symptom

When you execute remote function calls, the RFC logon screen is displayed for the logon to the selected application server. The same applies when you execute one of the functions of transaction SM51 (for example, Release Info).
Otherwise, the entries CALL_FUNCTION_SIGNON_REJECTED or CALL_FUNCTION_SYSCALL_ONLY are made in the system log (transaction SM21) and in the developer trace files (dev_w*).
Other terms

RFC, logon screen, logon, CALL_FUNCTION_SIGNON_REJECTED, CALL_FUNCTION_SYSCALL_ONLY, high availability
Reason and Prerequisites

These situations occur only if an RFC logon fails. For the RFC logon procedure, see Note 51367.
Generally, the system does not require an RFC logon under the identical client and user ID in the same system. Only the RFC logon screen and either of the entries CALL_FUNCTION_SIGNON_REJECTED or CALL_FUNCTION_SYSCALL_ONLY are displayed in one of the following cases:
1. The RFC destination uses the incorrect logon data; that is, the maintained values for client, user and password display no valid logon data.2. Not all servers that belong to the same system have the same release (kernel release) and the same patch level. When using high-availability cluster packages, you have to make sure that this condition is met for all servers involved.3. The server in question does not have sufficient shared memory (PXA memory). In transaction ST22 (transaction for ABAP/4 dump analysis), you find the ABAP/4 runtime errors PXA_NO_SHARD_MEMORY or PXA_NO_FREE_SPACE.4. The database key differs on different servers that belong to the same system. This may be due to the installation of several network cards in the database server from which some servers identify the database server by another host name and IP address. You may be able to display and compare this information with the database data that is displayed in the system status of the respective servers.5. The database key was regenerated due to a database crash or system tablespace reorganization, and it differs from the database key that was already used in an application server. Therefore, each attempt to log on to another application server using transaction SM51 terminates with the following error message “SIGNON failed”:

Trace extract level 2 contains the error message:
A RFC SignOn> SIGNON failed <===
A RFC SignOn> Generated DB-Key
A RFC SignOn> Regularly Logon Access Type: R
A RFC SignOn> Client
A RFC SignOn> User
A RFC SignOn> WhoAmI
A RFC SignOn> Tcode SM51
A RFC SignOn> SystemID
A RFC SignOn> TimeStamp
A RFC SignOn> Same tickets = N <===
A RFC SignOn> DB-Key
A RFC SignOn> Signon RC 1 <===
6. The profile parameter gw/alternative_hostnames was configured incorrectly.

Remarks:
An RFC logon screen is displayed only for online communication. During background processing, RFC communication terminates with the note on incorrect logon data (CALL_FUNCTION_SIGNON_REJECTED or CALL_FUNCTION_SYSCALL_ONLY in the developer trace files or in the system log).Using function module "DB_DBIDENT", you can determine the value of the database key on each application server. You must ensure that this value is the same for all application servers of a system that are involved.7. After the database was upgraded, the database client software on the application server in question was not upgraded or an error occured during the upgrade.Solution

1. Check the logon data by means of the destination used.
You have to make sure that the user has not previously been
locked.
2. Make sure that all participating servers have the same
release (kernel release) and the same patch level.
3. You can solve the shared memory problem (PXA problem), for example,
with Notes 4413 and 77833.
4. Make sure that all participating servers
access the database server using the same host name and IP address.
Check that all servers have the same
database hostname. This is defined using the profile parameter
SAPDBHOST (usually contained in the file DEFAULT.PFL
or, in the case of MSSQL, this is overridable as the system
environment variable MSSQL_SERVER) and must be identical
(note uppercase and lowercase).
With lib_dbsl_411 (Note 374276),
the processing sequence of the parameters in the MSSQL
server database has changed as follows:
new old
1. Environment variable 1. Profile parameters
2. Profile parameters 2. Environment variable
Remark:
See Note 773501 for the error in the lib_dbsl during the
fingerprint determination.
5. Restart all application servers in the system after you have corrected the problem with the database crash or reorganized the system tablespace.
6. See Note 662895.
Remark:
Note 91980 can help you to analyze the errors in more depth. Here, you must make sure in advance that the error can be reproduced.A temporary solution is delivered with Note 25721.
7. Check the installation of the databank client software on the server in question.
Repairs in the Code

Important: Do not enter any source code here. You must only enter source code in the screen
'Corrections' -> ‘Correction instructions’.
Any lines entered here are automatically deleted when you save.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Leave a Comment