Conference ucrow::desktop_acms

824.0. "Acmsdi_srvdead, multiple exes, same submitter??" by KERNEL::PULLEY (Come! while living waters flow) Tue Feb 18 1997 11:29

Hi,

I've a customer using ACMSdi v2.2, Windows 95 with Microsofts TCP/IP stack,
using Visual Basic v3, connecting to a VAX.
He has multiple executeables using same submitter id.
Did work on Windows v3.1, but I'm not even sure if that was with IP.
So I think this does look similar to other notes like 651 & 572 ...

Now, I think they did have it not working using reflections IP stack and
using Windows 95, but the reflections winsock has ben changed & they tell
me it works.

The errors they get in the acmsdi.log on Windows 95 using Microsofts IP--
after they called a couple of tasks, so it may well be the first in anotehr
.exe--are:-
NET__CLIREAD: TCP/IP(10093), TCP/IP error
NET__CLIDIS: TCP/IP(10093), TCP/IP error
READ_TCPIP_MESSAGE: RPC(38), Client disconnected
RPC__CALL: RPC(38), Client disconnected
ACMSDI_CALL_TASK: ACMSDI(-3020), ACMS Desktop Server or network link terminated

The customer reckons, if he can get Microwsoft to make a similar change to
the reflections folks, in their winsock, that is applications will work,
but reading those notes, it didn't seem as clear as that.

So, if he needs workarounds, and shouldn't be going anywhere near this, what's
DDE and OLE, as they were mentioned during possibilities in about 651.8?
That note also seemed to suggest it might be good if this did succeed,
without the need for workarounds, because customers often ask for it, even
though ACMS Desktop may not have been designed with it in mind.
Is there any change in that situation, or did I read it wrong anyway?

Thanks for any comments/suggestions,
Steve.

    Steve,
    
    The ACMS Desktop V2.3 field test update kit should go out to signed up
    sites the end of next week. It will include an extension to work around
    this problem for Windows 3.1 clients using TCP/IP - 16 bits. It will
    also be tested  with Windows 95 running 16 bit applications but no 32
    bit implementation is planned. If they are interested in field testing
    they should sign up soon because limited number of kits and
    documentation will be made available, there might still be time. 
    Winsock V1.1 standard does not provide for multiple tasks sharing a
    connection, but individual implementations might allow it. Sounds like
    the reflections stack is allowing it. The above mentioned workaround is
    for the ACMSDI DLL to start up a separate task and route the TCP/IP I/O
    through it, on behalf of the various .EXEs trying to share the connection.
    There are no changes needed to the customers application code.
    
    Tom