[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 |
2634.0. "Detached process failure: Bad file number" by MICROW::LANG () Thu Mar 26 1992 09:00
I'm testing an AM I've written on Ultrix, and it is exiting with a
Bad file number. Does anyone have ideas about why? This
occurs after a DCE/RPC call, which returns the error connect_rejected.
I think this might be related. It seems that enrollment should
kill off the old process, and it says it does, but then I would
assume the newly created process would be fine.
thanks,
Bonnie
MCC> enroll mcc_tps_am
Killing existing MM mcc_tps_am (pid 8323)
Kill succeeded
%MCC-I-ENRDUPLENTRY, enrollment successful; duplicate entries found and replacd
MCC> Detached process failure: Bad file number
Detached process failure: Bad file number
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2634.1 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Fri Mar 27 1992 08:54 | 3 |
| I'm pretty sure this isn't an MCC message. Set a breakpoint at perror
in your AM and see if you hit it through some other subsystem (DCE?).
|
| 2634.2 | error handling provided? | MICROW::LANG | | Wed Apr 01 1992 09:58 | 11 |
|
Thanks. I haven't been able to reproduce this error, but will
try this as soon as I can. Can you tell me if its the PM or
part of MCC that is handling the error (printing out the message:)
Detached process failure:
thanks,
Bonnie
|
| 2634.3 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed Apr 01 1992 11:54 | 2 |
| It could be anyone.
|
| 2634.4 | Our bug | TOOK::BURGESS | | Mon Apr 06 1992 12:23 | 10 |
| This could be our bug in the "pm shell" module
which returns to the shell with the mcc status of MCC_S_NORMAL
of which the lower order byte is "9" which might e
be interpretted as EBADF. The code is being changed to return
0 (success) -1 (failure). The fix will go into bl x1.2.19
sometime this week.
\Pete
|