Conference azur::mcc

MCC does not provide portable implementations of those
VMS system services and RTL rtns and discourages their
use.


sys$exit(and the C RTL exit ()) should *NEVER* be invoked
because it short-circuits the normal termination activitiies.
Besides blowing away MCC, it blows away VMS/PCA etc.  Remember
your mm may just be executing one of many threads in the current
process.

sys$getmsg and sys$putmsg are both VMS specific services
which are not available on other operating systems.
The user i/o device is "owned" by the MCC presentation manager.
All screen output must be performed by the PM (otherwise
its screen display gets corrupted.)  

MCC SRM discusses "exceptions" in terms of responses to
mcc_call_XXX.  This documenentation would be a good starting point for you.

lib$signal and lib$establish.  Again VMS specific.
The MCC architecture does *prohibit* signalling across
the MCC module interface.


For DECmcc v1.0 which is VMS specific.
The framework establishes a handler for each thread.
Conditions with severity of fatal force the thread to
be terminated but not necessarily the process.
All other conditions are "continued".  A sys$putmsg is
performed by the handler, as well.

Whenver the "main thread" is terminated, then the framework
alerts all the other threads to terminate as well
and terminates the process.

Same for v1.1


DEC has submitted a portable exception handling facility
to POSIX (modified modula-3 stuff).  It might be 
useful, but I am concerned about performance (C setenv, raise)
and the general intractability and non-determinastic
behavior from signalls emitted from various pts in a block of code.

Pete Burgess

Are there any similar limitations if MCC is used only by its callable
interface ? (I hope not...)

BTW: I suppose it is not possible to use threads mechanisms, MCC timers, ...
from the callable interface, unless you accept all these constraints.


				Thanks and regards,


							Pierre.

RE .1

I'm not convinced we are communicating effectivly.  On page 197 I see they
define something called a CVR which indicates success or failure.  On page
200 they say

  "The out_p arguement does not contain a reply (a response or an exception)
for a failure CVR. the CVR indicates the error directly".

Ok - when I get a CVR what do I do with it?

I assume this CVR is a scalar entity - probably a longword.  I want to
  (1) Check the severity of the CVR
  (2) Translate the CVR into a text string
  (3) display the text string in a log file or on the users terminal.
  (4)  possibly abort the application depending on the severity of the 
      problem described by the CVR
  (5) Possibly cause the VMS command procedure or the U* shell script to abort
      (again, depending on the severity of the CVR).

Can someone give me the numbers of the pages in the documentation that describe
how to do these tasks?

Let me phrase the question differently:  Attached is a program for VMS that does
the above tasks.  It contains two kinds of checking that I would like to 
translate into MCC

   (1) return status from OS calls
   (2) sanity checking on user inputs within the main program.

  How do I translate it to MCC?  

                               Sieg
---------------------------------------------------------------------------------
$ set def [.c]
$ if f$search("example.obj") .nes. "" then $ delete example.obj;*
$ message sys$input:/object=example
       .TITLE  Error Messages for Sample Facility
       .IDENT     'Version 1.0-00'
       .FACILITY   smpl, 1 /PREFIX=SMPL$_
       .SEVERITY FATAL
       noneoftheabove <Illegal option, it is none of the above>
       insufmem <Insufficient memory, adjust PGFLQUOTA and VIRTUALPAGECNT>
       missingcommand <No command or directive specified on command line>
       missingarg <Another argument is required on command line>
       allocfail <request to allocating !SL bytes of memory failed>/FAO=1
       .SEVERITY   INFORMATIONAL
       start <Starting Example "!AZ">/FAO=1
       aok <Everything is running as expected with no errors>
       allocatemem <Allocating !SL bytes of memory>/FAO=1
