In article <[EMAIL PROTECTED]>,
Shmuel Metz , Seymour J. wrote:
>> Very true, but not obvious from the marketing material at that time.
Even though the MCH only refreshed a few things, there was the implication
that the class of things which would be refreshed would expand over time to
cover us
On 28 Oct 2006 11:42:59 -0700, in bit.listserv.ibm-main you wrote:
>== Shmuel Metz (Seymour J.) == wrote2006-10-25 23:46:
>> In <[EMAIL PROTECTED]>, on 10/23/2006
>>at 06:02 PM, Thomas Berg <[EMAIL PROTECTED]> said:
>>
>>> I think it's funny that this thread that started
>>>fro
== Shmuel Metz (Seymour J.) == wrote2006-10-25 23:46:
In <[EMAIL PROTECTED]>, on 10/23/2006
at 06:02 PM, Thomas Berg <[EMAIL PROTECTED]> said:
I think it's funny that this thread that started
from details in teaching basic assembler to newbies
has evolved into an interactive l
In <[EMAIL PROTECTED]>, on 10/26/2006
at 11:31 AM, Phil Payne <[EMAIL PROTECTED]> said:
>True, but the /165's TTL memory didn't have a fraction of the
>problems the /65's core had.
The 3165 used core, as did the 3155. The solid state memory came in
later for the big machines then it did for th
In <[EMAIL PROTECTED]>, on 10/25/2006
at 10:25 AM, "Jeffrey D. Smith" <[EMAIL PROTECTED]> said:
>IBM Documentation, "Program Management" SC27-1130-00
>Chapter 7, Binder Options, Page 123.
That documents the current rules for specifying the REFR, RENT and
REUS attribute. It's not the definitive
> SYS1.ASRLIB was also relevant to the S/370.
True, but the /165's TTL memory didn't have a fraction of the problems the
/65's core had.
Didn't figure.
> Why would it, unless you were writing a nucleus csect, an ERP or an SVC? The
> MCH in OS/360
never refreshed anything else.
Very true, but n
In <[EMAIL PROTECTED]>, on 10/24/2006
at 02:19 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:
>Eons ago I was told (very probably incorrectly) that dated back to
>the ancient pre-virtual days of Rollin/Rollout.
Only by coincidence the RO/RI code rolled out entire regions; it did
not test the
In <[EMAIL PROTECTED]>, on 10/23/2006
at 06:02 PM, Thomas Berg <[EMAIL PROTECTED]> said:
>I think it's funny that this thread that started
>from details in teaching basic assembler to newbies
>has evolved into an interactive lesson in very advanced
>assembler.
Except that there is disagreement
In <[EMAIL PROTECTED]>, on 10/23/2006
at 11:19 AM, Phil Payne <[EMAIL PROTECTED]> said:
>It goes back at least as far as later versions of the 360/65 machine
>check handler. I'm not sure it was ever implemented. IBM made lots
>of noises about how good /65 MCH was going to be, but they only
>d
On Wed, 25 Oct 2006 10:25:51 -0600, Jeffrey D. Smith
<[EMAIL PROTECTED]> wrote:
...
>The syntax of the REUS option is as follows:
>REUS={NONE|SERIAL|RENT|REFR}
>The reusability values are:
>...
Ok. Maybe reading the manual doesn't help. The Humpty Dumpty effect
again. The manual says a REFR m
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, October 25, 2006 7:22 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices
In <[EMAIL PROTECTED]>, on 10/22/2006
at 08:31 PM, "Jeffrey D. Smith" <[EMAIL PROTECTED]> said:
>No, that's reentrant.
RYFM.
>Refreshable means the program does not
>modify itself *ever*.
No. It means that the program produces correct results even if
refreshed. It can modify itself as long
In <[EMAIL PROTECTED]>, on 10/22/2006
at 12:27 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>In fact, the way Binder can shuffle CSECTS (e.g. as when invoked by
>SMP/E) there's little certainty that the primary CSECT will be
>first.
Worse, with PDSE there's little certainty that the module wil
In <[EMAIL PROTECTED]>, on 10/22/2006
at 12:16 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>My understanding is that the design motivation was to be able to
>re-fetch a REFR load module in case of detected physical damage to a
>page.
Correct, and that is implicit in the definition of reshresh
On Sun, 22 Oct 2006 12:16:30 -0500, Paul Gilmartin
<[EMAIL PROTECTED]> wrote:
>...
>> Currently, there is a "refreshable" attribute that the binder
...
>My understanding is that the design motivation was to be able to
>re-fetch a REFR load module in case of detected physical damage
>to a page. E
In response to Ed's
> -Original Message-
> That will round out each CSECT to a 4K multiple. Suppose you want to
> link two or more CSECTs together and have the resultant *module*
rounded
> to a 4K boundary?
Sam replied
> Good point. Is this something that should be raised against the
Bin
son handling sql/ds technology transfer from
> endicott back to stl for db2
> http://www.garlic.com/~lynn/95.html#13
re:
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant
HLASM coding practices ever defensible?
the meeting was primarily to focus on cluster scaleu
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Paul Gilmartin
> Sent: Monday, October 23, 2006 11:13 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> defensi
On 10/23/2006 4:31 AM, Bernd Oppolzer wrote:
Now consider the following:
We have modules that try to improve performance by doing complex computations
only once.
The modules are RENT, because they are used in a dialog environment.
This is usually implemented by having a static pointer which
In a recent note, Bruce Black said:
> Date: Mon, 23 Oct 2006 12:42:18 -0400
>
> Also, the ORDER statement (which orders csects) has a P option to align
> a specific csect on a page boundary. You can also use it to specify the
> load module that follows it to fill in the rest of the page.
> My understanding is that the design motivation was to be able to
> re-fetch a REFR load module in case of detected physical damage
> to a page. Either lost in a redesign, or never fully implemented.
It goes back at least as far as later versions of the 360/65 machine check
handler. I'm not
su
"This was a known - and to my mind indefensible - issue with the z900
machines."
Been going on for years. Remember Sharp APL? Did a nasty STC into a following
branch
instruction and blew the pipeline to smithereens on the old NAS AS/9000 series.
Happened in a
tight and frequently used loop.
That will round out each CSECT to a 4K multiple. Suppose you want to
link two or more CSECTs together and have the resultant *module* rounded
to a 4K boundary?
In the binder input, the PAGE csectname command will align that csect to
be loaded on a page boundary.
Also, the ORDER statement (whi
On Sat, 21 Oct 2006 09:33:41 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
>You've hit a "sore spot" with me. In my experience, anything (not just a
>program) that starts out as a "One Off" or "Quick & Dirty"
>implementation often has a way of eventually being used for daily,
>production use. Th
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Knutson, Sam
> Sent: Monday, October 23, 2006 9:37 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> defens
I think it's funny that this thread that started
from details in teaching basic assembler to newbies
has evolved into an interactive lesson in very advanced
assembler.
I really like this list. :)
Thomas Berg
--
__
Mundus Vult Decipi
__
Th
Good point. Is this something that should be raised against the Binder
as a requirement for load modules? It doesn't seem like anyone who
wants to do this should have to use anything besides IBM HLASM and
Binder to accomplish it. Is there a way to do that today?
Best Regards,
Knutson, Sam wrote:
If you want to round out the modules to allow you to page protect them
perhaps something like this instead of the special link edit procedure.
*
LTORG ,
*
* round this module to a page boundary for page protect
DC((*+4095-DRIVER)/4096*4096-(*-DRIVER))X
Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Gilbert Saint-Flour
Sent: Monday, October 23, 2006 10:17 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding practices
ever defensible?
Edward Jaffe wrote:
> Howev
Edward Jaffe wrote:
> If REFR programs are automatically protected by a future operating
> system release, why would you care into which subpool they are loaded?
> I prefer SP 252 because it isn't fetch protected, thus allowing the
> modules' storage to be "read" in any key. But, that's a differe
Gilbert Saint-Flour wrote:
Edward Jaffe wrote:
However, this post serves to further underscore the validity of my
suggestion re: the REFR attribute. It is an old option that is not
currently being exploited by the operating system. It could be "added"
in an upward compatible way. (See Jim Mu
Edward Jaffe wrote:
> However, this post serves to further underscore the validity of my
> suggestion re: the REFR attribute. It is an old option that is not
> currently being exploited by the operating system. It could be "added"
> in an upward compatible way. (See Jim Mulder's post in this threa
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
>
> [ snip ]
>
> Will CSV and storage management ever allow load modules and
> data to occupy the same page? If so, a program might need to
> be protected with neutral zones on both ends.
CICS Stora
Bernd Oppolzer wrote:
The RENT attribute is not ignored for unauthorized programs. The program is
still treated as reentrant (no new LOAD; no wait for completion of other
processes), only the write protection is not set.
Of course, that's what I meant. The RENT option is ignored for
unauth
On Mon, 23 Oct 2006 10:34:46 +0200 Bernd Oppolzer <[EMAIL PROTECTED]>
wrote:
:>The RENT attribute is not ignored for unauthorized programs. The program is
:>still treated as reentrant (no new LOAD; no wait for completion of other
:>processes), only the write protection is not set.
:>Now consid
The RENT attribute is not ignored for unauthorized programs. The program is
still treated as reentrant (no new LOAD; no wait for completion of other
processes), only the write protection is not set.
Now consider the following:
We have modules that try to improve performance by doing complex c
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Sunday, October 22, 2006 12:06 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices
In <[EMAIL PROTECTED]>, on 10/21/2006
at 05:09 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:
>Use RENT as well as RSECT instead of CSECT and you will get TOLD at
>assembly time when you're not reentrant.
No. You will be told of some possible failures of refreshability.
There will be val
In <[EMAIL PROTECTED]>, on 10/21/2006
at 04:30 PM, john gilmore <[EMAIL PROTECTED]> said:
>More important, it is in logic a universal negative; and it can be
>proved that no instance of an universal negative can be proved.
Not only false but self contradictory.
--
Shmuel (Seymour J.) M
In <[EMAIL PROTECTED]>, on 10/21/2006
at 11:43 AM, Charles Mills <[EMAIL PROTECTED]> said:
>Just TWO things would make life so much simpler:
>1. A universal hardware and OS stack. Then all the discussions about
>reentrance go away.
No. It would slightly simplify storage management but would n
In <[EMAIL PROTECTED]>, on 10/21/2006
at 11:37 AM, John P Baker <[EMAIL PROTECTED]> said:
>Reentrant code tends to be larger than non-reentrant code and to run
>slower in that it generally has to increase the instruction path
>length due to the need to acquire and release dynamic storage for
>w
In <[EMAIL PROTECTED]>, on 10/21/2006
at 10:19 AM, "Jeffrey D. Smith" <[EMAIL PROTECTED]> said:
>Mainframers tend to use the word "reentrant" to mean
>a program that is concurrently executable by multiple
>units of work and it does not modify itself at all (or
>may modify itself in a way that i
In <[EMAIL PROTECTED]>, on 10/21/2006
at 10:15 AM, Steve Comstock <[EMAIL PROTECTED]> said:
>Interesting. I didn't know that. I joined IBM in 1968
>and I seem to recall reentrant being the common tongue
>then and reenterable used later.
Of course, what's really being discussed here is refresha
When memory moved from tubes or real "core" it became somewhat more
reliable. :)
Dave Gibney [EMAIL PROTECTED]
System Programmer(509) 335-7359
Information Technology
Washington State University
Pullman, WA 99164-1222
> My understanding is th
Ozzy Osbourne? I forget.
L8R,
Lindy
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne
& Lynn Wheeler
Sent: Sunday, October 22, 2006 6:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding pract
@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding
practices ever defensible?
Craddock, Chris wrote:
[snip]
> It is possible (BTDTGTS) to build coding and run time environments on
> z/OS where the programmer (even the system's software
developer) never
> has to co
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Saturday, October 21, 2006 9:59 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding
> practices ever defen
Paul Gilmartin wrote:
On Sun, 22 Oct 2006 10:28:19 -0600, Jeffrey D. Smith <[EMAIL PROTECTED]> wrote:
It doesn't take much work to LOAD the target program, figure out the
boundaries and issue PGSER PROTECT (or IARVSERV ACCESS=READONLY). Then
on the way out, be sure to unprotect the pages befo
Charles Mills wrote:
I'm not sure I would ask for stack support in hardware - that tends
to be more expensive than you really want.
I was thinking of hardware support for stack over/underflow
detection/diagnosis. A lot easier (in my hardware ignorance ) to have
that detection with some sor
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.
[EMAIL PROTECTED] (Paul Gilmartin) writes:
> Some non-IBM systems can mark segments as I-fetch only and D-fetch
> only. Does z/Series have this capability? It instantly traps on
> wild-b
On Sun, 22 Oct 2006 10:28:19 -0600, Jeffrey D. Smith <[EMAIL PROTECTED]> wrote:
>
> It doesn't take much work to LOAD the target program, figure out the
> boundaries and issue PGSER PROTECT (or IARVSERV ACCESS=READONLY). Then
> on the way out, be sure to unprotect the pages before issuing DELETE.
IBM Mainframe Discussion List wrote on 10/22/2006
12:19:36 PM:
> I've never understood why the CsvRentSp252 DIAG trap is necessary. What
> is the rationale for ignoring the RENT attribute for unauthorized
> programs? Authorized or not, a RENT program that modifies itself in an
> unserialized
On Sun, 22 Oct 2006 09:19:36 -0700, Edward Jaffe <[EMAIL PROTECTED]> wrote:
>
> I've never understood why the CsvRentSp252 DIAG trap is necessary. What
> is the rationale for ignoring the RENT attribute for unauthorized
> programs? Authorized or not, a RENT program that modifies itself in an
> uns
On Sun, 22 Oct 2006 09:19:36 -0700 Edward Jaffe <[EMAIL PROTECTED]>
wrote:
:>Programs loaded into SP 252 are loaded into what are usually considered
:>to be "program-only" pages.
Subpool 252 is also used when a key zero program requests subpool zero.
--
Binyamin Dissen <[EMAIL PROTECTED]>
http:
cussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Craddock, Chris
Sent: Sunday, October 22, 2006 7:04 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
defensible?
> I meant in theory. I meant had they done this "back when." I mea
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Edward Jaffe
> Sent: Sunday, October 22, 2006 8:38 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> defensible
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 22, 2006 9:20 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> defensi
Paul Gilmartin wrote:
To get complete protection of all RENT modules, you must use the
CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules
once they're loaded. I don't recommend that setting on systems older
than z/OS V1R8 because there are several popular IBM programs, resid
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Edward Jaffe) writes:
> Write-protected subpools?! No such thing!
>
> I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What
> that
---
In C, the main program acquires the stack and heap as part of early
initialization. We do something similar in our assembler programs as do
(I'm sure) most savvy programmers.
---
I tr
On Sun, 22 Oct 2006 07:37:46 -0700, Edward Jaffe <[EMAIL PROTECTED]> wrote:
>
> Write-protected subpools?! No such thing!
>
Now that I think about it, I suppose that makes sense.
> I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What
>
I overlooked that. Several months ago, whe
Paul Gilmartin wrote:
On Sat, 21 Oct 2006 15:44:00 -0600, Jeffrey D. Smith <[EMAIL PROTECTED]> wrote:
LA R3,FUBAR
ST R2,0(0,R3)
No way for the assembler to determine that the ST is storing
into field FUBAR.
The only way to know for sure is to put the program into
read-only storage. An una
Craddock, Chris wrote:
[snip]
It is possible (BTDTGTS) to build coding and run time environments on
z/OS where the programmer (even the system's software developer) never
has to confront the low level details. In such an environment,
reentrancy is natural and in all but the most trivial cases, bl
> I meant in theory. I meant had they done this "back when." I meant as
> opposed to 100 things that Chris might wish for and that other OSes do
> routinely, just these two things would be (would have been) a huge
> improvement.
Chris has done rather more than just wish for "it". In a recent forme
On Sat, 21 Oct 2006 15:44:00 -0600, Jeffrey D. Smith <[EMAIL PROTECTED]> wrote:
>
> LA R3,FUBAR
> ST R2,0(0,R3)
>
> No way for the assembler to determine that the ST is storing
> into field FUBAR.
>
> The only way to know for sure is to put the program into
> read-only storage. An unauthorized
oland
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills
Sent: Saturday, October 21, 2006 5:24 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding
practices ever defensible?
> reentrant code
Whoa !!!
In all this, maybe the most interesting facet is that we managed to drag
Steve Samson away from the bridge table.
Guess his partner must have been declarer at the time ... ;-)
Shane ...
--
For IBM-MAIN subscribe / sign
ssion List [mailto:[EMAIL PROTECTED] On Behalf
Of Wayne Driscoll
Sent: Saturday, October 21, 2006 12:50 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
defensible?
And doing this while keeping true to compatability allowances unique to
the pla
, October 21, 2006 2:44 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
defensible?
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Robert A. Rosenberg
> Sent: Saturday, Octo
AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding
> practices ever defensible?
>
> john gilmore wrote:
> > Steve Comstock<[EMAIL PROTECTED]> writes:
> >
> >> Well, when you are learning Assembler, the work to
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Robert A. Rosenberg
> Sent: Saturday, October 21, 2006 3:09 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> d
At 07:58 -0700 on 10/21/2006, Charles Mills wrote about Re: Is the
teaching of non-reentrant HLASM coding practices:
And then there is no way to test that the code really is reentrant (that I
know of -- am I missing something?) without running it APF-authorized.
Use RENT as well as RSECT inst
On Sat, 21 Oct 2006 16:30:59 +, john gilmore <[EMAIL PROTECTED]> wrote:
>
> More important, it is in logic a universal negative; and it can be proved
> that no instance of an universal negative can be proved.
>
Hmmm. So there is a proof that no proof of a universal negative can exist.
This a
IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding practices
ever defensible?
> And a corollary would be "why DID IBM make it so darned hard to write
> reentrant assembler code?"
Umm... because they really weren't thinking about the problem. Back in
john gilmore wrote:
Chris Craddock writes:
This is of course, a religious argument to many. I don't expect to
change any minds. But I offer the following challenge to assembly
language application developers. Even though LE is a demented rats-nest
of bad ideas, if you simply use it, you might b
Edward Jaffe wrote:
A symptom of a mature operating system. The now decades-old services
allowed parameters to be set along with MF=L and attempted to merge
options in their MF=E expansions. The new services merely reserve space
and declare symbols in their MF=L expansions and their MF=E expans
On Sat, 21 Oct 2006 11:43:17 -0700 Charles Mills <[EMAIL PROTECTED]> wrote:
:>Just TWO things would make life so much simpler:
:>1. A universal hardware and OS stack. Then all the discussions about
:>reentrance go away.
LE will sort of give you that (on the software side).
:>2. Get the I/O cont
the teaching of non-reentrant HLASM coding practices ever
defensible?
http://www.watsonwalker.com/PR010302.PDF
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
defensible?
> And a corollary would be "why DID IBM make it so darned hard to write
> reentrant assembler code?"
Umm... because they really weren't thinking about the problem. Back in
the day things were con
On 21 Oct 2006 05:54:37 -0700, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (john gilmore) wrote:
Steve Comstock<[EMAIL PROTECTED]> writes:
Well, when you are learning Assembler, the work to write
reentrant (I, too, prefer that term to the relatively
new-fangl
Chris Craddock writes:
This is of course, a religious argument to many. I don't expect to
change any minds. But I offer the following challenge to assembly
language application developers. Even though LE is a demented rats-nest
of bad ideas, if you simply use it, you might be pleasantly surprise
[mailto:[EMAIL PROTECTED] On Behalf
Of Edward Jaffe
Sent: Saturday, October 21, 2006 9:34 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
defensible?
You've hit a "sore spot" with me. In my experience, anything (not just a
program) tha
* A.6.3 Bypassing Post and Wait
> * A.6.4 Lock/Unlock
> * A.6.5 Free-Pool Manipulation
> * A.6.6 PERFORM LOCKED OPERATION (PLO)
>
> ... snip ...
re:
http://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant
HLASM coding practices ever defensible?
... as to having
It seems I've touched off another little fire-storm :-)
> And a corollary would be "why DID IBM make it so darned hard to write
> reentrant assembler code?"
Umm... because they really weren't thinking about the problem. Back in
the day things were considerably simpler and there was really no need
Ted MacNEIL wrote:
z900 and later processors have a separate caches for instruction fetch and data
fetch; usage DOES have a significant effect on performance
9672's and later.
I remember SAS having issues with this long before z.
There may have been some minor issues with SAS on 9672
John P Baker wrote:
You are correct in that an optimal situation exists when necessary dynamic
storage can be supplied to a reentrant program by the caller.
However, that is not ALWAYS the case.
My objection is to the use of the term "ALWAYS".
To paraphrase something read years ago, "THE ONLY
>z900 and later processors have a separate caches for instruction fetch and
>data fetch; usage DOES have a significant effect on performance
9672's and later.
I remember SAS having issues with this long before z.
Optimisation of ASM is an art that has long lost its need.
You can take the saving
Charles Mills wrote:
Sure. True quick-and-dirties. My product supports DD overrides using the
typical "second parameter" convention. I have an assembler program to
exercise that feature. It consists of a LINK macro and a few DCs. Reentrance
would be overkill.
You've hit a "sore spot" with me
BSOLUTE IS THAT THERE ARE
NO ABSOLUTES."
John P Baker
Software Engineer
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jeffrey D Smith
Sent: Saturday, October 21, 2006 12:24
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Is the teaching of non-re
John P Baker writes:
My experience is that the assertion that reentrant programs ALWAYS perform
better than non-reentrant programs can not be justified. There are simply
too many variables involved.
This is, at best, a straw man, constructed to facilitate dismemberment.
The textbook proposit
Charles Mills wrote:
And a corollary would be "why DID IBM make it so darned hard to write
reentrant assembler code?" Some IBM macros can be used in standard form
without a problem. Some simply require MF=E with MF=L in the DSECT. Some
require MF=L in the DSECT and a "model" in CSECT storage that
gt; Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> defensible?
>
> If the reentrant program must acquire and release storage (via
> GETMAIN/FREMAIN or STORAGE ACQUIRE/RELEASE) during each invocation, I can
> not see how the operation of the internal cache is goin
On
> Behalf Of Rick Fochtman
> Sent: Saturday, October 21, 2006 9:53 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
> defensible?
>
>
> A program that is re-entrant
non-reentrant HLASM coding practices ever
defensible?
John, it's a function of the internal cache usage; z900 and later
processors have a separate caches for instruction fetch and data fetch;
usage DOES have a significant effect on performance. While the factors
you cite can have an e
Steve Samson wrote:
Um, Steve, "reenterable" was the original word circa 1964.
Interesting. I didn't know that. I joined IBM in 1968
and I seem to recall reentrant being the common tongue
then and reenterable used later.
-Steve Comstock
Some IBM
dockie circa 1970 thought that that looked too
Charles Mills writes:
Reentrant code is typically more scattered in its storage references, which
increases paging
overhead (at least in theory).
Properly qualified, this once good theory can be rescued. Locality of data
reference is good, and locality of instruction reference is good. Glo
---
I have problems with this assertion.
Reentrant code tends to be larger than non-reentrant code and to run slower
in that it generally has to increase the instruction path length due to the
need to acquire and release dynamic storage for wo
---
Could you elaborate on that? I understand that there is a savings if
reentrant code can be reused without reloading (such as if it is
resident in the LPA) but why would reentrant code be inherently faster
than non-reentrant? There is certa
A program that is re-entrant according to the strict definition is one
that spontaneously re-enters itself. We call such behavior a loop.
Sometimes we call it "recursion".
: Re: Is the teaching of non-reentrant HLASM coding practices ever
defensible?
> reentrant code tends to run faster than non-reentrant code
Could you elaborate on that? I understand that there is a savings if
reentrant code can be reused without reloading (such as if it is resident in
the LPA)
1 - 100 of 114 matches
Mail list logo
