May 25, 2012

Paper passes on primers on MPE, and more

Imagine it's your first day managing an HP 3000. You don't have to travel in a time machine to find that kind of event. However, a magic carpet of the past ensures the delivery of time-tested fundamentals. The carpet is paper, where so much MPE lore first unspooled for your community. If not for articles on paper, much of the 3000's wisdom would never have made it to the web.

As for that first day, an IT manager at Disston Tools in South Deerfield, Mass. has had that date arrive just this month. He's a total newbie, taking over for a veteran who's leaving this manufacturer. Everybody's a newbie at something. It's just like publishing news: if it's something you didn't know, then it's news to you.

NewsprintNot many Interweb resources call themselves publishers, but we do. We started with ink on paper, my partner Abby and I, initially for a cross-platform IT publisher before the NewsWire was first delivered from our own offices. This week we delivered our 155th print issue. The May edition will be available to our community newbie, as well as one veteran that community icon Vladimir Volokh scouted out in Los Angeles. Vladimir hand-delivers print issues on his consulting trips, much to our delight.

With all that print heritage, I took note of a retrenchment in printed news this week. The daily newspaper in New Orleans will be daily no more. The Times-Picayune is going to three times weekly in print and everyday online. This is a newspaper that won two Pulitzers for its Katrina reporting. Sadly, the caliber of content doesn't bulwark many publications anymore. Advertisers, like our fine sponsors, determine how often the presses roll.

In the alternative, of course, there's the Interweb. I use the jokey term for online news because it's completely pervasive and so up to date that the future seems like yesterday if you bury your head in links. Knowing where to look, however, becomes a great mission for printed publications. We always hear that people have found our reports for the first time when they get a print issue of the NewsWire. It's nice to have that outpost, and essential to who we are and how we deliver. But for printed pages long gone, it's great to have host sites that preserve things like George Stachnik's instruction about using files in MPE, and much more. It's one of 21 articles in a series he wrote for the now-departed InterACT magazine. All are preserved for the education of newbies, as well as the rest of us.

Chris Bartram at 3K Associates has collected Stachnik's articles, as well as many other papers, at the 3k.com website. (Think about how long that site has been around. It's so fundamental it's got a two-character domain name. Fewer than 1,300 of those in existence.) Our community is lucky to have the riches of several of these kinds of sites. Open source software, at mpe-opensource.org. Tech papers at robelle.com, adager.com, allegro.com.

But most of those papers started out on paper. Because MPE's preserved its roots, even an article like Stachnik's written more than a decade ago will be useful at Disston Tools. The company's covering its MANMAN support needs with service from the Support Group, Inc. Terry Floyd there gave us a heads-up about the new IT guy, and we're glad to send the new member our printed May issue.

Print-ExclusiveSponsors in your community still believe in the power of paper, even while they buy Adsense keywords from Google and build Twitter feeds and pursue Facebook Likes. We're always mindful that the NewsWire depends on support as well as new readers and faithful followers. We once led off with print reporting and archived it on the Web. But about the time Katrina was hitting New Orleans we switched out our lead horse -- with some exception. Every printed issue carries content that's only available in paper as an exclusive, for awhile. If you'd like your own printed copy in the US, we'd be glad to send it to you. (Click on the icon above to send us a message.) Our non-domestic web-only readers, thousands of them, have access off the page. Like the Times-Picayune, we're working with a blended model of the old and new, even as we link wisdom from the elders to our new readers.

Posted by Ron Seybold at 01:50 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

May 21, 2012

HP runs ahead and behind, then and now

The iconic entity called Interex emerged this month 28 years ago. HP had announced it would catch up to 32-bit computing with Spectrum. And the vendor whose sales still didn't exceed $7 billion said in 1984 that touchscreens were the most intuitive interface. Being ahead and behind all at once is a sign that you're still developing, making leadership while you catch up your customers

RandomAccessInteract84Hewlett-Packard used the 1980s in your community to push out new ideas. Touch-based personal computing hit the market in the HP 150, one of the Series 100 PCs that transformed the International Association of Hewlett-Packard Computer Users. Before HP cast its seeds of PC innovation, Interex didn't exist. In a May column from executive director Bill Crow in InterACT magazine, the user group renamed itself "to define the association's independence" from HP.

Although that user group has been in the grave more than six years, its members' insights haven't evaporated. An era of ink on paper (click above for detail) has preserved milestones like HP running more than 25 years ahead of the industry with touchscreens. It's easy to forget your community was reaching for a breakthrough office experience even while it was dragging along chips devised a decade earlier.

Ed McCracken, a GM of HP's Business Development Group, announced in early '84 the seven basic principles guiding HP's "office automation strategy:

1. The workstation is the most important component, followed by the distributed data processing system (DDS)
2. All workstations will be personal computers
3. The touchscreen is the most intuitive interface
4. Workstations will not tie directly to mainframes but to an intermediate DDS
5. A pragmatic approach to open architecture is required
6. High quality is essential
7. There must be an intuitive integration linking managers' workstations, secretarial workstations, and the other components of the system.

Number 3 is the most striking of the guides offered by McCracken, the man who drove the genius of bundling the rising DDS of the 3000 with a crack database. But in '84 HP was already considering IMAGE a database that needed a successor. The vendor was following in IBM's wake, right down to a new partnership with a small company built by an IBM ex-pat. Interex also recognized that Alfredo Rego -- "the man behind Adager" -- was on par HP's CEO, John Young. Both gave 1984 user conference speeches, but Rego recognized that IMAGE was to remain the force behind the 3000's success.

It wasn't going to come through a new processor family -- although the Spectrum project's 32 bits were critically overdue. Like today, software mattered more than hardware like Itanium. Oracle's database, built upon the same IBM roots, will determine the fate of the last remaining OS that HP ever built with its own R&D. Databases are lynchpins.

HP saw as much when it partnered with Esvel Inc. The firm founded by Kapali Eswaran, one of the founding members of the IBM System R relational DB product, would develop "scalable database architecture for HP." The next product turned out to be Allbase, but HP already wanted a common database among its real-time, scientific (HP-UX) and office systems.

Like then, the vendor's reaching for some commonality with its Itanium futures. Last year Intel was announcing new underwear for the chip the industry forgot, promising that Xeon architecture would share base elements with Itanium. HP wants to have it both ways -- a market in a the commodity space along with the power of software built on proprietary hardware. You've still got that kind of power in your MPE-IMAGE world. Because Oracle's got HP by the scruff of its enterprise neck, the software still calls the plays. But now HP doesn't control the database -- to the point of seeing customers define themselves as Oracle shops. Oracle's not leaving HP computing. It's departing the computing most profitable to HP.

Esvel was the first step that HP took toward embracing an industry standard for its enterprise business. Back in 1984 the little company had already delivered the seeds of DB2 to IBM. HP was chasing Big Blue in every field but instruments back then. The vendor which created the HP 3000 believed in a pragmatic approach to open architecture: standards were less important than reliable value. In less than seven years HP didn't believe that anymore, driving the Open Enterprise with open systems.

Allbase earned a few footholds in the Open Enterprise, but IMAGE ruled the 3000's roost. Just like Oracle does today, HP's database had become the common coin of computers for HP business. You couldn't switch over billions of records without a lot of magic in 1984. Hewlett-Packard had the right idea about touch interfaces, but the wrong technology and message. This May the message is in the hands of the software providers, not the hardware makers. HP used have R&D enough to be both, which is what still makes the 3000 value durable beyond all accepted wisdom. 

Posted by Ron Seybold at 11:45 AM in Homesteading, MPE's Hidden Value, News Outta HP, Your System's History | Permalink | Comments (0)

May 10, 2012

Intrinsic Advice: Finding HP's 3000 Savvy

While I fine-tuned (okay, corrected) yesterday's report about the current lifespan for MPE date intrinsics, my associate technical editor Vladimir Volokh suggested we include HP's documentation page for HPCALENDAR. That's the intrinsic HP wrote for the 6.0 and 7.x releases of the 3000's OS, a new tool to solve an old problem. Alas, HPCALENDAR is fresher, but it's only callable in the 3000's Native Mode.

But poking into the online resources for MPE Intrinsics, I stumbled on HP's re-shelving of its 3000 docs. No longer available at the easy-to-recall docs.hp.com, these manuals are at HP's Business Support Center. And just about nowhere else within a 10-minute search across Google's search engine. (Bing did no better.) So where are the guidelines to intrinsics for MPE/iX? All docs for the 3000's software are at the BSC 3000 docs page.

The Intrinsics Manual for 7.x is a PDF file at 

h20000.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=416035&targetPage=
http%3A%2F%2Fbizsupport2.austin.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2F c01712464%2Fc01712464.pdf

A lot to remember, but not much is simple while using HP's resources for 3000s these days. It used to be much simpler. In the 1990s the Interex user group ran a collection of well-written white papers by George Stachnik. We're lucky enough to have them with us today, cut loose from ownership and firewalls. One is devoted to the system's intrinsics.

By the time The HP 3000--for Complete Novices, Part 17: Using Intrinsics was posted on the 3K Associates website, Stachnik was working in technical training in HP's Network Server Division. He'd first written these papers for Interact, the technical journal devoted to 3000 savvy for more than two decades. Even though Interact is long out of print, Stachnik's savvy is preserved in multiple web outposts.

Stachnik explains why intrinsics tap the inherent advantage of using an HP 3000.

When an application program calls an MPE/iX intrinsic, the intrinsic places itself in MPE/iX's "privileged mode." The concept of privileged mode is one of the key reasons for the HP 3000's legendary reputation for reliability. Experienced IT managers have learned to be very wary of application programs that access system internal data structures directly. They demand that MPE/iX place restrictions on HP 3000 applications, to prevent them from doing anything that could foul up the system. This is what led to the development of the intrinsics. Application programs running in user mode can interact with the operating system only by invoking intrinsics.

Even if your company has a migration in mind, or doesn't have an unlimited lifespan for the 3000, knowing how intrinsics work is an intrinsic part of learning 3000 fine-tuning that might be inside classic applications. Tools can help to hunt down intrinsics, but it helps to know what they do and what they're called. You can fine-tune your 3000 knowledge using Stachnik's papers and HP's Intrinsic documentation.

Posted by Ron Seybold at 02:20 PM in Homesteading, Migration, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

May 09, 2012

Which bits produce the 3000's stall in 2028?

Vw-egoAt the risk of beating a dead horse, we will return to the 3000's roadblock in 2028 one last time. We can wrap up our CALENDAR intrinsic discussion with an explanation of the reason for its hold on the 3000's far future. But it might be useful to consider that 2028 is not so far away that engineers aren't already conceiving its technology. When you merge VW and 2028, you can get an image like the one above.

Before the future, though, there's always history. When MPE was created in 1970, it started as a project called Omega. The miracle of this engineering was its use of 32-bit computing, still a novelty at the time. But when HP canceled Omega in favor of a 16-bit 3000 -- a management choice that prompted black armbands among HP staff -- it sealed the server into a 57-year period of service.

That's because, we were reminded by MPEX co-creator Vladimir Volokh, 16-bit 3000s left only enough intrinsic room for 127 years of accurate dates. The intrinsic CALENDAR, written for the eldest MPE Segmented Library (SL), uses only 7 bits to describe which year is in effect. That delivers a maximum number of 127 years which you can express, and MPE was built with 1900 as its base for dates.

From HP's Intrinsics Manual:

CALENDAR
date

16-bit unsigned integer
(assigned functional return)
Returns the calendar date in the following format:

Bits Value/Meaning

7:9
Day of year
0:7
Year since 1900

HP only allotted 7 bits to describe the year for MPE. Who'd expect that the OS would have a lifespan of more than 50 years? Someone who figured newer and better tools would take over by then. It's commonplace to believe in the equivalent of flying cars -- Volkswagen's 2028 model concepts (shown above) are online in the company's German video and Flash site. Maybe cars will fly in some places, maybe not in others. Oh, for one extra bit. But HP ordered 16 extra, just too late to influence the heart of MPE.

Working in the realm of the original 16-bit MPE intrinsics, "You cannot make less than 9 bits for the date of the year," Vladimir said. "That would be less than 365 days. So that leaves us 7 bits to express the year."

The vintage-'90s HPCALENDAR, reaching into the new elbow room of 32 bits, can use as many as 23 bits for the year. That intrinsic will cover 8 million years, even more. HPCALENDAR is available in Native Mode MPE, and it remains the best choice for any new work done on a 3000's applications.

But MPE's existing intrinsics provide the barrier here: the oldest are in Segmented Library (SL) -- and the newer HPCALENDAR is in Native Library (NL). And the only companies with any chance of adjusting the 3000's dates into 2028 and beyond are those which have insight into MPE/iX source. Then there's knowing what to do with it. They must get into the MPE source and recompile it to use HPCALENDAR.

For complete reference, here's the manual page for HPCALENDAR:

NM callable only.

This intrinsic returns the date in the supported
date type code 4 listed in the table, 
“Supported Date Formats.”
Syntax

I32

   date := HPCALENDAR;

Operation Notes

Where date is the 32-bit unsigned integer
(assigned functional return). This returns the
calendar date in the following format:

Bits Value/Meaning

23:9 Day of year

0:23 Year since 1900

Dates don't vex MPEX, Vladimir reminded us. It can do operations with DATE. "If you have MPEX, and who doesn’t," he says, "DATETOCALENDAR is a function in MPEX."

Vladimir also talks, on his return from consulting trips to 3000 sites, about the level of 3000 knowledge he sees in even long-time users. Management relies on the HP guys to tell them what’s up, and the HP guys don’t know.

"There are all kinds of excuses not to know what you’re doing," he says. He tells of his philosophy about learning. You draw a circle to represent what you know. "Inside the circle is what you know, outside is what you don’t know. You go along the circumference. Only by going along there can you see what you don’t know. So you learn, and you draw a bigger circle, a bigger circumference. The more you know, the more you know what you don’t know."

In converse, consider the smallest circle of knowledge, just a point. Vladimir adds, "When you know nothing, you think you know everything."

No one knows who will be working in the years near 2028 on HP 3000s. But in an era where Amiga computer games can be played on iPhones -- and companies now earn money for such a creation -- it's easy to say we don't know who will break this 2028 barrier. And they might be driving a car called a Volkswagen, and using a computer called the 3000, and neither will resemble what we know today, more than 15 years away.

Posted by Ron Seybold at 05:16 PM in Homesteading, MPE's Hidden Value, Your System's History | Permalink | Comments (0)

May 01, 2012

RAIDing LDEV1, finding code for migration

What are the solutions for replacing our 4GB internal LDEV1 with something that supports RAID -- or at least disk mirroring? We currently have our production data in 'Jamaica' units, fully mirrored (Mirror/iX), but I've been worried about that ancient LDEV1. We do everything possible to not shut down power. It has reached the point where I have concern that if the drive ever lost its taste for power, it might never spin up again -- and the thought of a RELOAD is not fun.

Mod 20Jack Connor says

There are two fairly low cost solutions which could handle RAID for your 3000. These would be the Mod 10/20 (at left) and Autoraid 12H units, both of which connect via FWD SCSI. A Mod 10/20 would require two FWD cards/connections to be available; the 12H, just one.

Gilles Schipper says

If the HP 3000 is not an A-Class or N-Class, then the best solution would be a Mod 10/20 or an Autoraid 12H. If it is an A-Class or N-Class, the best solutions include any number of fiber-capable devices -- such as a VA7xxx, an XP unit, and others. You could use the Mod 10/20 and Autoraid, but why would you, unless cost is the most important factor?

Craig Lalley says

One problem to consider is the model of HP 3000. The older "NIO" backplanes used in the 9x9s and earlier do not support native Fibre Channel. The N-class boxes do. To boot from a VA7xxx array, you would need the A5814A-003 Fibre to SCSI "brick" if you are not using an A-Class or N-Class.

We have recently begun our migration off the HP 3000. How can I determine what programs reference the data items in our TurboIMAGE databases, since the application vendor we currently use did not provide us with a data dictionary?

Robot3000Michael Berkowitz says

Since you're using COBOL and probably use copy libraries, you could use Robot/3000 from Productive Software Systems. (Screen shot of Robot shown at left)

Larry Simonsen adds

Another option is to use the 3000's grep command in MPE/iX.

Posted by Ron Seybold at 01:55 PM in Homesteading, Migration, MPE's Hidden Value | Permalink | Comments (0)

April 30, 2012

3000's use in 2028: bug, or feature?

The CALENDAR intrinsic that blocks HP 3000 use in 2028 has been described as a bug. On the first day of that year, dates will not be represented accurately. Some in your community consider that New Year's Day, less than 16 years from now, as the 3000's final barrier. But it depends on how you look at it -- as a veteran, or a voyager.

VladimirNov2010A voyager sees CALENDAR as a deadline for departure. This is a part of MPE that was designed in the 1970s, a period when HP had just scrapped a 32-bit release of the 3000's first OS. And just like the Y2K date design, HP engineers never figured their server's OS had any shot of working by the 21st Century -- let alone 2027. But VEsoft's Vladimir Volokh says, "It's difficult to predict anything, especially the future." An IT pro who's planning to depart the 3000 believes CALENDAR is a bug, but that's not how Vladimir sees it.

"This is not a bug, really," he said. "It's a limitation. The end of 2027 date was as far away as infinity when MPE was created." This is a man who defines the term veteran, the kind of professionals who had to work inside 4K memory spaces to build 3000 programs. Limited and expensive resources like memory and disc were supposed to be extended with newer computers. "Every analyst told us a computer would live five years, at most," Vladimir said.

But as a veteran, you've now come to see the day when MPE's lifespan is reaching eight times that prediction. The veteran who chooses to see CALENDAR as a limitation can refer to HP's own lab response. Engineers during the '90s built HPCALENDAR to start extending the 3000's date limits.

The HP 3000's date intrinsics will outlast those in Unix, so long as a program uses HPCALENDAR. HP advised its 3000 customers in 2008 to begin using it on HP 3000s. HPCALENDAR harks back to version 5.5 of MPE/iX. Its power lies in the 3000 for use by programmers who want accurate dates beyond 2038 (the limit in Unix) for application files.

Lifting the limits in application date handling -- that's one level of engineering skill. Extending the operating system limits beyond the 16-bit CALENDAR is a task with a greater challenge. It doesn't mean that it cannot be done. What matters is how healthy the 3000's best experts will be in 10 years or so. Vladimir says he'll be younger than 90 by then. Almost everyone in today's community will be even younger. And isn't 70 the new 60? It will matter when the 3000 needs the last set of bits to move from 16 to 32.

There's a old joke about software shortcomings being called features, rather than a bugs. Veterans learn to call them limitations and look for ways to overcome these aging designs. Everything is aging, even something as omnipresent at Windows XP. (Microsoft wants to end the life of that OS, used on more than 90 million computers, by 2014. Good luck with that.) XP is dying, the 3000 is dying. Well yes, says Vladimir. He tells his hundreds of customers who he visits, "We are all dying. But slowly."

Posted by Ron Seybold at 12:59 PM in Homesteading, MPE's Hidden Value, Your System's History | Permalink | Comments (0)

April 16, 2012

Migration racks up list of emulated tasks

Some HP 3000s which remain in service are using many MPE nuances to get their jobs accomplished. Each of these tasks needs to be emulated in a migration away from the server. Even as companies embark on migrations to reduce risks, the list of tasks that they hope to replicate from their in-house apps can be surprising.

Such is the case at MM Fab, a fabric manufacturer in LA's South Bay Area. The 3000 shop is now taking its first year of steps off the system, developed and managed by Dave Powell. He shared a list of the things that an emulator must do if it were to succeed at replacing HP's 3000 hardware at his shop. The list also serves as a extensive catalog of the capabilites required of any new operating environment.

"We are thinking about migrating," Powell shared, months before the decision was made. "Which means we have to think about the choice between buying a package vs some form of emulation. Which means I could use some assurance that the [3000 hardware] emulation tools out there would actually work for us."

