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

[Shmuel Metz (Seymour J.)]

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 IBM has long since cleaned it up.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

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

[Peter Relson]

>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 (SP252) and other modules are placed into SP251.

Therefore one concludes that a reentrant module that does need to "store 
into itself" either needs not to be fetched from an APF-authorized 
concatenation or needs to be able to get into key 0. 

If the sentiment related to thinking about REFRPROT, note that the 
REFRPROT option applies only to things that are marked refreshable which 
is stronger than reentrant.

I'm sorry I got the group off track by my use of the term 'static' to 
refer to intended-not-to-be-written-into storage. I defer to those on the 
group with more knowledge of the historical use of the term (particularly 
by high level languages). Whether their use was a good use of the term or 
not is largely water under the bridge. It is what it is.
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. 
Maybe we just like the protection of having the assembler flag stores into 
the CSECT for reentrant parts, and don't care to bother tweaking that 
option for a case where such a store could be OK. 

Peter Relson
z/OS Core Technology Design

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

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

[Paul Gilmartin]

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 threads or subtasks. Then there should be ONE cache, and of course,
>the anchor information for this cache has to be in static storage, and when
>establishing the cache or accessing (or changing) the cache (which resides
>in dynamic storage, of course), the anchor has to be written into the
>static storage.
> 
A coworker of mine accomplished something similar by causing his
RENT CSECT to dynamically load a small serially REUSable CSECT
into which it stored the anchor.  This antedated the availability of
name-token.

-- gil

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

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

[John McKown]

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's a requirement for PL/I programs with this
>> characteristic).
>>
>> In that case, the program can write into the program itself too.
>>
>> For the static csect, does PL/I do something to keep track of CSECT
>> mappings and obtain storage for the static csect in user-key storage?
>> That's the only way that writing into that csect could "overcome" APF
>> authorization rules.
>>
>> Peter Relson
>> z/OS Core Technology Design
>>
> I'm talking about simple user programs that are fetched from normal
> not APF-authorized libraries. The STATIC CSECT (with compile option NORENT)
> is part of the load module, so with normal MVS LOAD, it is fetched
> together with
> the program text, in user-key storage.
>
> I don't really get the problem with this RENT / read only discussion.
>
> Of course, normally a program linked as RENT should not change its static
> stroage, but:
>
> 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 threads or subtasks. Then there should be ONE cache, and of course,
> the anchor information for this cache has to be in static storage, and when
> establishing the cache or accessing (or changing) the cache (which resides
> in dynamic storage, of course), the anchor has to be written into the
> static storage.
>

​I have seen this sort of thing done. A type 2 SVC (r/w nucleus) did
something like (from personal memory):


   L R5,INTERNAL_GLOBAL_POINTER
   LTR R5,R5
   BNZ AROUND ALREADY INITIALIZED!
   GETMAIN R,LV=SOME_LENGTH,SP=???
   CS R5,R1,INTERNAL_GLOBAL_POINTER
   BE AROUND POINTER UPDATED
* SOMEBODY GOT IN FRONT OF ME, RELEASE WORK AREA
   FREEMAIN R,LV=SOME_LENGTH,A=(1)
AROUND DS 0H



>
> These cache accesses have to be protected by semaphors etc, of course
> (or maschine instructions like compare & swap).
>
> This was present before WSA was invented. If now with new releases of the
> OpSys, all modules linked as RENT will be read only, we all are forced to
> use WSA even with "classical" languages like PL/1, COBOL and C (without
> ++);
> I don't like this ... for performance reasons. And this even will not
> help, because
> WSA exists once for every parallel task ... if I want ONE cache for all
> parallel tasks,
> as in my example, I have to find another solution. With "true static", I
> knew where
> to put the anchor of that cache.
>

​I now use a global NAME/TOKEN to store the address of my global (system
wide) work areas.​ For an address space, there is an address space level
NAME/TOKEN, and a 3rd level for TCB level NAME/TOKEN
ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9B0/15.0
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A6A1/18.0

​Before use of NAME/TOKEN, I recall a "perversion" of ENQ control blocks
where it had a NODE similar to: PRODUCT...
The application code would scan the ENQ control blocks looking for a match
to the prefix: PRODUCT. (or just PRODUCT for a system level),
and then take the  portion as the printable encoding of the
memory pointer.



>
> Kind regards
>
> Bernd
>
>
-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

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

[Bernd Oppolzer]

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, the program can write into the program itself too.

For the static csect, does PL/I do something to keep track of CSECT
mappings and obtain storage for the static csect in user-key storage?
That's the only way that writing into that csect could "overcome" APF
authorization rules.

Peter Relson
z/OS Core Technology Design

I'm talking about simple user programs that are fetched from normal
not APF-authorized libraries. The STATIC CSECT (with compile option NORENT)
is part of the load module, so with normal MVS LOAD, it is fetched 
together with

the program text, in user-key storage.

I don't really get the problem with this RENT / read only discussion.

Of course, normally a program linked as RENT should not change its 
static stroage, but:


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 threads or subtasks. Then there should be ONE cache, and of course,
the anchor information for this cache has to be in static storage, and when
establishing the cache or accessing (or changing) the cache (which resides
in dynamic storage, of course), the anchor has to be written into the 
static storage.


These cache accesses have to be protected by semaphors etc, of course
(or maschine instructions like compare & swap).

This was present before WSA was invented. If now with new releases of the
OpSys, all modules linked as RENT will be read only, we all are forced to
use WSA even with "classical" languages like PL/1, COBOL and C (without 
++);
I don't like this ... for performance reasons. And this even will not 
help, because
WSA exists once for every parallel task ... if I want ONE cache for all 
parallel tasks,
as in my example, I have to find another solution. With "true static", I 
knew where

to put the anchor of that cache.

Kind regards

Bernd

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

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

[John McKown]

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 into its STATIC CSECT.
> >>
> >> But only if the program is not fetched from an APF-authorized
> >> concatenation ...
> >>
> >​As an aside, I really wish that _all_ programs marked RENT,REFR would be
> >loaded into key 0, write protected, storage independent of APF
> >considerations. I'm sure that there is _some_ reason why it is done as it
> >is currently done, perhaps for "hysterical"  reasons. If I am
> really
> >worried about such, I try to use the PGSER PROTECT function to do this.
> But
> >that is really only easy in HLASM.
> >
> But doing it uniformly would make sense, so it wouldn't be hysterical.
>

​Sorry. My whimsy: Substitute "hysterical" for "historical" when I disagree
with the historical (hysterical) implementation. ​



>
> Isn't there a REFRPROT option to enforce what we wish?
>

​Yes. Now how in the blue blazes did I miss that? And we are actually on
z/OS 1.12, where _apparently_ that where it came in.​


>
> -- gil
>
>
-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

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

[Paul Gilmartin]

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 ...
>>
>​As an aside, I really wish that _all_ programs marked RENT,REFR would be
>loaded into key 0, write protected, storage independent of APF
>considerations. I'm sure that there is _some_ reason why it is done as it
>is currently done, perhaps for "hysterical"  reasons. If I am really
>worried about such, I try to use the PGSER PROTECT function to do this. But
>that is really only easy in HLASM.
> 
But doing it uniformly would make sense, so it wouldn't be hysterical.

Isn't there a REFRPROT option to enforce what we wish?

-- gil

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

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

[John McKown]

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
> characteristic).
>
> In that case, the program can write into the program itself too.
>
> For the static csect, does PL/I do something to keep track of CSECT
> mappings and obtain storage for the static csect in user-key storage?
> That's the only way that writing into that csect could "overcome" APF
> authorization rules.
>
> Peter Relson
> z/OS Core Technology Design
>
>
​As an aside, I really wish that _all_ programs marked RENT,REFR would be
loaded into key 0, write protected, storage independent of APF
considerations. I'm sure that there is _some_ reason why it is done as it
is currently done, perhaps for "hysterical"  reasons. If I am really
worried about such, I try to use the PGSER PROTECT function to do this. But
that is really only easy in HLASM.

-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

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

