Has anyone developed a better way to determine the required tables for
drill and selects in LSF-9?

Anyone else care to share their experience re this issue?

The Lawson documented way of going through Lawson Security form by form
and rt-clicking on the form field then selecting "Drill Explorer" is the
most ridiculous thing I have ever heard of.

Unfortunately, I don't have clue how to construct the proper LDAP query
to return this info (assuming that's the place to look).

BTW...this is only an issue because my current client insists that each
security class contain all necessary security for the apps being
secured, including access to the required drill fields. They do not
want to create security classes such as "FilesAP", "FilesGL",
etc...granting access to all files in a system code and then just plase
those security classes in various roles.

They only have about 45 different security classes with a total of 635+
different applications. Obviously many of the 635+ apps are secured in
more than one security class.

TIA,
~Shane

This may be an answer, but not a very good one. The drill capability comes from any input field that has a Select. If a field has a Select capability, there are 5 places you have to look to find out what's going on:
...1 The input Form for that particular screen
...2 The KNDEF utility
...3 the SKNDEF utility
...4 The Screen Rules (xx.sr) file
...5 the Object Rules (xx.or) file

...1
Screen Rules form: Check the "$TRANS" section. Column "KN" (column positions 55-58) contains the key number. The Key Number is the link to the Screen Rules. If a field does NOT have anything in the Key Number field, it SHOULD NOT have any Drill-Around or Select capability.

That gives you a quick way to find out what fields on a Form have Drill-Around / Select capability: Look in the $TRANS section.

...2
KNDEF defines what special Name goes with a Key Number.

WARNING: The Name appears to be independent from any other object in the system, but seems to link to field (column) names in a database file (table) in many of Lawson's 4GL utilities.

NOTE: Key Numbers are defined here, they are not usable until activated for a System Code using SKNDEF.

...3
SKNDEF activates the Key Number for use in any particular System Code.

...4
The Screen Rules (xx.sr) file defines how the Name will be used. You have to know that when a Screen Rule talks about a particular Name, it's matching to a Key Number on a Form. Screen Rules are System-Code wide, there's only one .sr Screen Rules file per System Code.

...5
And finally, the Object Rules (xx.or) file defines how Drill-Around works. It won't work without the Screen Rules. I've written a detailed analysis, posted somewhere in this section, a while ago.

..................
In the short term, it's a LOT easier to just right-click on a field than to go through the gyrations I've begun to describe above. Oh, and one more thing: All of the code used to enforce all of this has NOTHING to do with the underlying COBOL. The compiled program executes the Screen and Object rules at a layer above the compiled COBOL code.

Good luck understanding this, it took me weeks and months. :disco:

Ref: Doc for Developers: Application Development Workbench Standards

Because I can't remember where I posted that info, and I couldn't find it when I looked, I'm uploading the info here.

This is the Object Rules diagram.

Here is the Screen Rules diagram.