Jan-Erik Söderholm wrote:

> Is there any drawback having the files beeing set to
> variable record format when one is always using fixed
> sized records anyway ?


2 extra bytes for the record length are stored. And I think if the
record legnth is and odd size, a padding byte at the end. (not sure
about fixed length record of odd size needing a padding byte or not).

There are probably a few more assembler instructions that check the
record length to ensure a record being read will fit into the buffer
(since each record could be a different length).

JF Mezei wrote:
> Jan-Erik Söderholm wrote:
>
>> Is there any drawback having the files beeing set to
>> variable record format when one is always using fixed
>> sized records anyway ?
>
>
> 2 extra bytes for the record length are stored. And I think if the
> record legnth is and odd size, a padding byte at the end. (not sure
> about fixed length record of odd size needing a padding byte or not).

OK, so to change to "fixed" one has to unload/reload
the data due to the extra lenght bytes, right ?

>
> There are probably a few more assembler instructions that check the
> record length to ensure a record being read will fit into the buffer
> (since each record could be a different length).
>

OK, doesn't matter much probably.... :-)

Anyway, if the Rdb Gateway to RMS doesn't complains about
it, I'll probably just leave them as "variable"...

This once was a RMS-only "database" a long time ago on
some 11/7xx box. Aprox 10 years ago a switch to Rdb
was started and never finished. The systems today has
aprox 50-60 tables in Rdb and aprox 20 in RMS indexed files.

I'd like to at least beeing able to run ad-hoq queries
joining RMS files with Rdb tables...

JF Mezei wrote:
> (not sure
> about fixed length record of odd size needing a padding byte or not).

It does.

Arne

Hi Jan-Erik,

Maybe they wanted to be able to add any new fields to the end of the record
and leave in-situ historical data untouched? Is there a record-type field
somewhere? A returned record-length check? Who knows?

Cheers Richard Maher

PS. Is DBI and Transparent Gateway still supported or sold?

"Jan-Erik Söderholm" wrote in message
news:JWKQk.3898$U5.25028@newsb.telia.net...
> Hi.
> While analyzing some old indexed RMS datafiles
> that I *know* always are used with fixed size
> records (from COBOL apps), I've noticed that
> they are created with :
>
> RECORD
> CARRIAGE_CONTROL carriage_return
> FORMAT variable
> SIZE 280
>
> Question is, why not use "fixed" when all records
> are fixed size anyway ? My best guess is that it is
> like this just becuse "variable" is the default, and
> noone has ever thought about changing it to "fixed"...
>
> Is there any drawback having the files beeing set to
> variable record format when one is always using fixed
> sized records anyway ?
>
> (Apart from the one I do know about. "Rdb Transparent
> Gateway to RMS" has some restrictions on variable
> records formated indexed RMS files, but as I read it,
> it is no issue if the records are all the same size
> anyway...)
>
> B.t.w, this is part of a project to setup DBI and
> the "Rdb Transparent Gateway to RMS" to be able to
> run SQL queries against the RMS files and also run
> joins between the RMS files and between the RMS files
> and the Rdb database. It all looks just fine right now.
> I'm currently entering field, record and database
> definitions into CDD to get some metadata for the
> RMS files (about 20 files).
>
>
> Jan-Erik.

=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:

>Question is, why not use "fixed" when all records
>are fixed size anyway ? My best guess is that it is
>like this just becuse "variable" is the default, and
>noone has ever thought about changing it to "fixed"...

>Is there any drawback having the files beeing set to
>variable record format when one is always using fixed
>sized records anyway ?

I'm going to guess the file accesses of a fixed file will be a touch
faster, and the files will be slightly smaller, due to not having to
deal with the small overhead of dealing with the "variable" record length.

If you have a "sandbox" where you can play with your application, why not
use CONVERT/FDL to convert to a fixed record format, and run your
sandboxed application to see if it's any faster? I'm going to guess the
file size will be smaller but most of it will be due to squeezing out of
unnecessary space (deleted records/buckets) and only a small amount to
the variable/fixed conversion. Many RMS indexed files benefit from a
rebuild once in a while.

