But that's the beauty of NaviQuest - you can set up your test case, test 
it against your 'live' code changing values until your results match what 
you're seeing.  Then you can run that test case against new code to see 
what it does with the data.

As to not knowing what is being presented to the routines,  you can add 
variables to your WRITE statement to tell you exactly what SMS sees. 

In the case I was working on yesterday, my test dataset was falling out of 
the code a long way from where I thought it was supposed to & I couldn't 
see why.   So I updated to WRITE statement where it was falling out of the 
code and added a dozen different variables to the WRITE - specifically I 
wanted to see the variable I was testing for in the earlier segment.   I 
was testing for the RACF defaults security is supposed to set up when they 
define a new user ID - my displays showed me that for this ID that had not 
happened.   There was actually nothing wrong with the code - it was in how 
the ID was set up -

I've been doing this a lot of years and haven't found an instance yet that 
I couldn't debug using WRITE statements and the right combinations of 
WRITE Variables.

HTH's.
ddk

///////////////////////////////////////////
No, I didn't. But I don't think this will help here, because I don't know 
what is being presented to the ACS routines and the problem occurs only on 
a specific allocation of a specific product with one specific data set. I 
can only debug this problem in a live environment, hence the 'tracing' 
needed for the live ACS routines.
 
Kees.

________________________________

Van: IBM Mainframe Discussion List namens Darth Keller
Verzonden: do 12-9-2013 17:21
Aan: [email protected]
Onderwerp: Re: ACS routine trace.



I'm curious.  Do you ever use the NaviQuest SMS test facility?
ddk

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to