| Author |
Message
|
| RichA |
 Posted: Mon Oct 25, 2004 9:47 am Post subject: Trace |
 |
|
Centurion
Joined: 14 Mar 2002
Posts: 102
|
What would be really handy is some method of writing information to the trace log from within compute nodes. An ESQL command like -
Trace ( <String> ) ; |
|
| Back to top |
|
 |
| PGoodhart |
| Posted: Mon Oct 25, 2004 9:58 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
It's not exactly what you want but check out the trace node in the message flow editor.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| RichA |
| Posted: Mon Oct 25, 2004 10:08 am Post subject: |
|
|
Centurion
Joined: 14 Mar 2002
Posts: 102
|
| Yeah, I know about the trace node. But if you've got a whole bunch of SQL doing loads of stuff to tables all in the same work unit and you just want to check something in the environment is what you think it is or to confirm you're reaching the part of the code you want to reach it would be handy. It's a pain to deal with propagating mid-compute to go to a trace node as there's have to be a filter to determine whether it's the mid-compute propagate or the return propagate. I didn't particularly want to go to that kind of effort. On account of me being lazy. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 25, 2004 10:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I typically do that kind of "print statement" style debugging by sticking stuff into Environment, and then putting a trace node after.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RichA |
| Posted: Mon Oct 25, 2004 10:15 am Post subject: |
|
|
Centurion
Joined: 14 Mar 2002
Posts: 102
|
Oh well, looks like I'm going to have to do that then, it means I'll have to write at least 2 extra lines of code and go to the effort of checking out the message flow from clearcase as well. That's going to take me at least another mmmm, 5 minutes. Probably quicker than writing this thread to be honest. Still it would be handy.  |
|
| Back to top |
|
|
| JT |
| Posted: Mon Oct 25, 2004 10:29 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| ...you just want to check something in the environment is what you think it is or to confirm you're reaching the part of the code you want to reach... |
Why not use the debugger for these occasions? |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Oct 25, 2004 3:48 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Debugger works well if you are debugging the problem in Dev/QA region or when you are able to reproduce the production problem in other environments. For some of "after the fact" debugging, like jeff said, log key info into Environment tree and write it to a trace file.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| chanduy9 |
| Posted: Mon Oct 25, 2004 6:49 pm Post subject: |
|
|
Disciple
Joined: 28 Nov 2001
Posts: 177
Location: USA
|
Hi,
Take the trace by running mqsichangetrace..with this you can see the execution of each and every statement of your code...it may help you...
Thanks,
Chandra. |
|
| Back to top |
|
|
| RichA |
| Posted: Tue Oct 26, 2004 12:27 am Post subject: |
|
|
Centurion
Joined: 14 Mar 2002
Posts: 102
|
I can't debug in this situation, the trace does not tell me what is in the environment, the results of a select statement, I can do the trace node thing, but like I said it involves an extra check out, modification of a messageflow to add a filter, and a trace, extra code to deal with this to be non-intrusive to other peoples work, I just thought it would be handy to be able to output things to the trace file from within a compute. It's fine to make the assumption that I might not know of the other methods of achieving my goal, but I do and the easiest way would be to just have a command that would output something to the trace log. I can indeed determine that I have reached the point in the code that I want to reach, but that means reading through the log and interpreting which line of code I am at etc. wouldn't it be easier just to put in a print statement and then grep the file for what you print? I suppose I could declare a unique variable, then grep for that. But then I still need to know what's hapening around that declare, if there were a print to trace statement then I could just grep for my marker and find the information I need, it's lazy but isn't that the point?  |
|
| Back to top |
|
|
| nathanw |
| Posted: Tue Oct 26, 2004 1:50 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
persoanlly what i do is add a MQ OUPUT node to a specific q and then check the data posted to the q
that way at least yu know what data is being passed at that point
is not the best solution and you would have to still take it out to modify but it is alot easier at times
doesnt give you all the data you may need but as long as the message passes on from there you get a copy at that point |
|
| Back to top |
|
|
| RichA |
| Posted: Tue Oct 26, 2004 2:17 am Post subject: |
|
|
Centurion
Joined: 14 Mar 2002
Posts: 102
|
The situation is such that I have a Compute node with a number of database reads, writes and updates.
The particular part of code I want to modify has to update a table on an inner join, now the syntax I did have for the update inner join results in -
SQL0104N An unexpected token "JOIN" was found following "". Expected tokens may include: "FROM". SQLSTATE=42601
The update is in the form of a passthru statement built up from a number of different variables, so the log is full of the resolving of this statement and other statements, meaning I have a big search to find the part of the log I'm interested in.
I believed my syntax to be correct, but it not working proves otherwise. Speaking to a DBA I changed the way I was performing the update.
This throws no error, but the results are not as I expect at the end of the flow. This could be because the update has been overwritten further down, or the update is not working as I want. There are a number of options open to me, some aren't really open to me because of the environment I'm working in. It's not an environment I can use debug in.
The simplest solution I could think of would be to select the information into variables and print to the log, but I have to propagate a message with the data from the select in the environment to a log, then filter it out away from the rest of the message flow while allowing the original result to continue through the flow unchanged.
Incidentally can anyone tell me what's wrong with this syntax -
Update Table As T1
Inner Join Table As T2
On T1.OID = T2.OID
Set OTP.VALUE = ''
Where T1.SEQUENCE Is Not Null
This is a much simplified statement compared to the one I'm using but results in the same error. |
|
| Back to top |
|
|
|
|
