Re: System Logger - access to staging data?

I am curious why you would like to do that. It an random, undetermined, part of the logstream, so what is interesting in that particular part? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lionel B Dyck > Sent: 15 Augu

Re: Instruction speeds

On 2019-08-16 3:17 AM, Tony Harminc wrote: This is really interesting. For those put off by the "C++" note that the issue has nothing whatsoever to do with C++. It is a pure branch prediction issue. Picture a program that computes an array of pseudo-random 8-bit integers from 0 to 255. Then it so

Re: LOCASCB STOKEN=

On Thu, 15 Aug 2019 22:40:08 -0400 Tony Harminc wrote: :>I'm a bit puzzled. This service takes a pointer to an STOKEN, and returns :>an ASCB address. Or a return code indicating that the STOKEN is invalid or :>obsolete. So if I am passed an STOKEN pointer by my caller, this seems like :>the right

Re: LOCASCB STOKEN=

I'm a bit puzzled about the original question. Using addresses of things is fundamental to how computers work. And as Binyamin said, if you can't access it, it doesn't matter anyway. However, it does load up the actual ASID if that option is used (and uses a completely different linkage... given

Re: LOCASCB STOKEN=

> I'm a bit puzzled about the original question. Using addresses > of things is fundamental to how computers work. Using addresses of addresses is not. The OP's question was why the parameter was an address of a word containing another address, rather than just taking that other address direc

Re: Local time in C on z/OS

IMHO the right way is to log both the time in UTC and the local zone offset. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent:

A bit of nostalgia

Hi Folks,     Almost ever since I started using TSO, if I wanted to see who else was logged on, I would use the USERS command.  It was second nature.     At one point, maybe ten years ago, I started looking around for the source code for USERS.  And I couldn't find it. It wasn't on the CBT T

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

That's part of the issue REXX essentially supports only what is in the CMS stack, not the features of the TSO stack written specifically for CLIST. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of

Re: LOCASCB STOKEN=

Well, I don't think that's what the OP said. Furthermore, that's not how LOCASCB works. I have occasionally seen unnecessary levels of indirection, but this isn't one of them. sas On Fri, Aug 16, 2019 at 10:21 AM Seymour J Metz wrote: > > I'm a bit puzzled about the original question. Using

[SUSPECTED SPAM] Re: Local time in C on z/OS

On 2019-08-16 10:42, Seymour J Metz wrote: IMHO the right way is to log both the time in UTC and the local zone offset. +1 -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.

Re: Local time in C on z/OS

Seymour J Metz wrote: >IMHO the right way is to log both the time in UTC and the local zone offset. I don't even disagree with that, although it's a bit late for me to change this particular item (and it's just debugging info, not likely to matter; the issue was that people either look at it

TGIF

Anyone ever notice that macro DCBD produces a DSECT named IHADCB, and that macro IHADCBE produces a DSECT named DCBE? Go figure. Reminds me of parkway vs. driveway. How about the DCBE version 1 (not to be confused with the *first* version... sheesh), which expands the original by 24 bytes to add

Re: Reason for 2 digit years was Re: Instruction speeds

I'd note this fun page: https://web.archive.org/web/20170108175446/http://www.jcmit.com/memoryprice.htm -- For IBM-MAIN subscribe / signoff / ar

Re: TGIF

That's an especially good one, but the inconsistency is rampant: MACRO IHADSAB, DSECT DSAB MACRO IEFJFCBN, DSECT JFCB MACRO IHAPSA, DSECT PSA but MACRO and DSECT both IEZJSCB Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of

Re: LOCASCB STOKEN=

On Thu, 15 Aug 2019 at 23:33, Jim Mulder wrote: >> Is there a design reason the service takes a pointer rather than the STOKEN >> itself? > The LOCASCB service originated in MVS/ESA SP3.1.0, around 1987. An > STOKEN is 64 bits, and we did not have 64-bit registers until 13 years later. Ah, ma