Re: Has anyone done any processing with OA and WORKSTN device types?

On Jun 27, 2011, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

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

No argument here. In fact I have made a point in all my lecturing/writing on the topic to say that I don't recommend individual shops to undertake this kind of effort - far better to buy one of the third party solutions. Of course there are customer like one I had that prototyped and wrappered all of the C display file functions so they could have a truly generic subfile handler program. But they are the exception.

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.

You can either choose to have the name/value pairs and loop through it or you can elect simply to take the whole buffer. I suspect most of the vendors take the buffer as they will have to extract the metadata from the display file anyway and so might as well get a faster response and add the from/to info to the list of data retireved.

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

My point was not that the way in which data was presented was elegant - but that the way state information was handled was elegant.

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.

As I said earlier - I don't recommend writing your own handlers. I suspect that the cost of buying one is less than the cost of writing even a simplistic one. The OP seemed to be headed towards writing one so I simply stated that I might do it on a one-off basis - for fun if nothing else. But as you state I have been saying for a long time that for an individual shop it is far a better solution for non-display files.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com