CALL_FUNCTION_SIGNON_REJECTED

We are getting the short dump CALL_FUNCTION_SIGNON_REJECTED in every 30 minute in ECC6 server (We just upgradeed R/3 4.6c to ECC6 last week). We have two application server and one CIDB server. We are getting the following short dump in both applcation server after every 30 minute:
Short text |
You are not authorized to logon to the target system (error code 1).
Error analysis |
RFC (Remote Function Call) sent with invalid
user ID "SAPSYS " or client 000.
User "SAPSYS " under client 000 from system "NPR " has tried to carry out an
RFC
call under the user ID "SAPSYS " and client 000 (Note: For releases < 4.0, the
information on caller and caller system do not exist.).
User and Transaction
Client.............. 000
User................ "SAPSYS"
Language Key........ "E"
Transaction......... " "
Transactions ID..... "4B84CF0E521C02CFE10000000A2C0A31"
Program............. "SAPMSSY1"
Screen.............. "SAPMSSY1 3004"
Screen Line......... 2
Information on caller of Remote Function Call (RFC):
System.............. "NPR"
Database Release.... 701
Kernel Release...... 701
Connection Type..... 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type........... "synchron and non-transactional (emode 0, imode 0)"
Inbound TID.........." "
Inbound Queue Name..." "
Outbound TID........." "
Outbound Queue Name.." "
Client.............. 000
User................ "SAPSYS"
Transaction......... " "
Call Program........."SAPLSALC"
Function Module..... "SALC_GET_MT_LIST_BY_MTCLASS"
Call Destination.... "rx1n1v3_NPR_03"
Source Server....... "dbcinpr_NPR_15"
Source IP Address... "10.44.10.10"
Additional information on RFC logon:
Trusted Relationship " "
Logon Return Code... 1
Trusted Return Code. 0
Note: For releases < 4.0, information on the RFC caller are often
| only partially available.
Pls help to fix this problem.
Thanks
Amar

For this issue please read:
"Note 1622004 - RZ20 sometimes displays a communication error", if your dump shows issues on function module SALC_GET_MT_LIST_BY_MTCLASS.
Sometimes RZ20 shows communication problems and dumps on ST22 CALL_FUNCTION_SIGNON_REJECTED appears with user sapsys and client 000, you have to check your system topology on RZ21 under technical infrastructure and change the oracle context instance (database and CCMS database Selfmonitoring) to the correct segment name database server or CI.
Kind Regards

Similar Messages

SM21 log Run-time error "CALL_FUNCTION_SIGNON_REJECTED"

Hello All,
This error occurring due to report Z_USER_LOCK_REPORT executes in BG job
u201CINACTIVE_USER_REPORTu201D and locks user u201CSMANAGERu201D this user is not dialog
user.
As per the Z_USER_LOCK_REPORT report it should lock only dialog user.
Can anyone please help with the inputs?

erm didnt you give the required inputs yourself?
Just lock user if he is as dialog user. thats it.

Regading getting data to and forth between 2 programs through SUBMIT

