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



<snip>Tried to get another developer to use it but he could/would not
understand. When I wrapped a callable program around it, he used it all the
time. I guess the upside is he is using my module.
...
"Why are you making it so hard? Give us the program name and we'll just
call the program directly."
</snip>

I assume the problem with the procedures and service programs is, they don't
know how to handle them.

Create a binding directory, register your service programs in this binder
directory, add the binder directory to the H-Specs (just give them a copy
member for the H-Specs) and voila, everybody can use your procedures and all
programs can easily be compiled with CRTBNDRPG.
I had programmers, who thought ILE concepts is too complex and a few of them
were not flexible enough to understand how it really works and will be never
able to write a new procedure
... but they were all able to call the procedures.

For example our WOPiXX package(which allows RPG programmers to write web
applications solely with RPG and which is by the way free), consists of
almost only callable ILE procedures and functions.
We ship a copy member with the H-Specs (which can be used or be replaced
with individual ones) and a copy member containing all prototypes.
Embedding both members in the source code, allow the procedures and
functions to be called and the programs to be compiled with CRTBNDRPG.
... and recently one of our customers (WOPiXX user) told to another one:
"You don't need ILE, it's just normal RPG" (IMHO these WOPiXX programs are
the only ILE programs he ever wrote)

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Roger
Harman
Sent: Montag, 11. September 2017 04:44
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Database I/O Modernization

+1 <frown>

I have a service program that does some really complex calcs. Tried to get
another developer to use it but he could/would not understand. When I
wrapped a callable program around it, he used it all the time. I guess the
upside is he is using my module.

We're writing an EDI (like) interface for an external source and I wrote CL
Commands for all the config/data retrieval and CSV/tab/pipe file
processing...

C'mon people....


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Sunday, September 10, 2017 7:02 PM
To: Midrange Systems Technical Discussion
Subject: Re: Database I/O Modernization

<snip>

Companies I used to work at I would write service programs but the
programmers demanded that I write a callable program wrapping the procedure
because they would not touch a procedure. Same thing were ever I have been.
</snip>
This sounds familiar.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 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 Campin <alan0307d@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 09/08/2017 07:04 PM
Subject: Re: Database I/O Modernization
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Not really. You are limiting SQL. This allows a single table. What happens
if I need to join together three tables. With SQL, I just write the
statement or create a view.

There is a way to write these things that is high efficiency and multiple
tables but again why bother if you have SQL.

And the basic problem is here that if you are stuck in the past and still
using RLA instead of SQL why would you use procedures? You wouldn't. You
would avoid them like the plague. That's why IBM had to come up with OA.

Anything you can do in OA you can do as good or a lot better in a
procedure
and a service program but IBM knew that most RPG programmers would never
use a procedure so they created OA.

Companies I used to work at I would write service programs but the
programmers demanded that I write a callable program wrapping the
procedure
because they would not touch a procedure. Same thing were ever I have
been.

On Fri, Sep 8, 2017 at 3:45 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

On Fri, Sep 8, 2017 at 4:02 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

Pretty easy answer. None. Use SQL. IBM has spent unknown millions of
dollars developing SQL which does the same times a thousand. Record
I/O
is
obsolete. Let it go.


Alan, if I understand correctly, you object specifically to the use of
RPG
op codes. But what about the procedure interface implemented in the
service
program?

If the RPG op codes were replaced with SQL, would the procedure
interface
meet with your approval?
--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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.