Re: iNav Run SQL Scripts vs CCSID

The issue is substring of pseudo-character data; i.e. effectively binary data, designated as character. Homogeneous reference to the binary code points will enable the perception of the data as character [strings]; thus /pseudo-character data/ as noted above, since its actual encoding is unspecified. A non-described [flat, Hex shifted, ccsid(*hex)] character field must be cast to a character data type _with a CCSID_ to enable transport from EBCDIC to ASCII; or use the /force translation/ option when available, as noted.
Since the /field/ SYSLOGFLD of a QHST* file is CCSID(65535), so too will a substring of that field, irrespective of CCSID() for the JOB; i.e. a request to CHGJOB CCSID(37) will not assist in that scenario. Thus resolution is best achieved by an explicit cast, to designate the character encoding. Of course if the data were not really EBCDIC English Upper Character data, then both the explicit cast and the attempt to lie to the interface [e.g. JDBC] claiming that the data is really CCSID(37), then it is GIGO.

Regards, Chuck