I can't afford to take this for granted because our system uses some rare features and does unusual things. Lots of them. Example: we do lots of tricky escape-code screen handling (mostly for point-and-shoot, drill down inquiries) that breaks some terminal emulators. Reflection 10.0 works, as does Minisoft WS92 v5.4 and actual terminals from 262x on, but last I checked, Minisoft Secure92 fails big-time. Not trying to make Minisoft look bad, but I need to make the point that software that works elsewhere may not work for us.

"We never cared about portabililty," Powell said, "because we never had any intention of moving to any other platform." From such situations are customers made for the Stromasys virtualization engine. If you're uncertain of whether you're using any MPE nuances in your application, it's a good strategy to get an evaluation of what's in production use today. Even if you're not migrating.

Powell said he doesn't think terminal emulation will be a big migration issue. In an emulation, "I think we could just keep on using the two products that work -- I just need to emphasize that we are off the beaten track, feature-wise."

Since there won't be as much room for all the details of MM Fab's custom-code tricks in our printed edition, we thought we'd put them on display here. This list might be useful to let you see if any of this is working inside your in-house apps. For the record, Stromasys says that anything that's working on MPE today will work in its emulator. The only exceptions they've found were HP's internals diagnotics, like SHOWCLOCKS.

A new platform/replacement app would have to embrace the top-level abilities in Powell's custom-code list. It's the kind of situation that makes some 3000 customers a poor fit for a migration, because these nuances were built over more than 20 years of IT budgets. A migration or replacement would address these all at once -- a cost structure that many 3000 shops cannot endure today.

Powell's MPE magic:

Job queues with separate job limits.

Smart :pause command (wait up to 'x' seconds for that job to log off).

MPE functions like finfo and jinfo.

User functions. Some of them are extra date / calendar routines beyond the built-in ones, like "how many days till end-of-month?" or "how many work-days in the next 'n' days?" and "how many months old is this file?"

MPE variables. User variables plus system variables like hpdatetime, hpaccount, hpfile, hpcpusecs, hpjobcount, hpstreamedby.

Message files / circular files / temp files, including temp message files and temp circular files.

Lots of command files, with tricks like with multiple entry points, input or output or both redirected to files, etc. Command files that use :echo to build a job (in a temp file) which they then stream. (I always wanted a way to have UDCs/command-files run offline, or feed parms into a job like UDCs do, so I finally rolled my own).

Jobs that use :echo or :print to build command-file subroutines (also in temp files), which they can then call lots of times with different parms, like running the same program over and over with one cmd-file parm becoming the info that is passed to the program to tell it what to report, another parm becoming part of the file name where it stores the report output, and another parm telling it who to email the report to.

Lots of do-it-yourself logging, with overglorified :echo to circular files, so I don't need to worry about the logs getting too big.

VPlus, with heavy use of vchangefield in newer apps, and family-of-forms in older ones, both to dynamically make some fields inputable and others display-only, changing the display enhancements so users can see which is which.

Creative escape codes in vplus apps to do things that VPlus didn't do as nicely as we wanted, mostly setting function-key labels and screen-printing.

Lots of escape sequences in non-VPlus terminal IO, mostly in character mode.

Extra terminal control features like turning echo on and off, time-out reads, etc. (Hint: escape codes that cause the terminal to send data back to the computer may work most of the time, but don't get solid unless echo is off. Even so, if something goes wrong you don't want the computer to wait forever for an answer).

Lots of env-files for both lasers and old impact printers, mostly changing orientation, print-size and lines per inch so the same report can print on either type of printer. Some reports have a run-time way to tell them how many lines per page, so by coordinating that with env-files I can have a report that normally does 132-column 60 lines do really-small-print portrait mode 124 lines per page on a laser. Also some tray-selection in env-files.

Do-it-yourself fancy laser-printed invoices with legalese in very-tiny print, company name in big print, etc. No special forms package here, just me spending quality time with the PCL documentation.

Converting simple report output to PC-readable format. That's a one-liner on our 3000 with my HP2RTF command file. The new system doesn't have to use RTF, but it does have support a common PC-readable format, has to preserve/translate HP-style line-spacing and page-breaks, and has to support changing print-size and line spacing so the PC file will look normal on screen and printed page. And it has to be easy to invoke in batch.

Email reports. This is also a one-liner here, thanks to a set of command-files I have wrapped around a nifty mail program originally from Telamon. The command files provide logging, improved error-checking, distribution lists, and even automatic retries at gradually-increasing intervals if there is an internet connection problem. I would like to keep that functionality. If possible I'd like to keep the outer layers of my command files, wrapped around whatever mail-sending pgm exists on a new system.

Mass file rename/delete/print/email, with ability to select by date, file age, file size, etc. Some use MPEX, others use my own routines (listf into a file, read it back, maybe call finfo).

IMAGE b-tree dbfinds.

COBOL macros. Intrinsics like command. Any and every HP extension that ever seemed helpful over the last 30 years.

Posted by Ron Seybold at 04:37 PM in Migration, MPE's Hidden Value, Users & Reports | Permalink | Comments (2)

April 11, 2012

Changing IP Addresses for HP 3000s

I need to change the IP address of our HP 3000 in the near future, and it's been over 10 years since I've done anything like this. Here's what I think needs to be done:

NMMGR
Open Config
NS
Guided Config
Put in the network interface, (LAN1), then press Config Network
Enter the new IP address
Save Data
Validate

Tracy Johnson replies:

I would go with Unguided Config. Guided may change things (besides the IP address) to defaults that may have modified over the last 10 years.

Craig Lalley adds:

Depending on the old IP address and the new IP address, you may want to also change the subnet, and the gateway. The gateway can be accessed by hitting F4 for Internet. The gateway is found at the path NETXPORT.NI.LAN.INTERNET

If you are making the change because of a new switch/router, make sure the network guys configure the port for the HP 3000 correctly. In other words, if you have a 100MB card, make sure it is set to 100MB/full duplex and do the same on the HP 3000, and turn off auto negotiate.

Lalley noted that this kind of reconfiguration goes smoother when a manager takes the time to check the network timing settings. Those are available at the path NETXPORT.GPROT.TCP.

Independent IT consultant Al Nizzardini adds that creating a new System Load Tape is an important part of the process. Gilles Schipper of indie support company GSA also explained a key step.

After making the change via NMMGR and validating both netexport and DTS, you need to:

netcontrol net=lan1;update=internet

to actually effect the change

Posted by Ron Seybold at 04:31 PM in Homesteading, MPE's Hidden Value, Users & Reports | Permalink | Comments (1)

April 05, 2012

Migrating Data for Extended Homesteading

Update: Added advice from Brian Edminster on using Jeff Vance's free UDC, UDCVOL.

The redoubtable 3000-L mailing list still boasts more than 600 readers, and more than 100 of them answer questions about 3000 operations. The discussion helps homesteaders, or those who are making moves to extend the life of 3000s.

Or replace them with other 3000s. A reseller recently asked for help on data migration of the homestead variety. He got instructions useful for anyone populating a fresh disc with production data.

I'm using MPE/iX 6.5 on a 9x7 3000, and trying to move data from a system volume set to a private volume set. I made a full backup and have created a private volume set, but I'm having problems restoring my data to the private volume set.

Craig Lalley of EchoTech replied:

You need to build the accounts and groups on the private volume before the restore. On the old system, run BULDACCT like this

acct_list%VSACCT=user_set

Purge the old accounts, then STREAM BULDJOB1. This will build the "buckets," the accounts/groups on the private volume. Then do the restore.

Brian Edminster of Applied Technologies took note of a free program to control volume operations.

An even better idea is to use Jeff Vance's Volume Mgmt UDC's, available at the OpenMPE 'JAZZ' page. It's a step up from doing it manually, because you can set up a config file that will automagically put accounts/groups on the proper volumes. I use this on all my systems, and for all my clients that have non-system volumes. (Basically, anybody with a system big enough to have more than one disk)

Purging that old account was part of several replies to the question. Keven Miller of 3K Ranger said, "You can avoid doing the NEWACCT,NEWGROUP,ALT... yourself by using the ;CREATE and ;VOLSET=p-volume  on the restore. But you will likely want to purge the old account first."

Tracy Johnson of Measurement Specialties said that the concept for the migration is "to make duplicate accounts with NEWACCT on the new volume set with the ONVS parameter, as well as any NEWGROUP commands you may need. Once done, you need to ALTGROUP the groups with the HOMEVS parameter. A pair of job streams can be created with the BULDACCT command. And purging the old data is a good idea. Otherwise you end up with phantom disc space usage."

Posted by Ron Seybold at 12:20 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

March 28, 2012

Making An HP 3000 More Secure

The Internet includes a wealth of advice, but it also harbors guidelines for IT malice. Not long ago the HP 3000 mailing list and newsgroup included a message that pointed to a pair of documents about hacking into the HP 3000. One expert in the system said these were dated, but still effective.

There's always been a lot in MPE that makes your servers more secure, of course, plus independent software to bolt its doors shut. (Security/3000 from VEsoft comes to mind. User Robert Mills says that "it is well worth the cost and time involved in setting up.") Even MPE's included passwords and permissions usage might be in the dim recesses of your memory, however. Consultant Michael Anderson of J3K Solutions supplied some refresher material.

An easy way into a MPE box is when the default passwords are left unchanged, like the TELESUP account and a few more third-party accounts that are well known. Securing your HP 3000 is simple.

1. Set unique passwords on all user/accounts, and maybe even groups.

2. Use PASSEXEMPT to avoid keeping passwords in job streams, enabling you to change passwords frequently.

3. Make sure ACCESS= & CAPABILTIES are set properly to avoid the use of the RELEASE command.

4. Programatically audit, audit, and then audit some more!

When anyone does log on, there are more options as well.

Write a simple script/program to check the remote IP address at logon, and if it is from the outside you can add additional security requirements, keep a table of allowed addresses, log these events, track outside sessions more rigorously, or simply not allow it.

I don't have my HP 3000 plugged directly into the Internet. However, if it wasn't behind a firewall, I believe it would take the beating and keep on ticking.

I've configured my firewall to forward all telnet traffic to the HP 3000 directly, and I do see attempts to hack it everyday. But none are successful. On the other hand, I've had my Unix and Linux machines hacked, using buffer-overflows and brute force attacks, several times.

Posted by Ron Seybold at 11:23 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

March 12, 2012

Set your 3000 clocks all the time

It's not too late this morning, even if it seems like it when you look at your watch on the first Monday after the time change. There's still time to get your HP 3000 clock set accurately. Last Friday the community was trading tips and technique about how to get on time. Donna Hofmeister, whose firm Allegro Consultants hosts the free nettime utility, explains how time checks on a regular basis keep your clocks, well, regular.

This Sunday when using SETCLOCK to set the time ahead one hour, should the timezone be advanced one hour as well?

The cure is to run a clock setting job every Sunday and not go running about twice a year. You'll gain the benefit of regular scheduling and a mostly time-sync'd system.

In step a-1 of the job supplied below you'll find the following line:

    !/NTP/CURRENT/bin/ntpdate "-B timesrv.someplace.com"

Clearly, this needs to be changed.

If for some dreadful reason you're not running NTP, you might want to check out 'nettime'. And while you're there, pick up a copy of 'bigdirs' and run it -- please!

Also, this job depends on the variable TZ being set -- which is easily done in your system logon udc:

    SETVAR TZ "PST8PDT"

Adapt as needed. And don't forget -- if your tztab file is out of date, just grab a copy from another system. It's just a file.

This job below was adapted from logic developed by Paul Christidis:

 !JOB SETTIME,MANAGER.SYS;OUTCLASS=,5
!TELLOP       SETTIME  
!TELLOP       ALL MPE SYSTEMS
!TELLOP ==SETTIME -- SYNCs SYSTEM CLOCK W/ TIME SERVER !
!# from the help text for setclock....
!# Results of the Time Zone Form
!#
!#   If the change in time zone is to a later time (a change to Daylight
!#   Savings Time or an "Eastern" geographic movement), both local time
!#   and the time zone offset are changed immediately.
!#
!#   The effect is that users of local system time will see an immediate
!#   jump forward to the new time zone, while users of Universal Time
!#   will see no change.
!#
!#   If the change in time zone is to an earlier time (a change from
!#   Daylight Savings to Standard Time or a "Western" geographic
!#   movement), the time zone offset is changed immediately.  Then the
!#   local time slows down until the system time corresponds to the
!#   time in the new time zone.
!#
!#   The effect is that users of local system time will see a gradual
!#   slowdown to match the new time zone, while users of Universal Time
!#   will see an immediate forward jump, then a slowdown until the
!#   system time again matches "real" Universal Time.
!#
!#   This method of changing time zones ensures that no out-of-sequence
!#   time stamps will occur either in local time or in Universal Time.
!#
!showclock
!showjob job=@j
!TELLOP =====================================  SETTIME   A-1
!
!errclear
!continue
!/NTP/CURRENT/bin/ntpdate "-B timesrv.someplace.com"
!if hpcierr <> 0
!  echo hpcierr !hpcierr (!hpcierrmsg)
!  showvar
!  tellop NTPDATE problem
!endif
!
!tellop SETTIME -- Pausing for time adjustment to complete....
!pause 60
!
!TELLOP =====================================  SETTIME   B-1
!showclock
!
!setvar FallPoint &
!   (hpyyyy<=2006 AND (hpmonth = 10 AND hpdate > 24)) OR &
!   (hpyyyy>=2007 AND (hpmonth = 11 AND hpdate < 8))
!
!setvar SpringPoint &
!   (hpyyyy<=2006 AND (hpmonth =  4 AND hpdate< 8)) OR &
!   (hpyyyy>=2007 AND (hpmonth =  3 AND (hpdate > 7 AND hpdate < 15)))
!
!# TZ should always be found
! if hpday = 1
!    if SpringPoint
!# switch to daylight savings time
!      setvar _tz_offset   ![rht(lft(TZ,4),1)]-1
!      setclock timezone=w![_tz_offset]:00
!    elseif FallPoint
!# switch to standard time
!      setvar _tz_offset   ![rht(lft(TZ,4),1)]
!      setclock timezone=w![_tz_offset]:00
!    endif
!  endif
!endif
!
!TELLOP =====================================  SETTIME   C-1
!
!showclock
!EOJ

Mark Ranft of 3k Pro added some experience with international clocks on the 3000.

If international time conversion is important to you, there are two additional things to do.

1) Set a system-wide UDC to set the TZ variable. (And perhaps account UDCs if accounts are for different locations)

:showvar tz
TZ = CST6CDT

2) There is also a tztab.lib.sys that needs to be updated when countries change when or if they do DST.

:l tztab.lib.sys
ACCOUNT=  SYS         GROUP=  LIB    

FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                 SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX

TZTAB            1276B  VA         681        681   1       96  1  8


:print tztab.lib
# @(#) HP C/iX Library A.75.03  2008-02-26

# Mitteleuropaeische Zeit, Mitteleuropaeische Sommerzeit
MEZ-1MESZ
0 3 25-31 3  1983-2038 0   MESZ-2
0 2 24-30 9  1983-1995 0   MEZ-1
0 2 25-31 10 1996-2038 0   MEZ-1

# Middle European Time, Middle European Time Daylight Savings Time
<< snipped >>

Posted by Ron Seybold at 09:37 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

March 09, 2012

Some 3000 time services labor to serve

ClockforwardEditor's Note: Daylight Saving Time takes hold this weekend in most of the world. The 2AM changeover can give a 3000 manager a reason to look at how the server manages timekeeping, including the potential for the open source tool ported to the 3000, XNTP. Our Homesteading Editor Gilles Schipper is working on an article to address some of the laborious steps needed to utilize it. His research took him to a few experts in networking and open source over the Web, Chris Bartram (our first webmaster, and creator of the DeskLink and NetMail apps) and Brian Edminster (operator of the MPE-OpenSource.org website.)

Chris: As I recall, ntp services never worked well on the 3000. It won’t work at all as a server for other clients, I believe. And as a client it seemed a waste; my vague memory says it had issues because you couldn’t set the time with the resolution it wanted. It ended up oscillating.
 
There’s a very simple standalone NTP client, ntpdate, though that you can run from the command line -- that’s what I use on my systems. I simply run it a couple times a day – it pulls the time from whatever NTP server you point it at and sets your local clock. We even shipped a copy with every NetMail tape. Look for ntpdate.sys.threek if you have a NetMail/3000 or DeskLink equipped system available.

Brian: The latest version of XNTP was the 4.1.0 version hosted on Jazz, and ported by Mark Bixby. It includes both ntp client and server functionality. Through the magic of the 'Wayback Machine' there's a link to HP's install instructions and other resources. The bad news is that HP put the actual download link behind a 'freeware agreement' page - and that download link wasn't wasn't saved by the Wayback.  Some community members who 'archived' Jazz that might have that download package.

However, there is an earlier v3.5.90 version from October 2008 hosted on Mark Bixby's site -- and although Mark's took site down after his departure from HP, the 'Wayback Machine' comes to the rescue with a downloadable install file.

This Bixby website archive has Mark's excellent install instructions, and it well documents the 'time update granularity' issue that the XNTP client has on MPE/iX. In short, it can cause the time to drift if left running continuously -- where it's trying desperately to update the time, but cannot do it to its satisfaction due to the precision it expects to be able to use.

The workaround for xntp is to run it periodically, perhaps daily, for a single update. Mark wrote about this on his xntp page, and even put in a SR with HP to get the underlying MPE/iX internal issue fixed.  And no, it didn't get done in time.

Edminster noted two other server time-sync tools (both ntp clients):

nettime -- a program created Brian Abernathy of HP.  Source and binaries are included, and can be found on Speedware's Jazz page. Note: this program has the name of the time server 'hard-coded' as 'time-server'. But since source is included, it can be changed and recompiled with HP's C compiler for MPE/iX.

timesync -- a 'client only' solution from the folks from Telamon, Inc. It's a binary-only distribution, but it works quite well, and apparently was designed to work with their network engines too. I have a copy of this and can email it to users and managers as a Store to Disk file.  It's the simplest way I've found to get time synchronization for your 3000s. It's literally just a 'restore and run', and has a 'preview but not do' mode to ensure you've got it configured correctly.

Posted by Ron Seybold at 02:19 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

March 08, 2012

This weekend, it's all about 3000 timing

Time-changeEditor's Note: Daylight Saving Time begins at 2AM local time around most of the world this weekend. A lot of HP 3000s run around the clock to serve companies, so a plan to keep the 3000 on time is essential. The founder of the MPE-OpenSource.org, HP 3000 open source repository, Brian Edminster, offers a plan, experience and a sample jobstream to help get you through our semi-annual time change.

By Brian Edminster

Here's an important implementation note for anyone that wants to put up a 'time synchronization' client on their HP 3000: Do not use it to adjust for spring and fall time-changes!  Use a job that runs on the appropriate dates/times to do a 'setclock timezone=' command.  I have an example below that is a derivative work from something originally posted by Sam Knight of Jacksonville University, way back in April, 2004 on the 3000-L mailing list.

I've updated the job to be more readable, to account for a 'looping' effect that I found in the fall from running on a fast CPU, and to run at 2AM -- the 'official' time that time-changes apply. I have this job set to be intiated by 'SYSSTART.PUB.SYS' on server bootup, and then automatically reschedule itself each Sunday at 2AM.

I'd suggest doing whatever sort of time synchronization necessary before this runs each weekend - so the time corrections complete before this job runs.

