Re: Get Start Date of a Week Number

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-