Re: LOCASCB STOKEN=

[Tony Harminc]

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, makes sense... The first thing the PC routine does is
  SPKA
  LM  R14,R15,0(R1)
  SPKA0
so I suppose a pair of 32-bit registers could have been used. But I
agree that's not a very standard interface style.

On Fri, 16 Aug 2019 at 05:51, Binyamin Dissen
 wrote:
> One wonders how the ability to pass the STOKEN in a 64bit register would help,
> as the API to your routine passes it in storage - and your code would S0C4
> fetching it.

No... I should elaborate. I have a routine that I'm updating, and
there are both legacy and new callers of it. A legacy caller passes R1
-> an area of known size containing a fixed number of 31-bit pointers;
standard OS-style arg list, but without a VL flag. There is spare,
uninitialized space after the pointers. The new caller will somehow
pass an STOKEN in addition to the existing arguments. I had thought to
put a pointer to the STOKEN after the last legacy argument, and then
pass that pointer to LOCASCB in the hopes that it would tell me if
this really is a pointer to an STOKEN or is just uninitialized junk
from a legacy caller. I won't S0C4 fetching the putative pointer, but
anyone (my code or IBM's) who loads from where it points, may. So I
can safely pass the actual STOKEN in the list, then pass its address
to LOCASCB, and (assuming the chance of a random 8 bytes being a valid
STOKEN is tiny) I'll know if this is a new or legacy caller. (I need
to use the STOKEN in any case to find the ASCB, so there's no
additional overhead.) Another approach would be to pass the STOKEN in
a non-volatile 64-bit register. So if LOCASCB accepted the STOKEN in a
register, I could just pass that in directly. As it is I have to store
it somewhere and pass the address of that doubleword.

Well many tricks are possible to manage this; having never had cause
to use LOCASCB before I was just slightly surprised that one can't
pass the STOKEN in a register.

> If you were supervisor state and did not want to return an abend in such a 
> case, an FRR would work wonders.
>
> As you have a problem state requirement, you could use VSMLOC against the 
> address to avoid an 0C4.

Yup - and it's not an integrity issue (TOCTTOU between VSMLOC and
LOCASCB, because LOCASCB *is* checking correctly. I just wish *it*
would do the VSMLOC if it won't take the STOKEN directly. Yeah, that's
not free either...

On Fri, 16 Aug 2019 at 10:21, Seymour J Metz  wrote:
> On Fri, 16 Aug 2019 at 09:16, Steve Smith  wrote:
> >  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 directly as a parameter.

Uh, no. You've imagined a level of indirection that I didn't suggest.

Thanks for all the suggestions.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TGIF

[Charles Mills]

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 Steve Smith
Sent: Friday, August 16, 2019 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 one new
bit?  I guess DCBEFLG4 was miffed at being skipped and negotiated a big
payoff.

-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Phil Smith III]

I'd note this fun page:

https://web.archive.org/web/20170108175446/http://www.jcmit.com/memoryprice.htm 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

TGIF

[Steve Smith]

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 one new
bit?  I guess DCBEFLG4 was miffed at being skipped and negotiated a big
payoff.

-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Local time in C on z/OS

[Phil Smith III]

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 instantly, in which case the timestamps don't 
matter, or they look at it much later, in which case they're trying to map it 
to something in the system log, and then the offset is confusing).

 

I'd note (not Shmuel's fault!) that this suggestion still would have left me 
with the original problem: getting the MVS time! (Which, I agree, is a better 
term than "local time".) Again, thanks to those who led me to salvation.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Gord Tomlin]

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.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOCASCB STOKEN=

[Steve Smith]

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 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 directly as a parameter.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Seymour J Metz]

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 
Jesse 1 Robinson 
Sent: Thursday, August 15, 2019 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

One CLIST feature I miss in REXX is the ability to run in subcommand mode. With 
CLIST, you can execute for example TSO TEST and supply in-line subcommands that 
execute in sequence from within the CLIST. With REXX, you have to QUEUE the 
subcommands before issuing TEST, after which REXX is no longer in control.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 15, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

DATA and DATA PROMPT come to mind, as does the parsing of keyword parameters. 
I've tried to avoid CLIST since TSO/E V2, but there really re things that it 
does better than REXX.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Dana Mitchell 
Sent: Thursday, August 15, 2019 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

What would be one of those cases?  I can't really think of anyting, maybe its 
been so long since I've written a clist that I'm don't remember what I'm 
missing.  If you want a trip into the early 80's, try writing an IBMi  CL 
program ;)

Dana

On Thu, 15 Aug 2019 16:41:15 +, Seymour J Metz  wrote:
>
>Seriously, there are actually cases where CLIST still makes sense. I just wish 
>that they'd enhance REXX to have the same capability.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

A bit of nostalgia

[Sam Golob]

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 
Tape, or in any of my archives.  So I disassembled the load module, and 
kept the disassembled source around, just in case..


    There was another good program which served the same purpose:  
DUSER on CBT File 300.  So I started using that program instead.


    Recently, (like last night), I got around to looking at the 
disassembled source and tried to get it to work properly.  I was always 
wondering why the main CSECT in USERS was not called USERS, but it was 
called ACTIVE.  Not only did I get it to work and assemble, but I 
discovered that if you gave the load module an alias of ACTIVE, you'd 
get a "Display Active" display, whereas if you ran the program as USERS, 
you'd see the TSO users who were logged on.  So my mind was relieved, 
and even though the source code doesn't have labels, I fixed the ACTIVE 
command to be AMODE 31 and to display the right stuff.  You can now find 
the result as members USERS and USERSACT on CBT File 300.


    There are better programs.  The DA command on File 300 (I think) 
