|
midrange.com
Well, obviously one thing that you are missing is that I didn't tell you
that I only use it for PRINTER FILE override, or OVRDBF, ADDLIBLE. I have
never used it for CPYF, or anything like that. I use a CL pgm to handle
that stuff before calling the RPG pgm.
The only important information I need from OVRPRTF OVRDBF, ADDLIBLE is, was
did it complete successfully. If I need more information, I will code for
that in the CL pgm. There's you have my thinking of it.
I appreciate your thoughts...
"One man's garbage is another man's meal ticket."
Michael Schutte
Scott Klement
<rpg400-l@scottkl
ement.com> To
Sent by: RPG programming on the AS400 /
rpg400-l-bounces@ iSeries <rpg400-l@xxxxxxxxxxxx>
midrange.com cc
Subject
06/01/2006 03:43 Re: Change printer
PM
Please respond to
RPG programming
on the AS400 /
iSeries
<rpg400-l@midrang
e.com>
I prefer SYSTEM() but only because I don't have to tell how many characters.
With the way I program, system() requires *extra* work!
I make every effort to write error-free programs, but even so, errors
occur. I always make it my business to make sure that when an error
occurs, it's as easy as possible to troubleshoot and fix the problem --
the point at which the user is the most frustrated is when an error
occurs, and if I can't find and solve his errors, I look bad.
Consider the following code:
H DFTACTGRP(*NO) BNDDIR('QC2LE')
D system PR 10I 0 extproc('system')
D command * value options(*string)
/free
system('CPYF . . .');
I'm assuming that my CPYF will always work. Always. Except when
something stops it from working :) You know what I mean? I don't want to
code for a condition where it'll fail, because I want to be as productive
as possible. But, I don't want to do what I did above and simply ignore
any errors and proceed, either! If that CPYF fails, I want to know about
it, and I want to know WHY it failed so that I can fix the user's problem.
So I have to code the following, at a bare minimum:
H DFTACTGRP(*NO) BNDDIR('QC2LE')
D system PR 10I 0 extproc('system')
D command * value options(*string)
D systemErr s 7A import('_EXCP_MSGID')
D wait s 1A
D errMsg s 50A
/free
if system('CPYF . . .') <> 0;
errMsg = systemErr + ' when running CPYF command!';
dsply errMsg '' wait;
*inlr = *on;
return;
endif;
/end-free
Actually, in a production program I wouldn't use DSPLY, I'd call the
QMHSNDPM API to end the program with an *ESCAPE message so my caller would
know that if failed, too... but even if I cut corners and used DSPLY (as
above) I've still added a significant amount of code to my program.
Even with that extra code, when the error occurs, all I'd get is a msgid
like CPF0006 (or whatever) and I'd then have to look up that message ID to
see what the problem is. If there are any fill-in fields in the msgid, I
wouldn't know what they are. I'd probably have to try to re-create the
problem on my own machine to get enough information to help the user.
The user himself would NEVER figure out the problem from the message
"CPF0006 when running CPYF command!"
On the other hand, I could use QCMDEXC. For example:
D QCMDEXC PR ExtPgm('QCMDEXC')
D command 32702A const options(*varsize)
D len 15P 5 const
D cmd s 200A varying
/free
cmd = 'CPYF . . . ';
QCMDEXC(cmd: %len(cmd));
*inlr = *on;
/end-free
What I did was put the command in a VARYING variable and then used %LEN()
to determine it's length so that I don't have to count the characters.
Yes, that's one extra line of code over using system()! However, if the
QCMDEXC call fails, my program receives and exception message and stops
processing! That saves me having to code a routine to detect the error
and display it. Furthermore, all of the error information is in the job
log. It won't just be the msgid, but it'll be the exact details of the
error.
There's a good chance that a more advanced user or system operator type
person will be able to look at the job log and solve the problem from the
information there. If not, he'll have the option to dump the program,
which gives me additional diagnostics, plus I can look at the job log for
even more diagnostics.
All in less code than it took to call system()!
If you want QCMDEXC to work like system() where it counts the characters
for you and returns a success/fail indicator, you can easily stick it in a
subprocedure and add a few lines of code to make it work like system().
(but with full job log information).
I have to admit, I see people suggest system() as an "easier" alterative
quite often, and I really wonder if they're thinking it all the way
through.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
