I believe tha in real life other options may have more weight than message-files
** This thread discusses the Content article: The API Corner: Still Using Compile-Time Arrays? **
The system-i specific of message-files may be more a hindrance than a help.
The 5th unmentioned option, is to create a single purpose program that determines the order status. This is a true separation of concerns for retrieving the description. It has it's advantages:
* say that in the future, that order status is determined by not just Ordstst, but by another database field in the record or in other database records. The separated logic in an external program is more easily modifyable as it is external from the programs.
* once separated, the code is more re-usable as a function or prodcedure. The combinations of the two approaches, to extract the logic out into a program or procedure, AND to use message-file text storage, may be a better good solution, but still probably not the best.
* the goal should be to keep the logic small and containable (following the Single Responsibility Theory). Then wrappers for non-system-i languages is possible.
* So for real future flexibility, the wrappering of this functionality into a SQL UDTF function makes it the most adaptable. It is then applicable to dot Net, Java or PHP implementations as it can be wrappered for general use by a non-system-i application. Choice 3, storing it in a retrievable database file, also allows SQL access to the text easier than using message files.
But it is a good article on a sample usage. But converting to message files may not be the end-all of the redisign.
One of the problems I encounter into as I work with various companies is that "real life" varies so much! I happen to agree with your proposal of providing (in this scenario) the text associated with an order status by way of a shared function. If the company uses SQL, a UDTF approach would be taken (and I've implemented many such). For companies that, for one reason or another, don't have SQL -- an exported *SRVPGM function makes sense. Or, which I often end up doing, both -- though in that case the *SRVPGM export uses a return value (rather than a parameter as I did in the article) so I can easily have the function accessed by either SQL UDTF or a procedure call. Depending on the situation the UDTF/procedure might then accept simply an order number, a company and an order number, or (as shown in the perhaps overly simplistic article scenario) a message ID.
This function may then implement order status text access with a *MSGF, a message catalog, a database access, or any other mechanism that makes sense for the platform/application. As the article was in the "API Corner" I chose to use a *MSGF and, in the next article, an implementation based on the QMHRTVM API (I hadn't planned, and still haven't come to any conclusion on, an article using message catalogs -- another set of APIs availabe on i and more oriented to portability). In the simple article scenario using database could also easily provide the function as the scenario is not utilizing replacement variables within the message text (with possible sentence restructuring due to language translations -- an area I am often concerned with when displaying textual information).
I most definitely agree that using a *MSGF is not an end-all to all application (or company) requirements. I do believe that a *MSGF is better than storing textual information in a compile time array, and that a UDTF and/or *SRVPGM export is a good general starting point.
A small article about message catalogs sounds good.
Thanks for the reply.
Your articles always make us readers think.
> . . . an implementation based on the QMHRTVM API . .
I insert a logger to the joblog while developing an app - getting close to T.D.D. and RSPEC - - - with a subproc of @jRPG() with up to 4 message lines, and then disable it into a program comment as @cRPG()
Thinking out loud, maybe i should turn it into more specific with messageID. That is really what I like about the many facets of messaging - - I should probably build my generic logger into a messageID (one for each RPG program) so that logs could be searched even better., and logs directed better, to something other than *INFO messages.
> . . . an article using message catalogs --
I would love to hear about these. Their advantages and drawbacks.
Are they available on V5R4 ?
Tags for this Thread