× 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.



Comments inline

On 1/14/2017 8:18 AM, D*B wrote:
Hi Vern,

I saw also that there are ISAM APIs that provide ways to get to data in an ISAM setup. Do we mean like CHAIN, READ, READE, etc.?

yes

The same article makes this assertion - "Relational databases <https://en.wikipedia.org/wiki/Relational_database_management_system> can easily be built on an ISAM framework with the addition of logic to maintain the validity of the
links between the tables. "

they could, but ISAM is only one way to implement, what MySQL calls a "stotage engine"
******************************************************************************************************************************************
Agreed - I see ISAM as an underlying framework - it could be a networked database or an heirarchical one, probably - there is the implementation at a lower level and the way we have access to it - ISAM to me seems more of the low-level way data is organized, and both RPG RLA and SQL are ways of working with it an an application level.
******************************************************************************************************************************************
I do believe that we do have an ISAM framework and an RDBMS over it. Any distinctions of those 2 concepts, these 2 different levels of abstraction, are not very important, to my way of thinking.

that's true for the world of DDS described tables. These are ISAM tables and the old query engine (CQE) is a layer above, representing a RDBMS.
For SQL tables the relation is the opposite way. The ISAM APIs are using a RDBMS (and only a subset is implemented)
******************************************************************************************************************************************
I was on the team that was testing the new query engine in Rochester, in 2001. I have looked at data files in SST, whether created as PFs or as tables - they all look the same. There is no opposite way so far as the physical layout of the objects - they still use blocks on disk to hold the data, they all use the same constituent space MI objects - the difference is in certain attributes that allow certain methods to be used against DDS-created objects and other methods to be used against DDL-created objects.

Both RLA and SQL access use the same low-level DB components in SLIC, RLA and CQE and SQE - all are a layer above the low-level DB subsystem (data management) that itself used storage management functionality.
******************************************************************************************************************************************

The way to the future is to forget ISAM and use higher levels of abstraction to access databases. SQL is only the next step, then there are data access procedures/functions, next level are ORM (object relational mapping) frameworks.
******************************************************************************************************************************************
I can't agree completely with this - if by ISAM you are speaking of RLA in RPG and COBOL and C/C++ and REXX, etc., I believe all that is still an advantage of our system - we might not agree on that, but that's alright, eh?
******************************************************************************************************************************************

Dieter


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.