On 24/09/2009, at 9:15 PM, Dennis Lovelady wrote:

Answering my own question... if you did call the program from a script, and
then (from your program) checked the parent process, you should find that
the parent process is that script. If it's not that script, then it's
either a CALL command or someone is violating your protocol. Right?

True, but then I'm forcing somewhat unnecessary behaviour by requiring a script that does nothing other than invoke a program. It's a bit like sticking a CLP between a CMD and HLL for no reason other than that's how we usually do it. The HLL could be the CPP for the CMD. It doesn't need any CL glue. Same here. The symbolic link can be used to run the program directly. It doesn't need any script glue.

Also, how would I distinguish between a protocol violation and CALL? The worst that would happen is messages being sent to the wrong place but still not the behaviour I desire.

Some background:

I'm porting a Unix-y tool to OS/400 (well re-doing something I did years ago). I really hate the way these open-source tools presume English by embedding error message text etc. in the program code (don't they know ANYTHING about software development?). I also LOATHE the way most Unix-y ports end up running within QSH or PASE instead of as a native application. I also hate the way they print error text to STDOUT or STDERR from anywhere within the code. While this sort of output to a terminal makes sense in their original environment it doesn't make sense to splatter them willy-nilly through-out the code. Better would be an error function that received a message ID (or array element reference) and the error function would print the error. At least that way other platforms would only have to change the one function to send the message to a different output.

What I have done is extract all the message text and stick it in a message catalogue. A proper OS/400 message file would be better but that's simply to much work (deciding which messages are *DIAG, *INFO, *COMP, *ESCAPE, etc. and writing second-level text where that concept simply doesn't exist) and too invasive to the existing code. I'll modify the existing code to fetch message text from the message catalogue. Then if it's running in QSHELL I'll just use the existing fprintf etc. methods to display that text. If it's not running in QSHELL then I'll use Qp0zLprintf to send the message to the job log. If some problem occurs retrieving from the message catalogue (or a national language variant doesn't exist) then I'll send the default English text.

That seems a reasonable compromise and the code changes will also work on other platforms that support message catalogues--which seems to be almost anything with a POSIX-compliant interface.

I just wondered if someone brighter than me had a better alternative than my suggested approach.

Simon Coulter.
FlyByNight Software OS/400, i5/OS Technical Specialists

Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
ASCII Ribbon campaign against HTML E-Mail / \

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].