QCDRCMDD differences at different releases - need to reconcile

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

I'm using the QCDRCMDD - retrieve command definition - API to get what 
all the parameters are set to, etc. It puts out XML representation into 
either a variable or an IFS file. I am using it to compare commands that 
customers may have modified using CHGCMDDFT. I don't really care about 
the details, only that a change was made, so I make a hash out of 
whatever the API returns, using the CIPHER MI instruction as surfaced to 
use in ILE languages. I chose to make a hash instead of walking through 
and looking for parms and defaults in the XML.

The output is different at different releases of the OS - one class of 
differences is when there are new parameters on the PARM command - CCSID 
on a parameter came in in V5R4, e.g. I can resolve that by stripping 
that from the output, so that it is the same as V5R1, which is my base.

A surprise was that apostrophes in defaults were not even output at V5R1 
(sometimes) and as an entity, & a p o s ; , at V5R4, if not before that. 
I think this was to make things conform to XML rules. Again, I can get 
around that by stripping it whenever it appears.

But I've just run up against something that I'm not sure what to do with 
(I think I'm tired enough not to want to battle this alone) - the XML, 
by the way, is in ASCII. Here is a TextPad comparison of differences 
between the 2 versions - there were multiple CCSID examples, left out to 
save space.

Compare: (<)C:\Documents and Settings\Vernon Hamberg\My 
Documents\v5r4box.xml (4923 bytes)
  with: (>)C:\Documents and Settings\Vernon Hamberg\My 
Documents\v5r1box.xml (4783 bytes)

265d257
<   CCSID="JOB"
284c275
<   Dft="&apos;Document&#160;Route&apos;"
---
>   Dft="X&apos;C49683A4948595A340D996A4A385&apos;"

The problem is the last pair - Dft= - at V5R4 it keeps the text, putting 
the entity in for the apostrophe, and a hard space where there is a 
x'40' in EBCDIC. At V5R1, it appears that the command definition reports 
some character defaults in their hex form in EBCDIC before presenting to 
the API. Perhaps this is becaus of a space in the default value - just 
guessing there. This seems also to be where the apostrophe entity was 
used at V5R1, but I can't guarantee that right now.

I see I could maybe look for X and the apostrophe entity, bracketed by a 
trailing apostrophe entity. I still have to deal with spaces being 
represented as the non-breaking space, ASCII 160. I don't think we have 
any international stuff, so I won't worry for now. I can always use 
cvthc or cvtch to take that hex string into EBCDIC, then convert to ASCII.

All I can say is "Uffda!!!" Some of you will understand.

Both boxes have QCCSID = 37 - jobs are both ENU US 37 37 for the 
attributes of language, country, CCSID, and default CCSID.

Is there some APIat v5r1 that will encrypt text for XML like this?

Help is appreciated - I feel like I'm partly there but weary of this task.

Regards
Vern