RAC Consulting Sponsor Message

Net.digest summarizes helpful technical discussions on the comp.sys.hp.mpe Internet newsgroup and 3000-L mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

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. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse’s behind, let me know. If you spot something on 3000-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.

Directory, directory, wherefore art thou directory?

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 – why did it do that?

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.

Web Console weirdness

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.”

What do you do with COBOL programmers if migrating to HP-UX or Linux?

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 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 want to make a comparison among the various languages, here is a URL for the “Hello World Project”: www.latech.edu/~acm/HelloWorld.shtml

John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.