This chapter describes known problems and restrictions in using the MessageQ Client for Windows Versions 4.0A and Version 3.2.
The MessageQ Client for Windows sets specific limits on MessageQ function parameter values that allow very large arguments on MessageQ server systems. The limits for the function parameters reduce the size for request and response messages between the client application and the remote Client Library Server (CLS) running on the MessageQ server group.
The limits implemented for the functions indicated are the following:
In all other respects, the MessageQ function calls implemented on the MessageQ Client are identical to the MessageQ functions on any other platform.
The import library (dmqcl32.lib) is not compatible with the Borland C++ linker. Attempting to build an application with this file will result in the following error:
Bad object file `dmqcl32.lib'
This can be corrected by using the Borland IMPLIB utility to create a compatible import library. For example, set you default directory to the \MessageQ\lib directory and use the following commands:
copy dmqcl32.lib dmqcl32.sav
IMPLIB dmqcl32.lib ..\bin\dmqcl32.dll
Include the new dmqcl32.lib in your Borland C++ project. Add the \MessageQ\include directory to the Include directories and \MessageQ\lib directory to the Lib directories specified in the Project Options.
When a client application crashes or terminates without calling pams_exit or pams_detach_q the TCP/IP connection to the CLS remains open (running the netstat utility shows the TCP/IP connections to the remote server still open). This open connection occurs more frequently with Visual Basic applications than with Windows applications developed in C/C++. Applications in C/C++ that crash suddenly appear to allow the network stack to reset the network connection which notifies the CLS that the client has terminated.
If the client application attaches to temporary queues, the CLS processes must be stopped manually. The Version 3.2 (and earlier) CLS supports same client reconnect to a permanent queue. If the client application uses permanent queues, they will be able to reconnect and the previous CLS process will terminate. See the description of 'Recovering from Client Crashes' in the Troubleshooting section of the MessageQ Client for Windows User's Guide for more information.
The "same client reconnect" logic will be removed from the Version 4.0A CLS. Visual Basic applications should use one of the techniques to prevent attach problems from VB run mode.
Visual Basic allows application developers to run the application interactively and pause or stop the application at runtime to switch back to design mode. Applications that initiate a MessageQ attach operation at runtime (typically during a form load event) will leave a TCP/IP connection open to the CLS when the developer uses the Visual Basic stop button to switch back to design mode.
There are a few techniques to limit creating lots of open TCP/IP connections while debugging in Visual Basic. The following suggestions provide a way to avoid this problem:
pams_exit as the initial MessageQ operation in the Form_Load event. This closes any open connections to the CLS. Custom control users can use the DetachQAction. Refer to the dmqfrmvb.vbp or dmqccsam.vbp Visual Basic sample programs.
The Minimum Packet Protocol requires the server platform to be running MessageQ for UNIX or MessageQ for Windows NT, Version 3.1 or later. MPP is not currently supported by MessageQ for OpenVMS.
The MessageQ Client for Windows Security Utility requires MessageQ for UNIX or MessageQ for Windows NT, Version 3.1 or later. MessageQ for OpenVMS, Version 4.0 or later supports CLS security.
The multi-threaded CLS for OpenVMS does not support attaching to permanent primary queues by name or number. However, it is possible to attach by name or number to an un-owned secondary queue when using the CLS in multi-threaded mode.
The CLS must be run in single-client mode if you need to attach to primary queues by name or number. Refer to the MessageQ Installation and Configuration Guide for OpenVMS for more information.
On Windows 95, the Event Watcher utility, Formatted messages of any length can be logged to the message trace file, Visual Basic Version 4.0 (32-bit) programs may have problems transmitting or receiving messages which consist of user-defined types. This is because VB Version 4.0 (32-bit) uses DWORD alignment (4-byte) for user-defined types, adding padding if necessary.
Note that this UDT alignment issue applies only to Visual Basic V4.0 (32-bit). All 16-bit versions of Visual Basic use byte-alignment for UDT's, so padding is not added.
The only data type guaranteed to be instantiated and passed without extraneous padding is a byte array. However, Visual Basic does not provide a built-in mechanism for copying data between byte arrays and user-defined types.
A workaround to the problem of copying between byte arrays and user defined types (UDTs) can be implemented using a combination of temporary data types, LSet, and explicit byte-by-byte copies. The following sample code shows how this can be done for a UDT consisting of an SBS registration message. If you have problems with padding in user-defined types, contact Microsoft Visual Basic Technical Support at (206) 646-5105.
When using DECnet from PATHWORKS 32 V7 an error occurs when the network connection is closed. The shutdown and closesocket functions fail with WSAEINPROGRESS even though no blocking operation is active. This prevents internal DECnet buffers from being released. After several attach/detach cycles, connection attempts will fail with WSAENOBUFS.
This is a known problem with PATHWORKS 32 V7.
The implementation of the Minimum Packet Protocol (MPP) uses a hidden Windows helper process, The restriction in the use of MPP with Netmanage is caused by the product's inability to allow different Windows tasks to share access to Windows sockets. In the MPP implementation, DMQAYSNC receives asynchronous data from sockets that the primary client task uses for sending requests. However, the standard request/response protocol works properly with Netmanage Chameleon.
PATHWORKS Version 4.1B for Windows NT does not support Win16 applications using DECnet. Only 32-bit DECnet applications are supported. Attempting to run 16-bit DECnet applications may cause the Win16 subsystem to become unstable.
In addition, PATHWORKS Version 1.0 for Windows 95 does not provide a 32-bit Windows Sockets DLL to support DECnet. Only 16-bit DECnet applications are supported.
Client applications must be attached to a queue before calling the Client applications must be attached to a queue before calling the Automatic timer-based reconnection does not work on Windows 95 with V3.2. This restriction is due to a problem handling a timer callback function. Use of timer-based reconnection will result in an error which generates the following message:
Timer-based reconnection works properly on Windows NT and Windows 3.1.
MPP Requires MessageQ for UNIX or Windows NT Version 3.1
Security Utility Requires MessageQ for UNIX or Windows NT Version 3.1
Attaching by Name or Number Using the OpenVMS CLS
Event Watcher Message Length
dmqwatch.exe, fails to display messages greater than approximately 256 bytes in length. The Event Watcher displays messages of any length on Windows NT; however, displaying messages over 1000 bytes in length may negatively impact system performance.
dmqtrace.log, under both Windows 95 and Windows NT. This file can be printed or viewed with a text editor such as Wordpad.
Visual Basic V4.0 (32-bit) User-Defined Types
' Visual Basic Version 4.0, 32-bit example to show the copy of a user defined
' type (UDT) to and from a byte array, omitting alignment padding bytes present
' in the UDT. Note that this is not necessary and should not be done in Visual
' Basic Version 4.0, 16-bit or Visual Basic Version 3.0.
' SBS registration message
Type SBS_Reg_Long_Form
Version As Integer
MOT_Addr As Integer
Distribution_Q As Long
Offset As Integer
Operator As Byte
Length As Integer
Operand As Long
Req_Ack As Byte
Req_SeqGap As Byte
Req_AutoDereg As Byte
End Type
#If Win32 Then
' SBS registration message sized temporary byte array (INCLUDING padding)
Type SBS_Tmp
byt(23) As Byte
End Type
' SBSRegToByteArray()
'
' Copy SBS registration message to a byte array
'
Sub SBSRegToByteArray(sbs As SBS_Reg_Long_Form, byt() As Byte)
Dim tmp As SBS_Tmp
' Use LSet to copy the SBS registration message to the
' temporary byte array.
LSet tmp = sbs
' Copy the temporary byte array to the return byte array,
' skipping pad bytes.
byt(0) = tmp.byt(0) ' Version
byt(1) = tmp.byt(1) ' "
byt(2) = tmp.byt(2) ' MOT_Addr
byt(3) = tmp.byt(3) ' "
byt(4) = tmp.byt(4) ' Distribution_Q
byt(5) = tmp.byt(5) ' "
byt(6) = tmp.byt(6) ' "
byt(7) = tmp.byt(7) ' "
byt(8) = tmp.byt(8) ' Offset
byt(9) = tmp.byt(9) ' "
byt(10) = tmp.byt(10) ' Operator
' pad
byt(11) = tmp.byt(12) ' Length
byt(12) = tmp.byt(13) ' "
' pad
' pad
byt(13) = tmp.byt(16) ' Operand
byt(14) = tmp.byt(17) ' "
byt(15) = tmp.byt(18) ' "
byt(16) = tmp.byt(19) ' "
byt(17) = tmp.byt(20) ' Req_Ack
byt(18) = tmp.byt(21) ' Req_SeqGap
byt(19) = tmp.byt(22) ' Req_AutoDereg
End Sub
' ByteArrayToSBSReg()
'
' Copy a byte array to a SBS registration message
'
Sub ByteArrayToSBSReg(byt() As Byte, sbs As SBS_Reg_Long_Form)
Dim tmp As SBS_Tmp
' Copy the input byte array to the temporary byte array,
' skipping pad bytes.
tmp.byt(0) = byt(0) ' Version
tmp.byt(1) = byt(1) ' "
tmp.byt(2) = byt(2) ' MOT_Addr
tmp.byt(3) = byt(3) ' "
tmp.byt(4) = byt(4) ' Distribution_Q
tmp.byt(5) = byt(5) ' "
tmp.byt(6) = byt(6) ' "
tmp.byt(7) = byt(7) ' "
tmp.byt(8) = byt(8) ' Offset
tmp.byt(9) = byt(9) ' "
tmp.byt(10) = byt(10) ' Operator
' pad
tmp.byt(12) = byt(11) ' Length tmp.byt(13) = byt(12) ' "
' pad
' pad
tmp.byt(16) = byt(13) ' Operand tmp.byt(17) = byt(14) ' "
tmp.byt(18) = byt(15) ' "
tmp.byt(19) = byt(16) ' "
tmp.byt(20) = byt(17) ' Req_Ack tmp.byt(21) = byt(18) ' Req_SeqGap tmp.byt(22) = byt(19) ' Req_AutoDereg
' Use LSet to copy the temporary byte array to the
' return SBS registration message.
LSet sbs = tmp
End Sub
#End If PATHWORKS 32 V7 shutdown and closesocket errors
Known Problems with the MessageQ Client for Windows Version 3.2
MPP Incompatible with NetManage Chameleon TCP/IP
DMQASYNC.EXE, to respond to asynchronous Windows Sockets events. Although this architecture works well with PATHWORKS TCP/IP, Microsoft TCP/IP, and others, it does not work with the Netmanage Chameleon TCP/IP product.
DECnet Limitations on Windows NT and Windows 95
Client Must be Attached Before Calling the pams_locate_q Function
pams_locate_q function. Failure to do so will result in a return status of PAMS__NOTDCL.
Client Must be Attached Before Calling the pams_status_text Function
pams_status_text function. Failure to do so will result in a return status of PAMS__FAILED.
Timer-Based Reconnect on Windows 95
"This program has performed an illegal operation and will be shut down."