Here's the spring and fall time change jobstream code. All are welcome to use, and modify for specific needs. Note that it's set up for the Eastern US time zone. (That's the TIMEZONE = W5:00 -- meaning the number of hours different than GMT -- and TIMEZONE = W4:00 lines.)  Modify these lines as necessary for your timezone.

!JOB TIMECHG,MANAGER/user-passwd.SYS/acct-passwd;hipri;PRI=CS;OUTCLASS=,1
!
!setvar Sunday,    1
!
!setvar March,     3
!setvar November, 11
!
!showclock
!if hpday = Sunday and &
!   hpmonth = November and &
!   hpdate < 8 then
!   comment (first Sunday of November)
!  SETCLOCK TIMEZONE = W5:00
!   TELLOP ********************************************
!   TELLOP Changing the system clock to STANDARD TIME.
!   TELLOP The clock will S L O W   D O W N  until
!   TELLOP we have fallen back one hour.
!   TELLOP ********************************************
!elseif hpday = Sunday and &
!       hpmonth = March and &
!       hpdate > 7 and hpdate < 15 then
!   comment (second Sunday of March)
!  SETCLOCK TIMEZONE = W4:00
!   TELLOP *********************************************
!   TELLOP Changing the system clock to DAYLIGHT SAVINGS
!   TELLOP TIME.  The clock jumped ahead one hour.
!   TELLOP *********************************************
!else
!   comment (no changes today!)
!   TELLOP *********************************************
!   TELLOP No Standard/Daylight Savings Time Chgs Req'd
!   TELLOP *********************************************
!endif
!
!comment - to avoid 'looping' on fast CPU's pause long enough for
!comment - local clock time to be > 2:00a, even in fall...
!while hphour = 2 and hpminute = 0
!   TELLOP Pausing 1 minute... waiting to pass 2am
!   TELLOP Current Date/Time: !HPDATEF - !HPTIMEF
!   showtime
!   pause 60
!endwhile
!
!stream timechg.jcl.sys;day=sunday;at=02:00
!showclock
!EOJ

Posted by Ron Seybold at 04:40 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (1)

February 21, 2012

Respect MPE spooler, even as you replace it

PrintspoolerMigration transitions have an unexpected byproduct: They make managers appreciate the goodness that HP bundled into MPE/iX and the 3000. The included spooler is a great example of functionality which has a extra cost to replace in a new environment. No, not even Unix can supply the same abilities -- and that's the word from one of the HP community's leading Unix gurus.

Bill Hassell spread the word about HP-UX treasures for years from his own consultancy. Now he's working for SourceDirect as a Senior Sysadmin expert and posting to the LinkedIn HP-UX group. A migration project just finishing up drew Hassell's notice, when the project's manager noted Unix tools weren't performing at enterprise levels. Hassell said HP-UX doesn't filter many print jobs.

MPE has an enterprise level print spooler, while HP-UX has very primitive printing subsystem. hpnp (HP Network Printing) is nothing but a network card (JetDirect) configuration program. The ability to control print queues is very basic, and there is almost nothing to monitor or log print activities similar to MPE. HP-UX does not have any print job filters except for some basic PCL escape sequences such as changing the ASCII character size.

While a migrating shop might now be appreciating the MPE spooler more, some of them need a solution to replicate the 3000's built-in level of printing control. One answer to the problem might lie in using a separate Linux server to spool, because Linux supports the classic Unix CUPS print software much better than HP-UX.

The above was Glen Kilpatrick's idea. He's a Senior Response Center Engineer at Hewlett-Packard. Like a good support resource, Kilpatrick was a realist in solving the "where's the Unix spooler?" problem.

The "native" HP-UX scheduler / spooler doesn't use (or work like) CUPS, so if you implement such then you'll definitely have an unsupported solution (by HP anyway). Perhaps you'd be better off doing "remote printing" (look for that choice in the HP-UX System Administration Manager) to a Linux box that can run CUPS.

This advice shovels in a whole new environment to address an HP-UX weakness, however. So there's another set of solutions available from independent resources -- third-party spooling software. These extra-cost products accomodate things like default font differences between print devices, control panels, orientation and more. Michael Anderson, the consultant just finishing up a 3000 to Unix migration, pointed out these problems that rose up during the migration.

My client hired a Unix guru (very experienced, someone I have lots of respect for) to set this up a year or more ago. They recreated all the old MPE printer LDEVs and CLASS names in CUPS, and decided on the "raw" print format so the application can send whatever binary commands to the printers. Now they have some complaints about the output not being consistent. My response was, "Absolutely! There were certain functions that the MPE spooler did for you at the device class/LDEV level, and you don't have that with CUPS on HP-UX."

Anderson has faith that learning more about CUPS will uncover a solution. "One plus for CUPS, it does make the applications more portable," he added.

There's one set of tasks can solve the problem without buying a commercial spooler for Unix, but you'll need experience with adding PCL codes and control of page layouts. Hassell explains:

Yes, [on HP-UX] it's the old, "Why doesn't Printer 2 print like Printer 3?" problem. So unlike the Mighty MPE system, where there is an interface to control prepends and postpends, in HP-UX you'll be editing the model.orig directory where each printer's script is located. It just ASMOS (A Simple Matter of Scripting). The good news is that you already have experience adding these PCL codes and you understand what it takes to control logical page layouts. The model.orig directory is located in /etc/lp/interface/model.orig

What Anderson needs to accomplish in his migration is the setup of multiple config environments for each printer, all to make "an HP-UX spooler send printer init/reset instructions to the printer, before and after the print job. In other words: one or more printer names, each configured differently, yet all point to the same device."

You won't get that for HP-UX without scripting, the experts are saying, or an external spooling server under Linux, or a third party indie spooler product. If you'd like to look over the discussion in real time and add questions, it's on the LinkedIn HP-UX group's webpage. The third party software list for Unix is long. ROC Software moved into this field more than six years ago, along with its support of Maestro job scheduling for the HP 3000. ROC's products for Unix are Rhapsody and EasySpooler, for multiple-server and single-server environments, respectively. Another spooler software vendor with 3000 experience is Holland House, which sells its Unispool product for environments including Unix.

3000 managers who want third party expertise to support a vast array of print devices are well served to look at ESPUL and PrintPath spooling software from veteran 3000 developer Rich Corn at RAC Consulting. Corn's the best at controlling spoolfiles for 3000s, and he takes networked printing to a new level with PrintPath. Plenty of 3000 sites never needed to know all that his work could do, however -- because that MPE spooler looks plenty robust compared to what's inside the Unix toolbox.

Posted by Ron Seybold at 12:34 PM in Homesteading, Migration, MPE's Hidden Value, Users & Reports | Permalink | Comments (0)

February 14, 2012

String some perls on a day for love

PerlheartThe HP 3000 has a healthy range of open source tools in its ecosystem. One of the best ways to begin looking at open source software opportunity is to visit the MPE Open Source website operated by Applied Technologies. If you're keeping a 3000 in vital service during the post-HP era, you might find perl a useful tool for interfacing with data via web access.

The 3000 community has chronicled and documented the use of this programming language, with the advice coming from some of the best pedigreed sources. Allegro Consultants has a tar-ball of the compiler available for download from Allegro's website. (You'll find many other useful papers and tools at that Allegro Papers and Books webpage, too.)

Bob Green of Robelle wrote a great primer on the use of perl in the MPE/iX environment. We were fortunate to be the first to publish Bob's paper, run in the 3000 NewsWire when Robelle Tech made a long-running column on our paper pages.

Although you might be dreaming up something to bring to your sweetie tonight, you could grab a little love for your 3000, too. Cast a string of perls starting with the downloads and advice. One of HP's best and brightest -- well, a former HP wizard -- has a detailed slide set on perl, too.

The official perl.org website has great instructions on Perl for MPE/iX installation and an update on the last revision to the language for the 3000. First ported by Ken Hirsch in 2000, the language was brought to the 5.9.3 release in 2006.

An extensive PowerPoint presentation on perl by the legendary porter Mark Bixby will deliver detailed insights on how to introduce perl to your programming mix. Bixby, who left HP to work for the 3000 software vendor QSS, brings the spirit of open source advocacy to his advice on how to use this foundational web tool.

As an example, Bixby notes that "it's now possible to write MPE applications that look like web browsers, to perform simple HTTP GET requests, or even complicated HTTP POST requests to fill out remote web forms." It's no box of Godiva, or even the classic blue box from Tiffany's, but perl might be something you love to use, to show that 3000 isn't a tired old minicomputer -- just a great sweetheart of a partner in your mission-critical work.

Posted by Ron Seybold at 11:07 AM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

January 20, 2012

Iconic Kodak product may fade to hobbyists

Zi8Eastman Kodak's filing for bankruptancy yesterday signaled a transformation for an iconic inventor. The leader in film for more than 100 years, Kodak faces a new future this morning, one that will be tied to printing success. The company's been given until February 2013 to produce a reorganization plan, and it will try to get the sale of $2 billion in imaging patents approved by June 30. But Kodak's breakthrough of film won't go away, not any more than an MPE/iX environment will disappear. For Kodak, the expectation is that film imaging will retreat to hobbyist and enthusiast markets.

Like MPE/iX, film photos will become the standard by which successors are judged. And what's possible is the same fate of vinyl recordings: a modest renaissance as lifelong digital picture-takers consider the advantages of older technology. The same thing will be happening to paper books in the future. Companies without a plan for these newer complimentary technologies will suffer. Most of the 3000's customers are using at least a Windows server somewhere in their enterprise.

Kodak's inventions in film and imaging have become its last stronghold, a redoubt the company fell upon while trying to sell off its patent portfolio. The stock was pounded again today, shares which were de-listed from the NYSE in a stunning reversal for a company of its age and reputation. But that reputation is what's likely to leave Kodak's products in a spot where they'll survive well. A later-era entry like the company's pocket video cameras (above) which included novel features like mic inputs might have the same kind of aftermarket that the 3000 has enjoyed. When you build it well to start, the value remains even after the vendor has fled.

As an example of one beloved product's aftermarket, consider the Stereo Realist community. These are the acolytes of stereo photography, the technology that rose in the '50s and '60s until prints took over for slide film. These days you'd call it 3D, but that was not the term my father used when he'd show off his stereo slides on the projector in our basement.

But the old portable stereo slide viewers remain in great demand. A product that was sold for under $50 when it was introduced now sells for $200. Even in constant currency that's a remarkable retention of value.

HP 3000 value, both in hardware and software, is important to your community. Some of the most specialized resources rely on the continued value of this business solution. Unlike Kodak, your happy dovecoat of settled, harmonious owners won't be turning to a highly competitive sales plan. Many suppliers have experienced a stall in growth when making that leap. We'd like to believe in the wake of the Kodak collapse that well-engineered products have a limitless lifespan. The 3000 still has enthusaists who know there's no substitute for the extra dimension of the server.

 

 

Posted by Ron Seybold at 04:15 PM in MPE's Hidden Value, Newsmakers | Permalink | Comments (0)

January 05, 2012

Good foundations support 3000 managers

Editor's note: Yesterday we got a call from a company which had read this "Worst Practices" column written in 1999 as if it were brand-new. Scott Hirsh, who's now leading the charge into cloud-based storage solutions at Nirvanix, wrote these columns for the NewsWire after his years of managing an HP 3000 operation for a capital management firm in San Francisco. It's robust advice for anybody new to managing a 3000, and the guidelines are still useful today. If you're inheriting 3000 management, or passing it along to someone younger and newer, account structures are still a great place to get things correct before anything else happens. He called this one "Shaky Foundation."

By Scott Hirsh

As we board the train on our trip through HP 3000 System Management Hell, our first stop, Worst Practice #1, must be Unplanned Account Structure. By account structure I am referring to the organization of accounts, groups, files and users. (To keep this discussion simple — and typical — I will discuss the standard MPE name space, not the Posix name space.) I maintain that the worst of the worst practices is the failure to design an account structure, then put it into practice and stick with it. If instead you wing it, as most system managers seem to do, you ensure more work for yourself now and in the future. In other words, you are trapped in System Management Hell.

What’s the big deal about account structure? The account structure is the foundation of your system, from a management perspective. Account structure touches on a multitude of critical issues: security, capacity planning, performance, and disaster recovery, to name a few. On an HP 3000, with all of two levels to work with (account and group), planning is even more important than in a hierarchical structure where the additional levels allow one to get away with being sloppy (although strictly speaking, not planning your Unix or Windows account structure will ultimately catch up with you, too). In other words, since we have less to work with on MPE, making the most of what we have is compelling.

As system managers, when not dozing off in staff meetings, the vast majority of our time is spent on account structure-related activities: ensuring that files are safely stored in their proper locations, accessible only to authorized users; ensuring there is enough space to accommodate existing file growth as well as the addition of new files; and occasionally, even today, file placement or disk fragmentation can become a performance issue, so we must take note of that.

In the unlikely event of a problem, we must know where everything is and be able to find backup copies if necessary. Periodically we are asked (perhaps with no advance notice) to accommodate new accounts, groups, users and applications. We must respond quickly, but not recklessly, as this collection of files under our management is now ominously referred to as a “corporate asset.”

You wouldn’t build a house without a design and plans, you wouldn’t build an application without some kind of specifications, so why do we HP 3000 system managers ignore the need for some kind of consistent logic to the way we organize our systems? A logical, adaptable, documented account structure is a huge time saver in many respects. As most of us now manage multiple systems, we have no time to waste chasing down lost files, working with convoluted file sets, struggling to keep access under control or reacting to full volume sets.

I once had a conversation with a co-worker who was an avid outdoorsman. He was discussing rock climbing and I asked him about exciting rock climbing experiences. His reply: “In rock climbing, anything exciting is bad.” I would say the same thing about system management. By getting your account structure under control, you build a solid system management foundation that translates into much more pleasant work.

If this were a “best practices” column, we would discuss the best ways to clean up your system’s account structure. But this is worst practices, so let’s look at the no-nos.

No naming standards, bad naming standards

Oscar Wilde once said, “Consistency is the last resort of the unimaginative.” Do you think he was referring to HP 3000 system management? If so, not much has changed since Oscar’s day.

• In one account the jobs are located in group JCL. In another account, group JOBS. The developers keep “special” jobs in a group you never heard of in the critical application account. And just to make things more interesting, all your so-called “production” jobs are kept in an account called JCL, containing all kinds of groups, including “TEMP.”

By having consistency across accounts I control, I can easily find what I need when I need it. If jobs are always in the same group across accounts, I can LISTF @.JOBS.@, etc. Backups/recoveries are easier, updates are easier, training new operators is easier. Sure, consistency is boring, but we must resist the lure of adrenaline.

• I’m going out on a limb here, but my guess is that your UDCs, the few you have left, are in a different place in every account. Why is that? And your system UDC (singular) is located in the SYS account, right? Because it’s the SYStem UDC, of course! Maybe it’s not such a bad thing to have another, non-SYS account for globally accessible files. What’s the catch? The system UDC file needs to be in the system volume set, for obvious reasons (learned that one the hard way).

• An MPE file name consists of a whopping maximum of eight characters. That should make every character count, right? So why do jobs that live in a group called JCL or an account called JCL all start with the letter J? File that under the department of redundancy department.

• We manage the systems, so we make the rules, right? Wrong. If we want the rules followed, if we want the best rules possible, we must get input and buy-in from all the others who will be expected to honor our rules. Ignoring users when it’s time to develop naming standards and other system policies is a classic Worst Practice, and a good way to ensure continued chaos. And don’t forget that upper management will need to be involved when a little “gentle” persuasion is required.

Trespassing in Vendor Accounts

What is it about the SYS account that system managers can’t resist? Here’s a hint: it belongs to HP. I know it’s tempting to park files here, like any PUB group, because it’s so… public. The people’s account! A good place to put files you want to share with everyone. Well, not really. There’s actually a tiny sign inside this account, barely visible. It says, “This account subject to change without notice.” It’s bad enough that third-party software vendors litter this account with install programs. Don’t pile on.

• Your third-party accounts are also hands off. Consider them the exception to all the rules you lay down on what goes where and what it’s called. In fact, it’s a worst practice to try and reorganize a third-party software account.

Account structure-driven security

MPE security is more flexible than it once was, with the ability now to save across accounts, plus all the new Posix tricks. But I think it pays to stick with the old rules, many of which were described by VESOFT’s Eugene Volokh in his book, “Thoughts and Discourses on HP 3000 Software.” [Ed. note: we have copies of this book available at the NewsWire. Contact us to get yours.] Because all the action is at the group level, leaving the account level at ANY access is one less thing to worry about. So once again, the way we organize our account structure is going to weigh heavily on system security.

• “We haven’t had a problem in 15 years, so don’t worry about system security.” (I have actually been told this). No problem, but do you leave your car unlocked in front of your house? Do you leave your front door unlocked at night? Why not? As they say in the investing business: Past performance is no guarantee of future results. This argument usually boils down to “I’ve been getting away with murder for 15 years; don’t start messing with me now.”

• The SYS account belongs to HP. So why hang out in there? You’re just going to trash the place and you know it (especially if you’re a guy). Why not set yourself up in your own account, where you can do your system manager thing with impunity?

• And while we’re at it, stop the insanity and take SM away from your users. “But we must have it!” they’ll say, while threatening the end of the world as we know it. Perhaps if we straighten out the account structure and apply proper file access, everything will work out after all. One world, one sky, one user with SM capability.

• But let’s not stop there: Hey, you! No developers messing around in production accounts! Do your thing on the development box or in the development account, then operations will move in the addition/change/fix (with change control software, of course). We’re trying to run a business around here.

• If everyone logs on as a generic user (e.g., ENTRY), then all files created by that user will have the same ownership. Not the worst practice in the world, but we need to be aware of that when it comes time to do some spring cleaning. Sure, security programs allow you to distinguish for security purposes (by session prefix) one generic user from another. But that’s only half the story. Having many files created by user ENTRY will make it more difficult to weed out the dead soldiers later on. And if you need to debug a problem, determining which log file was created by which ENTRY user will be a time-consuming chore.

Nice guys finish last

There’s nothing wrong with being a control freak if you’re ultimately held responsible for areas ostensibly under your control. In other words, don’t blame me for being uptight about disk space if you’re quick to scream at me when your volume set runs out of space. We all want to be liked, but sometimes the system management truth hurts.

• The only way I know of — without third-party software, anyway — to keep track of connect time and disk space is at the group level, as provided by the REPORT command. So doesn’t it make sense to try to work with that limitation? I’m assuming you check at least once per year for users who have zero connect time. And I know you care about how much disk space everyone is using. So unless you can somehow restrict your users to certain groups for logon purposes and disk space purposes, you will have trouble controlling disk space by user — and you will be unable to easily determine which users should be removed for inactivity.

• Another obvious tie-in to account structure is volume sets. Groups reside on volume sets, not accounts, so the way you organize your groups correlates to your efforts to manage disk space at the volume set level. The good news is that system managers seem to be aware of the UDCs for managing accounts and groups (NEWACCT, NEWGROUP), which makes assigning and enforcing volume set standards much easier.

Final Rants

A best practice says “do this,” a worst practice, “don’t do this.” So don’t put off your initiative to get your account structure under control. Don’t be a system management slob. Kick the adrenaline habit and give yourself a break.

Work with everyone who has the potential to undermine your efforts toward system management. Reach consensus on what groups you should have for jobs, executables, UDCs, etc. Collectively decide on a naming convention for accounts, groups, files and users. Have everyone sign off, and get upper management to agree to enforce these standards (on penalty of death, if possible). Document everything, and monitor for compliance. Don’t backslide.

In summary, don’t be afraid to be consistent, don’t be afraid to be boring. In system management, boring is good.

Posted by Ron Seybold at 11:52 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

October 28, 2011

Emulator query sparks private volume tip

In an example of the newest HP 3000 technology linking to one of the server's oldest, one question about a 2012 product unearthed advice about a feature introducted in 1978. Next year's HPA/3000 emulator received some upgrades to its SCSI periperals support this week, according to the product's vendor Stromasys. These improvements will make it possible to better answer a question about private MPE/iX volumes, and how well HPA/3000 can handle them.

BuiltToLastCraig Lalley, working with Stromasys on the MPE/iX aspects of HPA/3000, said he hasn't tested private volumes yet, "due to an issue with the SCSI interface. But I intend to." At the same time, a question about private volumes' use in the current era prompted some advice from Applied Technologies' Brian Edminster -- who had to miss the Reunion briefing on HPA/3000 due to pressing work to open up the new MPE open source website, MPE-OpenSource.org. (You can track updates to the project through its RSS feed, which can be viewed in Google's RSS Reader, among others.)

