RE: QRY1733 - How to stop this message

Chuck,

THANK YOU for that explanation. It makes complete sense. I went to one of
our US machines which has everything as CCSID(37) and noted that if I
changed the job to CCSID(297) then I received the message at the bottom of
the screen rather than *EXT (and I was wondering why the different
behavior). The Query object itself is *HEX.

I must admit, it would be preferred if it didn't tell me via *EXT every time
it changed, because the query is used by users in multiple languages, but I
digress :-)

I will take you advice and open up a ticket with dev.

Thanks,

Crispin.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, January 25, 2008 4:03 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: QRY1733 - How to stop this message

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