It looks like it was written by someone unused to having people understand their programs :-)
OK, it is interpreting the code returned from an XML-parsing failure, and that is given as a decimal number represented in a binary field, so always needs to be converted to hex, which is what the code is doing.
The COMP PIC 9(2) field will define a two-byte binary (which can hold four decimal digits) but the two digits are used to mimic the message code when you look it up. A nice touch.
The COMP-5 is necessary, because the binary code can utilise all the bits of the two bytes of storage defined. In this instance it doesn't matter which value, one through four, is used for the PIC.
The code is only going to execute once, so the fact that this is a very heavy-handed way to do it does not matter.
Still, it happens when there is an error, and someone is going to be looking at that code and... wondering what it is doing. It is doing as Robert has outlined.
It could be made more easy to understand.
Code: Select all
1 XML-DECODE.
2 RTN COMP PIC 9(2).
2 RSN COMP-5 PIC 9(4).
1 HV PIC X(16) VALUE '0123456789ABCDEF'.
DISPLAY " RC=" RTN
",REASON=X'"
HV ( ( FUNCTION MOD ( ( RSN / 4096 ) 16 ) + 1 ) : 1 )
HV ( ( FUNCTION MOD ( ( RSN / 256 ) 16 ) + 1 ) : 1 )
HV ( ( FUNCTION MOD ( ( RSN / 16 ) 16 ) + 1 ) : 1 )
HV ( ( FUNCTION MOD ( RSN 16 ) + 1 ) : 1 )
"'"
Or even:
Code: Select all
DISPLAY " RC=" RTN
",REASON=X'"
HV (
( FUNCTION MOD ( ( RSN / 4096 ) 16 )
+ 1 )
: 1 )
HV (
( FUNCTION MOD ( ( RSN / 256 ) 16 )
+ 1 )
: 1 )
HV (
( FUNCTION MOD ( ( RSN / 16 ) 16 )
+ 1 )
: 1 )
HV (
( FUNCTION MOD ( RSN 16 )
+ 1 )
: 1 )
"'"
I'd not even do that, but work out four separate values, and DISPLAY those. When there is a problem, I'd not want people looking at the diagnosis-aid code first to understand that before they get to even start looking at the problem. That's a terrible thing to do to someone.
There's no disadvantage in doing it in more than one statement, and plenty of disadvantages often in doing it in one statement.