Outside domain unable to connect to application server

Server version: Oracle HTTP Server Powered by Apache/1.3.19 (Unix)
The Operating System Level is: AIX 5100-05 ; Running Oracle 9ias

Problem:  One agency we have been supporting and maintaining their database has moved outside our domain but still requires access to the database within our domain but get this error: FRM-92050: Failed to connect to the Server: http://appserv2.ourdomain:7777/servlet/oracle.forms.servlet.ListenerServlet-1

We have another application Server version: Oracle-Application-Server-10g/ Oracle-HTTP-Server on AIX 5200-01 with Oracle 10gas which they are successful in connecting to.

We have modified the httpd.conf file to have the appserv2 name fully qualified with domain name attached at every reference of appserv2.

We have also done the same to formsweb.cfg and forms60_server.  These last two caused another agency, which is inside our domain to fail so we had to undo those changes.
We are at a loss at this time as to what needs changed or corrected on our side or on their side.
This system is a production system.
All suggestions will be greatly appreciated.
Who is Participating?
PAQd, 500 points refunded.

CS Moderator
This sounds more like a firewall problem.  Are you using a client proxy?
On your webserver, make sure the following ports are open


and give that a try.  If that doesn't work, you could try connecting in HTTPS mode.
slcoitAuthor Commented:
Everything is working fine through the firewall.
All ports are open.
I have now had success with a workaround by creating an entry in a local hosts table with the IP and the fully qualified domain name (FQDN).
This is just a workaround since it can create additional legwork if and when names or addresses change.
The proper way to resolve this issue would be to configure the application's hyperlinks to use the FQDN.  
Currently on our appserver that is failing, the initial screen uses the FQDN but when the next screen is called by the application, the domain name is left off the address and the applcation fails.  I do not know enough about the application and/or Apache to know what configuration file to insert the FQDN so that the application will automatically call it.  Our other appserver is using a newer Oracle and is inserting the FQDN automatically.  But since the two Oracles have different configuration file names, I cannot do a comparison to find where to make this entry.  I do not even know if it is a config file that needs this entry or if this is something that is totally handled by the application code.  Still need help. Thanks.
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

can you post the relevant parts of httpd.conf (the part you mention you changed to fully qualify the domain name)?
are any parts of the app using https/ssl? (the url you posted was http://)

your firewall needs to allow port 7777 (according your description)
nociSoftware EngineerCommented:
Googling for the error gives:

See note 116804.1 on metalink
(I have no account there, so I cant check).

Also if putting a name in the hostfiles does work,then please check your DNS
configuration. (resolv.conf pointing to valid DNS servers?)

If it a Name daemon is running, can it find the names?

What does 'dig appserv2.ourdomain' show?
slcoitAuthor Commented:
Our initial review of the situation indicated that the issue was not network related because the first home page request does in fact resolve to the proper server.  That is that DNS and network routing works fine and initially the failure appears to occur at the application level.  However, a number of forum articles reference firewall, DNS and routing errors as the cause.  In addition to our testing, our consultant was also briefed on the situation and his opinion was that the version of the OS and Oracle currently in use was not installed to allow for FQDN.  And it is not possible to modify this setting unless at the time of installation or upgrade of the OS, which is not possible unless the application was also upgraded.  Regardless of the cause we do have several solutions.  

Three solutions have been determined.  The first was that a local host file entry was added to the workstations requiring access.  The second solution was the OS and application be upgraded or reinstalled.  The third and easiest solution would be to modify the DCHP server on the the Court Admin Network to update each clients DNS suffix search list with both the cj19 domain name and the stlucieco.gov domain name.  This does not require a manual entry at each workstation but it would only apply to dynamic clients.  Those clients that have static assignments would still require manually entry of the DNS suffix search list.

Proceed for the time being with option 3 which includes the DNS suffix search list.  Future planning can be addressed to include FQDN to the application and OS.
> .. indicated that the issue was not network related  ..
Well, everyone might make her own definition if DNS is network related or not, but most people knowing what it is, would sort it to network problem though.

Anyway, what do you wantr to know now?
nociSoftware EngineerCommented:
Not network related and it is a DNS problem... hm contradiction?

If there is no IP network then there is absolutely no need for a DNS.

If there is an IP network DNS is optional, but managing the internet
through hosts files would be a pain....., think about having to
add www.google.com to your hosts files anytime you want to do a search.
And yes the server you used yesterday is in maintenace now and unavailable
for a while, so you have to update the hosts file again.... also for ANY
host you want to visit. And with just using ip numbers virtual hosting would
become quite a mess....., IMO DNS is network related.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.