I found these pages helpful:
https://alcor.concordia.ca/~gpkatch/gdate-algorithm.html
https://alcor.concordia.ca/~gpkatch/gdate-method.html
The second page is referenced from the first one, so you really only need the
first one.
According to the algorithm description on the second page, the
Besides, the TIME macro generates non-reentrant code which under CICS I'd have
to make reentrant by moving its parms into the "working storage", which the
subroutine just can't afford to getmain+freemain
STCK is an input parm, so it doesn't need WS, but you are right, I am planning
to "mis-use" the Register Save area as the program needs only a couple of
registers to perform the calculations
On 2015-11-16, at 08:57, Victor Gil wrote:
> Besides, the TIME macro generates non-reentrant code which under CICS I'd
> have to make reentrant by moving its parms into the "working storage", which
> the subroutine just can't afford to getmain+freemain
>
Doesn't STCK also require "working
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.
A$$uming you want the current day [TOD] of
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
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
On 2015-11-16, at 10:17, Gary Weinhold wrote:
> Depending on how long the process runs and you're concerned that it will
> start before midnight and end after, you could force an EXEC CICS call if
> TIME is > 23:59. So there'd be a few higher overhead calls right around
> midnight.
>
If
Had a strange occurrence-wanting to see if anyone can explain.
IODF has and has always had following
CF01 MFID of 6
LPAR1 MFID of 1
LPAR2 MFID of 2
LPAR3 MFID of 3
LPAR4 MFID of 4
LPAR5 MFID of 5
New LPAR MFID of 7
The policy had CF01 as policy 0 >> been this way before I can remember
We did
Yes, this is what I am now thinking about - use the EIBDATE and EIBTIME [i.e.
local DATE and TIME] available from the CICS and interrogate CVTLDTO to
determine the GMT DATE. Which in our case should be 6-7 hours ahead.
This is only to determine the right DATE.
One issue which requires
Depending on how long the process runs and you're concerned that it will
start before midnight and end after, you could force an EXEC CICS call
if TIME is > 23:59. So there'd be a few higher overhead calls right
around midnight.
Gary Weinhold
Senior Application Architect
DATAKINETICS |
Rather than re-inventing a wheel why not use the Language Environment
callable service CEELOCT (get current local date or time)
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clcloct.htm%23clcloct?lang=en
Which should be CICS-friendly.
If you have to do it
On 2015-11-16, at 15:19, Dougie Lawson wrote:
> Rather than re-inventing a wheel why not use the Language Environment
> callable service CEELOCT (get current local date or time)
> https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clcloct.htm%23clcloct?lang=en
>
Paul Gilmartin wrote:
>> Which should be CICS-friendly.
>But does it meet the OP's performance requirement?
Probably not, because you call CEELOCT using 4 parameters (in workspace) and
depending on needs, may need also call CEEDATM after checking your CEELOCT
output for validity.
And there
14 matches
Mail list logo
