Searching and Finding
Inside VESOFT covers tips and techniques you can use with VESOFTs products, especially MPEX.
Gonna find her, gonna find her, Well-ll-ll, searching
Yeah Im goin searching, Searching every which a-way, yeh yeh
The Coasters, 1957
I have to admit it Im a bit of a pack rat. It drives my wife crazy and Ive 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 cant 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 Ive used over the years for different reasons, and well 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 thats 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:
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
%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 lets 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 youre 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 theres 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 cant do that with PRINT, because PRINT well, prints the result, showing the occurrence of the string you are searching for. Lets 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 dont 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
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 :
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 havent learned yet that you dont ask that question, then we need to talk later.
The better question is why the FSEARCHEXP attribute? Im glad you asked. This is the one of these attributes that lets you to a caseless search:
Note the additional set of quotes in there. FSEARCHEXP also lets you do boolean searches, but thats 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.
Copyright The 3000 NewsWire. All rights reserved.