SQLRPGLE performance problems - IBM AS400

This is a discussion on SQLRPGLE performance problems - IBM AS400 ; "Dieter Bender" wrote in message news kfum4-sgv.ln1@eiffel.bender-dv.de... > with my statement: > > is talking about tables with multiple formats, I don't know how this is > implemented in os400, in some cases formats seem to be no longer unique ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: SQLRPGLE performance problems

  1. Re: SQLRPGLE performance problems


    "Dieter Bender" wrote in message
    newskfum4-sgv.ln1@eiffel.bender-dv.de...
    > with my statement:
    >
    > is talking about tables with multiple formats, I don't know how this is
    > implemented in os400, in some cases formats seem to be no longer unique
    > (create table as .... twice and loooking to the format level ids, or was
    > it
    > create table like ..., or maybe a bug, I don't know?), but this was not in
    > scope of the discussion (why is a single synchronous read by rla faster as
    > by sql.
    >


    Sorry I was speculating on the additional physical file complexity that the
    DB2/400 environment has to cater for which other SQL reliant RDBMs don't
    typically need to worry about. The concept of record formats is completely
    alien to other vendors as can be seen most obviously by the variance in the
    connection strings for, say, ADO, between the DB2/400 and the other
    databases.

    Rj.







  2. Re: SQLRPGLE performance problems ; digression: record formats

    Most of the following details are available directly from DMPOBJ of a
    database *FILE object.
    The "format" is an object of type *FMT. As an 'internal object
    type', the format object is not exposed [externalized to a user] in a
    library. As an object-based system, this allows the database to
    encapsulate the definition of the columns rather than storing them
    externally [with respect to the TABLE or VIEW] in the catalog; the *FILE
    being a composite object. Having a format to define the columns enables
    just the one sub-object to represent, without redundancy, multiple
    composites. The format object is tracked in a database directory object
    of type *DBDIR when more than one composite references that format.

    Another RDBMS which does not support this self-describing
    object-based nature would not need a concept of a 'format', as they can
    just extract the list of fields that define the layout [aka format] of
    the data. The i5/OS also supports effectively that other way to define
    the layout, using the data dictionary object as is done for [linked]
    S/36 files even on the S/36 -- the *DTADCT for SQL in pre-v3r1m0 was
    effectively redundant [now deprecated], only used prior to the existence
    of active tracking of columns to the system-wide dictionary [file
    QADBIFLD].
    The DB2 for i5/OS SQL only allows a single format [aka layout] for a
    TABLE or a VIEW, so the reference to combining header and detail data is
    not applicable there.

    When a database file is deleted and its format is either not tracked
    to a directory or otherwise would be the last file to 'own' that format,
    the format is destroyed.

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    Thomas wrote:
    > DBDriver wrote:
    >
    >>> RLA transfer the data by Format, SQL at field level RLA checks
    >>> the data by format level id (level check) SQL is strongly typed
    >>>

    >> See here's where it gets interesting though. How many other RDBMS
    >> even support the notion of formats? From experience formats tend
    >> to be just a lazy means of mixing Header and Detail records in a
    >> single file for faster sequential access in traditional
    >> processing. Very much not a normalised approach to table
    >> structures.

    >
    > ??? I'm completely in the dark about how 'record formats' and
    > 'mixing Header and Detail records in a single file' have any
    > relationship to each other, except that 'records' in externally
    > described files have formats.
    >
    > A 'record format' seems to be a database object under OS/400 (and
    > i5/OS). They're created at a level apparently inside TIMI since, AFAIK,
    > there is no object type that's externalized for programmer use.
    > E.g., you can list objects of type *PGM or *FILE, but there is no
    > type [*RCDFMT] or whatever they might be called.
    >
    > A given record format will be unique within each ASP. If a new file
    > is created that resolves to the same format, the single format is
    > shared.
    >
    > I've seen no info on what causes a format object (or compound object
    > possibly) to be deleted. They might always exist or might be deleted
    > when no files reference them.
    >
    > That's about as far as I can discuss format objects because there isn't
    > enough widely publicized info about them. I'd love to see more detail
    > from anyone who can supply it.


  3. Re: SQLRPGLE performance problems ; digression: record formats

    CRPence wrote:

    > Most of the following details are available directly from DMPOBJ of a
    > database *FILE object.


    'Ask and ye shall receive.'

    Thanks, Chuck. It's good to read significantly authoritative details
    once in a while. Maybe if I retire someday, I'll find the time to
    decompose *FILE objects in detail. For now, this kind of stuff is plenty.

    --
    Tom Liotta
    http://zap.to/tl400

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2