<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=402115811-28052006><FONT face="Courier New" 
size=2>&nbsp;&nbsp;&nbsp; </FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #ffff00 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Boaz Bezborodko 
  [mailto:boaz@mirrotek.com]<BR><B>Sent:</B> Sunday, May 21, 2006 10:17 
  PM<BR><B>To:</B> filepro-list@lists.celestial.com; John 
  Esak<BR><B>Subject:</B> Critical uptime question (Was "Looking for some 
  upgrade advice")<BR><BR></FONT></DIV><BR><BR>John Esak wrote: 
  <BLOCKQUOTE cite=mid20060519133742.BF933541D3@diablo.celestial.com 
type="cite"><PRE wrap="">Date: Fri, 19 May 2006 07:37:16 -0400
From: "John Esak" <A class=moz-txt-link-rfc2396E href="mailto:john@valar.com">&lt;john@valar.com&gt;</A>
Subject: OT: RE: Looking for some upgrade advice
To: "Fplist (E-mail)" <A class=moz-txt-link-rfc2396E href="mailto:filepro-list@seaslug.org">&lt;filepro-list@seaslug.org&gt;</A>
Cc: Rick Walsh <A class=moz-txt-link-rfc2396E href="mailto:rick@nexusplastics.com">&lt;rick@nexusplastics.com&gt;</A>
Message-ID: <A class=moz-txt-link-rfc2396E href="mailto:JIECJPPMJGMIINMGGNGAAEHJPBAA.john@valar.com">&lt;JIECJPPMJGMIINMGGNGAAEHJPBAA.john@valar.com&gt;</A>
Content-Type: text/plain;        charset="us-ascii"

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">I suspect the only reason I haven't seen comparable uptimes on my linux
systems is because the kernel updates require a reboot.  I talked directly
to the 2nd in charge of the kernel, as well as some of the other kernel
devs, and the consensus was that if I wanted a hot-swappable kernel, I
could go and write the hot-swap code myself.  They didn't consider it a
priority, or even desirable.
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
As you know, the *last* thing in the world I want to do is start a Linux
thread here. :-)

BUT... this is something I hadn't considered in our upcoming major move to
SuSe Linux. We have a situation where the main *nix server (currently SCO
OpenServer 5.6) can NOT go down at all. Literally, it is used to produce
various things, mostly bar code lables 365/24/7... with absolutely NO down
time at all except for two week long vacations during the year and some
other extremely special circumstances... hardly would I called these
"planned maintenance"... mor like get in whatever we can because the system
went down for some unforeseen reason! :-)  Very occasionally, and I mean
very occasionally, we can stop the constant transactional postings (and
label printing) for a few minutes... rally, just a few. Otherwise, it
becomes much like the "I Love Lucy" chocolate factory conveyor belt scene.

What, seriously, are we going to do in this situation. I was kin of hoping
we could find a *stable* Linux... meaning a kernel that does not need that
much or *any* patching. Are you talking about real security problems, or
feature upgrades? We simply can not bring the mahcine down for either
reason... at least not on *any* kind of ongoing basis.... how in the world
does *anyone* cope with such a situation.

Yes, yes, I'm constantly considering and devising possible methods to
de-reference our main databases and CPU's from this immediate hardware
interface... but to date, I have not come up with anything that would work
well enough to meet the need. Our systems are currently up-to-the-minute and
pretty much *have* to stay that way.

Suggestions?