[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, the program can write into the program itself too.

For the static csect, does PL/I do something to keep track of CSECT 
mappings and obtain storage for the static csect in user-key storage? 
That's the only way that writing into that csect could "overcome" APF 
authorization rules. 

Peter Relson
z/OS Core Technology Design

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

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

[Bernd Oppolzer]

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's truly part of a "CSECT" that is part of a load module, then this
statement is wrong (or needs to be fine-tuned). All z/OS storage is
read/write if you're in the right key (unless z/OS has page-protected it).
So if you're trying to say that a non-key-0 program can write into it, in
z/OS that will depend on the APF authorization of the load library
concatenation and the reentrancy of the module.


Even a non-authorized program which is linked RENT can write into its 
STATIC CSECT.
We did this all the time in our PL/1 modules that are compiled using the 
NORENT option
(or compiled with old releases of PL/1, before the RENT option was 
available).


There are two use cases (at our site) to do that:

a) to store the entry point of modules that are dynamically loaded, so 
that only at the
first call a LOAD macro is needed ... at the subsequent calls the entry 
point is non-zero,

so it can be used immediately

b) to store results of expensive computations (and the arguments, that 
leaded to this

results), in case that the following call is done with the same arguments

In the second case, you have to take care that there will be no damage 
due to the
parallel use of the module from different tasks ... there are ways to do 
this. In the
first case, you dont have such a problem ... the only damage that can 
occur is

that you do the LOAD too often.

BTW: our PL/1 modules (no DLLs, simple LOAD modules) call each other using
ASSEMBLER interfaces, doing MVS LOAD ... we don't normally use LE services
for that (this is an old technique from the early 1980s). But it works 
until today,

and the rest is all LE compliant. We use the new EP PL/1 compilers.

Same goes for C ... no difference at all.

Kind regards

Bernd

--
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

[Shmuel Metz (Seymour J.)]

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 shared
>constructs like files 

What are you smoking?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

[Peter Relson]

>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 might not, might not be all 
that relevant.

>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's truly part of a "CSECT" that is part of a load module, then this 
statement is wrong (or needs to be fine-tuned). All z/OS storage is 
read/write if you're in the right key (unless z/OS has page-protected it). 
So if you're trying to say that a non-key-0 program can write into it, in 
z/OS that will depend on the APF authorization of the load library 
concatenation and the reentrancy of the module.

Peter Relson
z/OS Core Technology Design

--
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

[John Gilmore]

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 shared
constructs like files and control blocks: a separate PRV instance is
allocated and initialized for each PL/I dispatchable.

It is true that for, say,

declare cp pointer controlled ;
 . . .
allocate cp  ;
 . . .
allocate cp ;

second and subsequent instances  of the same variable are pushed down
as another instance of it is allocated and popped up/reinstated when
an instance of that variable is freed, but this is incidental
behavior, and no sane person would try to manage a PL/I stack by
exploiting it: much simpler, lower-overhead schemes for doing so are
readily implemented.

John Gilmore, Ashland, MA 01721 - USA

--
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

[Shmuel Metz (Seymour J.)]

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.

 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

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

[Bernd Oppolzer]

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 for runtime checks (storage protecting the
module area, and then monitoring the 0C4 abends resulting from
stores into the module area).

With the new PL/1 compiler, we can enforce this by assigning implicitly
NONASSIGNABLE to all STATIC definitions; this is a sort of additional
control.

If sometimes for special reasons, there is a need to store some information
into the static area, the variables have to be defined explicitly with 
the ASGN

attribute.

One such reason could be:

The module stores the parameters of the last call and the results in the
STATIC area, and if the parameters on the next call are the same,
it simply outputs the result, without computing again. Of course, you
have to take care that this works correctly in a multi-threaded 
environment.


Kind regards

Bernd



Am 17.01.2015 um 18:36 schrieb John Gilmore:

Note also that the chief value of the PL/I attributes ASSIGNABLE and
NONASSIGNABLE is in the characterization of procedure parameters.

John Gilmore, Ashland, MA 01721 - USA



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

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

