|
Joe,
Since you are moving from application to system programming, I question the use case definition that it has to be generic, in fact I'll suggest it's probably inappropriate. The probability of malicious code getting into the system gets too high, and with these types of application where the security granted to the user is quite high, makes it a questionable endeavor.
System programming relies on knowing the system you are connected to and setting it up for that specific situation. It' rare when we have multiple systems that are so similar in usage and workload that they could be considered generic.
Therefore, rather than try to find a generic solution, why not modify the approach and fetch the name of the system from the system or another source, and then concatenate that into the SQL as needed. More complicated, sure, but then you also have the ability to stop malicious code. Also varying the user profiles and authorities between systems will make things more secure as well.
Maybe what you might consider would be a web service or API that has the appropriate security built in to give your application the information it needs without exposing the underlying structure of the system?
The days of write once, push across many systems are quickly fading due to multiple threat vectors that we need to deal with. Our use case definitions need to reflect that.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Joe Pluta
Sent: Tuesday, April 13, 2021 9:44 AM
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Three part names and library lists
I spent a lot of time recently working with external ODBC connections
and library lists in order to follow some best practices with external
processes. Basically, these processes can be used in either a test or
production environment simply by changing the connection. That's done
by removing all schema qualifications from tables, views, procedures,
etc. This works wonderfully. Fast forward, and I've just started
using three-part naming to reach across partitions. I've done this
primarily for system analysis (object statistics and so on) so I
haven't had to worry about environments. I just use
partition1.qsys2.object_statistics
and I'm fine. But that doesn't play well with the idea of using an unqualified table name for application data. I haven't found any sort of syntax like partition1.*libl.mytable that will work. I'm afraid there may be no such syntax, but I figure if anyone knows, it's the members of this list.
So IS there a way to do a cross-partition unqualified table reference?
I don't know, sounds like it might be a technical oxymoron. :)
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
