I have never found comparing instruction speeds to be a fair gauge of
performance. It's not the choice of instructions (unless the original
choices were very poor) that affect performance but algorithms. As has been
pointed out, I have never seen any evidence that converting an algorithm
using
Almost 10 years ago, I converted an application using 7 data spaces into one
using a single shared memory object. As Gord has pointed out, the CPU
advantage was negligible though I feel it is very difficult to benchmark the
effect. The real advantage was a reduction in error rates because of the
Because I've used memory objects for so long, I have not had a reason for
IARVSERV. I read both the description in the macro reference and in the
authorized assembler guide and there seems to be a ton of restrictions and
quirks (such as TPROT). The most notable restriction is the sharing limit of
The short answer is that any module loaded by an authorized program
must come from an authorized library.
I've been reading this post with interest since I've had to do a lot to deal
with authorized services loading programs from unauthorized libraries. I
have a utility that copies the
Modifying the CVT to perform intercepts is definitely very easy but also
extremely risky. Modifying the CVT affects the entire system. All it takes
is the mishandling of a single caller, particularly one critical to an
address space and all hell breaks loose. I tried it once. I modified the PC
Subject: Re: Serialization without Enque
On 14/11/2013 12:23 AM, Kenneth Wilkerson wrote:
If I read the article you sent correctly, this algorithm is using a
spin lock. It has provision for implementing a lock-free algorithm but
none of those are detailed.
Most of the shared_ptr implementations
$0d278340$@austin.rr.com, on 11/12/2013
at 10:34 PM, Kenneth Wilkerson redb...@austin.rr.com said:
Actually, the algorithm performs well for read-often, write-rarely list
because the active chain count does not change and therefore there are
relatively infrequent re-drives.
What happens
Sent: Tuesday, November 12, 2013 11:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 13/11/2013 12:34 PM, Kenneth Wilkerson wrote:
Actually, the algorithm performs well for read-often, write-rarely
list because the active chain count does not change and therefore
I use cell pools. I also use a proprietary storage manager that doesn't use
chains. These methodology offer me capabilities well beyond those found in
traditional methods. Much of what I do is based on these capabilities, but
the algorithms could easily be adapted to use a conventional storage
cell phones as
early as next year.
On 12/11/2013 11:18 PM, Kenneth Wilkerson wrote:
I use cell pools. I also use a proprietary storage manager that
doesn't use chains. These methodology offer me capabilities well
beyond those found in traditional methods. Much of what I do is based
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Sunday, November 10, 2013 8:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serialization without Enque
On 11/11/2013 10:36 AM, Kenneth Wilkerson wrote:
I read the article. This article is about transactional
In PLO, the hardware locking occurs according to the lock word.
The POM is not specific about the lock word other than a transformation
occurs to generate a PLT logical address used to acquire a lock. However,
this does not affect its application. The key point is that 2 or more
processors
I read the article. This article is about transactional event facility
introduced in z/EC-12 and not PLO which is an LL/CS. I wish I had access to a
z/EC-12 with the transactional event facility to play with it and compare it to
PLO. The transactional event facility is much more comprehensive
For anyone interested.
THIS IS AN EXAMPLE OF A THE COMPLETE PROCESS USED TO ADD A NEW
DISPATCHABLE UNIT (DU) ENTRY TO A QUEUE OF ACTIVE DUS. FOR SIMPLICITY,
A DU IS EQUIVALENT TO A TASK.
THIS QUEUE CAN BE SIMULTANEOUSLY SEARCHED, NEW DUS ADDED AND
TERMINATING DUS DELETED. ADDS AND DELETES
I really don't see the big deal with an 0c4 in this scenario (should
happen rarely)
You misunderstood my point. You could use PLO to serialize a chain even if
the areas are released as they are deleted provided you always use PLO
Compare and Load to load the pointers and recovery sets a retry to
-Original Message-
From: Kenneth Wilkerson [mailto:redb...@austin.rr.com]
Sent: Friday, November 08, 2013 8:46 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: Serialization without Enque
I really don't see the big deal with an 0c4 in this scenario (should
happen rarely)
You
First, I'm not sure why you have chosen PLT as your lock word. It's very
important the lock word resolve to the same REAL address no matter where the
PLO executes. Since you are talking about multiple operations against the same
chain, unless all the processes exist in the same shared program
A storage overlay cannot occur in a properly implemented PLO with a counter
as long as the counter is properly maintained with every process
incrementing it by 1. Even in in a free chain implementation, an improper
PLO sequence can result in a circular or broken chain.
Kenneth
-Original
.
You can't even say how long the element may be in use (e.g. task does not
get any CPU because of CPU load or swapped out address space in
multi-address space serialization).
Jon Perryman.
From: Kenneth Wilkerson redb...@austin.rr.com
A storage overlay cannot
If your application is not designed to use PLO for serialization, it'll
definitely not work for you. I use PLO for serialization because of issues with
locks that you are describing (system affects) and many others. All my code can
run as SRBs but unlike what you describe I almost never acquire
Thank you for mentioning the issue with CS/CDS. I have always understood
that if you use PLO anywhere to serialize access to an area, you must use
it everywhere to serialize access to that area. It's nice to know that the
transactional facility serializes it against CS as well. I wish I had
to avoid this situation.
Thanks for the great information, Jon Perryman.
From: Kenneth Wilkerson redb...@austin.rr.com
The order of stores is unpredictable except that according to the POM,
operand 2 (in this case, the count) is always stored last
I have used PLO almost exclusively for serialization in multi-address space,
multi-du code for almost 10 years. I use all 6 operations. Since everything
I write is 64 bit mode, I generally use the +2 variant (64 bit length) but I
like using the +3 variant (128 bit length) for some really cool
Since an SRB can do a SCHEDIRB it can do whatever it likes. SRBs were
designed for authorized code to overcome restrictions. If you're authorized,
the gates open.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Yes, it is possible that the updates are not performed in any order.
However, it is guaranteed that the updates are only performed if the swap
can be done. Therefore, I use a simple rule. If the number of instructions
needed to compute the new chain pointers are small (as is the case in my
if you fetch the new count and the old value1.
On Mon, 4 Nov 2013 11:38:38 -0600 Kenneth Wilkerson redb...@austin.rr.com
wrote:
:Yes, it is possible that the updates are not performed in any order.
:However, it is guaranteed that the updates are only performed if the swap
:can be done. Therefore, I
.
From: Binyamin Dissen bdis...@dissensoftware.com
That won't help if you fetch the new count and the old value1.
On Mon, 4 Nov 2013 11:38:38 -0600 Kenneth Wilkerson
redb...@austin.rr.com
wrote:
:Yes, it is possible that the updates are not performed in any order.
:However
Peryman.
From: Kenneth Wilkerson redb...@austin.rr.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, November 4, 2013 1:06 PM
Subject: Re: Serialization without Enque
This is not correct. The choice to PLO compare and load is not required
since the count
Since you're using ALESERV EXTRACTH, I'm assuming you want to schedule and
SRB into the home address space. IEAMSCHD is expecting the address of the
STOKEN. So if you were to do this,
LA R2, SRBSTOKEN
IEAMSCHD EPADDR=SRBRTN@,
PRIORITY=LOCAL,
Not a big fan of EUT FRRs
Your right. I prefer to examine my environment and chose to use an ESTAEX
instead of a FRR unless required. The FRR stack is limited to 2 uses. So when
forced to use an FRR, I extend the FRR stack by replacing the prior FRR and
restoring it upon exit. Using an
I use FRRs a lot because just about every PC routine I write can be called from
an SRB. The PC routine defines a ESTAEX when called in task mode and examines
the FRR stack and adds or replaces an FRR when called in an SRB routine or when
a lock is set. I rarely use EUT=YES FRRS. Not a big fan
Address space resource managers execute in asid 1, *MASTER*. Unless they
issue a message, you would never know they executed. If an ASCB RESMGR were
not cleaning up after itself, it would account for accumulations.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Thursday, September 05, 2013 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NSA foils much internet encryption
More Snowden documents have been reviewed by the New York
I rarely use TERM=YES. I use RTM exits almost exclusively for error
reporting and setting a retry. About the only time TERM=YES is used is in
the primary driver task for a cross memory server so that its RTM exit can
reset the PC services available flag to minimize D6 abends. But I don't even
rely
Program calls (PC) is a Z/Architecture feature that has a z/OS server, PCAUTH,
ASID 2 to administer it. The ETCON, ETDES, ETDIS, and ETDEF macros are the
primary interfaces into that server. It's the first PC numbers defined in the
system during IPL in the range of 0 to x. Chapter 5, Program
The management of the CPU timer is completely in the realm of the
dispatcher/scheduler. Therefore, using ECTG when you're not in an disabled
state during the entire timing process will not produce the results you
want. I have always used TIMEUSED to get CPU time. It's been many years
since I've
I can't imagine any instruction sequence in any language performing a Load
Reversed with Mirrored Bytes more efficiently in the Z/Architecture than a
STG, TR for eight bytes and LRVG. Even though, the TR is probably
micro-coded (I don't know about the LRVG), I can't see any loop that shifts
and
I'm basing everything I'm doing on the Principles of Operations manual
(POM). The Z/Architecture is the final authority for any program even MVS.
The linkage for PC instructions are handled by the linkage stack which fully
supports 128 bit PSW and 64 bit registers. If it didn't, nothing that I'm
I relocate all non-PC code into 31 bit storage. To the code being called, it
appears as if it's RMODE31. I do call PC routines above the bar, but it would
be trivial to relocate them as well if it became necessary. I trust the
Z/Architecture to handle the PC linkage.
-Original
The point is that SLIP LPAMOD=and the IPCS WHERE subcommand
will not be able to identify your module by name. So when someone needs to
refer to your module on a SLIP command, they will need to manually determine
the address of your module in order to use use ADDRESS= (and the address
could
A D6-22 is a linkage exception meaning the LX is not connected to the
address space issuing the PC. For a system LX, this means the LX has not
been connected by an ETCON, the LX has been disconnected by an ETDIS or
ETDES, or the address space that connected the LX has terminated. For a
non-system
since most of the stuff I write is RMODE64.
Really? Perhaps you meant AMODE 64. But I'm not sure what that has to do
with PC routines.
And it has a lot to do with PC routines sine the LPA is 24/31 bit storage.
If you want to exploit RMODE64, you can't currently do that in the LPA. PC
routines can
You know who owns it because its defined as a PC and therefore has an entry
table assigned to it. Looking in the entry tables for a program is just as
common a practice as looking for identified programs. So finding PC
routines just requires different methods. Besides, if this is a stacking PC
] On Behalf
Of Walt Farrell
Sent: Monday, July 08, 2013 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dynamic LPA Services
On Mon, 8 Jul 2013 07:55:46 -0500, Kenneth Wilkerson redb...@austin.rr.com
wrote:
And it doesn't
matter what the AC= is for a LPA program. MVS is going to treat
Control Register 0 bit 44 contains the system setting for LXRES as defined
in the POM in the chapter of control. I'm a Z/Architecture guy and I usually
go to the architecture for settings instead of z/OS. I'm also pretty sure LX
Reuse did not exist in 1.4 though I may be wrong. It was added
I don't know what you're trying to do but I would never define a PC in the
LPA for a lot of reasons. The most basic of these is that LPA routines are
callable by the EP=or EPLOC= parameter on LOAD, LINK, XCTL and ATTACH
services. When called from these services the traditional linkage is
TMI2REC+ISTAT-IREC,SDLET
Is equivalent to:
LA somereg,I2REC somereg is R1-R15
USING IREC,somereg
TM ISTAT,SDLET
DROP somereg
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent:
:25 -0500, Kenneth Wilkerson wrote:
You have to
be able to acquire key 0 to even examine the DUCT let alone modify the
DUCT to define the required trap control blocks. This means, of course,
that the application creating the trap environment must be authorized.
Doesn't that mean
TDF does not use traditional intercept technology. TDF never alters any
user code other than user specified breakpoints and it never alters any MVS
code in any way.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Chuck@arneycomputer
Howdy,
My name is Kenneth and I'm the architect of TDF. I thought I would take a
few minutes to clarify a little about TDF. This is my first time doing this.
First, TDF is designed to be much more than an interactive debug tool. It
wasn't designed to compete with any existing products.
You are certainly correct about the z/OS implementation of the TRAPx
instruction. I often wondered why the hardware designers decided to
implement it such that it inherits the user state and not a predefined state
and why they didn't provide a service to register trap interfaces so they
could be
-0500 Kenneth Wilkerson redb...@austin.rr.com
wrote:
:You are certainly correct about the z/OS implementation of the TRAPx
:instruction. I often wondered why the hardware designers decided to
:implement it such that it inherits the user state and not a predefined
state :and why they didn't provide
: Tuesday, April 09, 2013 9:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Use of the TRAPx Instructions
On 4/9/2013 7:03 PM, Kenneth Wilkerson wrote:
So now specifically to asynchronous exits. There are 3 ways to
schedule asynchronous exits that I know of, by STIMER(M), by SCHEDIRB
53 matches
Mail list logo