shows a better "Display Active" type display (and it can show the TSO 
users with a parm of T).  The DUSER command (also on File 300) shows a 
fine TSO users display.  But my old "buddy" the USERS command now has a 
semblance of correct source code to support it.  Gives me a "sense of 
security" inside, and I'm going to start using it again.


    So for those of you who have the same nostalgia, the USERS command 
is now available in "assemblable source" on CBT File 300 on the Updates 
page.  Have fun...!!!


    All the best of everything to all of you.

Sincerely,    Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Local time in C on z/OS

[Seymour J Metz]

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: Thursday, August 15, 2019 7:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS

On Thu, 15 Aug 2019 23:11:48 +, Jon Perryman wrote:
>
>C offer's localtime and UTC but not z/OS time. The OP wants the z/OS time.
>
As the OP observed, localtime is not well defined; worst on z/OS.

>"where are you" is too simplistic. Time is relative to the problem being 
>solved. C and z/OS take the simplistic approach that there is a single time 
>zone involved. C assumes this time zone is customizable where as z/OS has a 
>single timezone for the system. The C assumption works well for Unix where 
>user's run their programs in a process. This paradigm starts having problems 
>in products such as SAP, Peoplesoft and others. I suspect IBM decided on a 
>single timezone because z/OS encounters these types of issues.
>
"single"?  Doesn't z/OS provide two?

There's a right way to address this problem.  Such products should log UTC,
which is always available.  Conversion for display at the users' discretion.
Enforcing standards for such as printed reports is a management issue, not
a systems issue.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOCASCB STOKEN=

[Seymour J Metz]

>  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 directly as a parameter.


--
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Friday, August 16, 2019 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 Jim's history lesson, not surprising).

It may be that this isn't really your program's problem.  A S0C4 is
appropriate for LOCASCB, and it may be for your program.  But if not, ESPIE
or ESTAE might work, although I'm not sure if they need memory for parms.
You'd have to trigger the S0C4 before LOCASCB does though.

sas

On Fri, Aug 16, 2019 at 5:51 AM Binyamin Dissen 
wrote:

> 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. ...  Is there a design reason the service takes a
> pointer rather than the
> :>STOKEN itself?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOCASCB STOKEN=

[Steve Smith]

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 Jim's history lesson, not surprising).

It may be that this isn't really your program's problem.  A S0C4 is
appropriate for LOCASCB, and it may be for your program.  But if not, ESPIE
or ESTAE might work, although I'm not sure if they need memory for parms.
You'd have to trigger the S0C4 before LOCASCB does though.

sas

On Fri, Aug 16, 2019 at 5:51 AM Binyamin Dissen 
wrote:

> 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. ...  Is there a design reason the service takes a
> pointer rather than the
> :>STOKEN itself?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOCASCB STOKEN=

[Binyamin Dissen]

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 service to tell me if this is pointing to a valid and current
:>STOKEN, which it does. But if I pass in a bogus *pointer*, e.g. to some
:>random address that is fetch protected from me (I'm running user key,
:>problem state) then the PC routine code abends, because it's done the right
:>thing and assumed my key before trying to reference the supposed STOKEN.

:>So... Although the description says "Abend codes: none", in fact it can
:>S0C4. (Yeah, I know this means that LOCASCB itself generates no abend
:>codes.)  So it seems I have to check the validity of the pointer before I
:>pass it in. I agree such a requirement makes sense in most cases, but here
:>I am in a constrained environment with no work area, so I have no obvious
:>way of passing in the STOKEN itself for checking without having a pointer
:>to it. Is there a design reason the service takes a pointer rather than the
:>STOKEN itself?

One wonders how the ability to pass the STOKEN in a 64bit register would help,
as the API to your routine passes it in storage - and your code would S0C4
fetching it.

If you were supervisor state and did not want to return an abend in such a
case, an FRR would work wonders.

As you have a problem state requirement, you could use VSMLOC against the
address to avoid an 0C4.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Instruction speeds

[David Crayford]

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 solves the problem "what is the sum of all
of the numbers in the table greater than or equal to 128?" It does that
with the obvious loop, which then contains

IC   R0,next_table_byte
CHI  R0,128
JL   *+6
AR   R2,R0

The assertion of the thread -- and I don't doubt it -- is that the above
code uses 1/6 the CPU time if you first sort the table. (Obviously, a
stupid way of doing things: you could sort the table high to low and then
exit once you got a value below 128; but that's not the point.)

It illustrates the value of, or problem with, depending on your point of
view, branch prediction. If the table is random then the outcome of the
CHI/JL is unpredictable, and the branch prediction is at best useless and
at worst counter-productive. But if the table is sorted, then the branch
prediction has a chance to be right most of the time.


Of course the sort doesn't generally come free. As well as the basic CPU
cost (typically n log n for any modern sort), it will have some amount of
startup CPU and additional memory references. Yes, of course I understand
that this is an example to demonstrate branch prediction. But in the Real
World, branch prediction is just one of many aspects of modern CPUs that
are hard to predict.


I think that was the pertinent point of the thread that even with the 
overhead over the sort it was faster

than processing an unsorted array.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: System Logger - access to staging data?

[Vernooij, Kees (ITOP NM) - KLM]

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 August, 2019 16:14
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: System Logger - access to staging data?
> 
> Is there a utility that will copy/print the staging data for a logstream?
> 
> 
> 
> thanks
> 
> 
> 
> 
> 
> Lionel B. Dyck <
> Website:   http://www.lbdsoftware.com
> 
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN