Conditioning the execution of virtual code

Date: Archived
Product/Release: LANSA for the AS/400 and LANSA for Windows
Abstract: Conditioning the execution of virtual code based on whether a field has been requested in a LANSA I/O command. This can improve the execution of an I/O module.
Submitted By: LANSA Technical Support

Virtual code is often very straightforward, and the execution of it as part of an I/O request places very little overhead on the system. But sometimes, virtual code can be more complex. Having such code execute every time an I/O is performed, whether it's required or not, could have a significant impact on performance. This applies whether the virtual code is written in RPG or C.

In such cases, the following technique can be used to condition the execution of virtual code by determining whether a particular field has been requested by any LANSA I/O command. The following discusses the additional code required in order to use this technique. It should be noted that the code can exist in any of the 'C spec' areas allowed for virtual code, i.e. 'after input', 'before output' and 'internal subroutines'.

Firstly, an example of what the RPG code might look like:


    	     MOVEL'ABC_V'  [email protected]@N )
    	     MOVE 'IR   '  [email protected]@N )  Note 1 

    	     EXSR [email protected]@F          )  Note 2 

  [email protected]@P IFGT *ZERO                )  Note 3 


Note 1:

In this section of the code, the name of the relevant field is moved into the [email protected]@N variable. Don't include any length or type definition for this variable in the code, as it has already been defined elsewhere in the I/O module. Note that this is achieved by using two 'C specs', in order to stop LANSA substituting the internal name for the field into the code at compilation time, which is triggered by the VC_USING command.

Note 2:

Once [email protected]@N has been set with the name of the field, subroutine [email protected]@F is executed, which determines whether the field has been requested by the calling function. Again, the [email protected]@F routine doesn't need to be coded by the user: it already exists as a standard part of the I/O module.

Note 3:

The variable [email protected]@P, upon return from the [email protected]@F subroutine, will be zero if the field has not been requested, or greater than zero if the field has been requested, and can thus be used as the conditioning statement for the relevant virtual code. Like the [email protected]@N variable, don't code any definition of the [email protected]@P variable, as it is defined elsewhere in the I/O module.

Secondly, an example of what the C code might look like:

If ( pG->pCurrFldIndex -> X_DBM_FldsUsed[X_V_ABC_VIR] == YES)



Also consider writing virtual code in RDML. The same code could then be reused on different platforms.