Compiler Errors

pwdiener · Post by **pwdiener** » Thu Jul 19, 2012 5:58 pm

I'm working with a COBOL compiler on an AS/400, and would like to integrate it with Zeus. There are a number of tasks that need to be accomplished for this, but one key one is to be able to take the error list from the compiler and integrate it with Zeus's normal compile error handling, i.e. show the errors, be able to go to the source file, step through the errors while in the source file, etc.

As a first step, I've prepared a file that I think should work. It looks kind of like tool output - a file name, line # in file name (parenthesized), then error text. To test, I created the error file by hand, then used the command "type error.file" as the compile command, thus producing standard output that contains the error messages. This command is in a CMD file. I see the file in a compiler window as a result. A sample line from the error file is:

Code: Select all

"C:\<directory structure>\PTWOC0400A.CBL" (483) *  1672  MSGID: LNC1326  SEVERITY: 30  SEQNBR:  048300 '2320-HEADERS' not defined name. Statement or clause ignored.

The error text begins with the *, with the number after that being a statement number in the listing file produced by the compiler, which I've used to translate to source file name and line number.

My problem is that when I move to the first "error" and press Enter, Zeus displays the message "The current document does not have any associated compiler errors." I've configured both a Lines regex and an Errors regex which should identify the line # and a line containing an error message, respectively. These are the 2 that the documentation implies are necessary. I've also configured a filename regex.

Code: Select all

Lines Regex: '\([0-9]+\)'
Errors Regex: '  MSGID: '
Filename Regex: '^"([^"]+)"'

where the single quotes are NOT included, just there to show spacing.

The other, minor, issue, is probably related to the way I'm just handing over this file as the errors. When I compile, Zeus shows me a message that says "Compilation completed successfully." I tried putting "exit /b 1" in my CMD file, but the result is the same. What does Zeus use to determine whether the compile succeeded or failed? I thought it was the exit code, but perhaps that exit statement isn't doing what I thought it did.

So my questions are:
1) What do I have to do to let Zeus know that the compile failed?
2) What does the error message file need to look like in order to support the full range of Zeus's compiler output handling?
3) Is there something else I need to do to associate the stdout results with the document I tried to compile?

Post by **jussij** » Fri Jul 20, 2012 7:07 am

To test, I created the error file by hand, then used the command "type error.file" as the compile command

That is exactly what I do when I need to setup a new compiler

What do I have to do to let Zeus know that the compile failed?

I think you where on the right track but I suspect for some reason you might have ended up changing the wrong document type

In any case this is what I did:

1) I changed your C:\temp\error.file code to read like this:

"C:\temp\PTWOC0400A.CBL" (23) * 1672 MSGID: LNC1326 SEVERITY: 30 SEQNBR: 048300 '2320-HEADERS' not defined name. Statement or clause ignored.
"C:\temp\PTWOC0400A.CBL" (24) * 1674 MSGID: LNC1326 SEVERITY: 30 SEQNBR: 048300 '2320-HEADERS' not defined name. Statement or clause ignored.
"C:\temp\PTWOC0400A.CBL" (26) * 1676 MSGID: LNC1326 SEVERITY: 30 SEQNBR: 048300 '2320-HEADERS' not defined name. Statement or clause ignored.

So I have an error in the C:\temp\PTWOC0400A.CBL file at line number 23.

2) I then created a simple C:\temp\PTWOC0400A.CBL file which had at least 23 lines of code. The contents of the file are not important.

3) I opened the C:\temp\PTWOC0400A.CBL file and then used the Options, Properties menu to get at the document type properties.

4) In the Compiler section I put in the test command: type C:\temp\error.file

5) In the Compiler section I put in ' MSGID: ' as the Errors regexp (without the quotes of course).

Now if I compile the C:\temp\PTWOC0400A.CBL I get the compiler errors window with the error highlighted.

I can click on the error and it will load the file and position the cursor at the correct line number 23.

Cheers Jussi

pwdiener · Post by **pwdiener** » Fri Jul 20, 2012 5:20 pm

That's almost exactly what I did, but no joy.

