Conference azur::mcc

1088.0. "Elimination of PLIB (runtime, anyway)" by TOOK::SWIST (Jim Swist LKG2-2/T2 DTN 226-7102) Mon Jun 03 1991 17:24

   As I mentioned in an earlier note, we are going to be eliminating the use
   of PLIB (the emulated VMS RTL) on MCC/Ultrix.  PLIB provides us with very
   little added value for the amount of overhead in virtual memory (200 to
   250k=b per mcc exe on MIPS/Ultrix).  In addition, it is a  proprietary
   library whose use we must eventually eliminate as we port to other open
   systems platforms (OSF/1, System/V, etc).

   The first phase of the elimination of PLIB will be taking place this week
   to eliminate the runtime use of libplib.a and libots.a.   We will
   continue to use the message compiler and the definition system for CVRs
   and their fields until such time as someone gives us a portable way of
   handling the same.

   We have tried to make the elimination of PLIB as easy as possible;
   however, there are a few changes necessary.   All groups will have to
   change at least their .make files, and possibly a few minor code changes,
   as indicated below:



   Implementation

   The following VMS library routines now have mcc, rather than plib
   equivalents:

                 old routine               new routine

	   *	plib$concat 		mcc_str_concat
	   **	lib$show_vm 		mcc_show_vm
		lib$signal 		mcc_signal
		str$append 		mcc_str_append
		str$prefix 		mcc_str_prefix
		lib$sfree1_dd 		mcc_sfree1_dd
		str$free1_dx 		mcc_sfree1_dd
		lib$sget1_dd 		mcc_sget1_dd
		str$get1_dx 		mcc_sget1_dd
		str$element 		mcc_str_element
		str$copy_r 		mcc_str_copy_r
		str$copy_dx 		mcc_str_copy_dx
		sys$getmsg 		mcc_getmsg
		lib$sys_getmsg 		mcc_lib_getmsg
		lib$sys_fao 		mcc_sys_fao
		lib$sys_faol 		mcc_sys_faol
		sys$faol 		mcc_sys_faol
		lib$scopy_r_dx 		mcc_scopy_r_dx
		lib$scopy_dxdx 		mcc_scopy_dxdx
		str$compare_eql 	mcc_str_compare_eql
		str$find_first_in_set 	mcc_str_find_first_in_set
		str$find_first_not_in_set mcc_str_find_first_not_in_set
		str$case_blind_compare 	mcc_str_case_blind_compare
		str$compare_multi 	mcc_str_compare_multi
		str$translate 		mcc_str_translate
		str$upcase 		mcc_str_upcase
		str$match_wild 		mcc_str_match_wild
		str$compare 		mcc_str_compare
		str$trim 		mcc_str_trim
	    **	lib$init_timer 		mcc_init_timer
	    **	lib$show_timer 		mcc_show_timer
	    **	lib$free_timer 		mcc_free_timer
	
             * = arglist is different than str$concat, hence it replaces
                 plib$concat, not str$concat

            ** = defined, but return MCC_S_NORMAL without doing anything.


   Note that the string routines in general do NOT support class VS
   descriptors, except for routine str$append, because fcl needs it. We
   recommend using only class S and D descriptors.


   Step by step procedure for each component:

   1) File mcc_descrip.h contains the above redefinitions.  You do not need
   to make wholesale changes in called procedure names.

   2) With the exception of str$concat, as mentioned above, we have reverted
   to the VMS calling sequence for all routines that formerly required plib$
   equivalents.   In every case except str$concat, the reason the routine
   name had to be changed was that the VMS routine had optional trailing
   parameters which cannot be supported portably.   But since the mcc
   versions don't have to be as general, we are simply requiring that all
   parameters be supplied and we have reverted to the original name. This
   will result in fewer VMS/Ultrix #ifdefs.  Str$concat takes a true
   variable length arglist, so the argument count has to be inserted as the
   first argument - this is the only exception where a different calling
   sequence is required on VMS.   (My search of the source code found no
   cases where an RTL routine was being called with missing optional
   trailing parameters).

   So you must remove all things like:

                   #ifdef unix
                   #define str$trim plib$trim
                   #endif

   3) You must remove the reference to plib from the link command in your
   makefile by removing things like "$(PLIBA) $(PLIB)libots.a" from your
   links.  Don't forget to get both the VAX and MIPS link command lines.

   4) Do not remove the source reference to $(PLIB) for include files.  You
   will need it for stsdef.h (CVR fields).  You may also find that you are
   including strdef/libdef/ssdef.h even under Ultrix - there should be no
   further refs to SS$_/LIB$_/STR$_ symbols in Ultrix after this change but
   it won't hurt if you leave those #includes in for now.   Do not change
   anything with regard to message file compilation, if you have such
   things.

   5)  The following makefiles have already been done as part of testing
   this (or will be done by 4-Jun at 5 PM):

             ui_trm_descrip.make
             pml_descrip.make  
             par_descrip.make (no changes needed)
             common_build_descrip.make
             exec_descrip.make (no changes needed)
             dap_descrip.make
   	     ui_tbd_descrip.make 

   6) Source changes are needed if you make explicit references to CVRs
   returned by the VMS RTL.   All the above routines return MCC CVRs. A
   generic success test like "if (!(status&1)) barf" will work on both
   platforms.   I scanned the source code in the ut1.2.1 build area and
   found just a couple of stray references to SS$_NORMAL and a couple of
   references to STR$_TRU (other than references in VMS-only code). The mcc
   string routines return MCC_S_INSUF_BUF if you need to explicitly test for
   buffer too short. You will have to put this in an ultrix conditional if
   you must test for this case.

   The following components have already been changed:
   	
   	common_build
   	exec
   	fcl/pml/par
   	domain        (verified as needing no changes)
   	registration  (verified as needing no changes)
   	dap
   	tbd


   7) The first build with missing plib will be Tues night June 4.  Let me
   know if you have any problems making this.  By the end of the week we'd
   like to have a working system.


   Jim

    
    RE: message compiler...
    
    Hi Jim,
    
    You may want to contact Luk Ho (SMAUG::L_HO) for a way to have portable
    message definition/compiling.  She has implemented a portable
    programmable interface for Ultrix (soon to be back ported to VMS).  She
    may have some suggestions around which tools to use.
    
    ~Jon.

    Everytime I check out one of these things, it's missing one or both of
    the following things we've really come to depend on...
    
    1) arguments (FAO args in the VMS world).
    
    2) severity codes (warning, informational, error, etc).
    
    If I can find something that supports things things I'll look at it.

    Have you tried NAS Portability Message Text Facility (DECWET::MTEXT)?
    It seems to have all the things you needed.  Right now Mtext supports
    VMS, ULTRIX/RISC, so you may want to find out when it's going to be
    ported to ULTRIX/VAX.
    
    Luk