×
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.
It was never an issue until I realized I had to send pgm msg to ext q, rcv
the same msg to prevent it from executing and then call qcmdexc. If this is
not done the qcmdexc call never ends up in the joblog and whether this is
desirable or not depends on the req and/or pers. pref. The message key part
came in when I realized it could be used in rcv msg to start the error
search. I would need to collect about 3 errors to store for history after a
recursive call, for example. Part of this is requirement, the other just
curious on better ways to achieve the samething. I need the call in the
joblog so I'll just use the key to search from there backwards up the q
until the end which equals all the errors.
Efficiency, sure, it's gone from call qcdexec and rcv no error if occurred
on call to:
snd call text to ext q ( this will post text in joblog)
rcv back to prevent execution.
call qcmdexc
if errors occurs use key or time and go back up q to get all error msgs from
call.
Note I could call qcmdexc and from the last msg in the q keep searching
until reach the time before qcmdexc is called and that would be all the
errors too. It just depends, since logging to the joblog is desirable.
Note it's not an occasional qcmdexc call, it's alot and completely
dynamic(conditions beyond my control) but yes I'm not going to worry about
it at this point.
This was definitely a good learning exercise. IMHO, if I wasn't so darn
busy I'd still go straight to the qjobmsgq and roll my own because if it's
just a matter of logging the msgs on the q and then surfing it if error
occurs. Yes I think this is alot of overhead just for every qcmdexc call.
<IBMVENT>
What qcmdexc and/or QCAPCMD should be doing is logging these calls as an
option and reporting the full error txt back. But that's too logical,
calling 4 diffrent api's plus repeated calls to get the errors associated
with the call is much better. Sorry I'm an efficiency guy.
</IBMVENT>
Thanks for the help though!
From: "Leif Svalgaard" <leif@xxxxxxxx>
Reply-To: MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>
To: "MI Programming on the AS400 / iSeries" <mi400@xxxxxxxxxxxx>
Subject: Re: [MI400] QCMDEXC errors
Date: Fri, 19 Mar 2004 09:03:01 -0600
From: Ted Slate <tslateone@xxxxxxxxxxx>
> message had been sent previously. I not thrilled with this overhead
from
> the send, receive and then qcmdexc just to get the actual error if one
> occurs but don't know another way.
why worry about efficiency for error conditions? these happen
rarely (one hopes).
_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.
_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE
download! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/
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.
midrange.com