The first package Edminster added to site was SFTP quick-start, a bundle "which aims to make installing SFTP easier on MPE/iX systems. It is a std file which includes all the components necessary to install and configure sftp, scp, and keygen under MPE/iX, with links to instructions for the installation process."

Edminster is well-versed in the non-open-source tools for the HP 3000 as well. When Dave Powell of MMFab asked during a HPA/3000 discussion if anyone was even using private volumes on an A400 Class of server, Edminster advised that the 3000 sites where he administers or consults are employing this bedrock MPE tool -- one first introduced 34 years ago in MPE III, on the Series III.

I've always considered it a best practice to divide your disk storage up into several Private Volumes. Why?  When a non-mirrored spindle in a PV dies, it only takes that PV out with it -- allowing the rest of the machine to keep running (unless the PV is the mpe_system_volume_set, in which case you're going to be doing a system install).  If it's only one of the data volumes that goes down, the 'system' is still up, greatly facilitating recovery.

Data volume protection has always been at the heart of MPE's private volumes.

If you can't afford arrays that protect the 'system' volume-set, at least you can get something (even if it's only HP's subsystem software Mirror/iX for RAID-1) to protect the data volumes. And if you configure it properly,  RAID-1 is wicked-fast on reads, and pretty decent on writes.

Oh, and to answer your original question:  Yes, A400s can be set up this way.  At least, the ones I administer are set up this way. The drives inside the CPU chassis are set up as "system volume set," and an external mirrored array is the "data' volume.

Works great. If the system volume goes down, data isn't likely affected. If a mirrored drive fails, just swap it for a replacement. This has gotten my client near 100 percent up-time for this system, for almost 10 years now.

Posted by Ron Seybold at 06:14 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

August 23, 2011

Zipping Files on Today's HP 3000s

Although the code for compressing files on HP 3000s is more than a decade old, like a lot of things on the system, it continues to work as expected. A customer recently asked how to Zip and Unzip files to move things between the HP 3000 and other servers.

Tracy Johnson, who manages the Invent3K server operated by OpenMPE, noted he's using the MPE/iX Posix shell's compress and uncompress. "It creates a file that ends in capital Z. Seems the compressed format is compatible with both GNU-zip and Winzip programs or any other *nix machine."

Lars Appel, who ported the Samba file sharing tool to MPE, offers a comprehensive answer. He points to software that resides on his own development server, open to the public.

You can pick up the InfoIP zip/unzip programs (in a tar file) at www.editcorp.com/personal/lars_appel/WebKit2 The link in that webpage that contains the zip/unzip programs is

E:\WebKit2\upload\infozip.tar.Z

Transfer it to the 3000 in bytestream or (fixed) binary format and then unpack with :/bin/tar "-xvzopf FILENAME". Place the two programs where you like; I typically have them in /usr/local/bin or (with uppercase filename) in a group or directory that is part of my HPPATH settings.

The web page also contains a tar.Z file with /usr/local/bin/gzip

E:\WebKit2\upload\gnuzip.tar.Z

(gzip -d decompresses; creating a symbolic link gunzip is also useful)

 

Posted by Ron Seybold at 12:21 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

August 04, 2011

Old veteran console tricks for PCs

Got a wheezing PC someplace in your IT shop? Believe it or not, even the creakiest of desktops can still serve your HP 3000: as a console, a la the HP700/92 variety. This is the kind of PC where, as one veteran puts it,"the keyboards have turned to glue."

...Trying to type a coherent instruction (or even worse, trying to talk someone through that task remotely) where random keys require the application of a sledgehammer to make them respond, at which point they auto repeatttttttttttttttt.

It's enough to give a veteran manager a pain in the posterior, but hey -- some HP 3000s (of the 900 Series) demand a physical console as part of their configuration. Can't you just hook up such an antique PC straight to the 3000's special console port and let it work as a console? Yes, you can.

Overheard among chatter between 3000 vets:

You can connect a PC via its serial port to the console port on the HP3000, and then run a terminal emulator via the serial connection, leaving it logged on as the console. That way, using free remote control software (VNC Free) on the PC, you could even have control of the physical console (as opposed to just taking the virtual console) so that things like Control-A/B would work.

You'll need a little physical cabling help to make this work. Even though those desktop PCs are old, most of them have not had serial ports in many years. Think about it. It's all USB by now. So you buy a USB-to-serial converter. You'll need a copy of a HP 3000 terminal emulator on the PC configured to connect via the serial port.

Just make sure the PC stays up and the emulator's window is open and connected. You don't need the console buffer filling up.

Posted by Ron Seybold at 09:08 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

July 29, 2011

A Full Day of Free 3000 Networking Advice

In a flurry of under 24 hours, six HP 3000 veterans chipped in advice this week to help a 3000 manager who's weathering poor network response times. All of the consulting was free, offered though the 3000's ultimate community resource, the HP3000-L mailing list and newsgroup.

Kevin Smeltzer, an IT Specialist in MPE Systems at IBM's Global Services group, said he was watching his development N-Class responses slip into unusable measurements. "Today was so bad that test programs could not stay connected to a Quick program," he reported at 4 PM yesterday. "Linkcontrol only shows an issue with Recv dropped: addr on one path. This is a known issue with some enterprise network monitoring software that sends a packet that the HP 3000 cannot handle. Even HP last year had no solutions for that issue."

Donna Hoffmeister, Craig Lalley, Mark Ranft, Tony Summers, Mark Landin and Jeff Kell all came to Smeltzer's aid in less than 24 hours. Hoffmeister, Lalley and Ranft work support and consulting businesses, but nobody wanted to collect any fee. Summers and Landin chimed in from veteran 3000 manager status. And Kell, well, he founded the 3000-L, and headed the System Manager's special interest group for years. Like the others, he's steeped in the nuances of HP 3000 networking.

So long as the 3000-L is running, no one has run out of places to ask for this kind of help. There has been a thread of 16 messages so far, back and forth emails with long dumps of NETTOOL reports, examinations of TCP timer settings (Hoffmeister wrote an article for Allegro about this on its website), and discussion of switch port settings. "Do I need to shutdown and restart JINETD or restart the network," Smeltzer asked this morning, "to have my TCP changes in NMMGR take effect?"

The point here is not the solution to Smeltzer's problem -- still developing today -- but the careful exam he was getting from fellow managers about his 3000's condition. "I still have not heard from my network admin," he said. "This will tell me if a network change happened and port/switch changed so that the HP 3000 connection is no longer set to 100BT. This is my best hope at this time."

Lalley ventured a guess after a close reading of Smeltzer's reports:

How are your gateways defined? If you change the gateway

NSCONTROL ;UPDATE=INTERNET

then you could try deleting the wrong gateway and see if it helps. I think you have a router broadcasting a wrong gateway.

Hoffmeister said the problems might be in the physical layer:

Did you change NMMGR before or after the reboot? If after, you're going to want to reboot again. Your packet loss is disturbing. I'd be suspicious of a physical layer problem.

Problems in the physical layer can be addressed by replacing parts, Mark Landin advised.

Could be a bad network cable or connector. Replace them.
Could be a bad network switch port. Connect the system to another port (properly configured, of course).
Could be a bad NIC. Swap them in the 3000 and see if the problem moves with the card.

Hoffmeister pointed back to the TCP timer issues.

On PCI (A- and N-Class) systems with 100bt cards, you're more likely to see 'recv dropped: addr' counts due to the way the card handles (or not, actually) traffic routed for a different destination.

Typically these counts are nothing to be concerned about. What is concerning are the TCP statistics.  Retransmits are almost always a function of using the default (or otherwise messed up) TCP timers. Let's just say I've never seen a case where it's not.

You get the idea. Smeltzer, who's competent enough to provide all the needed reports to the 3000 community, is getting HP Support Center-grade assistance. And free. Better assistance, even, since he noted about the enterprise packet problems of 2010, "Even HP had no solutions for that issue."

This is why when our email link to 3000-L went dead for a few days (thanks, ATT) we got online to set up an alternative delivery address. More than 110 message this month devoted to HP 3000 techniques. You can sign on for the free help at 3000-L, or just read the advice, at the mailing list website: http://raven.utc.edu/cgi-bin/WA.EXE?A0=HP3000-L The NewsWire would never have gotten off the ground without 3000-L's networking with the community. Make that network one of yours, too.

Posted by Ron Seybold at 08:27 PM in Homesteading, MPE's Hidden Value, Users & Reports | Permalink | Comments (0)

July 22, 2011

It's time to change your 3000 timers

Allegro Web logo Allegro Consultants has offered a new white paper that deals with an old and common issue of 3000 management: TCP timers. The support company's Donna Hoffmeister, who has posted a passel of tips about 3000 administration on the 3000 newsgroup, wrote A Discussion of MPE TCP Timers. These timers are a management subject every 3000 owner should discuss with their admin folks. They establish how quickly your system responds to network traffic calls.

These values control how a 3000 reacts in the event it needs to re-send (retransmit) a packet ("chunk") of data over a TCP/IP network. These values were established at least in the MPE V days (and possibly before that) – back when only big, important computers were trying to talk to each other. (Unlike today, when even your refrigerator thinks it needs to "yack it up" over the Internet!)

The important thing to understand about these values is that they are perfectly fine and do not need changing because they are never (or rarely) used on an optimally-performing network.  However, given that

1. These days, networks rarely perform optimally, and
2. HP Network Engineers described the above values as "way out of whack"

you should change your TCP values.

Hoffmeister's paper sets out the recommended values for the modern era. HP 3000s have been useful for so many decades that it's easy to overlook some of the fundamental assumptions at the heart of the MPE environment.

Allegro's president Steve Cooper reminded us that the new White Paper from his company is part of a collection of MPE and HP 3000 help at the firm's Papers and Books web page. Advice there includes repairs for aborts and hangs on HP3000s, and even a paper on HP-UX system panics. The company is committed to providing support for 3000s through at least 2016.

Posted by Ron Seybold at 01:29 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

July 14, 2011

Community considers upgrading essentials

Secure transfers of HP 3000 files, as well as the ability to compress and decompress them, remain projects in need of technical help. A Secure FTP functionality (SFTP) is still short of production-grade release by some managers. Using ZIP to squeeze and unsqueeze 3000 data requires a 14-year-old piece of software.

On the FTP front, a decent set of files and documents once was available on the Invent3K server which HP operated until 2008. Ken Hirsh did that work on OpenSSH, which is essential to making SFTP more useful on a 3000. But Invent3K operations and contents were transferred to OpenMPE recently. Hirsh doesn't have an active account on the new version of the server.

ZIP needs help as well. The current version of the industry default for compression has had several updates since 1997, but none have been ported to the HP 3000. Some managers at multi-3000 sites still use ZIP daily, and an upgrade (which by now would really be a port) will help compress and decompress files bigger than 2GB. That's how old the 3000's ZIP is today; IMAGE jumbo datasets to go beyond 4GB arrived in 1995.

System managers of the 3000s report they are willing to develop -- or pay an outside party -- to bring these industry standards in line with more modern verions. Independent developers, or the originators of the older ports, are available in the community to help, too.

ZIP was last ported to the 3000 by Neil Harvey & Associates, one of the seven holders of MPE/iX source code licenses. The most current version managers are seeking for ZIP is 3.2.2.

FTP issues are more complex, but there is also more on the table to use for the security that can satisfy auditors. Brian Edminster, the community's specialist in open source software for the 3000, said "SFTP clients are available for MPE/iX, and work fine on v7.5. You can contact me if you’d like to discuss how to get a copy of your own. I’ve had extensive experience with the SFTP client, and some with the SCP [network file transfer] client. Both work remarkably well, although there are some quirks it helps to be aware of."

Today's limitation on securing file transfers is that the 3000 must originate the transaction. Edminster explains that "This can make for some process redesigns if your existing applications are used to your 3000 being the server. And no, jinetd doesn’t need to be running for SCP or SFTP to work."

SCP needs OpenSSH on MPE/iX to perform its transfers, but only an initial port was done by Hirsh, who was doing the work for free. Edminster says the ported software runs on MPE/iX 7.0 and 7.5. The port included the ssh command line client, but it had very limited functionality, he added.

It also included the client components SFTP and SCP, as well as a random number generator written in Perl. This last piece is necessary because the random number functions under MPE/iX aren’t very random. At least, not as far as serious cryptography is concerned. This Perl script (modified by Ken to run on MPE) was originally written by others to get round not having a kernel based entropy source for their systems either. Poor quality random number generation is not just a MPE/iX issue.

The 'server' components (sshd, sftpd, and scpd) were never ported for reasons that Ken could possibly explain. It might have been something as simple as he didn’t need them. From my perspective, I’m thankful that Ken did the port in the first place. I have installed his OpenSSH port many times, and even tightly integrated it with legacy applications. SFTP is still in use many times a day with those applications, and since first installed several years go -- has safely and securely transferred terabytes of data, with no clear end-date for this application’s life.

Hewlett-Packard opened the door for this kind of community porting when it included much of the software required for creating an installable version of things like OpenSSH in MPE/iX. It should also be available from non-HP sources by now. That's an issue for OpenMPE to take up. At the moment these volunteers are hosting contributed 3000 software (the CSL) and charging access for development accounts on Invent3K. Locating and hosting the open source work is a mission the community could embrace.

Posted by Ron Seybold at 03:26 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (1)

June 27, 2011

Must-have firmware, patches for 7.5 install?

We have just started up a new A-class 2-way running 7.5 PP5. This system is configured with 4GB RAM, a VA7410 running off two PCI FC Host Bus Adapters, one DTC 16, and two SureStore DDS-2 tape drives running off the LVD SCSI interface. SUBSYS products consist of NS, COBOL, and FORTRAN. We do use FTP, incoming and outgoing. We will probably start using Sendmail for a few things (as an old Unix admin, I respect Sendmail, but do not fear it!) Our primary use for this system is MANMAN with around 170 users.

Our third party portfolio is the usual: Suprtool, MPEX, Minisoft ODBC, and Adager, plus some other odds and ends. So, for this kind of system, what are the “must have” patches that we should install on top of PP5?

After Gilles Schipper assured the manager that "PowerPatch 5 should be all you need," Jack Connor replied:

You may want to check the PDC firmware level. I believe the Fiber Channel patches found in 43.43 for the N class are in 43.50 for the A. You can see the PDC level at the boot menu.

Do you have an HP-UX or Windows box with Command View set up to monitor the VA? It's very advisable, as you can do a lot of drill down if you have problems and all can be remote to the system. Did you configure High Availability Fail Over (HAFO)? You may want to offload the CIO network interface card with a standalone 100Bt card and leave your DTC on the CIO.

Craig Lalley added:

Yes, MPE can do HAFO. What I do is configure all the odd LUNs down one path and all the even LUNs down the second path. Then SYSGEN IO HA , and then create the secondary path. It works on the VAs because all the LUNs are seen down both paths.

Lalley added that firmware will be an important part of configuring such a system.
Don't forget to put the correct firmware on the VA7410 controllers and disk. To update the firmware, CommandView is required.

The latest firmware bundle (that I know of) can be found at HP's Biz Support website http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=316166&prodTypeId=12169&prodSeriesId=89018&swLang=13&taskId=135&swEnvOID=54

HP's Jim Hawkins says that HAFO was built for the any SCSI disk device where a manager can see LUNs on more than one port. But HAFO really wasn't useable until Fiber Channel took off on the 3000s.

Original HAFO was with XP256 F/W SCSI, but that was a pretty clunky device even when it was “state of the art”. HAFO really didn’t become useable until FC. I lead the FC-based effort and we did all of our work on XP and then VA devices, because they were what worked at the time; those are the configurations that were officially supported, blessed, and used successfully by many customers.

We did evaluate EVA [storage] products and they did “work” as disks, but they didn’t have this “LUNs visible on more than one path” feature until way too late for lab development and certification. HAFO probably would work on EMC, though our co-development/marketing agreement with them had terminated by the time HAFO was developed. They did continue to advertise support for MPE/iX systems long after we stopped working with them.

Posted by Ron Seybold at 08:00 AM in Homesteading, MPE's Hidden Value, Users & Reports | Permalink | Comments (0)

June 15, 2011

N-Class price, storage advice points at value

While we were trolling our files for news about the HP 3000, we found a note about this year's cost of the N-Class HP 3000 servers. The ultimate HP 3000 ever built by the vendor, used as a spare parts unit or a hot backup for a production machine, sells for $3,000-$8,000 from one supplier. That's the price for a server that's got a pre-loaded version of MPE/iX, but the license is up to you to arrange. The $8,000 N-Class was listed as the most powerful (750 MhZ), sporting three processors.

On the other end of the useful 3000 power scale, the Series 927LX -- almost the smallest PA-RISC HP 3000 ever built by HP -- is still in use in the field. Chuck Trites asked this week if a DLT tape drive could be installed in this server that was designed in the early 1990s.

"This is not a problem as long as you have a free slot, or an open 28696A fast-wide card," says Jack Connor of Abtech. "I believe you need to be on MPE/iX 6.0 or 6.5 to go with a DLT8000. I'm sure a DLT4000 and probably a DLT7000 are okay." Larry Kaufman of legal firm Weltman, Weinberg and Reis reports that the 28696A IO card is easily obtained, a double-high interface device that permits the 927 to use HVD SCSI DLTs of 4000, 7000 or 8000 models.

HP 3000 managers trade this kind of configuration experience often, usually bolstered by independent support companies like Gilles Schipper's GSA. Schipper adds that some DLT4000s have a Single-Ended SCSI interface if that 927 doesn't have a spare full-height slot.

You might miss one point of this set of exchanges. At one end there's a 20-year-old server still working in a production setting. At the other end, the most powerful 3000s sold by HP are now less than $10,000, at least in a spare-parts or hot DR offering with your own licenses. There's value available for a server HP hasn't built in more than seven years, if you know where to ask for help.

Trites, who runs a consultancy that serves 3000 managers and sites, created a tape with a DLT4000. "What I need to do is restore the databases on the tape to my system for a project.  I only have a DDS drive, and don't know if it's worth trying to install a DLT drive or not." Mostly, that would depend on the price of the DLT SE-SCSI w

Other 3000 IO advice is being offered on balancing file allocations by duplicating a DISC class in SYSGEN. "I want to put an 18GB drive on LDEV 1 and a 9GB on LDEV 2: DISC twice on LDEV 1 would seem to be good to do this," says John Pitman. "I tried to do this in SYSGEN, but it said it was already there."

Schipper explains:

That used to be a good technique in the pre-MPE/iX and MPE/XL days. But it’s not necessary any longer. MPE will naturally choose whichever disc has the most free space for its file disc space allocation.

And there is also a special allowance for LDEV 1 to ensure it does not prematurely fill up. You can control some aspects of disc utilization via the permanent and transient percentages that can be manipulated via VOLUTIL.

Craig Lalley of EchoTech notes that the VOLUTIL commands are

ALTERVOL MPEXL_SYSTEM_VOLUME_SET:MEMBER  Perm#  Trans#

HP's own Jim Hawkins, a longtime engineer in the IO labs for the 3000, offered his insights on how MPE/iX uses its algorithm to balance the allocations.

I poked around in this code as part of the "Large Disk" patch set. The algorithm is based upon percentage full -- that is, we pick the disk in the set with lowest percent full. Note though this does have a disadvantage that if your volumes are very different sizes as you may bottleneck or serialize lots of IO to the larger disks.

 MPE does do better when disks are matched in size. Also, the original algorithms were designed when 4 GB was a really big disk, so were granular to 1/100. With one of the Large Disk patches, I think I made that 1/10000 -- otherwise you'd have to add 3GB of files to a 300GB disk before you'd move to the next volume.

Posted by Ron Seybold at 09:13 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

