Version Dependency Data Area DC OSVEROP

You are here:

Version Dependency Data Area DC@OSVEROP

The version dependency data area DC@OSVEROP is optional. It may or may not exist on your system.

DC@OSVEROP is a different style of data area. Rather than setting a special byte within the data area to enable an option you simply include a pre-defined text string anywhere at all within it.

These Strings are also converted to Y/N flags or values and exported to Visual LANSA in file LX_F96 when a system export, *PLUGIN or *REFRESH is performed. They can be changed in Visual LANSA through the Configure menu.

DC@OSVEROP may contain one or more of the following strings:

String	Meaning / Comments
*CHECKBOX=x	x defines the character used to depict check boxes when displayed on the screen painter, or printed on a screen design report. The default character is X'9F'.
*CRUDEWARNONLY	Indicates that a function that would cause the "Crude Element Complexity Rating" to return a FATAL will cause a WARNING only. It is not recommended to use this setting as the function may subsequently fail to compile.
*DBCS_BUILD	Indicates to always build IBM i RDML objects (DDS files and programs) for DBCS, irrespective of the current build language. This value does not impact the build of RDMLX objects on IBM i or the build of Windows objects. When DBCS_BUILD is not present in DC@OSVEROP, RDML IBM i objects will be built according to the current build language type. When DBCS_BUILD is present in DC@OSVEROP, all RDML IBM i objects will be built as though the current build language is a DBCS language. For example, all DBCS keyboard shift attributes of J, E or O for fields will be generated into the DDS.
*DROPDOWN=x	x defines the character that follows a field to indicate that it is drop down capable. This character is also used when the field is displayed on the screen painter, or printed on a screen design report. The default character is 'V'.
*EXTENDED_TRIGGERS	Indicates that the normal LANSA rules that prevent database event triggers from calling other functions and using "user interface" commands should be relaxed. This use of this option is not recommended in most circumstances.
*FUNRTRLIBL	Controls the use of Function Routing table X_FUNRTR from *LIBL. If this is not set the Function Routing table in the partition module library will be used. See description of Function Routing for further details.
*HSTABEXTEND	Allows database files with record lengths up to 1988 bytes to be added to a user index for high speed lookup. WARNING: Refer to Database File Attributes before using this option. WARNING: It is strongly recommended that if option HSTABEXTEND is added to system data area DC@OSVEROP to make the extended entry record length available, or is removed to limit entry length, that all files tagged as high speed tables, all read only functions that use these files and all other I/O modules and Dboptimized functions that use high speed tables for lookup validation rules be recompiled AFTER deleting the current user index which is DC@TBLIDX if adding HSTABEXTEND, DC@TBLIDY if removing *HSTABEXTEND.
*ILE See Note 2	Activates the second level of ILE implementation. That will statically bind any GUI and multilingual program into the function program and use supplied service programs to dynamically call (CALLB) LANSA internal programs. *** Must be used in conjunction with RPGIV **
*IMPREFFLDNOPROP See Note 3	If present when an Import executes, it indicates that Reference Field characteristics are not propagated to fields that reference those Reference Fields. Note that if a Reference Field is changed subsequently, the changes are propagated to the fields that reference it, as usual.
*IOMBLOCKBYKEY See Note 1	Use this option to indicate that I/O modules should be compiled to support high speed record blocking in physical file key order. You must use this option when using LANSA Client. You must use this option when using the LANSA SuperServer BLOCKBYRRNnnnn selection option or the "receive immediate" option. You must use IOMXSERVER if you use this option.
*IOMBLOCKBYRRN #1	Use this option to indicate that I/O modules should be compiled to support high speed record blocking in relative record number order. You must use this option when using LANSA Client. You must use this option when using the LANSA/ Server BLOCKBYRRNnnnn selection option or the "receive immediate" option. You must use IOMXSERVER if you use this option.
*IOMNOADOPT	Indicates that all I/O modules created by LANSA are to have USEADPAUT(*NO) i.e. do not use program adopted authority for I/O modules.
*IOMXSERVER See Note 1	Use this option to indicate that I/O modules should be compiled to allow support of: LANSA Client applications. and/or LANSA Open applications using blocked I/O methods or the "receive immediate" option and/or Visual LANSA SuperServer applications. It is recommended that you set the full list of values IOMXSERVER, IOMBLOCKBYKEY and *IOMBLOCKBYRRN into data area DC@OSVEROP as a system default for all LANSA systems.
*LEADZERO	'1' indicates that Visual LANSA code will display numeric values containing decimals with a leading zero. For example, 0.12 or 0,12 depending on the LANSA decimal point format. This option would be suitable when QDECFMT='J'.
*LONG_USER_AUDIT	Indicates that user stamping (USRC, USRU, USRX) fields will be supplied with a user name of up to 256 characters. Refer to detailed information in Output Stamping Attributes for more information.
*MINISCREENMSGLIN=xx	xx specifies the line that IBM i messages will appear when using the *MINI_SCREEN facility. The full function checker does NOT validate that the line specified falls within the pop-up windows used.
*NOL4WCOMP	Disables Visual LANSA component-related information from being transferred between a LANSA for the IBM i system and Visual LANSA systems. The flag affects the export, check out and check in functions. Warning: Use of this flag should be considered carefully to avoid loss of component details.
*NOLADCOMP	Controls how Visual LANSA component-related information is exported and imported between LANSA for the IBM i systems. Warning: Use of this flag should be considered carefully to avoid loss of component details.
*NOWEBEXP	Disables the export of all Web details. This includes Web components as well as web details associated with fields, functions and system variables.
*NOWEBIMP	Disables the import of all Web details. This includes Web components as well as web details associated with fields, functions and system variables.
*ODBC #1	Use this option to indicate that I/O modules should be compiled to allow support of the LANSA Open (LANSA Open) ODBC Interface. You must use *IOMXSERVER if you use this option.
*OTHER_DATETIME	Indicates that the conversion option *DATETIME is to be used when OTHER file I/O modules are compiled. This allows date (L), time (T) and timestamp (Z) fields to be accessible in LANSA.
*OTHER_VARCHAR	Indicates that the conversion option *VARCHAR is to be used when OTHER file I/O modules are compiled. This allows variable length (VARLEN or varchar) fields to be accessible in LANSA. Note that this setting does not allow variable length character fields to be used as keys within LANSA. If the physical file or any logical views made known to LANSA have a varchar field as a key, the I/O module will fail to compile.
*PERMFILOVR	Allows permanent file overrides to be used. When you specify permanent file overrides you are telling LANSA that "every time I use this file, I really want to use this other file". This is useful when you want to use files with 10 character file names, files with a "." in their name, etc. Refer to The Permanent File Overrides Facility for details and examples.
*RADIOBUTTON=x	x defines the character used to depict radio buttons when displayed on the screen painter, or printed on a screen design report. The default character is X'80'.
*RPGIV See Note 2	Specifies that each program is to be compiled using RPG/IV code, then bound as a single module ILE type program.
*SELECTCHAR=x	x indicates the character used to select an option from a check box or radio button group. The default character is '/'
*SQL_BUILD	Indicates to build physical files and logical files on IBM i using SQL as much as possible when in an RDMLX partition. The physical file will be built as an SQL table.This keyword will have no effect on how logical files are built, and logical files sharing the access path of a corresponding SQL index no longer occurs. Note that there are some valid CRTPF /CHGPF parameters that will not be able to be applied to physical files created as tables using SQL, and similarly some valid CRTLF / CHGLF parameters that will not be able to be applied to logical files created as indexes. One such parameter for both is MAXMBRS with a value other than 1 or SAME. RDML files built when the SQL_BUILD option is in effect can be imported to RDML partitions provided they do not have DB triggers set on, however if they are rebuilt in the RDML partition they lose the effects of the *SQL_BUILD option.
*TTG6FUNCLOCKING	Disables the new task tracking logic that enforces that all functions are locked with the same Task Id as the parent process. This flag only applies when the 'Allow user to change tasks while working?' task tracking configuration flag is set to no.
*UIMHELP	Indicates that the IBM's Panel Groups are to be used for the presentation of user defined help text, rather than the LANSA help text display facility. *V2WINDOWS must also be selected.
*V2WAF/400	As the parameters used to call Workfolder Application Facility/400 have changed with V2 this option is used to determine which parameters to use.
*V2WINDOWS	Indicates that pop-up windows created by LANSA should use the IBM i windowing facilities.
*WEBNUMVAL	Indicates that the default for the web process compile option 'Validate numerics' should be 'YES'. Refer to the section Compiling a Process from New or Amended Definition for details of this option. This also indicates that the COMPILE_PROCESS Built-In function default should be 'YES' rather than 'NO'.
*WINDOWTRIM	Indicates that an existing LANSA defined pop-up window has the 2nd function key line trimmed from the display. Only use this option in conjunction with the *V2WINDOWS option to enable existing functions that have been specifically sized onto line 24 of the display device to recompile without change.

