Classic Newswire

While surfing the net, I came across this 1999 article by Ron Seybold about Vladimir and Eugene Volokh of VESoft.

Homesteading and MPE Tips

MPE for Unix User (Parts 3 and 4)

In part 1 of our MPE Quickstart for Unix Users  we presented a quick reference of the closest MPE command to each of the main Unix commands. In part 2, we explored the directory structure in the context of logging onto an HP 3000 system.

In part 3 (MPE for Unix Users, Part 3 ), we look at MPE files to see how they are different from files in Unix. The File System is one area where MPE is really different from Unix. And much more complicated. Click the link above to find out how complicated!

In part 4 (MPE for UNIX Users, Part 4), we learn how to examine the content of files. This introduces the Unix user to Print, Editor, Fcopy, Qedit, Magnet, MPEX and Suprtool.

Disaster Recovery Planning for Homesteaders

Paul Edwards has issued an update to his paper on disaster planning: “Your HP 3000 system is probably the heart of your company's business operation. Some disasters, like disk drive failure, are minor, while others can destroy the computer center or entire corporate structures. The top ten types of disasters, which have caused the most damage in recent years, are power outage, storm damage, flood, hardware error/failure, bombing, hurricane, fire, software error, power surge/spike, and earthquake. “

Qedit Tips

Qedit Deals with Trailing Blanks

Removing Trailing Blanks: A Qedit for MPE user called with an interesting problem. He had a large data file that was used as input to a program. The input records had many trailing blanks, so he thought he could save a lot of disc space by converting the file to variable-length records instead of fixed-length records. His first attempt at converting the file was not successful. He had used FCOPY to convert the file from fixed- to variable-length, but the file didn't take any less space. It seems that FCOPY did not strip the trailing blanks.

According to a LISTF, the original file occupied 10,928 sectors of disk space.  The variable-length version of the file created by FCOPY used 12,288 sectors of disk space (since the trailing spaces were not trimmed and the disk packing is not as efficient).

Because the customer had Qedit, we used Qedit to convert the file from fixed- to variable-length:

:run qedit.pub.robelle

/t fixfile; set keep var on

/keep varfile; exit

Qedit stripped the trailing blanks from each record. The file was now significantly smaller than the original file (2,576 sectors instead of the original 10,928).

But the user's application program choked on the file, because the file label no longer described the file as a 200-byte file. Qedit assigned its own record length and blocking factor, which the user has no control over.

The third attempt was successful, combining both Qedit and FCOPY:

:build varfile;rec=-200,1,v,ascii;disc=123456

:fcopy from=foo;to=varfile

*200*WARNING: FROMFILE RECSIZE IS 1276 BYTES, TOFILE RECSIZE IS 200 BYTES.

CONTINUE OPERATION (Y OR N) ?y

EOF FOUND IN FROMFILE AFTER RECORD 13981

13982 RECORDS PROCESSED *** 0 ERRORS

END OF SUBSYSTEM

Ta-dah. A Listf command shows that the variable file now uses 4,096 sectors. The variable file is  now significantly smaller than the original fixed file, while still retaining the original record length and blocking factor.

Preserving Trailing Spaces: In the past, Qedit always padded lines with spaces in fixed-length files (Set Keep Var Off) and removed trailing spaces in variable-length files (Set Keep Var On). However, users-specified trailing spaces are sometimes significant, and are not supposed to vary during the edit session. Since version 5.5, Qedit has offered the TrailingSpaces feature. The option is disabled by default on MPE and enabled (by default) on HP-UX.

Set Work Trailingspaces ON requests that Qedit preserves trailing spaces and makes them significant characters. The option also allows creation of odd-length lines. Once enabled, all workfiles created or opened from that point will have trailing spaces preserved. To check the current status, do:

/Verify Work           

 . . . Set WOrk TRailingspaces ON

/Verify Keep           

 . . . Trailing spaces preserved

The last line shows that trailing spaces are preserved in this workfile.

If the option is disabled, that line reads “Trailing spaces trimmed.”

Disabling the global setting with Set Work Trailing Off does not disable the option in the workfile. You have to clear the workfile after disabling it. The Trailingspaces setting is stored in the workfile so it's recognized when the file is opened in the future. These workfiles may contain data specific to Trailingspaces. This may cause unexpected behavior if opened with old versions of Qedit. Because trailing spaces are now treated as significant characters, Keep files created from these workfiles may be different from Keep files created with an older version.

