The results of the voting for the OpenMPE Board of Directors are in. Yours truly was elected along with Donna Garverick, Ron Horner, Steve Suraci and John Wolff. Additionally, Alan Tibbetts was unanimously appointed by the Board to replace Ted Ashton whose resignation took effect upon the seating of the new Board. Hopefully you are already a member. If not, why not since membership is still free? We need to energize the MPE-IMAGE community. Supporting OpenMPE is the best shot you have for MPE-IMAGE to exist post 2006 in some supportable and maintainable form. If you have not joined OpenMPE and are not planning to, contact me and give me a chance to talk you into changing your mind.
April saw more of the now all-too-familiar off topic threads about Iraq, or religion, or politics, or Iraq and religion and politics. However, there were also some interesting/amusing off-topic topics, such as this from ComputerWorld, “Forty years ago, at 4 a.m. on May 1, 1964, two Dartmouth College professors -- with the help of two of their undergraduate students -- made computing history. While the professors, John Kemeny and Thomas Kurtz slept; the students successfully ran two simple Basic programs on two separate Teletype terminals located in the basement of College Hall.”
I always 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.
Don’t
Try This at Home
[Name and company withheld for obvious reasons]: “I'm just wondering -- we had HP onsite yesterday and went through the ‘Free Conversion Process’ of turning an A400 into an rp2400. As of about an hour ago, we've got HP-UX up and running on the same hardware that yesterday was running MPE/iX 7.0. We're apparently the first to do this in the entire southeastern US. Are we also the first ones, period, to receive the famous ‘free’ 3000-to-9000 conversion from HP?”
Several people commented that this user would have been much better off selling the A400 and buying a new HP 9000 (complete with 3-year warranty). After all, while it probably runs 5 times faster (without the MPE/iX crippling code), they took a machine “worth $5K - $15K and turned it into a machine worth $1K.” HP has always made a big deal about this, but the fact is there are few A-/N- boxes available in the used market. They are retaining their value because of this. You are likely to lose money on paper by converting an A-/N- class to an HP 9000.
Buffspecs, IMAGE’s Appendix
It is said that the human appendix serves no purpose any
more. The same is true with the buffspecs schema parameter. A user asked, "Something came up today that prompted
me to think about this. After a bit of research, I found that some of the
parameters of our production database are 'default' values. Since it is pretty
much a 'given' that 'defaults are bad', but I'd like some clarification on the
following. In particular, the parameter I am talking about is BUFFSPECS."
He went on to describe his situation and how under certain conditions the
number of buffers would either be too small or not big enough.
Denys Beauchemin gave us all a history lesson, "The buffspecs stuff was never implemented in the native mode version of IMAGE. On the classic series and on the Spectrum boxes before Image was ported to native mode, the buffspecs were important. The default was set as you see in DBUTIL, which meant that the first DBOPEN created the DBCB (Data Base Control Block) to a certain size. The DBCD was a privileged mode data segment, sort of like a piece of memory allocated to a specific purpose. There was another PM data segment, called the DBGB (global block,) I think. At any rate, the data segment would remain that size for the next (second) DBOPEN. On the third DBOPEN, Image would destroy the PM data segment and create a new one with the size specified for 3 and 4 users, and so on, until it reached the maximum size.
“In the days of small memory systems, this was a way to conserve every byte of RAM until it was actually needed. Furthermore, when the number of DBCLOSE started bringing down the number of DB users, the segment would be copied into a smaller segment and then be overwritten. This placed undue overhead on larger systems with people opening and closing databases, so one of the tricks savvy systems managers would use was to specify a buffspecs set immediately to the maximum, so that when the first DBOPEN occurred, the PM data segment would be created one, for everybody. When Image was migrated to native mode, back in 1987 or so, the DBCB and DBGB were merged and became the PM mapped file called the GB file. At that time, the buffspecs became ineffective but remained in DBUTIL for compatibility sake.”
“We've
hit the capacity limit of our DLT 4000 tape drive.”
So said a poster to HP3000-L. He went on to ask about options. This is fast becoming the all-Denys Beauchemin issue, but so be it since he is a recognized expert in backup devices. Denys noted that for a non-PCI architecture machine, the only real alternative is a DLT7000 or DLT8000. Using the same DLT-IV media, you can get close to 70GB on one tape (DLT7000) or 80GB (DLT-8000). This is approximately double the capacity of a DLT4000 (40GB). If the DLT4000 is connected using an SE-SCSI, you will have to install an HVD-SCSI (FWSCSI) controller in order to connect a DLT7000 or DLT8000. These drives and cards can be found in the used market. If you have a PCI architecture machine (A-/N-class), you can also use an LTO Ultrium tape drive that can give you up to 200GB per tape. This will require MPE 7.5 or 7.0 with patches and something other than TurboSTORE (TurboSTORE does not work well with LTO; however, some third party backup software works very well). LTO devices are LVD-SCSI.
Help! I just updated the
system and now the network will not start.
Oftentimes, the answer is to stream the job jconfjob.net.sys. In my experience this is the most overlooked task in system OS updates. Let’s assume you’ve streamed this job, but the network still will not start.
It is increasingly likely that more and more HP 3000 systems with indeterminate heritage will be popping up in shops around the world. There is a serious gotcha in networking services that can make these systems unusable after you perform a system update, say from 6.0 to 7.5, unless you know what to do. Typically, the problem occurs when the SUBSYS tape you update with is missing products that were on the system before. This happened to me some years ago when updating from 5.5 to 6.0. We had stopped support for x.25 because we no longer used it. Everything seemed to go fine with the update (and yes we streamed jconfjob.net.sys) until we went to start up the network, at which point we got something like this:
"Network
service software versions do not match" or "Version error: Bad
Modules"
The result was of course that the network would not start. We were hosed (highly technical term). Unfortunately, MPE/iX update software and procedures give you no way to de-install products. After getting one of the above errors, you need to run "nmmaint,3" and "nmmaint,6" to determine where the problem is and then take appropriate action. In our case, this involved renaming several files beginning with "x25" in the NET.SYS group, "possibly" deleting a file called x25mast.net.sys and re-streaming the job jconfjob.net.sys. Another scenario I've seen recently on HP3000-L comes when updating a system that has the complete NS Services (DSCOPY, etc.) product with a SUBSYS tape that does not have the full NS Services product. In this case, ASRFAVERS, NFTNMVERS and RFANMVERS will have "** MODULE ERROR **" in the "nmmaint,6" display. The solution (thanks to James Hofmeister) is to either get a tape with the NS Services product, or delete the file NSSMAST.NET.SYS and re-stream jconfjob.net.sys. Of course in this latter case, you will not have DSCOPY, etc.
Until this stops coming up on HP3000-L, as it
did this month, I’ll continue periodically stating,
If your printer does not understand PCL, you cannot hook it up as a network printer on the HP 3000 using only MPE/iX’s network print spooler! You have to purchase one of several third party products or do away with network printing and hook it up serially to a DTC. If the printer understands PCL then all sorts of things are possible. For example, I have an HP PSC 2510 Photosmart color dot matrix printer with wireless LAN capability. I configured it in npconfig.pub.sys with SETUP_FILE = PCLLP.HPENV.SYS. Works great.