Originally, IBM CMOD dates could only be between 1970 and 2069 - a limitation that's been removed with the addition of native database date fields. However, there are still a few leftovers from those days. An Application Group with the old 'date/time' fields can only represent dates out to 2038 or so. And if you have a cache-only system, and you've (ever) entered "36525" in the 'Life of Data and Indexes' parameter in the Application Group definitions, you've likely run into an overflow situation -- the current date + 100 years = a number bigger than Content Manager OnDemand can handle.
This is probably still an IBM CMOD bug -- you'd be best to open a PMR and ask for some guidance.
Also, just for the record, the numeric directory name (17368) you mentioned used to be the date an entire directory would expire -- this is, again, a remnant of a time when I/O bandwidth was painfully slow, and you wouldn't ever want to review each and every file in the cache -- but instead, you'd want to delete a whole directory of documents that were eligible for expiration. That isn't the case anymore -- disk I/O is blazing-fast -- so verifying the entire cache filesystem, looking for documents to delete is a reasonably fast task. Because you have some numbers are beyond what IBM CMOD's arsdate command can handle, it's best to call IBM to find out how to deal with this.
Don't forget to report back and let us know how you solved this issue!
-JD.