Richard Maher wrote:

> Cheers Richard Maher
>
> PS. Is DBI and Transparent Gateway still supported or sold?

It's unsupported.

I had to make a change in one of the command files in
one of the backupsets (DBI070A.A) to make it install
with Rdb 7.2.x. The version check included 4.1 - 7.1.

I have an updated .A saveset that can be used together
with the rest of the kit from Oracle, if someone is
interested.

Oh, and the "nonreletional gateways" (NREL) was commented
out in another command file, so I had to re-enable that
also to be able to install the NREL parts...

So, yes, it's definitely unsupported... :-)

Note also that the "Transparent Gateway for Oracle" from
the same kit has been in production use on this box for
years accessing an Oracle7 database on a AIX system. Works
like a charm, all accesses are from Rdb code in COBOL.

Jan-Erik.


>
> "Jan-Erik Söderholm" wrote in message
> news:JWKQk.3898$U5.25028@newsb.telia.net...
>> Hi.
>> While analyzing some old indexed RMS datafiles
>> that I *know* always are used with fixed size
>> records (from COBOL apps), I've noticed that
>> they are created with :
>>
>> RECORD
>> CARRIAGE_CONTROL carriage_return
>> FORMAT variable
>> SIZE 280
>>
>> Question is, why not use "fixed" when all records
>> are fixed size anyway ? My best guess is that it is
>> like this just becuse "variable" is the default, and
>> noone has ever thought about changing it to "fixed"...
>>
>> Is there any drawback having the files beeing set to
>> variable record format when one is always using fixed
>> sized records anyway ?
>>
>> (Apart from the one I do know about. "Rdb Transparent
>> Gateway to RMS" has some restrictions on variable
>> records formated indexed RMS files, but as I read it,
>> it is no issue if the records are all the same size
>> anyway...)
>>
>> B.t.w, this is part of a project to setup DBI and
>> the "Rdb Transparent Gateway to RMS" to be able to
>> run SQL queries against the RMS files and also run
>> joins between the RMS files and between the RMS files
>> and the Rdb database. It all looks just fine right now.
>> I'm currently entering field, record and database
>> definitions into CDD to get some metadata for the
>> RMS files (about 20 files).
>>
>>
>> Jan-Erik.
>
>

In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
> Hi.
> While analyzing some old indexed RMS datafiles
> that I *know* always are used with fixed size
> records (from COBOL apps), I've noticed that
> they are created with :
>
> RECORD
> CARRIAGE_CONTROL carriage_return
> FORMAT variable
> SIZE 280
>
> Question is, why not use "fixed" when all records
> are fixed size anyway ? My best guess is that it is
> like this just becuse "variable" is the default, and
> noone has ever thought about changing it to "fixed"...
>
> Is there any drawback having the files beeing set to
> variable record format when one is always using fixed
> sized records anyway ?

There's a tiny overhead for entering the record length
at the begining of each record. I suspect no one ever
bothered to "fix" it. You might actually see a performance
improvement if you change it, but you might also find
that you need a way to maintain upward compatability with
at least reading archived data.

On Nov 7, 2:02*pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
> > Hi.
> > While analyzing some old indexed RMS datafiles
> > that I *know* always are used with fixed size
> > records (from COBOL apps), I've noticed that
> > they are created with :
>
> > RECORD
> > * * * *CARRIAGE_CONTROL * * carriage_return
> > * * * *FORMAT * * * * * * * variable
> > * * * *SIZE * * * * * * * * 280
>
> > Question is, why not use "fixed" when all records
> > are fixed size anyway ? My best guess is that it is
> > like this just becuse "variable" is the default, and
> > noone has ever thought about changing it to "fixed"...
>
> > Is there any drawback having the files beeing set to
> > variable record format when one is always using fixed
> > sized records anyway ?
>
> * *There's a tiny overhead for entering the record length
> * *at the begining of each record. *I suspect no one ever
> * *bothered to "fix" it. *You might actually see a performance
> * *improvement if you change it, but you might also find
> * *that you need a way to maintain upward compatability with
> * *at least reading archived data.- Hide quoted text -
>
> - Show quoted text -

