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

Very much appreciated.

JS

El jue, 4 dic 2025 a las 23:17, Daniel Gross (<[email protected]>) 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 <
> [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.
>
>
-- 
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.