RE: User Space or Data Queue or PF or IFS

Anton Wrote:
John, the whole thing of writing the "result set" that you receive
from the SQL server to *disk* is necessary? Isn't that a piece of
middleware that should pass that on to a processing program? Wouldn't
be allocating a decent amount of memory and reusing that as a sort of
communications buffer better? Or shall that be a sort of cache for
faster answers on repeating calls demanding the same data?

Anton:
Yes, it is true that writing the entire result set is excessive.
The problem is that when it comes off of the socket, there
is no way to tell if you are in the middle of a dataset record, nor
can you tell that you are at the end of the result until there is
no more data to return.
I can do it mid-stream, but it's really really ugly.
Just a fallacy of MSSQL.
John

-----Original Message-----
From: Anton Gombkötö [mailto:gombkoetoe@xxxxxxxxxx]
Sent: Monday, November 03, 2003 2:57 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: User Space or Data Queue or PF or IFS


> Haven't been following this thread that much, but the recent posts
> have caught my attention.  Sorry if this has already been stated.

> There is something that I just heard about called a User Index that
> supposedly holds up to a Terabyte of data.  The IBM person said it
> operated similar to a User space except you could index the entries.
> You might want to check that out even though you would be in some
> serious do-do if you ever got something that big;-)

Oh yes, you are right, Aaron!

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

and scroll down to "Index size option" (at about 75% of the vertical
scrollbar). A value of "1" means a maximum size of 1 terabyte. A value
of "0" means a maximum size of 4 gigabytes.

And for John's compatibility problems:
prior to V2R2M0: maximum size 1 gigabyte,  max. key length   120 bytes
V2R2M0 - V5R1M0: maximum size 4 gigabytes, max. key length 2,000 bytes
V5R2M0: 1 terabyte.

But the drawback is the entry length. That can only be 2,000 bytes.

A 32K chunk would make up 17 records, with unused 768 bytes in the
17th record.

To take advantage of the size of 4 gigabytes, we need 4,294,967,296
unique keys, 17 for every 32K chunk. That would be a 4 byte hex key,
the rest would be the "data". 1996 bytes * 16 records + 832 = 32,768
bytes.

I really don't know which approach is the more cumbersome, that one or
ending up with max. 256 user spaces. :-)

John, the whole thing of writing the "result set" that you receive
from the SQL server to *disk* is necessary? Isn't that a piece of
middleware that should pass that on to a processing program? Wouldn't
be allocating a decent amount of memory and reusing that as a sort of
communications buffer better? Or shall that be a sort of cache for
faster answers on repeating calls demanding the same data?

-- 
Mit freundlichen Grüssen / best regards

Anton Gombkötö
Organisation und Projektleitung

Avenum Technologie GmbH
Wien - Salzburg - Stuttgart
http://www.avenum.com



_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/03
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.535 / Virus Database: 330 - Release Date: 11/1/03