Jump to content
The Uniform Server Community

Xcell

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About Xcell

  • Rank
    Newbie

Previous Fields

  • Main OS
    Windows XP
  1. Like I said before, the odds of someone else running a SCO system in this day and age along side US are very low. Not to mention the US team probably will never have access to a system like this to test my issue. But if there is just one other person looking for that needle in the haystack, hopefully this tale can give them the tools to think outside the box to find it. I plan on leaving the backup turned off until the transition is complete, then re-enabling it for an added layer of protection, once the SCO box is off the system. I also have to agree with you that I have no idea how this sent out a signal on our network that would kill the SCO system. Fortunately this system has never been accessible from the internet. And let me tell you this thing is ancient. The majority of the hardware is from the late 90s. Pentium 2, 40GB HD, 512MB RAM, an old Intel pro100b NIC, SCO 5.0.4. , no USB ports, and we are still using DDS-90 backup tapes. It's taken me 3 years to convince my boss to move on before the availability of hardware becomes nonexistent. A series of tape drive faults helped that argument considerably. The joke around here is the hot new thing was jealous of the old hag and was trying to kill her off. As far as my backup, I simply uncommented the default line in CRON and changed the time period. ;[db_backup] ;start = 2011-11-21 2:00:00 ;period = 14400 ;path = C:\UniServer\uni_con\db_backup\Run_db_backup.bat ;ref = 1330979552 and here is my db_backup config. [FIFO] Fifo_depth = 6 [LOG] Logging = true
  2. Now to start off, I would like to say the odds of someone using the same configuration as I am is fairly slim. Nonetheless I feel a cautionary tale / bug report is in order. I have been running various versions of US for about a year now on systems running XP, Vista, and 7. Little did I know how violent this little program could be. I am currently in the process of writing a new POS/Inventory/Employee management program for my employer. I am pretty good with computers and would occasionally code for fun but, I am not a software engineer by any stretch. We are currently running a horrible little program called Filepro. This dinosaur hasn't changed much since its inception on the TRS-80 computer. We have been running it since 1987. Our biggest issue is the version we have MUST run on the old SCO Unix operating system. It CAN NOT run on Linux, only SCO. No one here knows much of anything about Unix, let alone a version from a company that bankrupted themselves 8 years ago trying to prove they invented Unix and profit from it. But we are stuck until I am done. About 3 months ago I upgraded to the new Coral US. Around the same day, our old router died and needed to be replaced. And this is where the problems began. Every day at exactly 10AM the Unix server would crash with a kernel panic related to the network card driver. We tried everything, bought a new network card for the SCO box, bought yet another router, unhooked cables, and tweaked every setting imaginable. And then came the day I decided to change my db_backup settings. I worried about losing data, so I changed it to backup every 2 hours instead of every 24. DOH!!! So I changed it to backup every 5 minutes. Guess what happened? I still have no idea why running db_backup in cron would cause another computer on my network to crash. I have since changed to another backup solution. Just a reminder to not spend too much time focusing on one possible cause of a problem. We were determined that the problem was the router. So much so that we went through 3 months of daily server crashes without really testing which device was truly causing the problem, a little Windows XP machine backing up some data.
  3. When I first boot 8.1.1 when it asks to change the root password for MySQL i receive the error in the attached picture. I can still change the password through the menu in coral with no issues at all. All other scripts seem to work fine as well. It's just that first boot splash screen. For now I just click no to the automated prompts at that initial start and continue with business as usual. Just wanted to pass this along.
  4. Well, don't I feel dumb. At some point I had shifted the default program for .vbs files to Notepad ++. N++ did not change the edit function of these files, it chose to open them. It's an easy fix. Go into any folder and choose tools>>folder options from the menu. On the File types tab select vbs files and click advanced. In the next window highlight the open line and choose edit. On the application line enter: c:\windows\system32\wscript.exe "%1" %* Solved the problem completely.
  5. Thanks for the assist Bob. Unfortunately I still have the issue, although the number of pop ups has reduced. Seems the display logo setting only applies to scripts run directly from the command console. I am going to test tonight to see if this is a configuration issue. I have Vista and 7 computers at home. I haven't checked to see if coral has the problem on those computers. I have only ran Orion at home.
  6. I have also had this problem on all versions of coral. Every time I start or stop the MySQL or Apache Servers a window pops up in notepad titled us_hta_delay.vbs with the text wscript.sleep WScript.Arguments(0). You close one window and another pops up. This happens 3 times for each server, every time. That's 6 windows for each start up. It also does it twice for each server when checking server status. XP SP3 on 2Ghz Core2 processor with 4GB RAM. Java 7 u2 Visual c++ 2005, 2008, and 2010
×
×
  • Create New...