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:

VC_USING FIELDS((ABC_VIR')) 

    	     MOVEL'ABC_V'  USE@@N )
    	     MOVE 'IR   '  USE@@N )  Note 1 

    	     EXSR USE@@F          )  Note 2 

  USE@@P IFGT *ZERO                )  Note 3 

          '
          '
          '
          '
    	ENDIF

Note 1:

In this section of the code, the name of the relevant field is moved into the USE@@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 USE@@N has been set with the name of the field, subroutine USE@@F is executed, which determines whether the field has been requested by the calling function. Again, the USE@@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 USE@@P, upon return from the USE@@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 USE@@N variable, don't code any definition of the USE@@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.