I think that if you use *MSGALL, no need to use SET VMCONIO IUCV and SET
CPCONIO IUCV first. *MSGALL traps anything that would have been sent to
the console, regardless of what you SET to IUCV.
Stronger: if you'd have an active path to *MSG (e.g. WAKEUP (IUCVMSG is
active), the message classes set to IUCV will not be captured by STARMSG
*MSGALL but presented to *MSG.
*MSGALL was created for fullscreen CMS, so that CMS could get everything
that was not grabbed by programs like WAKEUP(IUCVMSG.
Kris Buelens,
--- freelance z/VM consultant, Belgium ---
-----------------------------------------------------------------------
2016-11-28 21:41 GMT+01:00 Michael Harding <[email protected]>:
> This might supply a good starting point:
>
> /*
> **
> */
> Address Command
> Parse value Diag(8,'QUERY SET') with 1 . 'VMCONIO' vms . ',' 1 . 'CPCONIO'
> pms . ','
> nl = '15'x
> Parse value Diag(8,'SET VMCONIO IUCV'nl'SET CPCONIO IUCV') with .
> Parse arg stuffs
> 'PIPE var stuffs|starmsg *MSGALL|spec 17-* n|stem dumb.'
> Parse value Diag(8,'SET VMCONIO' vms nl'SET CPCONIO' pms) with .
> Do i=1 to dumb.0
> Say i dumb.i
> End
> Exit 0
>
> --
> Mike Harding
> z/VM System Support
> /sp
>
>
> CMSTSO Pipelines Discussion List <[email protected]> wrote on
> 11/28/2016 12:32:58 PM:
>
> > From: "John P. Hartmann" <[email protected]>
> > To: [email protected]
> > Date: 11/28/2016 12:33 PM
> > Subject: Re: Capture rexx output with both CP and CMS commands
> > Sent by: CMSTSO Pipelines Discussion List <[email protected]>
> >
> > Alan, CMS does not trap commands that are forwarded to CP by the default
> > setting IMPCP on; nor explicitly by the CP command of CMS.
> >
> > I'd say SPOOL the console. Or perhaps read the manual.
> >
> > It is true that
> >
> > PIPE literal <command> | starmsg | ...
> >
> > will do as requested, but I'm sure something will go awry for this
> > unsuspecting newbee.
> >
> > On 11/28/2016 09:13 PM, Alan Altmark wrote:
> > > On Monday, 11/28/2016 at 07:06 GMT, Offer Baruch
> <[email protected]>
> > > wrote:
> > >> Hello everyone,
> > >>
> > >> I am new to the list and need some assistance...
> > >>
> > >> I am trying to capture the output of a Rexx exec. the Rexx contains
> both
> > >> CMS and CP commands...
> > >> I would like to capture this output into a stem variable...
> > >>
> > >> something like:
> > >> PIPE <run my rexx stage> | STEM output.
> > >>
> > >> At the moment i feel like i am in a dead lock...
> > >> I am unable to use the PIPE CMS command to run my rexx as the CP
> command
> > >> output will not be captured...
> > >> I am unable to use the PIPE REXX command as my rexx is not a stage and
> > > uses
> > >> "say" along with CP and CMS commands... it is not using 'OUTPUT'...
> > > causing
> > >> the output to hit the terminal and not the next stage of the STEM.
> > >>
> > >> I am aware that i can use the PIPE CMS and workaround the issue by
> using
> > >> the following inside my Rexx for CP commands:
> > >> PIPE CP <my cp command> | STEM var.
> > >> and then printing the content of var. using say...
> > >> the problem is i don't control the Rexx and i am trying to avoid
> forcing
> > > my
> > >> users to rewrite their scripts...
> > >>
> > >> All i am asking is to be able to trap the output of any Rexx exec no
> > > matter
> > >> what commands it uses...
> > >>
> > >> Say in TSO/Rexx you have the OUTTRAP function to help you do that...
> > >>
> > >> any ideas anyone? am i missing something?
> > >
> > > Start with
> > > PIPE CMS <their program> | STEM var.
> > >
> > > That will let you trap the output of any CMS or synchronous CP commands
> > > issued by their program. You can then massage that output to interpret
> it
> > > or reformat it. But much depends on the specific CP commands they
> issue
> > > and how they issue them. If they issue DIAGNOSE 8 themselves, you may
> not
> > > be able to trap it without using SCIF and PIPE STARMSG. But again, it
> > > depends on how they dispose of the output from DIAGNOSE 8.
> > >
> > > Asynchronous responses from CP must be trapped via STARMSG.
> > >
> > > Alan Altmark
> > >
> > > Senior Managing z/VM and Linux Consultant
> > > Lab Services System z Delivery Practice
> > > IBM Systems & Technology Group
> > > ibm.com/systems/services/labservices
> > > office: 607.429.3323
> > > mobile; 607.321.7556
> > > [email protected]
> > > IBM Endicott
> > >
> >
>
