Informix Connect Question -- sqlexecd
Posted in 1999
Topics: Connectivity: ODBC / JDBC / .NET, Networking & sqlhosts Configuration
I'm moving from an old version of Informix SE up to SE 7.24. We currently have ODBC connectivity to the old server by running the sqlexecd daemon. The problem is making it work on the new server. I have the following entry in my /informixdir/etc/sqlhosts file mega seipcpip mega sqlexec I have the following entry in my /etc/services file sqlexec 1530/tcp I'm not quite sure if I have to invoke the sqlexecd daemon like I used to on the older version of Informix, but when I try I get the following error: 1999-02-03 10:49:50.198342 daemon err = -25592: Communications service not supported by network driver. Can anyone shed some light on this? Jon Gjerset jwg@nuera.com
In article <36B89ADC.EF77D472@nuera.com>, Jon Gjerset <jwg@nuera.com> wrote: > > I'm moving from an old version of Informix SE up to SE 7.24. We > currently have ODBC connectivity to the old server by running the > sqlexecd daemon. The problem is making it work on the new server. I > have the following entry in my /informixdir/etc/sqlhosts file > > mega seipcpip mega sqlexec > > I have the following entry in my /etc/services file > > sqlexec 1530/tcp > > I'm not quite sure if I have to invoke the sqlexecd daemon like I used > to on the older version of Informix, but when I try I get the following > error: > > 1999-02-03 10:49:50.198342 daemon err = -25592: Communications service > not supported by network driver. > > Can anyone shed some light on this? > > Jon Gjerset > jwg@nuera.com > > I think your problem might be that you are trying to enable the sqlexecd daemon using using an unnamed pipe (PIP). If you want to enable remote or local loopback connections, you will have to start the sqlexecd daemon. Assuming you're starting the sqlexecd daemon with: '$INFORMIXDIR/lib/sqlexecd mega', Informix will find "mega" in the sqlhosts file and automatically try to associate the service name with a valid service in /etc/services. In your case it locates "sqlexec" and tries to establish sqlexecd to listen through port 1530 using TCP. Problem is, "mega" is configured as a local unnamed pipe connection (ie seipcpip). Sqlexecd cannot establish itself to listen on a port using PIP, hence the -25592 error. To enable remote connections, you will need to add another entry in your sqlhosts file specifying the tcp/ip protocol using either tli or soc as your network interface. You should also remove the sqlexec entry from /etc/services. Something like: mega_remote sesoctcp mega mega_soc and correspondingly in your /etc/services file: mega_soc 1530/tcp If you use tli rather than soc, change all occurrences of soc to tli. Start your sqlexecd daemon using: $INFORMIXDIR/lib/sqlexecd mega_remote. Hope this wasn't too confusing. Good luck, Bob -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <36B89ADC.EF77D472@nuera.com>, jwg@nuera.com says... > > >I'm moving from an old version of Informix SE up to SE 7.24. We >currently have ODBC connectivity to the old server by running the >sqlexecd daemon. The problem is making it work on the new server. I >have the following entry in my /informixdir/etc/sqlhosts file > >mega seipcpip mega sqlexec > >I have the following entry in my /etc/services file > >sqlexec 1530/tcp > >I'm not quite sure if I have to invoke the sqlexecd daemon like I used >to on the older version of Informix, but when I try I get the following >error: > >1999-02-03 10:49:50.198342 daemon err = -25592: Communications service >not supported by network driver. > >Can anyone shed some light on this? > >Jon Gjerset >jwg@nuera.com > The error is in the word "seipcpip" of the sqlhosts file. I just find the same error upgrading from SE 5.X to SE 7.23. In my system (Unixware 2.1.3) i have to change the old "seipcip" with the new "setlitcp". You have to read the "Release Information" in the directory $informixdir/release about your operating system / hardware. Bye Pierluigi P.