Suggestion: %DATE() compiler warning

[mlopez01]

Hello,

We just got burned with RNX0112 (Date, Time or Timestamp value is not valid) in a ILE RPG program because it was accidentally compiled with CVTOPT(*DATETIME) and a PF used in the program has a timestamp field (Z) and was the parameter to the %date() BIF.

The instruction that crashed was %date(FIELD), where FIELD is the TIMESTAMP field. The date format for the program is *ISO.

Unless I'm missing something and there's a case where you can use %date() with a 26-character field, I think that a compiler error should be issued.

Any thoughts?

Mike

[Peder Udesen]

You could raise a RFE at IBM

[mlopez01]

I raised an RFE at IBM.

[Scott Klement]

imho, there isn't really any problem with allowing longer strings to be passed to %date(). This can be very helpful when, for example, you have a large field that sometimes contains a date + blanks. The %DATE() function can get the data from it.

Also, %DATE( )can accept a timestamp as a parameter, this is an easy way of extracting the date portion of a timestamp.

So I think it makes perfect sense the way it is. I think Mike had a bug in his program that he was using %DATE() when he meant to use %TIMESTAMP(). I know how frustrating it can be when its hard to find a bug and you spend a lot of time on it! But, I don't think its fair to blame the compiler. The compiler isn't really intended as a way to find the bugs in your programs.

[mlopez01]

I think %DATE(expression) shouldn't fail if "expression" is a 26-byte character field and has a valid timestamp value. The problem arose when someone here accidentally recompiled a program using CVTOPT(*DATETIME). That caused a TIMESTAMP field in a PF to be converted to a 26-byte character field and, subsequently, caused the %DATE() function to fail. I think %DATE() shouldn't fail in this type of situation. I think the fix is to change %DATE() not to fail, or issue a warning/error in the compilation and not just a mention in the listing that the field will be 26-byte character, as it does now. It's quite hidden.

[mlopez01]

I think %DATE(expression) shouldn't fail if "expression" is a 26-byte character field and has a valid timestamp value. The problem arose when someone here accidentally recompiled a program using CVTOPT(*DATETIME). That caused a TIMESTAMP field in a PF to be converted to a 26-byte character field and, subsequently, caused the %DATE() function to fail. I think %DATE() shouldn't fail in this type of situation. I think the fix is to change %DATE() not to fail, or issue a warning/error in the compilation and not just a mention in the listing that the field will be 26-byte character, as it does now. It's quite hidden.

[Barbara Morris]

If the character field has a valid date in the first 8 bytes and blanks in the remaining bytes, it works fine with %DATE.

[mlopez01]

I don't think %DATE(expression) should fail if "expression" is a 26-byte character field and has a valid timestamp value.

[Scott Klement]

Mike,

At the start of this thread, you suggested that a 26-character field should cause a compile error.

Now you are saying that you don't think it should if it has a valid time stamp value.

Please understand that at the time that the source code is compiled, there isn't any value in the variable yet. The variable values are set when the program is run... there's no way the compiler can know what the value would be. It'd need to base its decision purely on the type/length of the field, not on whether its value is valid.

There is already a run-time error when the value isn't valid. That's the "RNX0112 (Date, Time or Timestamp value is not valid)" you mentioned in your original post.

[mlopez01]

Scott,

Yes, I did suggest that and still think it should - if IBM doesn't change %DATE(expression) to successfully evaluate the expression even if the expression's value is a valid timestamp value represented as a 26-byte character field. After my post someone here pointed that out. I agreed.

I know how it works and there's no way the compiler developer can know ahead of time what the RPG programmer is going to put into a 26-byte character field. RNX0112 is necessary.

So, if IBM would make that change to %DATE(expression) then the rest of this post is moot and there's no good reason to keep reading.

If not, then ...

The run-time error shouldn't happen under the following condition (this is what I posted to the RFE community):

IF:
1) %DATE(expression) is used,
2) "expression" is a TIMESTAMP field from a database file,
3) CVTOPT(*DATETIME) is specified at compile time,

THEN:
1) ERROR if "expression" is not modified
2) WARNING if "expression" is modified.

Currently the compile listing adds a line after the PF field definition in the I-Spec section that states "External data type is Timestamp". That's not enough. No one I know reads an entire compiler listing. They go to the "Message Summary" section to look for warnings and errors.

A run-time error should not have occurred, since a value was a valid timestamp value being represented in a 26-byte character field.

It's my belief that the programmer should not have been able to compile the program in the first place since condition 1 of the "THEN:" block (above) applied. The compiler developers know where a field is defined and if it is modified, so it's not a stretch to make this check.

FWIW.

Mike