DE> Thanks, I am finally able to do that now. A major part 
 DE> of my problem was that the paths to some of my .inf 
 DE> files were incorrect.

I assume you realize that you can look at an INF file from the command
line?  By default, the VIEW program looks at the current directory and then
at the environment variables, particularly BOOKSHELF, for path info.  If
you want to look at a file manually, you can just change directory so that
it is in the current directory or specify the path explicitly: "VIEW
GUIREF20" or "VIEW C:\OS2\BOOK\GUIREF20.INF" will both work.

 MB> Hooking the Int 1Ch vector in DOS is by no means a 
 MB> "real time" facility.  As a matter of fact, the only 
 MB> thing that you get by hooking the Int 1Ch vector in DOS 
 MB> is a very primitive kind of multitasking.  

 DE> Yes, that is one of the things that I have done with the 1Ch timer.
 DE> But I also found that the tic was reasonably 
 DE> reproducible for timing purposes.

I would tend to disagree with that.  For one thing, the Int 1Ch timer under
DOS is called by the operating system.  When there is an application
program running, you may get no Int 1Ch ticks.  If you really need a
watchdog under DOS, you have to hook Int 08h directly, which is not simple
to do without destabilizing the system.  In any case, all of that nonsense
is totally unnecessary under OS/2, which provides real facilities for
handling this.

 MB>  There are even more extreme things you can do, such as 
 MB> setting PRIORITY=ABSOLUTE and adjusting the TIMESLICE 
 MB> parameter in CONFIG.SYS.  However, if you are writing a 
 MB> program that must have total control of the machine and 
 MB> you never want to allow anything else to run, then what 
 MB> is the point of using OS/2?  You would be much better 
 MB> off using DOS.

 DE> The objective here is to have the control process maintained
 DE> as the main priority of the system. However, if the operator
 DE> needs to view history files or edit a report then this is 
 DE> allowed.

OS/2 provides priority settings to handle this specific sort of situation. 
If the control process is that important, then it can be set to have
fixed-high or time-critical priority.  More accurately, since priority in
OS/2 is on a per-thread basis, the control process can have one or more of
its threads running at high priority.  Normal priority activities such as
editing or viewing files on a user console might be separate threads in the
control process or separate processes entirely.  Such normal priority tasks
will never be scheduled by the OS/2 kernel while there are any higher
priority tasks ready to run.  The usual architecture for this is to have
the higher priority tasks call DosSleep() or something similar that causes
them to block, allowing the normal priority tasks to run for a while.

 DE> The main process is very intelligent, even 
 DE> monitoring the disk for sufficient storage room. 
 DE> Logging is verbose and intensive which can result in 
 DE> several meg a day under extreme conditions. If the disk 
 DE> does not have sufficient room or some other system 
 DE> function is in jeopardy, the process will take whatever 
 DE> action is necessary to insure complete system integrity. 

That's no problem.  OS/2 can handle that quite easily.

 MB> In any case, how would abruptly rebooting the machine 
 MB> solve this?  If bad consequences would ensue from even 
 MB> a single missed interrupt, I would expect utter 
 MB> disaster to result from a reboot.

 DE> A single missed interrupt will not cause a diasaster, 
 DE> but several could be an indication of potential 
 DE> problems. The point is, if there is a problem it is 
 DE> quite likely to be caused by a program other than the 
 DE> control system and a reboot is a final resort method of 
 DE> trying to eliminate a potential threat to the system.

OS/2 does not work like this at all.  You are still thinking in DOS terms. 
Hardware interrupts in OS/2 are serviced by device drivers, and there are
no exceptions to this.  Device drivers under OS/2 are not subject to the
scheduler priority system, and will get almost immediate control of the
system when their registered IRQ occurs.  It is then the job of the device
driver interrupt handler to do whatever is necessary as quickly as
possible, stuff data into a buffer for the application level program to
retrieve when it gets scheduled, and return.

If you are hooking an interrupt in DOS in order to respond to a piece of
hardware that is asserting an IRQ, then you are going to need a device
driver under OS/2.  If, however, you are hooking interrupts in DOS which
are not tied directly to an IRQ, such as Int 1Ch, then you simply have no
need to take that approach with OS/2, since the native scheduling and
priority management will do exactly what you want without DOS-style tricks.

Since the interrupt handling in OS/2 is done by device drivers, your
application only sees the data buffer built by the device driver, and is
otherwise isolated from critical timing issues.  In other words, NO process
under OS/2 will be capable of preventing a device driver from handling IRQ
events, and rebooting is not the answer.  It is conceivable that the device
driver could fill its buffer or queue before the application is able to
read and remove the data, but this likewise is not the kind of thing that
you will solve by a spontaneous reboot.

On the other hand, if your high priority tasks are not being scheduled,
usually because there is some other high priority task that has started
running, then you will obviously be unable to detect this without hardware.
 In effect, you are saying that you want your high priority task to be able
to reboot if it is not being scheduled, but it will by definition have been
scheduled if it is even able to evaluate whether it has been scheduled. 
(This is known as the "computo ergo sum" principle of
multitasking.)

 MB> but I would not use it as a platform for, say, a life 
 MB> support machine.  Some of the things you describe can 
 MB> only be done properly with custom, triple-redundant 
 MB> hardware.  Even if OS/2 is the world's finest operating 
 MB> system, it will fail quite thoroughly if it happens to 
 MB> be running on a machine with a power supply that was 
 MB> soldered together by prisoners in a Chinese labor camp.

 DE> Granted, there are some things that will defeat the best laid plans of 
 DE> mice and men. The goal here is to provide the best 
 DE> quality hardware to suit the owners budget (I doubt that a farmer would 
 DE> be willing to shell out an extra $100k for triple 
 DE> redundancy to water his crops). He still expects the 
 DE> system to work without his having to babysit it. 
 DE> Therefore, on top of the hardware is a layer of well 
 DE> thought out control software that takes into 
 DE> consideration the most obscure of Murphy's Laws. 
 DE> Finally, this control system is monitored by a small 
 DE> computer that does nothing but watch and notifies a 
 DE> remote operator by phone or radio if the process 
 DE> controller fails.

I recall that you said something about this all being a "MUST NOT
FAIL" system,or some such language involving all caps.  What you
describe is far from that class.  The safety of human life is not at issue,
and almost anything below that level is probably a reasonable job for OS/2.
 Still, using DOS-style techniques such as forcing a system reboot is not
usually wise.  If you do have a process that is allowed to spontaneously
reboot OS/2, then you need to structure this very carefully, even if the
machine is dedicated to your task.

You should also set REIPL=ON in CONFIG.SYS in case OS/2 itself traps, since
you are not always guaranteed that a reboot attempt will succeed.

 MB> OS/2 can be quite reliable and is a nice platform for 
 MB> control software of the general sort you are 
 MB> describing, but I would not trust my life to it.

 DE> Me either! But I strive to make my applications as 
 DE> failsafe as is financially reasonable for the customer.

OS/2 does have the native facilities to support what you want to do.

-- Mike


--- Maximus/2 2.02