Hi Rob
I understand what you are saying. Just consider that the function/procedure is a little black box. Don't be that concerned about the internal workings, just that it gives you what you want, in this example, for a particular order number, the order type.
Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, March 15, 2012 11:49 AM
To: Midrange Systems Technical Discussion
Subject: RE: Creating an SQL UDF on a procedure
Another thing to consider is are you sure you want to code execution of the subprocedure to be dependent on the internals of the subprocedure (or function)? Let me explain, let's pretend your subprocedure is written in RPGLE. And you are doing your I/O with chain's instead of sql. So your goal is to avoid the overhead of opening/closing the file on each execution of the function. Admirable. However, if the subprocedure is fundamentally changed do you want to have to change all the programs that call that function? Again, for example, you rewrite it by using sql instead of chains. Or you rewrite it by consuming a webservice that
provides the result or ... Now, all previous executions were jumping
through hoops to ensure that files were closed upon completion by calling it with a special parm or whatever. How do you handle that?
Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Alan Shore <ashore@xxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 03/15/2012 11:39 AM
Subject: RE: Creating an SQL UDF on a procedure
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Thanks for your reply Paul.
What you are telling me, is that I need not be concerned about the SQL
function not specifically closing the files, because the system will close
them for me?
Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Morgan, Paul
Sent: Thursday, March 15, 2012 11:36 AM
To: Midrange Systems Technical Discussion
Subject: RE: Creating an SQL UDF on a procedure
Alan,
Will holding a lock (file and maybe record) cause a problem? Is the
program buffering any file data that could be held until file close? The
file does get closed at job end.
Paul Morgan
Principal Programmer Analyst
IT Supply Chain/Replenishment
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Thursday, March 15, 2012 10:53 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Creating an SQL UDF on a procedure
Hi everyone
We have a procedure that leaves the files open until the procedure is
called one final time with an extra parameter to close the files For
example, within an RPG program
Ordertype = getOrderType(Ordernumber);
And then at the end of the RPG program
Ordertype = getOrderType(Ordernumber: Closefiles);
We now need to create a function on this procedure. I don't have a problem
creating the function. My concern is that the "final" call - namely
Ordertype = getOrderType(Ordernumber: Closefiles); - will NOT be done (or
is there a way to do it).
My questions to the panel are - is this a cause for concern?
Will this be a problem at some time?
Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
Disclaimer: This message contains confidential information and is intended
only for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake
and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission. If verification is required please request a hard-copy
version. Any views or opinions presented are solely those of the author
and do not necessarily represent those of the company.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