[Bernd Oppolzer]

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
that you are working at ... sometimes for decades. I recall a site, 
where all variables
were static due to DEFAULT RANGE ... the reason behind that was, that 
AUTO variables
are harder to find in the SYSUDUMP (static variables are in the STATIC 
CSECT,

so no problem).

Or another site, where there were no internal PROCEDUREs allowed, only 
calls to
external modules, so the developers there knew nothing about local 
variables, the block

concept and even parameter passing mechanisms besides the very basic
passing of addresses of structures ... that's all they did, always to 
external modules.
Inside the modules, all variables were global, only one procedure, 
normally.
There were program blocks similar to procedures based on label 
variables, but without

local variables.

When these colleagues were moved to another system at the same company,
which used kind of "standard" PL/1, they had to learn much of the PL/1 
basics
from the start ... after working 20 years with "reduced" PL/1, in some 
cases.


Kind regards

Bernd



Am 17.01.2015 um 16:36 schrieb Peter Hunkeler:
Difficult, if you start as a trainee at a company that decided to 
force that all STATIC variables be set to NONASSIGNABLE.

They very much look like constants then. (Been there, seen that.)

I admit it is not the STATIC but the NONASSIGNABLE keyword that makes 
the constants,
but a trainee migth not yet appreciate that fine distinction. 


--
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

[John Gilmore]

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) initial(3.141592653589793238e+000) ;

and

declare pi binary float(53) value(3.141592653589793238e+000) ;

are functionally equivalent in most cases.

I do not myself make much use of named constants in PL/I, both because
their syntax is ugly and irregular and because aggregate named
constants are not supported; but they are available to those who wish
to use them.

Note also that the chief value of the PL/I attributes ASSIGNABLE and
NONASSIGNABLE is in the characterization of procedure parameters.

John Gilmore, Ashland, MA 01721 - USA

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

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

[Peter Hunkeler]

>> 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 
constants then. (Been there, seen that.)


I admit it is not the STATC but the NONASSIGNABLE keyword that makes the 
constants, but a trainee migth not yet appreciate that fine distinction.


--
Peter Hunkeler



--
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

[John Gilmore]

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

--
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

[Elardus Engelbrecht]

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 informative explanation. Much appreciated.


