cancel
Showing results for 
Search instead for 
Did you mean: 

Operating system call gethostbyname failed (error no. 11004)

ken_halvorsen2
Active Participant
0 Kudos

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?

Accepted Solutions (0)

Answers (2)

Answers (2)

ken_halvorsen2
Active Participant
0 Kudos

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.

former_member204746
Active Contributor
0 Kudos

try deleting job SAP_SLD_DATA_COLLECT in SM37.

then, delete system in SLD

ken_halvorsen2
Active Participant
0 Kudos

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

former_member204746
Active Contributor
0 Kudos

maybe you could try to re-register your refreshed system in RZ70?

markus_doehr2
Active Contributor
0 Kudos

> 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

ken_halvorsen2
Active Participant
0 Kudos

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

former_member204746
Active Contributor
0 Kudos

check config in RZ70 on ABAP stack.

ken_halvorsen2
Active Participant
0 Kudos

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

former_member524429
Active Contributor
0 Kudos

Hi,

Please refer the following reference links with similar symptoms:

[|]

[Note 992538 - EarlyWatch Alert: gethostbyname failed (error 11004)|https://service.sap.com/sap/support/notes/992538]

Regards,

Bhavik G. Shroff

ken_halvorsen2
Active Participant
0 Kudos

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