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

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.