Many thanks... I have passed this info to my Windows admin (I am also the
Unix admin) as I have only noted this
problem so far on Windows based archives. He will be installing the
4.2.1.15 client on one of our windows boxes and
we will test for a few days. If there are no other negative issues, we will
probably jump to 4.2.1.15 client. Again, many thanks!

George Lesho
AFC Enterprises






Andrew Raibeck <storman AT US.IBM DOT COM>@VM.MARIST.EDU> on 01/09/2002 04:11:16
PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: George Lesho/Partners/AFC)
Fax to:
Subject:  Re: Return code=4 on scheduled backup


Archives are not considered successful unless every file in your file spec
is backed up successfully. If one or more files fail, then the archive
will be flagged as failed.

The idea behind this is that archives are for long-term storage, and that
if you are looking to store the files for an extended period of time, it
is important that they *all* get archived. Thus anything other than 100%
of the files being archived will result in the failed event.

For the next release, we are planning on handling this a little
differently:

Scheduled backup-archive client operations where all the files are
processed successfully will have a status of "Success" and a return code
of 0 (zero). If the operation was invoked from the command line (or
script), dsmc will return '0' to the caller.

Scheduled backup-archive client operations where the *only* problems are
skipped files will have a status of "Success" and a return code of 4. If
the operation was invoked from the command line (or script), dsmc will
return '4' to the caller.

Thus the return code can be used to determine which events had skipped
files (and thus require further investigation) and which did not.

Standard caveat: This information is being provided on an informal basis,
and does not constitute any formal announcement or commitment.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




George Lesho <GLesho AT AFCE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/09/2002 14:04
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Return code=4 on scheduled backap



I have two TSM servers Win2K at 4.1.5 and AIX 433 at 4.1.4.5 with clients
at 4.1.3 across the board. I get this error for the Windows clients
consistantly but not the AIX clients. I have reported this to Tivoli but
their first line support person is insisting that there is a comms loss
which will be relfected in the tsm error log (but isn't). This error
occurs
when doing the FIRST incremental or an archive and doesn't appear to occur
in subsequent incrementals.  If anyone has an apar or reference that I can
pass back to the Tivoli support person, I would appreciate it.

George Lesho
AFC Enterprises






"Rushforth, Tim" <TRushfor AT CITY.WINNIPEG.MB DOT CA>@VM.MARIST.EDU> on
01/09/2002 03:06:10 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: George Lesho/Partners/AFC)
Fax to:
Subject:  Re: Return code=4 on scheduled backap


When I tested the 4.2.1.15 client, the bug was fixed.  Are you sure it is
not a real failed schedule?

Any error messages in dsmerror.log or previously in dsmsched.log?

Tim Rushforth
City of Winnipeg