WDSC iSeries Error List Behaviour

[chrisr]

I don't understand what is happening here. I'm using WDSC 7.0 RSE perspective to edit an SQLRPGLE source member. When I compile the iSeries Error List pane shows a list of problems. I'm used to being able to double click on an error and the source view positions to the line with the error. This is the behaviour I've become used to.

What happens with this particular source member is my double click action opens a source member type RPGLE (not the SQLRPGLE) and I've just noticed while I'm typing this there is a error/warning message in the source display saying...
"The error messages could not be inserted into the original source file. The error messages have been inserted into temporary member LIB/EVFTEMPF01 (MBRNAME)."

Why is this happening, am I doing something wrong?

[jamief]

Re: WDSC iSeries Error List Behaviour

Chris I would love to help you but Im still coding on the back of one of Moses's tablets with a brick hammer.

[chrisr]

Re: WDSC iSeries Error List Behaviour

Thanks. I have one of those tablets too. It sits up there on the shelf with my as400 programming reference summary book, for the envy of my colleagues.
I'm trying to drag this place in to the 20th century but something unexplained like this gives the disbelievers fuel to their "anything non green screen" fire.

[BenThurley]

Re: WDSC iSeries Error List Behaviour

I think this is because an SQLRPGLE program must first go through a pre-compiler. The pre-compiler converts your SQL into regular RPG that can then go through the normal compiler. The net result is that the line numbers in the source member don't match those in the error message. I believe WSDC anticipates this and gives up. I usually have to either switch back to PDM/SEU or guess where the problem is if I see these.

For a second I was excited that somebody might be experiencing the same problems as me with WSDC. Every time I compile a program I get an error list full with "invalid thread access" errors. If I then click the iSeries error list I can see whether the program has compiled or not. It doesn't stop me doing anything, it's just annoying. I wasted the best part of a day reinstalling everything but it had the exact same problem when I finished!

[littlepd]

Re: WDSC iSeries Error List Behaviour

I think I remember the problem being that the pre-compiler generates code in a temporary storage location that gets deleted when the compile step is finished, whether it's successful or not.

There is a way to get the "double-click" action to work on SQLRPGLE source members. It's been a while for me so I don't remember exactly how, but I think it involves changes to the compile command to tell the pre-compiler to not store the generated code in it's QTEMP lib, but you specify a library where you want that code stored. Then, when you double-click the error message, it finds the source line number in that generated code, and shows that to you.

I think... Sorry, I've been using WID and java instead of WDSC and RPG for the past several months.

[chrisr]

Re: WDSC iSeries Error List Behaviour

Thanks Ben and little. If it's that convoluted I don't know if I'll worry. SQLRPGLE source isn't too common here thankfully and I was still able to figure out in this instance where the errors were without going to PDM/SEU. So long as it isn't something I've done wrong I'm happy.

[BobGenis]

Re: WDSC iSeries Error List Behaviour

Ben is correct that there is a pre-compiler step where the SQL enviroment is copied to your source member. The setup wasn't *that* bad, though. In the Compile menu; Work With Compile Commands and in your CRTSQLRPGI command add the options:

TOSRCFILE(lib/QSELTEMP1).

By default the library is QTEMP which isn't found when the errors are displayed/clicked on. But if you specify a different library, WDSC will be able to find them. When you double click on the error it will open up a Read Only RPGLE member that is the result of the pre-compile step. It's sort of a hassle because you have to go back to your SQLRPGLE source member to do the corrections but at least you can see the statement in error. Otherwise you're just guessing since even the line numbers don't match up.

HtH