Bruce Martin's response, the reference to *multiline* messages, jogged my memory and a correction to my previous post is needed.
In the case of VTAM DISPLAY commands, there is a synchronous IST097I DISPLAY ACCEPTED response followed my a *single* asynchronous message which is in *multiline* form. In the case of DISPLAY NET,ID= the first message identifier is IST075I NAME = whatever-was-specified , TYPE = something - as a synchronous message - followed by a sequence of the messages you probably want to analyse all within the asynchronous multiline message. The sequence ends with the IST314I END line. That last point is what required the correction. All the above is good as long as there is not some sort of error in what is specified in the original command. Assuming you can set up some sequence of commands in TSO which allows a command to be issued and all potentially resulting output to be "picked up" so that you can analyse the text within the output, I recommend the following which I vaguely recall being my approach when processing messages from VTAM commands - or any commands with asynchronous output - in NetView. You need to set up a clist which issues any specified command and then note down the messages returned both when it works and when you deliberately enter incorrect variables. You need to work out which of the message sequences is a single line message and which multiline messages and, of course, whether synchronous or asynchronous. You should then code your intended clist to deal with all of the circumstances which might arise. And I find I have simply been advising programming "motherhood"! Chris Mason On Mon, 5 Apr 2010 21:58:15 -0500, Chris Mason <chrisma...@belgacom.net> wrote: >Bruce > >Alan is correct in that the "xxx ACCEPTED" response is actually a response to >the VTAM command and the output you really want to see is generated >asynchronously. > >Ideally you would be operating in a NetView environment. These days - for >very many years now - you could be using the NetView "pipes" function. This >came along after I used to work intensively with REXX in NetView with a >variety of commands including both MVS and VTAM. Consequently I relied >heavily and exclusively on the NetView facilities for picking up these >asynchronous responses centred on "wait" functions - potentially fully reliable >but tortuous to code and analyse. Generally, you specify the message >identifiers for which to wait - with a longish timeout in order to cope with a >sick system - and process each message as it arrives looping back in order to >wait for the next one until the last message is known to have arrived, IST314I >END in the case of a VTAM DISPLAY command. > >I'm afraid I can't advise on working in a presumed TSO environment. I just >hate having to stick a wet electronic finger in the air and estimate the delay >before which I just possibly might expect the response to appear which I >guess is what this fifth positional parameter of GETMSG is all about - ugh!!! > >Chris Mason > >On Mon, 5 Apr 2010 18:34:18 -0400, Bruce Schaefer ><bruce.s...@gmail.com> wrote: > >>Hello list, >>I have a rexx that issues console commands and writes the responses to a >>dd after using getmsg to retrieve the response. Everything is good for >>MVS commands and JES2 commands if L=Z is included. Is there a similar >>option for VTAM commands? For D NET,<options>, I am only getting: >>IST097I DISPLAY ACCEPTED >>I've tried adding the CART parameter to my emcs console and the getmsg >>with same results. >>Thanks, >>Bruce Schaefer >> >>-- >>/* >>//* Bruce Schaefer >>//* mailto:bruce.s...@gmail.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
