CompuServe Messages

>>sorry, but any program can cause a RAM chip error. What are you talking about? The original problem dealt with the "ramlib" task. This is the file handler for the RAM disk. There is absolutely no evidence whatsoever that there is a hardware flaw with the chip, a crash of the ram disk file handler does not mean the ram chips are bad. Any and every program can be using ram, so if the chips are flawed, any program could crash due to a ram error. If the ram chips were defective, the problems associated with it could be slowdown, data loss, random program crashing and misoperation, or a complete system hang. The RAMLIB is a task, and all I was saying is that to consistently crash the Ram-lib a program is making an error with the ram disk, or a program that deals with the ram disk. Many programs use the ram disk unknowingly since T: is assigned to ram:, and is used by some system functions. For example, preferences (and MUI prefs) uses the RAM disk for the ENV: directory. I don't think you understood what I was saying. Someone brought up the possibility a ram chip was flawed, and I was simply trying to say this would not consistently cause a ram-lib error, associated with only MUI. MUI is the problem, and not in its allocation of memory, but likely in its handling of RAM-based files. With MUI's history of being fairly buggy, I think its hard to claim MUI can't be the source of the problem. I've gotten MUI to work alright on my 3000 now, but have had crashes in the past, and I have also heard from many other people that have had it cause intermittent problems, mainly if they are running any other specialized commodities or whatever.