Problem: Shared variable l_tel has not yet been created

Posted by Admin on 17-Oct-2006 02:40

When implementing my code the following error appears:

c:\windows\temp\p98718_oldnewtel.cmp Shared variable l_tel has not yet been created. (392)

I work not yet for a long time with Progress. I do not know how I can repair this problem

I read that this should go with the Application Rebuild somehow. But how I can open and serve this Tool?

Thank you for your answers.

Sorry that I trouble you maybe with so stupid question.

All Replies

Posted by jtownsen on 17-Oct-2006 09:02

The code that you're running has something like:


Such code expects that the shared variable has already been created:


This program expects one of the parent procedures to actually create this shared variable (eg. the application's startup procedure, menu, records selection screen, etc).

The easiest solution is to run your application first and then drop back into the editor. If that doesn't work, you could create a program that defines all of the shared variables as new. Run that and your program above should work fine.

Incidentally, shared variables are a coding technique that is generally frowned upon for newer applications. Since you seem to be maintaining an existing application, you probably don't have much choice but to use them.

Posted by Thomas Mercer-Hursh on 17-Oct-2006 11:31

Let me make a somewhat stronger statement. Since you are new to Progress and just beginning to make changes to existing programs, you are naturally going to have to move cautiously. But, you should bear in mind that shared variables are a problem which you should try to remove when you have the opportunity. The problem you are reporting here is one of those issues with shared variables ... where are they getting created, where are they used, where are they modified. If one has a bunch of interacting programs one can go nuts trying to figure out what happened after some program 4 down in the call stack modified a value which a higher level program was expecting to remain fixed. Not to mention the problem of trying to re-use a piece of code and then having to add a passel of shared variables to the calling program and get their values set.

As you learn more and the opportunity presents, think of converting routines into procedures with parameters. Then, in the procedure, you will always know where the value came from and how it is being returned. There is a clean interface between caller and callee. Next, start looking into persistent procedures as a way of encapsulating frequently used logic and making it available without having to pay for a RUN every time it is used. Then, move on to superprocedures which essentially expand the name space of your program. Or, if you are on 10.1A, you can start with objects.

This thread is closed