×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
rob wrote:
Some of the fields in the file generated by RTVDSKINF
are 37 and some are 65535.
<ed for brevity>
DICDAT CHAR(6) FOR BIT DATA ... DIOBOW CHAR(10) CCSID 37
I hate having to turn on stuff to translate 65535.
Environment: Run SQL Scripts in iNav.
That looks like a defect in the definition for those fields
[DICCEN, DICDAT, DICTIM, DIUCEN, DIUDAT, DIUTIM] of the model
outfile QAEZDISK in QSYS. There should be no reason one should have
to use the "lie about the data" feature to enable seeing the
character data [from a non-EBCDIC client]; the DIOBTX is a possible
exception, but its implementation as 65535 versus something else, is
a side effect of a larger /issue/. The true "character field"
definitions of the file, those intended to have visible character
results presented, should have a non-hex CCSID defined if the data
is not binary data. Those character fields have that intention, but
miss the mark due to the *HEX CCSID.
Regards, Chuck
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
