TBSORT and TBSARG/TBSCAN question.
Hawley Scott
I'm writing a toy for the users here that will allow them to selectively
display rows from it using the TBSARG/TBSCAN facilities. We have ISPF
3.5 running (currently, OS/390 2.6 and all of the newest goodies are still
on
our test lpar). I initially had some trouble with TBSARG until I RTFM and
saw
the following paragraph jumping out at me.
ISPF Dialog Management Guide and Reference
Version 3 Release 5 for MVS
Document Number SC34-4266-02
2.2.34 TBSARG - Define a Search Argument
"Only extension variables can be included in the search argument. They
are
included by specifying their names in the name-list parameter. The
values
of these variables become part of the search argument. A null value in
an
extension variable is a valid search argument."
I changed my TBADD to use the SAVE(...) with what I would normally put in
the
TBCREATE NAMES(...). That worked out great until I went to add a little more
functionality to my widget with some sorting capability. I went back to the
book
(eventually) and found this in the TBSORT section
2.2.38.3 Description of Command Procedure and Call Parameters
" Each sort field-name must be either a KEY or NAME field. The first
(left most) field-name is the primary key (most significant) and the
rows are then collated based on the values of the field-names."
I guess IBM never thought these services would be used on the same table.
or am I just missing something obvious. My dialog writing is a little
rusty...
My question is has anyone found a way around this? I've just started looking
around and thought somebody must have invented this wheel already.
Jim Harrison
arguments by itself. TBSARG is really not needed at all (AFAIKT).
Frank Clarke
>Has anyone else tried to use TBSORT and TBSARG/TBSCAN on a table?
Sure. The key concept to keep in mind is to start with a 'clean'
environment. This is NOT obvious from reading the manual, but
--any non-null variable participates in the setting of the
argument--
Start by saving any values you will need for the TBSARG. Then do the
TBVCLEAR to wipe those variables clean. Then TBSARG.
The syntax of TBSARG allows you to specify (a) extension variables,
and/or (b) a cond-list (V1,EQ,V2,LT,V3,NG etc.). Unless you have
real honest-to-goodness extension variables, only use the cond-list.
Frank Clarke
Tampa Area REXX Programmers' Alliance (TARPA)
Member of the REXX Language Assn
Join us at http://www.rexxla.org
(remove currency symbol when replying)
Hawley Scott
have the whole picture - I'm working on that too. In the meantime I have
to answer a lot of the same 'how much space do I have in my SMS pool'
or similar questions. I took the DCOLLECT VOLINFO output and loaded
it into a table specifically so I could let them enter the SG name in a mask
field at the top of a column and by using TBSARG combined with the MODEL
ROWS(SCAN) in the panel they would see a list of volumes in that SG less
all of the other 'stuff' that they don't want. I liked this approach since I
could
use a kind of boolean filter logic like "not MVS* volumes and free cyls
>500"
It's working great but when I was adding a sort option (a la TBSORT) I came
across this and thought it was strange to have these restrictions.
Hawley Scott
Harrison,
and Lionel B Dyck for getting my thoughts on the problem in order. I
was
doing a TBVCLEAR after I built the arguments and before saving them.
I sort of jumped out at me all at once. It still seems to me that
the manual
is a bit misleading - at least the TBSARG portion of it. Now on to
the help
panels...
Mickey
>
> On 17 Feb 1999 11:45:36 -0800, Haw...@TCE.COM (Hawley Scott) wrote:
>
> >Has anyone else tried to use TBSORT and TBSARG/TBSCAN on a table?
>
> Sure. The key concept to keep in mind is to start with a 'clean'
> environment. This is NOT obvious from reading the manual, but
>
> --any non-null variable participates in the setting of the
> argument--
>
> Start by saving any values you will need for the TBSARG. Then do the
> TBVCLEAR to wipe those variables clean. Then TBSARG.
True, but there is another way, which I use on tables with few elements.
Instead of saving off my search var, and then issuing the tbvclear, and
then restoring, I simply set the vars I wont be using to a null in the
rexx. As rexx and ISPF share the function pool, this works just as well.
mickey
Frank Clarke
>Frank Clarke wrote:
>>
>> Start by saving any values you will need for the TBSARG. Then do the
>> TBVCLEAR to wipe those variables clean. Then TBSARG.
>
>True, but there is another way, which I use on tables with few elements.
>Instead of saving off my search var, and then issuing the tbvclear, and
>then restoring, I simply set the vars I wont be using to a null in the
>rexx. As rexx and ISPF share the function pool, this works just as well.
...until someone redefines the table with another column. Then you're
back to "How come I only get two rows? I should be getting 124." The
only antidote to this (absent TBVCLEAR) is to TBQUERY for the KEYS and
NAMES, eliminate the ones you want to keep, null all the rest.
TBVCLEAR means never having to say you need a re-write.