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 |
I'm trying to handle in a proper way the canceling of a multiple-response to MCC$CALL. I thougth reading the SRM that : - If a MCC routine sends back to me a MCC$ALERT_TERMREQ status the normal processing is : - save my own context, - set handle state to "MORE" - return CVR="MCC$ALERT_TERMREQ" then the IM is supposed to call me back, setting the handle state to "CANCEL" I then : - get back my context, - eventually cancel calls to routines handling contexts (MIR for example) - perform all cleanings needed - reinit handle (handle state = "FIRST") - and return CVR="MCC$_CANCELED" In fact, all seems to behave like this, except that MCC never calls me back. When I return MCC$ALERT_TERMREQ, I just get the message : %MCC-E-ALERT_TERMREQ, Thread termination requested and then the MCC> prompt. So what's wrong ? Another problem : sending CTRL-Cs to MCC sometimes leads to unexcepted errors, I just give you two examples : 1 - Sending CTRL-C as soon as possible : - IM has not called me yet, - it performs the call normally (handle state is first, MCC$THREAD_TEST_ALERT returns FALSE) - I so perform the call normally (sends back MCC$RESPONSE, with handle state = "MORE") - but IM (or whoever) does not accept the response : DECmcc (T1.0.0) MCC> show member toto line * all char %MCC-I-CANCEL, Cancel %MCC-E-NOENTITY, No corresponding entity instance exists %MCC-F-TRM_FAILURE, Fatal MCC Error 2 - Sending CTRL-C just before returning to IM :sending a MCC$RESPONSE to IM with a CTRL-C unseen) - IM has called me, - I perform the call normally - CTRL-C occur but I don't mind, - I send back MCC$RESPONSE, with handle state = "MORE" DECmcc (T1.0.0) MCC> show member toto line * all char Member TOTO LINE TYTY Characteristics AT 29-MAY-1990 17:13:06 Examination of attributes shows: Line type = ETHERNET Critical State = Foreground Line Speed = 0 Interface Name = interface name %MCC-I-CANCEL, Cancel %MCC-E-NOENTITY, No corresponding entity instance exists %MCC-F-TRM_FAILURE, Fatal MCC Error Maybe MCC and CTRL-C are not good friends ? Pierre.
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
135.1 | more work needed | GOSTE::CALLANDER | Tue May 29 1990 17:28 | 14 | |
Pierre, Control C processing in T1.0 is what I would have to term as less than stable. We are working on getting it to work consistently through the system. It should be better in the EFT update kit, but I don't expect it to be perfect (too many modules involved). I will also append in response to this note two additional pieces of information regarding handling and debugging Ctrl-C. I hope these help. jill | |||||
135.2 | how to handle control C | GOSTE::CALLANDER | Tue May 29 1990 17:30 | 1710 | |
135.3 | debuggin | GOSTE::CALLANDER | Tue May 29 1990 17:39 | 196 | |
***Please note that this uses the EFT update new DCL syntax. From: TOOK::PETE::BURGESS "Pete Burgess, NMSE, LKG2-2/T02, DTN 226-5315 15-May-1990 1623" 15-MAY-1990 16:25:37.90 To: @user$49:[rhoades.dis]mcc_v10_pl.dis CC: Subj: ControlC/ALert debugging technique Here is a techique for tracking down problems with "Control-c being ignored by MCC somewhere..." Recall that the design operation steps are control-c -> generates an out-of-band ast which triggers the cc_daemon thread to send an alert to the main thread the main thread should restore invariants and bubble up the mcc$_alert_termreq cvr Given the symptoms of the alert cvr being converted to some other cvr, we are looking to identify the routine which performs an incorrect cvr translation... -------------Step A ----------------------------- #1 define the framework logical to signal alert events #2 startup up mcc, activating the debug #3 instruct the debugger to break on all exceptions. Now we can control the program execution points of interest... POLE> def mcc$framework_log 10 POLE> manage/enterprise/present=mcc$decw_pm/debug VAX DEBUG Version V5.3-017 %DEBUG-I-NOGLOBALS, some or all global symbols not accessible %DEBUG-I-INITIAL, language is C, module set to MCC$MAIN %DEBUG-I-DYNIMGSET, setting image MCC$DECW_PM %DEBUG-I-DYNMODSET, setting module MCC$DECW_PM DBG> set break /exception DBG> g Reading in class data ---------- Step B ------------------------ ( Now we enter control-c at the point in which we experienced an earlier problem) %DEBUG-I-DYNIMGSET, setting image MCC$KERNEL_SHR %DEBUG-I-DYNMODSET, setting module MCC$MTS_SMG %MCC-I-CANCEL, Cancel break on exception preceding MCC$MTS_SMG\OUT_OF_BAND_AST\%LINE 1123 ----------------Step c -------------------- Ok, now we tell the debugger to DO GO UNTIL the message mcc-i-alertrecvd is displayed... at this point the main thread will first become Alerted DBG> g %MCC-I-CANCEL, Cancel %DEBUG-I-DYNMODSET, setting module MCC$MTS_ALERT %MCC-I-LOG_EVENT, Logging event type 00000010 reported by thread (name = CC_Daemon, id = 00010002) at 15-MAY-1990 15:19:11.85 -MCC-I-RTN_ENTRY, Routine (MCC$THREAD_ALERT_SEND) called at PC = 000F5FD8 break on exception preceding MCC$MTS_ALERT\MCC$THREAD_SEND_ALERT\%LINE 391 DBG> g %MCC-I-LOG_EVENT, Logging event type 00000010 reported by thread (name = CC_Daemon, id = 00010002) at 15-MAY-1990 15:19:13.07 -MCC-I-RTN_ENTRY, Routine (MCC$THREAD_ALERT_SEND) called at PC = 000F5FD8 %MCC-I-LOG_EVENT, Logging event type 00000010 reported by thread (name = CC_Daemon, id = 00010002) at 15-MAY-1990 15:19:13.14 -MCC-I-SENDALERT, Sending Alert from thread (00010002, CC_Daemon) to thread (00010000, Main_Thread) at 15-MAY-1990 15:19:13.14 break on exception preceding MCC$MTS_ALERT\MCC$THREAD_SEND_ALERT\%LINE 421 DBG> g %MCC-I-LOG_EVENT, Logging event type 00000010 reported by thread (name = CC_Daemon, id = 00010002) at 15-MAY-1990 15:19:16.09 -MCC-I-SENDALERT, Sending Alert from thread (00010002, CC_Daemon) to thread (00010000, Main_Thread) at 15-MAY-1990 15:19:16.09 %DEBUG-I-DYNMODSET, setting module MCC$MTS_RMS %MCC-I-LOG_EVENT, Logging event type 00000010 reported by thread (name = Main_Thread, id = 00010000) at 15-MAY-1990 15:19:16.21 -MCC-I-ALERTRECVD, Alert Received by thread (00010000, Main_Thread) at 15-MAY-1990 15:19:16.21 break on exception preceding MCC$MTS_RMS\MCC$RMS_GET\%LINE 1752+110 ----------------------- step D ------------------------- Now show call shows the call stack! If there is a problem, then it is with one of these routines!!! So, we just set radix to hex and and set break points for all/most recent absolute return pc. and check the returned cvr DBG> sho call module name routine name line rel PC abs PC *MCC$MTS_RMS MCC$RMS_GET 1752 00000105 00100F2C MCC$DB_RMS_REC 00000000 000B2E9F MCC$DB_RMS_REC 00000000 000B4295 MCC$MIR_INST_KEY 00000000 000D0DD4 MCC$MIR_INSTANCE 00000000 000A8F35 MCC$MIR_INSTANCE 00000000 000A92AE MCC$MIR_INSTANCE 00000000 000A94E4 MCC$DICTIONARY_LOOKUP 00000000 000B631E SHARE$MCC$DECW_PM 00000000 00259561 SHARE$MCC$DECW_PM 00000000 00259421 SHARE$MCC$DECW_PM 00000000 0025DF33 SHARE$MCC$DECW_PM 00000000 00249893 MCC$KERNEL_PRESENTATION 00000000 000C2B19 SHARE$MCC$MAIN 00000000 00000BE1 SHARE$MCC$MAIN 00000000 000045A2 SHARE$MCC$MAIN 00000000 00000FB2 SHARE$MCC$MAIN 00000000 0000457D DBG> set radix hex DBG> set br 0b2e9f,0b4295,0d0dd4,0a8f35,0a92a3,0a94e4 DBG> set br 0b631e,259561 Now we just Go; check r0 (return cvr) while (r0 = alert-termreq) DBG> g %MCC-I-LOG_EVENT, Logging event type 00000010 reported by thread (name = Main_Thread, id = 00010000) at 15-MAY-1990 15:20:31.84 -MCC-I-ALERTRECVD, Alert Received by thread (00010000, Main_Thread) at 15-MAY-1990 15:20:31.84 %DEBUG-I-DYNMODSET, setting module MCC$DB_RMS_REC break at MCC$DB_RMS_REC\MCC$DB_RMS_GET\%LINE 6104+0B DBG> ex /cond r0 MCC$DB_RMS_REC\MCC$DB_RMS_GET\%R0: %MCC-E-ALERT_TERMREQ, Thread termination requested DBG> g break at MCC$DB_RMS_REC\MCC$$DB_NXT_ENTDEF0_REC\%LINE 6951+0B DBG> ex /cond r0 MCC$DB_RMS_REC\MCC$$DB_NXT_ENTDEF0_REC\%R0: %MCC-E-ALERT_TERMREQ, Thread termination requested DBG> DBG> ex /cond r0 [1K DBG> g %DEBUG-I-DYNMODSET, setting module MCC$MIR_INST_KEY break at MCC$MIR_INST_KEY\MIR$INST_NXT_ENTDEF0_REC\%LINE 6488+0F DBG> DBG> g DBG> ex /cond r0 MCC$MIR_INST_KEY\MIR$INST_NXT_ENTDEF0_REC\%R0: %MCC-E-ALERT_TERMREQ, Thread termination requested DBG> DBG> ex /cond r0 [1K DBG> g %DEBUG-I-DYNMODSET, setting module MCC$MIR_INSTANCE break at MCC$MIR_INSTANCE\MIR$$INST_NEXT_IDENT\%LINE 8715+0F DBG> DBG> g DBG> ex /cond r0 MCC$MIR_INSTANCE\MIR$$INST_NEXT_IDENT\%R0: %MCC-E-ALERT_TERMREQ, Thread termination requested DBG> DBG> ex /cond r0 [1K DBG> g break at MCC$MIR_INSTANCE\MCC$MIR_GET_IDENTIFIERS\%LINE 9179+2A DBG> DBG> g DBG> ex /cond r0 MCC$MIR_INSTANCE\MCC$MIR_GET_IDENTIFIERS\%R0: %MCC-S-DONE, Done servicing multiple response calls !*************************************************************************************************** DBG> ! so mir$$inst_next_ident erroneously converted DBG> ! an alert cvr to a mcc$_done cvr !*************************************************************************************************** DBG> ! DBG> exit = POLE> lo LEMMON logged out at 15-MAY-1990 15:22:39.95 | |||||
135.4 | handle state ? | TENERE::FLAUW | Thu May 31 1990 10:22 | 28 | |
Jill, I still have a question relating to the handle. When your AM is alerted in the middle of a multi-response call (handle = More), what is the correct processing ? 1- - save my context - set handle to MORE - return CVR = MCC$ALERT_TERMREQ I would then expect the client to call me back, with a canceled handle. That is what I have learned during the trainings 2- - clear my context - reinit the handle to FIRST - return CVR = MCC$ALERT_TERMREQ Thanks, Marc. | |||||
135.5 | both | GOSTE::CALLANDER | Thu May 31 1990 18:17 | 25 | |
you can do either number 1 or 2. The choice is up to you. In case 1 your code can simply set the handle to more and return the CVR. Then when you are called back, you entry point simply checks the handle state for cancel, and if so clean up and return. In case 2, when you see the alert, you simply clean up and exit. Each has their benifits. In case 1 all your clean up code can be centralized in one place, and you simply return on an alert and check for handle cancels. In case 2 you don't have to worry about being called back again, but throughout your module you will have to keep track and clean up. (My stuff actually uses case 2 so that I don't have to both maintaining all my context to clean up. But in looking through the code in the TRM there are still some places that DON"T handle this right. Upon seeing the alert_termreq we are NOT always remembering to check the handle and calling the modules back. I will make sure that this is QARed. One place I noticed this was in the WITH clause processing.. Hope this helps | |||||
135.6 | TOOK::STRUTT | Colin Strutt | Fri Jun 01 1990 18:19 | 28 | |
> I still have a question relating to the handle > > When your AM is alerted in the middle of a multi-response call (handle > = More), what is the correct processing ? > > 1- > > - save my context > - set handle to MORE > - return CVR = MCC$ALERT_TERMREQ > > I would then expect the client to call me back, with a canceled > handle. > > That is what I have learned during the trainings > > 2- > > - clear my context > - reinit the handle to FIRST > - return CVR = MCC$ALERT_TERMREQ Despite what reply .5 says, #1 is the one you MUST use. That is what was described in the training (as you point out). That is what is described in the SRM. I refer you to section 12.1.2. You might ask Ted Hupper to explain in more detail why #2 causes problems. Colin | |||||
135.7 | ? | TENERE::FLAUW | Tue Jun 05 1990 07:00 | 7 | |
Can you explain in this note why option #2 should not be used ? Thanks, Marc. | |||||
135.8 | I will find some clarification | GOSTE::CALLANDER | Tue Jun 05 1990 17:59 | 12 | |
Marc, I will try to get some one else, of Colins opinion, to answer this one. Because my AM does it as in option 2 so that I don't have to be called back. I was under the impression from Pete Burgess that this was allowed. I will make sure we get some one to clarify this. jill | |||||
135.9 | Why #1 and not #2... | TOOK::STRUTT | Colin Strutt | Tue Jun 05 1990 17:59 | 29 |
I've chatted with Pete Burgess, who's spoken to Ted Hupper. The reason for requiring alerts to be handled as in #1 and not in #2 relates to the desire that the code that is going to deal with the alert be the one that decides what to do. Specifically, the client may wish to continue with the operation that was in progress (and call down with the same handle) to get the response for the interrupted operation, and THEN cancel the sequence of operations. This might be a case where the handle represents both a wildcard and a time sequence, but a desire that all the entities in the wildcard for a single time instant be completed before stopping. This means that the service provider (eg. the AM) is not aware of the needs (ie. policy) of the client. Therefore for the client to arbitrarily return WITHOUT the results of the extant directive, and with NO WAY to ever return the results, means that the client is limited to how they can handle the alert. Thus we documented it so that the service provider always returns the notification to the "top of the food chain" and let's the client (who was alerted) make the decision as to how to deal with it. It would seem reasonable that this discussion be documented in the Guide - I've skimmed my review copy and can't find it. However I will let the right people know, so the material can get added in to the document. Colin | |||||
135.10 | And what about TRM ? | TENERE::LAVILLAT | Wed Jun 06 1990 14:39 | 19 | |
First thanks for the explanations on this "philosophical" problem. Then Ok for solution #1, but there is still a practical problem. When I return a ALERT_TERMREQ CVR , with a handle state set to "MORE", TRM NEVER calls me back. I read in 135.5 : > But in looking through the code in the TRM there are still some places > that DON"T handle this right. Upon seeing the alert_termreq we are NOT > always remembering to check the handle and calling the modules back. I > will make sure that this is QARed. One place I noticed this was > in the WITH clause processing.. Is it "NOT always" or never, or is there still a problem elsewhere ? Pierre. | |||||
135.11 | still a problem | GOSTE::CALLANDER | Wed Jun 06 1990 17:34 | 5 | |
it is still a problem and won't be fixed until the EFT update release. jill | |||||
135.12 | T1.0.1: Still a problem ? | TENERE::LAVILLAT | Thu Jul 12 1990 09:52 | 64 | |
Here again... We are now running the T1.0.1 FCL and it seems that what was said in 135.10 still apply. Could you please tell us what policy for CTRL-C hanlding the FCL use, and what has changed in this EFT update ? By the way, testing CTRL-C leads now to new impredictable results coming from FCL, here some examples (obtained by typing CTRL-C just after the command) : GWENAE_$ mana/enter DECmcc (T1.0.1) MCC> show mcc 0 all char MCC 0 Characteristics AT 12-JUL-1990 11:35:56 Examination of Attributes Shows: Component Version = T1.0.1 Component Identification = "DECmcc" MCC> show mcc 0 all char %MCC-I-CANCEL, Cancel Characteristics AT 12-JUL-1990 11:36:03 Examination of Attributes Shows: Component Version = T1.0.1 Component Identification = "DECmcc" %SYSTEM-F-ABORT, abort %MCC-F-TRM_FAILURE, PM unable to continue GWENAE_$ mana/enter DECmcc (T1.0.1) MCC> show mcc 0 all char %MCC-I-CANCEL, Cancel %MCC-E-ALERT_TERMREQ, Thread termination requested No Such Attribute Partition Exists In The Dictionary AT 12-JUL-1990 11:36:40 %MCC-E-NOENTITY, No corresponding entity instance exists MCC> show mcc 0 all char No Such Attribute Partition Exists In The Dictionary AT 12-JUL-1990 11:36:44 %MCC-E-NOENTITY, No corresponding entity instance exists The first case was well known, but the second is new... Regards, Pierre. | |||||
135.13 | no dictionary pointer | GOSTE::CALLANDER | Thu Jul 12 1990 16:32 | 22 | |
The first case is new to me. I haven't seen MCC recieve a fatal error before there. The reason the PM terminated was due to the system fatal error that it received. The question is where did it come from? I will look into trying to reproduce this problem. The second item I found right before I left on vacation. My guess is that the fix Matt incorporated introduced this new problem. When first found the PM would access violate when attempting to call the dictionary routines because the dictionary pointer was not initialized. The problem happens when you start up MCC and then hit control C before the dictionary gets loaded. What happens is that the alert terminate is causing the dictionary load to abort. That is why the PM doesn't see anything for output any more. As far as control C processing goes we are still working on it across the entire system. Sorry for the inconvenience, and thanks for the input. | |||||
135.14 | alerts still wrong | GOSTE::CALLANDER | Thu Jul 12 1990 17:45 | 4 | |
By the way the alert CVR and MORE handle are still (in 1.0.1) not right. We are working on it. | |||||
135.15 | fixed in V1.0 SSB kit ?? | TENERE::DUNON | Paul Dunon - Telecom Engineering - VBO | Sat Oct 27 1990 16:02 | 6 |
As far as I could test, the problem described in this note (alert CVR and MORE handle) is not yet fixed in SSB V1.0 kit. Right ? -- Paul | |||||
135.16 | SSB - most modules compliant | GOSTE::CALLANDER | Mon Oct 29 1990 19:59 | 15 | |
I would be interested in knowing what you are having a problem with. It is true that not all modules were able to be SRM compliant for SSB but you should be able to get all commands to terminate (in some case you might have to ^C more than once). If you can't the input would be appreciated so we can document it. Since some modules were not fully compliant not all ^C's are seen, that is why multiple ^C's are now needed. If you are developing against SSB you should find the FCL is compliant in it's handling of ^C (just remember which ever module is actively running when ^C is hit is the one responsible for processing it). jill |