|
View previous topic :: View next topic
|
| Author |
Message |
arindam111
New User
Joined: 29 Nov 2006
Posts: 27
Location: India
|
|
|
|
I have an ISPF table like this:
TABLE1
| Code: |
COL1 COL2
+++++ ---------------------------
33aaa a cat
44bbb another cat
44ccc another cat which is great
55aaa cat
66ccc cat is white |
I'm trying to read COL2 for those rows having a string "cat" in any position.
This is what I have tried -
| Code: |
COL2 = ""
"TBOPEN TABLE1 NOWRITE SHARE"
"TBVCLEAR TABLE1"
COL2 = "*" || "cat" || "*"
"TBSARG TABLE1 NEXT NAMECOND(COL2,EQ)"
"TBDISPL TABLE1 PANEL(PANEL1)"
"DISPLAY PANEL(PANEL1)" |
My panel MODEL section is like this:
| Code: |
)MODEL ROWS(SCAN)
@COL2 |
But no rows returned. All I can see is *cat* in the panel.
-------------
I have tried with
| Code: |
| COL2 = "cat" || "*" |
Then i'm getting this in the panel - which is correct -
Why *cat* wild-card not working while cat* is working? It'll be great if someone can help. Thanks. |
|
| Back to top |
|
 |
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| TBSARG supports the asterisk-as-wildcard only as a suffix; prefixed or infixed asterisks are treated as literals. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
Is there a space before your || and a space afterwards?
Then you are looking for * space space cat.
No data matches that, correct?
| Quote: |
COL2 = "*" || "cat" || "*"
|
|
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
Akatsukami is correct.
I should have read the manual before I posted.
maybe arindam111 should have done so as well? |
|
| Back to top |
|
|
arindam111
New User
Joined: 29 Nov 2006
Posts: 27
Location: India
|
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
Maybe it is not so clear?
| Quote: |
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. For example, to perform a generic search for a row value of DATA*12, the generic search argument is:
DATA*12*The first asterisk is part of the search argument. The second asterisk designates the argument to be a generic search argument
|
|
|
| Back to top |
|
|
arindam111
New User
Joined: 29 Nov 2006
Posts: 27
Location: India
|
|
|
|
Ohh! I missed that. Thanks.
But any other way you can think of? |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
I think you are on the right track with your solution.
Rather than using a stem, create a temporary ispf table, when you scan and parse, do a tbadd when you have a match.
Then change your tbdispl for your 'temp' table.
No so ugly, but effective. It depends on the size of your main table I guess. |
|
| Back to top |
|
|
arindam111
New User
Joined: 29 Nov 2006
Posts: 27
Location: India
|
|
|
|
Okay! I'll try it out. In my requirement, table size would be max 1000. So after pattern matching it will be less than < 1000. I think, this wont be a performance issue in Z/OS system.
Thanks! |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2547
Location: Silicon Valley
|
|
|
|
| Quote: |
Is there a space before your || and a space afterwards?
Then you are looking for * space space cat. |
Dave, I do not believe your statement is correct. It will concatenate as it was intended.
My suggestion is similar to Arindam111's. Add an additional column to the table. Use TBSCAN to search one row at a time and if 'cat' is found, set that variable to 1 and do a TBMOD for that row. Then use TBSARG to search that column. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
Pedro,
I know I was incorrect, that is why I retracted with the next post:
| Quote: |
Akatsukami is correct.
I should have read the manual before I posted.
|
I like your technique for sticking with one table.
If however the search argument changes from cat to dog, the new variable needs to be reset back to zero or all rows prior to a new scan being done. |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2547
Location: Silicon Valley
|
|
|
|
Dave, I apologize for not following the entire thread.
| Quote: |
| the new variable needs to be reset back to zero |
Rather than 1 or 0, how about figuring out a unique token and then only display the rows with the matching token. In that way, you do not have to start the search from the top, nor update rows unnecessarily for rows that do not match. |
|
| Back to top |
|
|
|
|
