There was so much discussion about the fate of MPE and the HP-Compaq merger (two unrelated items that will forever be nonetheless linked because of timing), that there were few of the lengthy threads that usually serve as source for net.digest. Not to worry though, I stockpiled threads from previous months that never made it to print because of space limitations.

As always, I would like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse's behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.

My all time favorite candidate for worst default behavior in a command option is the "directory" parameter of the STORE command. Every few months someone asks about restoring a user volume set and every few months somebody has to remind everyone about the proper usage of the "directory" option. This month it was Gilles Schipper who provided the reminder: "You need to ensure that your backup includes ALL directories; for example,

:store /;directory;onvs=mpexl_system_volume_set,uservolset1,uservolset2…

Then, after you have rebuilt your volume set, you simply restore the directories as follows:

:file t;dev=tape
:restore *t;;directory (note 2 consecutive ";"'s)

Then restore the data that used to be on the user volume set. Make sure you use the KEEP option on any restores - just to guard against any errors in specifying the file sets that need restoring.

Symbolic links have been around for a long time, yet they remain underutilized outside the Posix realm and misunderstood in general. Consider this posting: "Here's my official complaint/warning/whatever about how ":PURGE" deals with links. A ":PURGE" of a link does NOT purge the link. It purges the file the link points to. It's not at all obvious to me why one would want it to do this and I'd rather not think too long about my recent experience regarding why one would NOT want it to do this!" And this was from someone who would normally be considered an MPE guru. Another guru explained why the behavior of ":PURGE" on a link made perfect sense to him, but then complained about the behavior of ":RENAME".

The best way to think about symbolic links is to think of them as permanent file equations. For example,

:build mytest
:file mylink=mytest,old
:purge *mylink

will result in the purging of the file mytest. Note that the file equation still exists, but it points to nothing. If you want to remove the file equation, you use the "reset" command. If you want to remove a symbolic link, you use the "purgelink" command. As a second example, consider,

:build mytest
:file mylink=mytest,old
:rename *mylink,mytest2

This will rename the file mytest to mytest2. Again, the file equation still exists, but points to nothing. Symbolic links behave the same way.

A number of people have written over recent months about problems with the Secure Web Console hanging. "For no apparent reason, without any warning, they hang. The only way to 'un-hang' them is to close the console and re-access it, losing all terminal buffer history." Carl McNamee provided a possible workaround: "We had the same problem with lock ups at our site until we isolated the web console devices onto their own LAN segment. It appears that the devices go out into left field if the number of network packets they receive goes over some threshold. It doesn't have to be a steady stream of packets either. We found that a quick burst of packets was enough to cause problems. Since moving our web consoles to a network segment that has almost no traffic the problem has completely disappeared."

The question: "We’re planning new applications to replace our MPE ones that can't easily be ported or that really do need to be re-written. One school of thought is that we should write new stuff in c. c is good for attracting new programmers, but how hard is it for Cobol programmers to learn to use c? Another school of thought is that the programmers should write in the language that they know best, to get the best code with the highest productivity. This appeals to me, since productivity is going to be extremely important. The same modular design can be written in either c or Cobol and as long as the two talk to each other this multi-language strategy would work. How well do different languages cooperate on Unix or Linux? (I.e., can Cobol make libraries c can call, and the reverse?)"

Jim Phillips provided the philosophical answer, with which I agree completely: "Way back when I went to programming school, we learned four languages: Basic, Fortran, Cobol, and RPG. Since then I've picked up Visual Basic, C, and some C++. For me (and I'd like to think, for any competent programmer, no matter what language they use primarily) I've not had a problem picking up new languages, in so far as syntax and such like. Now, procedural versus event, that's a different story. That requires some change in design. But still, not so much so as to make everything I've learned using those old, out-dated languages completely useless.

"I guess the bottom line is: If you want to retrain your existing Cobol programmers to use c, you may have problems with individual programmers (but I'll bet those ones have been giving you problems anyway), but the vast majority will probably be excited to learn something new. Don't discount them just because they use Cobol."

Gavin Scott provided a more technical answer: "Having the programmers write in the language they know best is probably always going to be the fastest route to a robust and predictable solution. The biggest problem with COBOL on HP-UX or Linux is that it is probably the least available language. The kind of people who like to hack Unix code are the least likely to also like writing COBOL programs, so the COBOL compilers that exist tend to be expensive commercial products. The Unix COBOL compilers often have proprietary runtime libraries and some are not native compilers at all, but are either pure interpreters or produce an intermediate PCODE which is run by a virtual machine. I suspect all of them have at least the ability to call out to c (and therefore most other languages). You can probably call into most of them as well, but things start to look more like Java than c. Most everything else on Unix tries to be compatible with c/c++. So, in the worst case you might have to write a small amount of glue code in c to make random language A be able to invoke code written in random language B."

For the geeks among us, Douglas Becker noted, "if you who want to make a comparison among the various languages, here is a URL for the "Hello World Project":

http://www.latech.edu/~acm/HelloWorld.shtml

When using a "file" equation with the "dev=" parameter, it appears that sometimes the system validates the value and sometimes it does not. Consider the following:

:file t;dev=LP
:FILE T;DEV=GARBAGE
^
Unknown device class. (CIERR 344)
:FILE T;DEV=1BADDEV
:showdev 1baddev
^
Logical device class "1BADDEV" cannot be found on the system. (CIERR 1583)
:FILE T;DEV=12345BAD
^
Unknown logical device. (CIERR 345)

Jeff Vance explained: "I looked at the code and the FILE command calls GETDEVINFO which calls an internal routine named ATOB which converts ASCII to decimal. ATOB() stops its scan at the first non-numeric character. The resultant value is then used for a validity check. In the case of "1BADDEV", most systems have an ldev 1, so it passes; while ldev 12345 is unlikely to exist and therefore gives the ‘Unknown logical device’ error. It is a bug, but appears to have been in place a long time."

To this someone responded: "There should be a consistent set of rules for what is a 'valid' device class name and what will be accepted as a (potentially) valid LDEV number."

Here’s where the tangled web comes in. Jeff Vance again: "This seems perfectly reasonable, but I was involved many years ago in cleaning up some of this code. We enforced stricter parsing rules specifically for DEV= and broke Netbase, which embedded remote machine info into the DEV= parm. We had to undo our "fix". Also, the FILE command is a mixed bag. Most of the parameters must exist on the system, but some don't need to. For example, :file a=b works fine even if B does not exist at the time the file equation is created. :FILE was not originally designed to be an LDEV checker etc., but has been used very creatively by our customers for so many years that there is a fair chance of breaking something if we alter its parsing rules."