On 6/27/2011 10:07 AM, Jon Paris wrote:
One of the points raised by Joe (calling from one program to another when both use subfiles etc.) is not quite as difficult as it might be because of the simply elegant way in which OA handles state information. As long as any arrays etc. related to the subfile are stored within the file specific storage area then RPG effectively takes care of it for you as whenever the handler is called you are immediately connected to the file specific storage. This also makes it a simple task to write a handler that can be used for multiple files in a single program.
Yes I suppose it's not "as difficult as it might be" but that still
leaves quite a bit of difficulty factor to play with. You have to
allocate an array of data structures to represent the subfile (which in
turn means that you have to know the size of the subfile and of the
subfile records).
And of course the problem there is that if I'm not mistaken, you don't
actually get a data structure with the data in it. You get a big array
of IBM-defined QrnNameValue_T data structures, one for each field, that
you have to spin through to find the actual data, all of which has been
converted to character data. So the first thing you need to do is
re-convert that data back to something resembling your original data
structure so that you can store it in the array that you allocated and
stored in your file specific storage area.
"Simply elegant" isn't the phrase that leaps to mind for this. At least
for Java IBM provided a Java toolbox API that would convert between an
EBCDIC data structure and a Java object. This might be a bit more
palatable if IBM provided a similar API for their QrnNameValue_T data
structure; one would expect the API already exists under the covers and
simply needs to be surfaced.
And there's still the rest of the reverse engineering that has to
happen. Handling which values to plug into the INFDS is hard enough
with one subfile - it's even more fun with two! Yes, I know that's an
edge case and if you already know which features you need from your
display file, you can probably write file-specific handlers without an
inordinate amount of work. But then that means each time you want to
use a new DDS keyword in your RPG program, you need to check and see
whether it is supported in the handler for that file.
And of course my real problem with this is that it simply kicks the can
down the road as far as real rewriting, which provides so many more
benefits. Rather than write a new file handler for each display file,
why not invest in the time to rewrite the program and separate the UI
from the business logic? Then you have a real advance in your
architecture, and you can do whatever you want, from web services to
mobile apps, without an intervening layer, fee or no fee.
OAR may make sense for non-display files, but it sure doesn't seem like
the first choice fit for UI modernization. It you don't want to
re-engineer your programs, then it seems in a make vs. buy analysis the
cost of any of the available modernization tools would in most cases be
preferable to the cost of writing your own version of HATS.
Joe
midrange.com
