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

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 <[email protected]>:
> 
> 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 (<
>> [email protected]>) 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 <
>> [email protected]> 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 (<[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.
>>> 
>>> 
>> --
>> 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.
> 
-- 
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.