I've been working with several of these recently, and have some comments/concerns/questions about using them. Note that I understand that they're behavior is based on ISO COBOL standards, so not under control of (only!) IBM.
Firstly, the requirement of a "timestamp literal", rather than the routines simply determining if a string is in correct timestamp (ISO 8601) format, makes use of the functions very inflexible. The assumption seems to be that protocols will have explicitly defined use of a particular time format (unqualified, UTC, or offset from UTC), and also the number of digits for decimal fraction. In the particular case of the protocol I am using (ISO 20022) that is not the case. All three of the time formats are supported (in extended format), and there is no particular limitation on the number of digits for the decimal fraction. Some examples have 3 and some have 0. This all means that I have to test the date value against up to 12 different datetime literals. And even then, that assumes there will be no more than 3 digits for the decimal fraction. Am I missing something obvious, as this seems to be a terrible design.
There does not appear to be a function to retrieve the time zone offset value from a formatted time. Is there some other way to convert from a non-local time to a local time (other than doing my own parsing of the date/time field, which of course is possible)?
There also seems to be lacking the inverse of the COMBINED-DATETIME function. That is, you can create a combined date/time value using this function, but you have to manually recreate the date integer and seconds value if you want to use any of the functions that return date/time values. I guess maybe the function is designed only to handle datetime comparisons.
------------------------------
Frank Swarbrick
------------------------------