Re: Jobs that use 65535 CCSID... Why? -- MIDRANGE-L

I am surprised how many of my clients STILL have the CCSID set to 65535 at
system level. And when i ask I always receive two answers:

1) If we change stuff - (perhaps) something breaks.
2) We are running multitenant - and there is no way we can ( at row level)
control the CCSID.

Well - the first answer is just sluppy, but hard to argue with: "If aint
broke dont fix it"

The second answer is, however, more delicate.

Consider this: I have a client that runs multitenant ERP all over the world
- however the database is not unicode (or UTF-8) for that matter. By
setting the system CCSID value to 65535 it allows people to read and write
data in Latin-2 to the same tables where people from Scandinavia read and
write Latin-1. In that case some rows are in Lantin-1 and some are in
Latin-2. and there is no EBCDIC CCSID that can carry both charsets at the
same time. So when processing data ( batch) they have to deal with the
conversion - leading to all kinds of issues - but it works - and has been
working for many years.

The biggest issue is where I bring Microservices and open source to these
clients since that is PASE based and therefore ASCII. Also the IFS are used
heavily of course.. and now the fun begins.. It is a nightmare.

We did launche a UNICODE project however - changing a complete ERP to
UNICODE was a billion $ task. so it stalled.

Therefore I have posted an RFE to IBM to please implement UTF-EBCDIC as an
alternative CCSID. UTF-EBCDIC is basically UTF-8 but where UTF-8 has ASCII
as the base charset, then UTF-EBCDIC will have EBCDIC. This means the
national chars like æøåÆØÅ wil occupy two bytes each and abcABC will occupy
one byte each. Perhaps we need to extend some columns, but that is a much
simpler task than converting the entire system to UNICODE.

This will let the database and programs run unchanged and give the client
the option to set this CCSID at system level. Open source and spring boot (
Java microservices) will convert from UTF-EBCDIC to UNICODE and/or UTF-8 on
the fly. This will let the transformation process focus on applications and
not CCSID and eventually bring the IBM i platform in position in the global
infrastructure while dealing with legacy application.

So please, gentlemen, please go and vote for this RFE so we can end this
discussion once and for all.

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=138076

Read more here:
https://en.wikipedia.org/wiki/UTF-EBCDIC

On Tue, Jan 4, 2022 at 9:32 PM Steinmetz, Paul via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

Some of the PF were ones we created, many others supplied by 3 party
vendors.
So any of ours going forward ok.
Still have to watch out for 3rd party vendor PF during an install, which
is usually a RSTLIB.

Paul

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Patrik Schindler
Sent: Tuesday, January 4, 2022 3:28 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Jobs that use 65535 CCSID... Why?

Hello Paul,

Am 04.01.2022 um 19:41 schrieb Steinmetz, Paul via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx>:

Going way back, when the system value QCCSID was changed from 65535 to

37, we still had issues.

PF with CCSID of 65535 were causing issues.
Ended up identify all PF set to 65535, and changed those PF CCSID from

65535 to 37.

Interesting remark!

Before changing QCCSID, my machine already created all new files with 273
(Germany). So there seems to be another setting have gone wrong on that
machine you're describing.

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com