Hi All,
I have a issue regarding fetching internal table data from one program to another.
Actually I have Main Program from that through SUBMIT statement i am calling another program and executing it for every 100 records - Actually this program is having BAPI running in it, By result i will get an internal table data. Now i want to get that internal table data back into my MAIN Program so that i can use it for next process.
EXPORT & IMPORT statements are working from MAIN Program to Other Program.
EXPORT & IMPORT statements are not working from Other Program[SUBMIT'ed Program] to MAIN Program.
So can anybody tell me how can i get that data in other program into MAIN Program[Back].
Thanks in advance.
Thanks & Regards,
Rayeez.

When you submit the program is then running in parallel with the program which submitted it. There is no mechism that you are using to stop the calling program and wait for the submitted program to finish and bring back some data. Most likly program 1 ends before program 2 is finished updating the material master. You can do this kind of thing with Function modules. You would put your call to the submitted program inside of a function module, then call that function module saying STARTING IN NEW TASK, then you can wait for it to be done and get the results using the RECIEVING statement.
Here is the F1 Help.
+
CALL FUNCTION
Variant 2
CALL FUNCTION func ...STARTING NEW TASK task name.
Additions:
1. ... DESTINATION dest
2. ... DESTINATION IN GROUP group name
3. ... DESTINATION IN GROUP DEFAULT
4. ... PERFORMING form ON END OF TASK
5. ... EXPORTING p1 = f1 ... pn = fn
6. ... TABLES p1 = itab1 ... pn = itabn
7. ... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
Starts the function module func asynchronously ina new session. In contrast to normal function module calls, the callingprogram resumes processing as soon as the function module is started inthe target system. It does not wait until the function module hasfinished. Through CALL SCREEN,the called function module can, for example, display a screen and thusinteract with the user.
Notes
This variant applies only from R/3 Release 3.0, so boththe client system and the server system must have Release 3.0 orhigher.
With this variant, the called function module must also be flagged inthe Function Builder as externally callable, even if it is executedlocally (without the addition DESTINATION).
There can be no function call to the destination 'BACK' in thecalled function module (for more information about the destination 'BACK', see CALLFUNCTION func DESTINATION dest).
This variant does not support the execution of externalprograms accessible via the destination of the TCP/IP type asasynchronous calls (see the Transaction Tools ¨Administration, Administration ¨ Network ¨ RFC destinations formaintaining destinations).
You cannot display screens (screens or lists asamodal windows in RFC communication using SAP Router.
From Release 4.0, you can check the load of each RFC destination moreclosely (in the RFC destination maintenance for an R/3 connection, choose Destination -> ARFC options). This checks whetherthe target host has sufficient resources before the function module isexecuted. If the target host is overloaded, the system delays executingthe function module. The algorithm for calculating the load on thetarget host is the same one used in an asynchronous RFC call using the DESTINATION IN GROUP addition. Note that this option can only beused with target hosts running Release 3.1H or higher. Note also thatit is the default setting.
In principle, parallelization makes sense whenever applicationservers have the necessary resources. In this case, the applicationservers must be configured with at least 3 dialog work processes.
A program that is run in the background and uses RFC parallelizationrequires at least 1 dialog work process per application server becausedialog processes use parallel execution.
If the instance profile parameter 'auth/rfc_authority_check'is set (to 1), the system automatically performs an RFC authorizationcheck. The authorization check refers to the relevant function groupfor the function module to be called. If no authorization is found, aruntime error occurs. You can check the authorization in advance withthe function module AUTHORITY_CHECK_RFC. If the communication takes place in the same system with thesame user context (same client and user ID), there is no authorizationcheck. For further information, refer to the RFCAuthorization Concept.
When you are using asynchronous RFC to implement parallel windows,all these windows are closed if the caller session is the only sessionand terminates.
ABAP_ADDITION_1&
... DESTINATION dest
Effect
Executes the function module externally as a RemoteFunction Call (RFC); dest can be a literal or a variable.The R/3 System where the function module is executed depends on thespecified destination. Externally callable function modules must beflagged as such in the Function Builder (of the target system).
Note
If the destination is not explicitly specified, the systemuses the default destination 'NONE'.
Note
If, during a RemoteFunction Call, an error occurs in the target system, detailsof the error message are passed bac to the calling system in thefollowing system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1,SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields areinitialized before every RFC. If a short dump or a type X messageoccurs, the short text of the dump is transferred to the caller, andthe contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.
In RFC-enabled function modules, no ABAP statements are allowed thatwould end the RFC connection (for example, LEAVE, SUBMIT or the ANDRETURN addition).
Note
Note that a database commit occurs at eachRemote Function Call (RFC). Consequently, you may not use RemoteFunction Calls between pairs of statements that open and close adatabase cursor (such as SELECT ... ENDSELECT).
Addition 2
... DESTINATION IN GROUP group name
Addition 3
... DESTINATION IN GROUP DEFAULT
Effect
You use this addition to perform parallel execution offunction modules (asynchronous calls) on a predefined group of R/3System application servers.
You use addition 2 (DESTINATION IN GROUP group name) toperform parallel execution of function modules on a predefined group ofapplication servers. To maintain the RFC groups, choose Tools ¨ Administration ¨ Administration ¨ Network ¨ RFCdestinations ¨ RFC ¨ RFC groups. The application programmer isresponsible for the availability of RFC groups in the productionsystem.
You use addition 3 (DESTINATION IN GROUP DEFAULT) to performparallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However,instead of this variant, you are recommended to use an RFC group withappropriate resources for parallel processing of asynchronous calls (atleast for performance reasons). Please note that the additionDESTINATION IN GROUP ' ' has the same effect as the additionDESTINATION IN GROUP DEFAULT.
When you first call a function module with these additions, thesystem initializes the specified RFC group (provided no explicitinitialization has already been performed).
To obtain current information about resources (that is, the number ofresources available to process function modules), you can alsoinitialize the RFC group explicitly in the program via the functionmodule SPBT_INITIALIZE. You must perform this actionbefore the first function module call.
In both cases, the system first determines the number of currentlyavailable resources (work processes) on the available applicationservers (either a group of servers or all servers). By checking thecurrent system load of each application server, the system determineshow many work processes are available to execute asynchronous calls.
After determining the available resources, the asynchronous call isexecuted at one of the destinations. If no resources are available atthat particular time, the system executes the exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In thecase of an asynchronous function module call, this exception must be handled by the application program (see example).
Parallel processing cannot take place if any of the resourcethresholds are exceeded.
Notes
In order to be taken into consideration for RFC parallelprocessing, an application server must have at least 3 freedialog processes.
The system triggers the exception RESOURCE_FAILURE only forasynchronous RFCs with the additions DESTINATION IN GROUP groupname and DESTINATION IN GROUP DEFAULT.
At present, only one RFC group per program environment issupported for parallel execution of asynchronous calls. Using both theadditions DESTINATION IN GROUP group name and DESTINATION INGROUP DEFAULT in a program is thus not allowed.
To find out which destination was automatically selected, call thefunction module SPBT_GET_PP_DESTINATION immediately after thefunction module call with the two additions. This returns the selectedRFC destination.
If you want to delete an application server from the list of theconfigured RFC group at runtime (for example, when the applicationserver is not accessible for technical reasons), use the functionmodule SPBT_DO_NOT_USE_SERVER.
Addition 4
... PERFORMING form ON END OF TASK
While the parameters for receiving results (i.e. IMPORTING andTABLES parameters) are specified directly as additions in thecase of "conventional" function modules (see variant 2), these arelogged in the FORM routine form when making anasynchronous call (see RECEIVE).
Notes
If a function module returns no result, and you are notinterested in error messages that arise when executing the functionmodule, this addition (... PERFORMING form ON END OF TASK) canbe omitted.
If you want to handle the error messages that arise when executingthe asynchronous function module call, you must use thisaddition. Also, when receiving the results in the FORM routine(see RECEIVE), you must reactaccordingly to the system exceptions SYSTEM_FAILURE andCOMMUNICATION_FAILURE.
With asynchronous RFC, the task name uniquely identifies theasynchronous connection and thus the context called.
If several asynchronous function modules are executed consecutivelyto the same destination, you must assign a different task name to each.
A calling program that starts an asynchronous RFC with PERFORMINGform ON END OF TASK cannot switch roll areas or change to aninternal session. This is because the asynchronous function module callreply cannot be passed on to the relevant program. You can perform aroll area switch with SUBMIT or CALL TRANSACTION.
If a calling program makes asynchronous calls, finishes, and thenexpects responses, these responses cannot be delivered.
To wait for the reply to a started asynchronous function module, usethe WAIT command with the additionPERFORMING form ON END OF TASK. Here, WAIT must be in thesame program context (session).
Note that the execution of the asynchronous calls involves a changeof roll area. This means that the FORM routines for receivingthe external calls can be processed while you are making furtherexternal calls. This means that the developer must ensure thatthe FORM routines can be executed at any time. You cannotmake any assumptions about the processing sequence.
Addition 5
... EXPORTING p1 = f1 ... pn = fn
Effect
EXPORTING passes values of fields and fieldstrings from the calling program to the function module. In thefunction module, the formal parameters are defined as importparameters.
Addition 6
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes the contents of internal tables.
Addition 7
... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
While any exceptions arising in the called functionmodule are handled by the second addition (in the FORM routine),this addition can handle two special system exceptions, as withfunction module calls with the addition DESTINATION:
SYSTEM_FAILURE
is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE
is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with theoptional addition
... MESSAGE msg
Note
In principle, you should always react to these twosystem exceptions, whether you are making an asynchronous functionmodule call or receiving results.
Examples
Asynchronous call to a transaction and display in a separate session.
DATA: MSG_TEXT(80) TYPE C. "Message text
Asynchronous call to Transaction SM59 -->
Create a new session
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'
DESTINATION 'NONE'
EXPORTING
 TCODE = 'SM59'
EXCEPTIONS
 COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
 SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT.
IF SY-SUBRC NE 0.
 WRITE: MSG_TEXT.
ELSE.
 WRITE: 'O.K.'.
ENDIF.
Using RFC groups to parallelize function module calls (RFC parallelprocessing)
TYPES: BEGIN OF TASKLIST_TYPE,
 TASKNAME(4) TYPE C, "Task administration
 RFCDEST LIKE RFCSI-RFCDEST
 END OF TASKLIST_TYPE.
DATA: INFO LIKE RFCSI, C, "Message text
 JOBS TYPE I VALUE 10, "Number of parallel jobs
 SND_JOBS TYPE I VALUE 1, "Sent jobs
 RCV_JOBS TYPE I VALUE 1, "Received replies
 EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
 TASKNAME(4) TYPE N VALUE '0001', "Task name administration
 TASKLIST TYPE TABLE OF TASKLIST_TYPE,
 WA_TASKLIST TYPE TASKLIST_TYPE.
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO'
 STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT
 PERFORMING RETURN_INFO ON END OF TASK
 EXCEPTIONS
 COMMUNICATION_FAILURE = 1
 SYSTEM_FAILURE = 2
 RESOURCE_FAILURE = 3.
CASE SY-SUBRC.
 WHEN 0.
Administration of asynchronous tasks
 WA_TASKLIST-TASKNAME = TASKNAME.
 CLEAR WA_TASKLIST-RFCDEST.
 APPEND WA_TASKLIST TO TASKLIST.
 WRITE: / 'Started task: ', WA_TASKLIST-TASKNAME COLOR 2.
 TASKNAME = TASKNAME + 1.
 SND_JOBS = SND_JOBS + 1.
 JOBS = JOBS - 1. "Number of existing jobs
 IF JOBS = 0.
 EXIT. "Job processing finished
 ENDIF.
 WHEN 1 OR 2.
Handling of communication and system failure
 WHEN 3. "No resources available at present
Receive reply to asynchronous RFC calls
 IF EXCP_FLAG = SPACE.
 EXCP_FLAG = 'X'.
First attempt for RESOURCE_FAILURE handling
 WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.
 ELSE.
Second attempt for RESOURCE_FAILURE handling
 WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.
 ENDIF.
 IF SY-SUBRC = 0.
 CLEAR EXCP_FLAG. "Reset flag
 ELSE. "No replies
 "Endless loop handling
 ENDIF.
 ENDCASE.
ENDDO.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST INTO WA_TASKLIST.
WRITE:/ 'Received task:', WA_TASKLIST-TASKNAME COLOR 1,
 30 'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.
ENDLOOP
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
 IMPORTING RFCSI_EXPORT = INFO
 EXCEPTIONS
 COMMUNICATION_FAILURE = 1
 SYSTEM_FAILURE = 2.
RCV_JOBS = RCV_JOBS + 1. "Receiving data
 IF SY-SUBRC NE 0.
Handling of communication and system failure
 ELSE.
 READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME
 INTO WA_TASKLIST
 IF SY-SUBRC = 0. "Register data
 WA_TASKLIST-RFCDEST = INFO_RFCDEST.
 MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.
 ENDIF.
 ENDIF.
ENDFORM
Note
If you encounter problems, refer toTypical RFC problems and theirsolutions.
Note
Runtime errors:
Note
Runtime errors:
CALL_FUNCTION_NO_RECEIVER:
Data received for an unknown CPI-C connection.
CALL_FUNCTION_DEST_TYPE:
Destination type not allowed.
CALL_FUNCTION_NO_DEST:
Specified destination does not exist.
CALL_FUNCTION_NO_LB_DEST:
Specified destination (in load distribution mode) does not exist.
CALL_FUNCTION_TABINFO:
Data error (info internal table) in a Remote Function Call.
CALL_BACK_ENTRY_NOT_FOUND:
The called function module is not released for use in RFC.
CALL_FUNCTION_FIELD_NOT_FOUND:
The function parameter that you passed is not recognized on therecipient side.
RFC_NO_AUTHORITY:
The user does not have RFC authorization.
CALL_FUNCTION_SINGLE_LOGIN_REJ:
No authorization to log on as a trusted system. The error codeshave the following meanings:
0) Valid security key but wrong logon data 1) Calling system is not a trusted system, or security key is invalid 2) User either does not have RFC authorization (authorization object S_RFCACL), or logged on as one of the protected users 'DDIC' or 'SAP*' 3) Timestamp of the logon data is invalid
CALL_FUNCTION_DESTINATION_NO_T:
Missing communication type (I for internal connection, 3 for R/3) in anasynchronous RFC
CALL_FUNCTION_NOT_REMOTE:
The function module called is not flagged as "RFC supported"
CALL_FUNCTION_REMOTE_ERROR:
An error occurred during the Remote Function Call. This has been loggedin the target system.
CALL_FUNCTION_SIGNON_INCOMPL:
The logon data for the user is incomplete.
CALL_FUNCTION_SIGNON_INTRUDER:
You cannot log onto a target system using an internal call.
CALL_FUNCTION_SIGNON_INVALID:
External RFC without a valid user name.
CALL_FUNCTION_SIGNON_REJECTED:
Attempt to log onto a target system without a valid user name. Theerror code can have the following meanings:
1) Wrong password or invalid user ID
2) User locked
3) Too many logon attempts
4) Error in authorization buffer (internal error)
5) No external user check
6) Invalid user type
7) Validity period of user has expired
CALL_FUNCTION_SYSCALL_ONLY:
RFC without a valid user name only allowed when calling system functionmodules. For the meaning of the error codes, refer toCALL_FUNCTION_SINGLE_LOGIN_REJ.
CALL_FUNCTION_TABLE_NO_MEMORY:
No memory available for a table to be imported
CALL_FUNCTION_TASK_IN_USE:
Asynchronous RFC only: Task name already in use.
CALL_FUNCTION_TASK_YET_OPEN:
Asynchronous RFC only: The specified task is already open.
CALL_FUNCTION_SNC_ERROR:
Error reading the SNC information for the destination.
CALL_RPERF_SLOGIN_READ_ERROR:
No valid trusted system entry for the calling system.
CALL_RPERF_SLOGIN_AUTH_ERROR:
No trusted authorization for the RFC caller and trusted system.
+
Regards,
Rich Heilman

