| Front Page | News Headlines | Technical Headlines | Planning Features | Advanced Search |
WRQ Sponsor Message


Unset UDCs, and a programmer’s heart

By Steve Hammond

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

I once heard a man whom I admire and respect, Alfredo Rego, tell how he has always considered himself a programmer. Now he heads one of the best-known HP 3000 companies, but I am quite sure he is still a programmer at heart.

And I think that’s true — once a programmer, always a programmer. While my primary job duties these days are more contract-related and system administration, I still truly enjoy the few programming chores I get. In the past few years, I’ve added Javascript, C++ and Linux shell scripting to my programming CV, just to try to stay current.

And part of that “jones” of being a programmer is the need to break down and understand processes and tasks that work so well and so efficiently.

That kicked in for me recently after I had a chat with VEsoft’s Vladimir Volokh. He told me he had been asked to find out if any users on a system had the VEsoft utility GOD in one of their UDCs and if it had the lockword embedded in the UDC. He gave me a series of two commands that did the trick and they had some added value to boot. Once I saw the commands, I was impressed with the simple elegance, but like a good programmer, I had to deconstruct it, break it down and reassemble the whole thing. If you’d like to play along, you need: MPEX, VEAUDIT (both available from, who else, VEsoft) and a healthy programmer’s curiosity (you’re going to have to provide that yourself).

The commands are:

%filter “veaudit listudc;invert”, r[0:1]>” “;format=word(r)>ve

%print ^ve;search=cl”vesoft”;highlight;keepamdates

You need to start in the middle (as often happens in a task like this):

veaudit listudc — this is the VEAUDIT command to list all the UDCs currently set on your system. This give you an output (in part) of:



When you tack on the “invert” to the “listudc,” this turns the output of the listudc around, so that the file name is listed first followed by all the users who have that UDC set (a very helpful feature), and you get:

@.PROD02 @.PROD97 @.PROD98


Now “filter” comes into play to help you clean up the data above so you can use it as an indirect file. What you ultimately need is a list of all the UDC files that have been set on the system.

Looking at the output, what you have is the fully qualified UDC file name followed by an indented list of all the users who have that UDC set (three users per line, with all subsequent lines indented to line up with the list of the users in the first line). On my system, I have one UDC that has 50 lines of users! So what filter does is allow you to set some ‘parameters’ to the format of the output. In this case, it does two things. Since we are going to ultimately search for a string in a UDC file, we just need the file name, not the list of the users. How do we do that? Eliminate any lines that have a blank in the first position. Here the ‘r[0:1]>” “‘ does that for us — it says retain any record (the predefined variable ‘r’) whose first position (“[0:1]” says start at the first position for the length of one) is greater than a blank. Only the lines that start with the file name, fulfill that parameter, so we retain just those lines.

Now we need to get rid of the list of users at the end of the line. Again, we need a little more help from the filter. This time we invoke the ‘format’ option, telling it perform the predefined ‘word’ function (actually an MPE function), which returns a specific word in the record (r). In this case, it takes the default of the first word. How does it determine the first word? Again relying on the default which considers the delimiter to be a space, it looks for the first space and anything in front of it must be the first “word.” Since there are no spaces in the fully qualified file name of the UDC, viola, we have extracted the names of all the UDCs set on the system. Now it’s just a matter of slapping those names into the temporary file ve and we’re ready for step two.

For step two it’s just a simple matter of using the file ve as an indirect file for the print command. We then search for the string vesoft (we could have looked for ‘GOD,’ but vesoft gave me more examples to work with). We use the caseless option (search=cl”vesoft”), highlight each occurrence of vesoft and retain the access/modify dates in the file label. Run that and you get something like this:

Non-existent file. (CIERR 907)
Non-existent file. (CIERR 907)
run mpex.pub.vesoft;nocb

Look for a string ‘GOD.PUB.VESOFT’ — that’s your file name and we have accomplished our original mission. But wait. What are those CIERR907 files? Those are files in the list that don’t exist! But they are UDCs that have been set! Looks like you can do some housecleaning and those UDCs can be un-set. How about that — you got some value added, you killed two birds with one stone, (insert your favorite cliche here). Time to play system manager again.

So what have we accomplished? Yet again, I’ve learned something from someone who knows far more than I do. (Could someone please explain this concept to my teenager?) We’ve learned an easy way to find UDCs that can be unset, and we have seen, yet again, the power of MPEX. This leaves us time to ... I know I’ll think of something!

Steve Hammond, who works for a trade association in Washington, DC, wishes to thank friends like Vladimir and Michael who are always there to make his job easier.

Copyright The 3000 NewsWire. All rights reserved.