 |
|||||
|
As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Join the TIBCO Community
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community. | |||||
Focal Point 
Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point (FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READING
Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point (FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READING Read-Only TopicGo | Search | Notify | Tools |
| (FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READING | Login/Join |
| Silver Member |
Hi all, We have a bacth jobb which calls a focexec to rebuild several databases. The rebuild/s is/are done using reorg. When one of the database is "broken" we get "(FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READING" and the focexec just stops running. Is there anyway to by pass this and run the next database rebuild plus can we pick up this error message and send a mail as an alert to this problem. Running on Windows 2003 server, using wf 764. A message from the darks side, there is! | ||
|
| Virtuoso |
Sounds like broken pointers. You might be able to detect the condition via the CHECK option of Rebuild, to avoid starting a doomed rebuild reorg. (That could increase your run time by up to 50%, so you have to weigh that cost against the added control.) But more basic question is, how does the corruption come about. Are you doing direct updates when you s/b using SU? Is mirroring on or off? - Jack Gross WF through 8.1.05 | |||
|
| Silver Member |
Well, there is a jobb running in the background where data from files sent in are updateing the databases. At the same time users of the application are running reports and doing some updating of one or two databases. We running the whole thing under SU. This application is over 10 year old. The FOC198 error has been happening more often after upgrading to the current version of WF on the server. How can we secure that every database tht has to be under SU is under SU and that SU has control. I think the self recover function has a hole in it. What I mean is that I have found that sometimes a database that should be under SU is not, I notice this when we try and copy over the database in question and I do not get a warning that it is held by another process. What happens during a self recover? Does SU drop control over all the DB or are they still protected? A message from the darks side, there is! | |||
|
| Virtuoso |
SU really is quite an old protocol, and very sensitive. You noticed that the database sometimes is not locked by SU when copying it. This is a correct observation. SU will open the database when instructed and when done, it will close it again. So, the only way to keep the file locked and under SU control all the time is to have a connection to the su that opens the database and then sits and waits until forever. The other way to ensure that SU databases are under SU control and stay under SU control is to use file system protection mechanisms, allowing only the SU process full control. Furthermore, Rebuild jobs can only be safely performed on databases that are NOT under SU control. That goes for all rebuild operations, although sometimes a dump operations finishes with a seemingly correct result. I would advise not to do any rebuild operation on a SU controlled database. GamP
| |||||||||
| ||||||||||
| Silver Member |
Ok.. let go back a bit. When the rebuild job is run we have shut down SU and closed the application, only the rebuild job is running. When we have a look at the log (we echo the job to a file), we see what has happened. What we have to do is to create some kind of alert when we get a FOC198. Now the next question is how can the database get a FOC198. The appliction is under SU. We have been getting "FDS special operation has crashed". With this message SU has gone down, either it will self recover or not. It is at this point I am wondering if there is no SU and two jobs are trying to write to the database at the sametime. Does anyone know what happens when there is a "FDS special operation has crashed"? I have noticed that under normal operations that sometimes a database is not "locked" and it can be copied over when it should be under SU control. How to check that SU has full controll over all the databases that we have placed in the SUprof? A message from the darks side, there is! | |||
|
| Virtuoso |
Robert, The fact that SU does not seem to always keep the files in suprof open is correct (re my previous post). The wya I solved this for my client is to have file permissions set for all the focus files (or the directory where they reside) so that only the su machine can access them, and noone else. As for the crash of the SU, there can be many many reasons for that to happen. Maybe there is something logged in the hliprint.log file which resides in the wfs directory of the server. GamP
| |||||||||
| ||||||||||
| Powered by Social Strata |
 | Please Wait. Your request is being processed... |
Read-Only TopicFocal Point Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point (FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READING
Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point (FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READINGCopyright © 1996-2020 Information Builders
| View $GS_USERNAME's Public Profile |
| Add $GS_USERNAME to my Ignore List |
| View Recent Posts by $GS_USERNAME |
| Notify me of New Posts by $GS_USERNAME |