RFC_SYS_EXCEPTION

Hi,
I am trying to connect to an R/3 system from a VB6.0 program. When I called an RFC I got:
"RfcCallReceive[1]: returns 3: RFC_SYS_EXCEPTION"
I inspected from SM21 and got the message: "CALL_FUNCTION_SIGNON_REJECTED".
does anybody have any idea about my problem?
thanks...
Ferudun

Hi ferudun,
1.
Runtime error: CALL_FUNCTION_SIGNON_REJECTED
This error codes may have any of the following meanings:
1) Incorrect password or invalid user ID
2) User locked
3) Too many login attempts
5) Error in authorization buffer (internal error)
6) No external user check
7) Invalid user type
8) Validity period of the user exceeded
regards,
amit m.

ABAP process hangs when calling a jCO Server J2EE-available RFC

Hi there
Here's the scenario:
We have deployed a jCO server under the SAP WAS. This jCO server implements two functions. They are both called from ABAP process through RFC. We are using the same RFC destination for both
First function is defined with import/export parameters and the second one only operates with a TABLE parameter.
Incidentally, these functions are captured by the jCO server, which calls an IBM MQ server
First function works fine. Second function hangs and there is not even a timeout so the ABAP process (run on foreground) can stay forever.
The interesting part is that the same application works really fine when called from a Tomcat using a standalon instance of the jCO.
Additional info:
We have noticed that some time after the second function gets called, there are five dumps on the system (the same amount of servers we make available). These are CALL_FUNCTION_SIGNON_REJECTED.
The fun part of the dumps is that the user making the RFC call is a different user that the one we use for the jCO connection, and the client number is '000', instead of the '728' we are using for the connection. Somehow they seem related but we do not know how yet:
Short text
 You are not authorized to logon to the target system (error code 1).
