Path: shared!uunet!pipex!mfmail!jfid
   From: jfid@mfltd.co.uk (James Fidell (x5320))
   Subject: Re: Currently running program's name
   Message-ID: <1992Dec17.182256.28935@mfltd.co.uk>
   Sender: jfid@mfltd.co.uk (James Fidell (x5320))
   Organization: Micro Focus Ltd., Newbury, UK
   References:  <1992Dec17.163135.2167@cc.umontreal.ca>
   Date: Thu, 17 Dec 1992 18:22:56 GMT
   Lines: 49


   In article <1992Dec17.163135.2167@cc.umontreal.ca>, lacs@ERE.UMontreal.CA (Lacombe Serge) writes:
   > 
   > 	Hi. I'm using Micro Focus 3.0 on a Unix server and i would
   > like to know if there is a fonction that return the name of the running
   > program?

   Unfortunately not.  It is possible, but it would involve linking C modules
   into the RTS, and it wouldn't work in future products.

So ? Isn't there already C code in the rts ? The rts has to know what the
ascii name of the program is, since if it couldn't find the entry point
it would have gone to disk to dynamically load it, assuming it wasn't
dynamically loaded in the first place, in which case......
So why not a simple little routine (e.g. CBL_GET_CURRENT_MODULE) that
would return the name(s) of the current module ?
   > 
   > 	Is there a way of knowing the number of parameters passed
   > to a subprogram?

   I assume that you want a function which takes variable numbers of parameters
   and has access to some information to tell it how to get at them.

   There isn't any way to do this directly.  One difficulty with the UNIX
   product (as opposed to the DOS version) is that in .int code, the RTS will
   not allow an incorrect number of parameters to be passed.  .gnt code doesn't
   do this check (for efficiency) unless you specifically turn it on using the
   "-N linkcheck" option when generating the code.

I thought that I was permitted to do what I pleased in terms of
passing parameters. That it was only when I tried to access them that
the rts would croak. Is this not so ?

   What I'd suggest you do is write the code so that the first parameter is
   the number of parameters passed, then the parameters, padded out with some
   dummy values so that the program will run in .int code and under Animator
   without problems.

   An alternative would be to pass parameters in a parameter block, declared to
   be big enough to hold the maximum number of parameters.  The first value in
   the parameter block would be the number of parameters which are valid.  This
   does have a benefit in that the parameter block can be interpreted in differing
   ways, depending on how many parameters there are.

A better solution would be a call (e.g. CBL_GET_PARAM_COUNT) which
would return the number of parameters actually passed. 


   > 
   > Thanks.

   S'okay.

   > 
   > Serge Lacombe,
   > Universite de Montreal,
   > 
   > lacs@eole.ere.umontreal.ca
   -- 
    "Yield to temptation --             |
     it may not pass your way again"    |     jfid@mfltd.co.uk
					|
	   - Lazarus Long               |              James Fidell


--
        Mike Kenny                             Shared Financial Systems
        uunet!shared!mikek                     Dallas, Tx 
        Phone: 214-458-3989                    Fax: 214-458-3876
        ------>>> everybody is entitled to their own opinions <<<------
        ------>>> these are mine and not those of my employer <<<------
-- 
        Mike Kenny                             Shared Financial Systems
        uunet!shared!mikek                     Dallas, Tx 
        Phone: 214-458-3989                    Fax: 214-458-3876
        ------>>> everybody is entitled to their own opinions <<<------