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

Sure, use and understand both, no absolutisms. Each has its place.But especially when interfacing with external things and webservices, those are clearly dominated by string parsing serialization and deserialization feast and various tokenizations, concatenation, do really yourself a favour and use varying or varchar. I've see too often the classic API call to fail because the guy built http headers with fixed length strings.
And clearly the TRIM operation is O(n) in complexity, and that compound fast when used everywhere... used with all the XML, HTTP, html things we have around today we have created the perfect heat wasting machines :DDDD

On Friday, December 5, 2025 at 03:54:20 PM GMT+1, Javier Sanchez <javiersanchezbarquero@xxxxxxxxx> wrote:

Very much appreciated.

JS

El jue, 4 dic 2025 a las 23:17, Daniel Gross (<daniel@xxxxxxxx>) escribió:

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.

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