By John Burke

Jeanette Nutsford called this year’s SIG3000 to order with about 45 people in attendance, a number that would swell to about 60 by lunch. Nutsford, who chairs the SIGCOBOL special interest group, called the meeting “The old IPROF with a new face.”

Stan Sieler led off the SIGMPE discussion with a presentation and commentary on Adrian den Hartog’s slides presented at SIGSoftvend on Monday. (There were approximately 80 people at SIGSoftvend, and reports indicated that the vendors’ and tool suppliers’ group for the e3000 had a very upbeat, exciting meeting.)

In a review of 6.0 features, a show of hands revealed that

• No one is using user defined job queues.

• Only a handful knew anything about Easytime/iX.

• Roughly a third of attendees are using Samba/iX.

• Only three are currently using Java/iX, but half of the attendees are investigating it.

In a review of 6.5 features:

• The performance improvements will only be seen in high-end multiprocessor (6 or more) systems

• 128Gb file support is for NMKSAM and flat files (it was noted this has implications for b-trees).

• Subsystems such as sort have been modified to deal with large files.

• The new 36Gb drives are supported, but LDEV 1 can still only use 4Gb of whatever physical drive is present.

• Sysdiag is gone, replaced with STM from the 9000 (some modules such as logtool and termdsm remain as standalone utilities). Note that passwords are still required for STM now.

MPE/iX 6.5 is supposed to be shipping this month (51453B opt 265).

There was a good deal of discussion about HP-IB, with Sieler suggesting there “might” be an opportunity for open sourcing the HP-IB drivers.

In discussing Posix, Jeff Vance and others from HP pointed out that the focus at HP is on porting issues as opposed to the former smoothing issues — they are not the same, though there is a lot of overlap.

As an aside, Sieler said that as an experiment, he has ported a Linux version of whois for the e3000 and placed it on the Allegro site. He noted that he is investigating making EDITOR bytestream file-aware.

As part of the Posix discussion, it was pointed out that HFS does NOT mean bytestream files. MPE files can live quite nicely in the HFS file space.

Before going over System Improvement Ballot items, Jeff Vance noted that because the lab has been hard at work on the N-class servers, delivering a new I/O system, and drivers, particularly networking. Vance noted CSY had made more progress then the HP-UX folks with less manpower.

As part of his presentation, Vance discussed patch MPEKXR8 for MPE/iX 6.0. The new patch is a collection of three totally unrelated items:

• The long-discussed ABORTPROC command

• STORE-to-disk as part of basic FOS STORE

• An enhanced CI INPUT command that now supports communication with the logical console

ABORTPROC is similar in functionality to the “kill” command in the Posix shell. It carries with it the obvious caveats about careful use.

STORE-to-disk (STD) as part of basic FOS STORE enables anyone to create software packages on disk which can be transmitted via LAN, WAN or the Internet and easily unpacked using FOS RESTORE. Until MPEKXR8, STORE-to-disk was only available as part of top-of-the-line TurboSTORE 7x24 True Online. All downloadable patches from the Response Center are now packaged as STORE-to-disk. STORE-to-disk is obviously useful for ISVs that want to download product to customers over the Internet. It can also be useful for organizations with multiple distributed systems that want to transfer packages electronically.

Finally, MPEKXR8 adds two new parameters to the CI’s INPUT command. The enhanced input command has a lot of possibilities, in my not-so-humble opinion.The full syntax is now:

INPUT   [NAME=]varname
[[;PROMPT=]prompt ] [[;WAIT=]seconds ]
[[;READCNT=]chars ] [[;DEFAULT=]default_str ]
[;CONSOLE ]

The new parameters are “DEFAULT=” and “CONSOLE”. “DEFAULT=” is what it says, a way to specify a default response in the case of either a timeout on the read or a CR response. The big news is the new “CONSOLE” parameter. This allows the prompt to be displayed at the logical console and “RECALLed” and “REPLYed” to by any user with appropriate capability.

Prior to MPEKXR8, this could only be done programmatically via the PRINTOPREPLY intrinsic. Now, using simple CI programming, job streams can be created that use communication with the console as a control mechanism. By using the read timeout via either the “WAIT=” parameter or the HPTIMEOUT variable, a job can loop, continuously prompting the console, until a reply is issued. This is particularly useful on busy systems where a single request for a reply can easily roll off the screen.

One important final note: MPEKXR8 is considered a site-specific patch and is not yet on the track to be General Released (GR). Jeff Vance needs more people to use it. The patch is currently in revision level “C,” so if you wish to request it from the Response Center, ask the RC for patch MPEKXR8C, saying you are on Jeff Vance’s Beta team.

In discussing the enhancement requests, Jeff dropped the bomb that within HP there has been some talk about Open Sourcing the CI! There would be a lot of work to get it ready, but the fact they are even talking about it is news.

A security subcommittee was set up with Bob Karlin as head to examine the big picture of how HFS security relates to MPE security.

After lunch, Donna Garverick launched into SIGSysman.There was considerable discussion about both console management and logon management, but no real new ground was broken.

The big news at SIGSysman was from HP’s Walt McCullough: CSY is working on a hardware mirroring solution with Just a Bunch Of Disks that would work on the system volume set. The solution is from the same company, Vicom, that makes the new fiber distancing solution. The initial offering will not be fully redundant with dual paths. A formal announcement is pending on a few technical problems he believes are solvable.

McCullough said very little else about the hardware mirroring of the system volume set using JBOD; he did not mention it at all in his hour-plus talk at the Solution Symposium. I can only speculate that they are using the same multiplexing technology used in the fiber distancing solution. The actual mirroring is probably straightforward. The challenge is likely in how you build/rebuild the mirror.