File Status in XML - why is it defined as comp?

In all examples (that I've found) in MF documentation about XML syntax extension to COBOL the variable for file-status is in the select (with organization is xml) is defined as s9(9) comp.

Here's a fun trick, stack the xml and procob precompilers, in your procob config file have comp5=yes which is recommended. Procob will worry that your file-status might be used as a host variable and will change it to comp-5. Now if you're using lvl 88 definitions to check your status, eg. 

           88 end-of-file-xml value -7.

    88 not-well-formed-xml value -9.

This will work in Net Express but fail in Visual Cobol.

Back to the question then - why is the status variable defined as pic s9(9) comp in examples? Is something like pic s9(4) comp-5 considered harmful? If yes - why, if no - documentation should be changed to reflect the fact that this may cause unexpected results in some configurations.

In the rules for the XML I-O Select statement in both Net Express and Visual COBOL it states the following where Data-name-5 is the xml-status:

"Data-name-5 must be declared in the data division as a PIC S9(9) (any usage) and holds the file status for the last I/O operation".

So it can be comp, comp-5, usage display, etc. It just needs to be a signed numeric data item large enough to hold the returned file status.

If you save the post preprocessed source using the o parameter:
     $set preprocess(prexml) o(foo.pp) warn endp

Then you can see the actual source that is compiled.

The definition for the returned file status from the XML I-O statements is:
    05  PREXML--XD-STATUS--0001      PIC S9(9) comp-5

And then this is just moved to whatever you declare as your status code assigned to the XML-STATUS clause.

When you state that it fails in Visual COBOL, what exactly do you mean?

Thanks.

There is a bug in the xml-parser, we thought that it was related to the definition of the status variable but after stripping down the problem to the smallest possible program the error is related to the ASSIGN TO definition. We're opening a bug report about this but in short

program 1.

   assign to "C:\\temp\\myfile.xml"

   open xmlfile

   read xmlfile *> status is 1

   read xmlfile *> status is -7 EOF

program 2.

   assign to "$FRED\\myfile.xml" *> FRED is C:\\temp

   read xmlfile *> status is 1

   read xmlfile *> status is 1

Both programs open the file without problem so there is no question that the environment variable is expanded. But at the second read one progam give EOF as expected but the other does not.