>in COBOL: WORKING STORAGE, LOCAL STORAGE (I'm no COBOL wizard)

I'm not really sure what to say here, even after RTFM. I will reread my COBOL 
books before I comment on this, so I will STFU for now. 


>Now there are some peculiarities:

I think ALL and EVERY languages have their peculiarities... :-D
You're not allowed to argue with me.  ;-D


>Option RENT with PL/1 and C, don't know for COBOL.

COBOL does has a RENT / NORENT option, but there are gazillion issues with it 
beside that option may/may not conflict with other COBOL compiler options.


>static NEVER means constant 

Yip. I believe all wannabee programmers should learn this fact. How difficult 
can it be to be understand?

Oh, of course, when writing a program, YMMV and you as programmer needs to 
consider all facts, usage and needs of future users of your program(s).

DISCLAIMER: I wrote/gave support/gave ad-hoc informal training in COBOL, 
Assembler, FORTRAN (in ancient times), REXX, Clist, PASCAL programs on 
different platforms. I have experimented/played with C, C++, and PL/I and some 
fancy languages like ADA, Natural, DB2 SQL, etc. for example.

Groete / Greetings
Elardus Engelbrecht

--
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

[Bernd Oppolzer]

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 keyword for auto, but:
see below

in PL/1: keywords STATIC and AUTO, defaults set by DEFAULT RANGE
(normally AUTO)

in COBOL: WORKING STORAGE, LOCAL STORAGE (I'm no COBOL wizard)

Now there are some peculiarities:

most "old" compilers put the static variables in STATIC CSECT in the 
load module,
which is OK, but makes the module not reentrant (because it is changed 
at runtime,
if the static variables are not constant ... you see the difference 
between static

and constant)

now some new compilers (inspired by C++, where this is common or even 
necessary)
allow to put the static variables in a special dynamic area called WSA 
(writable static area)
allocated at process start (for every process once), so the modules stay 
reentrant,

although they change their static variables. Option RENT with PL/1 and C,
don't know for COBOL.

Furthermore, there is one thing, which makes headaches with C:

the keyword "static" is also used to denote functions and variables in 
the source code, that are
not external, that is, are not known to the linkage editor. This is gaga 
in my opinion;

this keyword should have been "local", but the designers of C chose to reuse
"static" here, because they wanted to save keywords, and external functions
and variables are static (in the sense above), anyway.

and the last thing:

static NEVER means constant ... there are other keywords in all the 
languages

to denote constant values (more or less effective).

Kind regards

Bernd



Am 17.01.2015 um 09:42 schrieb Peter Hunkeler:

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 I started to work on IBM mainframes in 83, the first language I go taught was PL/I. PL/I distinguishes 
between "static" and "dynamic" storage for variables.


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.


Storage for dynamic variables will be allocated at run time.


PL/I did not have constants until the advent of Enterprise PL/I. You define a 
constant by defining its value via VALUE() keyword instead of the usual 
INITIAL() keyword.


Also new with Enterprise PL/I is the ASSIGNABLE/NONASSIGNABLE attribute for 
variables. So, STATIC as well as dynamic variables can be writable or not (i.e. 
constant after being initialized).

--
Peter Hunkeler

--
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: abend S602-0 when in AMODE 64

[John McKown]

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
> than to the variability of the contents predates C.
>

​This is conceptually similar to the difference, in a COBOL​ subroutine,
between WORKING STORAGE and LOCAL-STORAGE. With COBOL, WORKING STORAGE is
initialized at start up and keeps its values between invocations. This is
like the C "static" storage. OTOH, LOCAL-STORAGE is gotten and initialized
anew on each invocation. As is a non-static variable defined in a C
routine. Of course, there is a major difference in that a C "static"
variable is actually allocated in the storage of the executable code (i.e.
in the text segment). Whereas, IIRC, WORKING-STORAGE is dynamically
allocated in the LE heap somehow.



>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

--
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

[Shmuel Metz (Seymour J.)]

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
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

[Shmuel Metz (Seymour J.)]

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?

>:>One task overwritinf data used by another task.

>If the data is written to, how can it be static?

You're confusin static with constant. A static area is allocated to a
single address for every allocation.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

[Peter Relson]

>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 incorrect.

For things like ATTACH and LINK, BR 14 (or BSM 0,14) work fine.

If you have defined that your interface is to be called by BASSM 
(regardless of your AMODE) then you are expected to return by BSM.

If you are called by BASSM from AMODE 64 then it would be true that the 
low bit of R14 would be on.
If you are called by BASR and switch AMODEs, you can issue BSM 14,0 at the 
beginning in order to accommodate BSM 0,14 at the end.

>1) If in AMODE64 when the STIMERX macro was issued, 
>why was bit 32 on in R15? Seems wrong to me.
I'd say it's because you're expected not to need it or care, so no change 
was made to the existing logic which set the high bit on when PSW bit 32 
(on both for AMODE 31 and AMODE 64) is on. Could it have been done 
differently? Sure. Will it be changed? Not likely.

>2) Why didn't the "LA1,STIMECB" abend on an S0C4-38 
>when bit 32 on the base reg was on? 
Because you cannot get a PIC 38 on a LA instruction. As someone mentioned, 
it is just doing architecturally-defined arithmetic.

>>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 coding to be
>reentrant and refreshable.

There is no conflict with what I wrote versus being reentrant and 
refreshable. If reentrant / refreshable you would also have addressability 
to a dynamic data area.
But you would still use relative branch and would still have 
addressability to whatever static data you need. 

Peter Relson
z/OS Core Technology Design

--
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

[Binyamin Dissen]

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 data is written to, how can it be static?

--
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: Abend S602-0 when in AMODE 64

[Robert A. Rosenberg]

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, 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 coding to be
:>reentrant and refreshable.

What issues do you perceive sharing a STATIC data area?


The issue is with a Writable not a Read-Only area. The Static area 
would need to be acquired separately with each invocation and thus 
would need to be accessed via a register not by relative addressing. 
Otherwise different address spaces would overlay each other's data.




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

