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

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

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