This turns out to be a very simple problem, although I haven't seen much
on the web about its resolution (only a whiff of a solution on IBM.COM)
- hence this rant.
I had problems with the plugin and IIS, but lots of people had it
working, so it couldn't be broken right?
Here's the skinny:
I had installed the plug in, but forgot that I'd upgraded from 4.0.1 to
4.0.6 - so I went back and installed the upgrade (but just the plugin -
after all I dodn't need a whole websphere install on my front of house
web server!). Although I had to select "Websphere Application Server" as
the upgrade, and did need a copy of Java on there, it went pretty well.
It figured out I only had the plugin installed. The later dlls have a
2003 date, rather than the 2001 I had from 4.0.1.
Then I copied over my plugins-conf.xml, and sure enough, everytime I
started IIS, the dll refused to load with 7e 00 00 00 in the event log.
I took out the https transport and it worked first time. Then I put on
the "TRACE" mode and put https back in. It gives an error (if you look
hard enough)
lib_security: initializeSecurity: Initializing... lib_security:
loadSecurityLibrary: In load security library ERROR: lib_security:
loadSecurityLibrary: Failed to load gsk library ERROR: lib_security:
initializeSecurity: Unable to load security library ERROR: ws_transport:
transportInitializeSecurity: Failed to initialize security
a quick check and IBM say something like 'your gsk*dll can't found
in win32'.
I ended up copying from the installed gsk5kit all of the dll's into
winnt\system32 and hey presto it worked just fine. http: & https: from
IIS into Websphere - using a plugin generated from another box, just
like its supposed to.
I would strongly recomend only using "TRACE" mode very briefly. Also be
sure to really stop IIS when monkeying with the dlls (the plugin dll's
that is) - you need to do this via the services panel or with "net stop
whatever".
Worked for me.
--
posted via MFF : http://www.MainFrameForum.com - USENET Gateway