Conference iosg::all-in-1_v30

    The DSAB mechanism, accessible via scripts are fairly powerful.  Have
    they considered using the program(s) to build the script(s) and then
    execute them, say, in batch?

    Writing special code can be fun and can provide the speedy response
    time you desire, but it also come with a fairly steep price.  What do
    they desire to manipulate?  Everything?  There's "stuff" that ALL-IN-1
    does in the background that the "special" program may miss.  I opt for
    the dataset mechanism every time (well, almost ;*).
    
    My oa$TwoCentsWorth,
Dan

    Hi Paul,
    
    Sounds like a awful lot of work for little gain not to mention the
    maintenance of the software, especially when you consider the changes
    ALL-IN-1 has under gone over the years.
    
    What are their objection to using the sub-systems that are already in
    place ?
    
    Regards,
    
    Sunil

    Hi Sunil,
    	      The customer's main objection to using MUA is that it is time
    consuming because they have so many add/delete work to do.  I also get
    the impression that the site is short staffed, so the ALL-IN-1/VMS
    system manager would rather be doing something else other than user
    maintenance.  
    
    Thanks,
    
    Paul

Hi,

What is it about MUA that takes too much time?  If they mean they have too many
things to type in, then they could customise it very easily to provide more
defaults.  

If they mean that the MUA batch jobs take too long to run, then there isn't a
lot they can do about that; it's symptomatic of the number of things that
have to be created/deleted along with the user account.

Scott

    Hi Scott,
    
    The problem about being short staffed sounds familiar, I guess cost
    cutting gone to far syndrome :-}.
    
    I suppose what the customer could do rather than asking for a callable
    interface is to customise the option as Scott has suggested.  On the
    other hand if large sites are having problems maintaining a large user
    base in a PFR we could include the following feature.
    
    A housekeeping utility to delete, add user accounts.  Basically the SM
    or ADM would create a HK that would have a list of users to be added or
    deleted.  When the HK starts up it would access a datafile and carry
    out whatever was required.
    
    So this is another *WISH* what do ya think of that idea mate !!!
    
    Regards,
    
    Sunil

Sunil,

Half of your wish already exists:

>>  Basically the SM
>>  or ADM would create a HK that would have a list of users to be added or
>>  deleted.  When the HK starts up it would access a datafile and carry
>>  out whatever was required

This is exactly what SM MUA I <select users> XD does, so multiple deletes are
no problem.

As for multiple creates, they could customise ALL-IN-1 to:
    - provide a UI for entering multiple new user names
    - write those users to a datafile
    - write a script to access the datafile and invoke the create-user stuff

They could either use a script-script to drive the existing Create User UI,
which would be simple but not very efficient.  Or they could have a script that
itself does what the UI does, and calls MUA_CREATE; that's a
bit more complex, but more efficient.

As the customer claims to be technically competent enough to use a callable
interface, I don't think the second solution above would be too complex for
them.

Scott

    my infamous customer does something like this already. it was written
    many many moons ago. the people that add/delete users are not that
    "experienced" in ALL-IN-1 (supposedly this other interface is wasier
    for them to use). Also, each user has a unique UIC group number, so it
    would be difficult to do this in ALL-IN-1 without mucho templates.
    
    They call .COM files that call .EXE's that do WRITE ADDs to the PROFIL
    and the files in the OA OA.DIR are copied from the OA$LIB:USER.DIR.
    actually, its works pretty good. although it did need a major overhaul
    to work with 3.0.
    
    As far as deleting users, they  want each users account to be captured
    on a "full save" before it is deleted, so this interface maeks the
    account for deletion and another program deletes is after 40 days.
    
    	ann

    I just hope that the customer is willing to customize all the code
    that's included (for good reason) into the ALL-IN-1 SM procedures to
    handle items like groups and shared drawers.  If they don't then the
    danger exists that:
    
    -- Obsolete entries will be left in group definitions
    -- Drawers will be deleted from a system when users want to access
       data in them
    
    etc. etc. etc.
    
    They'd be better off concentrating on other areas of system management.
    They'd save more time and avoid the chance of messing up their system.
    
    FWIW, Tony