If you have code already that extracts the time portion, does that mean
you have a quotient that is the number of days since Jan 1, 1900?
Do you know that all dates you are working with will be more recent than
some date (for example, if the value you're converting is from a current
STCK instruction, it's more recent than November 15, 2015)?
Is it sufficient if the routine is only valid for the rest of the
century (or til 1942, if you're using STCK rather than STCKE)?
The routine becomes simpler the more of these are true. Because
basically it's the number of days divided by the number of days in a
year, adjusted for leap years, to get the year, then a table of
subtractions to determined the month, adjusted for Feb 29 in a leap
year, and the remainder is the day within the month.
Gary Weinhold
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone +1.613.523.5500 x216
Email: [email protected]
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
__________
On 2015-11-16 09:41, Victor Gil wrote:
Does anyone have a sample code which decrypts Time-of-Day [obtained via STCK]
into displayable format?
I have several samples [inluding my own from around 2000] which extract the
TIME portion, but now I need the DATE as well.
The reason I don't want to code STCKCONV is this is going to be used in a
high-volume transaction process under CICS, so I'd like to minimize the
overhead.
TIA!
-Victor Gil-
