IBM Mainframe Forum

by **djbland** » Wed Jan 16, 2013 12:54 am

I have a very large ISPF table with multiple columns. There are multiple values in this particular column I'm dealing with. Lets say the column name is COLOR. I would like to be able to issue a command that will tell me if a value is present in the COLOR column. Example.... the COLOR column might have a value of "BLACK WHITE RED BLUE". I want to know if RED is in the value list. Currently in a REXX exec I am doing TBSKIP to move from row to row, while checking to see if the COLOR value contains RED. This is slow since the table is large. I can't use TBSCAN since RED would not match "BLACK WHITE RED BLUE"

I'm thinking there is a command that can do this because if I display the tables contents using a utility I can issue on the command line "F COLOR RED" and it will take me to the row that contains RED, even though the columns value is "BLACK WHITE RED BLUE"

Thanks in advance for any recommendations.

by **Pedro** » Wed Jan 16, 2013 4:39 am

I do not believe there is a programming interface for FIND in a table. I have always done it with TBSKIP as you describe. Though, I typically do not require the column name.

I wouldn't be surprised if the table utility had its own internal logic to implement the FIND. For performance, they might rely on traversing ISPF control blocks rather than using TBSCAN. We are not developers of ISPF, so the control block structures are not exposed to us.

by **wkdan** » Wed Jan 16, 2013 10:41 pm

May be instead of a single column COLOR, use multiple COLOR columns (e.g. COLOR1, COLOR2 etc.), then TBSCAN on each COLOR column.

by **Peter_Mann** » Fri Jan 18, 2013 12:20 am

I've always used TBSARG prior to a TBSCAN to search an ISPF table for an argument

Select all

ISPEXEC TBSARG TABLENAM ARGLIST(NAMELIST) NEXT +
NAMECOND(NAMEPAIR)

TABLENAM - NAME OF THE TABLE FOR WHICH AN ARGUMENT IS TO BE
ESTABLISHED.
NAMELIST - OPTIONAL, LIST OF EXTENSION VARIABLES, BY NAME, WHOSE
VALUES ARE TO BE USED AS PART OF THE SEARCH ARGUMENT.
CHOOSE ONE, OPTIONAL
NEXT - DEFAULT, SCAN AFTER CRP TO BOTTOM OF THE TABLE.
PREVIOUS - SCAN BEFORE CRP TOWARD TOP OF TABLE.
NAMEPAIR - A LIST OF NAMES AND CONDITIONS FOR DETERMINING THE
SEARCH ARGUMENT FOR SCANNING THE TABLE.
NAME: NAME OF KEY FIELD, NAME FIELD OR EXTENSION
VARIABLE
CONDITION: EQ, NE, LT, GE, GT, OR LE

EXAMPLE: ISPEXEC TBSARG TABLE ARGLIST(E1 E2 E3)

an example below

Select all

SET &TCC=&LASTCC
IF &TCC ¬= 0 THEN DO
ISPEXEC SETMSG MSG(EDIF014)
EXIT
ENDO
ISPEXEC TBTOP JCLUSER
SET &KUSER=&STR(&SYSUID)
ISPEXEC TBSARG JCLUSER
ISPEXEC TBSCAN JCLUSER
SET &SC=&LASTCC
ISPEXEC TBCLOSE JCLUSER

above code is a short example of a table scan of a userid to determine authority

by **Pedro** » Fri Jan 18, 2013 12:45 am

The limitation with TBSARG is that the wildcard has to be the last character. You cannot search for '*RED*'. It is frustrating to me as a user to see it on the screen and for the search not find it. For example, if I type 'F RED' in the command line, it should find it, but does not using TBSARG / TBSCAN.

From the ISPF Services manual:

A search argument of the form AAA* means that only the characters up to
the asterisk (*) are compared. This is called a generic search argument. A
generic search argument is specified by placing an asterisk in the last
nonblank position of the argument. Asterisks embedded in the argument are
treated as data. ...

by **Peter_Mann** » Fri Jan 18, 2013 12:53 am

Pedro wrote:The limitation with TBSARG is that the wildcard has to be the last character. You cannot search for '*RED*'. It is frustrating to me as a user to see it on the screen and for the search not find it. For example, if I type 'F RED' in the command line, it should find it, but does not using TBSARG / TBSCAN.

From the ISPF Services manual:
A search argument of the form AAA* means that only the characters up to
the asterisk (*) are compared. This is called a generic search argument. A
generic search argument is specified by placing an asterisk in the last
nonblank position of the argument. Asterisks embedded in the argument are
treated as data. ...

Really? been a long time since I've used these services, this does spark some old brain cells, but in my small table scan utility (example) It has always worked, the ID is in the table? YES, proceed, NO, EXIT.
must have been sheer luck that this worked

by **Peter_Mann** » Fri Jan 18, 2013 1:09 am

