Re: CVTDAT Date limits

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hmm..  I always thought that commands with TYPE(*DATE) parms are kinda 
handy. It "normalizes" the date, if that makes sense...  so it doesn't 
matter whether the caller is sending MM/DD/YY or DD-MM-YY or YYMMDD or 
MMDDYY or DDMMYY, etc...  it always gets to your CPP as CYYMMDD, I think 
that normalization is quite nice!

I can understand the argument that you'd prefer it were passed to your 
CPP as YYYYMMDD, since CYYMMDD is a weird format.  If that's the case, 
you could certainly file a DCR with IBM and ask for a TYPE(*DATE8) or 
something like that to solve that problem.

But, no matter what the format, as long as it's using *DTS under the 
covers, it'll have the 2071 limit that Bruce mentioned.  And of course 
using the QWCCVTDT API (or the much nicer, imho, ILE date/time CEE APIs) 
instead of the CVTDAT command should lift that limitation.

On 11/12/2015 1:03 PM, Peter Dow wrote:
> Unfortunately, if you're defining commands with parameters of type
> *DATE, "When it is passed to the command processing program, it is
> always passed in the format Cyymmdd..." (from the PARM keyword help text).
>
> I supposed you could use type *CHAR and write a validity checking
> program to go with it, but so far for me it hasn't been worth the effort.