×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Charles,
You said:
They could.
On the other hand, using logicals with DTAMBRS(*ALL), you could easily write an application that
doesn't know that it's working with a mult-membered file. <<<
If you're working with a real RDBMS you don't need to nor want to do such a thing. Your program or query tool just sees the ONE table name. How the DBA set up the table for performance or availability is not something the programmer or query person has to worry about. Nor should they as that's one of the selling points of an RDBMS in the first place. And, the DBA uses a CREATE TABLE (only ONE table) statement not some other non-relational construct. In the real RDBMS world, programmers and query writers have long since not had to worry about table construction or access methods. I know the i5 world says you don't have to but I sure see a lot of questions on here about "file like" access methods.
I so wish die-hard DB2/400 folks that think their platform is the "bees knees" could spend some time working on those RDBMS that are considered viable commercial RDBMs. Then they could better understand what I'm talking about and see how DB2/400 really stacks up.
Dave
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
