How to change message ID RNX0112 message description

[bneal69]

I would like to change the invalid date message text when a program encounters this error. I would like to include additional information about the date. Let the user know that the month, or the day, or the year is not valid. Could someone point me in the direction on how to handle the process either in the CLLE or in the RPGLE.

Thanks
Bryan

[Jonathan Ball]

You could change the text of the message in the message file.

CHGMSGD MSGID(RNX0112) MSGF(QSYS/QRNXMSG) MSG('your message text here')

Don't forget that the message file is replaced when you do an OS
upgrade. You'll have to recreate your change if you make the change to
the message file in QSYS. Some IBM i installations prefer not to touch
the objects in QSYS (message files, compile commands, etc.) and make
copies in another library.

[CRPence]

A "user" should never see the RNX0112. The RPG program should be
coded to handle the error condition. The definition of /handling/ being
the key point; perhaps by communicating the problem and negotiating the
resolution, with additional feedback to\from the user, as required by
the UI. Of course often times the error is prevented by\at the UI
level, to avoid the possibility of the error reaching the
business\backend logic in the RPG program... excepting of course
alternate paths into the routine other than the UI or the UI having a
defect that allowed the bad date representation to get past its validation.

The RPG run-time does a holistic validation of a string [or numeric
value] that represents a date [, time, or timestamp] value. The
issuance of that message is binary; i.e. either the /date/ is valid or
the /date/ is invalid, without any specifics regarding what /component/
of the date is not valid, when that error is signaled. The validation
is performed IIRC, with respect to the DATFMT() that was established for
the compiled run-time object; I am unaware of any program-status value
available to expose the DATFMT() preference compiled into the run-time
object, but with an H-spec the setting could be assumed throughout the
source [rather than hoping to retrieve the setting dynamically, and use
that more generically to perform a validation].

Thus a procedure performing its own validation instead of detection
of that condition by the RPG run-time, is probably the best manner to
achieve what is described as the desirable effect. And in that case, it
is better to create your own message [file and] identifier to issue from
that date-validation procedure, to communicate whatever is desired if
using messaging; i.e. leave the RNX0112 unchanged.

The TEST opcode of the RPG enables, with the operation code extender
'E' or an error indicator ER specified, enables testing the value
without the RNX0112 being logged. The test of the %ERROR BIF could be
used to indicate that the user-program-validation should occur for each
of the sub-components of the value being used for the /date-string/ or
/numeric-date/ representation. So for example, given a 10-byte
character variable storing the value of a /date-string/ that should be
validated, rather than having the error get diagnosed during an
assignment from the %DATE() BIF, use something like the following:

H datfmt(*ISO-)
D myDateVar S D inz(D'1999-06-30')
D char10date S 10A inz('2000-01-01')
/free
char10date = '2013-31-12' ; // day and month reversed
// myDateVar = %date(char10date) ;
// above effects RNX0112 for invalid date string
test(ed) *ISO- char10date ; // Is date-string valid?
if %error ; // date-string is invalid
// call routine to validate date-string and give more
// comprehensive details about the date value using
// some feedback mechanism; e.g. messaging with msgId
// giving more details like the value being validated
callp diagInvalidDate(char10date) ;
else ;
myDateVar = %date(char10date) ; // already validated
endif ;
...

Note: Adjustments would be necessary, if both numeric and character
date representations needed to be validated and diagnosed that way. And
of course rather than coding the TEST in place of each assignment using
%DATE(), probably better to create a procedure that returns the date
result when valid, else diagnoses the error when invalid; e.g. something
like the following, but noting again, the DATFMT() for the current
procedure must be accounted-for [as alluded by the argument passed as
the undefined procDatFmt() function invocation]:
myDateVar = toDateFromChar(char10date:procDatFmt()) ;


<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507326.htm>
IBM i 7.1 Information Center -> Programming -> Programming languages ->
RPG -> ILE RPG Programmer's Guide -> Debugging and Exception Handling ->
Handling Exceptions -> Exception Handling Overview
_ILE RPG Exception Handling_
"ILE RPG provides four types of exception handling mechanisms:

� An error indicator or an 'E' operation code extender handler
� A MONITOR group
� An error subroutine handler
� A default exception handler
..."

<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507337.htm>
IBM i 7.1 Information Center -> Programming -> Programming languages ->
RPG -> ILE RPG Programmer's Guide -> Debugging and Exception Handling ->
Handling Exceptions
_Using RPG-Specific Handlers_
"ILE RPG provides four ways for you to enable HLL-specific handlers and
to recover from the exception:

1. error indicators or 'E' operation code extender
2. MONITOR group
3. INFSR error subroutine
4. *PSSR error subroutine.

You can obtain more information about the error which occurred by coding
the appropriate data structures and querying the relevant data structure
fields.

If you are using the 'E' extender instead of error indicators, the
relevant program and file error information can be obtained by using the
%STATUS and %ERROR built-in-functions.
..."

--
Regards, Chuck