February 28, 2013

A Thorough Chill of the OS Business

LGFridgeThe consumer product maker LG has announced it's purchasing the webOS team, talent and tech from HP. This means a company whose lineup includes french door refrigerators now owns the most modern mobile OS in the world. As it turns out, great technology like webOS doesn't have much value in the hands of a company which can't create demand for the magic.

There's so little value left in webOS that the joint release about the sale says "HP and LG do not expect this transaction to have a material impact on either company's financial statements." And so, without even a report of what webOS cost, HP froze itself out of another OS product line.

Some operating systems not only have enduring value, but they are also drawing top talent to their community. It happened late last year for RedHat's Linux; Jeff Vance took his next step away from HP's 3000 guru days, when he made his transfer from K-12 vendor QSS to the Hat. Vance arrived at QSS with gusto for newer development environments and got to ply his passion for years there.

But the signals sent by selling off an innovative OS for "no material impact," well, they say a lot about how system makers create their value in 2013. The mobile OS that was going to unseat Apple made its HP departure with the same language as 3000 customers shared about MPE/iX. The end of the line wasn't really the end of the line, was it?

 

At webOS Nation, the site's editors watched HP turn to a commodity technology the vendor doesn't own. They asked "Is this the end of webOS, or just the end of HP and webOS? Is this news of an HP Android tablet a nail in the coffin of Open webOS -- or is it just a nail in the coffin of HP webOS?"

Just swap in MPE/iX in those questions and you can hear the echo of 2002-05. An avid vendor base wanted a further life for MPE/iX, but HP didn't even want to sell out of that OS. The company got asked, too, in the months that followed the 3000-exit decree from HP. "Sell us the 3000 business, since you're getting out," one MPE stalwart vendor offered. HP declined while it went cold on its most storied business OS -- one used at big sites, too.

However, knowing deep secrets of extraordinary technology still has its advantages, even today. An HP veteran of 31 years sat at the Old Austin Cafe next to us last night. My friend Scott Hirsh, formerly of the 3000 world's system manager leadership and now tackling tech presales at Dell, wanted an authentic Texas chicken-fried steak to enjoy with us. That HP fellow "couldn't help but overhear" us raving about history and HP and the 3000. A handshake later he was sharing colleagues-in-common with Scott.

The HP veteran had started out in sales at the Neely Region (the US West) and soon moved to 3000 sales in the Series III era. He'd held jobs as a CE and an SE in a company where software was designed to sell servers. Where even a Local Area Network offering became LAN/3000. Just because it was a standard tech didn't mean HP wanted to brand it.

"I miss the days of Bill and Dave," he said by way of introduction. We were all on the same team for awhile over our steaks. But he also was carrying the torch of tech in newer environments, installing 3Par storage with its many nuances for an HP site.

"These days I never see the inside of offices at HP," he said when we talked about changing technical structures. He's on the road 80 percent of the time, with the off days at his home office. An expert in the 3000's OS might find a similar future, if they can find customers who still value their operating system.

Posted by Ron Seybold at 02:54 PM in Hidden Value, Migration, News Outta HP | Permalink | Comments (0)

January 08, 2013

How to Make HP's Diagnostics Free on MPE

ComputerdiagnosticMore than two years ago when HP officially closed its formal HP 3000 support, the vendor left its diagnostics software open for use by anybody who ran a 3000. Throughout the years HP sold 3000 support, CSTM needed a password only HP's engineers could supply. But the CSTM diagnostics tools started to run on January 1, 2011 without any HP support-supplied password. 

However, managers need a binary patch to free up the diagnostics. Support providers who've taken over for HP know how to enable CSTM. The community has a former Hewlett-Packard engineer to thank, Gary Robillard, for keeping the door to the diagnostics open. Robillard says he is "the engineer who, last worked on CSTM for MPE/iX when I was still a contractor at HP back in 2008."

A 3000 site must request a patch to get these expert tools working. HP arranged for 3000 sites to get such patches for free at the end of 2010. We tracked the procedure in a Newswire story, just in case that HP link above goes dark.

One such patched version of CSTM needs a binary patch. This month Robillard was revisiting his binary patch fix, which can be a part of using these diagnostics, with the HP patch ODINX19A noted below.

Versions of CSTM [patched] with ODINX19A or ODINX25A allow the expert tools with no licensing, but you still have to issue the HLIC command. 

If you install ODINX25A/B/C (6.5,7.0,7.5) you won't need to do anything except issue the hlic command with any password. The HLIC command might say it was not accepted, but the license is activated anyway.

At the end of 2010, Robillard said his patch corrects the problem with ODINX19A -- and gives 3000 managers access to these system diagnostics -- for servers running the 6.5, 7.0 or 7.5 versions of CSTM.

If you have installed ODINX19A, you need to do the following:

Logon as MANAGER.SYS. It's safest to create an input file to sompatch.

1. Run editor.pub.sys

2. Add the following three lines EXACTLY. The sompatch will only work if the instruction at offset 268 matches 86a020c2. The message "Error: Old value does not match" is displayed and no changes are made)

Here are the contents of BINPCHIN file (You will want to copy and paste these); 

~~~~~The 3 lines are below~~~~~~~

; Fix problem in DIAGMOND after 12/19/2010
modify ms_init_manage_sys  + 268,1 86a020c2|08000240 
exit
~~~~The 3 lines are above~~~~~~~~
//
K binpchin,unn 

