RE: Feed result set into a command

["Metz, Zak" <Zak_Metz@xxxxxx>]

Hey Vern, yeah I guess I must have been the only Saturday crazy after all.

I think I'm settling on doing this in Net.Data. I already have a mechanism to 
run a macro without a browser's involvement, and since it's so easy to process 
the result set from there...

Thanks for the info about UDFs!

Kind regards,
Zak Metz

-----Original Message-----
From: Vern Hamberg [mailto:vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Monday, April 05, 2004 12:50 PM
To: Midrange Systems Technical Discussion
Subject: Re: Feed result set into a command


I see no one's answered this over the weekend!

It's generally best to have UDFs that do the least work possible - they are 
called for every row of a table. Admittedly, there may not be that many 
rows here, but each row has to wait for the UDF to finish, and if MAILTOOL 
were to have any kind of delay, the SQL statement could timeout on you. The 
same thing can happen while debugging, BTW.

I recommend putting the exception join into an RPG program (or REXX, if you 
want some cool fun and something that no one else in your shop could 
maintain). Then use a FETCH loop and call MAILTOOL for each - you can 
prototype QCMDEXC nicely - see the Redbook by Jon Paris, et al., on stuff 
you never knew you could do in RPG.

You could also do this in CL, using STRQMQRY with an outfile, then RCVF on 
that outfile -- anti-CLers need not respond  ;-)

HTH
Vern

At 08:51 AM 4/3/2004 -0500, you wrote:

>Greetings fellow Saturday-hackin' crazies.
>
>I need to do an exception join and process each record of the result set 
>with a command. 
  
NOTICE: This E-mail may contain confidential information. If you are not 
the addressee or the intended recipient please do not read this E-mail 
and please immediately delete this e-mail message and any attachments 
from your workstation or network mail system. If you are the addressee 
or the intended recipient and you save or print a copy of this E-mail, 
please place it in an appropriate file, depending on whether 
confidential information is contained in the message.