×
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.
The Query Definition object can contain literals and other data which
may require CCSID conversion. The object is supposed to have its
literal text values /tagged/ with the noted "to-CCSID" when the object
is recompiled; i.e. the CCSID would be established as an attribute of
the object, to associate that CCSID with those literals, when the query
is saved. The message serves as a warning, such that if setting the
CCSID tagging for currently established CCSID were a bad thing, the user
would be able to choose not to save that change. Since there was never
any CCSID attribute of the query object until v2r1m1, any query created
prior would have an effective CCSID(0). Since most US English systems
would have never set a CCSID, any query created at v2r1m1 and beyond
would have CCSID(65535) until it was changed and saved while the job had
a CCSID other than *HEX.
If the query was truly saved after the message "from 37 to 297" was
received, it sounds almost as if the case of CCSID(0) is not being
handled properly. Do you have a *QRYDFN and simple *FILE [i.e. best not
multi-file query] that both exhibits the problem and can be saved with
FILEMBR((*ALL *NONE)) so as not to include any data, that you can send
to me to review? I suppose I could patch an object to test, but then I
would want the first page of a DMPOBJ .... Uhh.....
Scratch that. Apparently some customers complained that the CCSID
was permanent, so it appears the dev had since changed the code to be
more relaxed. Oddly I remember such an issue, but can find no record of
it; and I did not take the time to find the code change -- but I am
confident this is the case. With that relaxed behavior the option
exists to _correct_ what might have been a mistake in having saved with
the changed CCSID when it was actually inappropriate. But also with the
[IMO irritating] behavior of the warning coming each time the query is
being changed. The message is not issued when the job CCSID is 65535
[AKA *HEX]. Also if the query is created with *HEX, the message is only
at the bottom of the display instead of sent to *EXT when a job CCSID is
established; thus if the query is not saved with that new CCSID, it can
remain *HEX. If it is really irritating, you might be able to ask the
dev to provide an option to make the message remain less obtrusive, to
work just like it does when the from-CCSID is 65535.
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.
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.