Unidata Select-Lists

Daniel B. Klein

unread,

Aug 3, 1997, 3:00:00 AM8/3/97

to

To date, I have answered numerous questions for this newsgroup; now I have
one:

The company I work for is migrating from Sequoia to Unidata and although
there are some uncomfortable differences, they are all simple training
issues...except for one really annoying difference: Select-lists are broken
up into 32k segments. Now this is fine if all you are doing is, SAVE-LIST,
GET-LIST, etc. But what if you want to open the directory where the
select-lists are stored and read a particular item? We have several
programs that do the following:

OPEN "POINTER-FILE" TO POINTER.FILE ELSE STOP 201,"POINTER-FILE"
INPUT SELECTLIST.ID
READ SELECTLIST FROM POINTER.FILE, SELECTLIST.ID ELSE ...
ITEM.CNT = DCOUNT(SELECTLIST, @AM)
LOOP
READNEXT ID FROM SELECTLIST ELSE ...
REPEAT

I know how you would like to answer this:

EXECUTE "GET-LIST ":SELECTLIST.ID RTNLIST SELECTLIST

...and this would be fine, except that when you do an EXECUTE, it clears
all input from a DATA statement, and we have several processes which passes
input via a DATA statement (including the select-list name) to the program
which uses it.

I suppose I could modify these programs to look for the next segment when
the first one is exhausted, but what if I need to know the total number of
items in the list at the onset.

So you see, the questions are: Why does Unidata do this? Is this
"tunable"? Is there a substite command or will have have to develop a
routine to combine all of the segments? Or what???

Thanks for your consideration.

Daniel B. Klein
dkl...@cyberhighway.net

Ian McGowan

unread,

Aug 4, 1997, 3:00:00 AM8/4/97

to

Daniel B. Klein (dkl...@cyberhighway.net) wrote:
: To date, I have answered numerous questions for this newsgroup; now I have
: one:

ok, you've established credentials, without which no sane person would
offer any help. (though i was momentarily distracted by the 32
postings to rec.binaries.pictures.erotica by daniel V. klein :-)

<cut>
: I know how you would like to answer this:

actually, i would pontificate about the dangers of assuming that
underlying data structures will remain the same, and then go on to
expound about how, if you must do this, it's better to encapsulate
it into a subroutine. so easy to be smart, after the fact.

: So you see, the questions are: Why does Unidata do this? Is this

: "tunable"? Is there a substite command or will have have to develop a
: routine to combine all of the segments? Or what???

because they can? because it's more efficient? because there was
a translation problem that day and the chinese programmers were sick
of writing code at 0.00001 cents a line? why do they choose to hash
data files in the first place? - it's so inconvenient...

to count how many items are in a saved list (though you'll have to do
an execute) !wc -L SAVEDLISTS/<listname>* CAPTURING LCOUNT
to munge them all into one big list !cat SAVEDLISTS/<listname>* > BigList
if your lists are fairly static (say daily) you can do this at night and
not have to mess with any of your code. though if it's only several, i
would bite the bullet and change them (using a subroutine of course, so
that when unidata-8.0 changes the way lists are stored because of limits
in NT6.0, you don't have to go through this again).

: Thanks for your consideration.
: Daniel B. Klein
: dkl...@cyberhighway.net

if you actually get helpful information, would you mind posting a
summary?
--
work <- imcg...@trinitycapital.com Practice random lane changes and
play <- i...@netcom.com commit senseless bursts of acceleration

Jim Idle

unread,

Aug 5, 1997, 3:00:00 AM8/5/97

to

Daniel B. Klein wrote in article <01bca01b$3cfce8a0$08e682d0@dklein>...

>The company I work for is migrating from Sequoia to Unidata and although
>there are some uncomfortable differences, they are all simple training
>issues...except for one really annoying difference: Select-lists are broken
>up into 32k segments. Now this is fine if all you are doing is, SAVE-LIST,
>GET-LIST, etc. But what if you want to open the directory where the
>select-lists are stored and read a particular item?

You should not do this really as it relies on the format of the data to
remain the same for ever.
Unidata split lists up (this is an educated guess here), because it is much
quicker when
you are dealing with very large select lists.

Many variants of Pick/Picklike stuff these days have one or both of the
BASIC statements:

READLIST...
GETLIST...

at least one of which originated at McDD (could be wrong here). Anyway, if
Unidata supports either of these statements, it will do what you were trying
to achieve by reading directly from POINTER-FILE. If it does not, you would
probably be better not reading lists directly I would think.

Hope this is of some use to you (although "don't do this", is never a nice
answer to receive of course!).

Jim Idle
ji...@jac.com www.jbase.com

PS: This post especially for Joseba ;-)