May 16, 2011

3000 gains new function via migration work

Keven Miller of 3kRanger is doing migration work for a customer, but his labors have delivered a new function for the 3000 namespace of the HP 3000. HP added many useful functions for the server after the Posix introduction of the mid-1990s. But since some programs don't run from the Posix namespace, Miller needed to make a faithful replication of the putenv() for the 3000 namespace. putenv() changes or adds a value to an environment's variables.

You can download Miller's work for use on your 3000 at his website. "I found that the provided LIBC.LIB.SYS (MPE/iX 6.0) does not provide a  putenv()  function. So to whomever it may be useful, you can get one  under MPE Software, in the MPE issues in libc section. Now this can work in the MPE programming environment as well. Besides putenv(),  there are also a couple fixes for  sleep() and abort()." Miller explains further.

HP's Cathlene McRae noted that putenv() is a Posix function. In Posix, the environment is part of each process. In MPE, the environment is part of the job or session which allows all your processes access to the variables.

ANSI-C describes a getenv() function that retrieves environment variable values and is included in the MPE C library. It uses the HPCIGETVAR intrinsic to do so. However the putenv() function is not part of ANSI-C** and so I suppose that is one reason why it was left out.

A large part of migration projects I'm involved in is testing, to make sure the new environment works the same as on MPE. Therefore I attempt to make my code run on both environments. In this case, some built in runtime debugging code used putenv() which I happened to put back onto MPE for testing. I need to do this in the MPE environment, not Posix, since I'm working with MPE programs for migration.

So I put together a putenv() that uses the HPCIPUTVAR intrinsic; making a good match for the exiting getenv() function.

"The CI already provides SETVAR to set and change variables," Miller said "similar to the export command in Posix or other Unix-type shells. putenv() is a library function to give programs access to the environment variables." He cited the ANSI-C specification.
The definition of getenv is designed to accommodate both implementations that have all in-memory read-only environment strings and those that may have to read an environment string into a static buffer.  Hence the pointer returned by the getenv function points to a string not modifiable by the caller.  If an attempt is made to change this string, the behavior of future calls to getenv is undefined.

A corresponding putenv function was omitted from the Standard, since its utility outside a multi-process environment is questionable, and since its definition is properly the domain of an operating system standard

 

Posted by Ron Seybold at 08:35 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

April 28, 2011

File transfer backup tips flow off HP's forum

Relying on HP for 3000 support is becoming a gamble and a gambit. One of the spots to place a bet is on an open forum run by Hewlett-Packard's support team. A recent quest for FTP techniques reveals yet another place where independent experts share MPE/iX answers.

The question was how to use FTP to ensure a safe backup of 3000 data. In this case it was a KSAM XL database, but the manager didn't know that his FAK files were HP's special Keyed Sequential Access Method database files. "What appears to be program files are moved over," he said, "but database files get left behind. How do I get these files over to our Windows server?" This 3000 is running MPE/iX 6.0, so there's more than just management experience missing from this server, since 6.0 is more than 10 years old.

One rule of 3000 operations is that database files act differently than all others in transfers. So FTPing them to a Windows 2003 server won't be a successful way to ensure a safe data recovery. (There are tools like Orbit Software's Backup Plus to do this, updated and supported in a way that STORE or HP's TurboStore subsystems will never be supported again.) But if a machine is stuck on 6.0, it's probably going to have only the budget to tap included HP software for file backups and transfers.

Donna Hofmeister, whose resume helping 3000 users occupies a vast chunk of the 3000-L newsgroup archives, suggests starting with mystd to store the files to disk -- then transfer the STD file. The advice arrived from a source that won't see a forced shutdown, or a portal migration, like HP's. The answers came from your community.

"First try this little experiment," Hofmeister began in her answer.

    file mystd;dev=disc
    store a@.pub.sys;*mystd;show

