DKNFs even *with* -p [long; lots o' code]

[Bruce Easton]

Bruce Easton wrote Tuesday, June 19, 2007 6:24 PM:
> 
> Jay R. Ashworth wrote Tuesday, June 19, 2007 4:33 PM:
>  
> > On Tue, Jun 19, 2007 at 03:36:41PM -0400, Bruce Easton wrote:
> > > Jay R. Ashworth wrote Monday, June 18, 2007 11:26 AM:
> > [ 215 lines of unnecessary quoting elided ]
> > > 
> > > Jay - how is the "push" process called?
> > 
> > >From 'pullinv(1l)':
> > 
> > ==================================================================
> > ==========
> > rm -f /appl/acsi/filepro/InvImp/lockf*
> > 
> > cd /home/samba/dbexport
> > 
> > # fix case for foxcopy
> > echo Y | foxcopy inventory InvImp
> > sleep 2
> > 
> > # archive
> > mv inventory.dbf old/inventory.dbf.`date +%Y%m%d`
> > 
> > # go to fp file, move data to qualifier, and touch to keep filepro
> > # happy
> > cd /appl/acsi/filepro/InvImp
> > mv key keyybc
> > mv data dataybc
> > touch key data
> > 
> > # zero bulk item quantities
> > dreport sviinvtr -f zerobulk -s bulkitem -h "Zeroing quantities on bulk
> > items"
> > 
> > # cleanup indexes and push to sviinvtr/sviinvfr
> > dxmaint InvImp -ra -e -m ybc
> > dreport InvImp -f push -a -m ybc -h "Pushing inventory records"
> > ==================================================================
> > ==========
> > 
> > On Tue, Jun 19, 2007 at 03:55:54PM -0400, Bruce Easton wrote:
> > > Bruce Easton wrote Tuesday, June 19, 2007 3:37 PM:
> > > > Jay R. Ashworth wrote Monday, June 18, 2007 11:26 AM:
> > [ 220 lines of unnecessary quoting elided ]
> > >
> > > Also - is prc.whack identicall for both files sviinvtr and sviinvfr?
> > 
> > The prc tables are identical; the selection sets differ only in the
> > applicable field numbers.
> > 
> > 
> > On Tue, Jun 19, 2007 at 04:14:24PM -0400, Bruce Easton wrote:
> > > Bruce Easton wrote Tuesday, June 19, 2007 3:56 PM:
> > > > Bruce Easton wrote Tuesday, June 19, 2007 3:37 PM:
> > > > > Jay R. Ashworth wrote Monday, June 18, 2007 11:26 AM:
> > [ 229 lines of unnecessary quoting elided ]
> > >
> > > Jay - what do you mean by:
> > > 
> > > > > > I'm in a loop, working on the second table to get it 
> > exactly right, so
> > > > > > I have to run the first one multiple times as well.
> > > ?
> > 
> > I mean that I won't normally be running prc.whack in production,
> > because prc.push is equipped to deal with the idea that the item may
> > already exist -- we're shadowing an already installed system, and he
> > gives us a full inventory dump daily.
> > 
> > But since prc.whack and prc.push are the only things writing records in
> > those files at them moment, it seemed pertinent to mention it.
> > 
> 
> I see - and are there any other processes that delete records other 
> than whack?  It just seems like with your shadow system, you're the 
> only one affecting records with these few processes.  And correct 
> me if I'm wrong, but it sounds like you're running one of these 
> batch processes at a time, so I would think if you're indexes 
> were not corrupt to start with, then there must be some 
> creation/deletion coding conflict or creation/deletion 
> (irregular process) interruption.
> 
> I don't see anything obvious in the push program.  You might 
> try identifying when each lookup no longer needs to be open 
> and then closing them at those points so that at least you know 
> exactly when the writes are expected to occur.
> 
> [..]
> 

Jay - another thing I just noticed was in your script above - you 
have some mv commands followed by touch and then a dreport (although 
it looks like it's a different file).  It made me wonder, though,
that you might have some part of your procedure on your shadow 
system where you move keys around or zero them from the script 
(rather than from filepro), and then go right into some clerk/
report process (without rebuilding indexes first).  I think you 
did say something in the original email about rebuilding indexes 
before and after, but what I'm seeing above makes me wonder if 
that could be the source of a bad index(es).  I guess it would only 
take one time of getting things out of order to mess up the 
indexes.

Bruce

Bruce Easton
STN, Inc.