Andrew,
Thanks for your reply. You said:
"But you can still tell if it didn't work by checking not only the
status, but the return code."
Check it where? The activity log of our test is shown below:
09/28/07 09:50:05 ANR2561I Schedule prompter contacting STLO-TSM01
(session
60556) to start a scheduled operation. (SESSION:
9)
09/28/07 09:50:16 ANR0406I Session 60557 started for node STLO-TSM01
(AIX)
(Tcp/Ip loopback(49801)). (SESSION: 60557)
09/28/07 09:50:22 ANR0406I Session 60558 started for node STLO-TSM01
(AIX)
(Tcp/Ip loopback(49802)). (SESSION: 60558)
09/28/07 09:50:28 ANR0406I Session 60559 started for node
ROCKY_ORACLE (TDP
Oracle AIX) (Tcp/Ip rocky.stlo.mercy.net(41234)).
(SESSION: 60559)
09/28/07 09:50:57 ANE4952I (Session: 60557, Node: STLO-TSM01) Total
number
of objects inspected: 72,787 (SESSION: 60557)
09/28/07 09:50:57 ANE4954I (Session: 60557, Node: STLO-TSM01) Total
number
of objects backed up: 152 (SESSION: 60557)
09/28/07 09:50:57 ANE4958I (Session: 60557, Node: STLO-TSM01) Total
number
of objects updated: 0 (SESSION: 60557)
09/28/07 09:50:57 ANE4960I (Session: 60557, Node: STLO-TSM01) Total
number
of objects rebound: 0 (SESSION: 60557)
09/28/07 09:50:57 ANE4957I (Session: 60557, Node: STLO-TSM01) Total
number
of objects deleted: 0 (SESSION: 60557)
09/28/07 09:50:57 ANE4970I (Session: 60557, Node: STLO-TSM01) Total
number
of objects expired: 20 (SESSION: 60557)
09/28/07 09:50:57 ANE4959I (Session: 60557, Node: STLO-TSM01) Total
number
of objects failed: 0 (SESSION: 60557)
09/28/07 09:50:57 ANE4961I (Session: 60557, Node: STLO-TSM01) Total
number
of bytes transferred: 50.35 MB (SESSION: 60557)
09/28/07 09:50:57 ANE4963I (Session: 60557, Node: STLO-TSM01) Data
transfer
time: 0.11 sec (SESSION:
60557)
09/28/07 09:50:57 ANE4966I (Session: 60557, Node: STLO-TSM01)
Network data
transfer rate: 430,529.40 KB/sec (SESSION:
60557)
09/28/07 09:50:57 ANE4967I (Session: 60557, Node: STLO-TSM01)
Aggregate
data transfer rate: 1,260.13 KB/sec
(SESSION: 60557)
09/28/07 09:50:57 ANE4968I (Session: 60557, Node: STLO-TSM01)
Objects
compressed by: 77% (SESSION:
60557)
09/28/07 09:50:57 ANE4964I (Session: 60557, Node: STLO-TSM01)
Elapsed
processing time: 00:00:40 (SESSION:
60557)
09/28/07 09:50:58 ANR0403I Session 60558 ended for node STLO-TSM01
(AIX).
(SESSION: 60558)
09/28/07 09:50:58 ANR2507I Schedule @99 for domain TIER1DR started
at
09/28/07 09:46:24 for node STLO-TSM01 completed
successfully at 09/28/07 09:50:58. (SESSION:
60557)
09/28/07 09:50:58 ANR0403I Session 60557 ended for node STLO-TSM01
(AIX).
(SESSION: 60557)
I don't see any warning message, or indication of a return code of 8 in
any of it's messages. A "q event * * node=stlo-tsm01" yields:
Scheduled Start Actual Start Schedule Name Node Name
Status
-------------------- -------------------- ------------- -------------
---------
09/28/07 09:46:24 09/28/07 09:50:16 @99 STLO-TSM01
Completed
09/28/07 23:00:00 T1_UNIX STLO-TSM01
Future
No indication of an problem there. A "q event * * node=stlo-tsm01
exceptionsonly=yes" returns:
ANR2034E QUERY EVENT: No match found using this criteria.
So a return code of 8 is not considered an exception. Can you tell me
how to detect this? The warning status of 8 doesn't seem to show up on
the server at all.
It does show up in the dsmsched.log:
Executing Operating System command or script:
/usr/local/bin/TSM-postschedulecmd.ksh
09/28/07 09:50:58 Finished command. Return code is: 1
09/28/07 09:50:58 ANS1903W The POSTCHEDULECMD command failed.
But since that file is local to the client only, that doesn't give me
any easy way to show it in daily reports.
Best Regards,
John D. Schneider
Sr. System Administrator - Storage
Sisters of Mercy Health System
3637 South Geyer Road
St. Louis, MO. 63127
Email: [EMAIL PROTECTED]
Office: 314-364-3150, Cell: 314-486-2359
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Raibeck
Sent: Friday, September 28, 2007 10:06 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Postschedulecmd exiting with non-zero return code
should fail backup schedule
If POSTSCHEDULECMD fails, the schedule shows up as COMPLETED with RC 8,
not FAILED. In general (excepting schedules with ACTION=COMMAND) RCs 0,
4, and 8 are considered "Completed" (successful), and RC 12 is "Failed"
(failed).
Chapter 7 in the client manual describes RC 8 thus:
"The operation completed with at least one warning message. For
scheduled events, the status will be Completed. "
By design, a POSTSCHEDULECMD operation that fails does not cause the
scheduled event to fail. But you can still tell if it didn't work by
checking not only the status, but the return code.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]
IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageMan
ager.html
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 09/28/2007
07:55:40 AM:
> Greetings,
> We are just testing using pre and post schedule commands on our AIX
> systems (TSM client 5.3.4.0, and TSM 5.3.4.2 server) and having a
> problem.
>
> We want a non-zero return code from either the pre- and post- scripts
> to show up the backup as a failure. According to the manual, a
> non-zero return code from the preschedulecmd will cause the schedule
> to fail with a FAILED 12, and a non-zero return code from the the
> postschedulecmd will cause the schedule to fail with a FAILED 8.
>
> We tested this with two simple scripts, and the a non-zero return code
> from the preschedulecmd does indeed cause the schedule to fail with a
> FAILED 12.
>
> But it doesn't work for the postschedulecmd. A non-zero return code
> still causes the schedule to complete successfully. Yes, we can tell
> the post script is running, since it generates a log of it's
> execution, including the return code it is producing.
>
> Has anyone else see this?
>
> Best Regards,
>
> John D. Schneider
> Lead System Administrator - Storage
> Sisters of Mercy Health System
> Email: [EMAIL PROTECTED]