if it works, you just stored/archived all the files that begin with 'a' in the .pub group of the .sys account into a file called 'mystd' (my store-to-disc).  You can expand the number of files being stored into your STD file by modifying your store command to:
    @.pub.sys -- all files in .pub.sys
    @.@.sys   -- all files in .sys
    @.@.acct  -- all files in .acct (for example)
    @.@.@     -- all files on the system (and it's actually better to say '/' instead of '@.@.@')

Keep in mind that as you increase the scope of what your storing, so does the size of your STD file. In other words, to store the whole system you need 50 percent or more free space , which you probably don't have. So, break what you're storing into chunks (do one account at a time) and things should go smoothly.

If STD doesn't work, you might be able to get tar to work. The same space precautions apply.  One advantage of using tar is you should be able to verify the tar file on the destination system -- something you can't do with STORE without a 3000 in the mix.

Chris Bartram, who still operates an information treasure-house in 3k.com, added explicit advice about FTP and the 3000's files.

If you package all the MPE files up in either a store-to-disk (aka std) or a tar "wrapper" (disc file) you can transport that file around at will -- as a BINARY file -- don't try to transfer it as ASCII or CR/LF translations will trash it.

Once you get it back on the 3000, a simple file equation directing your source (tape) to the new (std) file name (and add the ;DEV=DISC to the file equation) will allow you to restore the files onto the 3000 preserving all the MPE specific file attributes they started with. Tar will work similarly for almost all MPE files, but can't handle database/PRIV files and probably not MSG (message) files and a few other very MPE-specific files.

tar works the same way on MPE as on *nix boxes. But is much more "familiar" if you run it from the Posix shell (sh.hpbin.sys), though that's not necessary. Treat the tar file just like you would on a *nix box.

For store-to-disc files, you use the same MPE syntax for storing files as you do normally; the only difference is that the output device is file-equated to ;dev=disc. As mentioned, be aware of the disc space required to store another copy of your backed-up files online.

Likewise, when you restore instead of pointing to tape, you point to the disc file -- and don't forget to add ;dev=disc to that file equation as well. If the store-to-disc files are going to be very large (several gigabytes) you can use some additional syntax to break them into chunks - but hopefully you needn't worry about that for now.

Treat a store-to-disc file just like a tar file. Record size and most other attributes aren't so critical, but if you move it around do NOT let FTP transfer it in ASCII mode or it will corrupt the file.

As for examples; I back my primary HP 3000 up to a disc file then transfer (FTP) it to a Linux server. Here's the gist of my JCL:

!FILE t=FULLB.PUB.BACKUP;DEV=disc
!CONTINUE
!STORE / - /BACKUP/ ;*T &
! ;SHOW=SHORT,dates,path;progress=5;directory;tree;&
! onvs=MPEXL_SYSTEM_VOLUME_SET,WORK;STATISTICS;COMPRESS=HIGH

!ftp.arpa.sys
open ftpserver
user userid password
del hp3000-full
binary
put FULLB.PUB.BACKUP hp3000-full
quit

Bartram hoped his answer helped the manager handling a 6.0-vintage HP 3000. HP's now got few unique resources to solve these problems. Most of these answers can be found on the 3000-L list, where both Bartram and Hofmeister have been regular contributors. HP's said this week that its IT Resource Center forums will remain open to everyone, even after the migration to the new HP support portal is enforced on June 1. If the vendor changes its mind, it's comforting to know there's a community resource to surpass HP's answers.

Posted by Ron Seybold at 02:05 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

April 14, 2011

3000 can listen for less to link with printers

We want to use a Ricoh Afficio printer with npconfig on the HP 3000. However, we do have an HP LaserJet that could be used. What I recall hearing is that the Ricoh can work -- but the HP LaserJet, not being a foreign printer, would be easier to use. True?

Jeff Kell of the University of Tennessee at Chattanooga replies:

If you are using real HP network printing without any third-party bells and whistles, the HP software is expecting to output something to a device along the lines of a JetDirect card or a networked Laserjet III/IV, and not much else. The 3000's MPE/iX generates fairly straightforward PCL output directed at TCP port 9100, has a rudimentary knowledge of SNMP status reports from a LaserJet/JetDirect. Later versions attempted some PJL handshaking in order to synchronize headers, print, trailers, and some error recovery.

So everything worked exactly as expected/planned, but for a very narrow window of time and hardware.

With that said, if you disable PJL (pjl_supported = FALSE), it eliminates many problems with earlier LaserJets and third party PCL-compatible printers, and now you're strictly dealing with fairly straightforward PCL.

If the print device isn't really an HP, it probably won't support the SNMP status requests either, so you may want to disable SNMP as well (snmp_enabled = FALSE). The combination of one or both of these should make any printer happy that "claims" to be PCL-compatible.

There was a later "turn off PCL" option (pcl_enabled = FALSE) but I never had a run at that one to know just how generic that made the driver.

We have some Ricoh multi-function devices on campus and have done some bulk printing to one before (not sure of the exact model.) But the 3000 had no issues with it after suitably neutering the MPE print configuration.

Posted by Ron Seybold at 10:59 AM in Homesteading, MPE's Hidden Value, Users & Reports | Permalink | Comments (1)

April 04, 2011

Keeping a 3000 on the Network

With most HP 3000s more than 10 years old by now, the internal components might be subject to failures. It doesn't happen often to anything but a disk, but any electronic part can go belly up on you. We liked the advice applied when a seasoned manager found his Network Interface Card (NIC) unresponsive on his 3000.

I have a NIC that appears to be down (no blinky lights).  When I tried to restart the LAN configured to it, I got the console message in reply to my restart command below:

/SYS/PUB%>NETCONTROL START;NET=LAN3

Encountered one or more errors while processing command. (CIERR 4436)

/SYS/PUB%>** NETXPORT Control Process : BUFFER MANAGER; Buffer manager error
- Loc: 45; Class: 2; Parm= $FFE300C9; PortID: $FFFFF78E

Does this appear to be software or hardware related? In other words, if I power down the HP 3000 and bring it back up, will the card wake up or remain dead?

Donna Hofmeister of Allegro replied:

Using NMMGR, check the configured packet size for the affected link. In particular, look for a packet size of 8224, which may indicate the NMCONFIG file has been corrupted, probably by an incompatible version of NMMGR. If the packet size is configured correctly, then depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system.

Use of the LINKCONTROL command can at least show if the 3000 can see the apparently dead hardware.

Mark Ranft of Pro 3k explains:

LINKCONTROL @,all

Or more specifically...

LINKCONTROL LAN3,all

3000 manager (and Invent3K DR system admin) Tracy Johnson posed the question. Before he asked for the techniques to test, he explained his solution. "I solved the problem by swapping the IP with an unused NIC and doing a NETCONTROl START on it."

But if you're starting to solve this kind of problem with no unused NIC on hand, knowing the diagnostic process is the best first step to keeping a 3000 on the network

Posted by Ron Seybold at 11:27 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

March 14, 2011

Architecture Toolbelt Emerges for 3000s

When Connie Sellitto of the American Cat Fanciers' Association (CFA) asked for help preparing for a migration, the 3000 community hacked out suggestions and pointers. But much of the toolset designed to identify what's to be migrated off a 3000 can also be put to use in sustaining projects. Sustaining is what a manager should be doing to homestead, if they are not migrating. As the word suggests, sustaining is an activity that goes beyond glancing at a console to see if the 3000 is running, plus ensuring there are enough backup tapes.

The advice from 3000 managers and experts was aimed at Sellitto's deadline of tomorrow; she needs to present a "wireframe" diagram of the system's database architecture by March 15. The document will go into the hands of a web design company the CFA's board has chosen, one which has won the right to migrate its HP 3000 to a Windows environment.

Wireframe is architectural terminology for the map of website design, page by page. In the environment at CFA, databases and applications take the place of website pages. Alan Yeo of ScreenJet, which has built the EZ View modernization kit for 3000 user screens still in VPlus, said the ubiquitious PC tool Visio that Sellitto was learning quickly might be overkill.

If you have Adager/Flexibase/DBGeneral, or already have a good schema file for the databases, just generate the schema files and import them into Word or Excel and give them to [your migrators]. If they can't put together the data structure from that, no amount of time you can spend with Visio is going to impart any more information.

A schema file isn't difficult to understand, and if they can't, there isn't much you can do to help them.

Yeo added a few pointers on understanding the schema file.

A Primary Key is a sorted key, and indications that a specific numeric has (n) implied decimal places should be the most they should need, plus a couple of pages from the IMAGE manual that describe the data types. IMAGE structures aren't complex.

But 3000 consultant and developer Roy Brown wrote us to advise further, with detailed pointers on how anyone who needs to chronicle and maintain the architecture of a 3000 can get the job done -- whether they're migrating, or sustaining.

Visio (Professional, let's hope they gave her Professional) can read the details of a SQL database and produce a visual schema automagically, so it's not like she's got to chart them manually. And standard HP 3000 tools let you generate SQL views of TurboIMAGE databases, for Visio to chomp on.

The SQL extensions to IMAGE are covered in the HP Communicator at docs.hp.com/cgi-bin/doc3k/B3021690178.13563/65

Brown added that IMAGE/SQL specifications, to help train any migration contractor, are also online at HP's 3000 web pages.

It's been a while since I used these tools, but they let you work on TurboIMAGE databases as if they were SQL ones. We were using them to pull data into Business Objects.

I recall using one of the tools (IMAGESQL) to even extend the definitions of the items, so the SQL access would know how many decimal places numeric fields had, something not held in IMAGE schemata. All these tools run on MPE, on the HP3000.

With all the above defined, you can then use the supplied ODBC client on a PC linked to the HP 3000, so that ODBC-compliant programs 'see' a SQL representation of the TurboImage database, and can work with this just as if it was a SQL one. Birket Foster (whose company created ODBCLink/SE) will probably know a great deal more about this than I do. And also in what ways his paid-for ODBCLink is superior.

But if I recall correctly, you configure things so the ODBC-compliant program on the PC knows: to use the ODBCLink driver; where the HP 3000 is (IP address or hostname), and how to authenticate -- and away you go.

Visio has free and open source competition, software which HP support veteran Lars Appel pointed out. "Perhaps Visio has similar 'database graph' features such as free or open source tools like dbVisualizer or SquirrelSQL."

Stan Sieler of Allegro noted that "You might look at our DBHTML product, with example output on our website, although it doesn't draw pretty pictures."

Sellitto checked back in on the 3000 newsgroup and reported some progress, but her migration contractor really seems to want those diagrams.

The SCHEMA file produced by Adager and/or FO from QUERYNM provides sufficient detail as to the tables (datasets) and fields (items) of an IMAGE database. I have provides these, along with an explanations such as ‘X6’ means a ‘char’ of 6 characters, ‘search item’ would be an ‘index’ and so on. In addition, I provided narratives of what each ‘table is used for, FO listings of representative records, and screen shots of how our users access the data. Should be sufficient -- and they seemed to indicate an understanding.

But now, with a few days before they visit our office, they have again requested the diagram approach.

Denys Beauchemin, who's written database tools for the 3000, wonders if automating these architecture layout tasks for 17 database is really worth the learning curve -- especially on a one-time, leave-the-3000 project.

You’re spending an enormous amount of time trying to make tools work. If this was something that would be ongoing, I can see spending the time for that, but for a one off thing?

I would sit down with the schemas and some paper and simply draw the two-level diagrams with a pencil, showing the links between master and details. Then I would simply scan the papers into a PDF file and call it good.

Beauchemin's opinion shows where a sustaining project could benefit from architecture automation, while a migration project won't enjoy the same payoff.

In a final test, Yeo worked with Visio and other tools and has broken down the process to show the architecture of 3000 databases.

The only databases and tables that I could access are those set up in the SQL DBE definition. So if you haven’t gone through all that work in the first place then its a non starter. As far as I can see the DBE only contains information about the datasets that someone has chosen to add (or probably that is make available via a view). When adding the databases' datasets to the DBE, if only the default item mappings were used, then all you are going to find out is that an item is char or numeric -- but you would have no idea about "date" types or decimal places etc. So again, not much good if you're trying to provide a data structure description.

Anyway, taking a reasonably well formed database into Visio and reverse engineering, you do get the tables and items. It will show you what the indexes in the tables are but as far as I can see it doesn't show that a detail is linked to a particular master. Automasters are missing anyway as they are really only for IMAGE.

My conclusion: if you have done all the work to load the databases in the SQL/DBE and done all the data type mappings, then importing in Visio might be a reasonable start to documenting the databases, as all you would have to do is add the linkages between the sets.

If you don't have everything in the SQL/DBE then I would say we are back where we started.

Go into QUERY, open the database just do an "FO" it will tell you everything about all the items, all datasets, all indexes, paths etc. Do a select all, copy, go into Word and paste. Then if you want to be really helpful, go through the item defs and mark up if they are a date format, of if numeric how many implied decimals. Oh, and if you're using a char as a numeric, or you have a field overloaded with undescribed children, that is probably the most useful info.

Posted by Ron Seybold at 02:59 PM in Homesteading, Migration, MPE's Hidden Value, Users & Reports | Permalink | Comments (0)

February 28, 2011

Start getting ready for IPv6

IPv6, the Internet address protocol for the future, is among the technologies that MPE/iX will not support this year. This Version 6 of software that routes Web traffic was among those that OpenMPE was considering when it applied for its license for the MPE/iX source. It was suggested back in 2008 that a contract project might have revised the 3000's networking to accomodate the new protocol.

But native support for IPv6 networking won't matter as much as some 3000 managers expected. Although the 3000 was prepared to do DNS service, the vendor didn't build a patch in 2009 to eliminate a security hole in DNS for MPE/iX. That's bedrock technology for Internet protocols, so it would have to be made secure. Much of this kind of routing for 3000 shops takes place on external PC systems today. You can even make an older Windows XP box do IPv6, according to Paul Edwards, a former OpenMPE volunteer who's a training resource for the 3000 community.

The new networking will become much more essential to an IT operation this year. Earlier this month the Internet Assigned Numbers Authority issued the last block of IPv4 addresses. Another organization, the American Registry for Internet Numbers (ARIN), advised that companies that do business over the Internet should support IPv6 on public-facing Web serversor  Web services by Jan. 1, 2012 or risk losing potential customers.

Edwards sent us a note this month that outlines a simple process to enable IPv6 on Windows XP -- which despite being as discontinued at Microsoft as MPE is at HP, continues to drive the majority of PCs worldwide.

You may have heard the news: the world officially runs out of IPv4 addresses this month. But never fear. IPv6 is here... well, sort of.

Many companies are converting their networks to IPv6 now,  and Windows 7 comes with built in support, but what about those who are still using Windows XP? Luckily, it’s easy to install the IPv6 protocol on your XP machine. Here’s how:

1. Click Start | Run
2. Type cmd to open the command prompt window. 
3. At the prompt, type netsh and press ENTER 
4. Type interface and press ENTER
5. Type ipv6 and press ENTER
6. Type install and press ENTER
This installs IPv6. You can confirm that’s been installed by typing, at the command prompt, ipconfig /all.

You should see an entry under your Local Area Connection that says “Link-local IPv6 Address”  and shows a hexadecimal number, separated by colons. That’s your IPv6 address.

There's a lengthy technical article about building a Linux-based lab PC to do IPv6 testing up on the InfoWorld site. That process involves installing Vyatta Core, a distro of Linux which supports IPv6 by using "a wide variety of routing protocols, including OSPF and BGP."

Edwards said he's enabled IPv6 on his XP systems, and hasn't encountered any conflicts with websites using the new protocol on XP.

Posted by Ron Seybold at 01:52 PM in Homesteading, Migration, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

February 07, 2011

Need a little 3000 disk? Go to the web

Bos2_cover_sm HP 3000s have a storage legacy to endure: SCSI, the IO interface that HP did not advance for the servers in the prior decade. Finding SCSI replacements for 3000s was supposed to be harder by now. But like any prediction about the death of technology, the reports fall short of reality. You can find what you need on the Web.

Disk drives are the most likely parts of an HP 3000 to fail, being just about the only moving part in the system. (Tape is the other.) Disks from HP are available from independent resellers, but are still more costly than more recent vintages of storage peripheral. When you browse the Web and see a 1 TB disk for $150, you might wonder if there's a chance to use that kind of device in your HP 3000.

By many experts' testimony, there's a good chance that an under-$100 drive will boot up your HP 3000 just fine. These older 3000s use pretty small disks, so the costs of replacement are small, if you go outside HP's inventory. HP stopped selling and making SCSI-2 drives long ago.

If a little drive is all you need, how can you be sure you're buying something that works with the 3000? Years back, John Burke wrote an article for the NewsWire explaining how to do it. HP replied at the time with its set of sensible reasons why the HP-firmwared devices are worth the extra cost. These Low Voltage Device units, long in the tooth, are making homesteading customers look at replacing their 3000 disks that are eight, 10, even 15 years old.

3000 storage experts like Denys Beauchemin have years of evidence that HP's disk standards have not been essential for reliable 3000 service.

I have been using non-HP firmwared disk drives in my HP 3000 for over 10 years now. "SCSI is SCSI," and as long as you can get your hands on a 50 pin SE or LVD disk drive, or if you can get a converter from 68 PIN to 50 pin you should be good to go.

Or if you would rather have something with a newer manufacture date than 1997 (that's so last millennium,) pick up any current (or at least 21st century) LVD-SCSI drive and get a 68-pin to 50 pin converter and have at it.

The converter can be had at granitedigital.com, where Granite Digital Part 6980, 80 SCA to 50m IDC (no termination) runs about $40.

Research on SCSI requirements is best started at the SCSI FAQ. Adaptec's website has good information, too. Allegro's Stan Sieler once posted a comprehensive list of Seagate's disk ackronyms for their drive interfaces. "Seagate drives indicate their interface via the one or two letters at the end of the model number."

LC  Low Voltage Differential, 80-pin SCA
LCV Same as LC, but with an increased cache size
LW  Low Voltage Differential, 68-pin Wide SCSI Connector
LWV Same as LW, but with an increased cache size
N   SCSI, 50-pin Narrow SCSI Connector
DC  Differential, 80-pin Single Connector Attachment (SCA)
ND  Differential, 50-pin Narrow SCSI Connector 

Then, the high-voltage differentials, (HVDs) which can't be used with a simple adapter:
   
W   SCSI, 68-pin Wide SCSI Connector
WC  SCSI, 80-pin SCA (Hot Swapable)
WD  Differential, 68-pin Wide SCSI Connector

So as an example, a Seagate ST318404LC (Cheetah 18GB 10,000 RPM) has a low-voltage (LV) 80-pin interface. Coupled with the converter, it can work with a Series 918 to replace original drives, if you use the original drive cable in the 3000.

Even today, it's simple enough to find a Seagate ST318404LC. Amazon lists the drives new at $74.99

Beauchemin has offered an interesting history of these interfaces:

SE-SCSI is very old (20-plus years) and was almost the original SCSI. It stands for Single-Ended SCSI. Speed is 5 MB/second and the cable can’t be very long, 6 feet or less.

Then came UltraSCSI or HVD-SCSI. The speed was up to 20 MB/second (or even 40, but I’m not sure.) The good thing with HVD is that you could go long distances, 25+ meters with it. It uses the difference in voltages between pins, whereas SE SCSI uses absolute voltages that are very low to begin with. If you remember RS-232 and RS-422, it’s the same principle here. RS-232 was based on signals having a (low) voltage and no voltage and RS-422 was based on the differences in voltage between signal pairs. Which is why RS-232 was certified for 50 feet and RS-422 could go thousands of feet.  It’s all a question of resistance and signal attenuation.

However, it seems that HVD had a speed limit associated with it, perhaps that speed of light thing. Also, as devices became (much) smaller, the need for long distances went down or was better addressed with fiber optics which is insensitive to stray electrical signals.

So, SE came back in vogue, but this time as LVD or Low Voltage Differential. When you plug a single-ended device in an LVD string, all devices, including the host bus adapter, drop down to SE signaling and to the speed of SE-SCSI. So, as long as you can account for the 50 pin to 68 pin thing, either with a cable or an adapter, LVD and SE devices can co-exist, at SE speeds.

LVD hasn't disappeared. Back when Jazz was online at HP, the vendor recommended in a white paper the supplier Rancho SysTech -- which today is still selling adapters to bridge this gap from the 900 Series 3000s that use HVD drives to the more-available LVD drives.

Posted by Ron Seybold at 10:47 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

January 26, 2011

PDF techniques span integration skills

HP 3000 experts and veterans recently swapped a wide array of techniques to create PDF files from the server's data, then move them via FTP to a Windows server. While the simplest answer to getting a report into PDF format and out to Windows is probably Hillary Software's byRequest (called a slick solution by Dave Vogt of Miller Compressed Air Company) there are other commercial solutions -- and a raft of bolt-together techniques you might try if you've got very limited budget to homestead.

Bob McGregor reported:

We used txt2pdfPRO by Sanface. We had a job that would run and check a pseudo device for spoolfile output, and if the pri > 0, would run the sf2html process, convert to PDF and then FTP to a Windows server. The process would then delete spoolfiles=0 on the pseudo device the next day. Setup took a bit... but once done, worked well.

Lars Appel, author of the Samba/iX file sharing tool, added:

I wonder if it might make sense to configure a "dummy" network printer on MPE/iX and have it send spooler output to a little socket listener on the WinTel system (similar to the FakeLP example from the 3000-L archive) and then invoke GhostPCL on the Windows side for generating the PDF output.

The "dummy" network printer would let the MPE spooler take care of the PCL conversion and also perform the "file transfer" automagically. The GhostPCL software is probably easier to get (or build / update) on Windows than on MPE (okay, I admit that it did also build on MPE long ago...)

Michael Anderson of consulting firm J3K Solutions added that there is also a open source PDF tool, pdfcreator, with which a manager might setup a network PDF printer. "Some assembly required, and batteries not included," he noted.

Another vote came in for the Advant/X software from Tracy Johnson, the OpenMPE volunteer who's built up the Invent3K shared server. Johnson noted that the STR Software product "while intended to convert spool files and then e-mail or fax them, I imagine it can be used short of the transmission process

John Pitman combines an off-the-shelf FTP solution from a departed vendor, Whisper Technology, with a good deal of original integration.

Nominate a spooled ldev as always suspended (74 in our case - arbitrary). Users can choose this device as their printer in their Menu, and all subsequent reports (until changed to another real printer ldev) will go to these device, and therefore NOT physically print. Some reports that are commonly used to import to excel have been modified to make headings tightly lined up with the data columns, and only print one page heading, to ease the import process.

Run a job on 3000 that every few minutes scans for spoolfiles for this ldev, copy them to posix space specific to 74(for generality), with  the creating user and account in the file name(eg mgr_stock_O12345.txt), delete the original spoolfile.

We use a product called Bullet Proof FTP Server on Windows - this provides FTP  user/password secured access to directories . Last time I looked this was a bit hard to find, but was free in at least one version - it came out of Whisper Technology.

A scheduled program on the windows box (every minute!) FTP connects to the 3000. When it finds a spool files as above example, it checks for a windows destination dir of MGR_STOCK , and copies the file  to it as O12345.txt, and deletes the 3000 copy of the file. The account name enables segregation of reports for different applications in our case. If the file is > 1MB(arbitrary size of your choice, designed to reduce network loads when the file is downloaded by the user), its zipped. It could as easily be converted to any desired form - pdf via cutepdf? It could aslo readily email the output to a user, given access to a mail server, and a way to develop the email address.

Users have a client to access the FTP server and obtain their .txt or .zip files

This has been running for at 10 years now, with almost no issues. Occasionnally a large file might hang ftp, but cancelling and restarting the copy usually fixed it. I have seen report selection errors produce 500mb txt files.

You might use several suspended ldevs for different types or groups  of users. We run this on four 3000s in different locations, each with their own separate windows boxes using BP-FTP server. This means that users in Oz can run a report on the Houston or China system to the local printer 74, pause, connect their ftp client to the relevant ftp server, and download the report without having to print it.

The process also enables soft storage of month end reports , which can be very useful for comparative purposes, auditing , and general historical reference - we now have about 8 years of this information stored , with backups and CD copies. Much more compact than paper, and cheaper!

Posted by Ron Seybold at 04:14 AM in Homesteading, MPE's Hidden Value, Users & Reports | Permalink | Comments (1)

January 12, 2011

Tape drive controls lead to Looney Tunes

Duck Autochanging tape drives used to be the stuff of science fiction among 3000 managers, but those days passed by before HP cut off making its Classic 3000 MPE V systems. Just because an autochanger is a standard storage option does not make it automatic to program, however.

A question posed to the community by systems manager John Pitman of RYCO Hydraulics reached for help on "programmatically controlling such autochangers -- to select a slot, and load the tape and come to ready." Advice is at hand, including a detour to a Looney Tunes classic. As it turned out, Pitman didn't need his programming, but the advice can make some autochangers toot smoother.

HP's pass-through SCSI driver came up in some advice. The software built by HP's labs and "not for the faint of heart" can assert a program's control over autochangers, although third party programs such as the Orbit Software Backup+/iX do this work. If you've never seen an autochanger at work, OpenMPE's Tracy Johnson pointed to great theme music, a tune called Powerhouse you will know as soon as you hear it, if you've ever watched a Warner Brothers cartoon.

Some programming ideas came from Denys Beauchemin, among others, the engineer who developed at HiComp for the HiBack 3000 solution. "For the next tape to be brought online automatically, I seem to remember there had to be a special setting with the dip switches."

As for being able to control the robot itself, you definitely need to have the [HP] SCSI pass-through driver configured and loaded, and then you need a program to actually issue the IOCTL calls to the robot with the properly formatted SCSI commands. There was such a program a long time ago from a vendor, but that's all gone now.

The pass-though driver is still available from HP for the strong hearted, a piece of coding designed to give 3000 sites control of SCSI devices HP didn't engineer or test for the server. Perhaps the high-test flutes and heavy octane horns of Powerhouse -- used in Duck Rogers and the 24th and a Half Century -- can be put up on the MP3 player while fitting the driver to MPE. ("Oh drat these computers -- they're so naughty and so complex," says Marvin the Martian in one installment. "I could just pinch them.")

Jack Connor of Abtech -- another OpenMPE volunteer -- pointed to similar complex answers about controlling DDS changers.

Typically, there's a second SCSI port/address assigned for the transport control which allows the selection of specific tape. For MPE, stacker mode is typically selected, which tells the drive to just mount the next tape in line when requested. I don't know if the DDS autoloaders have a network connection available like the C7145NA DLT autoloaders do; with that device's web interface you can reload any tape, bypass a bad tape, and so on.

Pitman checked in to report that a much simpler solution to his changer's control needs popped up. "On re-examining my code for HPDEVCONTROL, I found I had catered for 1- and 2-digit device numbers in the string passed, but I had configured the drive as dev 777. This produced a string dev number of 77, which doesn't exist as a tape drive. Once I fixed this, it works like a treat."

While that solves the control needs of HP autochangers at Ryco, the exercise also leaves the devices and the pass-through software with a classic piece of music by jazz master Raymond Scott as a theme song. It takes a community of 50-ish experts in an enterprise computer classic to connect long-ago-written, or long-gone, software with a tune that Warner Brothers' Carl Stalling used in a dozen 1950s cartoons.

Posted by Ron Seybold at 07:00 PM in Homesteading, MPE's Hidden Value, Podcasts | Permalink | Comments (0)

January 07, 2011

Users reach for new IO connnections

Linear Tape (LTO) and virtual disk arrays might not be common players at many 3000 sites. But as these servers mature in production settings, these higher capacity storage solutions are gaining attention from system managers. HP's engineering is better for the VA solutions than LTO, but both can perform in 3000 installations, according to user reports.

Are the LTO and LTO2 drives supported on Series 997 and N-Class servers?

Mark Ranft of Pro 3K replies:

They work, but they are not supported (if that means anything) with HP TurboStore. Other third party backup software vendors do support LTO. We do DLT backups to two, three or four drives with success.

Craig Lalley of EchoTech notes that N-Class LTO use yields the best results:

The 997 has a NIO bus that is capable of a sustained throughput of 20mb/sec. That is 20 megabytes per second. I seriously doubt that a 997 can make an LTO drive run in "stream" mode. Hence it would just "shoe-shine," back and forth. The N-Class is a different story, as long as it is not crippled.

Chad Lester of the MPE Support Group reports that the firm has LTO-2 and LTO-3 modules running on several N-Class servers the company supports. Dan Cossey of Client Systems takes note of HP's official communicator article regarding LTO support.

MPE/iX support of Ultrium 215 and 230 devices is limited to parallel LVD-SCSI connections only. Thus, these devices may only be connected to HP e3000 A-Class and N-Class systems running MPE/iX 7.0 or 7.5 Release. In addition, patch MPEMXJ3, version "A" for MPE/iX 7.0 or version "B" for MPE/iX 7.5, must be installed for the device to be supported. Finally, on 7.0 only, patch MPEMX74 "A" should also be installed.

Ultrium devices will only be supported for access/usage by certified third party supplied back-up products; certified products are currently limited to: BACKUP+/iX (ORBiT Software) and HiBackR (Mount10 Group).

The program devtool.pub.sys and the command file devctrl.mpexl.telesup may be used to load/unload media, but it will NOT support turning compression on/off for Ultrium. HP Ultrium incorporates "intelligent" compression that prevents attempts to compress data that is already compressed, so there is no need to explicitly turn device level (hardware) compression on or off.

We have a brand new VA7410 disk array. Is the CommandView SDM really necessary? I know it won't run on MPE, so I have to have a Unix or Windows host with an FC card to run it. But I also know the VA arrays have a serial port for command access. Can I do everything I need to do through the array's built-in command line? What can only be done via SDM?

Donna Hofmeister of Allegro Consultants replies:

You do want SDM running on something, because you need to be able to get to the array's log file and I don't think you can do that through the serial port. SDM will tell you (via logging) if your array is healthy or not -- probably something you really, really want to know.

But Craig Lalley demurs:

You can do most everything you need to do through the command port.  However, you cannot update the firmware, or monitor the array. If the firmware is correct, you can semi-monitor the VA through the serial port.

Jack Connor of Abtech adds:

You need either the HP-UX or Windows version of Command View to manage and diagnose the VA. You can configure it somewhat from the serial port in the back, but if there are log entries, such as a controller going bad or other issues, you’re going to have problems identifying them. Also, disc and controller firmware updates require CommandView.

While it will run on a WinTel platform, in my experience the fiber cards for a PC are (or at least were) cost-prohibitive compared to something like a J6700 workstation. 

Posted by Ron Seybold at 07:57 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

December 28, 2010

How to Train Newbies on an HP 3000

Several migration and sustainability experts have noted that the biggest risk in staying on a 3000 is the community's brain-drain. The answer to replacing more fundamental skills is to train for 3000 use and administration. John Archer of 3000 site ThermoLink needs training materials.

I need to put together some training for one of my employees that will be working on the 3k. He knows nothing about the box. I have been trying to find material on the basics and I can fill in on the specifics and more technical issues that I deal with day to day. It looks as if all links to HP's material (training wise) is gone and I can't find any self paced or tutorial material.

HP's Cathlene McRae replies:

Some 3000/MPE/iX training material can be found at HP's website. [Editor's note: This is a comprehensive set of links to dozens of training manuals and whitepapers written by HP, ranging from Using FCOPY to a comparison of several IMAGE maintenance tools.]

Using HP e3000 fundamental skills  and advanced skills manuals are at the bottom of the list.

Marc Cordeau of Speedware offered a link to the HP 3000 Series 9x8 Computer Systems Task Reference, hosted at docs.hp.com.

Paul Edwards of Paul Edwards Associates notes:

All the links [to training materials] are gone because HP shut down MPE training and licensed Frank Smith and me as exclusive MPE instructors, and had the HP training linked to our website. Our website was shut down last year due to the lack of interest in MPE training, except for in India. I still do MPE training on-site and have the details listed on my web site, www.peassoc.com. I don’t know if the old self-paced training modules are somewhere in the HP archives. Let me know if I can help.

Several other 3000 pros would like to help train newbies to the system. Mark Ranft of Pro 3K would be glad to assist.

But I get the impression that John was looking for self-paced training for free. With that in mind, there are options like the Guided Tour manuals that make very good starting points for learning MPE.

Lars Appel, the former HP support engineer who ported Samba to the system in the '90s, pointed to several of the training web pages.

* Performing System Operation Tasks

* Performing System Management Tasks
 
* Getting Started as an MPE/iX Programmer
  
Reviewing at the least the table of contents might be helpful to see if they have information useful for you. Some sections of the programmer guide, for example, do have nice overview- style info that might be useful for a more than just a person aiming to become a programmer.

 

Posted by Ron Seybold at 02:38 PM in Homesteading, MPE's Hidden Value, News Outta HP, Web Resources | Permalink | Comments (0)

October 27, 2010

More notes on 3000 SFTP, and HP's advice

We got expert response from the community for our Monday story about Secure File Transfer Protocol (SFTP), something that UK-based Adrian Hudson wants to manage from his HP 3000. Hudson checked in with us after hearing from consultant Mark Ranft of Pro 3k as well as the NewsWire. It turns out Hudson is a contractor working at Europ Assistance, a company using an HP 3000 to "provide insurance and assistance (e.g. motor breakdown, travel) cover across the world."

They have a need for SFTP to transfer new policy details from the Internet. I have a feeling that if Europ Assistance can’t do SFTP from the 3000, or if there is a cost involved, they will simply use one of their non-3000 servers as a piggyback to do the SFTP on the 3000's behalf. But with me being a nostalgic old soul, I would like to see it done from the 3000.

So, last week I started to look around for a zero-cost solution and found a Beechglen web page about it. This web page all seems perfectly okay, so I started to see if I could source the components mentioned on the web page, namely Openssl, Openssh, perl and a GNU C compiler.

On the openssl list server, I also started to independently look for versions of ssl and ssh which had been ported to the 3000 and I also sent an email to Tracy Johnson of OpenMPE to try and get a logon to the invent3k2 server to see what I might find on there.

Hudson offered some career history, which includes a seven-year stint at HP. "I worked on 3000s and 9000s on and off from 1986 until 2003 and was lucky enough to work at HP between 1997 and 2003 as a 3000 ‘expert’ in their Storage Division. Since then I’ve spent seven years or so on lots of different flavours of Unix and Linux and, to be honest, until 7 weeks ago I thought I had done my last LISTF. It has been a strange but warming experience to get back onto a 3000, especially one with vanilla TurboIMAGE!"

Separately, Ranft got back to us on the specifics of running SFTP on a 3000, something he doesn't recommend as highly as getting the services from another environment.

I have recently completed the instructions for installing sftp on Pro 3K’s server and on a customer’s server. It was not easy, but I managed to gather all the files needed.  Some of the components were extremely difficult to track down. I have them all stored in a single 100MB store-to-disk file that can be transferred to [Hudson's] system and restored.

The instructions have you install the GNU C compiler and make the components needed for SFTP client to function. As with following any instructions, we ran into a few issues along the way with syntax and typos. Most of these were pretty straightforward caused by slightly different names for the newer digest files.

When complete, your system will be capable of acting as an SFTP client, but not as an SFTP server. If you are not familiar with SFTP and how it works, another issue is the key exchange. SFTP depends on a public/private key exchange for security. The procedure for generating the key and storing it on the server is another complex portion of the project.

After completing the SFTP installation and key exchange, I am confident that you will have a solution that will work. But this HP 3000 SFTP solution will not be ‘supported’. [Ed. note: At least not supported by HP; independent companies have an option to support it.] Basically, if you or your customer have trouble down the road, once again you will be dependent on consulting to guide you to the solution.

In truth, using a non-HP 3000 server to be the intermediary SFTP solution is an excellent choice. This solution can provide additional security. The server running SFTP can be both a client (to send files) and a server (to receive files). The SFTP server can be placed in the DMZ of your customer's network. (A DMZ, or demilitarized zone, is a physical or logical subnetwork that contains and exposes an organization’s external services to a larger untrusted network, such as the internet.) This is a good solution.

Ranft added that the secure FTP white paper that HP referred us toward doesn't really detail how to get SFTP working on a 3000. "It's about making regular old FTP/iX more secure," Ranft said. "It has very little or nothing to do with SFTP."

HP states in the 2008 paper that it covers the enhancements HP applied to FTP/iX for security, a request voted No. 2 in the final Systems Improvement Ballot.

Briefly, these security enhancements are:

  • Restricting unauthorized users from logging on to an FTP server,
  • Restricting unauthorized users from retrieving certain files on an FTP server
  • Quarantining certain FTP/iX users to single directory roots,
  • Logging all FTP commands and all file transfers from both the server and client side
  • Preventing FTP users from rename, delete, and overwrite file operations
  • Disallowing read access of the NETRC configuration file (which contains sensitive logon data)
  • Password hiding when running FTP/iX in debug mode.

Another section describes a few methods to enhance security of FTP/iX in addition to the recent security enhancements. Some of the alternatives discussed are

  • An envelope FTP/iX script that provides encryption of the data transfer between hosts
  • Using non-MPE intermediaries like HP-UX to facilitate secure FTP communication
  • Porting of Open SSH on MPE/iX to provide secure data transfer
  • Use of a firewall for sockisified FTP
  • Hardware solutions for enhanced security

 

Posted by Ron Seybold at 03:23 PM in Homesteading, MPE's Hidden Value, Users & Reports, Web Resources | Permalink | Comments (0)

October 25, 2010

Getting OpenSSL, SFTP Working on 3000s

HP 3000s can use OpenSSL, cryptographic protocols that provide security for communications over networks such as the Internet. SSL can encrypt segments of network connections at the Application Layer to ensure secure end-to-end transit at the Transport Layer. It's an open source standard tool, but deploying it on an HP 3000 can be less than transparent.

Consider the following question from Adrian Hudson in the UK.

Does anyone know anything about putting OpenSSL on a HP 3000? I've seen various websites referring to people who have succesfully ported the software, but with the HP 3000s being used less and less, I'm finding lots of broken links and missing pages. My ultimate intention is to try and get Secure FTP (SFTP) running from Posix on the HP 3000.

Several up-to-date support providers can help Hudson and others who want this security tool running on a 3000. Mark Ranft of Pro3K (612.804.2774) said, "I would be happy to assist. I recently did this for another client. I have all the pieces and instructions to do this." Beechglen's founder Mike Hornsby also has software and experience at hand. "Beechglen has OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17, SFTP and SSHD versions for MPE/iX," he said.

HP placed the OpenSSL pieces in its WebWise MPE/iX software, according to former HP Internet & Connectivity engineer Mark Bixby (now developing at K-12 app company QSS). "When I left [HP's 3000 division], a fully functional OpenSSL was part of the Apache bundle. The last Apache/WebWise patch that I built contained all of the necessary source code and build scripts, and more."

However, Secure FTP is not provided in the WebWise bundle. A longtime friend of the 3000 community, still working in support, provided a white paper on how to set up SFTP for the HP 3000. The paper was written just two years ago.

Cathlene McRae, still working at HP in 3000 support, confirmed Bixby's report on SSL. "WebWise is the product you are looking for. This has OpenSSL." She shared a PowerPoint document of 85 slides written by Bixby in 2002, one of the last years that WebWise was updated for the HP 3000. (You can download these slides, a PDF file, from our site.) A few minutes later, she pointed us to the SFTP paper.

Finally, Keven Miller of 3K Ranger detailed his notes from installing OpenSSL on a 3000, aided by Craig Lalley of EchoTech. I'd be happy to talk with whomever has interest. I would like to do the "port" again with notes so others can reproduce; and place on my website or my Invent3k2 website, invent3k2.org/~GUEST.MILLER

I'm looking on my HP 918 (mpe 6.0 pp2)

Openssl 9.6a
OpenSSL> version
OpenSSL 0.9.6a 5 Apr 2001
OpenSSL>

I believe AFTP did build and run. That would be from OpenSSH. As I recall, the process is

1. install zlib
2. install openssl
3. install openssh

/OPENSSH/V00371P2/openssh-3.7.1p2#sftp
usage: sftp [-vC1] [-b batchfile] [-o ssh_option] [-s subsystem | sftp_server]
[-B buffer_size] [-F ssh_config] [-P sftp_server path]
[-R num_requests] [-S program]
[user@]host[:file [file]]
/OPENSSH/V00371P2/openssh-3.7.1p2#sftp hpux-1
Connecting to hpux-1...
Couldn't connect to PRNGD socket "/tmp/egd-pool": Can't assign requested address
Entropy collection failed
ssh-rand-helper child produced insufficient data
Connection closed

As I recall, I need to stream a job for this EGDPOOL. I hope to get back to this and other porting things.
But work gets in the way.

Posted by Ron Seybold at 03:13 PM in Homesteading, MPE's Hidden Value, Users & Reports, Web Resources | Permalink | Comments (0)

October 20, 2010

Tape data to disc files and setting Posix time

I have some information on a tape. I’d like to create a store to disc file with it — how do I do that?

Jack Connor replies:

There are several solutions. The first and easiest is to simply restore the info to a system (RESTORE *T;/;SHOW;CREATE;ACCOUNT=WORKSTOR) where WORKSTOR is an account you create to pull the data in.  Then a simple FILE D=REGSFILE;DEV=DISC and STORE /WORKSTOR/;*D;whatever else should create the disc store.

The second is to use FCOPY. You'll have to research the STORE format, but I believe it's FILE TAPEIN;DEV=TAPE;REC=8192,,U,BINARY.

The third (also easy, but you need the software) is to use Allegro's tool TAPECOPY, which moves from tape store to disc store and back.

John Pitman adds:

Do you mean copy it off tape to disk store file? I’m not sure if that can be done, as in my experience of tapes, there is a file mark between files, and EOT is signified by multiple file marks in a row... but anything may be possible. If you do a file equate and FCOPY as shown below, you should be able to look at the raw data, and it should show separate files, after a file list at the front.

FILE TX;DEV=TAPE;REC=32767
FCOPY
FROM=*TX;TO=;CHAR;FILES=ALL

Here is our current store command, and the message it provokes. MAXTAPEBUF speeds it up somewhat

STORE  !INSTOREX.NEW.STOCK2K;*DDS777;FILES=100000;DIRECTORY;MAXTAPEBUF

Why is the date/time in the Posix shell way off from the time on MPE, and what can be done to fix it? It’s over three weeks off.

Homesteading Editor Gilles Schipper replies:

First, check to ensure your timezone offset is correct and there are no pending time clock changes.

:showclock

SYSTEM TIME: TUE, OCT 19, 2010,  5:46:38 PM
CURRENT TIME CORRECTION:            0 SECONDS
TIME ZONE:    4 HOURS  0 MINUTES WESTERN HEMISPHERE

If incorrext timezone and/or time correction is non-zero, you can fix both with the :SETCLOCK command.

Next, ensure that the TZ variable is appropriately set. This can be done with a system logon UDC that executes the following:

comment the following is for Eastern Time
SETVAR TZ "EST5EDT"
comment use the following for california
comment SETVAR TZ "PST8PDT"

Posted by Ron Seybold at 02:26 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

September 30, 2010

Restrict 3000 access, link web console, UPS

Is there a way to restrict access to only a certain user within an account? For example, I would only like user OPERATOR.AIS to have access to everything in the FILES.AIS group and account. There are users within this account that have AL and or GL access.

Gilles Schipper replies:

If you wish to restrict the group FILES to be able to be accessed by only the user OPERATOR, do the following:

:ALTGROUP FILES;ACCESS=(R,L,X,W,A,S:GL)
:ALTUSER OPERATOR;HOME=FILES;CAP=+GL

This will restrict any kind of access to files within the FILES group to only the user OPERATOR, with the following possible exceptions:

1. Any user in that account that has AM capability cannot be denied access to files in that group.

2. If any other user in the account has its home group as FILES -- AND also has GL capability -- then that user will also have access to the files in the FILES group.

So, in the specific example you cite, you only need to ensure that any other user that has GL capability does not also have FILES as the home group. (Of course, as stated previously, you cannot deny access to any user in the account that possesses AM capability).

Possessing AL capability does not provide access, since, as shown in the above ALTGROUP command, all forms of access are given ONLY to users with GL capability. And GL capability is negated for all users that log in to other than their HOME groups.

To repeat -- this technique allows you the proper file access restrictions WITHOUT the nuisance of group passwords, because if any user in the account (other than an AM user) logs in to this group (and does not have FILES as the home group or lacks GL capability) that user will be denied access to all files in the FILES group.

Can I make a Web Console work with my 959? The 959 has a DB-25 remote console socket, rather than the 9-pin of the N-Class.

Mark Ranft replies:

With the correct cable, the Web Console should definitely work on the 959.  I had it working on a 989.  I am not sure why you would compare the 959 to the N-Class.  Anyone using Web Console on the N-Class should switch to using the GSP console.

For a better, more reliable, faster, more fully featured console on pre-GSP systems, I have set up remote console via DTC, using back-to-back DTC switching. It is very nice.

Craig Lalley adds:

Just use the 25-pin connector that is currently connected to the system console.

I have a system that I need to set up a UPS and Monitor/iX software. Is there a quick method to configuring and setting up the background job?


Gilles Schipper replies:

You'll need a straight-through 9pin-9pin serial cable attached from the N4000 UPS port to your UPS serial port.

You should already have the UPSUTIL.MPEXL.TELESUP software that you need to configure the UPS monitor.

The UPSUTIL manual, which is really pretty straightforward, is available at:

http://docs.hp.com/en/14249/upsutil.pdf

I am having an issue getting write access to the N-Class console after getting successfully connected. I have tried BREAK, and get the response [Read only - use ^Ecf for console write access.]

Craig Lalley replies:

The "^" stands for the control key.
 
So with three fingers  Control-Shift-E  take your fingers off and type 'c' then 'f'  -- then hit return



Posted by Ron Seybold at 08:51 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

August 16, 2010

Products, programs push remote printing

3000 consultant Michael Anderson tapped a wellspring of advice over the last few days with a request about remote printing from an HP 3000 to multiple locations.

I have a need to support "Printing on printers at the remote locations" to multiple client companies from my HP 3000. Kind of like the old time-share paradigm. The client companies can access the HP 3000 using Telnet/iX, but they need to be able to print from the HP 3000 (Telnet session) to their own local printers. Does anyone know of any “canned” software that would help achieve my goal, or perhaps another network strategy?

Charles Finley of Transformix, a migration and software services company that's been working with Robelle of late, posted eight replies of considerable detail to solve Anderson's problem. But along the way the 3000 community which still trades 3000 technique at comp.sys.hp.mpe chipped in a few commercial solutions for the challenge, as well as one recommendation to use Samba.

The simplest resource to implement looked to be the ESPUL HP 3000 software written and sold and supported by Richard Corn. The creator posts rarely on the newsgroup, but Corn offered this detail on how to use the print management product.

You would be using our product ESPUL to print from the HP 3000 to a Windows box into printer queues set up on that box. If you currently have Windows printing in your environment and a Windows system that hosts or has queues for the printers you want to use, you can make use of that from the HP 3000. One other option is using ESPUL to print to a locally attached printer via Reflection or MS92 session.

Finley began solving with the advice, "It can be done with mostly off-the-shelf open source stuff. But someone still needs to do a little programming."

1) You need to create what the HP 3000 thinks is a network printer to which the HP 3000 will send its output.  So, in this case you need to configure the Linux computer to look like a JetDirect box to the HP 3000. This means that you need a way to have something listen on TCP port 9100 and accept raw data from the HP 3000.

2) You need to strip out and/or convert CCTL characters to standard ASCII print controls. Therefore, you need an intercept program that processes the raw data you get from the HP 3000.

3) You need to alter your report programs so that there are some tags in each report identifying which customer it belongs to.  Your filter program needs to read the tags in the report.

