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. “The high point in MPE software was the JOBINFO intrinsic,” says Olav Kappert, an MPE pro who started with the 3000 in 1979.
Fast-forward 42 years later and people still ask about adding features to a system. The Obtaining File Information section of a KSAM manual on MPE/iX holds an answer to what seems like an advanced problem.
I’m still using our old HP 3000. I want to use the characteristics of an input file as HPFOPEN parameters to create an output file. That output file should be essentially an exact replica of the input file (give or take some of the data). This should all be possible without knowing anything about the input file until it is opened by the COBOL program.
I’m using FFILEINFO and FLABELINFO to capture the characteristics of the input file, after I have 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 says, “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 adds, “you might want to get a copy of the “Using KSAM XL and KSAM 64” manual. 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.”
Michael Anderson notes that details on how the 3000’s CI scripting can build upon the fundamentals of file information and COBOL.
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.
You can write a script to do everything you want, and call HPCICOMMAND to run the script, pass it parms. 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.
Eric Sand, another veteran of the 3000, commented that this kind of challenge really shows off the range of possibilities 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 concern.”