Hi Jim, I think you can use SCC(Sterling Control Center) to monitor the C:D process. You can define role in the SCC and if any error in the process the console will report the error and will send an email to you.
Or you can write a more notify step after you file transfer step. You can refer to below sample as one of our customer use: step1 copy step2 if step1 return code > 0 sub task 2010/12/18 Joel C. Ewing <[email protected]> > To avoid burning unnecessary CPU cycles, high frequency messages may be > completely suppressed from even going to an automation product at the z/OS > level via a PARMLIB member. This suppression support is at the message ID > (first "word" of the message) level, so a distinct msgid for messages of > "concern" is required to take advantage of it. We haven't done any > comparison tests for a long time, but the savings from automation > suppression with Netview were noticeable when we first started using it. > Products should use message ID conventions with this in mind. > Joel C Ewing > > > On 12/17/2010 12:26 PM, Ron Hawkins wrote: > >> Jim, >> >> Not that I have written much automation code, but wouldn't it be simpler >> just to check for the characters "COMP" in the positions 1-4 of the >> message >> text, and then branch your automation code accordingly? There's nothing >> terribly inefficient in that. >> >> Ron >> >> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] On >>> >> Behalf Of >> >>> Jim Marshall >>> Sent: Friday, December 17, 2010 9:09 AM >>> To: [email protected] >>> Subject: [IBM-MAIN] Connect:Direct Needed Enhancement >>> >>> Need some assistance from those running Connect:Direct for z/OS from >>> Sterling Commerce (who is now IBM). The way C:D reports the success or >>> unsuccessful transfer of files is by putting out a SVTM052I message. >>> For >>> example >>> >>> Successful - SVTM052I COMPLETED 00000000/SCPA000I >>> >>> Unsuccessful - SVTM052I #### COMPLETED 00000008/SVSA909I >>> >>> Monitoring these in any kind of System Automation software causes >>> >> excessive >> >>> overhead by having to trap SVTM052I and then parse down to either the >>> return code or maybe the ####. My suggestion is either to change errors >>> >> to >> >>> SVTM052E or maybe duplicate the unsuccessful SVTM052I message with a >>> SVTM052E to make it transparent for those who maybe are parsing the >>> message. >>> >>> We do many, many, etc, transfers per day and would like to "efficiently" >>> automate the monitoring of these using our System Automation product. If >>> you are a Connect:Direct installation, agree with the need, contact >>> >> Sterling >> >>> Commerce (IBM) and support my problem report of 256333. >>> >>> Thanks Jim Marshall >>> >>> Jim Marshall, Software Engineer >>> Washington DC 20415 >>> >> ... > > -- > Joel C. Ewing, Fort Smith, AR [email protected] > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