What happened?
 Error in the ABAP Application Program
 The current ABAP program "SAPMSSY1" had to be terminated because it has
 come across a statement that unfortunately cannot be executed.
Error analysis
 RFC (Remote Function Call) sent with invalid
 user ID "%_LOG01% " or client 000.
 User "ARINSO " under client 001 from system "SMD " has tried to carry out an
 RFC
 call under the user ID "%_LOG01% " and client 000 (Note: For releases < 4.0,
 the
 information on caller and caller system do not exist.).
Call Program........."SAPLSMSY_ACTUALIZE_DATA"
Function Module..... "SCSM_SYSTEM_LIST"
Call Destination.... "SM_ET7CLNT000_READ"
Source Server....... "sapwasmd_SMD_10"
Source IP Address... "172.17.82.80"
Termination occurred in the ABAP program "SAPMSSY1" - in
 "REMOTE_FUNCTION_CALL".
 The main program was "SAPMSSY1 ".
 In the source code you have the termination point in line 67
 of the (Include) program "SAPMSSY1".
Any tip or suggestion on where to look at is more than welcome
Thanks in advance,
Miguel

And this is the content of the defaultTrace.0.trc log from the WAS
1.#005056AB04C500440000000200002B0000046B495CA1AF67#1243862737727#com.sap.caf.um.relgrou
ps.imp.principals.RelGroupFactory##com.sap.caf.um.relgroups.imp.principals.RelGroupFactor
y.RelGroupFactory()#######SAPEngine_System_Thread[impl:5]_13##0#0#Info#1#/System/Server#P
lain###sap.com caf/um/relgroups/imp MAIN_NW701P03_C 2846629#
#1.#005056AB04C500240000000100002B0000046B495CCDAAFB#1243862740608#com.sap.engine.library
.monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
isterNode</Kernel/System Threads Pool/WaitingTasksCount>: com.sap.engine.library.monitor.
mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for node'/Kerne
l/System Threads Pool/WaitingTasksCount' (MANAGERS.SThreadPool.WaitingInRequestQueueCount
, max. 40 characters)#
#1.#005056AB04C500240000000200002B0000046B495CCDB4CC#1243862740612#com.sap.engine.library
.monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
isterNode</Kernel/System Threads Pool/WaitingTasksQueueOverflow>: com.sap.engine.library.
monitor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for nod
e'/Kernel/System Threads Pool/WaitingTasksQueueOverflow' (MANAGERS.SThreadPool.Waiting4Fr
eeReqQueueSlotCount, max. 40 characters)#
#1.#005056AB04C500240000000300002B0000046B495CCDCDA1#1243862740618#com.sap.engine.library
.monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
isterNode</Kernel/Application Threads Pool/WaitingTasksCount>: com.sap.engine.library.mon
itor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for node'/
Kernel/Application Threads Pool/WaitingTasksCount' (MANAGERS.AThreadPool.WaitingInRequest
QueueCount, max. 40 characters)#
#1.#005056AB04C500240000000400002B0000046B495CCDD69B#1243862740620#com.sap.engine.library
.monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
isterNode</Kernel/Application Threads Pool/WaitingTasksQueueOverflow>: com.sap.engine.lib
rary.monitor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group fo
r node'/Kernel/Application Threads Pool/WaitingTasksQueueOverflow' (MANAGERS.AThreadPool.
Waiting4FreeReqQueueSlotCount, max. 40 characters)#
#1.#005056AB04C500600000001600002B0000046B4960688301#1243862801089#com.sap.slm.exec.messa
ge.SLMApplication#sap.com/tcslmslmapp#com.sap.slm.exec.message.SLMApplication#Guest#0##
n/a##c59827604eaf11de9fb3005056ab04c5#SAPEngine_Application_Thread[impl:3]_0##0#0#Error##
Java###null##
#1.#005056AB04C500730000000000002B0000046B4CF0593ABD#1243878100908#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain###com.sap.mw.jco.JCO$AbapException: (126) 1: Array index out of rang
e: 48#
#1.#005056AB04C500730000000100002B0000046B4CF0594028#1243878100909#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at com.efh.jco.valtran.sap.ValtranRequestHandler.serverExceptionO
ccurred(ValtranRequestHandler.java:164)#
#1.#005056AB04C500730000000200002B0000046B4CF059406B#1243878100910#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at com.sap.mw.jco.JCO.fireServerExceptionOccurred(JCO.java:880)#
#1.#005056AB04C500730000000300002B0000046B4CF05940A3#1243878100910#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.listen(JCO.java:8187)#
#1.#005056AB04C500730000000400002B0000046B4CF05940DB#1243878100910#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.work(JCO.java:8303)#
#1.#005056AB04C500730000000500002B0000046B4CF0594111#1243878100910#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.loop(JCO.java:8250)#
#1.#005056AB04C500730000000600002B0000046B4CF0594143#1243878100910#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.run(JCO.java:8166)#
#1.#005056AB04C500730000000700002B0000046B4CF05941F0#1243878100910#System.err#arinso.com/
valtran_validator#System.err#Guest#0##ET7#MIGUELGU #4A240FF606CD5E
5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
p]##0#0#Error##Plain### at java.lang.Thread.run(Thread.java:770)#

