When you call a VAG program from a COBOL batch program then VAG will establish its runtime environment. When the VAG program terminates, it will remove the runtime environment again. If you are doing a lot of calls to the same or different VAG programs from COBOL in the same execution, then the VAG runtime environment will be established and removed a lot of times and this is a very resource consuming process.

The installations using VAG has different approaches for solving this challenge. Some installations has forbidden the use of VAG in batch. Others has coded their own preload tools where they in several different ways try to establish the VAG runtime environment up front. In the latest versions of VAG runtime services it is a builtin feature to preload the runtime environment, but I don't know how it works. Maybe it doesn't work and maybe it does. If your experience is that is doesn't work, you might as well read the rest of this tip.

There is a fairly simple solution to the challenge, though. You create a VAG program with only one function and that is to call the COBOL program causing the trouble. Now suddenly the VAG rumtime services are established up front and it will stay activated for all subsequent calls to VAG programs from the intermediate COBOL program. The result will of course depend on the number of calls to VAG programs from the COBOL program, but I have seen up to 90% reductions in elapsed time.

For the experienced programmer it is fairly easy to create a VAG program that is able to start any COBOL program and still keep the PARM input given from JCL intact. In this way it is only nessecary to create one VAG-program for all the COBOL programs that needs to be optimized.

There is one thing to be aware of that can cause a lot of trouble. If the VAG programs called from COBOL uses DB2 cursors and these cursors aren't closed when the VAG program is terminated, the strangest errors can occur. The problem arises when you call the same VAG program again and the COBOL program has issued a DB2 COMMIT (or ROLLBACK) between the two calls. COMMIT/ROLLBACK closes all open cursors, but the VAG runtime environment keeps track of OPEN and CLOSE of DB2 cursors. Therefore VAG runtime services still beleive that the cursor is open when the second call is issued. The reason for the occurence of this error is that before the optimization the VAG runtime services were shut down and VAG lost track of the cursor status, but when it is kept alive after the optimization, it suddenly remembers the status.