For Missing Question

[Deskin, Bob]

Since Chris mentioned my name, I feel I should respond. I wish I had been in
the position I'm in 20 years ago. I could have insisted on higher limits for
things like the occurrence (255) and file open (31) limits in QUICK.
Unfortunately I was not. We have had requests to increase them for about 15
years (not the first 5 or so of QUICK's life because customers hadn't gotten
to the limits yet).

These limits are actually table limits and are referenced throughout QUICK.
One would think that the actual limit is a variable that can be referenced
while the actual limit only occurs in one place. Unfortunately this is not
the case. In fact, these numbers often occur in other tables where a
specific number of bits are allocated for them. If we increase the limits,
we have to increase the number of bits allocated to them in our tables. So
there's a ripple effect. As well, we often offset into tables since it was
efficient to do things that way so the ripple effect becomes greater. Keep
in mind that we were writing for an HP MPE/V machine with a data stack of
32K words. So we had to be as efficient in our use of space as possible.

If anyone wonders where the 255 came from, it's the limit for the number of
times an item can repeat in the TurboIMAGE database on MPE. We did not have
DETAIL files in those days, just SECONDARY files, and 255 seemed quite
reasonable then. Hindsight is often 20-20.

So it's not that we don't want to change, it's that the time and resources
we have don't permit us the luxury of these changes.

Bob Deskin              
PowerHouse Web Product Manager and Senior Product Advisor
Application Development Tools, Cognos Inc.
bob.deskin@cognos.com (613) 738-1338 ext 7268 FAX: (613) 727-1178
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA


-----Original Message-----
From: Chris Sharman [mailto:Chris.Sharman@ccagroup.co.uk]
Sent: November 9, 2000 4:13 AM
To: pickering@myself.com
Cc: Chris.Sharman@ccagroup.co.uk; powerh-l@sphere.swau.edu
Subject: RE: For Missing Question



>I have a file that I want to display in a cluster where the order is 
>different than any of the indexes in the file. I have another file though 
>that I could use to "drive" this primary file so they would be retrieved in

>the order I want. In this case I want to retrieve them in customer-num 
>order, which is not an index on WPS-PO-MST but is on GLS-PO-DRIVER.
>
>The driver file (GLS-PO-DRIVER) has multiple records for the same 
>VENDOR-NUM. After entering the VENDOR-NUM, then I do WHILE RETRIEVING for 
>all of these records and retrieve the primary record (WPS-PO-MST) and 
>display them.
>
>The problem I'm having is that it will only display up to the number of 
>records in the "cache" and no further. In the example below I've purposely 
>set the cache to a low number for testing purposes, but it works the same 
>way at 255. After displaying the last record in the cache, it starts over 
>with the first record.

If I understand correctly, that there's multiple gls-po-driver records for a
given vendor-num, and multiple wps-po-mst records per gls-po-driver record,
then I think you're kind of stuck.

The 'correct' solution, as you doubtless know, would be a repeating primary
gls-po-driver record, with a subscreen with one gls-po-driver master record
& a
repeating primary wps-po-mst record.

If it's an ordering problem, Powerhouse has an 'orderby' clause for use with
some databases on some platforms, I believe, which would enable you to use
wps-po-mst directly as a repeating primary.

If neither of those are suitable, then I think you'll have to store some
unique
id of the last record during postfind. Then when next is called, you skip up
to
& including that record (probably using 'file wps-po-mst designer open 1
alias
skp'). A nasty fudge, and probably slow if you get up to thousands of
records.

Alternatively, lobby Cognos to remove the 255 limit (hi, Bob). I suspect
that
would expose a raft of memory problems though, and won't happen anytime
soon.

Regards
Chris
_______________________________________________________________________
Chris.Sharman@CCAgroup.co.uk		http://www.ccagroup.co.uk/
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.