Genisys Sponsor Message

Searching and Finding

By Steve Hammond

Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX.

Gonna find her, gonna find her, Well-ll-ll, searching

Yeah I’m goin’ searching, Searching every which a-way, yeh yeh

I have to admit it — I’m a bit of a pack rat. It drives my wife crazy and I’ve gotten better, but I still hold onto some things for sentimental reasons. I still have the program from the first game I ever saw my beloved Baltimore Colts play. On my desk is the second foul ball I ever caught (the first is on display in the bookcase). I have a mint condition Issue 1 of the HP Communicator — dated June 15, 1975 (inherited when our e3000 system manager retired). It tells that all support of MPE-B terminated that month, and the Planning Committee chairman of the HP 3000 Users Group was a gentleman from Walnut Creek named Bill Gates (okay, not that Bill Gates).

My problem is even when I know I have something, I just can’t find it. I had an item the Baseball Hall of Fame was interested in; they had no ticket stub from the 1979 World Series, which I had — seventh game no less. But it took me over two years before I literally stumbled across it.

I wish I could add some sort of easy search capabilities to my massive collection of junk like we have in MPEX.

The most commonly used is the search option in the PRINT command. But there are a couple of other ways to search that I’ve used over the years for different reasons, and we’ll look at those too.

In the olden days, when passwords were embedded in job streams, when we changed passwords, we would have to find every job with the password in it. A long, tedious task that never found all of them. And yes, the ultimate answer was converting to STREAMX, but that’s a column for another month.

When MPEX added the PRINT;SEARCH command, life became much easier and we found many uses for it. As the versions of MPEX evolved, the command gained power. The simplest form is:

%PRINT @.JOBS.PROD;SEARCH=”FILE”

This will search for any line with the word “FILE” in it — exactly “FILE”, not “file” or “File” or “fILE”, you get the picture. Easily solved with:

%PRINT @.JOBS.PROD; SEARCH=caseless “file”

or

%PRINT @.JOBS.PROD; SEARCH=cl “file”

Either of those will get you the word “file” in any form.

You can do boolean searches:

%PRINT @.JOBS.PROD; SEARCH= “FILE” and “TEMP”

%PRINT @.JOBS.PROD; SEARCH=”FILE” or “RUN”

%PRINT @.JOBS.PROD; SEARCH=”RUN” and NOT “PRODPGM”

The first returns any file that has a line or lines with both FILE and TEMP, the second looks for FILE or RUN and the third looks for files with any lines that contain RUN but do not have PRODPGM.

You can even delimit your searches — let’s say you have a tape drive that you call “DAT”. Well, doing the search

%PRINT @.JOBS.PROD; SEARCH=”DAT”

will find the reference to DAT as the tape drive you’re interested in, but as a bonus feature it will also find “DATA”, “DATABASE”, etc. By using the DELIMIT option:

%PRINT @.JOBS.PROD; SEARCH=delim “DAT”

you will find only occurrences of “DAT” with non-alphanumeric characters before and after it. Taking this a step further, you can right and left delimit your search

%PRINT @.JOBS.PROD; SEARCH=ldelim “DB”

%PRINT @.JOBS.PROD; SEARCH=rdelim “DB”

The first will files with lines containing DBSTORE but not PRODDB, and the second vice versa. You can even add the caseless option to delimited option:

%PRINT @.JOBS.PROD; SEARCH=caseless rdelim “DB”

Caseless can be abbreviated “CL” and delim can be “D”.

But there’s another way you can do searches, which I found very useful - searches that I used out of a LISTF, building an indirect file for later use. You can’t do that with PRINT, because PRINT well, prints the result, showing the occurrence of the string you are searching for. Let’s say we were changing the name of a database — DEVDB to PRODDB. All I really need to know is all the jobs that have the reference to “DEVDB” — I don’t need to see the context of the string, I just need to know the files. And I need to know the fully-qualified name of the file and I want it in a file named INDFILE1.

This is where the file attributes FCONTAINS FSEARCHSTRING and FSEARCHEXP come into play. The second and last are similar because you have to state that there are greater than 0 occurrences in the file (or any value for that matter), but otherwise they all work the same.

%LISTF @.JOBS.@ (FCONTAINS(“DEVDB”)),6>*INDFILE1

or

%LISTF @.JOBS.@(FSEARCHSTRING(“DEVDB”)>0),6>*INDFILE1

or

%LISTF @.JOBS.@(FSEARCHEXP(“DEVDB”)>0),6>*INDFILE1

As I said, FCONTAINS looks for the existence of that string in a file and basically FSEARCHSTRING does the same thing. But with FSEARCHSTRING, you can do :

%LISTF @.JOBS.@(FSEARCHSTRING(“DEVDB”)>2),...

which says you want to find a file that has any line with a minimum of three occurrences of “DEVDB”. Why would you want to do that? If you haven’t learned yet that you don’t ask that question, then we need to talk later.

The better question is why the “FSEARCHEXP” attribute? I’m glad you asked. This is the one of these attributes that lets you to a caseless search:

%LISTF @.JOBS.@(FSEARCHEXP(“CL’DEVDB’”)>0),...

Note the additional set of quotes in there. FSEARCHEXP also lets you do boolean searches, but that’s just getting way too complicated!

The final question is why did I do it this way? If I was going to change a string, I would do an overnight job that found the files that needed to be changed. I would put the output of that process into an indirect file in the LISTF,6 output format (fully qualified file name). I would then use the indirect file as input for the job or process to change the string.

So now, you should go out and SEARCH THOSE FILES, FIND THOSE STRINGS, UPPER CASE BE DAMNED!

Steve Hammond, who works for a professional association in Washington, DC, believes in the Constitutional protection from illegal search and seizure.