Andrew,
Thanks, I see that now. That would work. Richard Sims also
pointed me in a private email to his QuickFacts, which points out that I
could also pull it from the RESULTS field in the EVENTS table, which
would be easier programatically.
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 2:11 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Postschedulecmd exiting with non-zero return code
should fail backup schedule
Hi John,
Use F=D with the QUERY EVENT command. That shows 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
12:08:43 PM:
> 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/IBMTivoliStorageM
> an
> 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]
