The 7.0 version of QTerm brings a new look and easily accessible function panels which
can be permanently displayed (pinned) or can be automatically hidden and only displayed when
moused over. Mutiple frame windows are also supported with one or more terminal windows in each frame. This allows you
to easily take advantage of multiple monitors.
If you are interested in trying out the new version please click here to download the software
Click New to close.
The INT1 DataPort is an AccessServer port type that supports multiplexing of numerous host connections to one user program connection.
The user program connection is via TCP/IP, known as a Client connection, Data messages sent over the Client connection are in Uniscope data format with a header that identifies the individual multiplexed user connection.
The job of the INT1 DataPort is to create and manage a full INT1 session over TCP/IP to the 2200/Clearpath host system for each of the multiplexed connections.
For a list of error codes see the faq page.
The graphical interface is used to display configured information and the real time status of running objects. When running the AccessServer as a service this visual information is not available but can be viewed with the QMC management console program.
The user interface is principally point and click. You can add new configurable items, such as ports and hosts, and stop and start running entities. You can delete configured items and dynamically created items, such as Clients and users.
To redisplay current information, click on the refresh button on the toolbar.
Each INT1 DataPort is a listening port has one or more destination hosts. A listening port is configured to accept connections from user programs and then process messages sent over the tcp connection. Each user program connection is referred to as a Client. Each message level connection is referred to as a user. Therefore we can have many user connections over each Client connection.
To add an item, select the parent, such as INT1 DataPorts and click on the Add button on the toolbar or use a right mouse click to display a popup menu with the add command.
To delete an item select the item, such as port, and click on the Delete button on the toolbar or use a right mouse click to display a popup menu with the delete command. Note that you can delete dynamic items such as a client or a user. Deleting any item also deletes all child items, both configured and dynamic. For example, deleting a port deletes all hosts, all clients and all users, deleting a client deletes all child users.
Stop and Start
Stopping a Port simply stops it from listening for new connections. It does not stop any messages on existing client/user connections.
Stopping a Client prevents messages from all users of that client being processed, but any messages received from the host will still be sent back to the client. Starting a Client allows messages from the client’s users to be processed.
Stopping a User discards all messages received from the particular client and sends a reject back to the client for each message. Messages from the host will still be sent back to the user. The reason that the input is discarded is that a message has to be read before it can be decided which user sent the message, only then can it be determined that the user has been stopped.
Message counts are displayed for users, clients and ports. The counts are held as 32 bit integers so they can get very large but, at some time, they will wrap around to zero. Therefore, there may be some apparent disparity between input and output message counts.
The port status also displays message
rates, as messages per second. The
calculations are performed over the interval between clicking the refresh
Message Level Interface
The message level interface describes a message format that is used to pass all messages to and from the dataport client. Each message comprises a buffer header and data area, both of which are contiguous. See the FAQ page on the Quickware web site (www.qw.com) for definitions of error codes.
The buffer header is a fixed length, fixed format header that is at the beginning of each message. The function descriptions show only the required buffer header fields for each function. Other fields may be filled in for debug/trace purposes but are not used by the interface. For example, the m_user1 and m_user2 fields could be filled in for each data message to assist in tracing.
The identifier fields are very important:
These fields are used to identify the connection in both directions, from the client to QAS and from QAS to the client.
The client provides the m_user1 and m_user2 identifiers in the connect packet when instigating a user connection. These values are remembered by the data port and returned on every subsequent message for that user.
Similarly, the m_connectionId is returned from the data port in the buffer header in a connect confirm message. The client should use this value in every subsequent message for that user.
Note: int=32 bits, word=16 bits, byte=8 bits. All non-byte fields are big-endian except for m_link and m_flags.
Function Descriptions (commands)
Description: Request connect to the host. The host and terminal details are provided in a null-terminated connect request string which begins at the data offset. The following connect flags are defined:
Description: Disconnect but do not return a disconnect confirm
Description: Disconnect and return a disconnect confirm.
Description: A message sent from the client to specify global parameter settings.
String of parameter values separated by commas
Description: A message sent from the client to register the associated application name. The message payload contains a string that identifies the registered client name which is subsequently used to match the host application on a connect request.
Description: Send a data message to the host.
Description: Send a function key to the host.
Description: Send MessageWait to the host.
Description: Provides completion status for the last message, which required acknowledgment, either because it contained a print invocation or the host required an Assurance Unit. If the status indicates an error condition an Assurance Unit is outstanding then an Assurance Unit Fail is sent to the host, else a device status is sent, if the host has indicated that it wants to receive device status messages.
Description: Request to turn on tracing of input/output messages, for all connections.
Description: Turn off tracing, for all connections.
Description: Turn on tracing of a specific connection
Description: Turn off tracing of a specific connection
Description: Turn on logging
Description: Turn off logging
Description: Set the path to the folder to be used for log files, provided in a null-terminated string beginning at the data offset.
Function Descriptions (responses)
Description: A message sent to the client requesting a connection. The message payload contains a connect string that identifies the device name and the requested host application name. The response from the client is to be either a fncConConf with the m_user1/m_user2 fields or a fncConRej. This gives the client application the opportunity to accept or reject the connect request.
Description: Indicates that the host connection has completed successfully. Note that the Connection id is being provided for the first time on this connection and must be included on every subsequent message from the client for this user.
Description: Indicates that the connect to the host failed.
Description: Indicates that the current connection to the host has been terminated, by the host or due to a network failure etc.
A message has been received from the host.
If either of the print or AU flags is set, then the user program must
subsequently send a Status message to indicate that the message processing has
completed. This enables the
corresponding indication to be sent to the host.
Description: A message wait has been received from the host.
Description: A function key has been received.
Description: A requested command from the user program is being rejected. The reason for the rejection is indicated in the result field.
Description: A data, function key or MsgWait message has been sent to the host. These messages are only sent if requested when the session is opened (see fncConnectPkt).
Please see the list of codes in the FAQ page.
In a TCP/IP environment flow control is exercised by the open and closing of tcp send and receive windows. It is to be expected at random times that a tcp window will close, due to traffic load and/or network congestion. This and other events, means exception conditions must be considered:
AccessServer supports the COM compliant Automation interface by which properties and methods of an individual object are exposed for programmatic control and enquiry. Where multiple objects of the same type are implemented, they are maintained as collections of objects. Conventional methods are used to access theses collections (Add, Remove, Item Count).
INT1 DataPorts Collection
INT1 DataPort Object