$ EOD
$ create exception_example.c
#include <stdio.h>
#include <string.h>
extern long lib$get_vm();
extern void lib$signal();
extern void sys$exit();
globalvalue smpl$_noneoftheabove;
globalvalue smpl$_missingcommand;
globalvalue smpl$_start;
globalvalue smpl$_missingarg;
globalvalue smpl$_allocatemem;
globalvalue smpl$_allocfail;
globalvalue smpl$_aok;
main (int argc, char *argv[])
 {
  lib$signal(smpl$_start,1,argv[0]);
  if (argc < 2) lib$signal(smpl$_missingcommand);
  else if (strcmp(argv[1], "allocate") == 0)
   {
     int mem; long status; char* memptr;
     if (argc == 3)
      {
       mem = atoi(argv[2]);
       lib$signal(smpl$_allocatemem, 1, mem);
       if ((status = lib$get_vm(&mem, &memptr)) & 1 == 0)
          lib$signal(smpl$_allocfail, 1, mem);
      }
     else lib$signal(smpl$_missingarg);
   }
  sys$exit(smpl$_aok);
 }
$ cc exception_example/debug/lis/dia
$ link/nodebug exception_example, example, sys$input:/opt
sys$library:vaxcrtl/share
$ xxx := $sys$disk:[]exception_example
$ xxx ALLOCATE 4565
$ xxx ALLOCATE 2100000
$ xxx ALLOCATE
$ xxx 

    The CVR for an mcc_call_xxx call must be either Response, Specialized
    exception, common exception, or a failure due to the call itself.
    Examples of failure would be the Time was set up incorrectly.  These
    failures are related to the call, and not the function that was
    dispatched to.
    
    If your code was dispatched to correctly, and a failure occurred, then
    that failure must be reported as either a common or specialized
    exception.
    
    Is this what you're looking for?
    
    Christine
     

    On many processors, including VAXs and Intel 8086s, there is a feature
    to trap what VAX people call exceptions.  Intel calls them software
    interupts.   An example of an exception would be divide by zero error.

    Both VAX and 8086 processors allow the user to specify a routine that
    will be called when certain exceptions - such as divide by zero -
    occur.

    Thus far we are independant of operating systems.  These are features
    of the CPU.  Since these are features of all the modern general purpose
    CPUs in wide use - I expect MCC to provide means of using these
    features.  Is this a resonable assumption?
    
    VMS allows you to use these features with LIB$SIGNAL and LIB$ESTABLISH.
    
    Please point me to the page number in the MCC manual which tells how to
    use these features from MCC so I can make my code portable.
    
                               Sieg
    

I just had a phone conversation with Pete.  Basically, MCC does not provide
exception handling facilities.  

If you get a erroneous return value from LIB$GET_VM (or some portable counterpart,
malloc perhaps) you will want to send a message to the client telling it
that you can no longer continue.

The client may choose to use some counterpart to LIB$SIGNAL. 

Pete recommended we assume that the client and server are

  (1)  to be written by different software vendors.
  (2)  running on different machines.


                                       Sieg

    Could I suggest you read some sections of the SRM, notably
    
    	4.3.2.2	Condition Values Returned and Handling of Replies
    	4.3.2.3	Explicitly Not Handled or Translated Conditions
    	4.3.3	Error Model and Exception Handling
    
    Note - section numbers are from v1.1 of the SRM
    
    Colin

The "Error Model and Exception Handling" section (4.3.3) also exists in
the V1.0 SRM.

If someone reading this Notes Conference is concerned about not having
SRM V1.1, don't be: None of the Base System DEVELOPERS have a complete
copy of it either (I believe there are several in existence, more when
they finally come back from the printers)...

    
    
    And two last things frequently forgotten in the design stages:
    
    	1) don't forget about handling of the the CVR mcc_s_alert_termreq
           which is the internal translation of an ^C (user requested
           termination of a command).
    
    	2) global wildcards are USUALLY processed by the PM unless the
           FM is unreachable or nothing is register, in which case it
           is passed down; you must handle this case and either support
           it or return an unsupported wildcard exception -- do not
           try and return it as an error (CVR), you have to keep in mind
           that the modules above you are based on the same error and
           exception handling model, and they handle errors (especially
           fatal ones) as specififed in the SRM
    
    The list of all expected CVRs across the call interface are documented
    in chapter 11 of the SRM under the CVR section of the mcc_call_function
    routine.