HP 3000s took a big step forward with the introduction of a fresh intrinsic in 1995. 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, and JOBINFO came into full flower with MPE/iX 5.0, back in 1994. "The high point in MPE software was the JOBINFO intrinsic," said Olav Kappert, an MPE pro who could measure well: his 3000 experience began in 1979. JOBINFO sits just about at the end of the 456-page MPE/iX Intrinsics Manual published in '94.
Fast-forward 24 years later and people still ask about how they can add features to an application. The Obtaining File Information section of an MPE KSAM manual holds an answer to what seems like an advanced problem. That KSAM manual sits in one of several Web corners for MPE manuals, a link on Team NA Consulting's page. Here's an example of a question where INFO intrinsics can play cause and effect.
I'm still using our HP 3000, and I have access to the HP COBOL compiler. We haven't migrated and aren't intending to. How can I use the characteristics of an input file as HPFOPEN parameters to create an output file? I want that output file to be an exact replica of the input file. I want to do this without knowing anything about the input file until it is opened by the COBOL program.
I've tried using FFILEINFO and FLABELINFO to capture the characteristics of the input file, once I've 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 said, "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 added
Have a look at the Using KSAM XL and KSAM 64 manual (Ed. note: link courtesy of Team NA Consulting). 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.
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 (a repository for Tcl, a flexible language with a small core and many uses that can be adapted in ways). 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 issue."