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.



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].