Conference cookie::archive_backup

    
    Hi,
    
    We currently do not support for the user to be able to create their
    own backup schduling.  I am lobbying to make this into the next
    version's new features list. (I could get vetoed...)
    
    It makes sense for the users to be able to customize the scheduling.
    
    If you think this feature is really necessary, can you do us a favor?
    Send a mail to our product manager, Judy Cross requesting this
    feature.  It will make stronger case if we get more input from the
    field and th customers.  We are in planning cycle for the next release
    right now, so get your input heard NOW.
    
    Masami
    
    	

>                       <<< Note 373.1 by COOKIE::MHUA >>>
>                  -< Would like to support in future release >-
>
>    
>    We currently do not support for the user to be able to create their
>    own backup schduling.  I am lobbying to make this into the next
>    version's new features list. (I could get vetoed...)
>    
>    It makes sense for the users to be able to customize the scheduling.
    
The backup jobs from the scheduler will often have a different flow in the
weekend due to other activities like batch jobs.

When the customer has a full scheduler license the backup jobs will be
embedded in the production job-flow.

What I'm trying to say is that you will have more than one scheduler job
for the backups of the same disk(s) / file(s).

It would be very convenient if these separate scheduler jobs could refer to
the same save-request definition, no multi-edits to change add, change or
remove a backup specification.

I'm not sure if this is is feasable in the current ABS structure.

If it is, please reply because then it makes sense to send Judy a mail with
an enhancement request.

Henk.

    
    Henk,
    
    We could do the following with the current ABS :
    
    request #1 :
    Create a save request specifying a data to save as "$1$dka0:" and make
     this run on weekly schedule (let's say FULL save on every Sunday)
    
    request #2:
    Create another save request with EXACTLY THE SAME data to save,
    "$1$dka0:" and make this run on daily schedule ( as INCREMETNAL save )
    You can setup scheduler "special days class" (scheduler feature - you
    have to do this on scheduler interface) to setup this to run only on
    Monday through Friday.
    
    Since the data object to save "$1$dka0:" is the same in both request,
    the request #2 will base its incrementals on FULL saves done with 
    request #1.
    
    Still, this may not give you the flexibility of all you are asking for.
    
    In that case, please let Judy know.  Make sure you provide some
    examples of how you envision it scheduled/running in your request.
    
    
    Masasmi

                       <<< Note 373.3 by COOKIE::MHUA >>>
    
    
>    Since the data object to save "$1$dka0:" is the same in both request,
>    the request #2 will base its incrementals on FULL saves done with 
>    request #1.
    
>    Still, this may not give you the flexibility of all you are asking for.
    
>    In that case, please let Judy know.  Make sure you provide some
>    examples of how you envision it scheduled/running in your request.

This is how I did the backup for a customer at this time.

What I was thinking of is having data object sets to which save request are
referring. Updating the data object set is then limited to one place with no
risk of incremental save requests getting out of sync with full save requests.

I'm not sure if that's feasable with the current ABS code structure.
It would not make sense to request a change that would turn parts of the code
structure upside down (essential functionality would be an exception to this).

The day classes of the scheduler allow for most if not all of the scheduling
options you'd like so the request would be more like a convenience request.
Question arrises if ABS will continue to use this scheduler, if not then you'd
be limited to what ABS offers now and that would definitely not be enough.

Henk.