Help converting to a new Linux server

John Esak john at valar.com
Thu Aug 21 07:30:20 PDT 2008 

Hi Richard,

You sent this privately, but I'm answering It through the list... might be
helpful to someone else as well.

I have wrestled with this a little, but finally, I just leave it to whoever
*locks* the record first, gets it.  This is filePro's job and it does it
perfectly well.  When I'm in a situation where an @key does a routine that
doesn't lock the record, but I don't want someone else doing the *same*
routine by accident at the same time. It can be done in two ways... I hate
both, but they work.  Use a real field in the record and set it equal to a
value while the @key is running.  The first thing this @key does is check
this field, if it is non-empty then don't run and put up the "in use"
record. As soon as the first @key is done, it must clear this field.  If
there is no way to add this control field to the main record, then build a
temporary file that holds record number and just add it when the record is
in use and delete it when not... then do a lookup to this file for the @rn
first before executing the @key...

This is all very workable, but filePro does do it better... so I veer away
from this if it can be helped.

The real complex thing is to lock a browse... I had to do this for a large
scheduling (call center) program I wrote here at my new job.  Holy cow, this
was the most difficult process I've ever written... It took about two to
three weeks of live operation with 14 call center operators to work out all
the kinks... and essentially it is an extremely complicated version of the
above single record lock, but more elaborate.  The first caller in can only
see his available time slots.... after all if he is offering the 9:30am slot
to someone it would be bad if another operator in another city gives this
slot to another caller before the first can press his "booking" key to grab
it.  So, I essentially run each operator with his own session value (sort of
like a web session value) and disallow anyone else from getting those time
slots... or even offering them or seeing them. If the operator books the
slot and others they immediately are never seen again by anyone. As slots
are used, new available ones show up, and no operator ever sees anyone
else's possibilities.  

This as I say, enormously complicated, browse routine keeps the situation
from happening where you call Ticketmaster and they say the 5th row center
seats are available... and you hem and haw for 10 seconds then say okay I'll
take them... and the operator then says, oops sorry someone else just took
them.  Kind of like airline ticketing hassles, etc.

My system works pretty good for all its faults.  The main one being that you
can only lock out a reasonable number of time slots from viewing by
others... say a couple hours worth around the desired time slot and the
booking process has to be very fast to keep as many slots available to other
operators as possible. Otherwise, there appears to be no time slot available
on the desired date and time when their really might be.... 


I had a fun time writing this browse lockout... but let's just say the next
time I have to write something this difficult is two weeks after I'm dead.
Hopefully, they'll give me something *easy* to do next time!  All I can tell
you is I now have an even more enhanced appreciation for Ken and the other
programmers at FP Tech for writing the browsing and locking paradigm that is
in filePro today.  It is just incredibly complicated to do this... and do it
without the benefit of GUI abilities to immediately update the screen.  The
IUA brose is simply a miracle in speed and accuracy in this regard.  The
multi-user aspect is the difficulty and the complexity of incorporating
indexing and/or selection set criteria as well... is as I say, just
staggering. I would not take on this challenge again without many bottles of
aspirin.


John







