Re: Why you shouldn't be afraid to use VARCHAR in RPGLE... -- RPG400-L

To just add my 2ct to that discussion.

1st - yes VARCHAR is the way to go, with ALL modern development. We shouldn't be using CHAR for 50 byte Name oder street address fields anymore.

2nd - no (as in never) should any variable in a RPG variable be un-initialized. The INZ keyword should be the default that you type.

3rd - if you need to trim a lot(!) of "legacy" CHAR fields, always consider using %TRIMR - it's a good amount faster than a %TRIM as it only trims from right, not from both sides. This is also true from SQL with RTRIM vs TRIM.

4th - for new procedures simply use VARCHAR parameters with CONST OPTIONS(*TRIM) and you never have to think about it. If the procedure is called a lot (like in XML parsing) or if the procedure if the target of a SQL UDT/SP this can be a problem.

Just my 2ct.

Regards,
Daniel

Am 05.12.2025 um 03:09 schrieb Javier Sanchez <javiersanchezbarquero@xxxxxxxxx>:

It was a stand-alone var, but I do accept I may have not initialized it
properly to an empty string inz('') and the length field had anything and
it was a random value too large or yielded a negative value.

Thanks.
JS

El jue, 4 dic 2025 a las 19:51, Marco Facchinetti (<
marco.facchinetti@xxxxxxxxx>) escribió:

Hi Javier, this usually happens when the varchar is in a Ds and is not
properly initialized.

HTH
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco

Il giorno ven 5 dic 2025 alle ore 01:55 Javier Sanchez <
javiersanchezbarquero@xxxxxxxxx> ha scritto:

Thanks Charles! Good to consider it!
I once had a strange issue with a varchar variable. It was empty, and
taking the %LEN() of it was throwing me an exception. I was expecting me
to return zero, but the exception was that the length was not valid.

Did not have much time to find out why that was, so I had to quickly

change

it to a simple CHAR and use %LEN(%TRIM()) of it. Issue solved. Never

knew

and did not want to investigate further with that, but what I've been

doing

is that I first test the original var that will be the value of the
assignment, and that one is a CHAR type. Not a good practice at all, but
yes, I started to be scared of that.

Will listen to better practices with them.

TIA
JS

El jue, 4 dic 2025 a las 18:43, Charles Wilt (<charles.wilt@xxxxxxxxx>)
escribió:

I think I've maybe mentioned this in replies over the years. But as I
posted "Why you shouldn't be afraid to use VARCHAR in RPGLE" as a reply

to

a post on the midrange list, I thought the subject would be worthwhile

as

its own post here.

Back in 2016, a performance assessment by IBM's performance consulting

team

reported back to my company that a certain (home grown) XML parsing

routine

"was taking 23% of all cpu used by interactive jobs." The PEX report

IBM

collected even showed that that CPU was mostly being used on only 13

lines

of code in that routine.

I happened to see the report, and took a look at the routine in

question.

What I saw was a bunch of the following:

select;
when %trim($level(x)) = 'something';
....
when $trim($level(x)) = 'something-else');
....
endsl;

Obviously, doing the same work over and over again is a waste.

So I simply changed level and a couple other related variables from

CHAR

to

VARCHAR. Ironically, I didn't need to use %trim() at all, since level

was

originally loaded via:

$level(x) = %subst(chars:1:stringlen);

The next year's performance report noted that CPU consumption by our

XML

parsing routine had dropped to less than 1% of Interactive CPU usage.

The

sample size was somewhat small, so IBM also looked at the routine
explicitly and noted that CPU usage per call to the routine dropped by

a

factor of 15. Additionally, my testing showed that response time per

call

dropped from an average of 0.39s to 0.13s!

Not bad for a day's work....
Most of which was regression testing!

Now at the time, we had 7 or 8 big P50-tier POWER8 servers...each with
approximately 10,000 users. So, as you can imagine, interactive CPU

usage

was and still is hugely important to us.

Morals of the story:
- don't be afraid of VARCHAR
- lots of %trim() is often a red flag

HTH,
Charles

PS. Strongly consider VARCHAR for new DB fields. Just make sure you
ALLOCATE them appropriately.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.