My reply to Paul's suggestions:

--- Forwarded mail from "Jeff Vance" <[log in to unmask]>
Hi Paul,

First of all good to hear from you!

On Oct 1,  1:30pm, Paul Taffel wrote:
> Subject: Re[2]: Design for System CI vars

>   - System-level 'Global' variables.
>
>     These could be made available without any change to the current system
>     variable implementation, by (finally) implementing a UDC-like CI function
>     facility.  I believe that we already spoke about the possibility of
allowing
>     UDC-like CI functions to be defined, and that you told me that they were
(at
>     one time) planned for.

Yes.  This is why we have not added any parms to the RETURN command -- we are
hoping that some day we can RETURN a value.

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


>     Any changes to the Function return would be visible within Job/Sessions
the
>     next time that they referred to the 'VAR1' variable.
>
>   - ACD-Like security for system variables.
>
>     I hate this idea!  Why not place SETVARs within a file that's executed by
>     individual users, and allow security to be provided by the file system.

I am leaning against ACD-like security since most comments say it is overly
complicated for the problem were are solving.  Stan suggested a simple way
of expressing a READ-ONLY1 var (SM can write), READ-ONLY2 var (SM and AM
can write -- implies we need to keep track of the creator of the var) and
READ-WRITE var (everyone can read/write it), WRITE-ONLY var (I need some
examples to see how this is useful!)

>
>   - Ability to survive System Reboots.
>
>     Unnecessary.  If I want this, I'd echo the SETVARs to a file, and XEQ it
>     from a Logon UDC.

Ok with me!

>
>   - Read-Only Variables.
>
>     I would have liked the ability to flag a variable as read-only.  This
>     would allow the secure passing of data from one program to another,
>     knowing that even if the user had CI-access, the data would remain
>     secure from modification.  Write-only variables only dereferencable
>     from PM programs might also be useful for password-passing.

Can you give me a few examples for write-only?

>
>   - Local Variables.
>
>     I'm sure you're aware of MPEX's local variables (SETLVAR, SHOWLVAR,
>     etc).  I don't really understand why the most-obvious (to me) mechanism
>     has not been used: Why not extend AIFCHANGELOGON to specify that a
>     'nested' logon be provided with an isolated set of System Variables,
>     inherited from the parent process?  The final 'icing-on-the-cake' part
>     of this would be....

I guess this is possible, but I *think* the overhead will be pretty high
compared to just having a local variable scope.

>
>   - Nested HELLO command.
>
>     Make the damn AIFCHANGELOGON features accessible to users from the CI,
>     by allowing nested-HELLO commands ('HELLO MANAGER.SYS;NEST') to be
>     issued from any CI.  Thereby making AIFCHANGELOGON features available
>     to the unwashed masses who don't have MPEX, and allowing access to the
>     'local variables' described above.

A you probably can guess this good idea is beyond the scope of my project.
I know that a Michigan State O/S (MTS?) supported an idea similar to this
where you could issue a PUSH command to save your current env,
then you can add file equations, temp files, variables, etc without
disturbing the previous env.  Of course a POP gets you back.

>
>
>   Well, thanks for the opportunity to get this load off my chest!  I hope
>   that somewhere in here are a couple of useful ideas.  I've been surprised
>   that there's not been more dialogue on TECH3000 in response to your
>   posts, I hope this doesn't mean that this will get forgotten.

Definitely not forgotten and I apologize for not responding to postings
quicker and not providing the next draft sooner.  I have a little less free
time than originally expected...

thanks,
Jeff

---End of forwarded mail from "Jeff Vance" <[log in to unmask]>

--