From: Alan Campin
But this is easy to implement in a service program. You simply have 4
procedures and Get Customer price can simply call Get Base Price to get
the base price and you can call Get Discount Details in a loop and
performance is never going to be an issue.
I'm only going to get into this once, because I happen to agree that ILE is
the way to go. It makes design of properly encapsulated business logic much
easier. However, I must point out one thing:
Nearly EVERYTHING you implement with procedures can be implemented with
called programs, and in fact we did most of it over the years at SSA and
other places. Not uniformly and not perfectly, because it required more
work with the more primitive languages, but we did pretty good.
The most straightforward way to do things was to pass data structures with
lots of parameters, similar to what Alan said, and then have an opcode that
determined what actually happened. This really wasn't too difficult, and it
worked quite nicely.
It's even easier nowadays with based data structures and pointers; a program
can accept a pointer to a parameter and an opcode that identifies the layout
of the parameters. If you're even nuttier, you can pass just the data
structure and the first portion of the data structure can indicate the
format of the rest of the data structure (IBM likes this technique).
Privacy must be enforced through programming, certainly, but it can be done
quite nicely. You create "handles" to data structures, and those handles
are passed. External callers simply pass in the handles as necessary.
Again, a technique that's been around for a long, long time.
The beauty of CPF->OS/400->i5/OS is the late binding of program calls. As
far as I know, it's a unique capability of the platform. I've always
enjoyed the power of bidirectional program parameters and ever since I tore
apart my first monolithic program (SFC600) most of my main programs are
calls to subprograms, which in turn call other sub-subprograms, which all
share utility programs. I've been doing that in OPM and its predecessors
for nearly 20 years now.
My point?
It's not that ILE is not better. I believe ILE is indeed a better syntax
for encapsulating business logic, and modules, especially service programs,
allow a much easier maintenance and enhancement of that encapsulated logic.
However, how you encapsulate is up to you, not the language. The language
may make it easier, but if you don't know how (and better yet WHY) these
features work the way they do, it's unlikely that you'll use them properly
anyway. On the other hand, if you know how encapsulation really works, you
can do it in 8086 C if you have to (trust me, I've done it).
Anyway, I'm a big ILE fan. I'm nowhere near as good at service programs as
I should be, and that's probably due to inertia of having had to do manually
most of what ILE does today -- I think I wrote in an article about how
activation groups did away with one of my most elegant techniques for
registering programs and programmatically setting on LR <smile>. But I just
want to put forth my opinion that if you know why you certain programming
techniques are better than others, then you can implement them with whatever
tools.
In the end, it's pretty much load, store, add, subtract, compare and branch.
Joe
midrange.com
