QCDRCMDD differences at different releases - need to reconcile

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