Short Dump in master data load

In a master dataload from BI to APO, i'm getting these short dumps...
CALL_FUNCTION_SIGNON_REJECTED
TIME_OUT
MESSAGE_TYPE_X
RAISE_EXCEPTION
Kindly help me out getting these dumps rectified..

Hai message type x error have number of parameters for it one may be due to error in logical source system .Other may be inactive datatargets and lot more.
Time out is becouse of upfront loading trigger in the background and ask basis to extend the process time to max sap standards.
others may be due to lack of workprocess unavailability check it as well.
Goodday.

Gate Way Connection dropped - Urgent

Hi,
We created TCP/IP RFC destination. Through which we are calling the .NET services. The Listener running at .NET side. We can able to call the .NET function module. At this point of time we can see the entry(RFC) in TCode SMGW -->Goto --> Logged on clients.
But over the period when we call the .NET function we are getting the Dump as follows.
Runtime Errors : CALL_FUNCTION_OPEN_ERROR
"CPIC-CALL: 'ThSAPECMINIT'#Transaction program not registered ""
Error text........... "program TDF_INT not registered"
Description.......... "TP TDF_INT not registered"
AT this point of time we cant see the entry(RFC)in TCode SMGW.
Note: When we restart the Listener at .NET side, i can able to call .NET Function module.
We are able to see whether gate way is opened or not.
Is there any way to Connect the gate way programmatically? Or anybody could say me why we its breaking the connection after some time
Raja T