Director, Dissen Software, Bar & Grill - Israel



--
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

[Shmuel Metz (Seymour J.)]

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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

[Robert A. Rosenberg]

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 run in 24-bit or 31-bit addressing 
mode, the entry point address of the subtask routine.  When the 
subtask routine is to run in 64-bit addressing mode, it is expected 
to use relative branching and register 15 contains a value that can 
be used to determine the addressing mode of the issuer of the ATTACH 
or ATTACHX macro as follows:


Issuer AMODE 24: X'F000'
Issuer AMODE 31: X'F002'
Issuer AMODE 64: X'F004'


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.


--
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

[Binyamin Dissen]

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 a static data area

:>What if the code is shared? That goes against decades of coding to be
:>reentrant and refreshable.

What issues do you perceive sharing a STATIC data area?

--
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: Abend S602-0 when in AMODE 64

[Shmuel Metz (Seymour J.)]

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 coding to be
reentrant and refreshable.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

[Tom Marchant]

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
>
>
>Is there a document that documents the above? I want to see if there is 
>anything else I didn't know about AMODE 64 coding.

See, for example, the ATTACH macro in the Assembler Services Reference.


5.1.8 Parameters

The parameters are explained as follows:
 
...
  
  Register  Contents 
0 Used as a work register by the system. 

1 Address of the user parameter list if specified on either the PARAM 
or MF=E parameters; otherwise, contains whatever GPR 1 contained 
at the time the ATTACH macro was issued.  

2-12 Used as work registers by the system.  

13 Address of a standard save area.  

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 run in 24-bit or 31-bit addressing mode, the 
entry point address of the subtask routine.  When the subtask routine is to run 
in 64-bit addressing mode, it is expected to use relative branching and 
register 15 contains a value that can be used to determine the addressing mode 
of the issuer of the ATTACH or ATTACHX macro as follows:  

Issuer AMODE 24: X'F000'  
Issuer AMODE 31: X'F002'  
Issuer AMODE 64: X'F004'


-- 
Tom Marchant

--
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

[Don Poitras]

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 ECB address propagates it into R1. Thus R1 
> indicates it is a cross-memory POST.  In AMODE 31 the LA of the ECB 
> ignores it so the POST works as expected.
> Greg

> I turned off bit 32 in R15 and that fixed the problem... Thank you.

> I am confused about a couple of things however...

> 1) If in AMODE64 when the STIMERX macro was issued, why was bit 32 on in R15? 
> Seems wrong to me.
> 2) Why didn't the "LA1,STIMECB" abend on an S0C4-38 when bit 32 on the 
> base reg was on? 

> Thank you all for your help

1) Dunno. Seem wrong to me too. LLGTR 15,15 at entry would fix it. 
2) LA doesn't access storage, it just does arithmetic.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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

[Donald Likens]

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 
... 
 USING *,R15

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


Is there a document that documents the above? I want to see if there is 
anything else I didn't know about AMODE 64 coding.

--
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

[Donald Likens]

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 the LA of the ECB 
ignores it so the POST works as expected.
Greg

I turned off bit 32 in R15 and that fixed the problem... Thank you.

I am confused about a couple of things however...

1) If in AMODE64 when the STIMERX macro was issued, why was bit 32 on in R15? 
Seems wrong to me.
2) Why didn't the "LA1,STIMECB" abend on an S0C4-38 when bit 32 on the base 
reg was on? 

Thank you all for your help

--
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

[Elardus Engelbrecht]

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 resolved your problem after Peter Relson and Greg Dyck's questions / 
explanations?

Groete / Greetings
Elardus Engelbrecht

--
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

[Donald Likens]

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.

--
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

[Donald Likens]

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 / 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

[Peter Relson]

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 addressability:
STIMERX  DS0H 
... 
 USING *,R15

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

--
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

[Elardus Engelbrecht]

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

--
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

[Tom Marchant]

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 for help.

-- 
Tom Marchant

--
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

