Conference azur::mcc

>- What more is changed ?

The T1.2.3 toolkit release notes have a section on upgrading from
V1.1 to {V,T}1.2.  We will check to make sure the one you
discovered is listed.

RE: .0

> But now, if we give a command using the PABX AM, we get an error message
> from DECmcc that the out_p validation of callargs failed.

  I suspect this is due to the FCL now sending you a Dynamic Descriptor
  for Out-P ... Your Validation Tables probably indicate that you will
  only accept a Static Descriptor -- Update your table for Out-P:

	{ CAV_V_DESC_STATIC | CAV_V_DESC_DYNAMIC };

  To accept both Static and Dynamic Descriptors.  BTW, You don't have to
  do anything special for handling Dynamic Out-P Descriptor.  The DECmcc ILV
  routines have been updated to processes Dynamic Descriptors transparently.

> We have discovered a few changes in the framework of V1.2 (Dev. Toolk.)
>
> - MCC_K_ATTR_PRT_CHAR  -->  MCC_K_PRT_CHAR
>   MCC_K_ATTR_PRT_STATUS  -->  MCC_K_PRT_STATUS

  Yup - you'll have to change these literals in your source code.
  This was to make life difficult -- Just kidding 8)


> - with validate call args (in the header files) you had to give the 
>   address of in_entity and attribute , but now it is the value of in_entity
>   and the value of attribute.

  No - these aren't passed by value -- the variables are really arrays.  When
  you port your MM to Ultrix, you'll find that you shouldn't pass an array
  with the "&" in front -- It will give you an error message.  Removing the
  "&" removes the error .. and works correctly on both VMS and Ultrix.

> - the LocalContext contains one variable more -> ReplyArg_error_status

  Yes, there is an additional argument in the Directive Specific section
  of the Local Context ... This is not in the Common section.  This argument
  is to be used when something goes wrong, and you MM needs to return an
  exception containing an MCC error code (MCC_K_DT_MCCError).  Previously
  the ReplyArg_p1 variable was used, but I thought it was confusing...Also,
  if you had already began using ReplyArg_p1 when you detected a problem, you
  would have to zero out its descriptor pointer before calling
  'mcc_desframe_append_error'.

> - Why are these things changed (to make life difficult) ?

  A good guess - but as you can see there are real reasons for these changes.

  DECmcc V1.2 is a big change.  We ported the Kernel and *all* MM's to Ultrix.
  The documentation was modified to reflect the difference between both VMS
  and Ultrix platforms.  The testing strategies was expanded to accomodate
  both environments.

  The port caused a wave of portability changes through the system.  We really
  tried very hard to limit the impact on existing MMs.

> - What more is changed ?

  Of the top of my head ...

  o The 'mcc_thread_create' routine has been replaced with 'mcc_thread_create2'

  o We are now using DECthreads.  In v1.1, your threads would run until they
    did I/O or gave up the CPU.  In v1.2, threads are timesliced ... at any
    moment your thread can be swapped out to execute another thread.  This
    may require you to use Mutex's.

  o We've added the Mutex routines -- which you'll need when accessing
    shared data between threads.  Because threads now timeslice, you can't
    be sure that your thread will complete an operation so shared data before
    another thread will run...you have to lock and unlock shared data to control
    access by multiple threads.

> - What we have to do to integrate ready (home developed) AM's in DECmcc V1.2.3 
>   (Must any code be changed) ?

  In general, you'll only need to recompile/link your MM's if you'll only
  be running on VMS.  If you intend to port to Ultrix, you'll have to make
  the same portability changes we did (these kinds of chagnes are documented).

  If you use threads, you'll have to make the changes I described above.


  Hope I've answered your questions.

  Keith

And no need to wait for the release notes.  As indicated in note 3.119,
the T1.2.3 release notes are available in

PPINC::DUA0:[MCC_KITS.MCC_V12_IFT]MCCTK012.RELEASE_NOTES

Hello,

I changed my table for Out-P and than compile and link my source.
If I go to DECmcc then I get the following (see below)

I have added a printf() statement in the first line of the 
MCC_WRIGHT__SHOW_IDENT() routine, but don't see that printf().
So I thought this acc vio is not caused by my AM.

Any help should be appreciated.

Regards 
	Henk



===============================================================================

$ man/ent
DECmcc (T1.2.3)

MCC> show wright .lta158_1 all ident

%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=03268009, PC=000B4CE4, PSL=03C00004
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC
                                                           000B4CE4  000B4CE4
                                                           0044FCB4  0044FCB4
                                                           0044FC50  0044FC50
                                                           000AA77D  000AA77D
                                                           00083FC1  00083FC1
                                                           0007E9B8  0007E9B8
                                                           0008DFB1  0008DFB1
                                                           000AA885  000AA885
                                                           000F1790  000F1790
                                                           000B346B  000B346B
                                                           000B31CB  000B31CB
                                                           000B3121  000B3121
                                                           000B2B63  000B2B63
                                                           000B2614  000B2614
                                                           000B2523  000B2523
                                                           001C6A5C  001C6A5C
                                                           001C7740  001C7740
                                                           001C6271  001C6271
                                                           001C9261  001C9261
                                                           001C8636  001C8636
                                                           001C573C  001C573C
                                                           001C3F84  001C3F84
                                                           000C6E82  000C6E82
