Hi all,

Here is my reply to Jerry's comments re. system vars:

On Oct 11, 11:51am, Jerry Fochtman wrote:
> Subject: (Fwd) Re: Re[2]: Design for System CI vars

> >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.
> >

I replied to Paul:
> >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 ??
>

Jerry replied to  me:
> 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')

IMO functions, like above, do not fulfill all of the "needs" that we
(sort of) established in the beginning, namely:

1) SYSTEM VARS:
"Primary usage will be easy-to-use, efficient and simple interjob/process
communication (IPC).  Many customers have expressed a desire to
use this type of IPC facility for security purposes.  For example:
a system level logon UDC creates a shared system variable that the production
applications interrogate as they apply business rules."

2) "SCRIPT" VARS:
"There are 2 major reasons to have local variables: 1) a script using local
variables will not overwrite a variable of the same name in the job/session
scope, 2) the local variable cannot be changed by other processes in the
same job/session."

I think the idea of user-defined CI functions at various levels (like
system, account, user) is really good, but how do you do efficient
IPC without a common storage mechanism?  One of the benefits of system
variables is support for pseudo "shared memory".  Sure, the functions
could use files for the common storage, but seemingly files are
not adequate else I imagine that system level variables would not have
received such a high SIC ballot vote.

The function work great from a security perspective but lack from an
IPC perspective, IMHO.


good points re. function support snipped...
> 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....:-)

I agree here too, but I don't see functions, as defined so far, as being
OS or even CI user exits.  Now we could let you define certain CI
reserved function names with the correct arguments to be an interface into
AIF:PE or something like that, but this is another topic...

Thanks Jerry for your comments,
Jeff


--