× 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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.