David Zigray

unread,

Aug 7, 1997, 3:00:00 AM8/7/97

to

Ian McGowan wrote:
>
> Daniel B. Klein (dkl...@cyberhighway.net) wrote:
> : To date, I have answered numerous questions for this newsgroup; now I have
> : one:
>

> ok, you've established credentials...

> without which no sane person would
> offer any help.

>(though i was momentarily distracted by the 32
> postings to rec.binaries.pictures.erotica by daniel V. klein :-)

c'mon... whose establishing creditials???

>
> <cut>
> : I know how you would like to answer this:
>
> actually, i would pontificate about the dangers of assuming that
> underlying data structures will remain the same, and then go on to
> expound about how, if you must do this, it's better to encapsulate
> it into a subroutine. so easy to be smart, after the fact.
>
> : So you see, the questions are: Why does Unidata do this? Is this
> : "tunable"? Is there a substite command or will have have to develop a
> : routine to combine all of the segments? Or what???
>
> because they can? because it's more efficient? because there was
> a translation problem that day and the chinese programmers were sick
> of writing code at 0.00001 cents a line?

because it's hard to do it right!

[snip]

my 2cents

Jackie Burhans

unread,

Aug 7, 1997, 3:00:00 AM8/7/97

to

Jim Idle (ji...@jac.com) wrote:

: Daniel B. Klein wrote in article <01bca01b$3cfce8a0$08e682d0@dklein>...

: >The company I work for is migrating from Sequoia to Unidata and although
: >there are some uncomfortable differences, they are all simple training
: >issues...except for one really annoying difference: Select-lists are broken
: >up into 32k segments. Now this is fine if all you are doing is, SAVE-LIST,
: >GET-LIST, etc. But what if you want to open the directory where the
: >select-lists are stored and read a particular item?

: You should not do this really as it relies on the format of the data to
: remain the same for ever.
: Unidata split lists up (this is an educated guess here), because it is much
: quicker when
: you are dealing with very large select lists.

I suspect the reason it splits it up is that historically this was the
first way they implemented it and had something to do with how they
allocated memory. Its probably not required now but stays the way it is
for historical and compatibility reasons. Not that I'm doing anything but
guessing. I really could ask the Engineers if you *really* want to know
why. And to answer the last part of Daniel's question--no it isn't tunable.

: Many variants of Pick/Picklike stuff these days have one or both of the
: BASIC statements:

: READLIST...
: GETLIST...

: at least one of which originated at McDD (could be wrong here). Anyway, if
: Unidata supports either of these statements, it will do what you were trying
: to achieve by reading directly from POINTER-FILE. If it does not, you would
: probably be better not reading lists directly I would think.

UniData supports both of those statements. And they are a good way
to accomplish what Daniel is trying to do. Check the on-line doc for
the syntax but this should get the job done.

: Hope this is of some use to you (although "don't do this", is never a nice

: answer to receive of course!).

: Jim Idle
: ji...@jac.com www.jbase.com

: PS: This post especially for Joseba ;-)

Thanks for your input Jim.

Jackie Burhans
Unidata, Inc.

Michael Coley

unread,

Aug 15, 1997, 3:00:00 AM8/15/97

to

Ian,

On Mon, 4 Aug 1997 18:29:51 GMT, i...@netcom.com (Ian McGowan) wrote:

