on 02-17-2010 9:42 PM
I have recently restored a newly built Test server (stand alone Target) with a copy of a system (source) from a different network (meaning the 2 networks are totally seperate and can not connect to each other).
But when the standard background jobs "SAP_CCMS_MONI_BATCH_DP - RSAL_BATCH_TOOL_DISPATCHING" and "SAP_COLLECTOR_FOR_NONE_R3_STAT - RSN3_STAT_COLLECTOR" run, they do finish succesfully, but have system error messages "Operating system call gethostbyname failed (error no. 11004)" for each.
I've reviewed the trace record for that work process and find:
Wed Feb 17 16:09:26 2010
***LOG Q0I=> NiPGetHostByName: hostname 'XXXXXX-906' not found: gethostbyname (11004: WSANO_DATA: Valid name, no data record of
ERROR => ThCPIC: NiHostToAddr failed [thxxcpic.c 1866]
RFC 1485 CONVID
CMRC=19 DATA=0 STATUS=0 SAPRC=497 ThSAPOCMINIT
RFC> ABAP Programm: CL_SLD_ACCESSOR===============CP (Transaction: )
RFC> User: DDIC (Client: 100)
RFC> Destination: SAPSLDAPI (handle: 1, , )
TH VERBOSE LEVEL FULL
RABAX: end RX_GET_MESSAGE
ERROR => ThCPIC: NiHostToAddr failed [thxxcpic.c 1866]
RFC 1485 CONVID
CMRC=19 DATA=0 STATUS=0 SAPRC=497 ThSAPOCMINIT
RFC> ABAP Programm: CL_SLD_ACCESSOR===============CP (Transaction: )
RFC> User: DDIC (Client: 100)
RFC> Destination: SAPSLDAPI (handle: 2, , )
TH VERBOSE LEVEL FULL
RABAX: end RX_GET_MESSAGE
It should be noted that the hostname 'xxxxxx-906' is a server in the source system that was used for CUA.
I've run "rsdelcua" to take the target server out of CUA.
I've deleted all of the Source system RFC entries.
I've deleted all of the source system entries out of tables RSWTTR02, ALCONSEG, SWNCMONI, SMNCMONIINDEX, SAPLSERV and the like.
I've made sure an empty line is the last line in the host file.
The system profiles are new and do not have references to any other (source system) servers.
I did copy the source system background jobs making changes to reference the Target system \ client, although the above mentioned jobs do not have variants that required it.
I'm stumped on this one. Does anyone out there have any suggestions?
OK For those who're interested, my work around was to go to the RFC destination SAPSLDAPI and delete the Gateway host from it, which was pointing to the xxxxxx906 server.
After re-running the background job, there are no more corresponding system error messages.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Eric
Thanks but, in this restored system, I don't have the SAP_SLD_DATA_COLLECT background job running. I was getting the error message when the SAP_CCMS_MONI_BATCH_DP and SAP_COLLECTOR_FOR_NONE_R3_STAT background jobs ran.
It should be noted that this system was created from a restore of a backup of a system that was in an SLD. Basically it may still think it's in the SLD, but the SLD has not knowledge of or connection to this server.
As mentioned above, the work around I found was to delete the Gateway Host server from the RFC destination SAPSLDAPI which had the SLD server entry due to the database restore.
I'm wondering if there is some sort of "Delete client from SLD" program that can be run in a similar fashion as "rsdelcua" works in the client system.
Ken
> I'm stumped on this one. Does anyone out there have any suggestions?
I would
- start transaction SM36
- click on "standard jobs"
- delete all the jobs in the grid
- click on "default scheduling"
This will reschedule all the monitoring jobs with proper variants.
Markus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Markus
Unfortunatey recreating the background jobs has not stopped my system error message produced from the "SAP_CCMS_MONI_BATCH_DP" background job.
But I believe I have found where (or why) I'm getting this error from.
What I can figure is that the SLD was activated on the Source system, where the SLD server is xxxxxx906 (checked in transaction RZ70). As the target server is not hooked into the source system network and can not reach the SLD server, the "NiPGetHostByName: Hostname 'xxxxxx906' not found" error is produced.
So... Is there a way to shut down the (source system's) SLD on this (the target) stand alone system or do I just forgot about the error produced by this background job? The only thing I have found so far on the internet is information on how to set it up, not how to de-activate it.
Ken
Thanks Eric
There doesn't seem to be a "De-activate" selection in RZ70. I have even tried deleting all of the entries, (for example the SLD Bridge - Host) and de-selecting the Data Collection Programs.
But still get the error when re-running the SAP_CCMS_MONI_BATCH_DP background job. It's still trying to find the "xxxxxx906" host.
Do you kknow the consequences of not scheduling the SAP_CCMS_MONI_BATCH_DP background job?
Ken
Thanks Bhavik
I appreciate the advice, Yes I have similar system messages, although in this instance I've restored this stand alone system from a backup of a system that resides in an isolated network with NO connection between the 2 systems (source - target). Although it is somewhat of a Log on issue, I wont be able to resolve it by correcting the RFC connections ( systems are isolated and can not connect).
I had previuously check Note 992538, and found that all of the segements found in RZ21 are related to the new system with no references to the source (xxxxxx906 server).
I hoping that de-activating the legacy system SLD in this target system, although it has never been activated for this specific server in the first place, will solve my problem.
Ken
User | Count |
---|---|
84 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.