×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
