There should be some past threads of this discussion in the archives.
The "correct" CCSID for WMQ can not really be dictated by a WMQ
administrator. Take note of the following points:
*
Applications create WMQ messages. The implication of this is
that the Application Hosting Environments (AHE) that the applications
execute in will determine the CCSID of the data, not WMQ.
*
There are many AHE products: On the mainframe there are: JES
(batch), USS (Batch), CICS (online), WAS in USS (online), TSO, DB2
(Stored Procedures, ETL products, WII, etc.). Data may be written to or
read from a queue from any of these environments.
*
Multiple environments may write to the same queue.
*
Multiple environment may read from the same queue.
It should be clear that the character sets across these mainframe
environments must be compatible. This extends to the distributed
platforms, telecommunications (VTAM code pages), etc. We in the WMQ
community are, once again, the lucky guys in the middle dealing with a
systemic problem that most other folks don't even want to acknowledge,
let alone deal with.
If, for example, data is written in and read from a WAS environment and
stored in DB2 then the data, as seen in the WAS environment, should be
"stable". The data may appear to be corrupted in TSO and DB2. The
application will not see this corruption until someone extracts and uses
the data in DB2! The fact that the problem has bitten you yet does not
mean that the problem does not exist.
Glen
(410) 965-0574
NCC 5E7
_____
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
Sent: Thursday, September 28, 2006 11:37 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Clients and CCSIDs - ASCII - EBCDIC conversions
TSO uses 37, years ago when we had this issue I went through this same
issue. We had the business define in the specifications what characters
were acceptable for input. We looked at the conversions and realized
what worked. Nothing!!!! So we took the high ground and took the lesser
of the evils and changed the CCSID on MQ z/Os to 37. We then isolated
the offending characters and wrote a quick 20 line assembler program to
do a translate to the correct representation.
This was in 99'. So if you want to take out your sword and do battle
with the DRAGON I will tell you this issue has been there since then and
has not been corrected. Actually I believe from the Dragons point of
view. Everything is working as is. But if they fixed it. All those
clients that have workarounds would now have to start regression testing
their apps. Not a good idea. So the axium....If it is broke, don't fix
it!!
bee-oh-dubble-bee-dubble-egh
_____
> Date: Wed, 27 Sep 2006 19:45:56 -0400
> From: rtsujimoto-dEbs1jsJ3+***@public.gmane.org
> Subject: Re: Clients and CCSIDs - ASCII - EBCDIC conversions
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
>
> I don't think TSO uses CCSID 37. I think it's either 1047 or 924.
You
> can't see the square bracket characters if the data is converted to
CCSID
> 37,
> but TSO will show them properly if the data is converted using 1047 or
924.
> 1047 is the CCSID that FTP uses.
> ----- Original Message -----
> From: "eugene rosenberg" <erosenb100-***@public.gmane.org>
> To: <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
> Sent: Wednesday, September 27, 2006 5:42 PM
> Subject: Re: Clients and CCSIDs - ASCII - EBCDIC conversions
>
>
> > The conversion to CCSID 500 is working properly. The
> > issue is that an application, which is written in TSO,
> > is more likely using CCSID 37. And this is the issue -
> > mismatch between hexadecimal representations in MQ
> > after conversion (CCSID 500) and in the program (CCSID
> > 37).
> >
> > CCSID 500 was used as a default on many IBM products
> > but fired back probably only with MQ. It is
> > irrelevant, if a hexadecimal combination is
> > representing a "wrong" character in DB2, as long as it
> > is a "right" one for all putting and getting
> > applications.
> >
> > Eugene
> >
> >
> > --- "Brumbaugh, Glen" <Glen.Brumbaugh-***@public.gmane.org> wrote:
> >
> > > Wayne.
> > >
> > > These folks at Hursley must think that they are at
> > > the center of the WMQ
> > > universe. Well, I guess they are! It must make
> > > sense from their
> > > perspective to ship WMQ with the UK EBCDIC as the
> > > default character set.
> > > It would be nice if IBM as a whole decided to ship
> > > all of their z/OS
> > > products with compatible defaults. Oh yeah, world
> > > peace would be nice
> > > too.
> > >
> > > Glen
> > > (410) 965-0574
> > > NCC 5E7
> > >
> > >
> > >
> > > _____
> > >
> > > From: MQSeries List
> > > [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > > Sent: Tuesday, September 26, 2006 2:25 PM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Re: Clients and CCSIDs - ASCII - EBCDIC
> > > conversions
> > >
> > >
> > >
> > > Hi Glen,
> > >
> > >
> > > You are quite right, on new z/OS installs of
> > > MQSeries use CP037.
> > >
> > > We made the mistake years ago of using CP500 as it
> > > was the default
> > > and IBM normally ships the right defaults with
> > > mainframe distributions.
> > > Probably 95% of the US mainframes are running CP037
> > > (<==S.W.A.G.).
> > >
> > >
> > > What was IBM thinking? I would really would like
> > > to know.
> > >
> > >
> > > Cheers,
> > > Wayne
> > >
> > >
> > > ---------- ORIGINAL SNIPPET FOLLOWS -------
> > >
> > >
> > > All,
> > >
> > > WMQ on z/OS comes with the CCSID set to 500 (English
> > > EBCDIC) as the
> > > default. In the US, the Queue Manager CCSID should
> > > normally be set to
> > > 037. Not making this change will cause some
> > > conversion errors. You
> > > need to compare the 037 and the 500 character sides
> > > side-by-side to
> > > document the conversion errors.
> > >
> > >
> > >
> > >
> > > _____
> > >
> > >
> > >
> > >
> > > *************************** IMPORTANT
> > > NOTE ***************************** The opinions
> > > expressed in this
> > > message and/or any attachments are those of the
> > > author and not
> > > necessarily those of Brown Brothers Harriman & Co.,
> > > its
> > > subsidiaries and affiliates ("BBH"). There is no
> > > guarantee that
> > > this message is either private or confidential, and
> > > it may have
> > > been altered by unauthorized sources without your or
> > > our knowledge.
> > > Nothing in the message is capable or intended to
> > > create any legally
> > > binding obligations on either party and it is not
> > > intended to
> > > provide legal advice. BBH accepts no responsibility
> > > for loss or
> > > damage from its use, including damage from virus.
> > > *****************
> > > **************************************************
> > >
> > > To unsubscribe, write to
> > > LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> > > message body (not the subject), write: SIGNOFF
> > > MQSERIES Instructions for
> > > managing your mailing list subscription are provided
> > > in the Listserv
> > > General Users Guide available at
> > > http://www.lsoft.com
> > > Archive:
> > >
> > http://listserv.meduniwien.ac.at/archives/mqser-l.html
> > >
> > >
> > > To unsubscribe, write to
> > > LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
> > > in the message body (not the subject), write:
> > > SIGNOFF MQSERIES
> > > Instructions for managing your mailing list
> > > subscription are provided in
> > > the Listserv General Users Guide available at
> > > http://www.lsoft.com
> > > Archive:
> > >
> > http://listserv.meduniwien.ac.at/archives/mqser-l.html
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
> > in the message body (not the subject), write: SIGNOFF MQSERIES
> > Instructions for managing your mailing list subscription are
provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
> >
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided
in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
_____
Share your special moments by uploading 500 photos per month to Windows
Live Spaces Share it!
<http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http:
//www.get.live.com/spaces/features> To unsubscribe, write to
LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the
subject), write: SIGNOFF MQSERIES Instructions for managing your mailing
list subscription are provided in the Listserv General Users Guide
available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html