Not unless the job is submitted and executed under the control of a 'parent' job that does not itself end in JCL error. E.g. Control-M might be able to handle this.
On 03/11/2019 08:41, Peter wrote: > Is there a way to write WTO even if the previous step ends in JCL error ? > > On Sun, 3 Nov, 2019, 8:58 AM Jon Perryman, <jperr...@pacbell.net> wrote: > >> > Is there a WTO module which can write a message (highlight message) on a >> >>> console based on the JCL previous condition code? >> >> I believe you are asking about the sample exit IEFACTRT on the CBTTAPE >> which issues a WTO for each step completion message. You can change this to >> issue the message as desired. >> >> Alternatively, as others mentioned, you can write an MPF exit for the step >> completion WTL message but you will need to parse the message for the >> completion code. >> >>> The message displayed by WTO just comes up but i want it to br displayed >> as >>> a RED colour message with outstanding message number to suppress >> by operator. >> >> You don't mention what message is already displayed. z/OS does not have >> such a message to the consoles. I suspect you already installed the >> IEFACTRT from the CBTTAPE. >> >> Message numbers imply WTOR which require a wait on the ECB (or delete the >> WTOR). You can issue the WTOR and WAIT from IEFACTRT mentioned above. The >> job will be paused at this step until the operator responds to the WTOR. >> >> If on the other hand, you want the job to continue, then forget about >> WTOR. Instead, you will want to use WTO. >> >> WTO & WTOR route codes and descriptor codes used to be documented in the >> first volume of the z/OS system messages manual. I suspect it is still >> documented there. These will help you determine the best way to get the >> results you want. >> >> Be aware that your messages may affect operator's who use the D R command >> because of message retention changes. >> >>> There is very little that you can NOT do with an MPF exit. The only >> restrictions are WAIT related types >>> of things, and even that isn't really a restriction, just a really, >> really good idea not to wait. >> >> Restrictions depend upon the message being issued. Some system recovery >> messages can and extremely restrictive and will require special handling >> (e.g. linkage=branch). Many messages don't have any restrictions. >> >> Jon. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
