Visual LANSA Forum

Anyone know where data area DC@OSVEROP settings are stored in a Windows environment?
I suspect it's in an internal table or .dat file somewhere?
The documentation is IBMi centric when it comes to these settings and ignores the Windows platform.

what kind of information are you looking from the dc@osverop?
in windows, there is no data areas, and things like version of compiler to use, are in the windows registry.
A lot of things in the dc@osverop only makes sense for IBM systems, not windows

Specifically looking for the equivalent of this setting on Windows:
Relax restrictions on trigger functionality . . . : N

In case some settings are not relevant to Windows, then that should be mentioned in the documentation. This has been done in other places too, when you look under "Portability considerations".

In the IDE choose the File menu, then System Information. On the right side look for the section "Execution and Security". Double click on it. The last entry of the section is "Relax Restrictions on Trigger Information".

Thanks Casey, do you know where this setting would be stored in a runtime environment (no IDE installed)? Would this setting be relevant for a runtime environment?

Hi,

In LANSA runtime environments that will depend on the situation:

In general, you can distinguish these 2 situations:

a) a LANSA Environment using a Database
>> Then it will be read from the Internal LANSA database files

Or is it

b) A LANSA environment without any database connection?
>> In this case it will use the .xqd (i,e flat file extraction) files that were created by a *SYSEXPORT and ended up in
the partition's source directory.

This works the same for the main LANSA dataareas, Partition details , and other main LANSA System settings.


( Please do note that this is not always 100% the case, as it can be different in some situations where this is overrruled by the
LANSA X_Run System parameters (e.g. like FXQF) but that would only be used in special situations when advised by LANSA
technical persons to use this in order to overrule the defaults)

I am not sure where this is stored in a runtime environment. But I am pretty sure the feature you are referring to only applies at compile time so this wouldn't be a setting you need to worry about at run time. You could confirm this by having your trigger program call another function after you turn this setting, then turn it off and confirm the program is still called by your trigger.