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

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 (<[email protected]>)
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: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: [email protected]
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/rpg400-l.
>
> Please contact [email protected] for any subscription related
> questions.
>
>
-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact [email protected] for any subscription related questions.