Hi
Were also getting the similar kind of problem. We have .Net connector, but when it talks with SAP , its giving short dump . With "user name " does not exist . Finally we have posted the message to SAP.
What you can do to trace the problem :
You can also run the report: RSRFCTRC (TO Trace RFC ) OR Tr. S_ALR_87101279.
FYI OSS note # 313971
Symptom
The "CALL_FUNCTION_SIGNON_REJECTED" runtime error occurred.
Dumps or RFC errors occur in the syslog or in the Developer Trace files (dev_w*) for the SAPSYS user in a dialog process.
These errors occur every 5 minutes.
The analysis displays the SAPMSSY8 report or certain function modules used by the monitor architecture as the error source.
CAUTION: Various system components may cause error messages for the SAPSYS (AB0) user. This note is limited to error messages from data collectors in the monitor architecture. Refer also to Note 487873.
Other terms
SXPG_COMMAND_EXECUTE, X_ERROR, CALL_FUNCTION_SIGNON_REJECTED, RZ20, sapdba, CONTROL_PERF_REQUEST, AB0, RZ03
Reason and Prerequisites
When restarting the system, certain reports (Startup methods) are executed in monitoring, to create subtrees for different subject areas in RZ20 (for example, database monitoring).
For these subtrees to be supplied with data in the current system, additional reports or function modules (data collective methods) must run on a regular basis.
You can start startup methods and data collective methods online or in the background. Online, they run on the SAPSYS user. The SAPSYS user only has limited rights, particularly with regard to RFC calls.
RFC error messages in the monitoring area can occur in customer-specific methods.
However, there are also some SAP standard methods for the database monitoring agent of RFC syslog messages.
An external command is executed via SXPG_COMMAND_EXECUTE on the database host in these data collective methods (function modules/reports). If they are not running on the database but rather on another application server, an RFC call is started, which causes the SAPSYS user to terminate.
The following methods should only run on the central instance:
CCMS_DB_Freespace_CT
CCMS_DB_Indices_CT
CCMS_DB_LogMgt_CT
CCMS_DB_OptStat_CT
Change this configuration for these methods:
New:
RZ21 -> method definition -> Control -> startup method
X Execute method immediately after monitoring segment start
X Only on central instance
Save the configuration.
Solution
The following applies for methods not provided in the SAP standard system:
Most RFC problems in the monitoring area (RZ20) can be solved by changing the configuration for the data collection methods and startup methods concerned.
1. To find out which data collective method generated an RFC error message, an RFC trace must be generated on the host on which the RFC syslog messages occur. For more information about this, see note 176277.
In transaction SM50, activate the trace for dialog processes until the error message has occurred in the syslog again. The syslog displays the affected work process (for example, dev_w0) and the related dev_rfc* (dev_rfc0) file displays the RFC initiator.
2. In some cases the RFC initiator in the dev_rfc file is a report or function module that is directly entered as a method in
RZ21-> Method definition
In other cases, only a where-used list for the RFC initiator leads to a method in RZ21. The following always applies:
3. You can always specify which host is to be used to execute the method.
RZ21 ->
Method definition
 -> <Display/Change>
 -> Control -> Execute Method
 Execution -> Execute Method on
