HP3000-L Archives

March 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tad Bochan <[log in to unmask]>
Reply To:
Tad Bochan <[log in to unmask]>
Date:
Wed, 22 Mar 2000 08:31:05 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (208 lines)
Hi Kevin,
If I flood the file with more test data (200-300 records), I can read back
much more
old data, but I eventually see the new test data, loads of blank lines
and finally get the FSERR 105 (BAD VARIABLE BLOCK STRUCTURE).
Thanks,
Tad.
----- Original Message -----
From: Kevin Newman <[log in to unmask]>
To: Tad Bochan <[log in to unmask]>
Sent: 21 March 2000 23:36
Subject: Re: IPC file puzzlement (longish)


> What happens if you flood the file with a bunch of info.  Do you ever get
back
> to the info you are flooding with?  Are all of the messages old, and you
never
> get to the items you are putting in the file or is something going on
where the
> file is behind for some reason?
>
> Kevin
>
> Tad Bochan wrote:
>
> > 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 }
> > > >
>

ATOM RSS1 RSS2