Unisys Mainframe Connectivity including superior
Terminal Emulation 770-952-7635
Hits:
Hits:
QTerm 7.0The 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.
AccessServer Int1Dataport |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DescriptionThe 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. OperationThe 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. AddTo 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. DeleteTo 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 StartStopping 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 CountsMessage 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
button. Message Level InterfaceDescriptionThe 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. Buffer HeaderThe 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: · m_connectionID · m_user1 · m_user2 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)
Function: fncConnectStr 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:
Buffer Header:
Connect String: termName,termType,rows,cols,hostname[,appName,IPadr,port,transport,csuName[,conTimeout,localIPadr]] e.g. TERM01,4,24,80,ResHost TERM02,0,0,0,ResHost TERM03,0,0,0,ResHost,TIP,1.2.3.4,102,T,tipcsu,30,1.2.3.4
Function: fncDiscAbort Description: Disconnect but do not return a disconnect confirm Buffer Header:
Function: fncDisconnect Description: Disconnect and return a disconnect confirm. Buffer Header:
Function: fncParams Description: A message sent from the client to specify global parameter settings. Buffer Header:
Parameter String: String of parameter values separated by commas Parameter List
Function: fncRegister 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. Buffer Header:
Connect String: appName e.g.ResHost
Function: fncSend Description: Send a data message to the host. Buffer Header:
Function: fncSendFKey Description: Send a function key to the host. Buffer Header:
Function: fncSendMsgWait Description: Send MessageWait to the host. Buffer Header:
Function: fncStatus 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. Buffer Header:
Function: fncTraceOn Description: Request to turn on tracing of input/output messages, for all connections. Buffer Header:
Function: fncTraceOff Description: Turn off tracing, for all connections. Buffer Header:
Function: fncTraceConnectionOn Description: Turn on tracing of a specific connection Buffer Header:
Function: fncTraceConnectionOff Description: Turn off tracing of a specific connection Buffer Header:
Function: fncLoggingOn Description: Turn on logging Buffer Header:
Function: fncLoggingOff Description: Turn off logging Buffer Header:
Function: fncLoggingFolder Description: Set the path to the folder to be used for log files, provided in a null-terminated string beginning at the data offset. Buffer Header:
Function Descriptions (responses)
Function: fncConnect 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. Buffer Header:
Connect String: termName,appName e.g. TERM01,ResHost
Function: fncConConf 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. Buffer Header:
Function: fncConRej Description: Indicates that the connect to the host failed. Buffer Header:
Function: fncDisconnected Description: Indicates that the current connection to the host has been terminated, by the host or due to a network failure etc. Buffer Header:
Function: fncRcv Description:
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. Buffer Header:
Function: fncRcvAttention Description: A message wait has been received from the host. Buffer Header:
Function: fncRcvFKey Description: A function key has been received. Buffer Header:
Function: fncReject Description: A requested command from the user program is being rejected. The reason for the rejection is indicated in the result field. Buffer Header:
Function: fncSent 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). Buffer Header:
Reject Codes Please see the list of codes in the FAQ page.
Exception ConditionsIn 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 AutomationDescriptionAccessServer 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
Clients Collection
Client Object
Users Collection
User Object
Hosts Collection
Host Object
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
