×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Barbara, Jon, & Scott... thank you all for the replies. I'm will fix this today. I have a feeling that all the programs that call this are passing CHAR(6).
So regardless of whether I change the parameters to VARCHAR when I remove the *VARSIZE, I will still have to locate and recompile all the programs calling this procedure.
I wish I could figure out where this went off the rails - I'm certain it was mainly due to my confusion with *VARYING and *VARSIZE.
Again, thank you all so much for your help and explanations.
-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Barbara Morris
Sent: Saturday, April 30, 2022 1:54 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: *varying vs varchar
On 2022-04-29 4:46 p.m., Greg Wilburn wrote:
That would be me... This was originally written in fixed format and I used a converter to convert to /free format a while back. That could be part of the problem (and/or my confusion about VARCHAR and *VARSIZE).
So when I remove *varsize and recreate the service program, will I likely need to recompile all the programs that call it? Or will they be OK?
Earlier posts in this thread have talked about making it a
varying-length parameter. That would be good in general, but if you do
change it to have type VARCHAR, then you need to recompile all the callers.
So just removing OPTIONS(*VARSIZE) will be easiest.
But you will still have to recompile all the callers that were compiled
with OPTIONS(*VARSIZE).
midrange.com
