Filepro-list Digest, Vol 42, Issue 41

[Boaz Bezborodko]

> Date: Thu, 26 Jul 2007 11:37:32 -0400
> From: "Don Coleman" <dcoleman at dgcreact.com>
> Subject: RE: {Spam?} Re: {Spam?} Re: Identifying who has a record
> 	locked on	Windows network
> To: "'Brian K. White'" <brian at aljex.com>,
> 	<filepro-list at lists.celestial.com>
> Message-ID: <003401c7cf9a$e24ba530$236e10ac at SagerDGC>
> Content-Type: text/plain;	charset="us-ascii"
>
>
>   
>> -----Original Message-----
>> From: filepro-list-bounces+dcoleman=dgcreact.com at lists.celestial.com
>> [mailto:filepro-list-bounces+dcoleman=dgcreact.com at lists.celestial.com] On
>> Behalf Of Brian K. White
>> Sent: Wednesday, July 25, 2007 11:26 PM
>> To: filepro-list at lists.celestial.com
>> Subject: {Spam?} Re: {Spam?} Re: Identifying who has a record locked on
>> Windows network
>>
>>
>> ----- Original Message -----
>> From: "Don Coleman" <dcoleman at dgcreact.com>
>> To: <filepro-list at lists.celestial.com>
>> Sent: Wednesday, July 25, 2007 11:06 AM
>> Subject: RE: {Spam?} Re: Identifying who has a record locked on Windows
>> network
>>
>>
>>     
>>>> -----Original Message-----
>>>> From: Kenneth Brody [mailto:kenbrody at bestweb.net]
>>>> Sent: Wednesday, July 25, 2007 10:44 AM
>>>> To: Don Coleman
>>>> Cc: filepro-list at lists.celestial.com
>>>> Subject: {Spam?} Re: Identifying who has a record locked on Windows
>>>> network
>>>>
>>>> Quoting Don Coleman (Wed, 25 Jul 2007 10:03:46 -0400):
>>>>
>>>>         
>>>>> List:
>>>>>
>>>>> I probably already know the answer to this but I'll ask anyway.
>>>>> On a Windows network (WIN2000 Advanced Server, Windows 2000 & WINXP
>>>>> Pro.
>>>>> Clients, fP v5.0.13 64 user license), is there anyway, within the
>>>>> Windows tools or using an external utility, to identify which user or
>>>>> work station (I'd take either) has a particular fP record locked in a
>>>>> file?
>>>>>           
>>>> [...]
>>>>
>>>> I have looked, and I have yet to find any documented way to get this
>>>> information on Windows.
>>>>
>>>> --
>>>> KenBrody at BestWeb dot net        spamtrap:
>>>>         
>> <g8ymh8uf001 at sneakemail.com>
>>     
>>>> http://www.hvcomputer.com
>>>> http://www.fileProPlus.com
>>>>         
>>> Ken:
>>>
>>> Thank you,
>>>       
>> This is not a fatuous comment but a real one,
>> Why don't you make a small investment in time, possibly a small consult
>> fee
>> to someone, to just have someone look over your app and guesstimate how
>> plausible it would be to switch it to linux?
>>
>> Most code actually just runs without much fuss at all, some things might
>> cause migration pains but not if the unix guy is good. A lot of common
>> difficulties are perfectly avoidable merely by taking some care and
>> thought
>> up front about choosing which of the 10 ways to do something.
>>
>> It may sound silly to propose such a major change, but, if this is a large
>> site I can only say I don't think I've ever seen a locked record on sco
>> unix, or linux or freebsd that wasn't immediately identifieable,
>> explainable, and able to be dealt with both not only immediately but
>> gracefully. I don't think I've ever had to reboot a nix box to clear a
>> record, not once. I have, on rare occasions for other things but not for
>> that. filePro is just plain extremely well behaved and sane on unix.
>>
>> I don't put this out there lightly or frivolously. I think it would be no
>> great investment to get an initial evaluation done by one of us who
>> routinely handles both platforms and periodically ports our own code back
>> &
>> forth or writes code that will work on both platforms without porting. But
>> I
>> also know it would be a serious investment in several coins to actually go
>> through with it.
>>
>> I'm sayng that it would be worth it. These mysterious locked records when
>> no
>> person, machine, or net connection anywhere seems to have done anything
>> wrong, mysterious corrupted indexes, clerk & report binaries that just
>> crash
>> out of the blue once in a while, .. all stuff I've seen on windows too
>> even
>> on very small and lightly loaded networks with spotless hardware and os
>> installs and network topology... even on single user!, and never seen on
>> *nix even on the largest most heavily hammered sites except very rarely
>> and
>> it was always resolved and the cause determined, which most importantly,
>> means I never had to suffer that particulr error again. No crossed fingers
>> and hoping it runs ok today. So far, every time I've seen clerk or report
>> actually crash, I was able to track it down almost immediately to a
>> programming error on my/our part, or bad data/corrupt file. And those
>> times,
>> the file didn't just go corrupt out of the blue or for no reason. There
>> was
>> always some plain simple hardware or sys admin failure. Even on the
>> heaviest
>> used, largest boxes, there is no such thing as cron jobs to rebuild
>> indexes
>> or freechain. If I have to rebuild an index it's a big deal. If I don't
>> already know why an index went bad like it wasn't because of a botched
>> file
>> transfer or crashed process or hardware, then it's an extremely big deal.
>> As
>> far as I'm concerned, putting up with stuff like that is just
>> inconceivable.
>> It's not sane. You need to work in an environment where the various rules
>> are like natural laws of physics. Not in an environment where 3 random
>> times
>> a day gravity the sun doesn't work.
>>
>> Suffering the occasional error is unavoidable I think, but at least if the
>> environment is robust, and every error can be tracked down and _avoided_,
>> instead of lived with and worked around, at least that's a sane way to
>> operate and you can move steadily ahead and leave only closed holes behind
>> you and after a little while all the pitfalls in your app are uncovered
>> and
>> sealed and then you can really count on your system and debug your code in
>> a
>> more sane manner because if it acts funny, you can rest assured it is the
>> code that needs attention not some mysterious windows gremlin. Conversely,
>> on windows, perfectly correct code may fail, leaving you with no option
>> but
>> to modify it to be basically incorrect code that happens to be the only
>> way
>> to brute force it past some inexplicable windows behaviour. Like the way
>> people issue sleeps after writing and closing files before allowing the
>> next
>> process to open it. or the way one of my co-workers just "doesn't beleive"
>> that umask actually works and insists on writing lots of unnecessary chmod
>> commands. You are supposed to be able to rely on the os actually
>> fulfilling
>> it's advertised features. It's not a luxury it's a bare minimum base line
>> starting point. Anything less is not  "mostly works, tolerable, can live
>> with it, etc..." no, it's flatly not acceptable. You should not work
>> around
>> stuff like that. You should be using your brains to write more and better
>> application code, not wasting 15% or more of your precious few available
>> man-hours working around and recovering from having your OS fail out from
>> underneath you.
>>
>> It might not be as bad as you think to port over to unix either. We have a
>> fairly large app and once in a great while, almost never these days since
>> we
>> stopped actively supporting windows, it takes one of us about 5 or 6 hours
>> to do a conversion from nix to win or from win to nix. Granted that's our
>> own code and the guy doing it has done it countless times and over the
>> years
>> a lot of code has been massaged so that it works on either platform
>> without
>> modification, so that's an optimal figure you probably will not be lucky
>> enough to attain. But, it does tell you the scale your are looking at.
>> It's
>> probably on the order of days or maybe even hours to get an initial port
>> that works well enough that subsequent issues can be dealt with as they
>> turn
>> up. It depends how much fancy system command stuff you do and how much
>> windows-specific syntax is in the F5 menu batch files. A lot of that often
>> turns out to be unecessary and is easy to deal with by just removing it.
>> Like it's not necessary to specify the full path with drive letter to an
>> fp
>> binary. such a command would only work on one platform or the other, but
>> just strip away the path and leave the command, and voila, now it works on
>> both.
>>
>> I say all this simply becasue it's frustrating to see someone struggling
>> with something when you know it's unnecessary. We (by we I mean any
>> unix/linux fp user I've even met, customer or developer) simply never have
>> this kind of grief. A few people do have problems but, since I have had
>> and
>> eliminated the same problems myself, I'm confident that it's avoidable,
>> and
>> therefore not actually a problem at all, in their case too, merely they
>> haven't done the necessary methodical debugging process and I can't do it
>> for them since I have my own life to live.
>>
>> The closest thing to an honest to goodness, mysterious filepro problem
>> that
>> I ever see on any *ix platform, that hasn't been explained and eliminated,
>> is one that as far as anyone can tell, is doing no harm! For years and
>> years
>> and years on many boxes and several versions of 3 different os's etc...
>> That
>> issue is the way certain processes provoke DKNF warning messages without
>> any
>> explicable code or data justification. I say warning messages, not errors,
>> because I have far more evidence that the message is the only thing thats
>> wrong than I have that there is actually any data or processing error. And
>> it's only certain few know processes that do it so even that is almost not
>> a
>> mystery since it doesn't happen at random, doesn't interfere with work,
>> and
>> doesn't have any real world consequences we've been able to detect, and is
>> even able to be ignored/hidden via an fp variable now. I know what Ken
>> says
>> about this, and it sounds like the ultimate in stupidity to contradict him
>> on something like that, but, it's been too many years and too much data,
>> and
>> too many transactions and too many end of months and end of years, and too
>> many installations and too many varying usage patterns and too many checks
>> and reports printed and too many accountant reconciliations... etc etc etc
>> for there to have been an actual problem and us not have felt it
>> somewhere.
>>
>> I am _not_ one of those guys who thinks "format and istall linux" is the
>> answer to all questions. That kind of ignorant statement bugs the crap out
>> of me like you wouldn't beleive. Thats what I meant by this being a
>> sincere
>> not a fatuous post. It is sincere. If you have large sites that can't
>> suffer
>> unexpected crap like that, I really think you should suck it up and
>> investigate the linux angle and dig in to the learning curve. Or possibly
>> freebsd. At this point even I, mr. proud to love xenix, can not in good
>> conscience recommend any sco product any more. Of the other unix-alikes
>> linux will be _far_ and away the easiest to maintain and find reasonably
>> qualified support for and the most effortless hardware compatibility too
>> so
>> thats the only reason I say linux.
>>
>> I know it doesn't help you in the short term, but, every hour you spend
>> beating yiur head against the wall wondering why windows isn't doing what
>> it's supposed to, that very same hour could have been spent productively
>> adding to your linux-fu and bringing you closer to the hour when you no
>> longer have to suffer that problem ever again. Think of that goal of "no
>> more mystery". If it were me I'd, starting this minute, spend every hour
>> all
>> night and all weekend from now until I knew all the in's & outs of
>> installing a linux box and running fp on it and accessing that fp via
>> terminal emulators. 3 non-trivial core knowledge sets that you need to be
>> familiar with and which differ completely from how it all works on
>> windows,
>> but, only 3. You can get the basics of each in less time than you probably
>> think even if you never looked at a unix box before in your life.
>> especially
>> if you go in that order. Just install linux, maybe several times, maybe
>> several versions, first and figure out about kernel modules and hard
>> drives
>> and filesystems and backups and networking etc.. and don't even think
>> about
>> fp at all. fp would be a counter productive distraction at that point.
>> forget how to spell "fp". Then move to installing fp, after you are so
>> comfy
>> installing things in general, that you can sensibly uh, make sense of fp's
>> quirks, because it is quirky and not like most apps (just like it is on
>> windows come to think of it). These days it's way easier to get into
>> linux/bsd than it used to be to get into *nix. Cash in on that.
>>
>> Another thing you'll be cashing in on is a better class of help both paid
>> and free.
>> Those of us who use *nix have determined, at least to our own
>> satisfaction,
>> that it's a bad investment to spend any time at all trying to make things
>> work reliably on windows. Mostly things work ok, and that's fine, but
>> sometimes it doesn't and often there is no way to fix it because nothing
>> is
>> wrong, you don't have anything misconfigured or have bad hardware etc, you
>> can't make it any more correct, and yet it fails X percent of the time.
>> Once
>> you establish that, you just write off that platform as unuseable. Or at
>> least I do and a fair chunk of the people I know. So, whenever someone has
>> a
>> problem, if it's in unix there is both a lot more people with deep insight
>> into the system, and a lot more of those people will be willing to take
>> time
>> to answer a question or help debug a problem methodically. In windows,
>> there
>> are actually a lot more users, but hardly any with what I'd call deep
>> insight. How can there be? Probably not even very many of MS's own staff
>> has
>> deep insight into the system. The rest of us don't even have the code or
>> complete or clear documentation. A lot of problems can actually be
>> debugged
>> somewhat by having basic insight into computers in general, but not many
>> of
>> the folks who have that good methodical sense are willing to squander
>> their
>> time "polishing a turd". So you really do yourself a favor lots of
>> different
>> ways at once by moving onto a *nix like os. You may not quite belive it or
>> understand the motivations, but basically it's like this, to some extent
>> at
>> least, merely because it's _possible_ in unix to give you clear explicit
>> directions that have known expected results and known possible causes for
>> any other results, that fact alone causes some, many even, knowledgeable
>> people to be willing to give you not merely general tips and pointers and
>> clues, forget guesses, but actual explicit directions that you can just
>> follow like a recipe. It often takes far less time for a knowledgeable
>> admin
>> to write out a few lines of arcane looking shell commands than it would
>> for
>> them to explain the dozen factors each single line takes into account. So
>> they just write the lines and all you have to do is play keyboard monkey.
>> If
>> you're nervous wait a day for other people to nit-pick whatever post you
>> are
>> thinking of follwing because there is never a shortage of those. (Kind of
>> like here) It's because in unix such instructions are never a waste of
>> time.
>> whether it works or not, it always moves you forward towards the answer.
>> If
>> I say "type this..." and you say you did and nothing happened, well
>> depending on what that command was, I know exactly whats the next thing to
>> investigate from there. No mysteries. It's almost as good as not having a
>> problem when practically every problem is very straightforward to diagnose
>> and always progresses very predictably and methodically from symptom, to
>> some number of debugging steps that each eliminates a set of
>> possibilities,
>> to solution.
>>
>> I can't tell you how priceless that ongoing peace of mind is that this
>> produces. I go home or away and am just plain not worried. The process of
>> diagnosing is just so straightforward. You don't feel any stress because
>> you
>> always know exactly what to do because the system is transparent. All
>> parts
>> are knowable. And "knowable" is all that matters. You don't have to
>> actually
>> know all that much yourself, you just have to know how to read docs and
>> interpret error & log messages and if you have access to google at the
>> time
>> that just makes it almost effortless.
>>
>> Wow I completely did not intend to get that deep into that.
>>
>> Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
>> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
>> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>     
>
>
> Brian:
>
> I appreciate and acknowledge everything you said.  In this situation I would
> expect to be out of a large client before a conversion was done.  There is a
> power play of sorts going on whereas the I.T. Head used to report to the
> same person I program for (he gives me the projects to do).  The Mr. I.T.
> managed to have the person he reports to switched from my person to the
> Controller.  I assume he did this by either agreeing or acknowledging that
> large sums of money are spent in I.T. at his location and they should work
> more closely together (Mr. I.T. & Ms. Controller).  At the same time he also
> managed to have the person he previously reported to stripped of the title
> "Dir. Of Information Technology" and inherited it himself.  The new Dir. Of
> Information Technology is, of course, MS certified, and anything non-MS is
> surely a bad thing because it is out of his area of expertise.  He is
> somewhat of a control freak and what he doesn't personally know, use, or
> understand is suspect.  At this point the biggest thing I have going for me
> is this is a 24X7X365 operation and I have been developing this application
> for 7 years.  They currently have more enhancements on the board than they
> ever have, most of which are customer requests because they do go out of
> their way in accommodating customer custom programming requests, but some
> are internal efficiency enhancements as well.  
>
> They do have an internal programming staff of SQL programmers who develop a
> few stand-alone apps, but mostly do custom reports for customers by scraping
> it from their existing applications (non-fP).  All but one of these internal
> programmers report to the same individual as I do but Mr. I.T. is trying to
> change that as well.  As far as I know, the last time he tried to change
> this was 6-8 months ago and the senior SQL programmer said no way, I'll
> leave first.  In a way he has, his wife accepted a job across state and he
> moved with her and now telecommutes (mostly).  He is on site 1-2 times per
> month.
>
> If I were to advocate an OS change I suspect Mr. I.T. would first advocate a
> database change.  At some point the owners may be willing to re-invent the
> wheel and try to duplicate this themselves (using their internal staff) but
> at the present time I think their project list outweighs attempting to
> re-engineer an app. that is always up.  There may be a time to advance this
> but I don't believe it is now.  I try to continue making progress on their
> project wish list and come up with improvements to known issues as time
> permits.
>
> I do appreciate the time you spent clearly outlining the benefits of making
> an OS change.  I have had other contributors on this list make the same
> suggestion but not to the extent or detail as you have. 
>
> Thank you,
>
>
>
> Don Coleman
> Donald G. Coleman, Consultant
> 402 Andrew Circle
> Indiana, PA 15701
> dcoleman at dgcreact.com
> (724) 349-6302
>   
Don,

Might I suggest that you get yourself familiar with Linux yourself on a 
machine on the side?

I just climbed that learning curve without yet worrying about moving our 
FP apps to Linux in order to move from an older NetWare based server to 
something more current.  The old server crashed a few times due to a 
corruption on the partition.  I was able to rebuild them both times in a 
couple of hours, but someone at Novell said it was likely an OS problem 
and the version we had was no longer being supported. 

The learning curve was made a bit steeper because I also had to learn 
and configure Samba.  But it was very doable.

Linux was at least as easy to understand as MS or Netware once you get a 
basic feel for how it works, and also seems a bit more straightforward.

Others will have a lot more to say about how easy it would be to then 
set up the client's machines for the change.

I will say that I did get some hostility on this board when I asked for 
help in climbing the learning curve, but if you try this and I can help 
with any questions I'll do my best.

(It's a bit funny for me to read on this list a suggestion to move to 
Linux when some on this list were somewhat hostile to me when I wanted 
to do the same.)

Boaz