fpxfer export to a file - permissions/ownership

Mon Sep 18 10:49:23 PDT 2017

> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Fairlight
via
> Filepro-list
> Sent: Monday, September 18, 2017 1:28 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: fpxfer export to a file - permissions/ownership
> 
> On Sun, Sep 17, 2017 at 10:29:45PM -0400, Richard Kreiss thus spoke:
> >
> > I have been using filePro long enough to know that the *nix systems
> > have had an ongoing problem with permissions.
> 
> There only 'problem' *nix systems have with permissions is people not
> understanding how they work.  The tragedy is that they're really not that
> complicated that they should be considered some mystical black box.
> 
> Speaking to the point of, "Do we look for the root cause, or just get it
going
> again?" that really depends on whether you have the 'luxury' of doing
things
> correctly.  Do you expediently destroy the evidence which will likely lead
to a
> long-term fix (something I could buy 1-3 times)?  Or do you actually take
the
> time to address the problem properly and ensure that it doesn't recur time
and
> time and time again for decades?  How many times can the tolerate
> 'emergencies'?
> 
> Hey, it's their dime, and a good revenue stream, right?  There's a reason
I'm not
> rich; I believe in fixing something properly at the earliest opportunity.
> 
> > I would like to put it another way, running dxmaint at night is like
> > doing preventive maintenance on a car or a computer.
> 
> Richard, that's like 'preventing' whooping cough by prescribing a teaspoon
of
> cough syrup once a night.  It doesn't prevent anything, and at best masks
the
> symptoms.
> 
Agree, but if the issue is not in the programming but one outside ones
control, then doing "maintenance" on the auto indexes keeps the business
operating then this actually becomes a moot point.  If no problems occur for
a period of time, then a change in frequency to the running of dxmaint
should occur until a problem arises.  It may be an issue with just one index
and not all.  The newer releases of filePro are showing more information
about an error helping isolate where the problem may be coming from.

One thing that many don't look at is the size of an index.  Multi key
indexes with 5 or 6 figure record number can produce very large index files.
One can have an OS issue when the file size nears or is just over 3GB size
on a 32 bit Operating system.  That is one reason I have moved many of my
clients to 64 bit OS.  Also, any filePro upgrades is to the 64 bit version.
Although some clients are still running 32 bit versions of Windows 7.  This
has required me to install both the 64 bit and 32 bit versions of filePro.  

I am hoping that fpTech will take advantage of the added memory space and
add some runtime functionality which would allow clerk, report and dxmaint
to make efficient use of the multiple cores processors have today.  One
gaming article I read recently mentioned 16 core processors for gaming
machines.  Today's 64 bit operating systems can make efficient use of the
processor cores so why not filePro?