Suprtool Tips

Suprtool Learns About AMXW

Recently we at Robelle have been busy integrating Suprtool for HP-UX with a very interesting migration product from Speedware called "AMXW". The goal of AMXW is to reproduce the basic HP 3000 application environment (languages, file system, database, Vplus, and commands), so that you as the user do not need to rewrite your programs.

Since Suprtool already runs on HP-UX, why would you want to interface it to a library like AMXW? The answer is simple: to take advantage of the "MPE-emulation", of course. For example, Unix does not have the concept of a record length for files (all files are just a string of bytes). If you intend for a file to start a new "record" every 80 bytes, you need to tell Suprtool/UX about this in your Input command; Suprtool cannot figure it out automatically, unless of course you are reading a "self-describing" file created by Suprtool. AMXW maintains the equivalent of the MPE file label for each emulated file, so it can tell any program the record size, data type, and other MPE attributes of the file, such as user labels.

Here is how Speedware describes AMXW:

AMXW (Automated Migration to UNIX and Windows) … AMXW is a complete tool designed to migrate HP e3000 COBOL, SPL, C, FORTRAN and Pascal application environments to the HP 9000, Integrity Itanium, Windows, Linux, Sun or AIX platforms. It automatically converts code for new compilers, which prevents developers from needing to modify their MPE-specific code. The combination of AMXW's automated code conversion, MPE shell and Intrinsics libraries gets you up and running on your new platform in no time.

Although designed to migrate a variety of 3GL applications, AMXW is particularly well suited for companies that rely on HP COBOL 85 applications. AMXW automatically converts programs, including source code, copy libraries and $include files, to work with the most popular and proven COBOL compilers, namely ACUCOBOL-GT (ACUCORP) and Server or Net Express (Micro Focus).

Applications migrated using AMXW perform and operate the same way as on the HP e3000, even after the databases have been upgraded to RDBMSs. Using native database, file and operating system access, AMXW provides the highest level of performance. What's more, it includes two valuable components that allow application code to remain untouched. The MPE intrinsics library supports the most commonly-used MPE intrinsics. Therefore, concepts, such as environment variables, process creation and command execution remain untouched in the application, and run natively on the target platform. In addition to native UNIX, Linux and Windows commands, AMXW's MPE shell supports a wide range of MPE commands and functionality.

To take advantage of the MPE file functionality of AMXW, we put the MPE intrinsic calls back into the Suprtool/UX source code (we had removed them when we converted Suprtool for MPE to HP-UX). This means we now have calls to FOPEN, FREAD, FWRITE, FGETINFO, FCLOSE in Suprtool for HP-UX.

Once we worked out how to link to the proper AMXW library and get the parameters aligned, we were able to open a simulated-MPE file, call FGETINFO to find out the record size, sort the records and create a new simulated MPE file with the results.

How did we create the test data file for our first run? We ran the AMXW command shell and did a regular MPE :Build command!

And how did we check the new output data file from Suprtool? Again we used the shell and did an MPE :Listf command to check the format and a :Print command to check the contents!

Very cool.

Of course, AMXW does not emulate every feature of MPE. For example, it supports the HPFOPEN intrinsic, but not the "mapped-file" open option (we can always hope for this in a future update). However, since we already solved this issue for Suprtool for HP-UX we are still able to run under AMXW without missing any features.

More on the Command Shell

We re-inserted a call to the HPCICOMMAND intrinsic into Suprtool/UX and now we can execute MPE commands like :SHOWJOB from inside Suprtool/UX.

Commands we have used include BUILD, PURGE, RENAME, LISTF, PRINT, SHOWJOB, BUILD;TEMP, LISTFTEMP, and FILE equations.

You can set and use environment variables: SETVAR and SHOWVAR and hpcigetvar are supported.

Command Files

Command files are also supported, I made a simple command file called status to do a showme and showjob, which I can execute from within Suprtool on HP-UX.

Although we have not tested them yet, UDC's are supported as well.

AMXW, also has support for IMAGE calls to Eloquence. However, we have turned off their TurboIMAGE interface as we directly support Eloquence and have our own High speed access. However, they also support Oracle/Sybase and MS SQL through the same Image intrinsics.

Conclusion. So far our experience building an AMXW-version of Suprtool for HP-UX has been positive. Soon we plan to try the same thing for Qedit on HP-UX. Keep tuned for future updates on our experiences.