Reliable advice on speeding up 3000s
Advice on which database issues matter

Creating rich text from 3000 report files

Dave Powell, an ignited resource from the HP 3000 user community, is considering enhancements to his HP2RTF command file for transforming MPE/iX reports to the Rich Text Format. His work is a great example of how the 3000, given its do-it-yourself nature, is going to have a longer lifespan than any vendor might give the system.

HP2RTF is an everyday solution to an application need: convert files to be used across a company (in this case, MM Fab). Powell explains:

Input is a normally a fairly plain-vanilla report saved in a cctl regular file, but can be a spoolfile, or anything with cctl.  Output is a file in rich-text format so it will be readable on any PC word-processor once you send it to a PC. We use it, plus an e-mail program, to send reports to sales reps and customers.

Powell distributes HP2RTF by sending the command file to users who e-mail him. He says the command file has had a few tests outside his company, but he's got a desire to expand its reach:

I have sent HP2RTF to several other sites, with mixed results, possibly because they have non-COBOL apps which use different cctl codes. HP2RTF handles everything we need it for here, but doesn’t (yet) handle much that we don’t expect to ever need here. Time permitting, I can enhance it for things that other sites need even if we don’t (or anyone else is welcome to mod it).

Powell has ideas for HP2RTF and is volunteering to make it a solution more 3000 customers can use. He's also made a tool available to help test it:

I have a command file that makes it relatively easy to see what the actual codes are.  If anyone is having trouble with HP2RTF, it might help if I send it to you, and you send back to me the results of running it on your problem files. Or, if anyone else is curious about what there printouts are doing before they print, I can send it or just post it on the 3000 newsgroup. Be advised that spoolfiles keep some critical info in “secret” parts of the record that you DON’T get with MPE ‘input’ or COBOL “read”.  It is much easier to see what is going on if you direct your reports to a non-spool cctl file.

He goes on to suggest things he'll be willing to add to this utility. (We'd point out that this kind of behavior rarely comes from a vendor, unless they are selling an upgrade, but that would be churlish. So never mind.) And here's Powell's "I can do this" list. All 3000 users need supply is interest.

I’m thinking about some improvements, now that I don’t have to keep it lean and mean for performance reasons.  Is there anybody who might have a use for support of any of the following:

Portrait mode printing?  (this looks really easy and might happen even if nobody asks for it).

Non-Cobol carriage-control codes?  For example, Cobol double and triple-spaces with codes %202 and %203, but other languages can use %60 and %55.  The fwrite section of the intrinsics manual lists zillions of codes we don’t use here. Some look hard to implement, but codes like %55 & %60 would be a snap.

Subscript & superscript?

Any other print enhancements?  (besides boldface, italics & underline which already work).

Postspacing? (Cobol “write before advancing”, also $stdlists).  If I do this, it might be limited to $stdlist and standard (non-spool) cctl files. Spoolfiles keep the info on pre / post spacing in a hard-to-get-to location (see appendix A of Native Mode Spooler Manual) and I don’t think I will ever get around to ferreting it out.  Stdlists I can simply assume to be postspaced, and standard cctl files use documented codes in the normal place.

Non-cctl input files?