• Make sure DIAGMOND is not running (run STMSHUT.DIAG.SYS)
copy /usr/sbin/stm/uut/bin/sys/diagmond,DIAGMOND 
run sompatch.pub.sys;stdin=BINPCHIN;INFO='DIAGMOND' 
copy DIAGMOND,/usr/sbin/stm/uut/bin/sys/diagmond;YES 
• Restart DIAGMOND (run STMSTART.DIAG.SYS

After a few minutes, a "SHOWPROC 1;TREE;SYSTEM" should show the DIAGMOND process, and either the mapping processes, or memlogd, diaglogd and maybe cclogd (on A/N Class 3000s only).

Posted by Ron Seybold at 05:53 PM in Hidden Value, Homesteading, News Outta HP | Permalink | Comments (0)

January 03, 2013

Panel producer pursues PDF processes

NorbordNorbord, an international producer of wood-based panels, runs some of its operations on an HP 3000. This $1 billion company with 13 operating sites around the world needed to create PDFs on its 3000, a task assigned to John Pickering of the company. He went to the 3000 newsgroup for advice on how to do this, working to discover free, online resources already stocked away by indie support companies.

Pickering began by pursuing shareware, which is can sometimes be the budget choice for 3000 shops. (There's a superior and tested PDF-creating solution from Hillary Software, byRequest, which does this for 3000s as well as other enterprise systems.) But if a site wanted to bale together shareware like the txt2pdf software, a manager like Pickering needs Perl to run.

I'd be happy to use the shareware txt2pdf, but I don't know where to begin. The Sanface web site indicates that Perl is required, but that isn't on this 3000, either.

Allegro Consultants, supporting 3000s and crafting MPE software even in 2012, ponied up the Perl that Pickering needed to run txt2pdf.

You can get perl from Allegro," said veteran 3000 expert Donna Hofmeister at the company. "You'll want to get a copy of our SFTP PDF whitepaper as well, since it discusses how to install perl."

Keven Miller of 3K Ranger, another support provider and consultantcy, put the code for txt2pdf online at his site.

I've placed TXT2PDF.c version 1.1 from Phil Smith onto my site (It's MPE Software item #13) for those that might want to review it.

It's most likely not as advanced as the Sanface product. Probably need to change its name also.

Finally, Robert Mills reported that while he managed 3000s at Pinnacle Entertainment from 2001 to 2008, txt2pdf version 1.1 never gave him many problems in production use.

I had to increase the size of either the pageObs and/or locations arrays, because some of our reports were causing an abort (think that I doubled the size of them).

We didn't have HP's C compiler, so I downloaded GCC and it worked fine. Also, I had some other utilities that were only available in C source, which also compiled and worked when using GCC.

The Gnu C Compiler (GCC) Mills mentioned is the public domain bootstrap software of the 3000's open source software era. It was first forged in the 1990s by Mark Klein, whose DIS International hosts the compiler's software. The latest versions of GCC and related tools may be downloaded from DIS.

An open document format such as PDF was once locked away from HP 3000s until such open source options appeared. We chronicled the other aspects of PDF techniques for HP 3000 use in a story almost two years ago.

The longer that HP 3000s remain online worldwide, the more these updated features will need to be added to the MPE toolbelt. The community is not shy about sharing its experience, and it seems to be well-stocked in what's needed to use open source solutions.

Posted by Ron Seybold at 06:31 PM in Hidden Value, History, Homesteading, User Reports | Permalink | Comments (0)

November 29, 2012

Power of File Equations: HP 3000 Flexibility

Editor's Note: HP's George Stachnik spent more than a decade teaching HP 3000 customers how to use the best of the system, back in the days when HP was selling it, and then when the vendor was pushing migration. On the former mission, Stachnik wrote a 33-part series in InterACT magazine, The HP 3000 for Complete Novices. Our archives have revealed a paper copy of Part 14, which included figures you can't find anywhere else. The figures make the article, one of more than 20 available online at the 3k.com website, even more useful. Here's an excerpt of this advanced MPE/iX tutorial.

By George Stachnik

Let’s turn our attention to more advanced characteristics of MPE files: file equations. 

Suppose you were writing a COBOL program to read data from an input file. Let's assume that when this program is placed into production, its input file is called INFILE. In COBOL, you could code the filename right into the file definition. When you run such a program on an HP 3000, it will look for a file called INFILE and attempt to read data from it.

Of course, Murphy's Law dictates that as soon as you have a program that is "locked into" a particular filename, a need will arise to have it read a file with a different name. For this reason, most commercial operating systems provide a way of assigning a temporary alias to a file. Perhaps the best example is the granddaddy of all commercial operating systems: IBM's MVS operating system.

Most mainframe applications refer to files not by their filenames, but by temporary aliases called DDNAMES. On IBM mainframes, DDNAMES are assigned using DD statements in a job control language called (fittingly enough) JCL. JCL is an old (and cryptic) language, but the concept of DDNAMES is a good one. It allows mainframe application programmers a degree of flexibility. 

The HP 3000 provides a similar capability. MPE allows you to assign temporary aliases called "formal file designators" using :FILE commands.

Figure 1, shown below, shows an example of the simplest form of file command:

   :FILE INFILE=MYFILE

FileEquationFig1001Such a command is often referred to as a "file equation" because of the equal sign ("=") in the middle of the command. In this example, the filename MYFILE has been assigned a formal file designator of INFILE. The formal file designator can be used as a temporary alias for the filename. So MYFILE can now be referenced by two names: MYFILE and INFILE.

Figure 1 shows an example of how a file equation might be used in conjunction with a program that has been coded with the filename INFILE. On the left side of Figure 1, we see the application program as it normally works--reading its input from INFILE. But the right side of the figure shows what happens when we issue the file equation before running the program. In essence, this FILE command tells MPE that any program that tries to read a file called INFILE should be redirected to a different file (in this case, MYFILE).

The scope of a file equation is limited to the session in which the file command is issued. In other words, file equations are in effect only until you log off. For example, suppose you issued the file equation shown on the right side of Figure 1, and then immediately ran a program designed to read data from INFILE. The program would be redirected to MYFILE, just as the figure shows. You could run the program repeatedly during your session, and it would be redirected to MYFILE every time.

But as soon as you log off the system, any file equations that you've issued will die with your session. The next time you log on to your HP 3000, things will be back to normal (as shown on the right side of Figure 1). If you run the program again, it will revert to looking for an input file called INFILE.

Furthermore, the impact of file equations is limited to your session only. It is not global--it doesn't affect other users who may be logged on at the same time. So if you issue a file equation that assigns the formal file designator INFILE to the filename MYFILE, while another user runs the program, the program will behave normally for them, but it will be redirected when you run it.

There's another use for the :FILE command. Yes, file equations can be used to assign a temporary alias called a "formal file designator" to a file. The example shown below is a bit more complicated. The command is:

:file x=myfile;acc=append

This file equation does two things. First of all, it assigns the formal file designator "x" to MYFILE, so that a program that writes to a file named "X" will be automatically redirected to write to MYFILE. But this file equation also contains another parameter. The keyword "ACC=APPEND" (the "ACC" stands for "access") tells MPE that any data that is written to the formal file designator "X" should be appended to the file being written to.

Normally, when you write to a file that already contains some data, MPE/iX would simply write over the data that is already there. But the ACC= APPEND keyword preserves any data that's already in the file and appends the new data to the end of the file.

In order for this file equation to work, we need a program to write to an output file called "X." Of course, we could get out our trusty COBOL compiler and write one, but there's an easier way. Our old friend FCOPY can write to any formal file designator we like. All you need to do is to put an asterisk ("*") right before the output formal file designator. Returning once again to our figure above, we see the following FCOPY command:

:fcopy from=;to=*x

This command leaves off the input filename, just as we saw earlier. FCOPY will therefore read its input from $STDIN (i.e., from the keyboard). The output filename ("x") is preceded by an asterisk, or "star" ("*"). This tells FCOPY, "You are going to write your output to 'x'--but 'x' isn't a filename, it's a formal file designator. Go look at the file equation that I've specified, and it will find what file I want you to write to, and how to write to it."

FileEquationFig5Putting the :FCOPY command above together with the file equation in Figure 2 above (click for detail), we are telling the HP 3000 to read data from our terminal keyboard and append it to the end of MYFILE.

At the top of our figure, we saw that there was one record already in MYFILE when we started. The figure shows four additional records being added to the file. Record number 2 contains the number 2 (followed by 79 blanks). Record 3 contains the number 3, and so on. After we've added record number 5, FCOPY dutifully returns to our terminal keyboard for a sixth record. Watch what happens.

I've typed the character string "This one won't work!" Ordinarily FCOPY would have written a sixth record containing this string to our output file. But as you can see, something has gone horribly wrong. The error message "*134*FOUND EOF IN TOFILE" has been displayed instead, and FCOPY has terminated.

The error message isn't as cryptic as it looks. FCOPY is simply trying to tell us that MYFILE has a capacity of five records and we just tried to append a sixth record to the file. When it tried to write record six, it found the EOF (end of file), and it knows it can't write past the EOF.

Posted by Ron Seybold at 04:50 PM in Hidden Value, Homesteading | Permalink | Comments (0)

November 06, 2012

Voting for Security, Obscurity and Propriety

As I write this the polls have closed in the eastern-most time zone for the US elections. Nearly all of the ballots cast in this election have passed through some kind of electronic device, from a touchpad to a click wheel to other, non-uniform interfaces. You might visit a dozen counties in one state alone and see as many proprietary devices. Proprietary carries a negative vibe, this decade as well as this evening. A troubling report in Forbes related how experimental software patches in Ohio might be on live production voting machines today. Those are likely to produce unintended results, as such beta patches often do on HP 3000s.

But the word proprietary has a root of propriety, and that means proper: according to agreed-upon and accepted processing. You'd never sling out beta patches on an HP 3000 because it's just not proper. Your intention is to produce expected, reproducible and fact-checkable results. The fallout from using a proprietary interface, software or patch is simple: someone who's an insider needs to check it. And in a sinister aspect, knows how to crack it.

EugeneblogDecades ago the steady value of the HP 3000 and MPE was its security, one which flowed from privileged mode code. Then during the '90s it was the system's obscurity, once open-source and open system computers took the IT lead. Few people knew the 3000 well enough organize a serious breach. You were much more likely to be hacked from the inside, according to Eugene Volokh's classic Burn Before Reading. The same might turn out to be true this week, if the worriers from Forbes have conjured up a plausible nightmare about election machines. This evening, the biggest news outlets also fretted about the prospects.

Even during this data revolution, the 3000 is remaining settled in its nest of propriety as it's become ever more proprietary. The solution to the balloting mess is to standardize on devices and open the software. Not because the latter is harder to hack, but because an opened-up system is easier to scan for malware. The HP 3000 didn't need security patches after 2008 because the systems practiced propriety to earn their keep, and they were secure through their obscurity. National election voting systems don't have to meet that bar today. It costs too much, apparently.

My security expert colleague Steve Hardwick said that he's been involved in developing a secure voting system which could maintain its propriety. But the project didn't see the light of day in any of the 50 US states.

I did some work on a standard that would have provided very secure voting software. The effort was abandoned due to final cost of the units. Any system, including the physical one in place today, can be circumvented. I have not seen anything showing the comparative security to the physical one. At least the lawyers will have a field day. I wonder if this is the "hanging chad" of this election.

Nobody's hoping for such a thing, especially with so much at stake. But an HP 3000 veteran might be wondering, sometime tomorrow, how such a set of incompatible systems, installed entirely at local whim and desire with software so complex it can't be independently verified for security, could be rolled into production for this country's Big Event. It's the kind of thing that would get an IT pro of age 50 or more fired, if the results became improper.

To establish security of HP 3000s by now is a matter of sticking to an environment that's stable and limiting the access -- just like Eugene wrote in the 1980s. You keep track of who's got access and when to determine where the theft or malfeasance may have occurred.

The very fact that  someone is trying to run payroll across  a  phone  line  at  11 P.M. on a  Saturday is an indication of unauthorized  access. Thus, it is worthwhile to implement some form of security  that  prohibits access to certain user IDs and accounts at certain  times  of  day, days of week,  and/or from certain terminals. Alternatively,  you might want to force people to answer an additional password  at certain times, or especially when signing on from certain terminals.

This  may seem like a poor approach  indeed -- after all, if the thief hits  the time of day, day  of week, or terminal prohibition/password, this  means  that  he  has  successfully  penetrated the  rest of your security system, which will never happen -- right? In reality, this is a   very  potent  way  of  frustrating  would-be  security  violators, especially if the attempted violators are promptly investigated. Thus, another maxim appears:

Some forms of access are inherently suspect (and therefore require Extra  Passwords)  or  are  Inherently security  violations. Thus, access to certain user IDs at certain times of day, on certain days of the week, and/or from certain terminals should be specially restricted.

Eugene Volokh could understand those basics and preach them to his community of computer pros 30 years ago in his paper. By now, he's in government work, in the sense that he's a constitutional law expert and a maven of free speech. We might all hope, before our week is finished, that the philosophy that 3000 users knew in the 1980s about authorized access has traveled from Eugene's first community to his current one: the realm of the US courts.

Nobody ever hopes for a test of security, but it's expected that a system will pass -- or that changes, recalculations and improvements will result from any lack of propriety.

 

Posted by Ron Seybold at 06:32 PM in Hidden Value, Homesteading, Newsmakers | Permalink | Comments (0)

October 22, 2012

Marking Time with MPE's TZTAB File

By Gilles Schipper
GSA Associates 

Last in a series

Twelve days from today, Daylight Saving Time ends and will give HP 3000 users a reason to look at their clocks. This week may be an appropriate time to think about implementing some best practices associated with clock maintenance for the HP 3000s that you administer. One special nuance for MPE administrators is the TZTAB file. It's code that turns out to be important to third-party and independent software on your system.

TZTAB file and SETVAR TZ 

In other installments in this series, I mentioned the TZTAB file and TZ variable and their relevance to popular third-party software suites. Although not utilized by MPE, by and large, this file and variable are important for some widely-used software. 

And, due to a relatively recent change to the universal TZTAB file required to accommodate the new Daylight Savings rules effective in 2007, it's useful to understand the quite simple format of the TZTAB file, and the corresponding TZ variable that points to its appropriate location in the file.

Let's illustrate by using Aleutian Time (Hawaii) as an example. The TZTAB file (which is located in the LIB.SYS group), contains:

# Aleutian Standard Time, Aleutian Daylight Time (US)

AST10ADT

0 3 24-30 4  1970-1973 0   ADT9

0 3 6     1  1974      0-6 ADT9

0 3 22-28 2  1975      0   ADT9

0 3 24-30 4  1976-1986 0   ADT9

0 3 1-7   4  1987-2006 0   ADT9

0 3 8-14  3  2007-2038 0   ADT9

0 1 25-31 10 1970-1973 0   AST10

0 1 24-30 11 1974      0   AST10

0 1 25-31 10 1975-2006 0   AST10

0 1 1-7   11 2007-2038 0   AST10

So, where does that mention anything to do with Hawaii? It doesn't.

However, the first item in a Google search for "Aleutian Standard Time" does.

How to interpret TZTAB

Let's repeat the portion below that is associated with Aleutian Standard Time. We'll add a reference number at the beginning of each line.

1.  # Aleutian Standard Time, Aleutian Daylight Time (US)

2.  AST10ADT

3.  0 3 24-30 4  1970-1973 0   ADT9

4.  0 3 6     1  1974      0-6 ADT9

5.  0 3 22-28 2  1975      0   ADT9

6.  0 3 24-30 4  1976-1986 0   ADT9

7.  0 3 1-7   4  1987-2006 0   ADT9

8.  0 3 8-14  3  2007-2038 0   ADT9

9.  0 1 25-31 10 1970-1973 0   AST10

10.   0 1 24-30 11 1974      0   AST10

11.   0 1 25-31 10 1975-2006 0   AST10

12.   0 1 1-7   11 2007-2038 0   AST10

Line 1 is simply a comment line (#) in column 1, that identifies the common reference to the time zone

Line 2 is the actual value that the TZ variable needs to be set to for many Unix/Posix/Linux commands that need a time-reference to work properly.

All subsequent lines represent specific fields that have meaning according to their positional ordinal.

The first value (which is 0 in all lines) represents the minute of the hour.

The second value represents the hour of the day  (0 or 3 in all lines)

The 3rd value represents the day or day-range in the month.

The 4th value represents the month.

The 5th value represents the year or year-range.

The 6th value represents the day of the week (Sunday=0).

The 7th value is a string that represents the time zone adjustment in the form tznameDIFF, where "tzname" matches the first or last 3 characters of the TZ variable in line 1, and the DIFF represents the number of hours offset from UTC (Universal Time Clock, aka Greenwich Mean Time(GMT)).

In the above example, since only lines 8 and 12 apply to the current (and all future known) years, I will translate each of the 2 lines:

0 3 8-14  3  2007-2038 0   ADT9

On Sunday (6th field = 0), March (4th field=3) 11 (3rd field = 8-14), the first minute of the adjusted time will take place at 03:00 (fields 2 and 1, respectively), the adjustment resulting in the time being 9 hours from UTC (numeric part of seventh field).

Which means nothing for Hawaii, since Hawaii does NOT adhere to Daylight Savings Time.

One more thing: The above line suggests that the time adjustment BEGIN at 2:00AM, since the first minute of the ADJUSTED TIME should be 03:00 AM - which is exactly what happens when the time is moved forward one hour at 2am.

So, using the example above, we can see that:

0 1 1-7   11 2007-2038 0   AST10

means:

The first minute of the adjusted time will be at 1:00am on whichever day in November (1 thru 7) falls on a Sunday, in the years 2007 thru 2038. The adjusted time will be 10 hours removed from UTC. Again, since Hawaii does not adhere to Daylight Savings Time, no actual adjustment is necessary.

Let's use another example, using Eastern Time. The relevant portion of the TZTAB file is:

1.   # Eastern Standard Time, Eastern Daylight Time

2.   EST5EDT

3.   0 3 24-30 4  1970-1973 0   EDT4

4.   0 3 6     1  1974      0-6 EDT4

5.   0 3 22-28 2  1975      0   EDT4

6.   0 3 24-30 4  1976-1986 0   EDT4

7.   0 3 1-7   4  1987-2006 0   EDT4

8.   0 3 8-14  3  2007-2038 0   EDT4

9.   0 1 25-31 10 1970-1973 0   EST5

10. 0 1 24-30 11 1974      0   EST5

11. 0 1 25-31 10 1975-2006 0   EST5

12. 0 1 1-7   11 2007-2038 0   EST5

Line 1 is simply a comment line (#) in column 1, that identifies the common reference to the time zone

Line 2 is the actual value that the TZ variable needs to be set to for many Unix/Posix/Linux commands that need a time-reference to work properly.

All subsequent lines represent specific fields that have meaning according to their positional ordinal.

The first value (which is 0 in all lines) represents the minute of the hour.

The second value represents the hour of the day  (1 or 3 in all lines)

The 3rd value represents the day or day-range in the month.

The 4th value represents the month.

The 5th value represents the year or year-range.

The 6th value represents the day of the week (Sunday=0).

The 7th value is a string that represents the time zone adjustment in the form tznameDIFF, where "tzname" matches the first or last 3 characters of the TZ variable in line 1, and the DIFF represents the number of hours offset from UTC (Universal Time Clock).

In the above example, since only lines 8 and 12 apply to the current (and all future known) years, I will translate each of the 2 lines:

0 3 8-14  3  2007-2038 0   EDT4

On Sunday (6th field = 0), March (4th field=3) 11 (3rd field = 8-14), the first minute of the adjusted time will take place at 03:00 (fields 2 and 1, respectively), the adjustment resulting in the time being 4 hours from UTC (numeric part of seventh field).

The above line suggests that the time adjustment BEGIN at 2:00AM, since the first minute of the ADJUSTED TIME should be 03:00 AM - which is exactly what happens when the time is moved forward one hour at 2am.

So, using the example above, we can see that:

0 1 1-7   11 2007-2038 0   EST5

means: “The first minute of the adjusted time will be at 1:00am on whichever day in November (1 thru 7) falls on a Sunday, in the years 2007 thru 2038. The adjusted time will be 5 hours removed from UTC.”

Using these examples, you can construct your own TZTAB.LIB.SYS file  that satisfies the requirements of your particular HP 3000 system.

The bottom line to all of this: The TZTAB.LIB.SYS file, in conjunction with the TZ variable, is utilized by the MPE Posix environment, as well as some third-party software suites -- if and when necessary to accommodate GMT and local times.

If you can't find copies of NTPDATE or the TZTAB file, send me a request by email ([email protected]) and I will send you a copy of both in a single Reflection-label storefile format file. Thanks to Mark Ranft and Jeff Kell for assistance in acquiring these files.

Posted by Ron Seybold at 03:09 PM in Hidden Value, Homesteading | Permalink | Comments (0)

October 19, 2012

Changing Clocks for Good Maintenance

By Gilles Schipper

Second in a series

Two weeks from this weekend, Daylight Saving Time ends for 2012. It may be an appropriate time to think about implementing some best practices associated with “Clock Maintenance” for the HP 3000s that you administer. For example, there's the task of changing the system clocks for other than trivial or TIMEZONE changes.

Your system clocks can be inaccurate either because they are out of sync with each other (ie. wrong TIMEZONE setting) or they simply contain the wrong time, or both. If your problem is an incorrect TIMEZONE (as shown by the SHOWCLOCK command) you can easily and quickly correct with the SETCLOCK TIMEZONE= command.

Keep in mind that if this command would normally result in a backwards time adjustment, the change will take place gradually such that the system clocks will never go back in time.(This default behaviour can be overridden with the ;NOW option of the SETCLOCK command). If the SETCLOCK command results in a time advancement, the advancement takes place immediately.

Again, you can use the SHOWCLOCK command to see the current time, timezone as well as the pending time correction in seconds. If you are experiencing both a timezone problem and clock accuracy issues, that's another matter.

If you are experiencing both a timezone problem AND a clock accuracy issue, you can effect a correction as follows:

:setclock timezone=w5:00

:setclock ;cancel (which cancels any pending gradual changes and permits the subsequent setclock command to succeed.)

:setclock ;date=mm/dd/yy;time=hh:mm;now (the date/time should correspond to your desired “software” clock - ie, the actual location-specific date/time.)

Be careful if the above command sequence will result in the clocks being adjusted backwards that could affect any scheduled jobs or any running application that is date/time sensitive.

If the timezone is correct and you wish only to adjust your software clock, you can simplify by:

:setclock ;correction=no-of-seconds (plus or minus)

Regular Clock Maintenance

Now that you've set your system clocks appropriately, just like any nice-looking grass lawn, they need regular maintenance to stay nice-looking -- or accurate.

From my experience, HP 3000 system clocks are woefully inaccurate if left to their own. They tend to lose time over periods of time - notwithstanding power failures combined with non-functioning main-board batteries and UPS's, in which case the magnitude of clock discrepancy would be much larger.

The System Administrator can solve the clock maintenance problem in two ways:

1. Manually, by checking the system clocks at regular intervals with the SHOWCLOCK command, and, when necessary, issue the appropriate SETCLOCK command to effect adjustments, or

2. Automagically, by utilizing an available utility, called NTPDATE, scheduled to run at regular intervals to adjust your system clocks to the correct time.

Naturally, being a suitably lazy SysAdmin, I prefer option 2.

Since this utility works extremely well when used modestly, I choose to execute it once daily - at most. (Depending upon how inaccurate your system clock is and your tolerance for clock variances, you can choose to run it weekly or monthly)

The NTPDATE utility should be available from whoever is currently maintaining the old Interex contributed library, or an echo of the old HP Jazz site. It comprises a single program, called NTPDATE and can be located in PUB.SYS or whichever group/account you wish having PM capability.

To execute, simply

:ntpdate.pub.sys “pool.ntp.org”

It will synchronize your software clock with the time servers at pool.ntp.org and according to the value of your TIMEZONE setting. You can follow the ntpdate command with a showclock command to see if any adjustments were necessary. You can replace pool.ntp.org with any suitable time server that you prefer and have access to.

Placing this command in a regularly executing job stream will keep your system clocks accurate and worry-free while you work on other things. 

Next time: The nuances of HP's TZTAB file formats

Posted by Ron Seybold at 10:41 AM in Hidden Value, Homesteading | Permalink | Comments (0)

October 18, 2012

It's About Time

By Gilles Schipper
GSA Associates

First in a series

NeonClockWith the impending end of Daylight Saving Time (DST) -- just two weeks from this coming Saturday night -- it may be an appropriate time to think about implementing some best practices associated with “Clock Maintenance” for the HP 3000s that you administer.

To refresh your memory, beginning in the year 2007, DST was extended by approximately one month for most time zones in the US and Canada. Consequently, for most locations, DST now begins at 2:00AM the second Sunday every March, and ends at 2:00AM the first Sunday each November.

The rules for specific time zones are contained in a file named TZTAB.LIB.SYS, whose exact format and interpretation will be shown in detail later in this series. Suffice it to say, this file is largely irrelevant for the normal operation of the HP 3000. 

But it is relevant and important for various software products  that are common to the HP 3000 environment, including, among others, products by Nobix, IBM/Cognos, and Speedware -- but surprisingly not by a very useful utility, NTPDATE, which I'll describe in detail.

And for those products that do utilize the TZTAB file, it behooves to set the variable TZ to its appropriate value, for example:

:setvar TZ, EST5EDT (appropriate for the Eastern Timezone, which, during Eastern Standard Time, is 5 hours west of Greenwich Mean Time (GMT)). 

Two Clocks, Two Times

Each HP 3000 contains two separate clocks, commonly referred to as the hardware clock and the software clock.

Typically, the hardware clock is set at system boot time, with the ISL CLKUTIL command. This clock should be set to coincide with the GMT.

The software clock can be set at the ISL START NORECOVERY dialogue. This clock should be set to the actual local time in effect.

If both hardware and software clocks are set properly the system's TIMEZONE setting will reflect the difference between the two.

This can be checked with the command :showcloc

SYSTEM TIME: MON, SEP  3, 2012,  2:25:01 PM
CURRENT TIME CORRECTION:            0 SECONDS
TIME ZONE:    4 HOURS  0 MINUTES WESTERN HEMISPHERE

The SETCLOCK command

There are occasions when it's desirable to modify one or both of the hardware and software clocks - without requiring a system boot. The SETCLOCK command permits us to do exactly that.

As shown above, the SHOWCLOCK command will directly show you the value of the “SOFTWARE” clock (contents of SYSTEM TIME). 

The value of the “HARDWARE” clock is shown indirectly with the combination of SYSTEM TIME and TIME ZONE.

In the above example, the value of the “HARDWARE” clock is MON, SEP 3, 2012, 6:25:01 PM -- which is the value of the SOFTWARE clock plus 4 hours (TIMEZONE of 4 HOURS WESTERN HEMISPHERE). (If the TIMEZONE value showed EASTERN HEMISPHERE, the corresponding TIMEZONE value would be subtracted from the SOFTWARE clock to arrive at the HARDWARE clock.)

The SETCLOCK command has the following parameters:

SETCLOCK

Alters the system time or system time zone.

SYNTAX 

     SETCLOCK  {DATE= date spec; TIME= time spec [;GRADUAL | ;NOW]}
              {CORRECTION= correction spec [;GRADUAL | ;NOW]}
              {TIMEZONE= time zone spec}
               {;CANCEL}

You can see more detail associated with the individual parameters by issuing the command :help setclock, all

For those whose system clocks are generally quite accurate and properly maintained (and I will show you how to ensure that later), the command you will need to invoke twice annually is:

:setclock timezone=W5:00 (First Sunday in November, at 2:00AM, assuming Eastern Timezone)

and

:setclock timezone=W4:00 (Second Sunday in March, at 2:00AM, assuming Eastern Timezone)

These commands can be launched by a job stream that executes, say, once a week-- such as a full backup, for example -- by simply utilizing system date variables to calculate whether the following Sunday is either the first Sunday in November or second Sunday in March, and then stream a job that Sunday at 2:00AM which modifies the TIMEZONE with the appropriate SETCLOCK command.

However, there may be occasions when less granular modifications to your system clocks are necessary. One such occasion could be when your HP 3000 experiences the following conditions/events:

1. It shuts down (ungracefully) due to a power failure, and
2. It is unprotected by a UPS system, and
3. Its internal battery is no longer functioning 

The internal battery is what maintains the hardware clock. A non-functioning battery will cause your system to lose its proper clock value and typically boot up with a value of January 1, 1972 - or some ridiculously erroneous value like that.

Incidentally, this battery is easily replaceable - at least it is on my model 928. The battery it uses is a 3-volt lithium, Panasonic BR2325 - obtainable at most camera supply stores - but, hurry, camera supply stores, like the HP 3000, is a dying breed). If the Panasonic is unavailable, a suitable replacement would be a 3-volt lithium RENATA CR2325.

The battery is located on the main system board - the one containing the CPU, which you can also identify with its included black toggle switch donating “normal” when positioned to the left, and “service” when positioned to the right. To remove that board for battery replacement, you will need to remove the metal plate that covers the disabled RJ45 and AUI ports of the board.

Next time: The task of changing the system clocks for other than trivial or TIMEZONE changes

Gilles Schipper is founder of the system support supplier GSA Associates and Homesteading Editor for the 3000 Newswire.

Posted by Ron Seybold at 10:38 AM in Hidden Value, Homesteading | Permalink | Comments (0)

September 28, 2012

3000 Memoir Project: Wins from Easy Use

The 3000 Memoir Project is a living and growing history of your community, told by the server and its software. There are excepts of the book to be published next year, in paper as well as e-book formats. 2013 will mark the genuine 40-year anniversary of the system, while 1974 marks the start of the user group that integrated community pioneers.

We're looking for your stories of the first time you encountered a 3000. Call me at 512-331-0075, or send an email to the NewsWire's offices.

In this installment, the 3000 tells about relative ease of use versus mainframe standard, stories told to, and told by, Paul Edwards -- a former IBM mainframe manager, US veteran, and director of several user groups. By the HP 3000

I was sold on ease of use, and fun. 

PaulEdwards-atSaltLickI like what Paul Edwards and the others said about working with me, versus those entrenched mainframes. See, HP didn’t think of selling me as a big datacenter computer at the start. I was supposed to be a wheel-it-in computer. Some of my early ads showed people “rolling it up to the side of the desk,” Edwards says. My early models, the Series 30s and 40s, even had me built into desks as if I was part of the office furniture, instead of running the office.

That’s because I was a new idea in computers: something that regular office workers could manage, with the help of people like Edwards at HP.

They had a great database they gave me for good in 1976, IMAGE, and one of the fun examples of it used statistics from the NFL. Orly Larson at HP had cooked up the demo of IMAGE, “and every HP sales site had a copy of it. It was just a six-dataset database. But we’d say to the Systems 3 people, ‘let me show you how you can retrieve something, or update databases. They were amazed. It was fun. IBM systems weren’t fun – they were work.”

Edwards says that back in those early days, you couldn’t take fundamentals for granted. Like just writing a file. Me, I did it like a swimmer just jumping in after years of practice, not even thinking about it. “When I came to the 3000, I didn’t have to worry where on a disk I was going to put a file,” he says. “I just wrote out a file. On the IBMs, I had to specify which sector, which disk platter.” He called it one of the most advanced bits of tech that I had when he first started using me.

He says the other magic that made me easy was IMAGE, my strong heart of a database. I even had a built-in QUERY, something that the other computers’ owners had to write themselves. “It was fascinating to me,” Edwards says, “because you could just build an application with QUERY on the fly. You could just send a report out to a printer and show it immediately to the customer. It was the ease of sitting down to the terminals and developing with COBOL and IMAGE. Tools like QUERY, FCOPY for files, they would’ve loved to have had all of those built-in on the mainframes. I thought I’d died and gone to heaven.”

Of course, my console was a 50-pound beast, the 2640 or 45. This wasn’t a weight contest, so I could even have little tape drives in those consoles. I also had card readers to help Edwards and his cohorts absorb the IBM mainframe programs into my MPE. HP gave me my own version of RPG — that code still feels funny on my bones — which was a lot like IBM’s RPG, Edwards says. He’d do my updates, in the earliest days, by using 9-track tapes with a new version of MPE. I even had a paper tape reader for early demos, although the tape wasn’t paper — it was really mylar.

Comparing tape to disk was another place where I could shine in stealing IBM’s customers. Edwards worked in Frito-Lay’s manufacturing operations before he joined my family.  “I went from a tape-based operating system to a disk-based one,” he says. “It was light years ahead of the mainframe.”

I had a lot of ardent fans coming on in those days. People would punch out programs on cards from the System 3s, then go to work using the Data Entry Library. It was my first part of my body that had a human name: the DEL/3000. “We’d build the screens quickly, so the customers could come in and review them,” Edwards says. They’d give HP guys T-shirts from my birthplace in California that said, “Series I Has Begun.” Call them out to what they called the factory, back when they actually built me next to the labs, so they could learn something new and sometimes have beer blasts afterward in the parking lots. They they’d go back and cross-train the others at their HP offices. SEs and CEs collaborated.

Eventually Edwards left my Dallas office to go out on his own. A lot of the sharp SEs would do that in the early ‘80s, when he was just getting a fresh start as an indie consultant. He worked with Speedware on projects, taught things like Robelle’s Suprtool. From a time when my 7910 disks, with one fixed and one removable platter, held just 10 Mb, I’ve grown my reach into places like 500Gb disks, and maybe soon, up in that vague and uncharted storehouse for data called the cloud. Edwards tells me that he’s still got a Series 928 of his own at home that he fires up for consults. “Once or twice a year I’ll vacuum out the fuzzies, but other than that, it just runs,” he says. I like that reputation. I’ve held on more than three times as long as Windows XP, another computer body that Edwards says has fierce loyalists. I might get inspired by Paul to go to newer heights. He wants to take his FAA exam to extend his piloting experience, so he might get to fly classics in the Commemorative Air Force like the T-28 trainer — a prop aircraft that’s 20 years older than me. “They’re now looking for younger guys,” Paul says about the CAF, “but not necessarily that much younger.”

Posted by Ron Seybold at 11:20 AM in Hidden Value, History, Homesteading | Permalink | Comments (0)

September 06, 2012

Core memories spark a cold start for 3000s

Editor’s Note: Jon Diercks, the author of the only comprehensive MPE/iX administration book, offered us this story of the 3000’s very first year. It was a time of HP retreat from the minicomputer market: HP staff resigning, others unselling a system touted just months earlier as “a happening,” as the slogans of 1972-73 said in HP labs and offices.

Diercks worked at Anderson University in the 1990s alongside Tom Harbron, who’d been the college’s computer department director during 3000’s first months on the market. Diercks said Harbron was heavily involved in early discussions with HP about MPE and IMAGE. 

The institution began as Anderson College, and its very first HP 3000 was one of the earliest models. Diercks said the bragging line in those days was "Anderson College has the first HP 3000 ever installed anywhere between the Rockies and the Appalachians."

Harbron’s report on the 3000’s 1973 is part of Diercks’ 3000 memories, and so he’s contributed the writing as part of our 3000 Memoir Project — in all of its authentic, human and humbling beginnings. It's the first story I've read that details the 3000's retreat. An HP employee who couldn't look his customers in the eye about the 3000, and so resigned. A man whose job was to unsell the 3000s -- and later would bundle the greatest software HP ever wrote, IMAGE, to the Classic hardware, which not long after, fell behind the state of the art.

By Tom Harbron

Reports of problems with the HP 3000 operating system, MPE, continued to be received in the opening weeks of 1973. While it was not encouraging, I had confidence in the basic soundness of the 3000’s design and the integrity of Hewlett-Packard to ultimately deliver what had been promised.

HP’s Phil Oliver called and scheduled a meeting with me for February 6, 1973.  He brought along Bob Stringer, who had replaced Ed Pulsifer as the District Sales Manager; Ed McCracken, who was now HP's Market Manager for Government, Education, and Medical Markets; and Jay Craig, who was a new HP salesman from Indianapolis. McCracken would tell me, years later when he was the 3000 division manager, that the morning in my office was the most difficult day of his career. The people that HP hired were, mostly, an honorable group of people.

On that day in 1973, they had some bad news to deliver. Specifically there were seven points:

1. HP cannot bring the software components of the system up to full specifications before Fall 1973.

2. They are devoting “maximum resources” to correcting the problem.

3. The system will currently support no more than 4-6 simultaneous users.

4. HP will loan an additional 64K bytes of core storage to bring the system up to this 4-6 user level of performance.  (We had ordered the system with 64K bytes of core storage.)

5. IMAGE will be further delayed to January 1974.

6. Because of hardware difficulties, a slower console printer would be provided.

7. They would like us to cancel the contract.  Lacking that, they wish to amend the contract.

It was a tense meeting. McCracken was going about the country, visiting customers, and unselling the 3000. It was hard for everyone. Phil Oliver would return to his office later that day and resign. He told me he couldn’t look his customers in the eye. Ed Pulsifer had already resigned for similar reasons. 

I resisted their pleas to cancel the contract for four fundamental reasons. 

First, I had faith in the basic design of the system. I had run benchmarks that had come in almost exactly where I had predicted from the timings in the ERS. MPE was clearly a better design than nearly anything else then available. The combination was more cost effective than anything else by a factor of two or three. Moreover, I had met many of the people involved with the project and had confidence that they could do the job, given the time and resources.

Second, there really were no viable alternatives on the market at the time. DEC tried long and hard to sell us, but in the end their salesman conceded that the systems DEC had were either too feeble or far too large for our needs; the HP 3000 was a perfect fit. IBM tried hard to sell us on various timesharing patches to their systems, none of which worked well. The only systems available that would do the work were the XDS Sigmas and they cost five times as much as the 3000.

Third, I thought that HP had to make the 3000 succeed if they were to remain a growth company.  At that time, HP had about half of the instrument market and could not significantly expand their market share without anti-trust problems.  Their other market areas, such as microwave, were respectable, but in small markets that were not growing very fast.  

The only way that HP could continue to grow at historic rates was by entering the computer business in a major way. With $25 million already invested in the 3000, they were unlikely to write off that investment and content themselves with their existing markets.  If the 3000 failed, they would have had to immediately start over on another computer project.

Fourth, we had already invested several man-years in application development for the HP 3000 at the time that HP was trying to unsell the system.  It would have been a financial disaster for us to write off all of that work and begin again with a different system.  We really had no option beyond the 3000.

Years later, in a speech before the Users’ Group, McCracken said “I want to thank those of you who had faith that the HP 3000 would succeed at a time when many at HP had profound doubts.”  I’m sure he was thinking of that cold February day he spent in my office.

Posted by Ron Seybold at 05:55 PM in Hidden Value, History, Homesteading, User Reports | Permalink | Comments (0)

August 30, 2012

In the Beginning, There Was Tape

By Brian Edminster
Applied Technologies

First in a series 

In the beginning, there was tape. And if you’ve been around awhile, you remember it was on big reels about a foot across, was about a half-inch wide, and could have as much as 2400 feet of it on a reel. Yeah, they were heavy, too.

Data was recorded in parallel ‘tracks’ along the length of the tape. In this case nine of them, hence the name ‘9-track’ tape. At 800 bpi, that yielded a capacity of nearly 20Mb. Later technology allowed higher density, when 1600 bpi upped that capacity to about 120Mb. The last incarnation of 9-track was a whopping 6250 bpi — yielding nearly 1Gb of storage for a single reel of tape.

By comparison, anyone can get USB flash-drives that’ll hold 16Gb for $10 down at Walmart. 

Very few, if any later model 3000’s (those that run MPE/iX vs. MPE/V) will even have a 9-track tape drive on them. And that’s a good thing. These 9-track tapes take up far too much physical storage space, and are far too slow to read and write. They might have been okay, back when disk drives were 50Mb, 120Mb, 404Mb, or even 570Mb (the capacities of the old HP 7920, 7925, 793x, and 7937 disk drives, respectively).

Unfortunately, a 2Gb drive is pretty much the smallest drive you’ll see on a 3000 these days, and larger drives are more common. This presents a problem: What do you do when it takes potentially dozens of tapes — and many hours — to do your daily backups?

Again, advancing technology comes to the rescue. Instead of further density increases on 9-track tapes, a variant of the digital cartridge tape called DDS (Digital Data Storage) came into common use for backups. For any new managers who haven’t seen one, a DDS cartridge is just a little smaller than a standard pack of cigarettes.

DDS drives and media also progressed in technology over time, growing in both speed and capacity (and generally, in reliability as well) as the table below shows.

TapeTableSmAs it turns out, transfer speed (how fast the drive can read/write data) also scaled upwards as capacity grew — so that even if you didn’t need the capacity, there’s often a speed advantage to the larger capacity drives. For any system that needs a new or replacement DDS drive, I’d never recommend anything less than a DDS3, unless there was an absolute requirement to write DDS1 tapes. 

Also note that once you get to DDS3 and beyond, you’ll likely need a dedicated SCSI channel for the drive, in order to take advantage of the drive’s speed. If you cannot keep the tape drive’s buffers fed, it has to stop and re-position, which slows it down significantly. Note that this can occur while reading tapes as well. 

If you have sufficient CPU capacity available, software compression can also speed up reading/writing of backups by reducing the amount of data sent to and from the drive. I’ve also heard from people I trust that you are unlikely to experience the difference in backup time which is implied by read/write speed difference between DDS4 and DDS5 — at least not when attached to a 3000.

As I mentioned in an article covering VSTORE on the NewsWire’s blog, DDS drives slowly lose alignment as they wear. They have a remarkable tolerance for this, all things considered (especially DDS3 and subsequent drives). It’s still something to be on guard for, especially if you’re relying on your backups to be readable when the chips are down. 

Regarding media reliability: various sources give differing answers, but as a general guideline DDS tapes will take about 100 passes or so before they wear out. If you use the same tape once a week, expect to get about two years life out of it, before it wears out. You could get more uses, but the longer you go, the farther you’ll get into borrowed time territory. Don’t expect a catastrophic failure, but you’ll have to clean the drive more often. And face possible write failures and/or VSTORE failures. 

Failure is not something you want to tempt by scrimping with your backup tapes. Buy the best quality you can, and replace them yearly. Like doing backups in the first place, it’s cheap insurance. Would a rock climber wait until his ropes break before replacing them? I know I wouldn’t.

Next time: New media for a new millennium

Posted by Ron Seybold at 06:46 PM in Hidden Value, Homesteading | Permalink | Comments (0)

August 28, 2012

Porting to Posix on the HP 3000

One of the leading lights in HP 3000 development has been researching how to port software to Posix under MPE/iX. David Dummer, who created DataExpress and played a major role in making Transact a genuine language, was looking for help to resolve an error while compiling.

Why would a 3000 homesteader want to port software to Posix? One reason is to ready an application for the journey to one of the *nixes, like HP-UX or Linux. Here's Dummer's dilemma.

I have been trying for some days to port a Unix application to an HP 3000. One of the source files contains calls to the Posix functions of 'tcgetattr' and 'tcsetattr' for terminal handling control. I compile this source under the Posix shell, as the MPE C compiler doesn't appear to be able to find the included 'termios.h' header file. The application program is then created by the MPE linkage editor.

At execution time the loader denotes the two Posix functions as unresolved externals. From my reading of articles on Porting to Posix I would have expected these two functions to be in the relocateable library file '/lib/libc.a' 

I then decided to write a makefile and to perform all of the compile and build functions under the Posix shell. This appears to cure the missing function problem, but the resulting application aborts before reaching the first statement in the mainline program.

Mark Bixby, who wrote that seminal resource on porting to MPE applications to open source, weighed in with some advice for developers.

Bixby was cautioning homesteaders as far back as 2002 that they'd need to get comfortable with porting, because crucial 3000 software was certain to be in need of upgrades over the life of a homestead installation. Bixby's now working at K-12 app provider QSS, which is still supporting HP 3000 apps.

My extensive MPE Posix porting knowledge has largely been recycled in the eight or so years since I last did substantive MPE work. But if I recall correctly, the libbsd distribution -- or perhaps was it the Posix porting wrappers -- which used to be available from jazz.external.hp.com contained tcgetattr and tcsetattr implementations.

Lars Appel, another prodigious porter who moved Samba across to MPE/iX, pointed at repositories of these wrappers which are still online, hosted in the independent community now that HP's closed down that HP 3000 Jazz server.
As far as I recall, Steve H's porting wrappers also included those two. The Client Systems main Jazz page leads to http://clientsystems.com/portwrappers650.html

And you can typically only compile and use those few routines that you need -- you don't have to build and link the whole wrappers package.

More advice came about the Posix shell commands cc or cc89, a script with lots of extras added. Reports said it was pretty tricky to replicate that at the MPE command prompt. So the first rule of success would be to compile Posix programs only under the Posix shell.

MPE: run .\testposx;unsat=debug will get a developer to debug, for anything that was called but not available. Otherwise, use MPE: run .\testposx;debug

Posted by Ron Seybold at 04:53 PM in Hidden Value, Homesteading | Permalink | Comments (0)

August 22, 2012

Securely Storing Passwords

Editor's Note: Security is one of the limiting factors in adopting cloud computing. HP, as well as its partners, will tell you that cloud computing and similar remote access is a forward-thinking alternative to HP 3000 centralized on-site computing. But there's that security thing.

More than 30 years ago VEsoft's Eugene Volokh chronicled the fundamentals of security for 3000 owners trying to protect passwords and user IDs. Much of that access hasn't changed at all, and the 3000's security by obscurity has helped it evade things like Denial of Service attacks, routinely reported and then plugged for today's Unix-based systems. Consider these 3000 fundamentals from Eugene's Burn Before Reading, hosted on the Adager website.

Logon security is probably the most important component of your security fence. This is because many of the subsequent security devices (e.g. file security) use information that is established at logon time, such as user ID and account name. Thus, we must not only forbid unauthorized users from logging on, but must also ensure that even an authorized user can only log on to his user ID.

If one and only one user is allowed to use a particular use ID, he may be asked to enter some personal information (his mother's maiden name?) when he is initially added to the system, and then be asked that question (or one of a number of such personal questions) every time he logs on. This general method of determining a user's authorizations by what he knows we will call "knowledge security."

Unfortunately, the knowledge security approach, although one of the best available, has one major flaw -- unlike fingerprints, information is easily transferred, be it revealed voluntarily or involuntarily; thus, someone who is not authorized to use a particular user id may nonetheless find out the user's password. You may say: "Well, we change the passwords every month, so that's not a problem." The very fact that you have to change the passwords every month means that they tend to get out through the grapevine! A good security system does not need to be redone every month, especially since that would mean that -- at least toward the end of the month -- the system is already rather shaky and subject to penetration.

There's a broader range of techniques to store passwords securely, especially important for the 3000 owner who's moving to more popular, less secured IT like cloud computing. We've asked a security pro who manages the pre-payment systems at Oxygen Financial to share these practices for that woolier world out there beyond MPE and the 3000.

By Steve Hardwick, CISSP

There has been a lot in the news recently about password theft and hacking into email accounts. Everything needs a password to access it. One of the side effects of the cloud is the need to be able to separate information from the various users that access a centrally located service. In the case where I have data on my PC, I can create one single password that controls access to all of the apps that reside on the drive plus all of the associated data.

There is a one-to-one physical relationship between the owner and the physical machine that hosts the information. This allows a simpler mechanism to validate the user. In the cloud world it is not as easy. There is no longer a physical relationship with the user. In fact a user may be accessing several different physical locations when running applications or accessing information. This has led to a dramatic increase in the number of passwords and authentication methods that are in use.

I just did a count of my usernames and passwords and I have 37 different accounts (most with unique usernames and password). Plus there are several sites where I use the same usernames and password combinations. You may ask why are some unique and why are some shared. The answer is based on the risk of a username or password be compromised. If I consider an account to have a high value, high degree of loss/impact if hacked, then it gets a unique username or password.

Email accounts are a good example. I have a unique username and password for my five email accounts. However, I do have one email account that is reserved solely for providing a username for other types of access. When I go to a site that requires an email address to set up an account , that is the one I use. Plus, I am not always selecting a unique password. The assumption is that if that username and password is stolen, then the other places it can be used are only other web site access accounts of low value. I also have a second email account that I use to set up more sensitive assess, google drive for example. This allows me to limit the damage if one of the accounts is compromised, and so I don't end up with a daisy chain of hacked accounts.

So the next question is how do you go about generating a bunch of passwords? One easy way is to go into your favorite search engine and type in password generator. You will get a fairly good list of applications that you can use to generate medium to strong passwords. But what if you don't want to download an application -- what is another way?

When I used to teach security this was one trick I would share with my students. Write a list of four or five short words that are easy to remember. Since my first name is Steve we can use that. This of four or five short number 4-5 digits in length 1999 for example. Now pick a word and number combination and intersperse the numbers and letters S1t9e9v9e would be the result of Steve and 1999. Longer words and longer numbers make strong passwords – phone numbers and last names works well. With 5 words and 5 numbers you get 25 passwords. One nice benefit of this approach comes when you need to change your password. Write the number backwards and merge the word and data back together.

Next: How to remember all of those passwords. 

Steve Hardwick (CISSP) is the Product Manager at Oxygen Financial, which offers advanced payment management solutions. He has over 20 years of worldwide technology experience. He was also a CISSP instructor with Global Knowledge for three years and held security positions at several companies.

Posted by Ron Seybold at 02:49 PM in Hidden Value, Migration, Newsmakers | Permalink | Comments (0)

August 07, 2012

Follow that VSTORE onto other drives

Editor's note: After reading our article on SLT creation and validation yesterday, consultant Brian Edminster adds some notes on how to employ VSTORE in your 3000 management. He's also working on an article that covers backup automation.

By Brian Edminster
Applied Technologies 

If possible, do your VSTOREs on a different (but compatible model) of tape drive than the one the tape was created on. Why? DDS tape drives (especially DDS-2 and DDS-3 models) slowly go out of alignment as they wear.

In other words, it's possible to write a backup tape, and have it successfully VSTORE on the same drive. But if you have to take that same tape to a different server with a new and in-alignment drive, you could have it not be readable! Trust me on this -- I've had it happen.)

If you'll only ever need to read tapes on the same drive as you wrote them, you're still not safe. What happens if you write a tape on a worn drive, have the drive fail at some later date -- and that replacement drive cannot read old backup tapes? Yikes!

Using the 'two-drive' method to validate backup (and even SLT) tapes is a very prudent choice, if you have access to that array of hardware. It can also often help identify a drive that's going out of alignment -- before it's too late! 

There's another possible media choice, using store-to-disk. which I'll be writing about shortly.  

Unfortunately, SLTs have to be written to tape (at least, for non-emulated HP 3000s). However, your drive will last years longer if you only write to it a few times a year.

Posted by Ron Seybold at 01:13 PM in Hidden Value, Homesteading | Permalink | Comments (0)

August 06, 2012

What You Need to Do and Check for SLTs

At a recent visit to a customer's shop, VEsoft's Vladimir Volokh spread the word about System Load Tapes. The SLTs are a crucial component to making serious backups of HP 3000s. Vladimir saw a commonplace habit at the shop: Skipping the reading of the advice they'd received.

"I don't know exactly what to do about my SLT," the manager told him. "HP built my first one using a CD. Do I need that CD?"

His answer was no, because HP was only using the most stable media to build that 3000's first SLT. But Vladimir had a question in reply. Do you read the NewsWire? "Yes, I get it in my email, and my mailbox," she said. But like other tech resources, ours hadn't been consulted to advise on such procedures, even though we'd run an article about 10 days ago covering CSLTs. That tape's rules are the same as for SLTs. Create one each time something changes in your configuration for your 3000.

Other managers figure they'd better be creating an SLT with every backup. Not needed, but there's one step that gets skipped in the process.

I always say, "Do and Check," Vladimir reports. The checking of your SLT for an error-free tape can be done with the 3000's included utilities. The venerable TELESUP account, which HP deployed to help its support engineers, has CHECKSLT to run and do the checking.

There's also the VSTORE command of MPE/iX to employ in 3000 checking. If your MPE references come from Google searches instead of reading your NewsWires, you might find it a bit harder to locate HP's documentation for VSTORE. You won't find what you'd expect in a 7.5 manual. HP introduced VSTORE in MPE/iX 5.0, so that edition of the manual is where its details reside for your illumination.

It's also standard practice to include VSTORE in every backup job's command process.

There's another kind of manager wouldn't be doing SLTs. That's the one who knows how, but doesn't do the maintenance. You can't make this kind of administrator do their job, not any more than you can make a subscriber read an article. There's lots to be gained by learning skills that keep that 3000 stable and available, even in the event of a disk crash. Management might not respect the 3000's ability to take on new developments. But a company always respects the 3000's reliability.

CHECKSLT, and care and feeding of SLTs, are well-covered in a NewsWire column written by John Burke almost 13 years ago. His advice still holds today.

HP’s documentation tells us we need to have a current SLT. And that it can be created using the TAPE command within SYSGEN. If you look hard enough you will also find the warning that the CSLT you may have created when doing an update or manage patch is not adequate. That is about it for SLT recommendations.

Is this recommendation correct? Well, in the sense that it is necessary to have an SLT created by the TAPE command, then, yes, it is correct. You can re-install your system in the event you lose a drive in the system volume set using this SLT and appropriate other backups. But is this recommendation complete? I think not.

As has been proven countless times, the people who write manuals (and not just at HP) are not out in the real world. They are not running shops where if you get a six-hour maintenance window once a month you consider yourself lucky. They are not running shops where you have to have procedures that can be understood and followed by someone with only basic training in system operation. They are not running shops where cell phones go off like July 4th fireworks as soon as anything unusual happens.

You can find HP's VSTORE page in that 5.0 command manual online, just like the NewsWire's advice. Vladimir, you find him in your office, if he's traveling your way. But managers also find that he recommends our advice -- perhaps because we first get the instructions to do it, and then have our reports checked. Do and Check are words to live by, not just for managing 3000s.

Posted by Ron Seybold at 04:40 PM in Hidden Value, Homesteading, User Reports, Web Resources | Permalink | Comments (0)

July 27, 2012

MM/3000 stalwart serves, stocks 3000 docs

We're still thinking about how to organize and capture the wealth of lively links at hp3000links.com. This site has been without an administrator for most of a year, and it's still got more than 100 links on it that lead to useful information.

But the links to HP's documentation on the 3000's software and hardware go nowhere. Most of them were hosted on HP servers that have either been retired -- like the 3000 division's Jazz webserver -- or they point at a baffling HP webpage where somewhere or other there's a way to find documentation.

However, there's another web resource that seems to pop up quickly when we do a search for HP manuals like the MPE/iX 7.5 Maintenance Manual. It seems that one of the stalwarts of the HP Manufacturing Management application, Scott Petersen, has been stockpiling 3000 manuals at his hpmmsupport.com site. MM/3000, as it was called through the '90s, sold a lot of new 3000s -- because in choosing a platform it's all about the application, isn't it?

It is, until you make that choice, and then you're facing system administration like keeping an SLT up to date for your 3000. How to create a CSLT is part of that 7.5 manual. Petersen's site has it and much more.

HP's official position on this kind of document archival has been in flux. For awhile in the 2008-2010 era, the manuals were supposed to be in HP's websites only, or hosted as part of a licensing agreement with a third party. At one point HP was saying the manuals wouldn't go public until 2015. But HP's got bigger woes to resolve than whether's there's too much exposure for its 3000 manuals. HP won't even sell you support for your system by now. Unless you insist.

Petersen said that access to these documents is vital to supporting the 3000.

I have needed the 3000 information in the past and felt that it was a good community service to place the manuals and other things oout there for all to see. I am a pack-rat and decided that having access to the information was critical.

Petersen adds that he's "always on the lookout for things that might go away relating to the 3000, and adding them to the site if it is appropriate." MM/3000 didn't go away after HP dropped it. The software was bought and revived and expanded by former HP employees who became eXegeSys, with products named to match. Manufacturers were surprised, too. But the apps have supported a diverse group of users from governments, sports clubs, job shop manufacturers, process manufacturers and pharmaceutical companies.

Many of these have migrated to other applications. Our goal is to continue the process of high quality support for those organizations that have either not been willing or able to move to another platform and application. We knew the application when it was designed, and we are aware of how customizations have allowed the application to change.

This was an application vendor as surprised as any about HP's exit from the 3000, if memory serves from my meeting with them in 2002. But they've perserved, well beyond HP's capabilities. Things don't go away easily in a community stocked with these kinds of stalwarts.

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

July 25, 2012

Matches of Mountain Lion and MPE/iX

By Brian Edminster
Applied Technologies

Mountain-lionI follow far too many blogs, in my vain attempt to stay informed on the state of technology (software, hardware, and other). When Apple released its state of the art OS today, I kept on researching. As a byproduct of those attempts, I happened on an article from Information Architects, Mountain Lion’s New File System, and found it quite interesting.

In short, it appears that Apple -- in working to move away from a many-leveled folder hierarchy to 'force' a two-level hierarchy in its file-systems (iOS, and now in OSX) -- is now basically moving towards where MPE was from the beginning.

In MPE's case, it's Account and Group, rather than Application, and folder within Application. But the resemblance is striking.

MPE applications can 'see' -- and when necessary -- access, across accounts. I'm not entirely sure how that'll be achieved in OSX or iOS, although I'm fairly sure that those better-versed in Apple products could point it out to me.

I also noted that, perhaps for different reasons of which I'm not sure -- I'm going purely on conjecture here --Microsoft is doing the same basic thing in its folder structures. The folder structures in Windows 7 are becoming more libraries of 'kinds of things'-based, plus it tries to 'hide' you from the 'pathing' to get to a file. So far, I find their implementation far less satisfying that Apple's has been.

I can't honestly say that (for the filesystem structure, at least) that MPE was so far ahead of its time that other OS's are just now catching up. But I am curious about what drove the two-level structure. Perhaps someone who worked in the labs might have that insight to share. 

Regardless of the reason, good designs often converge in a particular direction or way. And I suspect that this may be an example of that as much that as anything else.

I know that the late Wirt Atmar of AICS Research firmly believed in simple paradigms for storage concepts (often explained as file-cabinet drawers and folders) -- and that MPE's filesystem fit that quite well. He firmly believed that was one of MPE's great strengths.

Posted by Ron Seybold at 05:20 PM in Hidden Value, Newsmakers | Permalink | Comments (2)

July 24, 2012

Make backups, but a CSLT is just as vital

Many homesteading HP 3000 shops are working with limited system administration. If you're reading this blog, that probably doesn't apply to your own 3000 shop. But you can pass on advice about backing up to any 3000 site you know. A backup of applications and databases isn't enough.

The CSLT needs to be fresh and available, too. The Custom System Load Tape tells the 3000 how the configuration is set up for devices attached to the system that you're restoring. (The original SLT that was distributed from HP has a generic configuration. This customized SLT reflects your physical configuration of your specifically-built system.) Also referred to as a boot tape, it contains the system load utilities, diagnostic subsystems, base system files, and other HP system files such as IMAGE, FCOPY and EDITOR.

A CSLT is generated with the system generator (SYSGEN) utility. You can build a CSLT for individual systems, each with a different configuration, after updates. These configurations tell the 3000 what other volumes are available to accept data. You can also put a full backup on the end of a CSLT, but it's better to have that backup on separate tapes. (Separating a backup from the CSLT also speeds up creating a CSLT.) Consultant Paul Edwards advises that managers make a CSLT at least every other time during a backup, plus having two tape drives on each system. "Being paranoid makes for a good system manager," he says. "If you're not paranoid enough, you better have a good resume."

Overlooking the CSLT is so common that even some admin pros have done it from time to time. For one such pro, an A-Class 3000 was recently rebuilt and had its apps consolidated. But the rebuilt system didn't have its CSLT freshened, which was discovered when the boot volume failed. 

We lost LDEV1 in the 'system' volume-set. The apps and databases are fine, but I'd neglected to make a fresh CSLT once the rebuild/configure/setup was complete. Fortunately, all the data volumes are protected with Mirror/iX -- but rebuilding the system volume accounts, network config, administration jobs and so on has been a pain.

An honest mistake like this is not one you need to make yourself. Even if, as another 3000 consultant notes, your shop has gone into Frugal Mode while it makes in-house moves. You have the right to be wrong in Frugal Mode. But you really don't want that right, unless you've got plenty of extra time.

"This is not a mistake I'll ever make again," said our CSLT rebuilder. "Until it's complete and stable, I now make a new CSLT at the end of each day's changes (in addition to the regular backups we do as Store-To-Disk, and then FTP to a NAS). Hopefully I'll never have to go through this hassle again."

AUTOINST updates temporary copies of the system libraries and then creates a CSLT. This can take up to two hours. One set of instructions to do this is available in HP's MPE/iX 7.5 Maintenance Manual. The process hasn't changed much from the 6.0 release of MPE/iX, either. We've got a pointer to each manual; just search for "CSLT" in each PDF file.

We've previously published a paper by Gilles Schipper on the use of BULDACCT versus the STORE command while backing up. The ;DIRECTORY and ;ONVS= options are a key there. What's more, one of our most prodigious contributors Brian Edminster is sketching out a technical, but easy-to-use, Automation of Backups and Effectively Eliminating Use of Tapes article.

Do all the backup that you need when protecting that HP 3000. It's a computer that established the gold standard for recovery in case of powerfail situations. But the success of its backups falls in the lap of the system's managers or owners. (Running CHECKSLT from the TELESUP account will verify if a CSLT is still good enough to boot your system. You'll want that CSLT to run on any tape drive, not just the one it runs on. Alignment issues kick DDS drives out of service regularly.) Don't forget about keeping your CSLT healthy.

Posted by Ron Seybold at 04:13 PM in Hidden Value, Homesteading, Migration, User Reports | Permalink | Comments (0)

July 13, 2012

Use MPE Input Files to Create Output Files

Intrinsics are a wonderful thing to power HP 3000 development and enhancement. There was a time when file information was hard to procure on a 3000. It was a long time ago, as I was reminded by Olav Kappert in his call about his HP 3000 history. "The high point in MPE software was the JOBINFO intrinsic," he said. Kappert started with the 3000 in 1979.

Fast-forward 33 years later and you'll find questions from a different programmer still working on a 3000, adding features to a system. The Obtaining File Information section of a KSAM manual on MPE/iX holds an answer to what seems like an advanced problem. That manual sits in a tucked-away corner of HP's website today, the HP Business Support Center page for 3000 documentation and manuals.

I'm still using our old HP 3000, and I have access to the HP COBOL compiler. We haven't migrated and aren't intending to. My problem is how to use the characteristics of an input file as HPFOPEN parameters to create an output file. I want that output file to be essentially an exact replica of the input file (give or take some of the data). I want to do this without knowing anything about the input file until it is opened by the COBOL program. 

I'm using FFILEINFO and FLABELINFO to capture the characteristics of the input file, after I have opened it. After I get the opens/reads/writes working, I want to be able to alter the capacity of the output file.

Francois Desrochers replies

How about calling FFILEINFO on the input file to retrieve all the attributes you may need? Then apply them to the output file HPFOPEN call.

Donna Hofmeister adds 

You might want to get a copy of the "Using KSAM XL and KSAM 64" manual. Chapters 3 and 4 seem to cover the areas you have questions about. Listfile,5 seems to be a rightly nifty thing.

But rather than beat yourself silly trying to get devise a pure COBOL solution, you might be well advised to augment what you're doing with some CI scripts that you call from your program.

In a lively tech discussion on the 3000-L list, Olav Kappert added, 

Since you want to do this without knowing anything about the input file until it is opened by the COBOL program, the only way is to use one of the MPE intrinsics to determine all the characteristics of the file in question. Then do a command build after parsing that information.

Michael Anderson added details on how the 3000's CI scripting can build upon the fundamentals of file information and COBOL.

I like Donna's plan.This is a strategy that will also help whenever you want similar functionality on a NON-MPE platform. Also, although COBOL is very capable, an external script might be a better tool. You don't always need a hammer.

This is hypothetical, to try to make a point. From your MPE CI prompt, type HELP FINFO. You should be able to set some variables (SETVAR FILEA "XXX"), and using FINFO add some more variables. Then from COBOL using HPCIGETVAR, string together a BUILD command (with a bigger LIMIT maybe), and call "HPCICOMMAND". You could string the build command from a command, into a single variable, then COBOL only needs to HPCIGETVAR once.

You can also write a script to do everything you want, and call HPCICOMMAND to run the script, pass it parms. It's pretty cool, and it makes your COBOL application more portable. (Same program, different script).

For example: On MPE I once wrote (using COBOL) a small utility to CALL DBINFO, extract all the meta-data from any IMAGE database, and then create, and write to the NEW KSAM COPYLIB, ending up with all the COBOL copylib modules needed for all datasets for any database, including call statements and working storage. My point to all this: I used CI scripting to create and write to the copylib. I actually used ECHO to write the copylib ksam file from a CI script. Now, seeing how I work more on HP-UX and Linux, plus OpenCOBOL and Eloquence, I should be able to compile this same program on Linux with minimal modifications, only changing the external script.

I use this method to access SQL databases, and much more, using OpenCOBOL and the Tcl/Tk developer exchange. This way I can run the same program, same script almost anywhere, no matter, Windows, Mac, or Unix.

Eric Sand, another veteran of the 3000, commented that this kind of challenge really shows off the range of possibility for solving development problems. "You can create almost any cause and effect in MPE that you can imagine," he said. "Reading about your concern gave me a little rush, as I mentally organized what I wanted to do to address your concern."

Posted by Ron Seybold at 05:50 PM in Hidden Value, Web Resources | Permalink | Comments (0)

July 11, 2012

Web console resets, environment rebuilds, dumping form printers lead Hidden Value

I switched from an A400 to an A500 some time back, and I only realized I had not set up the remote web console after the console was down. Where can I configure this? This last time my only access was via VPN, or verbally over the phone. ("What can you see? Okay, so type...") I want to be able fix this myself next time. The console is the built-in one, and not an external box.

Gilles Schipper replies

You can configure your web console from the main console via the GSP interface. Specifically, the command you're looking for is LC (LAN configuration).

This command can be invoked even while the system is up and running by typing ctl-B (control and B together). For more help, at the GSP interface, type HELP, then HELP LC. 

Craig Lalley adds that if you arrive at a password roadblock and need to clear a console back to the default login, "at the physical console, hit the GSP reset in the back of the system, then press P on the keyboard. It will reset the passwords."

I need to rebuild an environment from one HP 3000 system to another. Trouble is, we want to have groups from the same account end up on different user volumes. Is there a way to do this using BULDACCT? 

Keven Miller adds

BULDACCT was made for processing complete accounts. Do BULDACCT  CHC%VSACCT=MEDADV_1. Then edit BULDJOB1 for the other group, changing MEDADV_1 to _2

After Donna Hofmeister notes that "newacct has to be done on both volumes," Mark Ranft replies 

What I usually do is use BULDACCT to move the entire accounting structure. Then I surgically PURGEGROUP and NEWGROUP (with the appropriate HOMEVS= and ONVS= options, plus CAP= and ACCESS= etc) to duplicate the special groups.

Jim Hawkins notes

MPE/iX RESTORE supports changing volume set specifications on RESTORE (vol, volclass volset) . That is, you can take files/groups/accounts originally on one volume set and place them onto another volume set.

We are still using multipart pre-printed forms and RS-232 dot matrix printers, all direct connected to our HP 3000 for our MANMAN purchase orders, invoices and checks. Obviously, these old HP printers are getting tired and problematic. Our immediate target is the printing of purchase orders. Are there ways to migrate from these form-based printers without breaking the bank?

Lisa Christiansen replies

One option that would work without requiring programming expertise is using ByRequest software from Hillary. We are taking the print ques from MANMAN and overlaying the form/jpeg to print the forms. We also have it set up so that the reports (invoices, POs, and electronic payments) can be emailed to the various parties. 

Ed Stein adds

We moved to the ability to laser-print, or email purchase orders in PDF format, using eFORMz and eDirect from Minisoft. For vendors who require a faxed purchase order, we email the PDF of the purchase order to an email-to-fax service, otherwise we email them a PDF copy. We only laser-print purchase orders for vendors who either require a mailed copy or do not have an email address or fax number.

Can I configure a disk larger than 36GB on MPE/iX 5.5? The reason the customer is locked into 5.5 is they use Oracle 7.3 — so I'm now trying to set up a test bed to see if I can move the system up to 7.5 and still have all the wheels stay on. But we might not be able to migrate off 5.5, and the only way to get the enough disc space is to try going to 73GB drives. It doesn't look like 73GB are supported, but that doesn't mean someone hasn't been able to make them work 

Jim Hawkins replies

Although your mileage may vary, there is nothing "unsafe" about trying to access 73 GB on 5.5. Of course, there is a 4GB cap on LDEV1, regardless of disk's physical capacity). What's unsafe is the fact that you're likely running on 15-plus year old equipment -- and running on disk-to-firmware-to-HBA combinations they were never tested by us at HP. 

When researching "Large Disk" support in early 2000s, my observation was that disk size constraints were last re-engineered around the 4GB mark during MPE/XL 2.x (early 1990s). From there, most of the code worked pretty well up until 512GB, where we run off the rails of some 30 bit limits.

What didn't work okay up to 512GB was addressed by the "Large Disk" patches for 7.5. Things like REPORT running out of space to display a sector count, DISCFREE output etc. The only allocation change I made had to do with trying to spread IO across disks in a more granular way -- really an optimization, rather than an inherent limit.

Allegro's Stan Sieler adds

I remember that when Allegro encouraged HP to handle big disks, I found some definite problems in some obscure things — and that's why we filed a number of bug reports (including JAGad48770 in 2000) and then lobbied with Mike Paivinen, Louis Runnestad, and the CSY lab manager at the time to get really big disks supported. (Ironically, that triggered extra work for me... I had to make sure that De-Frag/X supported them, too.)

Unfortunately, I can't recall the details of what things had problems. Some of the things were offline utilities (for example, DISKCOPY, or DISCUTIL's SAVE command) that could be significant. Some were cosmetic (e.g., incorrect output from DISCFREE). 

In the back of my mind, I have a suspicion that on some releases MPE might create some disk-based data structures that are too small — in a way that could potentially cause an overwrite of data ... but I really don't remember what it was, or which MPE release (might have been *very* long ago, sorry!). 

My old notes say that 5.5 with PowerPatch 5 had an "official" max disk size of 18 GB and that I thought I'd seen a working 36 GB drive on a system. The same notes say that the base release of 5.5 officially had a 9 GB max disk drive size.

Posted by Ron Seybold at 04:39 PM in Hidden Value, Homesteading, User Reports | Permalink | Comments (0)

June 29, 2012

Celebrate net printing's anniversary: use it

Seven years ago this week HP's 3000 lab engineers announced that networked printing was ready for beta testing. This was one of the last enhancements first demanded by a wide swath of the 3000 community, then delivered by HP. The venerable Systems Improvement Ballot of 2004 ranked networked printing No. 1 among users' needs.

MPEMXU1A is the patch that enables networked printing, pushed into General Release in Fall, 2005. HP had given the community a OS-level substitute for good third party software from RAC Consulting. It might have been the last time that an independent software tool got nudged away by HP development.

The HP 3000 has the ability to send jobs to non-HP printers over a standard network as a result of the enhancement. The RAC third party package ties printers to 3000 with fewer blind spots than the MPEMXU1A patch. HP's offering won't let Windows-hosted printers participate in the 3000 network printing enhancement. There's a Windows-only, server-based net printing driver by now, of course. The HP Universal Print Driver Series for Windows embraces Windows Server 2008 and 2003.

Networked printing for MPE/iX had the last classic life that we can recall for a 3000 enhancement. The engineering was ready to test less than a year after the request. This software moved out of beta test by November, a relatively brief 5-month jaunt to general release. If you're homesteading on 3000s, and you don't need PCL sequences at the beginning and end of a spool file, you should use it. Commemorate the era when the system's creator was at least building best-effort improvements.

MPE/iX 6.5 was still being patched when networked printing rolled out. That's a release still in steady use at some homesteading shops. Plenty of later patches were only created and tested for the 7.0 and 7.5 PowerPatch kits.

Deep inside the Internet somewhere is a white paper that HP's Jeff Vance wrote, a guide he called "Communicator-like" after the classic HP technical documents. HP's pulled off its Jazz repository of tech papers where NWPrinting.html once was available. Our open source software expert Brian Edminster tracked down that gem at the Client Systems website -- the company was one of two which licensed HP's tech papers. But you could check in with your independent support provider, to see if they've got it.

Networked printing was never as comprehensive as indie solutions for the 3000, but at least it was delivered on the OS level via patches. The vendor warned that adding new printers was going to be an uneven process.

HP will support this enhancement on a “best-effort” basis, meaning we will attempt to duplicate and resolve specific spooler problems -- but we cannot guarantee that all ASCII based printers are supported by this enhancement.

While that might sound like a show-stopper seven years later, you'd be surprised how many printers of that era are still attached at homesteading 3000 sites.

Where do you get the patch? That's where HP's still doing its work. The MPE/iX patches were given special dispensation from the pay-for-patches edict of 2010. They're still free by calling HP. The printer and MPE might seem like old technology. But HP's still using telephones to deliver them, so there's that throwback.

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

June 14, 2012

Open Sourcing Access to Linux or Windows from MPE/iX

DSLINE is a classic networking access service provided for HP 3000s. The software is so classic that HP once charged separately for NS3000/iX Network Services. One user wanted to employ DSLINE to make connections, starting from MPE systems and into remote Linux and Windows servers. Sending commands was the task to be performed.

"I currently use a Reflection script to do the job," said Krikor Gullekian. "However, we are moving away from that and creating a JCL for it. I am using FTP to create a file on the host system which is activating commands to run, and that works, but it's a little cumbersome. That's why I was wondering if there were any other way."

Another community member pointed to using the ssh client included on the HP 3000. In theory, so long as the Linux and Window servers have an ssh server, then Gullekian should be able to run remote commands via ssh. But there's some hurdles to overcome in using ssh on a 3000 for remote command execution.

Brian Edminster of Applied Technologies, who's maintaining a repository of these sorts of open source tools for 3000s, warns that ssh needs some improvements to let it perform the same level of work as Linux or Windows versions of the remote access tool.

Unfortunately, the available ssh client for MPE/iX is none too current, and is essentially 'broken' with regard to remote command execution. As I recall, it has something to do with SELECT being busted on MPE/iX. It works well enough to support scp and sftp though, but that's pretty much it.  

Edminster has created workarounds for anyone who needs password-free invoking of secure remote scripts, however. What's more, it appears that the MPE way of writing such received files to disk is more secure than the other platforms' FTP services.

"What I've had to do in environments," Edminster says, "where I want passwordless secure remote script invocation (ala ssh) is to have a scheduled task (via cron or whatever) that looks for and executes specifically named scripts, one that then removes the script when done executing."

To avoid having the remote cron beginning to execute a partially sftp-put file, I'd send it with a '.tmp' suffix, and then rename it upon successful completion of the put and/or chmod the file to make it executable when I'm ready to have it run (rename and chmod being atomic operations). This is necessary because, unlike MPE/iX, many systems FTPd (and likewise, sftpd) will start writing the received content to disk as soon as it receives it -- making a partially received file 'visible'.    

Yes -- we've been spoiled in MPE/iX Land. 

For what it's worth, on my bucket list is either an update to the OpenSSH port (with an attempt to fix remote command execution), or port of other, simpler ssh implementations. If the OpenSSH implementation for MPE/iX is what you want to try, you can get the necessary files either from the fine folks at Allegro (from their website), or from www.MPE-OpenSource.org.

I'd be happy to work with anyone that needs help getting this OpenSSH port installed and operating -- including how to get around some of its limitations.

Over at the Allegro website, Edminster's MPE OpenSource site is named as the best destination for such software.

Those looking for MPE/iX ports of Open Source software that were formerly hosted at HP’s “Jazz” and other sites will appreciate http://www.mpe-opensource.org. Currently the site offers an updated all-in-one package of the components required to implement the SFTP Secure File Transfer Protocol on MPE/iX 6.5 or later. This package includes Perl, the Gnu Compiler Collection (GCC), as well as GNU tools, SSL, SSH, and required dependencies.

With that said, Allegro's Donna Hofmeister did point out that the company has a great whitepaper on using SFTP, as well as accompanying downloads. Look for "SFTP" on the Allegro whitepaper page.

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

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 Hidden Value, Homesteading, 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 Hidden Value, History, Homesteading, News Outta HP | 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 Hidden Value, Homesteading, Migration, Web Resources | Permalink | Comments (0)

May 09, 2012

Which bits produce the 3000's stall in 2028?

Vw-egoUpdate: We advise you to read our following day's report about HPCALENDAR and the CALENDAR intrinsic, for a complete view of the future viability of MPE. Also, the first entry in this series, including advice on what to expect from a 3000 running during 2028.

At 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 Hidden Value, History, Homesteading | 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 Hidden Value, Homesteading, Migration | 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 Hidden Value, History, Homesteading | 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 Hidden Value, Migration, User 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 Hidden Value, Homesteading, User 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading, 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading, Migration, User 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 Hidden Value, Homesteading, 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 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading, 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 Hidden Value, Homesteading, 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading, User 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 Hidden Value, Homesteading, 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading, User 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading | 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 Hidden Value, Homesteading, 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 Hidden Value, Homesteading, User Reports | Permalink | Comments (1)