Home The Company Publications Products Links Tips

Tips, Tricks, and Techniques

Last update: 30 April 2004

What are AIV's?


Application Indipendant Variables (AIV)

Define data areas to be used in a NATURAL program.

DEFINE DATA                                         
  INDEPENDENT  
    level +variable-name(format-length) INIT init-definition                
                        (format-length/array-def)INIT array-init-definition 
END-DEFINE    


Question from Lewis Pritchard, Australia

Using Nat227 under MVS, I have found what looks like an ideal application for Application Independent Variables. But the powers-that-be at the site have laid down the eleventh Commandment - "Thou Shalt Not Use AIVs".

When asked why, the response basically amounts to "because we said so".

Can someone give me a bit of a run-down on the technical details? In other words, what are the implications of using them? I've heard rumours that they are "very inefficient" but I don't know whether this is a reference to slow access, spaceusage, or what.

I'd really appreciate some help. Our system is hugely dependent on code lookups, and tests indicate I can gain maybe 60-70% improvement on calls to the common decode module by using AIVs, with little or no modification to any other modules.

Answer from Anita Haas, South Africa

I've made extensive use of AIV's, and experienced only advantages. You don't have to CATALL your system when you want to add, change, delete AIV's. They can be used in subprograms and by invoked modules residing in steplib libraries. Just define them in a central place, not all over the show - to prevent confusion.

We have achieved many performance enhancing techniques - e.g. storing ISN's of commonly accessed records - descriptions frequently required, etc. I have never experienced a single disadvantage - even on very large applications.

Answer from Steve Robinson

AIVs are the version 2 implementation of the old global variables from version 1. As such they have some of the inefficiencies, and also have some of the maintenance problems. why not consider the version 2 functional replacement for global variables, namely a global data area? this is more efficient and also forces all definitions into one module (yes, with AIVs you can tell people not to define new variables in other than one "controlling" module; but try to enforce that).

Answer from Kevin Furman

I Agree totally with Anita. However in my experience the reason sites ban AIV's is because many natural programmers do not know what AIV's are or how to use them.

Answer from Bob Steinkraus

I concur. I have used AIVs in addition to Globals, because of their advantages over GDAs (availability to subprograms, fewer CATALLs), as well as because you can pick and choose which variables get passed to which modules.

AIVs are a tool like anything else, and should be used if their advantages outweigh their disadvantages. I would bet that a 60-70% improvement is a pretty strong advantage. 'Because nobody is used to them' strikes me as nearly as silly as 'Because we said so' for a policy justification.

Answer from Liam Gartside

I Agree totally with Anita. However in my experience the reason sites ban AIV's is because many natural programmers do not know what AIV's are or how to use them.

Sounds like the earlier discussion on processing rules.

Answer from Max Lemke

My experiences with AIV's have been good when they are used in a proper context. I call them "session variables". I've found them to be useful in storing values that are needed anywhere in the system. e.g. Current User Id, current security authorization etc. The primary benefit of AIV's over Globals is that they do not suffer from the Global's restrictions. One can invent "black boxes", otherwise known as sub-programs or external subroutines, to implement session functions. e.g. Is this user authorized, display the errors, etc.

One time we were able to save ADABAS commands. We were informed by our DBA staff that a certain program was being executes hundreds of thousands of time in a day. We noticed that this program had a likelihood of retrieving the same ISN the next time it was called. Unfortunately this module was buried deep underneath the calling sequence and was widely used in the system. We created AIV's to save the information this program was getting from the ISN and wrapped the get in a condition that checked if the ISN differed from the one just saved. This simple use of the AIV's save several hundreds of thousands of commands per day.

Comment from Dieter: Can we really call it a black box if it is dependent on AIV's? For example, can we call it from another platform?

Answer from Darrell Davenport, Washington State University

I have to admit I have not investigated them lately, but I do know how they were implemented in the "old" days, and there were some real problems with them.

AIVs were originally called global variables. There was no such thing as a GDA, subroutine, subprogram, or helproutine; only programs and FETCH, which overlayed the old program with the new one... There was no hope of returning to the statement following the FETCH.

In order to preserve the global variable value, it was copied from the runtime buffer (I think it was ESIZE), to a buffer that was not overlayed (FSIZE, I think). When the next program started execution, the global variable list was copied from FSIZE back to ESIZE. The new global variables defined in the FETCHed program (if any) were added to the list. It was necessary to sort the list to merge them in. It didn't matter if the FETCHED program defined/referenced global variables or not, the overhead of copy, sort, copy back was always necessary. This was a huge amount of overhead.

Additional problems were:

  1. You didn't have to define the global variable in every program. As long as a preceding program had defined it, than it was known and available "on the fly". This brought up 2 problems. One during maintenance, and one during execution. Imagine trying to change, or even locate, the definition of dozens of global variables that are spread randomly throughout the application (What a maintenance nightmare). And during runtime, what if the program that defined the variable had not been executed yet?

  2. During development of an application, defining AIV(s) in a program then stowing or running it would define the variable(s) to the Natural session. For the remainder of that session, all other programs stowed would "include" all known AIVs, whether they referenced them or not. Then, you might decide to change a variable from, N8 to N9. You would go back and re-stow the previous programs that you knew referenced the variable and test out what you had. As soon as Natural encountered a program that you did not re-stow (because it didn't use global variables), it would die with a "global variable mismatch"! Also, if you decided to remove an AIV, you would have to re-stow everything. Otherwise the first encounter with a previously stowed program, would define it to Natural again. It would waste valuable space, and be included in the AIV-shuffle overhead mentioned above.

  3. When Natural introduced GDAs, things got worse in some respects, because we could then define a "+" variable in a GDA and it could be THE SAME NAME as an existing AIV! The two were kept in separate locations and could exist simultaneously. That caused much confusion and very difficult debugging.

I suspect that some of these problems are resolved today. I also suspect some of those problems still exist. I know that you can still enter the ancient EDIT VARIABLES command at the NEXT prompt, and see the AIVs that are defined at any one instance within the session.

Hmmmm, I wonder if I stowed a program while AIVs are known to the session if they are "included" into the module automatically.....

The bottom line is: This needs some investigation to know the truth of AIVs today.

By the way, Global variables in a GDA _are_ available to subroutines, if they are passed as parms.

Top Page


Back to NATURAL Tips, Tricks, Techniques -- Overview