Winsock error loading httpstk.nlm
Running Netware 6.5 sp1. Upgraded to NICI 2.6.7 and applied SECUPD7 (PKI 2.7.5, etc.)
Now httpstk.nlm won't load. Message:
Error accessing WinSock Services, ccode = 0x273B
(10043)
I tracked down the error code and it's defined as follows:
Protocol not supported. Either the requested protocol is not installed on the system or no implementation exists for it. For example, if TCP/IP is not installed on the system, attempting to create either a TCP or a UDP socket will generate this error.
Questions: What protocol is not supported/installed? How do I find out? Most importantly, how do I fix it?!
Now httpstk.nlm won't load. Message:
Error accessing WinSock Services, ccode = 0x273B
(10043)
I tracked down the error code and it's defined as follows:
Protocol not supported. Either the requested protocol is not installed on the system or no implementation exists for it. For example, if TCP/IP is not installed on the system, attempting to create either a TCP or a UDP socket will generate this error.
Questions: What protocol is not supported/installed? How do I find out? Most importantly, how do I fix it?!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Honestly, no, if PKIDIAG did not report any problems, I would tend to doubt it was the source of the fix. It just eliminated one possibility and let you concentrate on others.
Sounds to me like it was more of a timing issue, like the TID I cited (#10073617) suggested.
In any event, I'm glad to hear its working. Assign a grade as you think proper.
Sounds to me like it was more of a timing issue, like the TID I cited (#10073617) suggested.
In any event, I'm glad to hear its working. Assign a grade as you think proper.
ASKER
The problem is solved - but I don't know how! After working on this problem all Friday night and early Saturday morning, I shut down the server and went home for some sleep. HTTPSTK was not working at this time. Before shutting it down, I edited the autoexec.ncf file so that nothing but the topmost commands (setting time, server name, etc.) were executed. After bringing the server back up Saturday afternoon and reading your message, I ran PKIDIAG. It found no errors. So I tried HTTPSTK again just for kicks - and it worked! I don't know if running PKIDIAG, even though it didn't find errors, did something magic, or the fact that nothing else was loaded played a part.
There was another problem I was dealing with that I don't think was related (it persisted even after I got HTTPSTK working), but just in case, I'll record it here for posterity. My original autoexec.ncf loaded the security modules in the following order (the same as recommended in the TID #10073617 you suggested):
LOAD NICISDI.XLM s
LOAD SASDFM.XLM
LOAD SAS.NLM
LOAD PKI.NLM
LOAD NILE.NLM
.
.
(load all other stuff)
.
.
(end of AUTOEXEC.NCF)
LOAD HTTPSTK.NLM /SSL /keyfile:"SSL CertificateIP"
LOAD PORTAL.NLM
Unless I executed the first set of commands manually, loading the very next command after NILE.NLM - whatever that command might be - locked the system. I finally tracked down Novell TID #10082078 which stated the version needed and recommended the following load order:
Load NILE.NLM
Load HTTPSTK.NLM /SSL /keyfile:"SSL CertificateIP"
Load PORTAL.NLM
LOAD NDSIMON.NLM
LOAD NICISDI.XLM s
LOAD SASDFM.XLM
LOAD SAS.NLM
LOAD PKI.NLM
This still failed. It appeared that GAMS.NLM, autoloaded by NILE.NLM, wasn't getting loaded before the next command was executed. Also, TID #10060090 (though an old one) indicated that there was a timing issue between Java (which was loaded previously) and NILE.NLM. So I put in a 60 second delay before and after loading NILE.NLM. That's probably overkill, but by that time I was tired and just wanted to go home! Now my server is a happy camper.
PsiCop, I'll accept your answer. If you think that running PKIDIAG fixed the problem, even though it turned up no problems, I'll give you an A; otherwise, a B. I'll wait to hear from you on this before I close the problem.
Thanks!