Client code is a point-to-point connection with only one server, so destination identification is not necessary. Messages are exchanged with the server which accepted the socket connection request. As a result, there are fewer message formats on the client side.
The VM user ID where VM:Operator is running receives a message from some other VM user on the same system. The contents of text are sent to the server. The message may contain imbedded blanks. The data is delivered to the server for disposition, so the actual structure of the message data will be an installation standard with meaningful contents.
A special format of text allows any client to forward a message to any other connected client. When the first word of text takes on the appearance of a destination ID, the server will attempt to resolve the destination. If valid, the server code will treat the text data as if it originated from its global variable queue; that is, the destination ID will be stripped, and the remainder will be sent to that client. All methods of destination ID identification are permissible, except the broadcast '*'. Please note the receiving client cannot determine the original sender.
The client supports 2 commands:
The QUIT command or any of the candidate termination commands terminates client processing. The connection with the server is broken, and the server remains operational.
The health-check response is internally generated in response to a server probe, and not received through SMSG. PING exchanges are visible when the TRACE option is active.
The server returns either the WTO or GLV update return code to the issuing client as a message type REPLY.
Several examples follow. All are CP commands issued by a VM user on node SYSTEMC. CLIENTA on SYSTEMC is the VM user ID where the client resides.
SMSG CLIENTA Hi, MVS
SMSG CLIENTA CLIENTB@SYSTEMA: Report
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|