> -----Original Message-----
> From: GCC Consulting [mailto:gccconsulting at comcast.net]
> Sent: Thursday, August 21, 2008 9:33 AM
> To: john at valar.com
> Subject: RE: Help converting to a new Linux server
> 
> John,
> 
> Now I have the opposite problem, I would like to lock a record through
> programming when an operator is looking at the record even if he is not
> "updating" the record.
> 
> I would love to be able to, either in auto processing or at @entsel to
> issue
> a command like lockrec "Record in use by"<user_name, or something similar
> which would allow the current user to update the record but not allow
> anyone
> else to update the record.
> 
> This would be convenient in my call center program keeping 2 operators
> from
> accessing the same record.  A popup message when the record is accessed by
> other then the first operator would flash saying this record is in use.
> All
> update to the record are done through @key functions.
> 
> Oh well, another wishlist item.
> 
> Richard
> 
> 
> 
> > -----Original Message-----
> > From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
> >
> [mailto:filepro-list-
> bounces+gccconsulting=comcast.net at lists.celestial.com]
> On
> > Behalf Of John Esak
> > Sent: Wednesday, August 20, 2008 11:49 PM
> > To: filepro-list at lists.celestial.com
> > Subject: RE: Help converting to a new Linux server
> >
> > If you really want to solve your record locking problem ... whose
> locking
> a
> > record when it should be available... You need to look at all of your
> > processing. Here is where the problem lies. All your trouble is being
> > generated there.  FilePro does not cause record locking conflicts... in
> > fact, it has never, not once, in the nearly 30 years I've used it, ever
> been
> > the *cause* of a record locking issue.  It has been fully vetted over
> and
> > over again in this regard... and without fail, the reason for a record
> being
> > locked when it shouldn't be... is the, is the sole province of the
> > programmer and the processing tables being used.
> >
> > Sorry to take the long view... but somebody has to... get a hold of some
> old
> > Guru magazines, Smalltalk's , fPDJ's and so on... there are myriads of
> > examples of how to build your tables so no conflicts will occur.
> >
> > One of the main culprits I think, is working from within @key's
> routines.
> > This unnecessarily *locks* the record, so other reports, or clerk
> accesses
> > get stopped dead in the water.  I have yet to find an @key routine that
> can
> > not be transformed into an @entsel version, even including changing
> values
> > of the real fields on the current record.  It just takes little re-
> writes
> > here and there to open up your files to virtually complete access
> without
> > the fear of records being locked when they shouldn't be.  If you do lock
> a
> > record, do it for the shortest time you possibly can, and do it and lock
> and
> > unlock it correctly so you keep indexes correct as well.
> >
> > As to your actual question, the sholock program Ken mentioned is the
> tool
> > you want, but he is also correct it is 100% more effective if you use it
> > within Bob Stockler's lock.info script.
> >
> > Secondly, his mention of checking your lookups with CHECKLOCK is the
> very
> > best way to *quickly* find improper code.
> >
> > Third, you can do something to all subdirectories and files with
> wildcards
> > much easier in Linux than in any Windows platform.  Roughly it might
> look
> > something like this.
> >
> > Cd /appl/filepro   #(where your files live)
> > chmod 700 * */*       #Change ownership of all filePro files and dirs
> >
> > But, again, Ken's suggestion to run setperm in the fp/scripts directory
> is
> > really all you need.
> >
> > Cd /appl/fp/scripts   #or wherever your programs are
> > ./setperms
> >
> > This must be done as the root user.
> >
> >
> > Good luck,  The hard to understand part of all this is why you didn't
> have
> > the problems under Netware....  perhaps, it does not lock files as
> > thoroughly (i.e., strictly... in *alls* circumstances) as it should.
> I've
> > never been a fan of Netware, maybe It's okay, but I have no experience
> with
> > it.  I only have had run-ins with all the other products that Novel has
> > ruined over the years.... WordPerfect, Corel, Unix... etc.  :-)
> Whatever
> > the reason, now that you are on Linux, you have to deal with its full
> record
> > locking paradigm... and if you write your code properly, it will be no
> > burden.
> >
> > John Esak
> >
> >
> > > -----Original Message-----
> > > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > > [mailto:filepro-list-bounces+jo	hn=valar.com at lists.celestial.com] On
> > Behalf
> > > Of Kenneth Brody
> > > Sent: Wednesday, August 20, 2008 11:14 PM
> > > To: Nathan Lehman
> > > Cc: filepro-list at lists.celestial.com
> > > Subject: Re: Help converting to a new Linux server
> > >
> > > Quoting Nathan Lehman (Wed, 20 Aug 2008 22:12:41 -0400):
> > >
> > > > filePro 5.0.14D9
> > > > Novell Open Enterprise Server 2 on Suse Linux Enterprise Server 10
> > >
> > > [... moved from Netware to Linux ...]
> > >
> > > > One of the issues we are having with this new server is dealing with
> > > > file locks.  I find it really hard to find out who is locking a key
> > > > file.  The way we do it now is to run ncpcon from the server.
> However
> > > > this just shows everyone accessing the key file, not the one(s)
> > > > locking it.
> > >
> > > Get a copy of my showlock program, perhaps with Bob Stockler's
> lock.info
> > > wrapper.
> > >
> > > > I found after the first day that we needed to set all filePro files
> > > > with the -sh (shareable) attribute.  That really helped.
> > >
> > > Why?  What problems were you having, and how did it help?  I'm not
> > > familiar with a "shareable" attribute under Linux.  How, exactly, did
> > > you set this?
> > >
> > > > However I'm
> > > > not good enough at linux to know how to change all files in my
> filePro
> > > > and fp folders and have it change the attributes in every file
> > > > including the files in subfolders.  Right now I have to go into each
> > > > folder and change all the files in that folder, then move to the
> next
> > > > folder and do the same thing.
> > >
> > > Use the setperms script that filePro includes.  That's all that you
> > > should have to do.
> > >
> > > > One other problem that seems to be occurring more often on this
> server
> > > > is freechain rebuilds.  I'm not quite sure why this is happening
> more
> > > > often.
> > >
> > > Add PFCHECKLOCK=ON to the filePro config file and see if you have any
> > > unprotected lookups being modified.  (Note, however, that this would
> > > have caused problems in Netware as well, if you had more than one
> > > person in at a time.)
> > >
> > > > I guess I would just like to know if anyone has any tips or tweaks
> in
> > > > general for running filePro from my new linux server and if anyone
> has
> > > > any suggestions for the problems listed.  Thanks so much in advance.
> > >
> > > --
> > > Read the truth behind the movie "Expelled" at
> > > <http://www.ExpelledExposed.com>
> > > --
> > > KenBrody at BestWeb dot net        spamtrap:
> > <g8ymh8uf001 at sneakemail.com>
> > > http://www.hvcomputer.com
> > > http://www.fileProPlus.com
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.6.6/1625 - Release Date: 8/21/2008
> 6:04 AM

More information about the Filepro-list mailing list