Hi Jeff,

I have four comments / questions on this nice new capability.

1.  First, and most important, is the matter of item number 6.  I want to be
sure I understand it.  Let's say I have a UDC named UDC1 and it invokes
function FUNC1 as follows:

IF FUNC1() THEN
...

Now my understanding is that one WOULD be allowed to redirect the output of
UDC1, but that then the output of FUNC1 would NOT be redirected.  Is that
correct?  Could one get around this as follows:

SETVAR BOOL1 FUNC1()
IF BOOL1 THEN
...

That is, would the output of FUNC1 be redirected in this case?  If so, I
think we can live with item 6, though it is obviously a major restriction.

2.  Could a function return different types under different circumstances.
For example:

PARM RETURN_TYPE = "I"

IF "!RETURN_TYPE" = "I" THEN
   RETURN 1
ELSE
   RETURN TRUE
ENDIF

3.  I think you have made a design mistake with item 7, although I recognize
that there is an efficiency concern here.  The reason it's a mistake is that
if a new built-in function were added to MPE, it could break code that calls
a user-defined function of the same name.  Perhaps a call to a user function
should look different than a call to a built-in one.  Then the CI knows what
to look for.

4.  If you decide to have functions which return VOID, then would you allow:

IF FUNC1() FUNC2() FUNC3() THEN
...

if one of these returns boolean and the other two return VOID?

Best wishes,

Jim


Jim Kramer
Director of Research and Development
Lund Performance Solutions
Phone: (541) 812-7600 | Email: [log in to unmask]
Fax:   (541) 812-7612 | Web:   www.lund.com
Yahoo: jhkramer_1     | AOL:   jh kramer 1

NOTICE:  This communication may contain privileged or other confidential
information.  If you are not the intended recipient or believe that you may
have received this communication in error, please reply to the sender
indicating that fact and delete the copy you received.  In addition, you
should not print, copy, retransmit, disseminate, or otherwise use the
information.  Thank you.

> -----Original Message-----
> From: OpenMPE Support Group [mailto:[log in to unmask]]On Behalf Of
> VANCE,JEFF (HP-Cupertino,ex1)
> Sent: Monday, September 22, 2003 1:56 PM
> To: [log in to unmask]
> Subject: SIB item #10 - CI functions
>
>
> Hi all,
>
> Way back we said that we were going to implement "CI Functions",
> which is one of the top 10 2003 SIB items.
>
> John Burke was careful in the wording of this SIB request:
>
>   "...the ability to call another script or UDC as a function that
>   would return a value using an enhanced CI RETURN command...."
>
> This means, to me, that we are not going to implement library functions,
> where binary user code is executed by the CI.  It also means, to me,
> that we are not going to implement sub-routine functions inside of the
> same script/UDC, like are provided by the POSIX and other shells.
>
> Here is how I see this request, from an external perspective.
>
> 1. the function returns a value, which can be a string (limited by
> the value size of a CI variable to 1024 bytes), Boolean, or signed
> 32 bit integer, in place of its name and arguments.
>
> 2. the function value will be returned via the CI's :RETURN command,
> which will have an optional expression arg added.
>
> 3. a function that does not explicitly return a value will either be
> an error (dislike), or will be void (prefer).  A void function would
> simply be executed inline and erased from the command line image.
>
> 4. a user function is located via the same mechanisms used to locate
> UDCs and command files/scripts. That is, HPPATH is used to find scripts
> and the UDC directory is used to find UDCs. UDCs have precedence over
> scripts of the same name. A script could invoke UDC and script functions.
> A UDC could do the same.  Option RECURSION UDCs would cause the search
> to start over at the beginning of the UDC catalog. "NoRecursion" UDCs,
> which are the default, would start from where the current UDC resides
> (in file order and user, account, system order).
>
> 5. a script or UDC can invoke itself as a function and today's nesting
> limits will apply.
>
> 6. (sadly) I/O redirection will not be supported for many function
> invocations. This is because the CI does not perform I/O redirection
> on the most important commands involved with expression evaluation,
> such as: if, elseif, while, setvar, calc.
>
> 7. function precedence order is that predefined functions take
> precedence over user defined functions. So, if you define your own
> "string" function, you need to name it some other name besides "STR",
> since the CI will always execute the built-in str() function.
>
> 8. user function names follow the same rules as UDC and script
> names as far as legal characters and the length of the name.
>
>
> Some examples:
>
> a. if my_function(a,b,c) > 5 then
>
> b. if rht(strng,-3) <> "A" and usrFunction() then
>        # usrFunction returns a Boolean true or false
>
> c. while word(usrGetInput("prompt")) <> "" do
>
> d. echo ![Get_reply()] ABC.   # function without parms, or
>                                 using default parms
>
> e. echo ![update_file(1,2,3)]ABC   # will display only ABC
>        # void user function
>
> f. if true and update_file(1,2,3) then  # cierr 9940,
>        # void user function             # non-bool expr found
>
> g. if myfunc.grp.acct(1,2,3) = "ab" then
>        # qualified function name, HPPATH not used
>
> h. if /usr/funcs/myFunc.f(1,2,3) = "ab" then
>        # qualified function name, HPPATH not used
>
> i. if ./funcs/myFunc.f(1,2,3) = "ab" then
>        # qualified function name, HPPATH not used
>
>
>
> Myself and Hariprasad, the engineer from Bangalore that will be
> implementing this new feature, encourage your feedback on the
> external characteristics and assumptions above.
>
> Regards,
>  Jeff Vance, vCSY