Conference pamsrc::decmessageq

    
    when you say a VMS server you mean a VMS web server ?  as
    in you are doing the attach on the VMS side of the connec-
    tion ?  is your extension linked against the correct  ver-
    sion of the VMS software ?  is the  VMS  group  running ?
    have you considered turning on logging/tracing ?
    
    _sjz.

    
    Have you tried starting DMQ prior to starting IIS? Just curious as I
    had problems with pams_get_msg hanging when clalling DMQ from ISAPI and
    NSAPI unless I started DMQ first (ie: as a service on system boot). At
    first I thought the problem was the MFC and MSCRT DLLs but using the
    DLLs that ship with the DMQ kit didn't fix the problem.
    
    Alan 

sjz.  Im using NT DMQ which has a cross-group connection to
      commumicate to a VMS-based group, but I am attaching to 
      to PC DMQ.
      The client runs on the PC and the server on the VMS side.
      THis works perfectly as a VC++4.0 console-based application.
  B.

I'm helping Brian look at this problem. Just to
clarify the response to sjz's question slightly:

The Windows NT PC is the DMQ client, and is also
running MS's IIS v2.0 HTTP server. The DMQ client
requests are made from an ISAPI DLL. The DMQ
server is on VMS. There's no HTTP server on the VMS
system.  Using the ISAPI DLL version of Brian's DMQ
client code, the IIS server hangs as soon as he
attempts a DMQ attach. This causes the browser clients
(either Netscape or MSIE) to report a 'peer has reset
connection' error.

Brian has a separate Windows NT DMQ client application
which performs the same functions but is a console app. 
rather than an ISAPI DLL. This works correctly against
the same VMS DMQ server used above. Also, the ISAPI DLL 
version of the DMQ client which crashes IIS works
with the EYESAPI freeware utility for testing ISAPI
DLLs. We're not quite sure what EYESAPI does, but presumably
it partially simulates IIS. 

Alan, I presume from your reply that you're successfully
doing at least an attach and a get_message from within
an ISAPI DLL ? Is there any chance you might have a
simple working code sample that we could compare with our 
non-working code ? 

Regards,
Grainne Ni Choiligh @ILO

    
    So it  is a Client Library  Application.  Given
    that, I gracisouly bow out to my co-workers who
    are much  more likely to  provide a real answer.
    My guess is somebody initializing  winsock  mul-
    tiple times (or something like that).
    
    However,  we are currently  having  our  yearly
    engineering meeting (last one was two years ago)
    and the people responsible for the  client  lib-
    rary are travelling.  They may not  be able  to
    answer  your  questions  until Friday or Monday.
    
    _sjz.

    
    I'm not sure as to whether it is a CLS client, or simply the client
    part of a client-server application.
    
    I do know that Gary Burch in the UK has used DMQ sucessfully from within
    an ISAPI extension.
    
    I've just spoken with Brian on the 'phone, and suggested making sure
    that the bus and group ID environment variables were defined at the
    system level.
    
    If it is indeed using the CLS, then I believe there is an INI file that
    needs to be in the path of the IIS.
    
    Unless you spin off a background "worker thread" that stays permanently
    attached and performs DMQ calls on behalf of other threads, you will
    need to perform an attach, send/get (as many times as you wish),
    followed by a detach, each time your extension DLL gets invoked by the
    Web Server, since you cannot be sure that the Web Server will re-use
    the same thread.
    
    Cheers,
    		/Damian

    
    I mentioned the use of DebugBreak() to pop up the debugger inside your
    DLL.  This will work for ISAPI Filters, but the Web Server seems to
    trap the interrupt for Extensions.
    
    Instead, check out
    	http://www.valley.net/~tpozzy/iisvcdb.html
    
    
    	Cheers,
    		/Damian

    With the client library, you don't specify bus and group environment
    variables.  Perhaps his client was using the runtime library and
    attached to a group running on the same NT box?

    
    Brian phoned me yesterday and they are using the DMQ for WNT product
    (not the Client Library). But their ISAPI DLL was being built as a
    single threaded DLL - the /MD switch was missing.
    

    
    RE: .6 (Damian's note on thread context).
    
    One useful approach is to only attach once per thread and leave the
    thread attached permanently. This gets over the cost of attach/detach
    for each http request.
    
    The DllEntryPoint is a very useful place to put the attach/detach code: 
    for DLL_PROCESS_ATTACH and DLL_THREAD_ATTACH do the attach and
    DLL_THREAD_DETACH call pams_detach_q. Also a very useful place to
    manage your thread local storage.
    
    Alan

    
    Um, err,  as far as I know (and I wrote "some" of the code).
    Each thread within the DMQ DLL for the Windows  NT  product
    gets its own context.  If thread A attaches queue  1,  then
    thread B cannot use it because it is owned by thread A.
    
    _sjz.

    
    I assume that Alan means that each thread attaches to a different
    queue (or a temporary queue).
    
    This means that a specific queue can not be allocated for each Browser,
    since you can not be sure that two requests from the same Browser will
    be handled by the same thread thread inside IIS, and thus the ISAPI
    extension will not be called by the same thread (and thus share the same
    queue).
    
    What are the chances of DMQ allowing threads to exchange DMQ contexts,
    so that a thread that is not attached could grab the DMQ context from
    another thread (perhaps identified by primary queue number), leaving
    the other thread un-attached?
    
    My guess is that the chances amount to a fairly round number.
    
    	/Damian