After revewing the doc I think my example will still work, a search using a wildcard may have limitations, but positioning a table after a scan or displaying only those rows that contain the desired contents can still be obtained, I have developed many ISPF diaplogs using TBSARG - TBSCAN and have had much success scaning a table, then displaying the contents of that row in a panel or using this row for file tailoring

here's the begining of the chapter on TBSARG

2.73 TBSARG--define a search argument

The TBSARG service establishes a search argument for scanning a table by using the TBSCAN or TBDISPL services. When TBSARG is used in conjunction with TBDISPL, the panel definition referred to by the TBDISPL request must contain a specification of ROWS(SCAN) on the )MODEL statement in the panel definition.

The direction of the scan, forward or backward, can be specified. The conditions that terminate the subsequent scan can also be specified.

The search argument is specified in dialog variables that correspond to columns in the table, including key variables. A value of null for one of the dialog variables means that the corresponding table variable is not to be examined during the search. However, the variable will be examined if the NOBSCAN parameter was specified when the variable was defined using the VDEFINE service.

Generally, TBSARG is used before TBSCAN or TBDISPL operations to establish search arguments for these operations. To set up a search argument, set table variables in the function pool to nulls by using TBVCLEAR. Next, set a value in each variable in the function pool that is to be part of the search argument. Then, issue TBSARG to establish this variables as the search argument to be used in subsequently requested TBSCAN or TBDISPL operations.

Use the NAMECOND list to establish search argument conditions. For any table variable that was given a value in the function pool, but is not specified in the NAMECOND list, the default is EQ.

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.

by **Peter_Mann** » Fri Jan 18, 2013 1:15 am

Here's an example of a ISPF dialog I developed back in 1994, crude, but this does show an example of providing a wildard in the TBSARG

Select all

PROC 0 DEBUG TABLE(TICKT) DS(PRODCNTL.ISP.TABLE) DS1(TEMPJ.TABLE)
IF &DEBUG = DEBUG THEN -
CONTROL PROMPT NOFLUSH MSG CONLIST SYMLIST LIST END(ENDO)
ELSE -
CONTROL PROMPT NOFLUSH NOMSG END(ENDO)
DEL &DS1
COPY '&DS' &DS1
ALLOC F(TEMPT) DA(&DS1) SHR REUSE
SET ZMSGNAME = ZERRMSG
SET PANEL = TICKE1
SET TS =
ISPEXEC TBOPEN &TABLE NOWRITE SHARE LIBRARY(TEMPT)
ISPEXEC TBSTATS &TABLE ROWCURR(TICKCURR) LIBRARY(TEMPT)
IF &TICKCURR = 00000000 -
THEN DO
ISPEXEC SETMSG MSG(TICK001)
ISPEXEC LOG MSG(TICK001)
ISPEXEC TBCLOSE &TABLE LIBRARY(TEMPT)
EXIT
ENDO
ELSE DO
ISPEXEC TBTOP &TABLE
SET &DATEN=&STR(04*)
ISPEXEC TBSARG &TABLE ARGLIST(DATEN) NAMECOND(GE)
ENDO
SET &CURP=&ZTDTOP
ISPEXEC TBSORT &TABLE FIELDS(DATEN)
TBD:ISPEXEC TBDISPL &TABLE PANEL(&PANEL)
IF &LASTCC > 4 THEN GOTO EXIT
IF &ZTDSELS = 0000 THEN DO
TS: -
SET TS =
ISPEXEC TBDISPL &TABLE
SET &TCC=&LASTCC
ENDO
IF &TS = S THEN DO
ISPEXEC CONTROL DISPLAY SAVE
ISPEXEC DISPLAY PANEL(TICKA02)
ISPEXEC CONTROL DISPLAY RESTORE
SET &TS =
GOTO TS
ENDO
IF &TCC > 0 THEN DO
GOTO EXIT
ENDO
GOTO TS
/* */
END
EXIT: -
ISPEXEC TBCLOSE &TABLE LIBRARY(TEMPT)
FREE DA(&DS1)
EXIT

by **Pedro** » Fri Jan 18, 2013 4:00 am

but this does show an example of providing a wildcard in the TBSARG

You are missing a key point. There is no way to search for text imbedded in the middle of the field which is the emphasis of this discussion. Your example only searches for text starting with the first character of the field so it is not particularly useful.

by **Peter_Mann** » Sat Jan 19, 2013 2:04 am

I didn't interprite the OP's question that a wilcard seach or a seach in the middle of a field was what was needed, I see the OP state the there are multiple values in a FIELD, the point of seaching for imbedded text was yours I belive, no matter, my attempt was to show one meathod to provide a search argument, and scan for that argument
no argument here.

IBM Mainframe Forum

Need faster method to find value in ISPF table column

Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column

Re: Need faster method to find value in ISPF table column