John Esak

  </PRE></BLOCKQUOTE>
  <DIV>John, <BR><BR>I was thinking about this over the weekend.&nbsp; It seems 
  to me that you could give yourself a whole lot of flexibility if you could 
  somehow duplicate the database you're working with.&nbsp; I think that I could 
  do this if the database was not stored on the same machine as that which is 
  executing the filePro code.<BR><BR>Here is how I see it working:<BR>Run two 
  different servers each with its own copy of the database files.&nbsp; One is 
  the one that is directly accessed by the users while the other gets updated 
  with all of its transactions.&nbsp; Whenever it gets a transaction it 
  generates a record of the transaction as a separate file for the second 
  database to read.&nbsp; The second database would have a process that will 
  look for these transactions and update the files on its database.&nbsp; 
  <BR><BR>You could set up a controlled switch from the server running the first 
  database to the one running the second database.&nbsp; At the end of each 
  transaction executed on the data of the primary database you can have code 
  that will check some status flag as to the condition of the server of that 
  database.&nbsp; You can program the process to force the user to exit out of 
  the application if it sees a flag that tells it to switch to the secondary 
  database files.&nbsp; Once it exits you change the clients' configuration to 
  work from the secondary database upon re-execution.&nbsp; All transactions 
  will eventually move on to the second database server until all processes have 
  transfered leaving the first free for any changes or updates.&nbsp; In the 
  meantime that secondary database has now started acting as the primary 
  database and is building up a list of transactions that the original database 
  will have to update to bring it to the same condition as the first once it is 
  started up again.&nbsp; (Or you might be able to just copy files.)<BR><BR>I 
  don't know much about Linux, but I could see how an application working on the 
  same computer as the data would have a much harder time detecting and 
  adjusting for a switch to run off a different server.&nbsp; But if all you're 
  doing is going to a virtual drive similar to how I do it now--by running the 
  processes on separate windows machines while they look to mapped network 
  drives for the data--it is a much easier process to have a script that will 
  exit out of the process, change the mapped network drive to point to the new 
  server, and then re execute.<BR><BR>It seems like this will work well enough, 
  but not knowing the actual application I don't know if this is a good solution 
  for you.<BR><BR>Boaz<BR><SPAN class=402115811-28052006><STRONG><FONT 
  face="Courier New" size=2>&nbsp;</FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" size=2>I 
  certainly appreciate the suggestion. however....&nbsp; Well, I don't exactly 
  know how to state the however's... except that unfortunately, I think you have 
  minimized the do-ability of the procedures you are suggesting.&nbsp; if 
  filePro were a true RDBMS system with all that this entails&nbsp; (a la 
  Codd/Date) then yes, this would be possible.&nbsp; With filePro being what it 
  is... a flat file system using code written in this case by me or Rick to make 
  it function... there is I'm afraid to say, no viable way to emulate the 
  &nbsp;massive and deeply entwined </FONT></STRONG>&nbsp;<STRONG><FONT 
  face="Courier New" size=2> transactional nature of such databases.&nbsp; 
  </FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" size=2>I 
  don't mean to belittle the programming genius of either myself or my 
  colleague, Rick.&nbsp; :-)&nbsp; At least 200 people on this list will certify 
  that I feel I am the best filePro programmer in the world... :-)&nbsp; and 
  have stated so many times.&nbsp; :-)&nbsp; Is that enough smiley's to let 
  everyone know that I am fully aware that once you reach a certain level of 
  ability, the most you can be is occasionally first among equals... and there 
  are a hell of a lot of "equal" filePro programmers out there to me... possibly 
  even yourself... but of course I don't know you or your prowess so I'll just 
  give you the benefit of the doubt and guess that you are thoroughly capable of 
  writing whatever you want in filePro as the rest of us.&nbsp; HOWEVER, and 
  finally it comes... there is simply no way and no one I know, including even 
  Ken (either Brody or White) who could possibly do what you suggest.&nbsp; The 
  reasons are many, but mostly they lay in the misnomer of filePro itself and 
  sometimes just datasets themselves and Oracle all being called a 
  "database".&nbsp; Truly, if I could cull out the particular "database" as you 
  are referring to it and manipulate a transaction log and transaction data file 
  in the right ways, I could move between two application servers... maybe, 
  possibly.... perhaps... The reality, however, (there's that word again) is 
  that I have more than 700 active data files, thousands of processing 
  procedures, and hundreds of system/shell scripts to do the work in any 
  particular sub-application of what goes on at Nexus. If the module at hand 
  interfaces with our gut-level accounting system (also completely filePro 
  based), then many dozens of any of these several hundreds/thousands of items 
  may have to interact... and in a very tightly knit way.&nbsp; The task of 
  building in (from within filePro itself) some registering, transactional&nbsp; 
  process is not only daunting, but, I think, impossible. I am certain, after 
  many years of contemplating such things... and even implementing many smaller 
  subsets of this idea for myself and others... that on a large full-scale 
  basis, the only way to do it with full fail-safe operation is to have the 
  process and control already built-in to the RDBMS itself... as it, of course, 
  is in those systems. In other words, I wouldn't ever try "duplicating" this 
  with filePro. I am one of the longest-standing, loudest proponents of filePro 
  and all that it can do, which is nothing short of staggering... but I am also 
  a realist and know it is not internally capable of working in this 
  way.</FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2>The most I can hope for&nbsp; is a methodology wherein all of our 
  machinery that is "tied" to filePro can be simultaneously paused for a 
  specified length of time during which a controlled transfer to a duplicate 
  system can be managed.&nbsp; Along with this nearly impossible task, a 
  controlled transfer of all user processes to the duplicate system must also be 
  attained... and this is even harder to conceive.&nbsp; It can be planned and 
  done (mostly in a manual way) making sure IP's and all related matters are 
  dealt with properly... but it has never been something I am capable of 
  handling "automatically".&nbsp; </FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2>Short of absolutely pausing "production" for some length of time, there 
  is no cut-over or fail-over procedure which can be accomplished as our system 
  now sits.&nbsp; We can immediately fail-over from communications lines 
  failures like T1's going down between plants... but if the "main" server 
  itself fails, we always have a 15 minute to 30 minute period of real havoc and 
  repair that has to go on before things are back to normal on either "main" 
  or&nbsp; "duplicate" server.&nbsp; I hate the situation, but as I said, 
  haven't been able to come up with a solution yet.</FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" size=2>We 
  have looked into some of the older "mirroring server" software solutions, but 
  they are extremely expensive and never seem to guarantee that what we 
  are&nbsp; looking for ... is what they provide.&nbsp; If you, or anyone, know 
  such a system, speak up.&nbsp; The old days of 1776 and others like that are 
  gone.&nbsp; At least, our searches for such a solution do not ever include SCO 
  Open Server.&nbsp; Perhaps, we will have more luck with Linux.&nbsp; 
  (Although, I don't have high hopes for an affordable 
  solution.</FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" size=2>In 
  the very first place, no one has considered the "licensing" for a completely 
  hot-swappable server?&nbsp; In terms of filePro, I think it was brought up 
  during the beta testing for 5.6, but I don't remember if there was a precise 
  plan regarding this.&nbsp; Imagine that I did have a pair of mirrored servers, 
  would I need to get a license for both&nbsp; machines?&nbsp; I wouldn't think 
  so, but it is part of the whole cost thing to some 
  degree.</FONT></STRONG></SPAN></DIV>
  <DIV><SPAN class=402115811-28052006></SPAN><SPAN 
  class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2></FONT></STRONG></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=402115811-28052006><STRONG><FONT face="Courier New" 
  size=2>Sorry to be so wordy in all this... and yes, I would be thoroughly 
  happy&nbsp; if someone were to say, why haven't you checked out 
  "thus-and-such" it does exactly what you need... but I don't think it is going 
  to happen.</FONT></STRONG></SPAN></DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006></SPAN></FONT></FONT></STRONG>&nbsp;</DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006>And to get back to your suggestion for just one 
  second... I probably could have stated all this in the few words....&nbsp; 
  "Good idea, but it is just too hard for me to conceive of doing from within 
  filePro."&nbsp; :-)&nbsp; I've been waiting for a large download to finish... 
  and had some time on my hands... :-)</SPAN></FONT></FONT></STRONG></DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006></SPAN></FONT></FONT></STRONG>&nbsp;</DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006></SPAN></FONT></FONT></STRONG>&nbsp;</DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006>John</SPAN></FONT></FONT></STRONG></DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006></SPAN></FONT></FONT></STRONG>&nbsp;</DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006></SPAN></FONT></FONT></STRONG>&nbsp;</DIV>
  <DIV><STRONG><FONT face="Courier New"><FONT size=2><SPAN 
  class=402115811-28052006></SPAN></FONT></FONT></STRONG>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>