Guys guys... why speculate and guess?
Jan wrote INDEXED files. Ther eare no alllignment bytes for indexed
files.
And more often then not indexed file records have date or key
compression in which case RMS will have to have a record length word
no matter what. So the overhead is zero.
For fixed length record, with no compression there is the 2 byte
overhead... but that only makes a difference if the you can store
fewer records in a bucket... Given a particular bucket size that's a
matter of math, not speculation.

IN any case this will be totally minor compared to the typical Indexed
file usage errors sutch as lack of compression or inadequet bucket
sizes.

Cheers,
Hein.

Hein RMS van den Heuvel wrote:
> On Nov 7, 2:02 pm, koeh...@eisner.nospam.encompasserve.org (Bob
> Koehler) wrote:
>> In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
>>> Hi.
>>> While analyzing some old indexed RMS datafiles
>>> that I *know* always are used with fixed size
>>> records (from COBOL apps), I've noticed that
>>> they are created with :
>>> RECORD
>>> CARRIAGE_CONTROL carriage_return
>>> FORMAT variable
>>> SIZE 280
>>> Question is, why not use "fixed" when all records
>>> are fixed size anyway ? My best guess is that it is
>>> like this just becuse "variable" is the default, and
>>> noone has ever thought about changing it to "fixed"...
>>> Is there any drawback having the files beeing set to
>>> variable record format when one is always using fixed
>>> sized records anyway ?
>> There's a tiny overhead for entering the record length
>> at the begining of each record. I suspect no one ever
>> bothered to "fix" it. You might actually see a performance
>> improvement if you change it, but you might also find
>> that you need a way to maintain upward compatability with
>> at least reading archived data.- Hide quoted text -
>>
>> - Show quoted text -
>
> Guys guys... why speculate and guess?
> Jan wrote INDEXED files. Ther eare no alllignment bytes for indexed
> files.
> And more often then not indexed file records have date or key
> compression in which case RMS will have to have a record length word
> no matter what. So the overhead is zero.
> For fixed length record, with no compression there is the 2 byte
> overhead... but that only makes a difference if the you can store
> fewer records in a bucket... Given a particular bucket size that's a
> matter of math, not speculation.
>
> IN any case this will be totally minor compared to the typical Indexed
> file usage errors sutch as lack of compression or inadequet bucket
> sizes.
>
> Cheers,
> Hein.

OK, thanks all.

