Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

In , on 01/20/2015 at 08:29 AM, Peter Relson said: >I don't know of any reentrant code in the BCP in assembler or >(internal) PL/X for which static does not happen to equate to >constant-after-load. While some nonreshaable reentrant code ib OS/360 survived into MVS, my understanding is that

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

>If now with new releases of the >OpSys, all modules linked as RENT will be read only, I'm not sure where that thought came from. The operating system rule has been in place for way longer than I have. In general, reentrant modules from APF-authorized concatenations are placed into key 0 storage

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

On Mon, 19 Jan 2015 16:18:37 +0100, Bernd Oppolzer wrote: > >even a program that is linked as RENT may in certain circumstances >need to store some information in static storage. Think of a routine >that is >establishing a cache memory for a table access that is valid for ALL >parallel >running thr

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

On Mon, Jan 19, 2015 at 9:18 AM, Bernd Oppolzer wrote: > Am 19.01.2015 um 13:32 schrieb Peter Relson: > >> Even a non-authorized program which is linked RENT >>> can write into its STATIC CSECT. >>> >> But only if the program is not fetched from an APF-authorized >> concatenation (and maybe that'

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

Am 19.01.2015 um 13:32 schrieb Peter Relson: Even a non-authorized program which is linked RENT can write into its STATIC CSECT. But only if the program is not fetched from an APF-authorized concatenation (and maybe that's a requirement for PL/I programs with this characteristic). In that case,

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

On Mon, Jan 19, 2015 at 6:58 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 19 Jan 2015 06:40:30 -0600, John McKown wrote: > > >On Mon, Jan 19, 2015 at 6:32 AM, Peter Relson wrote: > > > >> >Even a non-authorized program which is linked RENT > >> >can write i

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

On Mon, 19 Jan 2015 06:40:30 -0600, John McKown wrote: >On Mon, Jan 19, 2015 at 6:32 AM, Peter Relson wrote: > >> >Even a non-authorized program which is linked RENT >> >can write into its STATIC CSECT. >> >> But only if the program is not fetched from an APF-authorized >> concatenation ... >> >​A

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

On Mon, Jan 19, 2015 at 6:32 AM, Peter Relson wrote: > >Even a non-authorized program which is linked RENT > >can write into its STATIC CSECT. > > But only if the program is not fetched from an APF-authorized > concatenation (and maybe that's a requirement for PL/I programs with this > characteri

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

>Even a non-authorized program which is linked RENT >can write into its STATIC CSECT. But only if the program is not fetched from an APF-authorized concatenation (and maybe that's a requirement for PL/I programs with this characteristic). In that case, the program can write into the program it

PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

Am 18.01.2015 um 17:19 schrieb Peter Relson: Storage for static variables, i.e. variables declared with the STATIC keyword, is "allocated" in the so called static CSECT that becomes part of the object module. Note that this *is* read/write storage, so in PL/I STATIC does not mean constant. If it

Re: abend S602-0 when in AMODE 64

In , on 01/18/2015 at 11:05 AM, John Gilmore said: >Mr. Metz has again betrayed his ignorance ROTF,LMAO. You really are a piece of work. I;ve been playing around with PL/I internals sice you were in diapers. >and their chief uses, >explicit and under the covers, are just as anchors for share

Re: abend S602-0 when in AMODE 64

>static NEVER means constant Maybe not to you. Maybe not to C or other LE-compliant languages now. I'd guess that if you went back far enough, "static" (at least in a reentrant module) means "not intended ever to be changed". The fact that C does not apply that meaning, or PL/I for that matter

Re: abend S602-0 when in AMODE 64

Mr. Metz has again betrayed his ignorance--or, perhaps better, naif understanding--of the PL/I language. An external controlled variable is independent of the block structure of the PL/.I procedures in which it is used; and their chief uses, explicit and under the covers, are just as anchors for

Re: abend S602-0 when in AMODE 64

In , on 01/17/2015 at 10:02 AM, John Gilmore said: >PL/I provides the storage class controlled for implementing anchors >and the like in reentrant routines. C and its sequelæ did/do not, Close but no cigar. CONTROLLED is for creating a stack variable, not for anchoring a single instance.

use of STATIC storage (was: Re: abend S602-0 when in AMODE 64)

At my recent site, we wanted all programs to be naturally reentrant for several reasons ... no matter, if PL/1, ASSEMBLER, or C. With the old compilers, we achieved this by telling the developers that the STATIC variables must not be changed during execution. We had some test systems that allowed

coding standards (was: Re: abend S602-0 when in AMODE 64)

Same rule at my recent site; with "new" PL/1, it is even possible to make all STATIC definitions NONASSIGNABLE by default, so that you have to code STATIC ASGN, if you want a STATIC variable to be ASSIGNABLE. Often the PL/1 knowledge is dramatically limited by the site standards of the site

Re: abend S602-0 when in AMODE 64

In PL/I---Things are very different in toy languages like C---the only legitimate use for static variables is as constants initialized in their declarations and never altered thereafter. In PL/I it is also possible to declare and use scalar constants. Thus declare pi static binary float(53) init

AW: Re: abend S602-0 when in AMODE 64

>> static NEVER means constant > Yip. I believe all wannabee programmers should learn this fact. How difficult > can it be to be understand? Difficult, if you start as a trainee at a company that decided to force that all STATIC variables be set to NONASSINGABLE. They very much look like co

Re: abend S602-0 when in AMODE 64

PL/I provides the storage class controlled for implementing anchors and the like in reentrant routines. C and its sequelæ did/do not, and this lacuna led to the need for such uglinesses as writable static. -- John Gilmore, Ashland, MA 01721 - USA

Re: abend S602-0 when in AMODE 64

Bernd Oppolzer wrote: >static vs. auto: different allocation technique and time, as already explained; >static: allocated once, lifetime of the variable is the whole process >auto: allocated on every call of the proc or function, removed at the end [ ... snipped ... ] Thanks for your informativ

Re: abend S602-0 when in AMODE 64

all languages: static vs. auto: different allocation technique and time, as already explained; static: allocated once, lifetime of the variable is the whole process auto: allocated on every call of the proc or function, removed at the end in C: keyword static to denote static variables, no key

AW: abend S602-0 when in AMODE 64

I'd say that it is C that confused static with constant. > Humans would think of static data as being constant (at least constant once > loaded). > "Writeable static" is, to me, an oxymoron. "Static" is just one of the terms used with computing that is being used with different meanings. When

Re: abend S602-0 when in AMODE 64

On Fri, Jan 16, 2015 at 10:22 AM, Shmuel Metz (Seymour J.) < shmuel+ibm-m...@patriot.net> wrote: > In > , > on 01/16/2015 >at 08:32 AM, Peter Relson said: > > >I'd say that it is C that confused static with constant. > > The ue of static and dynamic to refer to the allocaion tecnique rather >

Re: abend S602-0 when in AMODE 64

In , on 01/16/2015 at 08:32 AM, Peter Relson said: >I'd say that it is C that confused static with constant. The ue of static and dynamic to refer to the allocaion tecnique rather than to the variability of the contents predates C. -- Shmuel (Seymour J.) Metz, SysProg and JOAT IS

abend S602-0 when in AMODE 64

>You're confusing static with constant. A static area >is allocated to a single address for every allocation. I'd say that it is C that confused static with constant. Humans would think of static data as being constant (at least constant once loaded). "Writeable static" is, to me, an oxymoron.

Re: Abend S602-0 when in AMODE 64

In , on 01/15/2015 at 11:12 AM, Binyamin Dissen said: >On Wed, 14 Jan 2015 18:25:30 -0500 "Shmuel Metz (Seymour J.)" > wrote: >:>In <5vidba1s00e932fiphts1nu0tijahcu...@4ax.com>, on 01/14/2015 >:> at 10:05 PM, Binyamin Dissen said: >:>>What issues do you perceive sharing a STATIC data area

Re: Abend S602-0 when in AMODE 64

>I assume that there is a special method of returning to a AMODE 64 >caller since there is no mention in the R14 description. I have a >vague impression that the low bit of the return address being 1 (as >opposed to 0) indicates a return in AMODE 64. I would say that your assumption is incorrec

Re: Abend S602-0 when in AMODE 64

On Wed, 14 Jan 2015 18:25:30 -0500 "Shmuel Metz (Seymour J.)" wrote: :>In <5vidba1s00e932fiphts1nu0tijahcu...@4ax.com>, on 01/14/2015 :> at 10:05 PM, Binyamin Dissen said: :>>What issues do you perceive sharing a STATIC data area? :>One task overwritinf data used by another task. If the dat

Re: Abend S602-0 when in AMODE 64

At 22:05 +0200 on 01/14/2015, Binyamin Dissen wrote about Re: Abend S602-0 when in AMODE 64: On Wed, 14 Jan 2015 14:41:46 -0500 "Shmuel Metz (Seymour J.)" wrote: :>In <7102282945307177.wa.dlikensinfosecinc@listserv.ua.edu>, on :>01/14/2015 :> at 08:00 AM, Donal

Re: Abend S602-0 when in AMODE 64

In <5vidba1s00e932fiphts1nu0tijahcu...@4ax.com>, on 01/14/2015 at 10:05 PM, Binyamin Dissen said: >What issues do you perceive sharing a STATIC data area? One task overwritinf data used by another task. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: Abend S602-0 when in AMODE 64

At 09:11 -0600 on 01/14/2015, Tom Marchant wrote about Re: Abend S602-0 when in AMODE 64: 14 Return address. Bit 0 is 0 if the subtask routine gets control in 24-bit addressing mode; bit 0 is 1 if the subtask routine gets control in 31-bit addressing mode.  15 When the subtask routine is to

Re: Abend S602-0 when in AMODE 64

On Wed, 14 Jan 2015 14:41:46 -0500 "Shmuel Metz (Seymour J.)" wrote: :>In <7102282945307177.wa.dlikensinfosecinc@listserv.ua.edu>, on :>01/14/2015 :> at 08:00 AM, Donald Likens said: :>>AMODE 64 routines should be using relative branch and generally :>>should establish addressability to

Re: Abend S602-0 when in AMODE 64

In <7102282945307177.wa.dlikensinfosecinc@listserv.ua.edu>, on 01/14/2015 at 08:00 AM, Donald Likens said: >AMODE 64 routines should be using relative branch and generally >should establish addressability to a static data area What if the code is shared? That goes against decades of codi

Re: Abend S602-0 when in AMODE 64

On Wed, 14 Jan 2015 08:00:40 -0600, Donald Likens wrote: >>AMODE 64 routines should be using relative branch and generally should >>establish addressability to a static data area (such as where LTORG might >>be), often done by a LARL instruction. >> >>Peter Relson >>z/OS Core Technology Design

Re: Abend S602-0 when in AMODE 64

In article <2783086669968142.wa.dlikensinfosecinc@listserv.ua.edu> you wrote: > In response to: > > Can anyone explain why the following code did not work in AMODE 64 but > > works in AMODE 31? > Yes... bit 32 of R15 on entry to your STIMER exit routine is on. In > AMODE 64 the LA of the

Re: Abend S602-0 when in AMODE 64

In response to: As a reminder: AMODE 64 routines in general should not rely on the time-of-entry register 15 for addressability. LINK(X) / ATTACH(X) targets are cases for which it is "cannot" rather than "should not". The supplied code did use reg 15 for addressability: STIMERX DS0H ...

Re: Abend S602-0 when in AMODE 64

In response to: > Can anyone explain why the following code did not work in AMODE 64 but works > in AMODE 31? Yes... bit 32 of R15 on entry to your STIMER exit routine is on. In AMODE 64 the LA of the ECB address propagates it into R1. Thus R1 indicates it is a cross-memory POST. In AMODE 31

Re: Abend S602-0 when in AMODE 64

Donald Likens wrote: >The "LEFT HALVES OF ALL REGISTERS CONTAIN ZEROS" reply was in response to Dave >Day's inquiry. He asked what the left half values of the registers are. Many thanks. I now understand. I'm just trying to catch up with all the posts on IBM-MAIN including yours. Did you resol

Re: Abend S602-0 when in AMODE 64

On response to: On Tue, 13 Jan 2015 05:30:17 -0600, Donald Likens wrote: You didn't quote any of the message(s) that you replied to, so you leave us guessing. That is not a good way to ask for help. -- Tom Marchant Thanks you... I will try to include the question in the response from now on.

Re: Abend S602-0 when in AMODE 64

In response to Elardus Engelbrecht question. The "LEFT HALVES OF ALL REGISTERS CONTAIN ZEROS" reply was in response to Dave Day's inquiry. He asked what the left half values of the registers are. -- For IBM-MAIN subscribe / sig

Re: Abend S602-0 when in AMODE 64

Greg Dyck's response was, of course, fully correct. As a reminder: AMODE 64 routines in general should not rely on the time-of-entry register 15 for addressability. LINK(X) / ATTACH(X) targets are cases for which it is "cannot" rather than "should not". The supplied code did use reg 15 for addr

Re: Abend S602-0 when in AMODE 64

Donald Likens wrote: >LEFT HALVES OF ALL REGISTERS CONTAIN ZEROS Time for me to jump in. Just like Tom Marchant, I'm also asking what is above meaning or to what question(s) are you refering? Like others, I simply can't guess. Groete / Greetings Elardus Engelbrecht ---

Re: Abend S602-0 when in AMODE 64

On Tue, 13 Jan 2015 05:30:17 -0600, Donald Likens wrote: >Good thought but alas... and On Tue, 13 Jan 2015 05:43:39 -0600, Donald Likens wrote: >I do not think you are correct You didn't quote any of the message(s) that you replied to, so you leave us guessing. That is not a good way to ask f

Re: Abend S602-0 when in AMODE 64

I do not think you are correct. When the STIMER and WAIT macros are issued we are in AMODE64... Proof... I caused an S0C1 when the STIMER macro was issued. Here are the abend messages: SYSTEM COMPLETION CODE=0C1 REASON CODE=0001 TIME=05.37.37 SEQ=05744 CPU= ASID=003

Re: Abend S602-0 when in AMODE 64

Good thought but alas... I added the SYSSTATE macro and tested again... 1319 SYSSTATE AMODE64=YES 1320+*THE VALUE OF SYSSTATE IS NOW SET TO ASCENV=P AMODE64=YES A + VL=2 OSREL= 1321 *C

Re: Abend S602-0 when in AMODE 64

LEFT HALVES OF ALL REGISTERS CONTAIN ZEROS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Abend S602-0 when in AMODE 64

On 1/12/2015 7:52 AM, Donald Likens wrote: Can anyone explain why the following code did not work in AMODE 64 but works in AMODE 31? Yes... bit 32 of R15 on entry to your STIMER exit routine is on. In AMODE 64 the LA of the ECB address propagates it into R1. Thus R1 indicates it is a cross-

Re: Abend S602-0 when in AMODE 64

@LISTSERV.UA.EDU Subject: Abend S602-0 when in AMODE 64 Can anyone explain why the following code did not work in AMODE 64 but works in AMODE 31? I received an ABEND S602 R15=0 on the POST. Abend: S602 Explanation: An error occurred during processing of a POST macro instruction. The system issues this

Re: Abend S602-0 when in AMODE 64

What was in the high half of the registers when it was in 64 bit mode? On 1/12/2015 9:52 AM, Donald Likens wrote: Can anyone explain why the following code did not work in AMODE 64 but works in AMODE 31? I received an ABEND S602 R15=0 on the POST. Abend: S602 Explanation: An error occurred

Abend S602-0 when in AMODE 64

Can anyone explain why the following code did not work in AMODE 64 but works in AMODE 31? I received an ABEND S602 R15=0 on the POST. Abend: S602 Explanation: An error occurred during processing of a POST macro instruction. The system issues this abend only in association with cross memory pos