Re: Weird problem a customer is having with a file (James H H Lampert)

Hi, James:

You say this physical file was created by Query/400?

Perhaps there was a "bug" in Query/400 that created this PF incorrectly?  If 
so, perhaps you or your customer could try this:

Rename the original physical file that has the problem to, e.g. "BADFILE" ...

Create a new equivalent PF using DDS ... if you can do a DSPFFD to determine 
the field names, types, lengths, decimal places, etc., perhaps you could even 
use a tool like one of the RTVPFSRC commands to create equivalent DDS ...

Next, try using CPYF to copy the offending record, using FROMRCD and TORCD, and 
ERRLVL(nn) to ignore errors ... 

Then, use CPYF from the renamed original file to the new file, with 
ERRLVL(*NOMAX) to ignore any errors.

>From this point forward, when your customer runs the query, it should use the 
>new physical file, which is now (we hope) correctly created and specified ...

Let me know if that helps?

Regards,

Mark S. Waterbury

----- Original Message ----- 
> From: "James H H Lampert" <jamesl@xxxxxxxxxxx>
> To: "MI Programming on the AS400 / iSeries" <mi400@xxxxxxxxxxxx>
> Sent: Saturday, April 22, 2006 1:50 AM
> Subject: Re: [MI400] Weird problem a customer is having with a file (James 
> H H Lampert)
>

> George Lemen <georgelemen@xxxxxxxxxx> wrote:
>> You may have encountered a known problem . . . where if
>> a physical file created by SQL has a logical
>> view/file created over it, something like the "last use"
>> date gets corrupted and the object ends up (eventually)
>> being damaged.
> . . .
>>  Don't know if that is what you are looking at, . . . .
>
> Well, I've also got some people at IBM looking at the
> problem file, and as it turns out, they could tell right
> away that it didn't come from SQL. When I asked the
> customer how it was created, I found out it's an output
> file from Query. And I don't think it ever had any
> logicals defined over it.
>
> Just about the only things I know about it are:
>
> 1. There's a null-capable date field in it,
>
> 2. Reading a record with that field nulled-out causes a
> data mapping error,
>
> 3. The record with the nulled-out field still does make it
> into the low-level input buffer, BUT the null-map for the
> record has a 2, instead of a 1, for the nulled-out field,
>
> 4. The records without nulled-out fields can be updated,
> and new records can be added, but any attempt to null-out
> the field in a new or updated record gets ignored, and
>
> 5. The record with the nulled-out field rejects all
> attempts to update it, regardless of whether I plug a
> valid date into the field, or I plug either a 1 or a 2
> into the field's position in the null-map, throwing a
> data-mapping error every time.
>
> I haven't a clue what could be causing the problem, but
> I'm convinced that the "2" in the null-map is a key clue.
>
> Leif Svalgaard, Gene Gaunt, Dave McKenzie, any other MI
> gurus, WHERE ARE YOU?
>
> --
> JHHL
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/mi400
> or email: MI400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
>