For the time beeing I concider this as an non-issue.
I guess the default rec-fmt "variable" wasn't changed when
the files was created from the beginning (sometimes
mid-80's I guess).

I'm now creating "field", "record", "RMS-database" and
"database" definitions in CDD to be used by the Rdb
Gateway for RMS. I've never used CDD before. Fun ! :-)

Jan-Erik.

The best thing I ever found to work across both RMS files and
relational databases was Cognos PowerHouse.


On Nov 6, 5:18*pm, Jan-Erik Söderholm
wrote:
> Hi.
> While analyzing some old indexed RMS datafiles
> that I *know* always are used with fixed size
> records (from COBOL apps), I've noticed that
> they are created with :
>
> RECORD
> * * * *CARRIAGE_CONTROL * * carriage_return
> * * * *FORMAT * * * * * * * variable
> * * * *SIZE * * * * * * * * 280
>
> Question is, why not use "fixed" when all records
> are fixed size anyway ? My best guess is that it is
> like this just becuse "variable" is the default, and
> noone has ever thought about changing it to "fixed"...
>
> Is there any drawback having the files beeing set to
> variable record format when one is always using fixed
> sized records anyway ?
>
> (Apart from the one I do know about. "Rdb Transparent
> Gateway to RMS" has some restrictions on variable
> records formated indexed RMS files, but as I read it,
> it is no issue if the records are all the same size
> anyway...)
>
> B.t.w, this is part of a project to setup DBI and
> the "Rdb Transparent Gateway to RMS" to be able to
> run SQL queries against the RMS files and also run
> joins between the RMS files and between the RMS files
> and the Rdb database. It all looks just fine right now.
> I'm currently entering field, record and database
> definitions into CDD to get some metadata for the
> RMS files (about 20 files).
>
> Jan-Erik.

Could/can it join RMS and Rdb in the same
SQL SELECT statement ?

yyyc186 wrote:
> The best thing I ever found to work across both RMS files and
> relational databases was Cognos PowerHouse.
>
>
> On Nov 6, 5:18 pm, Jan-Erik Söderholm
> wrote:
>> Hi.
>> While analyzing some old indexed RMS datafiles
>> that I *know* always are used with fixed size
>> records (from COBOL apps), I've noticed that
>> they are created with :
>>
>> RECORD
>> CARRIAGE_CONTROL carriage_return
>> FORMAT variable
>> SIZE 280
>>
>> Question is, why not use "fixed" when all records
>> are fixed size anyway ? My best guess is that it is
>> like this just becuse "variable" is the default, and
>> noone has ever thought about changing it to "fixed"...
>>
>> Is there any drawback having the files beeing set to
>> variable record format when one is always using fixed
>> sized records anyway ?
>>
>> (Apart from the one I do know about. "Rdb Transparent
>> Gateway to RMS" has some restrictions on variable
>> records formated indexed RMS files, but as I read it,
>> it is no issue if the records are all the same size
>> anyway...)
>>
>> B.t.w, this is part of a project to setup DBI and
>> the "Rdb Transparent Gateway to RMS" to be able to
>> run SQL queries against the RMS files and also run
>> joins between the RMS files and between the RMS files
>> and the Rdb database. It all looks just fine right now.
>> I'm currently entering field, record and database
>> definitions into CDD to get some metadata for the
>> RMS files (about 20 files).
>>
>> Jan-Erik.
>

On Nov 8, 10:58*am, Jan-Erik Söderholm
wrote:
> Could/can it join RMS and Rdb in the same
> SQL SELECT statement ?
>

You wouldn't use SQL, you would be using the Quiz reporting module or
the Quick entry screens or the QTP bulk transaction module.

I have personally written reports with it which pulled data from RDB,
Oracle, and RMS.

The product used to be really cheap. I haven't priced it since IBM
took it over. PowerHouse is simply one of those tools every shop
should have laying around.

yyyc186 wrote:
> On Nov 8, 10:58 am, Jan-Erik Söderholm
> wrote:
>> Could/can it join RMS and Rdb in the same
>> SQL SELECT statement ?
>>
>
> You wouldn't use SQL, you would be using the Quiz reporting module or
> the Quick entry screens or the QTP bulk transaction module.

OK, so it sounds as the join is done in the PowerHouse
application, not in the database utself (such as in Rdb
Database Integrator, wich can join from Rdb and any
Transparent Gateway) which I belive could get slihtly
better performance.

>
> I have personally written reports with it which pulled data from RDB,
> Oracle, and RMS.
>
> The product used to be really cheap. I haven't priced it since IBM
> took it over. PowerHouse is simply one of those tools every shop
> should have laying around.

Well, I'm quite comfortable with the price of
the DBI-kit from Oracle also... :-) :-)

On Nov 8, 7:40*pm, Jan-Erik Söderholm
wrote:
>
> OK, so it sounds as the join is done in the PowerHouse
> application, not in the database utself (such as in Rdb
> Database Integrator, wich can join from Rdb and any
> Transparent Gateway) which I belive could get slihtly
> better performance.
>
>

Only one problem, the "join" isn't done inside of RDB like you think.
A result set is handed back to RDB from the Integrator.

Use what you want, I don't care. I pointed out the most robust tool
I've found in my 20 years on this platform. If you wish to continue
playing with a product that was so broken it was taken out and shot,
by all means, carry on.

Roland