4) You need some sort of PDF conversion software that will take the HP 3000 reports and convert them to PDF. You need a PCL to PDF (not text to PDF) converter to do this.  Otherwise, you will need to send the output to a printer instead of PDF.

5) You need either a web application that will restrict users to certain directories based on their login or you could even do it without a web application. This should be simple enough because you can give each user a unique Linux user account.

6) You need some sort of directory browsing application.  You could even let the customers use Reflection with its file transfer capability.

Essentially, it can be done with simply having one program that:

1) Listens on port 9100
2) Does the CCTL conversion
3) Reads the tags in the report and places the report in a specific user account based on the tag.
4) Converts PCL to PDF

Once all of the print output is in PDF, you do not need to address their printers.  Therefore, you do not need to print to their printers at all. They will be able to print from any printer at their own site.

Another 3000 vet suggested packaged software from OpenSeas, OpenPDF. Tony Summers said, "It is a product from OpenSeas on the HP 3000, and we continue to use it even though we’ve migrated onto HP-UX. The raw spoolfiles were converted in a simple two-stage process which we wrapped up into a UDC and the end result was FTP’d to the end user as a PDF file."

In the discussion that flowed across a Thursday afternoon and into Friday, Anderson was sparked by some of the ideas. "Having something that looks like a Jetdirect printer to the HP 3000 is key! My thinking is that something that looks like a JetDirect printer could be a CUPS print server. Then using CUPS in combo with Samba, and maybe SCP, will make the network connectivity issues easier to resolved, and enable the possibly of sending the output directly to the remote printer without any user intervention."

John Pitman added that he's used "an intermediate Windows box running BP FTP Surfer, with user and passworded access. Each HP user who directs printout to a specific device (that isn’t physically present) gets the output sucked off the HP to the FTP surfer to a directory specific to the user as a txt file. This is mostly to save paper and to provide data suitable for importing to Excel. Requires a job on the HP 3000 to move spoolfiles to a Posix directory, and an FTP job on the Windows system to suck them across every few minutes.

After reading Anderson's progress on the printing process, Finley summarized how available open source software and JetDirect gets the job done.

Since you are simply planning on using the Linux/CUPS machine as a store and forward message server. you could do the following:

1. Set up a CUPS server on each IP address you can give the Linux computer.  There are ways to assign more than one. One way to cheat is to pretend you have a multiport JetDirect.  I may be out of date, but the last multiport one I worked on had TCP ports 9100,0102, and 9103.  If you can get enough TCP/Port IP address combinations to satisfy all of your printing needs you may not need to do any programming.  For example 4 IP addresses = 4x3 separate “printers." I haven’t confirmed this, but if you can make each of those represent a separate Queue on the Linux computer you can assign one to each real printer.

2. Configure each Queue on the HP 3000 and print to it just as you would any network connected printer.

3. On the Linux end, simply configure each real printer to match each queue. Then I believe you’re done.

If you can’t do the above, you can send all of the output to one pretend JetDirect address and create a little intercept filter to separate the output to each real queue.

Anderson had enough advice by the end of Friday to go into a test "with two CUPS servers using scp, connected through the cloud, and setup a NPCONFIG device on MPE to print to it"

It is simple, and if addition massaging of print files is needed, the CUPS server is equipped with many powerful scripting tools, regexp, awk/sed, and tcl.

Using SCP to copy printfiles between the local CUPS server and the remote CUPS server should be very efficient, and the remote CUPS server can be anywhere in the world, anywhere that supports an internet connection. So, from the HP3000 spooler, you’ll be able to print anywhere in the world, after setting up local and remote CUPS servers. And MPE will just think they are normal JetDirect printers.

In Unix, you can use the |scp| command to copy files and directories securely between remote hosts without starting an FTP session or logging into the remote systems explicitly. The |scp| command uses SSH to transfer data, so it requires a password or pass-phrase for authentication. Unlike |rcp| or FTP, |scp| encrypts both the file and any passwords exchanged so that anyone snooping on the network can’t view them.

Less than 24 hours later, with the help of six 3000 experts, one solved problem. Independent support takes a lot of forms this year, but going to the remote network of veterans can yield a wide array of solutions.

Posted by Ron Seybold at 04:42 PM in Homesteading, MPE's Hidden Value, Users & Reports, Web Resources | Permalink | Comments (0)

June 14, 2010

Delete empties, checks on batch, and more

I have a group that contains flat files that get FTPed to our network by a job on the HP 3000. Before FTPing the files, I would like the job to delete files that are empty, but the problem is that the file name is never the same. How can I use MPE/iX or MPEX to determine which files in the group are empty and delete them?

Robert Schlosser replies:

In MPEX you can say PURGE @(EOF=0) and purge all files with no records

Dave Powell adds, for those who have only standard MPE/iX at hand:

If you don’t have MPEX (gasp), you can still :listfile into a msg file, and read it back, call finfo to check the eof, and you are in business.  Knowing how to do this can be handy if you want to do something to a fileset that isn’t a one-line MPEX command.

Here’s an example slightly dumbed-down from a routine we use to do things only to files with more than seven records.  You could adapt it by changing  “> 7” to “=   0” on the third finfo. It’s a bit fancier that you really need, because I insisted on echoing the file name and eof to the job listing, padded with blanks so the columns add up.

!PURGE   MG, TEMP    >   $NULL
!FILE    MG; REC=-72,,F,ASCII;MSG;DISC=5000,32,1;TEMP
!LISTFILE    fileset.group,6           >>  *MG
!
!SETVAR  _CNT        0
!IF  FINFO("MG",'EXISTS')    =   TRUE
!    WHILE  FINFO("MG","EOF")    >   0   DO
!        INPUT   _LONGNAME   <   MG
!        SETVAR  _NAME_X     lft('!_LONGNAME',26)
!        IF  FINFO(_NAME_X,"exists")
!            SETVAR  _EOF    FINFO(_NAME_X,'EOF')
!            SETVAR  _EOF_X  RHT('     !_EOF',6)
!            IF  FINFO(_NAME_X,"eof") >  7
!                ECHO File-Name = !_NAME_X    EOF = !_EOF_X
!                your commands go here, like maybe "purge !_NAME_X" or "print
!_NAME_X"
!                SETVAR  _CNT    _CNT + 1
!            ENDIF
!        ENDIF
!    ENDWHILE
!ENDIF
!IF  _CNT        =   0
!    your "nothing found" routine goes here, if any

!ENDIF

Is there a clean way to determine, either in a command file or programmatically, whether I am running in batch? I don't want to simply check the variable HPINTERACTIVE or HPJOBTYPE. Those don’t do what I want if we are in a session that was created by a REMOTE HELLO from a batch job on a remote machine.  I want a way to know that such a “session” is really “batch.”

Cathlene Mc Rae of HP's Response Center replies:

When a job is streamed on a system the hp variable set for the job are as  follows:

