Tad,
I've seem similar behavior before, but usually only 1 record at a time is
"Stuck in the pipe".
ex. If the file previous contained:
rec1
rec2
rec3
I then "empty" the file & get out only:
rec1
rec2
Now the file shows EOF=0
Then copy this into the file:
recA
recB
recC
I'd would get out:
rec3
recA
recB
but "recC" would be "stuck" until I copied 1 more record into the file
(which would then be stuck).
Don't know the cause. Only fix we had was to purge & rebuild the file.
It would be helpful if we can reproduce this behavior starting with a
non-corrupted file. Not sure how useful an already corrupted file would be
to the HPRC, but you never know.
_______________________________________________________________________
Rich Trapp "RAT"
Managed Business Solutions [log in to unmask] http://www.mbsnav.com
Assigned to Design Automation Support at Agilent Technologies
Telnet or 970-679-2221 [log in to unmask] Loveland, CO USA
_______________________________________________________________________
-----Original Message-----
From: Tad Bochan [mailto:[log in to unmask]]
Sent: Tuesday, March 21, 2000 3:07 PM
To: [log in to unmask]
Subject: Re: IPC file puzzlement (longish)
Yes Rich,
The example I give is correct. I write 5 lines of test data into an empty
file, and when I read them back, I get *different* data.
The *different* data is in fact data that was in the file at some point in
time, but shouldnt be there now.
Sorry if my description of the problem did not make that clear.
Cheers,
Tad.
----- Original Message -----
From: TRAPP,RICH (Non-A-Loveland,ex1) <[log in to unmask]>
To: <[log in to unmask]>
Sent: 21 March 2000 22:30
Subject: Re: IPC file puzzlement (longish)
> I think Tad's point is not that the file is empty after he prints it. It's
> that it was full of console messages when he put normal text into it! (Am
I
> correct or was your example mixed data?)
>
> RAT
>
> _______________________________________________________________________
> Rich Trapp "RAT"
> Managed Business Solutions [log in to unmask] http://www.mbsnav.com
> Assigned to Design Automation Support at Agilent Technologies
> Telnet or 970-679-2221 [log in to unmask] Loveland, CO USA
>
> _______________________________________________________________________
>
>
> -----Original Message-----
> From: Kevin Newman [mailto:[log in to unmask]]
> Sent: Tuesday, March 21, 2000 2:19 PM
> To: [log in to unmask]
> Subject: Re: IPC file puzzlement (longish)
>
>
> Tad,
>
> The M in VAM under type tells me that the file is a message file. When
you
> look at the
> contents of the file, you are reading the message file. By definition, a
> message file
> does a destructive read. In other words, the file is fine, until you
print
> it. This
> reads and at the same time deletes the information. There are ways of
> viewing the
> information without deleteing it, but I think that it might be copying the
> information
> back into the file. I'm not sure how to do this, but I have seen others
> talk about
> doing it on this list, so the information is out there. The big point
that
> I'm making
> here is that there is no data reliability problem, that is the way that
the
> message
> files are supposed to work.
>
> Kevin
>
> [log in to unmask] wrote:
>
> > Hi all,
> > I have a chronic problem with IPC files on our system, and was wondering
> if
> > anybody
> > on the list has encountered something like this as well.
> > The scenario is that very occasionally during the day, a command file
> echo's or
> > prints information into an IPC file called CONSOLE.
> >
> > Almost on a daily basis, the IPC file gets corrupted with
> > (BAD VARIABLE BLOCK STRUCTURE FSERR 105), but sometimes a problem
> > manifests itself differently.
> >
> > The following dialogue describes the problem. Yesterday, we had an SA
> (98,614)
> > which was linked to an IPC file which had a similar problem to the one
> described
> > here.
> > I have a call into HP, but perhaps some of you may find this
> > interesting/disturbing.
> >
> > { Display the file characteristics, note that EOF = 0 }
> >
> > DEV:listfile console,2
> > ACCOUNT= account GROUP= group
> >
> > FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
> > SIZE TYP EOF LIMIT R/B SECTORS #X MX
> >
> > CONSOLE 256B VAM 0 1002 1 1056 1 1
> >
> > { Set a file equation pointing to this file }
> >
> > DEV:file console,old
> >
> > { Now, display the contents of a small file of testdata }
> >
> > DEV:print testdata
> > Test Line 1
> > Test Line 2
> > Test Line 3
> > Test Line 4
> > Test Line 5
> >
> > { Pipe this data into the IPC file }
> >
> > DEV:print testdata >> *console
> >
> > { Display the file characteristics, note EOF = 5 }
> >
> > DEV:listfile console,2
> > ACCOUNT= account GROUP= group
> >
> > FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
> > SIZE TYP EOF LIMIT R/B SECTORS #X MX
> >
> > CONSOLE 256B VAM 5 1002 1 1056 1 1
> >
> > { Now for the IPC magic ! }
> >
> > DEV:print *console
> > MON, MAR 20, 2000 5:58 PM. From JOBNAME,USER.ACCT (LDEV
10):MBOSCH,CYUSER
> ABORT
> > ED. (LDEV 145).
> > MON, MAR 20, 2000 6:03 PM. From JOBNAME,USER.ACCT (LDEV
10):ADAMIA,CYUSER
> ABORT
> > ED. (LDEV 86).
> > MON, MAR 20, 2000 6:03 PM. From JOBNAME,USER.ACCT (LDEV 178):SOFTWARE
> ABORT
> > ON LDEV 178
> > MON, MAR 20, 2000 6:03 PM. From JOBNAME,USER.ACCT (LDEV
10):RCAZZA,CYUSER
> ABORT
> > ED. (LDEV 178).
> > MON, MAR 20, 2000 6:06 PM. From JOBNAME,USER.ACCT (LDEV
10):FREPET,CYUSER
> ABORT
> > ED. (LDEV 131).
> > DEV:
> >
> > { Display the file characteristics, note EOF = 0 again }
> >
> > DEV:listfile console,2
> > ACCOUNT= account GROUP= group
> >
> > FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
> > SIZE TYP EOF LIMIT R/B SECTORS #X MX
> >
> > CONSOLE 256B VAM 0 1002 1 1056 1 1
> >
> > { The above sequence can be repeated adinfinitum.
> > Clearly, I can rebuild the file, and the problem goes away, but
> > the point is that there was no error returned anywhere, and I
> > believe data integrity has been sorely compromised }
> >
|
