** 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.
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.
Comment