(I'm forwarding this to the list with Jerry's permission)

Subject: (Fwd) Re: Re[2]: Design for System CI vars

>From: Jeff Vance <[log in to unmask]>
>On Oct 1,  1:30pm, Paul Taffel wrote:

/snip
>>
>>     If I could define a system-level UDC-like function 'FUNCTION1()' then I
>>     could simply SETVAR VAR1 '!!FUNCTION1()' to make this available within a
>>     given Job/Session.  The 'FUNCTION1' UDC-function could simply be
>hard-coded
>>     to return a particular value, or could derive it by running a program,
>etc.
>
>True.  If we have "system level" functions (which could simply be a function
>declared within a system level UDC as you have described) then only the SM
>can change the functions.  All references to the function will be just
>like referencing a system variable.  Your setvar example causes VAR1 to
>track FUNCTION1, even if FUNCTION1 is modified.
>
>?? How do the rest of you tracking this topic feel about this ??

I find this quite exciting!  When used, any content would be passed to the
function as a byte string for de-coding/use by the function:

     SETVAR jerry !!My_Proc()    /*whatever the syntax would be*/
     ECHO !jerry('function data')

Couple of other things:  The setup would have to specify the library. A
dereference mechanism could provide the function name and location... A CI
error code would be added to indicate that the function name itself does not
exist in the library or the library is not accessable/etc. The function
itself could set a CIERR to some pre-defined specific values for conditions
such as bad values, etc., related to incorrect data in the arguments.

The internal table containing the plabels/etc., would go away at shutdown so
the users would have to re-set them as a part of the system startup.  Whos
to say this could not also be done at an account or user level as well.  As
such, you'd probably need a syntax similar to SETCATALOG to indicate
USER;ACCOUNT;SYSTEM and then track this in the internal table.  In this
manner a 'local' version of the same function can exist for users in
different areas under the same name....

Within the procedure I could then handle the process/user/account rules as
needed for the particular function, so the granularity can be more closely
tuned to the developers needs.... :)  Also, the VAR intrinsics would be
supported as well.

Given all the variations outlined on this thread with regard to
inheritance/etc.
perhaps this would provide a single methanism to help solve the variability...?

Anyway, just some more ideas to through in the pot.... (I've always been a
fan of OS-type procedure exists being available to the user to tailor
actions to meet their needs....:-)


/jf


--