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 firstname.lastname@example.org.
While I have read the post that it is all working now ...
I would reckon that the file was level check no and the program had not
Or it the code is as old as you suggest and using program described input
specs that they were wrong.
In recent times decimal data errors that just start happening are almost
always a file change and set to level check no
My 2 cents
From: "Brad Stone" <bvstone@xxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
Date: 10/11/2021 12:16 AM
Subject: Packed field with Blanks in it... how?
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx>
I am helping a customer with a random problem where a field from a file
(packed 16,0) is getting filled with blanks.
On a dump we see hex 04040404040.... in it. And of course it's throwing a
data decimal error.
I tried to look in the program for something obvious, but it's an old
monolith of a program with weird columnar RPGIII code.
Anyhow, in what instances would a field read from a file (or even an
unsuccessful read) that is defined as packed get blanks in it? The field
is not manipulated in any way that I can see.
If reads and no record, it should be zero. If it reads and gets a record,
it should be the value from the file (in this case, confirmed to be zero..
and even hex value shows 000000000000000F.
Just grasping at straws I guess. I've not seen this unless there is an
overlaying DS on a numeric field that gets set to blanks for some reason.
Bradley V. Stone
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any
As an Amazon Associate we earn from qualifying purchases.
This thread ...
Re: [EXTERNAL] Packed field with Blanks in it... how?, (continued)
This mailing list archive is Copyright 1997-2023 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.