Re: Routine using TIMEUSED called Statically gets different results

I had written: >CHI would be a better choice than CFI (4-byte instruction vs 6-byte >instruction) This is true. But a suitable compare-and-jump instruction (replacing both the CHI and BE) would probably be better still. Peter Relson z/OS Core Technology Design

Re: Routine using TIMEUSED called Statically gets different results

I copied and pasted.BAKR 0,14 is what I tested with. I did not read about it in POPS yet. Dealing with water heater issue and having company. Whee, So copy/paste. and quick test and the quick reply back. It'll be next week before I can do more digging into the BAKR PR impacts.

Re: Routine using TIMEUSED called Statically gets different results

AGAIN TIMEUSED ... JNZ Again Versus AGAIN TIMEUSED .. CFI R15,8 BE AGAIN If a macro does not document that it provides a condition code upon completion, it's not a great idea to rely on its doing so. While the LTR will always remain, not all forms of TIMEUSED use one, and a

Re: Routine using TIMEUSED called Statically gets different results

Chris, Sorry Sorry Sorry me culpa >> However when I ran a version of the program using BAKR and PR, the program abended with S0E0 Reason=30 Which means: "A stacking instruction was issued when the linkage stack was full." Could it be that you are using as BAKR as I wrote it an not

Re: Routine using TIMEUSED called Statically gets different results

On Wed, 15 Mar 2023 at 14:48, Chris P Fried < 04a1f5bf8721-dmarc-requ...@listserv.ua.edu> wrote: > Regarding: > > AGAIN TIMEUSED ... > JNZ Again > > Versus > AGAIN TIMEUSED .. > CFI R15,8 > BE AGAIN > > > I used CFI because it is an immediate instruction.That

Re: Routine using TIMEUSED called Statically gets different results

Discussion List On Behalf Of Chris P Fried Sent: Wednesday, March 15, 2023 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Routine using TIMEUSED called Statically gets different results EXTERNAL EMAIL Regarding: AGAIN TIMEUSED ... JNZ Again Versus AGAIN TIMEUSED .. CFI

Re: Routine using TIMEUSED called Statically gets different results

Regarding: AGAIN TIMEUSED ... JNZ Again Versus AGAIN TIMEUSED .. CFI R15,8 BE AGAIN I used CFI because it is an immediate instruction.That instruction is not going to need the literal pool. I also used that instruction because it is my understanding that TIMEUSED

Re: Routine using TIMEUSED called Statically gets different results

Thank you forresolving that puzzle I was really puzzled by your stmt (must be dynamic) and could not come up with a valid explanation of the strange results you are seeing. Chris, Chris, Chris,         Chris, Chris, Since we are talking about the subroutine- Question: you are using

Re: Routine using TIMEUSED called Statically gets different results

Resolved. There is an Alias named CPUTIME in CEE.SCEELKED. The SYSLIB for the link-edit step was configured with my library after the CEE libraries. Thus, the Link-edit was bringing in IBM's version of CPUTIME rather than my version., A side issue that made it harder to spot the issue is

Re: Routine using TIMEUSED called Statically gets different results

Yes, I agree that a STATIC call has less overhead to be loaded and even invoked. However, that does not explain why the TIMEUSED macro returns wrong Values. Basically: CALL WS-CPUTIME USING WS-START-VALUE might give a value of 1000 microseconds. <-- Dynamic COBOL Call Do some

Re: Routine using TIMEUSED called Statically gets different results

On 2023-02-12 12:02 PM, Chris P Fried wrote: I have run out of ideas on what could cause the results to be different when the routine is invoked via a Static call. "The Goog" led me to this:

Routine using TIMEUSED called Statically gets different results

Important: The TIMEUSED macro is NOT throwing an error. In the assembler routine, I changed the BNZ AGAIN to branch to an Abend: BNZ ABEND_0001 It never branched to the abend label. This routine returns different results when invoked Static versus Dynamic from IBM COBOL 6.