HPSTREAMEDBY = CATHLENE,MGR.MCRAE (#S102) HPJOBTYPE = J
HPINTERACTIVE = FALSE

When the job does a dsline system and a remote hello the following variables  are set for the remote session:

:remote showvar
 HPSTDIN_ACCESS_TYPE = NS/VT
 HPVT_CLIENT_LDEV_NUM = JOB INPUT SPOOLER  HPVT_CLIENT_JOB_NUM = #J14
 HPVT_CLIENT_JOB_NAME = MGR.MCRAE

 HPINTERACTIVE = TRUE
 HPJOBTYPE = S
 HPSTREAMEDBY = CATHLENE,MGR.MCRAE (#S102)

The variable set when a session does a dsline system and a remote hello are:

HPSTDIN_ACCESS_TYPE = NS/VT
HPVT_CLIENT_LDEV_NUM = 3
HPVT_CLIENT_JOB_NUM = #S102
HPVT_CLIENT_JOB_NAME = MGR.MCRAE     

So, how can you tell if a job or session started the remote  session?

Answer:

The hpvt_client_ldev_num will be may be set to “job input spooler “ and hpvt_client_job_num will be “#J”.

Tony Summers adds:

Please note, the variables won't exist if it's a local session. In the past I've used the BOUND command to prevent command scripts from failing.

IF BOUND(HPVT_etc)    
  IF  (HPVT_etc = "whatever")
      etc

Walter Murray, who posed the original question, commented:

The most clever suggestion was from Jeff Vance, who pointed out that you can try setting HPTYPEAHEAD to TRUE, and then check HPCIERR.  Sure enough, that works!

In the end, I decided to go with a technique that several others suggested, and Cathlene amplified.  There are a number of HPVT_xxx variables that are sometimes set.  I decided to check HPVT_CLIENT_JOB_NUM.

Here's what I came up with:

COMMENT *  Are we running in batch or interactively?
COMMENT *
SETVAR RUNNING_IN_BATCH FALSE
IF HPJOBTYPE = "J"
 SETVAR RUNNING_IN_BATCH TRUE
ELSE
 COMMENT *  A real session, or REMOTE HELLO from a Job?
 IF BOUND(HPVT_CLIENT_JOB_NUM)
   IF TYPEOF(HPVT_CLIENT_JOB_NUM) = 2
     IF LEN(HPVT_CLIENT_JOB_NUM) > 2
       IF STR(HPVT_CLIENT_JOB_NUM,2,1) = "J"
         SETVAR RUNNING_IN_BATCH TRUE
       ENDIF
     ENDIF
   ENDIF
 ENDIF
ENDIF

I face a serious situation on our HP 3000. A batch job which used to run for about 30-45 minutes (stores data in an IMAGE detail with about 3.2 million entries) runs now 4 hours and longer to handle the same amount of data. What should I look for?

Brian Donaldson replies:

Did anyone make program changes? Or change locking strategies in the program -- locking data sets and/or data items and not DBUNLOCKing until the program completes, instead of DBUNLOCKing immediately after an update (DBPUT, DBDELETE, DBUPDATE) has completed?

If TurboIMAGE is the problem, then you can investigate the possibilities of synonym entries in your automatic and manual masters.

If you just use HOWMESSY, however, it doesn’t give you info regarding the offending entries causing the problems. It will just give you a percentage of synonyms in a particular data set, "SET-A has 23% synonyms." Not very helpful if you want to find out the offending entries that caused the collision in the first place.

For example:

data-set-a (master), key item = data-item-a
data-type= X4, key-value="ABCD"

hashes to IMAGE record 1234. Record 1234 already occupied by key value “XXYY”. So then IMAGE has to go find a slot to place key value “ABCD”.

With each DBPUT this hashing/collision nightmare could slow you down immensely.

If TurboIMAGE is your problem you can try changing the capacities on your offending automatic and manual master data sets.

Integer keys on master sets work fine if the key value is between 1 and the capacity of the data set.
When a key value is greater than the capacity then watch out -- the synonym problem will bite you. Generally speaking, “X” type key items (search items in detail sets) work best.

If your app uses integer keys, you cannot just change the data types of these keys without having to modify every piece of source code that manipulates these data sets. Then you have to recompile the entire application. Not exactly the optimum solution.

If you determine that TurboIMAGE is your problem I suggest you go straight to the big guns for assistance and call the gurus at Adager. Those guys will be able to help you best, I’m sure of it.

Posted by Ron Seybold at 12:31 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

April 28, 2010

Intercepting PCL to Extend 3000 Printing

HP 3000s generate Printer Command Language, the format syntax HP created for its line of laser printers. The 3000s were glad to get PCL abilities in their applications and utilities, but PCL is not for everybody. Multifunction devices not schooled in HP technology, such as those from Xerox, need a go-between to extend the 3000's printing.

The easiest and most complete solution to this challenge, one recently posted on the 3000 newsgroup, is Minisoft's NetPrint, written by 3000 output device guru Richard Corn. When we last reported on Corn's creation it was helping the Victor S. Barnes Company pass 3000 output to Ricoh multifunction printers.

But for the company that can't find about $995 in a budget for that 3000-ready product, there's a commercial Windows alternative of about $300 less you might try to integrate into your system designs. Charles Finley of Transformix explains that the path to print outside of PCL is two-fold.

Finley says of the fundamentals:

1. You need to get the print output from the HP 3000 to some device that is external to the HP 3000
2. You may need to intercept the PCL generated on the HP 3000 and format it for the intended device.

On the one hand, you can license the product of either Richard Corn or Minisoft to manage all this -- or if you want to use what MPE provides, you need to intercept the stream by using something that pretends to be an HP LaserJet.

In the second scenario, assuming you can connect the printers to Windows computers, you can use LPD and an interceptor of some kind. A commercial product we have used is RPM from Brooks Internet Software to accomplish the communication part of the process, plus some other PCL translator product to convert the PCL to whatever you need on the printer.

We had two projects in which, instead of the RPM product, we provided our own little interceptor (described at www.xformix.com/xprint) that does the same kind of thing as RPM. We have the Windows machine pretend that it is an HP PCL printer and configure the HP 3000 to print to it. We used other commercial software (two different products) to intercept the output intended for what it thinks is a LaserJet and format the print output so that it prints correctly.

I believe in each case the customers wanted to translate the PCL to PDF and do other stuff with it on the Windows computer before actually printing it. In one case, they wanted to store the PDF on the Windows computer and store reference data in a SQL Server database so that customers could selectively view and print the file at will.

Posted by Ron Seybold at 12:11 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

April 15, 2010

Cross over lines from disk's unknown state

I had a mirrored disk drive in a Jamaica Enclosure attached to my N-Class 3000 go bad.  The DSTAT results showed that it went into a ‘BUSY’ state, and nothing short of a reboot could clear it. During the reboot, I replaced the drive. But when the system went through “Mount All Volumes” it complained about a duplicate volume. My 3000 now shows this replaced drive in an "UNKNOWN" state. How do I resolve this partially mounted volume issue?

Gilles Schipper replies

You should use VOLUTIL's suspendmirrvol command. After you've replaced the drive, you simply:

:volutil
replacemirrvol IT_UV:member2 (plus volume number)

There’s really no need to perform a store-to-disk or buldjob stuff. But if really want to do that, there are a few steps that are needed.

I would first perform a directory store, as in:

:store command.pub.sys;directory;onvs=mpexl_system_volume_set,diskdump,it_uv,a_uv,b_uv;*t;show

Then, store the files on it_uv, ..
Then, after vsclosing, etc,

:restore *t;;directory;show

Then restore of files on that volset -- with the ;olddate;create;keep;partdb options. But I don't think any subsequent steps (vsclose, scratch, then rebuilding the volume set) will be necessary.

What's more, you really should not need to do a FORMATVOL. I've only once actually ever needed to do that -- and I did not do it with MPE, which is extremely slow.

A simple VOLUTIL replacemirrvol should do the trick after you've replaced the drive. The fact that the drive is in an "UNKNOWN" state is perfectly normal for the situation you described.

Posted by Ron Seybold at 04:08 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

March 26, 2010

Get specific about access from IPs

Is there a way to force a particular user ID to use a specific IP address? In other words, I want to give a machine a static IP and only allow this person to access the HP 3000 from that PC with the static IP.

Tracy Johnson replies:

A simple logon UDC should suffice:

IF HPREMIPADDR = "aaa.bbb.ccc.ddd" then
  ECHO Welcome.
ELSE
  ECHO Evil message here.
BYE
ENDIF

Bob Schlosser of the Support Group inc adds:

You can set up a logon UDC that checks that the var HPLOCIPADDR is equal to the device (PC) that you want them to use. Something like this:

LOGON
OPTION NOBREAK,LOGON
IF "!HPLOCIPADDR" <> "123.456.789.321"        change "123.456.789.321" to
your IP address
  BYE
ENDIF

Using this we verify that the user is on the correct (assigned) IP address, and log them off if not.

Chris Bartram, who's created e-mail solutions for the 3000 and hosted Web servers since early in the 1990s, adds:

The following is an excerpt from system UDCs I use on my HP 3000s that might give you some ideas.

The "VALIDATEIPADDR" call in the UDC calls another command file that actually does a validation of the logging-on user based on data in a control file to determine if he/she is allowed to log onto the system from the specific host/IP address they are coming from.

The variables the UDC sets will work whether the logging on user is coming in via Telnet or NSVT (or hardwired or modem).

The TELLOPs also leave a nice log on the system console (and log file) of the login, including where they came from and what protocol was used to access the system.

***
LOGON
OPTION LOGON,NOBREAK,NOHELP

setvar _network_node ''
if bound(hpstdin_network_node) then
  setvar _network_node '!hpstdin_network_node'
endif

setvar _na ''
setvar _at 'HARDWIRED'
if bound(hpstdin_network_addr) then
  setvar _na '!hpstdin_network_addr'
elseif bound(hpremipaddr) then
  setvar _na '!hpremipaddr'
endif

if bound(hplocport) then
  if !hplocport=23 then
    setvar _at 'TELNET'
  endif
endif
  IF BOUND(HPSTDIN_ACCESS_TYPE) THEN
    SETVAR _AT "!HPSTDIN_ACCESS_TYPE"
  ENDIF

IF BOUND(HPSTDIN_TRANSPORT_TYPE) THEN
  SETVAR _TP "!HPSTDIN_TRANSPORT_TYPE"
ELSE
  IF "!_AT"="TELNET" THEN
    SETVAR _TP "TCP/IP"
   ELSE
    SETVAR _TP "SERIAL"
  ENDIF
ENDIF

IF BOUND(HPVT_CLIENT_VENDOR) THEN
  SETVAR _VND " (!HPVT_CLIENT_VENDOR)"
ELSE
  SETVAR _VND " "
ENDIF

TELLOP LOGON VIA !_AT USING !_TP !_VND

setvar _node ups(ltrim(rtrim("!_network_node")))
setvar _addr ups(ltrim(rtrim("!_na")))
if '!_node'<>'' then
  tellop !_at, IP: "!_addr" Node: "!_node"
else
  tellop !_at, IP: "!_addr"
endif

setjcw cierror=0
continue
VALIDATEIPADDR
if !cierror<>0 then
  echo
  echo ************************************
  echo **  NODE/IP CONTROL FILE CORRUPT  **
  echo ************************************
  echo
  bye
endif

Posted by Ron Seybold at 11:54 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

March 15, 2010

It may be later than it looks, to a few 3000s

Daylight Saving Time started in the US early Sunday morning, and your HP 3000 should have kept up with the forward progress of the outside world's clocks. But if it didn't, then independent consultant Keven Miller has shared a repair.

"My DAYLIGHT job was still on the old TZ dates," he said of the list of trigger-dates for changing the 3000's clock. "I checked my TZTAB file (which was correct), and fixed my job."

HP supplied a new file for 3000s in 2007, when the US government and a few others changed crossover dates for the spring and fall time shifts. Miller shared an updated job stream to keep the 3000 on time.

THE TZTAB file was complex enough to merit more than one attempt by HP to revise it. Miller's job slows down the 3000's clock in the fall, but jumps it ahead right away in the springtime.

55.1 !COMMENT 2010-03-04 2nd Sun Mar, 1st Sun Nov
56 !COMMENT
57 !showclock
58 !if hpday = 1 and hpmonth = 11 and hpdate >= 1 and hpdate <= 7 then
59 ! SETCLOCK TIMEZONE = W7:00
60 ! ECHO SETVAR TZ "MST7MDT" > TZ.CMD.XSI
61 ! TELLOP *********************************************
62 ! TELLOP Changing the system clock to STANDARD TIME.
63 ! TELLOP The clock will S L O W D O W N until
64 ! TELLOP we havev fallen back one hour.
65 ! TELLOP *********************************************
66 !elseif hpday = 1 and hpmonth = 3 and hpdate >= 8 and hpdate <= 14 then
67 ! SETCLOCK TIMEZONE = W6:00
68 ! ECHO SETVAR TZ "MST7MDT" > TZ.CMD.XSI
69 ! TELLOP *********************************************
70 ! TELLOP Changing the system clock to DAYLIGHT TIME.
71 ! TELLOP The clock jumped ahead one hour.
72 ! TELLOP *********************************************
73 !endif

HP once hosted the new TZTAB file on the Jazz Web server. That means it's now available at the Speedware host for these HP files, as well as the Client Systems Jazz host. You will need to click through HP's standard, 40-page end user license agreement to get to the download page.

Posted by Ron Seybold at 03:15 PM in Homesteading, MPE's Hidden Value, Web Resources | Permalink | Comments (0)

March 09, 2010

Of safe names, and safer 3000 documents

I've read about that Florida site where the system manager passed away without much notice. It sounds like documentation is pretty important in that kind of crisis. What do you recommend as a minimum?

Paul Edwards of Paul Edwards & Associates replies:

There are a couple of papers in PDF format that can be downloaded that deal with documentation that
every HP 3000 site should have on hand for these kinds of situations. The contents of a System Manager Notebook include hardware and software information that is vital to recovering your system in any type of disaster. The rest of the company’s busines operating procedures has to be combined with the IS plan to form a comprehensive corporate disaster recovery contingency plan.

The Notebook contains hardware model and serial numbers; license agreements for all software and hardware; a copy of all current maintenance agreements, equipment warranty information, complete applications documentation of program logic; data file layouts and system interaction, along with system operator run books and any other appropriate documentation. There is a wealth of information contained in each HP 3000 that can be printed and stored offsite that is critical to a recovery effort.

I'm trying to figure out what characters are really safe to use in file names in the HFS namespace. I was recently surprised to learn that the percent character has problems in MPE.  If I STORE and RESTORE a file with a percent sign in its name, it seems that the percent sign and all following characters are dropped from the name. To be completely safe, do I need to restrict myself to uppercase and lowercase letters, digits, and underscores? 

Cathlene McCrae of HP Support replies:

The help file for the build command in the HP 3000 reports incorrectly that file names can begin with or contain any of the following characters: a-z, A-Z, 0-9, _, ., ~, `, $, %, ^, *, {, },+,|,:

THE HP 3000 manuals and the online file command’s help have the correct character set, which is:

a-z, A-Z, 0-9, underscore, dash and period.

This a-z, A-Z, 0-9, underscore, dash and period is the character set that I would recommend, since it is compatible with  most of the other operating systems -- including Windows.

Posted by Ron Seybold at 01:27 PM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

February 11, 2010

Back up the directory, plus the data

Yesterday our Homesteading Editor Gilles Schipper gave sound advice on the use of buldacct and store while backing up -- to ensure that a restore puts files in the correct places on a 3000. He also advised we wait to hear what 3000 pro and Allegro Consultants support expert Donna Hofmeister has to say about doing an INSTALL, which Shipper concluded yesterday was a better option. 

Hofmeister ran 3000 IT operations for years at Long's Drug. She says, "As long as you are somehow and routinely backing up your system's directory, you're doing the right thing." She's got a document that details steps on how to do a weekly full backup, with buldjob files. She's shared that with us (a Word document).

The advice has been polished and improved by Hofmeister, former OpenMPE director Paul Edwards and Shipper. It started its life as an HP document. And so the third party independent community again improves on what HP has created and documented. That might provide solace for anyone who worries about the decline of HP's 3000 interests.

Posted by Ron Seybold at 09:15 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

February 10, 2010

Directions on Using Store vs. Buldacct

Editor's. Note: 3000 experts have been asking what would our Homesteading Editor Gilles Schipper do while using the 3000's store directory option, rather than invoking the buldacct program to make clean backups. He weighs in with some sound advice.

By Gilles Schipper
Homesteading Editor

The confusion surrounding the use of the ;directory store option versus the buldacct directory creation program is common. I believe it stems from the fact that in order to benefit from the store ;directory option, one has to utilize the option almost perfectly in both the store and the restore following a system INSTALL.

Consequently, it becomes much easier to fall back on the buldjob options to re-create the directory -- although that option is inferior.

In order to be able to effectively utilize the directory option, the first thing that must be done properly is to ensure that the appropriate ;onvs= option is also used in the case where user volumesets are utilized. Otherwise, the non-system volumeset directories do not get restored after the INSTALL since they are not on the tape.

But even if the store part is done correctly, the other opportunity to go wrong presents itself during the reload process.

The proper procedure during reload is as follows:

1. perform INSTALL
2. restore ;directory from tape
3. re-create disk and volumeset environment via VOLUTIL

Then -- and this where many go wrong,

4. Again restore ;directory from tape (this re-creates the volumset directory environment on the master volumes for all user volumesets for those utilizing it)

and then

5. restore files
6. reboot with start norecovery (to enable network functionality)

Of course, for those that do not utilize user volumesets, the directory option becomes much less error-prone. And, for those that utilize third-party backup utilities, the ;directory option -- as utilized in the MPE store command -- is generally replaced with a similar option in the various backup utilities.

However, the bottom line is that for those that utilize the MPE store command to perform their backups, the properly-used ;DIRECTORY (and, if appropriate) corresponding ;ONVS= options) - together with correct restore procedures as indicated above will get the desired result 100% of the time.

Notwithstanding, of course, any tape issues occuring, which would be problematic no matter which directory re-creation option is used.

The bottom line is that the proper way to perform a full backup if using MPE backup facility:

:file t;dev=tape
:store /;*t;partdb;directory;onvs=mpexl_system_volume_set,big;maxtapebuf[;progress=5;show;online[=xxxx]]

Of course, upon further reflection, better than the store command, use sysgen to create a backup tape that not only contains all files, but also the SLT -- so that the one tape alone can be used to INSTALL and RELOAD your system. The use of sysgen for such purpose will require use of an indirect file.


Posted by Ron Seybold at 08:51 AM in Homesteading, MPE's Hidden Value | Permalink | Comments (0)

February 02, 2010

3000 tips for autoload, net stats and more

I have a Certance DAT72 autoloader, configured on my HP3000 and have no problems reading from and writing to the unit. How can I configure it so I can  issue a command to load the next tape in the 6-slot magazine?

Denys Beauchemin replies,

To use an autoloader on the HP 3000 as an autoloader, you must set the device to be out of random mode and then enable autoeject with DEVCTRL. Certance was a spin off from Seagate in 2003 and was acquired by Quantum in 2004. Here’s the Web page on the Quantum site for the manual on this device. I would try the settings for HP-UX first, then Windows next.

I thought stopping and starting the network automatically reset the network statistics, similar to
linkcontrol @;status=reset
However, when I look, the statistics don't change. Why is that?

Gilles Schipper replies,

I think your command is correct - but your timing's a bit off.

If you re-issue the command, you will see all the numbers were actually reset, but the numbers you saw the first time were those just prior to the command taking effect.

"uname -i" will return the HPSUSAN on an HP-UX machine, just as "showvar hpsusan" would on an HP 3000. Calling HPCIGETVAR for the value "HPSUSAN" from within a program would allow me access to that value during a run. What is the equivalent on an HP-UX box?

Ken Hirsch replies,

If you're programming in Perl, you could say:

my $susan = `uname -i`;
chomp($susan);  # remove line feed from end
print "susan = '$susan'\n";

In C, it would be easier to call the uname() function:

#include <sys/utsname.h>
#include <stdio.h>

main()
{
 struct utsname u;
 if (uname(&u) < 0) {
   perror("uname");
   exit(1);
 } else {
   printf("id = %s\n", u.idnumber);
 }
 exit(0);
}
#include <sys/utsname.h>
#include <stdio.h>

main()
{
 struct utsname u;
 if (uname(&u) < 0) {
   perror("uname");
   exit(1);
 } else {
   printf("id = %s\n", u.idnumber);
 }
 exit(0);
}

In the “how would I know that?” category, if you look at the bottom of the “uname” man page, it says SEE ALSO: getconf(1), hostname(1), model(1), setuname(1M), gethostname(2), sethostname(2), uname(2), hostname(5).

Section 2 of the manual has system calls and Section 3 library functions, so that’s what you want for programmatic access. Just type “man 2 uname” at the shell prompt.

Posted by Ron Seybold at 12:52 PM in Homesteading, Migration, MPE's Hidden Value | Permalink | Comments (0)