You can use the program interface on the side of the applications to be administered as a dedicated message interface. In this case, control of the administration functions lies entirely with the administration application. This application supplies the four areas needed for each administration call with the data they require and uses MPUT NT/NE to send it to the administered application.
The administered application merely converts the data supplied to the syntax required by the administration interface and then calls it. This means that it checks neither the data supplied with MGET nor the codes and data returned by the call. The diagram below outlines a program of this type.
/**************************************************************************/
/* Dialog program for the administered application */
/* */
/* The program has four buffers in which data is received: */
/* parameter_area, identification_area, selection_area, data_area */
/**************************************************************************/
INIT
MGET NT in parameter_area /* Fully supplied parameter area */
/* for the administration interface */
MGET NT in identification_area /* The identification area is */
/* supplied as a function of the */
/* opcode for the parameter area. */
MGET NT in selection_area /* The data supplied to the selection */
/* area depends on the operation and */
/* may only have the length 0. */
MGET NE in data_area /* Data is supplied where necessary; */
/* otherwise the length 0 is supplied */
KDCADMI (¶meter_area, /* The program calls KDCADMI without */
&identification_area, /* checking the data. */
&selection_area,
&data_area);
MPUT NT parameter_area /* Parameter area with the return */
/* codes and other returned data */
MPUT NE data_area /* Data area with returned data or */
/* the length 0 if no data is */
/* returned */
PEND FI /* Terminate service; info is returned*/
/* to the administration application */
The administration application has to send a commensurate number of message segments. In the case of a UPIC client, the result may look something like this:
/**************************************************************************/
/* UPIC program for the administration application */
/* */
/* The program sends four message segments */
/**************************************************************************/
Enable_UTM_UPIC
Initialize_Conversation
[Set_TP_Name] /* Set TAC if necessary */
Set_Conversation_Security_Type /* Sign on as a UTM user */
Set_Conversation_Security_User_ID
Set_Conversation_Security_Password
memcpy (...) /* Supply all data areas */
...
memcpy (...)
Send_Data parameter_area /* Send parameter area */
Send_Data identification_area /* Send identification area */
Send_Data selection_ara /* Send selection area */
Send_Data data_area /* Send data area */
Receive parameter_area /* Contains return codes/info */
Receive data_area /* Data area containing the */
/* requested information */
Disable_UTM_UPIC
For details of how to generate this kind of UPIC client, see "Administration via UPIC clients".
If the administration application is running on a different platform to the application being administered, the characters in the areas supplied may be converted. No problems will arise as long as these areas only contain printable characters, i.e. the identification, selection and data areas. In the parameter area (parameter_area), which can also contain non-printable characters and numeric values, you will need to apply a conversion mechanism.
Define an interim parameter area in both applications which only contains printable characters.
The administration application converts the characters in the original parameter area into printable characters, puts these in the interim parameter area and then sends this to the applications being administered.
The administered applications write the values received to the interim parameter area, convert them to the correct numeric values and then copy these to the parameter area used for the administration call.