Vernon,

Yes, utlimately, it's turtles all the way down.

;)

On Thu, Dec 4, 2014 at 11:46 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi John

At some level, everything we use is a black box - and that applies to
everything from "normal" RPG opcodes to RPG %bifs to SQL functions (no
%bifs in SQL!) - and all the way back to assembly language instead of raw
machine code.

You speak of being in control - yes, that might have some benefit - but
every time we use a language, a further abstraction, we give "full" control
to someone else. There's always a trade-off - easier development vs. maybe
the most extreme optimization or knowing exACTly what is happening - I
guess I don't need to know the details so much.

You say that using SQL, "...you think that something will bite you in the
future..." - I just don't see that as valid - again, we COULD be bit by
everything any language or abstraction gives us to use. SQL is VERY
standardaized - I don't worry about something breaking as to syntax and all.

I'm going to go out on a limb here - I think our efforts are better spent
on making procedures for our business processes and less on writing
"better" versions of functions readily available, either through native RPG
or embedded SQL.

Oh yeah - everything we do in RPG ends up as a CALL to something - native
stuff calls the RPG engine, embedded SQL calls the SQL engine - an engine
in either case - just look at the actual code used in an SQLRPGLE - calls
to the same program repeatedly. I compare this to the Open Access handler
concept - YOU give the system the program to be called instead of the RPG
engine - everything is a call to something

Just thinking too early in the morning!
Vern


On 12/3/2014 9:40 AM, John E wrote:

Luis,

The "a bit faster" part is not very relevant, as it won't be noticeable
(maybe if you execute it 384.400.000 times).

The main reason - if the choice is mine - to choose the RPG implementation
instead of "default to" SQL, is that with a one-time investment you don't
have any dependency on SQL, and you can adapt the functionality of the
procedure to your own specific needs, if necessary. You're in control.

Especially if it's "simple" stuff, like replacing chars in a string, etc.

This example, calculating the weeknumber, is more tricky so i can imagine
you don't want to risk it. Also, there's not much reason to tweak or adapt
calculating weeknumbers. IMO, it makes things more simple, to not be
dependent on the SQL preprocessor and SQL runtime machinery just because
you have a couple of procedures which are a bit tricky to implement. For
me, it would be worth it. I don't dismiss SQL, of course, just use it for
what it was meant for.

It's a one time investment, and 90% of time is spent on gathering
information not actual coding, which will pay off the next x years. Once
implemented you can really forget about it. If it's implemented with
embedded SQL, and you forget about it, i think it will bite you sometimes
in the future. But maybe i'm wrong about this.

I also think that many programmers just don't want to implement it
themselves. E.g. a %replchar bif can be easily implemented with "normal"
rpg code, doesn't take days, and you can add all kinds of functionality
you
think of instead of being "locked" into the functionality that's given by
the equivalent SQL bif.

-snip-

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



This thread ...

Follow-Ups:
Replies:

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

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