18.7 The .XQ* Files

18.7.1 Tips for Setting up and Using .XQ* Files

Any PC that executes an application using DBID=*ANY, DBID=*AS400, DBID=*OTHER, DBID=*NONE or DBII=*NONE needs to have a special set of additional files created or installed on it, or available to it via a connected server disk drive.

These files are called the "xq*" files and are accessed by your generated Visual LANSA application(s) when users perform actions such as prompting, display help text, etc.

Values *NONE, *ANY, *AS400 and *OTHER are identical in indicating that no local DBMS system is to be used. The difference is that the value *ANY, *AS400 or *OTHER is used to additionally indicate that an automatic connection to a Server is to be established. The details of the connection are defined by a series of PSXX= parameters which are described in 18.4.12 PSxx Server Parameters.

The .XQ files are used in place of a local DBMS for read-only dictionary/repository access.

The complete set of these files is:

Name

Description

lx_msg.xqi

Message definitions

lx_msg.xqd

lx_f96.xqf

System definition (not used on IBM i)

lx_f46.xqf

Partition "ppp" definition

lx_f60.xqf

Partition "ppp" languages

lx_f03.xqi

Partition "ppp" field definitions

lx_f03.xqd

lx_f40.xqi

Partition "ppp" program defined and overridden field definitions

lx_f40.xqd

lx_f62.xqi

Partition "ppp" field descriptions

lx_f62.xqd

lx_f04.xqi

Help text

lx_f04.xqd

lx_f61.xqi

*MTXT values

lx_f61.xqd

lx_f05.xqi

Validation rule definitions

lx_f05.xqd

lx_f06.xqi

Validation rule definitions

lx_f06.xqd

lx_f07.xqi

Validation rule definitions

lx_f07.xqd

lx_f08.xqi

Validation rule definitions

lx_f08.xqd

lx_f09.xqi

Validation rule definitions

lx_f09.xqd

lx_f10.xqi

Validation rule definitions

lx_f10.xqd

lx_f11.xqi

Validation rule definitions

lx_f11.xqd

lx_f44.xqi

Process attachments

lx_f44.xqd

lx_f64.xqi

Physical file descriptions

lx_f64.xqd

lx_f65.xqi

Logical file descriptions

lx_f65.xqd

lx_f66.xqi

Process descriptions

lx_f66.xqd

lx_f67.xqi

Function descriptions

lx_f67.xqd

lx_f27.xqi

File Definitions

lx_f27.xqd

lx_f15.xqi

Logical Files

lx_f15.xqd

lx_f14.xqi

File Fields

lx_f14.xqd

lx_f26.xqi

System Variables

lx_f26.xqd

 

These files are in binary format. They are "read only" files and should not be manually edited with any type of tool.

Failure to observe this rule may lead to application failure and/or unpredictable results.

When created, each set of lx_fnn.xqi and lx_fnn.xqd are a "matched pair". File lx_fnn.xqi is an index and makes direct offset references into the lx_fnn.xqd (data) file. You must always create, ship and install both of the lx_fnn files together as a pair. Failing to observe this rule may lead to application failure and/or unpredictable results.

All lx_fnn files are placed into the partition source directory (x_lansa\x_ppp\source). If a file does not exist it is created. If it does, it is cleared of all existing data before the export proceeds.

In execution environments, when a specific file is being read, the x_lansa\x_ppp\source directory is always checked first. If the file cannot be located in that directory, the x_lansa\source directory is checked. This allows flexibility in deployment. For example, different partitions can have their own copy of the message file.

The xq* files may be created on any Windows development system at any time. To do this use the X_RUN command like this:

    X_RUN PROC=*SYSEXPORT FUNC=ttttt LANG=xxx PART=ppp .... etc.

The "ttttt" value can be specified as an individual table name (e.g. LX_F03 or LX_F46) or as *ALL. The special value *ALL causes all the output files to be produced.

Once started, the export process displays a standard event log and updates it as the export proceeds. When complete, an "OK" button will appear in the event log window, allowing you to review the messages. When you click on the "OK" button the export process ends.

The lx_fnn files will support system initialization, field prompting and help text display in a totally standalone environment. These are the essential elements of being able to execute an application in a standalone environment.

Any other form of database activity will fail unless the I/O operations are "diverted" to a server.

Note that I/O operations also include object lock requests (which may be automatically diverted to the server) and IBM i data area emulations (which must be manually diverted to the server by using the CALL_SERVER_FUNCTION facility). Other Built-In Functions such as SAVE_LIST may also involve database activity and must be manually diverted to the server.

Imagine a function that must perform some activity and give the result(s) back to the caller. For example, it might allocate the next order number, or save a list, etc.

The activity must always be performed on the server.

By structuring the function like this:

function *direct rcv_lsts(<working lists>)

 

exchange <other information> options(*always)

 

if *cputype = as400

      <perform required activity> 

else 

       use call_server_function ( ... itself ....... ) 

endif

return

 

When called on an IBM i this function does its job and receives and returns information via working lists, exchange lists, and so on.

When called in a PC application, the function immediately calls itself on the associated server (which does its job and returns the results).

To the program that called this one, the switching to the server (if required) is invisible and immaterial.

By using a more flexible and dynamic switch than "*cputype = as400" a very powerful and dynamic means of switching logic between the client and server could be designed.

User Defined Messages

User defined Messages will not be copied to LX_MSG.XQD / XQI files. Therefore the use of FXQF=*ALL is not recommended in scenarios where you have your own application specific messages. In such cases the use of a message file is required.