Middleware renovates HP 3000 manufacturing choices

Middleware renovates HP 3000 manufacturing choices

MiddleMan stands at heart of MM II renovation, work that HP hopes will attract new customers

Sites using HP’s MM II manufacturing solution are getting a new set of interfaces and connectivity for their mature software, and HP is looking forward to landing new 3000 customers with the combination.

The work is being done by Salt Lake City-based eXegeSys (801.538.0222), a consulting and program development firm founded by some of the former caretakers of HP’s MM II solution. eXegeSys provides support for the MM II product to HP’s Response Center, and is in the middle of a transition plan to take over the HP product. It also sells an Evergreen development environment to give MM II shops a client-server-based tool for working with the MM II Customizer.

eXegeSys recently revealed some details in its plans to overhaul MM II, software that first went into service in the early 1980s. At the heart of the plans is implementing connectivity and interface improvements that transform MM II into a client-server solution. eXegeSys is working on making MM II talk with other applications, using the MiddleMan middleware solution from Minisoft.


	The eXegeSys improvements are one step in the process of making an HP 3000 solution that’s been labelled “mature” a vital choice for discrete and process manufacturing

These eXegeSys improvements are one step in the process of making an HP solution that’s been labelled “mature” a vital choice for discrete and process manufacturing. The process will take the product away from HP, which was finished with MM II several years ago. This February HP will pull MM II from its price list, and provide support for the product only for another 12 months. eXegeSys then takes on sales of the product and acquires the source code. It will be working with the Minisoft front-end product FrontMan to integrate a graphical PC interface with an application that started its life in the block-mode terminal era.

MM II is the second 3000-centric manufacturing solution to gain functionality through MiddleMan. The middleware is already at work in another HP 3000 manufacturing product, AdvanceMan from Quantum Software. (See “MANMAN sites get client-server for HP 3000s,” February 1997 NewsWire.) eXegeSys will take MM II one step further with the Minisoft solutions, incorporating Minisoft’s FrontMan to do graphical interfaces to MM II screens.

While the work is progressing, HP is making plans to leverage what could be positioned as a new manufacturing solution for MPE/iX. Roy Breslawski, CSY’s marketing manager, said that he’s counting on the renovated MM II to spark sales of HP 3000s to new customers.

“There is an opportunity for MM II on the 3000 in a lot of the same installations where SAP is too big to swallow,” Breslawski said. In his quest to make 30 percent of 1998’s HP 3000 revenues come from new customers, the HP manager said he was relying on a revamped MM II.

“One of our focuses next year is in manufacturing,” Breslawski said. “It’s been one of the long-term strengths of the 3000, and it’s certainly something that has a lot of life in it for the 3000. We have an exceptional partner in eXegeSys, who’s been investing in the [MM II] product, and I think there’s a lot of things we can do together.”

What eXegeSys will offer that may trigger some sales is a way to let manufacturing sites integrate PC applications with MM II. The company recently announced a detailed process to make FrontMan work with MM II running in standalone mode, using versions already installed in HP 3000 shops.

eXegeSys said FrontMan can only be used with Native Mode versions of MM II, because the application’s library list must be modified using the MPE/iX link editor. The modification allows VPlus processing to be captured by the FrontMan listener and sent out on the network to the appropriate client.

MM II also utilizes a central application management utility called the Monitor. User sessions connect to the Monitor, which can be run in a standalone, single-user version. “Because of the way HP implemented the technology, neither we nor anyone else can interface with the Monitor program,” said Mike Sweeney of Minisoft. However, by using the single-user version in conjunction with MiddleMan and FrontMan, “we kind of replace their Monitor program with our listener jobs.”

The substitution brings client-server capabilities to MM II today, but Steve Quinn of eXegeSys said that “one challenge for MM II users planning to utilize the MiniSoft tools, not unlike one they have dealt with in the past, is keeping the customizer and screen environments in sync.” Customers must make screen modifications in the MM II Customizer, then transfer the changes using FrontMan tools. If an MM II site is continuing to use terminals in some places, the changes will need to be made using FORMSPEC as well.

To implement the Minisoft tools, MM II sites import their VPlus forms files into FrontMan. They then link the Minisoft library to the application programs and create a server job that starts the Minisoft listener. FrontMan can then create an Initial Application Form to provide the initial interface to the VPlus application on the HP 3000. The form must include at least one start button to launch the application, although FrontMan allows for the full range of GUI items such as dialog boxes, radio buttons, easy look-ups and retrievals, and windowing.

In addition to implementing Minisoft’s products with MM II, eXegeSys reported on a procedure to let MM II sites access the batch processing CONOUT file. It’s another way to make the application more accessible from client applications by using this output file from the continuous batch processor. MM II users want the files from batch processors MMSIN and MMSOUT become shared, multi-read message type files, to let other HP 3000 processes communicate with MM II and receive the error messages.

HP investigated designing an application API to do this after user requests at this year’s HP World meeting, but Quinn reported that “what HP found was that this type of interface would be a very difficult and costly enhancement, well outside their strategy for the applications.”

Quinn then added, in a posting to the MM II Internet mailing list, that eXegeSys has figured out another way to access CONOUT. “During the course of HP’s investigations, we at eXegeSys Inc. did a little investigating of our own,” he said. “We found is that it is possible to access the CONOUT file today.” A detailed COBOL module illustrating the process was e-mailed to MM II users on the Internet, and is available from Quinn by e-mailing him.