[Donald Likens]

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=003E   
 PSW AT TIME OF ERROR  070C2001   80007996  ILC 2  INTC 01   
   ACTIVE LOAD MODULE   ADDRESS=7000  OFFSET=0996
   NAME=MEASASMN 
   DATA AT PSW  7990 - 8918  002FD703  CD90CD90  
   GR 0: B300   1: 863E  
  2: 177DCFB0   3: 177DCFE0  
  4: 177DCFB0   5:   
  6: 007DAFC8   7: FD00  
  8:    9: 177DCE00  
  A:    B: 8000  
  C: 7000   D: 7190  
  E: 76C8   F: 7D70   

Did I misunderstand something?

--
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

[Donald Likens]

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   POST STIMECB  
1322  POST  STIMECB,X'40'SET ATTN/TIMER ECB 
1323+*MACDATE  03/11/11 
1325+ LA0,X'40'(0,0)   . SET POST CODE  
1326+ LA1,STIMECB  . LOAD ECB ADDRESS   
1327+ SVC   2  . ISSUE THE POST SVC 

ABEND S602-0!

However... this started me thinking... maybe the IRB is invoked in AMODE 31... 
070C1000   813FABEA.

+ SAM64   
+*SYSSTATE AMODE64=YES
+*THE VALUE OF SYSSTATE IS
+   VL=2 OSREL=000
+SE60081DS 0H 
 *C   POST STIMECB
  POST  STIMECB,X'40' 
+*MACDATE  03/11/11   
+ LA0,X'40'(0,0)  
+ LA1,STIMECB 
+ SVC   2 

ABEND S602-0 PSW AT TIME OF ERROR  070C1000   813FABEA

Thanks for the idea, but did not seem to work.

--
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

[Donald Likens]

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

[Greg Dyck]

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-memory POST.  In AMODE 31 the LA of the ECB 
ignores it so the POST works as expected.

Greg

--
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

[Rob Scott]

What does the macro expansion for POST look like?  (You should be able to tell 
if it is expanding to the correct 64-bit version).

Do you ensure that the SYSSTATE AMODE64 specification is correct in both the 
mainline code and the timer exit?



Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald Likens
Sent: 12 January 2015 15:52
To: IBM-MAIN@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 abend only in association with cross memory post 
processing.
The hexadecimal return code in register 15 indicates the nature of the error:
Code Explanation
00 The target address space control block (ASCB) is incorrect.

Per the manual STIMER, WAIT, and POST support AMODE 64.

 STIMER REAL,STIMERX,DINTVL=WKWAITI
 XC   STIMECB,STIMECB
 OI   WAITLAST,X'80'
 WAIT 1,ECBLIST=WAITLIST

STIMERX  DS0H
* TIMER EXPIRED
 DROP  R12
 USING *,R15
*C   POST STIMECB  ç In AMODE 31
 POST  STIMECB,X'40'   <== Abends on an S602 reason code 0
 DROP  R15
*C   RETURN
 BRR14

WAITLIST DS0F
ASMNSTOP DSA
WAITLAST DCA(STIMECB)
STIMECB  DSF

When I added the following before the STIMER it worked:

SAM31
SYSSTATE AMODE64=NO

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
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

[Dave Day]

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 during processing of a
POST macro instruction. The system issues this abend
only in association with cross memory post processing.
The hexadecimal return code in register 15 indicates the
nature of the error:
Code Explanation
00 The target address space control block (ASCB)
is incorrect.

Per the manual STIMER, WAIT, and POST support AMODE 64.

  STIMER REAL,STIMERX,DINTVL=WKWAITI
  XC   STIMECB,STIMECB
  OI   WAITLAST,X'80'
  WAIT 1,ECBLIST=WAITLIST

STIMERX  DS0H
* TIMER EXPIRED
  DROP  R12
  USING *,R15
*C   POST STIMECB   In AMODE 31
  POST  STIMECB,X'40'   <== Abends on an S602 reason code 0
  DROP  R15
*C   RETURN
  BRR14

WAITLIST DS0F
ASMNSTOP DSA
WAITLAST DCA(STIMECB)
STIMECB  DSF

When I added the following before the STIMER it worked:

SAM31
SYSSTATE AMODE64=NO

--
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