I had not used the Options/Properties way of getting to the document type properties, but when I did I saw exactly what I (and you) described. I just got to it through the Options/Document Type menu and selecting the COBOL document type.

In the sample error line I sent, I had just editted out path name details, so mine was longer than just "temp", but that's the only significant difference. I also verified that it SHOULD work (i.e. it refers to the appropriate file and line numbers) by just opening my errors.file and using the inline file display (Ctrl-E for me). On each line, this took me to the appropriate place in the source file. My errors.file actually refers to multiple source files, and they all work.

So the bottom line is - I still don't know why it's not working. I am running 3.97n-beta6.

Another experiment - I don't get a compiler window at all unless I configure the compiler output display mode for the document type to "always display" - I guess that is consistent with Zeus thinking the compile was successful.

I can send the actual files involved if that will help, but I'm doubtful that the problem is in the files being used.

The good news for me here is that the error file FORMAT should work - I have to write a program to produce that from the listing file, so I can start on that while we try to figure out what I'm doing wrong with the configuration. Unfortunately for me, the compiler is typical mainframe, producing a listing file, errors toward the end, but each error referring to a "statement number" which appears only on the listing and bears only a casual relationship to the source file line #. For instance, comment lines are un-numbered in the listing, source files copied in (includes) are included in the statement numbers, and the listing file is designed to be printed, with header lines embedded in it. So the statement number also bears little relationship to a line number in the listing file. Not an impossible task by any means, just a PITA.

Bill

Post by **jussij** » Sat Jul 21, 2012 6:02 am

Hi Bill,

So the bottom line is - I still don't know why it's not working. I am running 3.97n-beta6.

That is very strange since I am running the 3.97n-beta7 and I am positive this part of Zeus has not changed for a while.

You could download the latest patch file but I am pretty sure that will not fix the issue, but you never know

http://www.zeusedit.com/z300/zeus-beta-patch.zip

Just to double check I changed the error file (see prefious post) and ran through all the steps again and once again it worked for fine me

Another experiment - I don't get a compiler window at all unless I configure the compiler output display mode for the document type to "always display" - I guess that is consistent with Zeus thinking the compile was successful.

That is correct.

I can send the actual files involved if that will help, but I'm doubtful that the problem is in the files being used.

Send me a zip file containing your zConfig folder. The problem will be somewhere in that configuration.

The good news for me here is that the error file FORMAT should work

Yep that format should should work just fine.

Not an impossible task by any means, just a PITA.

My two cents worth. I haven't written anything like this before, but if I was to start I would at least start with a quick look at Python.

http://www.python.org/doc/

Why?

Because Python can easily do things like read a file into a list of lines.

Loop through those lines looking patterns using regular expressions.

Save matching lines into another list.

Write out a new file with those results.

Also there is a 2.7.2 version of Python that comes with Zeus so you can just use this as the compiler command line:

Code: Select all

pythonc.exe ParseAS400.py "$fn.some_error.file"

Cheers Jussi

Post by **jussij** » Sat Jul 21, 2012 6:41 am

Another experiment

One other thing that you can try is doing a full re-install using the latest installer found here:

http://www.zeusedit.com/z300/zeus-beta.zip

But before you run the install you have to make sure you rename you current Zeus install out of the way

Here are more details on how to do this: http://www.zeusedit.com/zforum/viewtopic.php?t=2719

Cheers Jussi

pwdiener · Post by **pwdiener** » Tue Jul 24, 2012 5:09 pm

Well, it appears that something in my installation was not quite right, because when I re-installed the beta and restored the configuration, it started working as expected. Not sure what the problem was. The only other change was moving from beta6 to beta9, and that seems unlikely.

My next issue is the error display. As you can see from the sample error line I sent, the error can be rather long. When stepping through errors, Zeus displays the error text in the message/status bar area, which is nice except that by the time the file name, line number, and compiler error number/severity/etc. are displayed, there is no more room for the actual error text, the most important part. A couple of solutions come to mind -

1)ask for some way to configure which part(s) of the error message line to display, probably via captures in a regex
2) write some macros to handle the error message display/stepping.

