× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.