This guide is for logs that were collected with the default logging options. If you have changed the logging options, your logs may have more or less information in them.
Rach log file begins with information about CIUMon's settings. If CIUMon was stopped and started while log file was being created, there will also be settings information in the middle of the log file.
After the settings information is the data. Remember that many logs begin while CIUMon is already getting data, so some requests may be partially in the log you are looking at and partially in the previous log or the next log.
Each line of logged data looks like this:
timestamp letter data
For CIUMon requests, the letter starts at
Z and counts downward, so that
timestamp Z is the first line of the request,
timestamp Y is the second line, and so on.
For responses, the letter is incremented between lines of the same entry, so
timestamp A is the first line of some entry,
timestamp B is the second line, and so on. If a single entry has more than twenty-six lines, the last lines will all be marked with
The data is either a sequence of bytes sent to or from the CIU (in hex), or a human-readable description of what is being sent to or from clients (eg Hyperview).
The following sequences of bytes have special meaning:
||End of line|
Any time you see
1B in the log, it is part of one of the above sequences.
Most of the communication from CIUMon to the CIU will begin with either
50 (fetch data),
67 (bulk fetch data from RoviSys Turbo),
19 (send fetched data), or
45 (environment fetch). The responses from the CIU generally begin with either
01 (request acknowledged) or
00 (ok, sending data). Some of the other possible messages are explained in How does CIUMon respond to errors?.
When "Alex" sends a request for a piece of data, it gets recorded in the log like this:
14:15:49.781 A read output 2 03 04 5 from IP Address 127.0.0.1 from Alex 14:15:49.781 A 14 01 02 03 00 04 00 05 23 0D 14:15:49.812 A 01 01 0D
Note that there may be other lines between these, depending what else CIUMon is doing.
The first line is CIUMon getting the request from Hyperview.
|read output||2||03||04||5||from||IP Address 127.0.0.1 from Alex|
|Type of command||Loop number (in decimal)||PCU number||Module number||Block number||CIUMon is receiving the request||IP address and logon name of the user requesting the data.|
The second line is the data CIUMon sent to the CIU. Remember that communication with the CIU is recorded in hex, so if you wanted to decode what was being asked for, and it involved numbers larger than 9, you would need to convert it.
|14||01||02||03||00 04||00 05||23||0D|
|get some data||what key to use||loop||PCU||module (two bytes)||block (two bytes)||checksum||end of line|
Note: The first byte in a request for data might sometimes be 50 or 67 instead of 14. A request that starts with a 50 works in a similar way to one that starts with a 14, but it can get more types of data. A request that starts with a 67 is a special type of request that CIUMon uses to communicate with RoviSys Turbo.
The third line is the response from the CIU.
|request acknowledged||checksum||end of line|
CIUMon will now delay a bit to give the CIU time to fetch the data, then it will ask the CIU to send the data. It will look kind of like this in the log:
14:15:49.890 A 19 01 1A 0D 14:15:49.921 A 00 01 28 13 01 3D 0D
The first line is CIUMon asking for the data.
|send data||key||checksum||end of line|
The second line is the data from the CIU.
|00||01||28 13 01||3D||0D|
|ok, sending data||type of value||requested value||checksum||end of line|
Finally, CIUMon will send the data back to Hyperview, which is recorded like this:
14:15:49.921 A read output 2 03 04 5 to IP Address 127.0.0.1 to Alex 14:15:49.921 B OK REAL 14:15:49.921 C 384.5 High Deviation
The first line contains the same information as the entry when CIUMon received the request, but now it's to the IP and user, because CIUMon is responding.
The second line specifies what kind of data is being sent. In this case, it's
The third line has the actual value that was sent to Hyperview.
When CIUMon sends or receives a communication from the CIU, the last byte before the
0D (end of line marker) is a checksum. To find the checksum, add up all of the preceding bytes in the communication, then take the last two hexadecimal digits from the result. When a communication is received, the bytes in the communication can be added to make sure that result matches the checksum; if it does not, it usually means that the communication was somehow garbled during the transmission.
For example, suppose CIUMon receives a line like this from the CIU:
00 01 36 E8 32 0D
Adding all of the bytes up to the checksum (that is, everything except the
32 0D) gives
01+36+E8=11F in hexadecimal. So, the checksum in this case should be
1F. Since the line shows
32 instead, this indicates that there was a communication problem. CIUMon would generate an error message if it encountered a line like this.
Note: In this particular case, the problem is that a
13 was missing from the line that the CIU sent to CIUMon. Adding in the
13 would make the checksum correct, since in hexadecimal
1F+13=32. If the checksum is off by exactly 13, this can sometimes indicate that CIUMon has been improperly configured to use XON/XOFF flow control.
DBDOC ©1996 - 2019 G. Michaels Consulting Ltd., all rights reserved. All other trademarks and registered trademarks are the property of their respective holders. Website source largely available under the terms of the AGPLv3.