Sorry, long day - I forgot you said this was a dynamic allocation, which is what made me thing about going back to NaviQuest in the 1st place.
my bad - ddk ///////////////////////// 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
