During startup of the XCOM started task, some of the messages include a string of blanks after the message ID. This happens even for messages with the same ID, as in the XCOMM0027I messages below. For example:
15.41.24 STC08038 XCOMM0027I XCOMTASK ESTAE ROUTINE HAS BEEN ESTABLISHED
15.41.24 STC08038 XCOMM0027I IPv4-SSL XCOMRANS ESTAE ROUTINE HAS BEEN ESTABLISHED
15.41.24 STC08038 XCOMM0806I IPv4-SSL STARTING XCOM TCP/IP SSL LISTENER
15.41.24 STC08038 XCOMM0027I XCOMRANQ ESTAE ROUTINE HAS BEEN ESTABLISHED
Is this normal or does it indicate any problem?
Other messages show additional information which is not mentioned in the message description in the manual. For example:
15.44.01 STC08038 XCOMM0300I XCOMI00 REQ#=001297 ID=SCHEDULE REQUEST # 001297 PROCESSED SUCCESSFULLY
15.44.01 STC08038 XCOMM0811I 192.nnn.nnn.nn #001297 XCOMJOB STARTING SECURE TCP/IP CONNECTION TO PORT=08045, IP=192.nnn.nnn.nn
What does it mean?
Release : 12.0
Component : XCOM Data Transport for z/OS
The blanks are normal and do not constitute any problem. They are part of the so called 'message prefix'. For some messages, there are components of the message prefix which are not meaningful and are therefore left blank.
It may certainly look surprising to see two different formats for messages having the same ID as in the XCOMM0027I message issued during XCOM startup. This has a reason which is explained next.
In general, the format of XCOM for MVS messages depends on the combination of several factors:
The 'short message' API prints only the message ID and the message text as defined in the internal XCOM message table. For example:
15.41.24 STC08038 XCOMM0056I XCOM(tm) 12.0.01 (GEN LEVEL 2202) IS UP AND ACCEPTING LOGONS
15.41.24 STC08038 XCOMM0056I ON CPU 2965 SERIAL # 0BE177 IN 31-BIT MODE MVS SP7.2.4
15.41.24 STC08038 XCOMM0027I MAINTASK ESTAE ROUTINE HAS BEEN ESTABLISHED
The 'prefixed message' API edits the message text adding a prefix with information about the transfer to which the message is related (if any) or the circumstances under which the message is issued:
Some examples of prefixed messages would be:
15.41.24 STC08038 XCOMM0027I IPv4-SSL XCOMRANS ESTAE ROUTINE HAS BEEN ESTABLISHED
15.44.01 STC08038 XCOMM0300I XCOMI00 REQ#=001297 ID=SCHEDULE REQUEST # 001297 PROCESSED SUCCESSFULLY
15.44.01 STC08038 XCOMM0811I 192.nnn.nnn.nn #001297 XCOMJOB STARTING SECURE TCP/IP CONNECTION TO PORT=08045, IP=192.nnn.nnn.nn
Note the different formats of the message prefix depending on whether the message is related to TCP/IP or to SNA, as well as other variations.
Message XCOMM0300I relates to a XCOMJOB TYPE=SCHEDULE that established a SNA connection to the STC to schedule a transfer. The prefix shows the originating LU name (XCOM00), the request number assigned to the transfer (001297) and the transfer ID (in this case, 'SCHEDULE', which was set by XCOM)
Message XCOMM8011I relates to the processing of a TCP/IP transfer. In this case, the prefix contains the target IP address, the request number and the transfer ID (in this case, XCOMJOB, also set by XCOM). Note that this message shows a TCP/IP prefix as it is a TCP/IP transfer, even though the XCOMJOB TYPE=SCHEDULE job that posted the request had used SNA to connect to the STC and therefore produced a SNA prefix.
Message XCOMM0027I is issued by one of the TCP/IP listeners. In this case the IP address and the request number make no sense and are not included in the message. This causes the string of blanks.
The last variation is introduced by MSGFMT parameter in the XCOM defaults. It influences the format of prefixed messages and has no influence over short messages. The possible values are:
The sample prefixed messages above are produced with MSGFMT=STANDARD. The same messages produced with MSGFMT=XCOM would be:
15.41.24 STC08038 IPv4-SSL XCOMM0027I XCOMRANS ESTAE ROUTINE HAS BEEN ESTABLISHED
15.44.01 STC08038 XCOMI00 REQ#=001297 ID=SCHEDULE XCOMM0300I REQUEST # 001297 PROCESSE SUCCESSFULLY
15.44.01 STC08038 192.nnn.nnn.nn #001297 XCOMJOB XCOMM0811I STARTING SECURE TCP/IP CONNECTION TO PORT=08045, IP=192.nnn.nnn.nn
MSGFMT=STANDARD is the best setting if automation needs to be setup from XCOM messages. This is because it places the message ID in a fixed position which makes it easier to define the automation rules.
Also, when diagnosing a problem, XCOM support might ask to set MSGFMT=STANDARD and set a SLIP trap to capture an SVC dump when a given message ID is printed