> > problems before they become a bigger problem.  This does not mean one
> > should not look for where the problem is coming from.  However
> > sometimes it is outside one's ability to correct the issue and
> > therefore must work around the problem.
> 
> The problem is that the readily availability of these crutches tends to
reinforce
> the tendency for people to take the easy way out, address the immediate
> problem, and let the situation ride because it's out of sight, out of
mind.
> 
> > This is not just a filePro issue but one of most programs have
> > otherwise no company would release maintenance releases.  Think about
> > the number of updates to the various apps that people have on their
> smartphones.
> 
> You really picked a comparison which puts fP-Tech in a bad light.  Many
mobile
> apps are -horribly- written, ill-designed, and get update after update to
fix things
> which should never make it past alpha, much less beta, gamma, and to
release.
> This assumes they don't become abandonware upon release.
> 
> By contrast, the OS itself (Android or iOS, pick either) gets (if you're
> -lucky- perhaps a release per quarter from the downstream telecom to which
> you subscribe if you're on Android, or Apple if you have an iPhone.  Apple
has
> impressed less in the last two years, with a flurry of patches which fix
patches, at
> least in the iOS world.
> 
> I'm convinced QA is practically a thing of the past, the way a lot of
vendors do
> business.  I don't understand it, either.  If something isn't right, and
you -know- it
> isn't right, it should never go out the door with 'known issues'
unaddressed, in
> my book.  Release date?  Who cares?  I'd rather push the date and get it
done
> correctly, than put something out there which proves I don't care about
quality.
> I'd rather any vendor did the same.  I'm actually dealing with a sample
library
> vendor which discovered that Native Instruments' Kontakt (upon which they
> base their own
> product) has a bug which screws with the note alignment in their guitar
> strumming routines for all their plugins.  They're going to take several
months to
> address the problem properly, without needing NI to address the underlying
bug
> (previous bug report having been lost by NI when they switched bug
tracking
> software, of course).  I can at least respect the fact that Orange Tree
will be
> releasing something I can trust, even if it takes longer.  Plus, they're
not shafting
> us with any upgrade charges.
> They're simply making it right, and doing it the right way.  A lot of
companies
> could learn a lot of things about doing business from a vendor like that.
> 
> Don't even start me on the gaming industry shipping with 'known issues'.
> We'd be here for a month, and I'd barely be getting started.  Ironically,
it's
> actually Nintendo which does the best job, here.  They're not bug-free,
but they
> are arguably the most polished, earliest in the cycle.
> 
> > One issue I do have with filePro is not knowing what functions are or
> > will be effected by the increased speed of systems.  I did run into
> > this problem a few years ago and had to modify some programming to
> > avoid the issue.  It was a simple matter of adding a drop to a browse
lookup.
> 
> Why would you need drop if the system was faster?  I would anticipate
needing
> drop if a system was -slower-.

OK - this will be a long explanation.

Client enters order details and usually ships within 48 hours of entry (no
back orders).  The bar code labels are produced for each item on the order.
The remaining bar code sheets are sent to the billing department.  Usually
these will be for specific items.  The order detail lines are deleted.  then
an invoice is printed from the remaining detail lines.

A simple operation.  However, there are 5 or more order clerks entering
orders all day.  These orders are from 2 to 200 or more detail lines.  All
of the data entry, once the order header is entered is numeric.  The order
clerks work very very fast.

The issue that arose came from the billing clerk.  She would notice in the
browse displaying the order details that there was a detail line from
another order.  I was advised to send the application to support but I told
them that their test environment would not duplicate the actual work
environment.  After checking the source code for the browse lookup function,
it was found that to allow for the quick redisplay of the browse lines, the
record numbers were cashed.  What was happening was the billing clerk would
delete a detail line (record).  Filepro would set that record # to be
available.  One of the order entry clerks would then use that newly deleted
record for the order being entered and it would appear on the billing clerks
browse.  This only started as the speed of the computers and the network got
faster.  The drop I added was if the PO number was not the same as the PO
being worked on, drop that record.  This eliminated the problem.

I was on the phone with John Esak at the time and he realized that he had
programs doing the same thing and needed to add a drop to avoid this
problem.

Now, was this a filePro issue or an error in programming for not considering
this possibility?  I think it is the latter, something I as a programmer did
not foresee.  I now try to think of all of the things that a person can do
to not get details in correctly or what errors can occur when this happens.

System speed is the one thing that can create an unanticipated problem. A
mistake years ago might add only 100 records to a file; today that same type
of mistake can add 10,000 records in the same time.

An unanticipated problem showed up years ago when a client upgraded from a
System 36 to a new AS400.  The clerk running the report had time to start
the report on the System36 and then walk over to the printer and change or
align the paper (form).  With the AS400 she lost the delay as the output to
the printer was almost instantaneous. She had to put the proper form in
before starting the print operation no after as with the System36.  

I am running into a perceived speed issue at a clients in how fast filePro
selects records and begins printing.  This is from that order file and the
output uses a dash lookup to select records to print(in the timed case, 25
detail lines).  It is doing this in a file will well over 20 million records
and doing it in under 5 seconds from record selection to completed print
job.  I timed it the other day so my numbers are accurate.  Their complaint
is the record selection is not fast enough.  These are network PC's running
across gigabit Ethernet.

The way that this operation could be speeded up would be to install a small
SSD and set filePro's temp directory to that drive.  That would be faster
than writing to a mechanical drive.

> 
> mark->
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list