Hello again everyone.

I have an interesting problem I have no idea how to solve. In our development environment only, a process that has worked for the last 4 years no longer works (go figure).

We have a menu option that calls a commuter module. This commuter module is also used by a window, and as such we are have the following line in the program:

$INSERT SYSINCLUDE,COMMON.AREAS

Now, when the window is loaded, the menu option works just fine (as expected). However, if the window is not loaded, and I access the menu directly from a TCL, then my commuter module breaks on the $INSERT line with the error message:

"B720 Attempt to use COMMON variable when COMMON has not been defined."

To my knowledge, nothing in the environment has changed recently. Also, I thought maybe a recent change to the commuter module was causing the problem, so I have tried the last 4 revisions, and all break on the $INSERT statement.

However, I went to our production environment and everything works fine there, whether or not the window is loaded.

I'm hoping I just have an environment setting wrong somewhere, but I don't have any idea where to look.

If anyone has any ideas, I would greatly appreciate it.

TIA,

Matt Sorrell

[email protected]

Matt

The variable probably causing the problems is W.CNT which crashes if window common block is referenced and a window is not active. So I don't know why this worked before unless the line was asterixed out or some additional logic was performed to check status to check.

Don't forget that $insert records are compiled at compilation time and NOT called at runtime in the way that subroutine is. So it is possible the COMMON.AREAS record was modified ages ago but it was only when you changed and recompiled the main program which therefore recompiled the inserted code that the error surfaced.

Just as a pointer it is best to use the newer (i.e. 1993 !!!) WINDOW_COMMON% references if possible to reduce the change of accidentally changing the value of a badly named common variable.

Hope this gives you some pointers.

Tony

Tony,

I understand most of what your saying, but my issue is this:

This program gets recompiled and redeployed all the time. As I mentioned in my earlier post, this error message only occurs in one system. We have several other systems where we do not get the error message. Also, the line that is breaking is the $INSERT line. For this one particular option none of the code that gets executed utilizes any of the common variables.

I just find it very interesting that in one system it will break, and in 3 or 4 other systems the exact same object executes flawlessly.

Matt Sorrell

[email protected]

Have you actually compared the record being inserted from one system to another? If the program is the same but the insert record is different, this could be the problem.

Matt,

Here's some brainstorming for you. It may completely miss the point, but maybe it will trigger an idea.

First, the obvious: It sounds like the Window establishes a variable globally that TCL does not. That would most likely be a window common variable, but it could be something unintentionally floating around like an @user0 variable.

Moderately obvious: Why is it looking for COMMON? Shouldn't it be looking for COMMON.AREA? But I might be remembering the $INSERT process incorrectly. Does the COMMON.AREA file have an insert of COMMON?

Less obvious: Weren't COMMON variables the ones used in the olden days, the days of version 1.x? Maybe a variable in your COMMON.AREA is outdated, but something has kept it alive, perhaps an old program in the window subroutines that has been changed by a developer.

Less obvious: perhaps, as Victor and Tony mention or imply, it may have always been that way, but there may have been a value in the COMMON.AREA file that defined it, on purpose or accidently. If the inserted file is different, i.e., missing that value, there you are. Or perhaps some subroutine hidden in the window establishes it.

Even less obvious: Has someone been monkeying with the TCL window? May your environment expects TCL to run a special subroutine in one of the hooks that manages the variables at different levels. That's a bit of a stretch though…

Some fundamental questions: how many developers or non-developers have access to your development area? How carefully do they control versions/releases? When you deliver your package as a single executable, these problems are almost exclusively with the platform, but with ARev you can deliver a new version that just has a new set of "object" code. This makes version control/configuration management absolutely critical, if it wasn't anyway These questions are particularly pertinent when one area works differently from three others.

Kenny

Good point, Victor…

You can easily write a program that will compare two object programs. Note, however, that the time/date of last compile are at the end of the object records and should be ignored. Just do a byte-for-byte compare of $OBJECT_1 to $OBJECT_2 and ignore the Date/Time stamp area.

FYI, if the lengths are different, the two are not identical since the date/time stamps are the same length.

Don Miller

C3 Inc.

View this thread on the forum...