How can the use of all programs can define a global variable. For example, variables such as systems used natural holds the official tax rate.
There are several things that are called “global variables”.
In Version 1 of Natural, “global variables” were identified by their name, which always started with a plus sign. For example: MOVE ‘ABC’ to +PROJECT (A3). Like all variables in Version 1, the format and length were defined at the first physical appearance of the variable.
Having defined +PROJECT, as shown above, I could not FETCH some-other-program where I could WRITE +PROJECT and see the value ABC.
In version 2, there was a new implementation of the old global variables. This was due to the new DEFINE DATA clause. They are called AIV’s or Application Independent Variables. They can be used interchangeably with the old global variables.
Also in Version 2, we had the introduction of Global Data Areas. Variables in a Global Data Area are defined in only one place; the Global Data Area itself. There is no “on the fly” creation. In all the objects that require a variable in a GDA, you must have: DEFINE DATA GLOBAL the-name-of-the-GDA.
steve
Thank you very much for your interest and relevance.
My English is not good because I could not explain my problem.
I want a variable that can be used common to all sessions. (May be read-only) This variable will have access to all programs in the natural environment.
For example, variables such as *OPSYS .
As far as I know, there is no such variable made available to an application.
I am sure you have looked at the list of System Variables. The majority of them do not allow their content to be modified. You might try something like *HARDCOPY, which is an A8 field; but this would be a problem if any program wanted to utilize it.
Basically, what you seem to want is a new “System Environment” System Variable that could be modified by a program (Read only would not be very useful; someone needs access to change something like a tax rate - your example).
You might try a Change Enhancement Proposal to Software AG.
steve
The current structure of the LDA, we keep these values. The tax rate is replaced by a law. Does not change frequently. The more than once a year is changing. There are many programs and use this variable. Changes in case this variable is used to find all the programs have to compile again.
Programs that have been determined by law in all of the tax rate should be used. This is why we must have read-only. But the system administrator must change this value. (Example: using a tool)
Thanks.
There are ways to achieve what you want. One is to have a subprogram that every other module calls to get the rate. The rate can still be held in your LDA but only the one subprogram uses the LDA so when the rate changes only that subprogram needs to be compiled and every other program gets the new rate immediately.
You could skip the LDA and just have the rate initialized in the subprogram.
Better yet, you store the rate on a file and read it in your subprogram. That way you don’t have to touch the code to change the rate. You just need a way to update the file record. If efficiency is a concern, the subprogram can cache the rate in an AIV and only read the file at an interval that is acceptable to you (daily, hourly, every 5 minutes).