| 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 |
My customer developed an AM with a "LOAD" command to downline load his X.25
switches parameters. He's using X.25 communications (PSI) to implement this
feature. But if any problem occurs while loading the parameters, a liberation
message is sent into the network mailbox, and the SVC is broken asynchronously.
On VMS, the solution is to queue an asynchronous I/O on the network mailbox, and
handle the error with an AST routine. But I think that the usage of ASTs is
forbidden in a DECmcc AM.
The solution, I think, is to use two DECmcc threads, one with a QIOW on the NW
channel, another with a QIOW on the Mailbox channel. Can someone explain me how
we can synchronize the two threads and tell me where I can find some
explanations on the techniques used in this kind of situation.
Thanks.
Michel.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3965.1 | Chapter 18-5 in MM development book. | TAVIS::ORNA | Tue Oct 27 1992 05:17 | 6 | |
See chapter 18-5 in the MM Development book.
This chapter explains how to execute multiple tasks.
I hope this will help you.
Orna.
| |||||
| 3965.2 | Don't bother | MARVIN::COBB | Graham R. Cobb (DECNIS development), REO2-G/G9, 830-3917 | Tue Oct 27 1992 08:53 | 8 |
Just ignore the mailbox message. If the call is cleared then any QIO which is affected will complete with an error status (SS$_CLEARED or SS$_FILNOTACC). The customer can then just code the application to handle that error (they have to do that anyway as mailbox messages can be lost). Graham | |||||
| 3965.3 | We should be AST compatible | TOOK::GUERTIN | Don't waffle (unless you want to) | Wed Oct 28 1992 09:01 | 25 |
In an earlier release, MCC used its own home grown threads package,
that package was not AST-friendly. We did not support the use of
ASTs. As of V1.2, we are using cma, which can co-exist with ASTs.
Having said that, I don't believe we "encourage" their use. The
release notes may have more information, but basically, it is very
easy to fall into very large, very deep pits. For example, many of
the VAX-C rtl routines (such as calloc, malloc, free) cannot be
called from AST level. The problem here is that either you end up
calling the cma wrapper routine cma_malloc, etc., or the real lower
level C routine. Either you will hang (waiting for an AST at AST
level), or accvio. Likewise many cma routines will not work
correctly if called from AST level. Also, most (perhaps all) MCC
routines may hang if called from AST level. There are probably
other pit falls which I cannot think of off the top of my head.
So I guess the answer to using ASTs is:
1) Use them if you have to (it's not forbidden).
2) But, be "extra" careful out there.
As for techniques in synchronizing two threads. It sounds like a
parent thread can fork off the two threads doing qiow's and then
do a mcc_thread_join_any().
-Matt.
| |||||