Check whether for your site method (local server,
any server, etc.) and execution type (dialog or background) are set in such a way that in the case of RFC calls (if the method uses these) no authorization problems arise.
4. As of Release 4.6B
You can also specify an executing server for startup methods.
RZ21 ->
Method definition
 -> <Display/Change>
 -> Control -> Startup Method
 -> Execute Location of Startup Method.
Check to see whether this configuration is correct.
Up to Release 4.5B: (The problem is corrected as of Release 4.6B.)</>
CAUTION: Here, it is not yet possible to specify the application server to be used to execute a startup method.
In particular, methods that run as data collectors in the background, if they are simultaneously startup methods, are also executed once in the dialog during the system restart. This once-off execution in the dialog occurs on an any server (cannot be specified). If the startup method was unsuccessful, it is restarted the next time you start the interactive dispatcher (after 5 minutes).
! This means that even a method that should !
! actually run in the background, writes RFC !
! error messages in the Syslog every 5 minutes !
Possible workaround.
- Remove the startup indicator for this method
- For all application servers, delete the node
CCMS Selfmonitoring
 -> MoniInfra<AppServer>
 -> Tooldispatching (short running tasks)
 -> STARTUP<XXXXXX>
that was created for the method affected (name of the method in the long text).
- Start the method manually (Transaction SE38 or SE37).
This bypasses the startup mechanism that causes the RFC error messages
P.S award the points
Thanks
Saquib Khan

CALL_FUNCTION_SIGNON_REJECTED

Similar Messages

Maybe you are looking for