> to count how many items are in a saved list (though you'll have to do
> an execute) !wc -L SAVEDLISTS/<listname>* CAPTURING LCOUNT
> to munge them all into one big list !cat SAVEDLISTS/<listname>* > BigList
> if your lists are fairly static (say daily) you can do this at night and
> not have to mess with any of your code. though if it's only several, i
> would bite the bullet and change them (using a subroutine of course, so
> that when unidata-8.0 changes the way lists are stored because of limits
> in NT6.0, you don't have to go through this again).

Be careful doing that. What if I have a list saved as INV and a list
saved as INVOICES. If I use that method to get a count of the items
in INV, I get the count of all items in both lists.

You would want to do something more like:

!wc -l SAVEDLISTS/<listname>[0-9][0-9][0-9]

(At least with the current version of Unidata...)

It's probably better to do something like:

EXECUTE "GET-LIST <listname>"
LCOUNT = SYSTEM(11)
CLEARSELECT

- Michael Coley
http://www.i1.net/~mcoley/
mailto:mco...@i1.net

Rich Conley

unread,

Aug 18, 1997, 3:00:00 AM8/18/97

to

<HTML>
Daniel,

In uniVerse we have a couple of commands which I believe are available
in Unidata (it has been a while so I don't remember) as well as other platforms.

If you want to preserve a select list you can use an EXECUTE (allows
"GET-LIST", "SSELECT", etc.) then the statement SELECT TO variable.listname. 
This saves a list from which you can READNEXT id FROM variable.listname. 
Also there should be a SYSTEM function (SYSTEM(11) in uniVerse and AP/D3)
which returns the number of items in select list 0(zero).

I believe (haven't tried it) that these list variables can be passed
to other programs using a COMMON or as arguments in a subroutine call.

If your version of Unidata supports this and you would like some examples
how it works I will be glad to help.

One example:

...
    INPUT SALES.LIST.NAME:
    *
    EXECUTE 'SSELECT CUSTOMERS'
    CUST.ITEMS = SYSTEM(11)
    SELECT TO CUSTOMER.LIST
    *
    CUST.DONE = 0
    LOOP
       READNEXT CUST.ID FROM CUSTOMER.LIST
ELSE CUST.DONE = 1
    UNTIL CUST.DONE DO
       EXECUTE 'GET-LIST ':SALES.LIST.NAME
       EXECUTE 'SSELECT SALES WITH CUSTOMER
= "':CUST.ID:'"'
       SALES.ITEMS = SYSTEM(11)
       SELECT TO SALES.LIST
       SALES.DONE = 0
       LOOP
           READNEXT SALES.ID
ELSE SALES.DONE = 1
       UNTIL SALES.DONE DO
            READ SALES.REC
FROM F.SALES, SALES.ID THEN ...
             
(process this)
            END ELSE
              
(error statements - if any)
            END
        REPEAT
    REPEAT    ;*  get next cust id
 ...

Rich
 RKC Consulting
 rk...@computer.net

Daniel B. Klein wrote:
<BLOCKQUOTE TYPE=CITE>To date, I have answered numerous questions for this
newsgroup; now I have
 one:

The company I work for is migrating from Sequoia to Unidata and although
 there are some uncomfortable differences, they are all simple training
 issues...except for one really annoying difference: Select-lists are
broken
 up into 32k segments.  Now this is fine if all you are doing is,
SAVE-LIST,
 GET-LIST, etc.  But what if you want to open the directory where
the
 select-lists are stored and read a particular item?  We have several
 programs that do the following:

OPEN "POINTER-FILE" TO POINTER.FILE ELSE STOP 201,"POINTER-FILE"
 INPUT SELECTLIST.ID
 READ SELECTLIST FROM POINTER.FILE, SELECTLIST.ID ELSE ...
 ITEM.CNT = DCOUNT(SELECTLIST, @AM)
 LOOP
     READNEXT ID FROM SELECTLIST ELSE ...
 REPEAT

I know how you would like to answer this:

EXECUTE "GET-LIST ":SELECTLIST.ID RTNLIST SELECTLIST

...and this would be fine, except that when you do an EXECUTE, it clears
 all input from a DATA statement, and we have several processes which
passes
 input via a DATA statement (including the select-list name) to the
program
 which uses it.

I suppose I could modify these programs to look for the next segment
when
 the first one is exhausted, but what if I need to know the total number
of
 items in the list at the onset.

So you see, the questions are: Why does Unidata do this?  Is this
 "tunable"?  Is there a substite command or will have have to develop
a
 routine to combine all of the segments?  Or what???

Thanks for your consideration.

Daniel B. Klein
 dkl...@cyberhighway.net</BLOCKQUOTE>
  </HTML>

Jackie Burhans

unread,

Aug 20, 1997, 3:00:00 AM8/20/97

to

Michael Coley (mco...@i1.net) wrote:

: It's probably better to do something like:

: EXECUTE "GET-LIST <listname>"
: LCOUNT = SYSTEM(11)
: CLEARSELECT

Another option to try is to substitute SYSTEM(11) with @SYSTEM.RETURN.CODE

I don't say it will work any better or worse than System(11) but coming
from a Prime background that would be my first shot at it.

Jackie Burhans