Are you really using CLIST or are you using CLIST interchangeably with REXX and 
you are using a REXX program?

If you are really using a REXX, why not do this and leave the PROFILE option 
alone.

/* rexx */                                                             
                                                                       
statout.1 = "IKJ56192I JOB KIXDPMSA(STC02389) ON OUTPUT QUEUE"         
statout.2 = "IKJ56211I JOB KIXDPMSA(STC01772) EXECUTING"               
statout.3 = "JOB CICSPA62(STC00059) ON OUTPUT QUEUE"                   
statout.4 = "JOB CICSPA62(STC21084) EXECUTING"                         
statout.0 = 4                                                          
                                                                       
do i = 1 to statout.0                                                  
   parse var statout.i ."JOB" jobname"("jobnum")" jobstat              
   say right(i,2)")" jobname", which is" jobnum", is currently" jobstat
   end                                                                 
exit                                                                   

In the above example, "statout." would be the stem that was trapped via the 
REXX outtrap process and the values I have coded are the examples you gave in 
what is causing your problem.

If you execute the above REXX, this is the output (at least what I get):

1)  KIXDPMSA, which is STC02389, is currently  ON OUTPUT QUEUE
 2)  KIXDPMSA, which is STC01772, is currently  EXECUTING      
 3)  CICSPA62, which is STC00059, is currently  ON OUTPUT QUEUE
 4)  CICSPA62, which is STC21084, is currently  EXECUTING      
***                                                            

Is this what you are ultimately looking for?

Chuck

Charles Hardee
CA technologies
Sr Sustaining Engineer
Tel:  +1-952-838-1039
charles.har...@ca.com



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barkow, Eileen
Sent: Monday, June 13, 2011 9:36 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TSO STATUS and IKJ56192I/IKJ56211I msgs

I will change the clists to look for the IKJ* msgs.
So far, it has been present in all the lpars that I run the clists so I did not 
know about
About the difference. Now I am working on a lpar where NOMSGID was set so I 
noticed it.

Actually, when run for production, the clists job gets submitted via the 
internal reader 
and runs under a different user id, not mine. I am only using my id for testing.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Tom Marchant
Sent: Monday, June 13, 2011 10:24 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TSO STATUS and IKJ56192I/IKJ56211I msgs

On Mon, 13 Jun 2011 09:50:53 -0400, Barkow, Eileen wrote:

>i use STATUS in come clists and have to trap the response with REXX OUTTRAP and
>the extra field or lack of it throws the clists off (unless I modify them
for each lpar to
>account for the IKJ* msgs).

IMO, you should code your clists to look for the prefix and ignore it if it
is there.

-- 
Tom Marchant

----------------------------------------------------------------------
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

----------------------------------------------------------------------
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

----------------------------------------------------------------------
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

Reply via email to