| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Having installed the TSAM V1.0 onto a T1.2.4 BMS system, I have tried
to implement a procedure to enable some DECserver alarming.
The original procedure enabled some decnet alarms, then the
decserver alarms - when the procedure starts the DECserver alarms in
sends the batch or interactive process into a RWMBX state. This was
after 31 alarms had been enabled.
I removed the DECserver entries and 60+ decnet alarms fired quite
happily, I then activate another procedure which is DECserver alarms
only and after the 4th DEcserver alarm (same as in previous procedure)
the process enters an RWMBX state.
Any pointers ?
%*)
Rex
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2378.1 | Try this | TOOK::FONSECA | I heard it through the Grapevine... | Fri Feb 21 1992 17:38 | 17 |
Rex- Sorry for the delay in replying. Would any of the DECservers you are alarming be hung or unavailable when the alarm caused the process to go into RWMBX? Unless you have an outrageous number of terminal_server's already defined, can you execute the following command in FCL: SHOW TERMINAL_SERVER * attribute where attribute might be PROMPT (or anything...I just trying to verify that you can get to all of the terminal servers you are alarming.) I'm grasping at straws, but just yesterday, the TSM developer finally was able to reproduce a bug which was causing it to hang, since TSAM is layered on TSM, this might be the cause. It appears that it usually happens when the DECserver is hung, unavailable, or its console port is busy. Of course it may be something else too... -Dave | |||||