Hi Patrik
That does look similar in concept to the example I gave. That one could be generalized, I suppose, as a header file (or LF in this case) that is its own detail file - it has a format like this -
EMPLOYEEID EMPLNAME JOBTITLE MANAGERID (other things, such as email address)
It's really an employee file, with employee-specific data, including a relationship to another management level.
Isn't this also similar to a bill-of-materials for building something, especially where different components can have some of the same parts?
Another shot in the dark - would matching records between overridden PFs do what you want? You're closer to that kind of thing, I've not done matching records since school in 1989.
Cheers
Vern
On Mon, 15 Jul, 2024 at 8:39 AM, Patrik Schindler <poc@xxxxxxxxxx> wrote:
To: midrange systems technical discussion
Hello Vern,
Am 15.07.2024<
http://15.07.2024> um 14:53 schrieb Vern Hamberg via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>>:
Maybe Patrik can give a more-detailed example - I can think how we use a file here that has employee numbers for both an employee and its manager, with detail information for each according to their own employee number.
That is a good example which isn't too far fetched from what I'm trying.
The underlying topic is not at all business related but more about gaming. I'm currently trying to follow the "best" path to success, for "best" meaning:
- Learning to build complex LFs from existing SQL (because they outperform SQL on my 150)
- Solve the greater problem with the least sensible programming effort
- Complete the SQL so the problem at hand can be solved e. g. on other platforms as well
Specifically, this is about armor in a game. Said armor comes in five parts: Two arms, two legs, torso. Armor parts can have three tiers of "legendary attributes", but the set of attributes is generated randomly when the player obtains the respective armor part and not changeable afterwards. Also, each tier has a distinct set of up to 20 attributes: e. g. tier 3 attributes never show up in tier 1, etc.. Combining all available attributes yields 5700 distinct attribute sets.
How to choose the best set of armor when you have dozens of individual pieces? Why not use the computer to compute this? :-)
Thus I've created tables holding all obtained armor parts with their tiered attribute IDs, two tables to translate attributes and parts ids to meaningful text, and a final table where I assigned priority values to each attribute: How "desired" is a specific attribute to have? The higher the value, the higher the desire.
Output should be 5 lines, one for each armor part ("limb"). The output is sorted by "score" in descending order, score being the sum of all three tier priorities for a given part ("limb"). Best part is listed first.
I struggle to express another restriction in SQL: If a specific attribute is already part of a selected (listed) part ("limb") due to its score, lesser scoring parts with the same attribute should be excluded from the subsequent remainder of the list. Aka, each attribute shall be considered only once. The final list of parts should not contain any attribute more than once.
If there is sufficient interest in this puzzle, I can write in more detail, although its scope is much broader than my initial question.
In RPG, I can see using 2 CHAINs to the same LF, in order to get the names of both employee and manager on the same line of a report.
Yes, that is the programmatic way. If possible I'd prefer to use existing facilities of LFs (or SQL).
Bottom line:
- There should be one RPGLE application for generating a report where record selection is done in a traditional way: Reading a file, add further information with CHAINs to auxiliary files, compute score, sort by score, eliminate duplicate legendary attributes, copy result set to printer/DSPF until five distinct parts are output.
- There should be — ideally just one — big SQL doing the same.
So what is the actual need here?
Did that help?
:wq! PoC
midrange.com
