× 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.
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.

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/

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2023 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.