| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1713.1 | | TOOK::PURRETTA | | Fri Nov 22 1991 17:39 | 7 |
| When the PhaseV am receives a termination request (cancel)
it terminates the link and returns. (IO$_DEACCESS+IO$M_SYNCH QIO,
and deassign of the channel on VMS, close of the socket on Ultrix).
It's up to the other end to detect that the connection went away
and handle it.
|
| 1713.2 | Thanks. | COOKIE::KITTELL | Richard - Architected Info Mgmt | Mon Nov 25 1991 10:18 | 0 |
| 1713.3 | Another control-c question | MICROW::LANG | | Mon Feb 10 1992 11:39 | 18 |
|
Along those lines, we have an AM which uses DCE/RPC to send
requests to a management agent.
I thought that if a user was issuing a directive which did not
have multiple replies, that even though the control-c was issued
it would essentially be "ignored", since there is not NEXT request
on which to set the handle to CANCEL. Would a Control-c work this
way? From one of the earilier notes, it sounds like it might
terminate the blocked runtime call (which would be the rpc call.)
For some directives, our AM itself is the management agent, and
makes SQL calls. If a cancel comes in, is there a chance that
it would be propagated to the SQL call?
Thanks for your help.
Bonnie
|
| 1713.4 | SQL thread safe? | TAEC::SILVA | Carl Silva - Telecom Eng - DTN 828-5339 | Mon Feb 10 1992 12:16 | 9 |
| > For some directives, our AM itself is the management agent, and
> makes SQL calls. If a cancel comes in, is there a chance that
> it would be propagated to the SQL call?
For this do you use ULTRIX/SQL or Rdb? Is the API for Rdb thread safe?
The API for ULTRIX/SQL is not thread safe and you have to either protect it
with a lock or execute it in a seperate process.
Carl
|
| 1713.5 | Control C == mcc_thread_send_alert | MOLAR::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Tue Feb 11 1992 07:38 | 53 |
|
Bonnie,
When the FCL sees you type the Control-C, it sends an Thread Termination
Alert to the thread which is executing the current FCL directive.
The Thread PC could be anywhere ...
o In the DECmcc Information Manager / Dispatcher (waiting for the
scheduled time)
o In your AM code
o In a DECmcc Common Routine
o In an O/S runtime routine ... such as SYS$QIOW
The MCC_S_ALERT_TERMREQ status can only be returned from a DECmcc Common
Routine.
<<< Synthesizing the MCC_S_ALERT_TERMREQ >>>
In some cases you have to translate a specific O/S type of error condition
into the MCC_S_ALERT_TERMREQ yourself. For Example, if the PC was sitting
at a SYS$QIOW ... and the thread was sent an Alert, the QIO would abort
and return the SS$_ABORT code in the I/O Status Block. You would have
to test for this and translate the code to the MCC_S_ALERT_TERMREQ.
In other cases, you may have to put a wrapper around a piece of code.
You may need to defer and the restore the Alert mechanism ... then Test
to see if the thread has been Alerted to Terminate (mcc_thread_test_alert).
<<< The Call Handle and Thread Termination >>>
As far as the DECmcc Call Handle argument; If you can cleanup properly
from the MCC_S_ALERT_TERMREQ, then you can re-initialize (mcc_ahs_reinit)
and return the CVR directly to the caller. The caller should test for
the CVR and realize the call has been terminated, then test the Handle.
Because you reinit'd the Handle, it will not be "more" and the call is done.
If you choose not (or cannot) clean up, you must set the Handle to "more"
and return the MCC_S_ALERT_TERMREQ. The caller should test for the CVR,
and then check the Handle. If the Handle is "more" - the call must set it
to cancel and recall your MM ... you see the Handle is set to "cancel" and
clean up.
A bit long-winded, but I hope it helps ... 8)
/keith
|
| 1713.6 | More on 1713.3 | MICROW::LANG | | Tue Feb 11 1992 08:52 | 22 |
| RE: 1713.4
>For this do you use ULTRIX/SQL or Rdb? Is the API for Rdb thread safe?
>The API for ULTRIX/SQL is not thread safe and you have to either
>protect it with a lock or execute it in a seperate process.
We are using both ULTRIX/SQL and Rdb for VMS. I don't think Rdb is
thread safe, and we are planning to protect both implementations with
a lock. Thanks for the input
RE: 1713.5
This helps a lot, I didn't realize this is the way it worked.
Does anyone know how if thread alert is handled if the code is
executing an SQL call within the same thread?
I'm also wondering about how the alert is handling if the code is
in the middle of a DCE/RPC call. Is the thread alert a cma mechanism?
If so, then I would think the DCE/RPC would get notification of this.
thanks a lot.
Bonnie
|
| 1713.7 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Tue Feb 11 1992 08:57 | 9 |
| The rpc operation is alertable, but what rpc does with the alert you'll
have to ask them. If they do nothing to catch it then it will
propogate back up the call stack until it finds a handler (like in your
code). If it finds not the thread will be killed.
SQL is not integrated with CMA, its I/O is all process blocking
and non-alertable. The alert will therefore have no affect on the
operation. You will have to test for the alert yourself.
|
| 1713.8 | Yah but... | TAEC::SILVA | Carl Silva - Telecom Eng - DTN 828-5339 | Tue Feb 11 1992 11:34 | 25 |
| RE: .6,
> We are using both ULTRIX/SQL and Rdb for VMS. I don't think Rdb is
> thread safe, and we are planning to protect both implementations with
> a lock. Thanks for the input
Yes, I would use ther same technique for ULTRIX/SQL if you link the API
with your AM.
RE: .7,
> SQL is not integrated with CMA, its I/O is all process blocking
> and non-alertable. The alert will therefore have no affect on the
> operation. You will have to test for the alert yourself.
Yes, this is true since SQL uses its own ULTRIX I/O statements that
were not interpreted by the SQL pre-compiler and therefore are blocking (for
example, the real select is used instead of cma_select). So the alert will not
work while your AM is making an SQL call and you will have to check after for
the alert.
Or you can put the interface to SQL in another process which is a lot
of fun on its own if you have the time and patience.... 8-)
Carl
|
| 1713.9 | sys$qiow - ss$_abort is a hint that an alert may be pending | TOOK::BURGESS | | Thu Feb 13 1992 13:28 | 11 |
| re .5 is slightly wrong is one respect on VMS.
if sys$qiow returns ss$_abort or ss$_cancel, (or smg_... returns whatever
it returns when sys$qiow returns ss$_abortor ss$_cancel), then the multi-threaded
client is merely given a *hint* that there might be (probably is) a "pending-alert"
and the client *should* then explicitly test for a pending alert
(mcc_thread_test_alert()).
The modified thread-safe version of sys$qiow, catches any pending alert,
cancels the current i/o, sends another alert to the current thread, and
returns with the iosb status.
|