Re: TOD conversion to display

@LISTSERV.UGA.EDU Subject: Re: TOD conversion to display On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <paulgboul...@aim.com> wrote: >one institution overcame a disadvantage >by introducing a wire(!) delay line to delay its competitor's transactions >by a few millisecon

Re: TOD conversion to display

On 2015-11-18, at 10:08, Tom Marchant wrote: > On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin > wrote: > >> one institution overcame a disadvantage >> by introducing a wire(!) delay line to delay its competitor's transactions >> by a few milliseconds. > > That would

Re: TOD conversion to display

On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin wrote: >one institution overcame a disadvantage >by introducing a wire(!) delay line to delay its competitor's transactions >by a few milliseconds. That would be a really long piece of wire. -- Tom Marchant

Re: TOD conversion to display

I have a program that converts a STCK to a WTO. It is reentrant, but you will need writable storage for the displayable string. Samples: +TODCON2 TOD= DATE= 9/17/2042, TIME= 23:53:47.370495 +TODCON2 TOD=CFDCC9B74A2892CB DATE= 11/17/2015, TIME= 13:15:43.795849 sas On Tue,

Re: TOD conversion to display

On 2015-11-17, at 08:21, Victor Gil wrote: > I guess you missed the whole point of not calling a supplied callable service > ... > > Regarding STCKF - this is indeed a great tip and I'd probably consider using > it except we have to use STCK anyway [along with the LPAR id extracted once >

Re: TOD conversion to display

Well, it doesn't support STCKE format directly (it's just a SLLG to make it old-style), but anyway: +TODCON2 TOD=CF2D54B4FBA8 DATE= 7/01/2015, TIME= 0:00:26.00 So, leap seconds are not accounted for. sas On Tue, Nov 17, 2015 at 9:43 AM, Paul Gilmartin <

Re: TOD conversion to display

On 2015-11-17, at 06:16, Steve Smith wrote: > I have a program that converts a STCK to a WTO. It is reentrant, but you > will need writable storage for the displayable string. Samples: > > +TODCON2 TOD= DATE= 9/17/2042, TIME= 23:53:47.370495 > +TODCON2 TOD=CFDCC9B74A2892CB

Re: TOD conversion to display

nt: Monday, November 16, 2015 9:41 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: TOD conversion to display 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 por

Re: TOD conversion to display

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

Re: TOD conversion to display

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

Re: TOD conversion to display

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

Re: TOD conversion to display

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

Re: TOD conversion to display

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

TOD conversion to display

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

Re: TOD conversion to display

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

Re: TOD conversion to display

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

Re: TOD conversion to display

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 |

Re: TOD conversion to display

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

Re: TOD conversion to display

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 >

Re: TOD conversion to display

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