Hello everyone,

We are running ADSM server 3.1.2.50 under MVS OS/390 2.7

I have a user with high expectations pertaining to ADSM backup procedures
and I am not sure if ADSM is capable of meeting these demands.  Here are
some of the most important demands and concerns my user have:

1.      Before backup starts, ensure the machine to be backed up is active.
2.   Prior backup, shutdown databases and have an indicator flag or return
status code indicating failure or successful of the shutdown.
3.   The flag indicator or return code would be use to proceed with the
backup process or stop the backup process and inform Operations.
4.   Ability to page, email or both to inform someone about backup results.
5.   The backup process should also provide a return code to proceed or stop
the process
6.   After the backup process completes successful, bring online database
and return a condition code indicating the status of the database.  The
database must be available the next morning.
7.   Backup process should produce a report of backed up files or files that
failed the backup.  This information would be used by the on-call programmer
to troubleshoot the problem and should be available in a single report and
if possible accessible by remote access (Internet or other means).
8.   Operations department should be the centralized location for initiating
the backup process and information related to backups.

Currently my user have a backup procedure based on MVS TSO meeting most of
their backup requirements but is affecting the ADSM server due to the high
number of queries needed to monitor the status of the backups (see step3
below).  Following is the description of their current backup procedure.

Step1. Ping the physical machine.
This step is to ensure the machine is active before further actions are
taken.  If IP or the machine is not accessible, the job step fails and no
further action is taken.

Step2. Connect to the Oracle server to bring down the application.
Connect to the application via an Oracle agent.  The instance is brought
down once, brought up and brought down again to ensure the instance would
not have problems at bring up.  A return code other than zero would prevent
further actions on this machine.  The reason for using this procedure
instead of the pre/post-schedule ADSM commands is because the script used
for bringing down the databases could not confirm the status of the
database. There was no indication if the database was down or not.  ADSM
executed the script commands and continued with the backup process even if
the script procedure failed.

Step3. Backup databases using In-house written interface program.
This code was written part Assembler and COBOL and runs under TSO and in
TEST mode.   The program performs the following sequence of actions.

        a. Logs on to ADSM server as Administrator using TSO Admin client
        b. Defines an immediate schedule for the client using the DEFINE
CLIENTA command to Archive the database files.
        c. Queries the server every X number of minutes to find out the
status of the schedule
        d. At end of the schedule, queries ADSM Event logs for additional
information and returns a status condition code.
        e. Returns condition code for incremental backup failed files (ADSM
schedule returns COMPLETED even if there are failed files)

        note: We were contemplating using the Tivoli Data Manager for Oracle
but the user wanted the capability of directing the backups
                 generated by the Oracle backup utility to go, at their
discretion, to their locals drives instead of always sending the
                   backups directly to ADSM server.

Step4. Bring up the database.  Similar procedure to step 2.


This procedure works for a small number of clients but query overhead
(step3) to the ADSM server is enormous when there are numerous Oracle
clients running backups concurrently. Also, this procedure is dependant of
TSO and ADSM server may not reside on MVS in the future.  Another problem we
having is when a jobstream is cancelled by Operations or the job terminates
abnormally, the ADSM server can not remove (DEL SCHEDULE) the backup
schedule left behind by the jobstream and the ADSM server must be reloaded
in order to remove the schedule.

I would appreciate any good ideas you may have to improve my current backup
procedure or even better to completely innovate a different backup approach
as long as my user backup requirements are met. My mind is open for
suggestions.

Thank You, very much.

Note: We are in the process of installing Tivoli Enterprise manager but I am
not sure if that would help either.


Ulises A. Lopez
Senior Operating Systems Programmer
(305)596-8255