IBM i message

RNQ0112: Date, time or timestamp value not valid

RNQ0112 means an ILE RPG program tried to use or convert a date, time or timestamp value that isn't valid, such as month 13, day 32 or a string in the wrong format. It matches RPG program status code 00112.

Other names for this code

Also written as RNX0112, status 00112, RPG status 112, %STATUS 112, RPG invalid date, RNQ0112 %DATE.

What it means

RNQ0112 is an ILE RPG runtime message for program status 00112, which IBM's ILE RPG Reference lists as a date, time or timestamp value that isn't valid. RPG date, time and timestamp fields can only hold real values. When a program converts something else into one of those types, the runtime checks it. A value that doesn't name a real date or time raises the error.

Most cases come from legacy data. Many IBM i files store dates in numeric or character fields, such as an 8-digit number like 20261018. Modern code turns them into real dates with %DATE, %TIME or %TIMESTAMP, or with MOVE into a date field. If the stored value is 0, 99999999, or a date in a different format from the one named in the conversion, the result is status 00112. Related problems have their own codes. Status 00113 is a date that overflows or underflows in arithmetic. Status 00114 is a date that can't be mapped to a 2-digit year format.

RNQ0112 is the inquiry form, sent when nothing in the program handled the error. The job waits for a reply on the user's screen or, for a batch job, usually in QSYSOPR. RNX0112 is the escape form of the same condition. It is logged without waiting and can be caught by MONITOR or a caller.

Common causes

  • A numeric date field that holds 0 for "no date", converted with %DATE.
  • A special value such as 99999999 or 9999999 used to mean "never" or "open".
  • A date in a different layout than the format named in the conversion, for example day-month-year data read as *ISO, which expects year first.
  • Bad data entered on a screen or received in a file from another system, such as 31 June or hour 25.
  • A time or timestamp string with missing parts or the wrong separators for the format code used.

How to find the problem

  1. Press F1 on the message. The help text gives the procedure, program and statement number. For batch jobs, look in QSYSOPR (DSPMSG QSYSOPR) or in DSPJOBLOG.
  2. Find the statement in the compile listing and note the conversion and the format code it uses, such as *ISO, *USA or *YMD.
  3. Look at the source value for the record being processed. A reply of D gives a formatted dump with the field's value. You can also display the record with DSPPFM or a query.
  4. Search the file for other bad values in the same field, since one bad record often means there are more.

How to fix it

  • Test the value before converting it. TEST(DE) *ISO datefield sets %ERROR on when the value isn't a valid date in that format, so the program can skip or report the record.
  • Handle special values such as 0 and 99999999 explicitly before calling %DATE.
  • Make sure the format code in the conversion matches how the data is stored.
  • Use a MONITOR group with ON-ERROR 00112 around conversions of data you don't control.
  • Reply C for the waiting job, correct the bad records or the code, then rerun.

IBM documentation

IBM Display Message Descriptions (DSPMSGD). Use the documentation for your installed release.

This link opens the relevant IBM reference library or lookup instructions. Match the complete code and your installed product release; it is not a code-specific review.

Report a correction to WND Software.

Questions

How do I check a date before converting it in RPG?

Use the TEST operation with the D extender, for example TEST(DE) *ISO datefield. If %ERROR is on afterwards, the value isn't a valid date in that format.

What is the difference between status 00112 and 00113?

Status 00112 means the value isn't a valid date, time or timestamp at all. Status 00113 means a valid date went out of range during arithmetic, such as adding years past the largest date the format allows.

Which reply should I give to an RNQ message?

C (cancel) is the safe answer when you don't know the program. D and F also cancel, but first write a dump the developers can use. G skips the rest of the current RPG cycle and resumes at its input step (*GETIN). That is a call for the program's owner to make.