RE: ILE Conversion

Peter:

I specifically disagree with using the physical file format as the
interchange format between the applications and the file server programs.
It was done at the time and I objected in writing but it didn't help.  They
did it anyway.  We are in violent agreement.

Here is how I would approach this problem.

Suppose that I created a table to store record format definitions (not
specified in more detail at this time) and another table to relate record
formats to the physical file and to file server programs.  In that way, we
could externally define multiple formats to be used by the file server
programs and support their inclusion into both the file server programs and
the "using" application programs.

Suppose that one of the "control and status" fields contained a record
format name.  The file server program would contain all the defined formats
and logic to copy the physical fields to and from the format fields.  The
file server program should contain finite state machine logic to verify that
only the fields returned to the caller on a read operation could be updated
in a subsequent insert or update.

If there was a coding convention that the record format name was moved into
the appropriate "control and status" field just before the call, it would be
possible to write a pre-processor that could verify that the caller always
used a valid format - the called file server program would never get an
invalid format name.  This is done to reduce the coding effort for the error
handling code.  There will always be at least one application program that
cannot be checked with the verifier.

So, by creating some tables and maintenance programs and compile-time edit
programs, I think that we get a good prototype to insulate the application
programs from the underlying physical design.

Now, onto phase 2.  Create mapping rule specifications and attach them
between the format specifications and the physical file format definition.
Create a mapping code generator that runs as part of the file server program
generation.  It will generate the correct code to perform the mapping.  What
am I getting at here?  Imagine that you want to call the file server
programs from a C program.  C is not fond of the character string definition
used by RPG.  Take the RPG chars and convert them into C strings.  Although
ILE RPG supports packed decimal, it is an extension to the ANSI C specs
(isn't it?).  Convert packed decimal into another format.

Most database tables contain coded data.  In other words, there is a table Y
containing at least two columns, Y-code and Y-description.  Y contains one
row for each possible value of Y-code.  In some other table X, there is a
field X-code whose definition is, "X-code is valid if there is a row in Y
whose Y-code value match X-code".  Y-description is a character string
describing Y-code.  Wouldn't it be nice if I could specify a format
containing the fields X-code and the matching Y-description?  This supports
a 3rd-normal-form physical implementation and a virtual 2nd-normal-form
interface.

A file server program that runs on the 400 is a good thing but wouldn't it
be interesting if the code generator could create programs for other
platforms?  Well, how do we simulate CHAIN?  How about SQL Select?  Since it
is generated code, suppose we add the ability to generate SQL?  Or the
appropriate interface for Oracle or ODBC?  I think that you get the idea.

I can envision logical joins across two or more dissimilar databases -
without writing file server code.  I am getting carried away.

Did I answer your original question?  You asserted that the design I
described - using the physical file format as the interchange format between
the application program and the file server program - does not insulate the
application program from the physical database design.  I agree with your
assertion.  I think that it is architecturally wrong to use the physical
file format as the interchange format.  It is wrong because of the reason
you describe and because it eliminates a large number of very valuable and
completely rational opportunities that have a high affinity to database
access.  We are in violent agreement.


Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Peter Dow
Sent: Tuesday, July 04, 2000 2:56 PM
To: RPG400-L@midrange.com
Subject: Re: ILE Conversion



Am I missing something? You say that "If you externalize your database
interface, you can change the database without having to change the
applications." As near as I can tell from your discussion of the file server
program, that's only true if you are talking about adding new fields at the
end of the record. If fields are rearranged, if an existing field expands or
contracts, if new key fields are inserted in the key list, I would think the
application programs would have to be revisited. Am I wrong?

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---