MCC_MAIN        main                             8258      00000208  00001E3C
                                                           000056F7  000056F7
MCC_KERNEL_INIT MCC_KERNEL_INITIALIZE             163      00000027  0000572B
                                                           000056D2  000056D2
$

> - the LocalContext contains one variable more -> ReplyArg_error_status

  Yes, there is an additional argument in the Directive Specific section
  of the Local Context ... This is not in the Common section.  This argument
  is to be used when something goes wrong, and you MM needs to return an
  exception containing an MCC error code (MCC_K_DT_MCCError).  Previously
  the ReplyArg_p1 variable was used, but I thought it was confusing...Also,
  
    
    I am sorry but I used extensively Reply_Arg_p1 for errors
    type MCC_K_DT_MCCERROR but also for responses, and 
    exceptions with other datatype.
    
    I cannot accept this change easily because I would have to
    go through my all code and sort out what argument is
    an MCC error what argument is not.
    
    So, a simple question. Can I still continue to ignore
    ReplyArg_error_status and use ReplyArg_p1 in any case ?
    
    You said :
    "if you had already began using ReplyArg_p1 when you detected a problem, you
    would have to zero out its descriptor pointer before calling
    'mcc_desframe_append_error'." 
    and I do not understand the full consequences of this sentence
    and the 'its' :
    
     If I ignore COMPLETELY ReplyArg_error_status.
        
     Do I have to zero ReplyArg_p1, in this case I have no chance
     to get my MCC error back as I did in the past. Correct ?
     (Which means I cannot ignore this ReplyArg_error_status
     bye, bye  backward compatibility)
       
     Or do I have to zero ReplyArg_error_status ?
    
     Could you re-explain the impact of this change in the
     algorithm of the mcc_desframe_set_cvr_and_reply routine ?
    
     
       		Best Regards
    
    
    			Catherine

RE: .5

Catherine,

1) You may continue to operate you code as-is (with regards to the ReplyArg_p1).
   This change was done to separate out the multiple use of the Reply Arguments.
   Some groups were trying to reuse ReplyArg_p1 with append error and had
   some problems.

2)  What does mcc_desframe_append_error do?

  This routine will link a series of error status codes together; building
  a setof error codes.  It is passed the address of a pointer to a Descriptor
  and expects the pointer to be MCC_K_NULL_PTR the first time it is called.
  Typically, a descriptor pointer from the LocalContext block is used with
  routine; i.e., ReplyArg_p1

  Because the LocalContext block is calloc'd (allocated and initialized
  to zero) this pointer will be NULL if it hasn't been used yet.

  If the descriptor pointer is not null, then this routine *assumes* that it
  had already initialized it -- and proceeds to append another error status
  code to the link list of descriptors.

  If you were using a descriptor for something other than append_error, and
  suddenly called append_error with that descriptor, I would expect an
  ACCVIO -- because append_error wasn't the one to initialize the descriptor
  first, the link list pointers and such would be setup incorretly.

  So, if you want to *reuse* a descriptor (ReplyArg_p1), you must set the
  pointer to MCC_K_NULL_PTR first then call append_error.  Because you use
  the desframe memory allocation routines, the memory which was pointed
  to by the descriptor will still be deallocated.  The memory was put
  onto a list and freed by a single call ... mcc_desframe_free_alloc_list.

Once again -- this change DOES NOT affect anyones existing code.  It was just
a style change to eliminate some confusion.  I'm sorry if it came across
as a backward compatibility issue.

If there are still any questions, please ask

/keith

Henk,

Have you tried running you MM with the debugger?  Did you Show entry-point
get called?  When you get to your Show entry-point, be sure to type:

	Set Break/Exception

To allow the debugger to stop when the ACCVIO occurs, and

	Set Module/All

To include all the symbols in your MM, then type

	GO

When the ACCVIO occurs, type 

	Show Call

This will show you all the routines that were called up to the ACCVIO.
Only your MM routine names will show up, as the MCC Kernel is not shipped
as a Debug image.

----------

If you MM isn't even called, then there is a problem between the FCL
(dictionary/parse table problem) and the Information Manager/Dispatcher.

Please post your results, thanks.

Keith

Catherine,

    Maintaining backwards compatibility of toolkit source code is and
    always been EXTREMELY important to the toolkit team.  Although we
    cannot guarantee that we will always be able to maintain backwards
    compatibility, we can assure you that we will do everything creatively
    possible to avoid required change.  In the event that change is
    required, we will attempt to give you plenty of warning in advance.
    We will also attempt to ensure that you get more notice of kernel-
    related change.

    We do, however, encourage you to use the latest release of the toolkit
    for new development and welcome your feedback.  We expect to further 
    reduce the amount redundant code you need to maintain for the "starter"
    YOURMM in the future; this will make it easier develop new MMs and
    easier to preserve backwards compatibility.


Darryl

    Please note that putting a printf in your code at the top of you show
    all ident will NOT get you the first line in your module. To find out
    if your module is being called turn on the fcl log bits (define
    mcc_fcl_pm_log 8), this will show you when the call is made. The first
    thing in your module tht will be called is the init probe and log entry
    points. If you have an old dispatch table hanging around this means
    that it will find a bogus address for dispatching to your module.