I switched from an A400 to an A500 some time back, and I only realized I had not set up the remote web console after the console was down. Where can I configure this? This last time my only access was via VPN, or verbally over the phone. ("What can you see? Okay, so type...") I want to be able fix this myself next time. The console is the built-in one, and not an external box.
Gilles Schipper replies
You can configure your web console from the main console via the GSP interface. Specifically, the command you're looking for is LC (LAN configuration).
This command can be invoked even while the system is up and running by typing ctl-B (control and B together). For more help, at the GSP interface, type HELP, then HELP LC.
Craig Lalley adds that if you arrive at a password roadblock and need to clear a console back to the default login, "at the physical console, hit the GSP reset in the back of the system, then press P on the keyboard. It will reset the passwords."
I need to rebuild an environment from one HP 3000 system to another. Trouble is, we want to have groups from the same account end up on different user volumes. Is there a way to do this using BULDACCT?
Keven Miller adds
BULDACCT was made for processing complete accounts. Do BULDACCT CHC%VSACCT=MEDADV_1. Then edit BULDJOB1 for the other group, changing MEDADV_1 to _2
What I usually do is use BULDACCT to move the entire accounting structure. Then I surgically PURGEGROUP and NEWGROUP (with the appropriate HOMEVS= and ONVS= options, plus CAP= and ACCESS= etc) to duplicate the special groups.
Jim Hawkins notes
MPE/iX RESTORE supports changing volume set specifications on RESTORE (vol, volclass volset) . That is, you can take files/groups/accounts originally on one volume set and place them onto another volume set.
We are still using multipart pre-printed forms and RS-232 dot matrix printers, all direct connected to our HP 3000 for our MANMAN purchase orders, invoices and checks. Obviously, these old HP printers are getting tired and problematic. Our immediate target is the printing of purchase orders. Are there ways to migrate from these form-based printers without breaking the bank?
Lisa Christiansen replies
One option that would work without requiring programming expertise is using ByRequest software from Hillary. We are taking the print ques from MANMAN and overlaying the form/jpeg to print the forms. We also have it set up so that the reports (invoices, POs, and electronic payments) can be emailed to the various parties.
Ed Stein adds
We moved to the ability to laser-print, or email purchase orders in PDF format, using eFORMz and eDirect from Minisoft. For vendors who require a faxed purchase order, we email the PDF of the purchase order to an email-to-fax service, otherwise we email them a PDF copy. We only laser-print purchase orders for vendors who either require a mailed copy or do not have an email address or fax number.
Can I configure a disk larger than 36GB on MPE/iX 5.5? The reason the customer is locked into 5.5 is they use Oracle 7.3 — so I'm now trying to set up a test bed to see if I can move the system up to 7.5 and still have all the wheels stay on. But we might not be able to migrate off 5.5, and the only way to get the enough disc space is to try going to 73GB drives. It doesn't look like 73GB are supported, but that doesn't mean someone hasn't been able to make them work
Jim Hawkins replies
Although your mileage may vary, there is nothing "unsafe" about trying to access 73 GB on 5.5. Of course, there is a 4GB cap on LDEV1, regardless of disk's physical capacity). What's unsafe is the fact that you're likely running on 15-plus year old equipment -- and running on disk-to-firmware-to-HBA combinations they were never tested by us at HP.
When researching "Large Disk" support in early 2000s, my observation was that disk size constraints were last re-engineered around the 4GB mark during MPE/XL 2.x (early 1990s). From there, most of the code worked pretty well up until 512GB, where we run off the rails of some 30 bit limits.
What didn't work okay up to 512GB was addressed by the "Large Disk" patches for 7.5. Things like REPORT running out of space to display a sector count, DISCFREE output etc. The only allocation change I made had to do with trying to spread IO across disks in a more granular way -- really an optimization, rather than an inherent limit.
Allegro's Stan Sieler adds
I remember that when Allegro encouraged HP to handle big disks, I found some definite problems in some obscure things — and that's why we filed a number of bug reports (including JAGad48770 in 2000) and then lobbied with Mike Paivinen, Louis Runnestad, and the CSY lab manager at the time to get really big disks supported. (Ironically, that triggered extra work for me... I had to make sure that De-Frag/X supported them, too.)
Unfortunately, I can't recall the details of what things had problems. Some of the things were offline utilities (for example, DISKCOPY, or DISCUTIL's SAVE command) that could be significant. Some were cosmetic (e.g., incorrect output from DISCFREE).
In the back of my mind, I have a suspicion that on some releases MPE might create some disk-based data structures that are too small — in a way that could potentially cause an overwrite of data ... but I really don't remember what it was, or which MPE release (might have been *very* long ago, sorry!).
My old notes say that 5.5 with PowerPatch 5 had an "official" max disk size of 18 GB and that I thought I'd seen a working 36 GB drive on a system. The same notes say that the base release of 5.5 officially had a 9 GB max disk drive size.