Note 1 *IOMXSERVER, *IOMBLOCKBYKEY, *IOMBLOCKBYRRN and *ODBC increase the number of files declared in an I/O module, the amount of static (literal initialized) storage used by an I/O module and the number of subroutines in an I/O module. Note also that if one of *IOMBLOCKBYKEY, *IOMBLOCKBYRRN or *ODBC are specified, *IOMXSERVER must also be specified.

Note 2 RPGIV and ILE: Before you attempt to use any of the RPGIV and ILE related switches it is highly recommended that you first read the ILE Implementation section of this guide.

If you have grossly exceeded the recommended limits for the number of logical views created (or made known to LANSA) then you may find that an existing I/O module may not (re)compile when these options are used.

If you have grossly exceeded the recommended number of real or virtual fields in a physical file then you may find that an existing I/O module may not (re)compile after these options are used.

In either case, temporarily remove the options from data area DC@OSVEROP while recompiling the I/O module that is experiencing the problem.

Also note that RPG/IV (V3 version of RPG from IBM) has removed the total file, total static initialized storage and total subroutine limits that may be causing such problems to occur.

Note 3 *IMPREFFLDNOPROP is also used by the host monitor and LANSA Import to decide if reference field changes should be propagated. Prior to V9.1 no updates were performed during these operations and "no update" is the initial default setting.

This flag now offers the choice of propagating changes or not.

The use of this flag is not recommended as fields may become out of synch with their nominated reference field and therefore it should be removed from DC@OSVEROP and set to 'N' in Visual LANSA.

When this flag is NOT set to 'N' the input and output attributes to a field which references another field are not protected. This was was the default before V9.1.

It should be remembered that when a field which is referenced by other fields is changed using the field maintenance options or the PUT_FIELD Built-In Function, all the referencing fields are also updated.