Yeah, I feel ya. I've got a situation where WTO's are being issued from a
CICS exit, and they too are malformed. Someone is supposedly working on
stitching together long, broken messages into a real MLWTO instead of the
mess it currently produces.

This is somewhat older SHARE handout that discusses MRT and clever uses of
(PIPE) EDIT statements:
https://share.confex.com/share/117/webprogram/Handout/Session9918/Session9918-NvEditLang.pdf

I've been working on standardizing local "eye catching" messages into more
useful formats using MRT rules, and don't mind sharing a snippet of what it
can do. This example boils down a "loose" WTOR to the necessary items that
the automation table and subsequent routine can use:

UPON (MSGID = '***')
  SELECT
*---------------------------------------------------------------------*
* Original:                                                           *
* 000 *** MTOREPLY *** ** OLS ? ? EXECUTE ? PROC                      *
*                                                                     *
* Revised:                                                            *
* 000 AOIMS9019A <jobnum> <member>                                    *
*---------------------------------------------------------------------*
    WHEN(WORD 3 NW   WORD 6 NW   WORD 9 NW   = 'MTOREPLY OLS EXECUTE')
      REVISE(WORD 1       1
             'AOIMS9019A' NW
             WORD 1       NW
             JOBNUM       NW
             WORD 11      NW
             'REVISED*'   AUTOTOKEN
             'Y'          AUTOMATE)

Although it doesn't include it, verifying it is a WTOR can be done with
interrogating WQE: WHEN(WQE SUBSTR 345.1   ¬= '00'X)

There are several other revision statements in the UPON group, but this
example has a good mix (IMO) of selecting keywords, revising message text,
and marking (via AUTOTOKEN) the message for later followup with the support
team to produce more meaningful messages.

Maybe there's enough elements to work with in your malformed messages to
overcome some of the issues you face, but maybe not.
Regardless, good luck!

On Tue, May 3, 2022 at 5:19 PM Mark Jacobs <
00000224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> We do, but these WTOs are malformed and Netview can't process them. I was
> hoping that MPFLSTxx would be more flexible.
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
>
>
> ------- Original Message -------
> On Tuesday, May 3rd, 2022 at 6:14 PM, Steve Horein <steve.hor...@gmail.com>
> wrote:
>
>
> > Do you have any automation products available for use?
> >
> > NetView has the Message Revision Table that can change a number of
> message
> > attributes.
> >
> https://www.ibm.com/docs/en/z-netview/6.3.0?topic=npaf-message-revision-table
> >
> > It's been awhile since I've worked with OPS/MVS, but I see it has quite a
> > few options as well:
> >
> https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/14-0/using/using-ca-ops-mvs/using-easyrule/specify-actions-to-be-taken-when-a-rule-executes.html
> >
> > On Tue, May 3, 2022 at 12:14 PM Mark Jacobs <
> > 00000224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Am I right in my thinking that without a user exit attached to a
> specific
> > > message, adding a message ID to MPFLSTxx can't alter any attributes of
> the
> > > message and how it's displayed on the console.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted
> > > email.
> > >
> > > GPG Public Key -
> > >
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > >
> > > ----------------------------------------------------------------------
> > > 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
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to