Re: Is hex 00000 in a string field equal to null?

That the first 32 bytes are all hex zeroes for a described incident seems to me to suggest, that the so-called "classic problem" is likely *not* the origin for the problem. Presuming that the parameter data is being used to set the value of the column which becomes all hex zeroes... If the error were the result of the default padding limit for a parameter, probably some of the first 32-bytes would have a somewhat expected and reasonable value [with hex zeroes being somewhat rare for most types except with zero-value integers], such that only the trailing bytes would have [the hex zeroes or some other unpredictable] unexpected data that comes from the PASA Program Automatic Storage Area.?

Regards, Chuck

On 21-Dec-2011 13:48 , Mike Wills wrote:

Yep, the information I see is classic problem. Just have to figure
out a fix.

On Wed, Dec 21, 2011 at 3:28 PM, Joe Pluta wrote:

I think you mean 32-character, and the only problem there is that
if you call a program with parms longer than 32 characters from a
command line and don't pass all the data, the part after 32
characters gets random garbage (not blanks). <<SNIP>>

On 21-Dec-2011 12:46 , Mike Wills wrote:

Thanks! The bug showed up again today, so I tried the REPLACE.
It worked perfectly! Now to figure out the damn bug. I am sure
it has to do with the 36 character limit on RPG parameters. I'll
probably remove the RPG from the picture to see if that resolves
it.

On Fri, Dec 9, 2011 at 10:32 AM, Mark Murphy wrote:

no need to go through all those gyrations, a single built-in
will do the job

REPLACE(field, x'00', ' ')

<<SNIP>>