While 1 is attractive (less work for me

), the second seems quite do-able.

One complication is the need to identify the compiler output window and save it, along with the current error line position, between macro invocations. For the moment at least, I am prepared to assume that I will be displaying the compiler window containing the errors when the first of a sequence of macro invocations is done, so I'll have the opportunity to save the window id.

Some questions:
1) Does that seem like a reasonable assumption?
2) Is there a reliable way to identify/confirm that I am in a compiler window? The default caption text seems to indicate that, and I suppose that if I display a compiler windows with my own caption text then I should be responsible for being able to identify it.
3) Is it reasonable to count on the window caption text being consistent going forward?
4) Is there a way to tell when the compiler window is closed? Obviously I can attempt to activate it and fail, but maybe something a bit more proactive? It would be useful to know this in order to delete any saved window id and/or error position when that data goes away.

A couple of other useful enhancements also occur to me:
1) CompilerErrorMessage keyboard function - display the complete current error message in a message box.
2) get_window_type(id) - return the type of window for a given window id.

Post by **jussij** » Wed Jul 25, 2012 1:28 am

The only other change was moving from beta6 to beta9, and that seems unlikely.

I to suspect it was something in the configuration. If you have the old zConfig folder just send it to me as a zip and I'll take a look.

1)ask for some way to configure which part(s) of the error message line to display, probably via captures in a regex

Something like that would need to be added to Zeus. I'll take a look into this.

2) write some macros to handle the error message display/stepping.

This might be quite difficult to do

1) Does that seem like a reasonable assumption?

There definitely a lot of state information that will need to be saved and managed which will make things more difficult.

2) Is there a reliable way to identify/confirm that I am in a compiler window? The default caption text seems to indicate that

Yep, you can use the caption text.

You can also use this function to create the window (search the zScript or the forum for an example):

Code: Select all

file_open_compiler(string file name [,string caption] [,string source file], [add_copyright = 1])

3) Is it reasonable to count on the window caption text being consistent going forward?

If you set the caption yourself then yes it will

Code: Select all

Is there a way to tell when the compiler window is closed?

The compiler window do not work that way, because you can close the compiler window and still repon it at any time later on.

The way it works is the compiler window is tied to a source file and while the source file is still open then the compiler error window can be re-opened.

So I think you need to check the existance of the error for.

For example if you use the file_open_compiler function the file name represents the error file and source file is as the name suggests the source file.

So as long as the source file is open the file name error file will exist but when the source file is close the error file will be deleted.

I will look to add these two new script functions something like:

Code: Select all

string current_error_message() - return the current status message.
get_window_type(id) - return the type of window for a given window id.

Cheers Jussi

pwdiener · Post by **pwdiener** » Wed Jul 25, 2012 2:18 am

Well, I didn't know it was going to be hard, so I did it today.

I've written a set of 4 macros, ErrorCurrent, ErrorNext, ErrorPrevious, and ErrorCurrentDisplay. They primarily use the CompilerErrorXXX functions, but have some code before and after using them. The code before attempts to identify the compiler window, with the easiest case being that we are sitting with it as the active window. Once identified, it saves the window id in a global string, then uses the CompilerErrorXXX function to display. Since my problem is really only with the display, after I display the message, I go to the compiler window, read the current line, parse out the part of the message I want to display, and use message to display it. Works well.

It's not as completely tested as I might like yet, but it does work well with all the cases I've tried so far.

Bill

Post by **jussij** » Wed Jul 25, 2012 3:17 am

Well, I didn't know it was going to be hard, so I did it today.

Well there you go. What do I know

So are you waiting on the new CompilerErrorMessage keyboard function

This will be fairly very easy to add so it you do need this function urgently let me know and I add it and put out a new beta.

Cheers Jussi

pwdiener · Post by **pwdiener** » Wed Jul 25, 2012 5:13 am

Hi, Jussi,

No, not urgent. I did that one too as a macro. I still think it would be a good keyboard function, and I also think the ability to configure what part of the message displays in the status area would be a good feature, but I've done essentially both of them for now, so no urgency here.

Bill