Hi

I would like, in a low level subroutine, to EXECUTE a SELECT statement
without interfering in any way with any select lists that might be
active belonging to a higher level calling program.

How do I find out whether there is a select list currently active?

How do I find out which list number it is?

How can I temporarily suspend the active list?
I am thinking along the lines of saving the list, doing what I have to
do and getting the saved list back again afterwards - but in order to
do that I have to have answers to the preceding questions so that I can
reactivate the right list number.

I'm working with UniData.

TIA,
Mike.

I do not know if it works with Unidata, it works with D3 and have
worked with previous picks:


open "file" to vffile
open "file_1" to vffile_1
*----------------------------------------*
* with select *
*----------------------------------------*
select vffile to lstfile
eof=0
loop
readnext var from lstfile else eof=1
until eof=1 do
eof_1=0
select vffile_1 to lstfile_1
loop
readnext var_1 from lstfile_1 else eof_1=1
until eof_1=1 do


repeat
repeat
*-------------------------------------------------*


*------------------------------------------------*
* with execute *
*------------------------------------------------*
*the same but:
execute "select........."
select vffile to lst_file


You can have many lists active


Hope this help

joseba real de asua

You have to be very careful with that approach, unless RD have fixed the
bug with READNEXT ... FROM.
I ran into this, when a program came up with weird results and error
messages using this technique.
If the nested select isn't successful and doesn't return an active
select list, the following READNEXT will use the previous select list,
in your program 1stfile.


jra wrote:

I use the select xxx to yyy; readnext id from yyy frequently with no
problems. If you execute a select, you should use system(11) to test for
success before assigning the list to an internal variable with select
xxx to yyy". Sometimes you can cheat and just "select to yyy" if you
have an external list active; perhaps that could lead to the problem
Mecki describes?

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006


Mecki wrote:

Do you mean you want to EXECUTE "S{S}ELECT ...." ? If so, don't see the
problem, since you can return the list to any variable via "RTNLIST var" and
that will not interfere, by definition, with any other extant lists. I
think Unidata probably has the SELECT file_variable TO variable syntax,
which then is the same solution as for the external list.

Is the issue more complicated? Why do you need to know what lists are
active, or suspend them?

Chandru Murthi

<michael (AT) preece (DOT) net> wrote

Hi

See also:
http://mvdevcentral.com/projects/listmaker/

Best regards.

murthi wrote:

Yes.

If there was a select-list active then wouldn't the S{S}ELECT I execute
attempt to return a subset of the active list?

If the calling program/subroutine had just executed a SELECT (without
specifying a list number or variable) so that list0 is currently
active, and my subroutine then executes another select on a totally
different file/directory, then wouldn't the latest select use the
already active list? Like:

..
..
..
EXECUTE "SELECT FILE1"
CALL MYSUB
..
..
..

SUBROUTINE MYSUB
..
..
..
EXECUTE "SELECT DIR1 ":SELECTCRITERIA:" ":SORTORDER:" TO ":LISTNO
* or ...RTNLIST LISTNO
LOOP
READNEXT KEY FROM LISTNO ELSE EXIT
..
..
..
REPEAT
..
..
..
RETURN

Wouldn't LISTNO always be a subset of the keys from FILE1?

The thing to bear in mind here is that I don't want to change any of
the existing program code - other than to plug in a call to my
subroutine as and when needed.

I'm working on UniData which differs from D3 in that it caters for
active list numbers 0-9. What that seems to mean is that, outside of
UniBasic, you can have up to 10 lists "active" at a time. That's a
little misleading though, because only select-list 0 is *really* active
as far as the system monitor is concerned. You can "SELECT..TO 1". It
will say "x records selected to list 1", but there will be no active
list as far as the system monitor is concerned. If you now "LIST
filename" it will not use the x records in list 1 - it will use
whatever was active as list 0 or, if list 0 wasn't active, list the
whole file. You can "SAVE.LIST listname FROM 1" though, which will use
the x records in list 1. It seems that the only other way, apart from
SAVE.LIST, to use lists 1-9 is in UniBasic READNEXT statements. In
UniBasic you can go ahead and "LOOP...READNEXT KEY FROM n". There is
also the ability, in UniBasic, to use list variables - as you suggest -
so you can READNEXT FROM a list number or a list variable. The thing is
though that that (the ability to specify a list variable as opposed to
a number) only seems to apply to UniBasic (internal) SELECTs - and not
EXECUTEd selects. With EXECUTEd selects you can have ...TO {listno} as
part of the EXECUTEd SELECT statement and then READNEXT FROM {listno},
or you can have ...RTNLIST {listno} as part of the UniBasic EXECUTE
statement. In both cases you have to specify a numeric list number in
the range 0-9. I therefore need to know if any or all of them are
already "active".

Fwiw - what I'm trying to do is develop a generic OS file handling
subroutine; something similar to one I wrote when on a contract a few
years back (back then I just had to call a pre-existing subroutine (or
function) to get a free list number). Two of its capabilities will be
to open the next new OS file in a directory (given some rules on how
the file name is to be constructed) and/or to open the next existing OS
file in a directory. The OS files in a directory are equivalent to
UniData records in a file. I can therefore SSELECT them WITH PREFIX
LIKE whatever WITH DATE LIKE whatever BY SEQNO to get a select-list,
and then use the resulting list to find out which filename to
OPENSEQ/OSOPEN.

Mike.

I you must guarantee the integrity of a pre-existing, active select
list, then I suggest something like the following:

restore.list = 0
if system(11) then
svlist = ""
open "pointer-file" to pf else stop 201,"pointer-file"
loop
readnext id else exit
svlist<-1> = id
repeat
write svlist on pf,system(22)
restore.list = 1
end
.... whatever ...
if restore.list then
execute "get-list ":system(22)
end
return

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006


michael (AT) preece (DOT) net wrote:

Thanks for that Scott. I was thinking along these very lines myself -
and was then over-complicating things again (having to reaquaint myself
with UniData after a few years working with D3). That takes care of the
extant list (0). Now that list 0 is free (temporarily) I don't have to
worry about lists 1-9 - they don't enter into it.

Cheers
Mike.

Yes, you're right, I was thinking in terms of *always* using RTNLIST which
would solve the problem, but of course require you to check *all* calling
programs. I never leave the RTNLIST out, so select list0 is never active.
Scott's solution is probably the only one, it could be simplified as you
don't have to write and read the list to a file:

restore.list = 0
svlist = ""
if system(11) then
loop
readnext id else exit
svlist<-1> = id
repeat
restore.list=1
end
.... whatever ...
if svlist # '' then select svlist

You also want to avoid using select list0 in [whatever], or make sure you
exhaust it, or the select svlist will not work.

Chandru Murthi
<michael (AT) preece (DOT) net> wrote