Forwarded to 3000-L with Paul's permission:

--- Forwarded mail from "Paul Taffel" <[log in to unmask]>

Date: Tue, 01 Oct 96 13:30:23 PDT

  Hi Jeff!

  I'm sure that all you need are a few more takes on how to implement
  System/Nested CI variables.  I'm not sure that I have an entirely coherent
  solution, but I thought of a few ideas that I haven't seen mentioned
  elsewhere.  Here goes:


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

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

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

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

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

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


  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.

  Regards,

  Paul Taffel
  Quest Software

---End of forwarded mail from "Paul Taffel" <[log in to unmask]>

--