SYNCSVCD (Was: What happens when an LPAR gets interupted.)

[Edward Jaffe]

On 11/21/2012 1:04 PM, Jim Mulder wrote:


   So if you have changed your program to take work which used to
run under a TCB and instead run it under an enclave SRB so that you
can run it on a zIIP, you may experience some reduction in
serviceability because this work will no longer be automatically
stopped by SDUMP while SDUMP is capturing the address space.


And this restriction is *highly* inconvenient! >:0

In the old days an instruction fetch PER SLIP could be specified with A=SYNCSVCD 
and a "sticky" problem could be solved. Now you get msgIEA426I and a dump that 
is worthless.


Our zIIP-enabled code is designed to run in TCBs when no zIIPs are configured. 
Therefore, we can issue the customer a one-byte ZAP to disable enclave SRB use 
when a SYNCSVCD is needed to solve a problem. It's inconvenient, but it works. 
Any ISV with a design that *always* uses enclave SRBs is SOL. :(


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/28/2012
   at 10:44 AM, John Gilmore  said:

>The functioning of LOAD and DELETE provide a convenient example 
>of what this implies  If I LOAD a reentrant program that is not
>already present in storage, it is loaded and its usage/invocation
>count is increased from zero to one.  If instead it is already
>present in storage, having been loaded by someone else, its usage
>count is increased by one.  If I then DELETE that program, its usage count is 
>reduced
>by one; and only if that count is thus reduced to zero, i..e., if no one else 
>is 
>currently using it, is the storage occupied by this program recovered for 
>reuse.

Nonsense; that's not even true for an authorized application that
specifies GLOBAL=YES; ownership is at the task and address space
levels. What is true is that the owning task can delete a module
loaded with GLOBAL=YES while code in another address space is
executing it and that tasks in the same address space can step on each
other..

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS CZX2PTRT

[Thomas Conley]

On 11/28/2012 5:47 PM, Charles Mills wrote:

It's not "my problem" but I have a customer that is running into problems
with the subject program. It's one of those classic situations: the exact
reason they are even running the program is lost in the mists of antiquity.
It apparently got introduced as part of a VSE to MVS conversion over 20
years ago. It is some sort of "pre-linker" used with a number of PL/I, COBOL
and Assembler programs.

It is blowing up now under z/OS V1R13 and it's holding up the customer's
conversion.

I guess the link runs to 0 even if you omit the pre-link, but you know how
mainframers are: they don't want to just put the re-linked programs into
production and see what happens. 

Can any of the august minds in IBMMAIN-land shed any light on CZX2PTRT?

The customer thanks you.

Charles



Charles,

You should contact Patrick Fournier at virtelweb.com.  I worked with him 
and Gilbert St.Flour on a couple of VSE conversions.


Regards,
Tom Conley

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

Re: Usefullness (or not) of STOC/LOC instructions?

[Charles Mills]

LOL. Ain't it the truth!

Possibly even "too much bother to explain to the tech writers" or "I don't
have a precise enough logical grasp of it to translate its operation into
English sentences."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Wednesday, November 28, 2012 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Usefullness (or not) of STOC/LOC instructions?

FWIW, I agree with all of the spirit and almost all of the substance of Tony
Harminc's post.

I must, however, add that "unpredictable" is sometimes in some IBM
publications used as a polite euphemism for "It's too complicated to explain
here, and you wouldn't understand anyway".

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

Re: PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS CZX2PTRT

[Charles Mills]

> Are you sure this is a prelink, or is this a function subroutine used to
handle printing, or some such?

It is an executable PGM= that the customer is running between the compile
and the link.

> what was the OS level this was last run under before coming to z/OS 1.13?

V1R11

> Also, what was the blow-up? Example: S0C4

That would be useful information, wouldn't it?  Let me ask the customer.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Thompson
Sent: Wednesday, November 28, 2012 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS CZX2PTRT

From:   Charles Mills 
To: IBM-MAIN@listserv.ua.edu, 
Date:   11/28/2012 04:48 PM
Subject:PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS 
CZX2PTRT


It is blowing up now under z/OS V1R13 and it's holding up the customer's
conversion.

I guess the link runs to 0 even if you omit the pre-link, but you know how
mainframers are: they don't want to just put the re-linked programs into
production and see what happens. 

Can any of the august minds in IBMMAIN-land shed any light on CZX2PTRT?


Well, if Gilbert were still around I do not remember the CZX or CZX2
prefix. And I do not remember pre-linkers because CORTEX did a complete
migration from VSE to MVS (my specialty was the ALC side of things and
operations support after the migration). [That is, no CIL load via special
routine such as from DUO-360]

Are you sure this is a prelink, or is this a function subroutine used to
handle printing, or some such?

Also, what was the OS level this was last run under before coming to z/OS
1.13? Also, what was the blow-up? Example: S0C4 - 04 with PSW pointing in
low storage?

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

Re: PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS CZX2PTRT

[Steve Thompson]

From:   Charles Mills 
To: IBM-MAIN@listserv.ua.edu, 
Date:   11/28/2012 04:48 PM
Subject:PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS 
CZX2PTRT


It is blowing up now under z/OS V1R13 and it's holding up the customer's
conversion.

I guess the link runs to 0 even if you omit the pre-link, but you know how
mainframers are: they don't want to just put the re-linked programs into
production and see what happens. 

Can any of the august minds in IBMMAIN-land shed any light on CZX2PTRT?


Well, if Gilbert were still around I do not remember the CZX or CZX2 
prefix. And I do not remember pre-linkers because CORTEX did a complete 
migration from VSE to MVS (my specialty was the ALC side of things and 
operations support after the migration). [That is, no CIL load via special 
routine such as from DUO-360]

Are you sure this is a prelink, or is this a function subroutine used to 
handle printing, or some such?

Also, what was the OS level this was last run under before coming to z/OS 
1.13? Also, what was the blow-up? Example: S0C4 - 04 with PSW pointing in 
low storage?


Regards,
Steve Thompson

 
Unsure what trademarks are in use here, but nothing in this post is meant 
to deny any rights of any trademark holder.

Opinions expressed by this poster may not reflect those held by poster's 
employer.

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

PRISM or CORTEX VSE to MVS conversion aid (?) MVSMS CZX2PTRT

[Charles Mills]

It's not "my problem" but I have a customer that is running into problems
with the subject program. It's one of those classic situations: the exact
reason they are even running the program is lost in the mists of antiquity.
It apparently got introduced as part of a VSE to MVS conversion over 20
years ago. It is some sort of "pre-linker" used with a number of PL/I, COBOL
and Assembler programs.

It is blowing up now under z/OS V1R13 and it's holding up the customer's
conversion.

I guess the link runs to 0 even if you omit the pre-link, but you know how
mainframers are: they don't want to just put the re-linked programs into
production and see what happens. 

Can any of the august minds in IBMMAIN-land shed any light on CZX2PTRT?

The customer thanks you.

Charles 

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

Re: OMVS su -

[Andrew Rowley]

On 29/11/2012 3:08 AM, Hunkeler Peter (KIUP 4) wrote:


Unfortunately, on z/OS UNIX you typically have more than one userid
having uid=0.

While not perfect, the different path and other settings could be set
from the "uid=0" section of the ENV script I posted. Maybe by sourcing a
shared script to help those with "su" authority to set the same values.
(The script would be readable my UID=0 only).


/etc/profile would probably be the correct place to setup the different 
PATH and other settings. However, to execute that (or any other 
initialization script) I think requires "su -" as we were initially 
discussing. I don't see the need for the uid 0 stuff to be only readable 
by UID 0, but you could do that by referencing a secondary script only 
readable by UID 0.


More than one userid with UID=0 is something I have always felt is a bad 
design on z/OS. On the Unix side of the fence the UID is the primary 
identity, so really you have one UID with varying behaviour depending on 
circumstances.


Regards

Andrew Rowley

--
and...@blackhillsoftware.com
+61 413 302 386

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

Re: Usefullness (or not) of STOC/LOC instructions?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Kirk Talman
> Sent: Wednesday, November 28, 2012 2:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Usefullness (or not) of STOC/LOC instructions?
> 
> might a lurker ask questions?
> 
> if one rearranges the code at bottom as this, is the load of R2
> "cheaper"
> because it can be done in parallel w/the LT?  is it worth doing if the
> JZ is taken?
> 
> is 0(,R1) preferred to 0(R1) because of cost or esthetics?

I guess, in my case, it is a combination of esthetics and being concerned about 
possible AR mode considerations. In AR mode:

L   R2,0(,R1)
and
L   R2,0(R1)

will likely result in greatly different values being loaded into R2 if the 
contents of AR1 <> primary address space. 

> 
> LT   R1,POINTER
> L   R2,INTVAL
> JZ   AROUND
> ST   R2,0(,R1)
>  AROUND DS0H
> 
> > From: "McKown, John" 
> 
> >L   R2,INTVAL
> >LT   R1,POINTER
> >   STOC   R2,0(,R1),NZ
> >
> > instead of:
> >
> >LT   R1,POINTER
> >JZ   AROUND
> >L   R2,INTVAL
> >ST   R2,0(,R1)
> > AROUND DS0H
> >
> > for the C construct:
> >
> >if (POINTER != NULL) *POINTER=INTVAL;

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

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

Re: Usefullness (or not) of STOC/LOC instructions?

[Henry Willard]

Tony Harminc wrote:

> On 28 November 2012 13:54, Alan Altmark  wrote:
> > On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin  
> > wrote:
> >
> >>But what plausible use do you envision that anyone or any group at IBM might
> >>have for the "model dependent" character?  It requires that software 
> >>developers
> >>test on every available and possible future system.  Simply, it's 
> >>irresponsible
> >>not to have made the behavior consistent across models.  If it's going to 
> >>fail
> >>on some models, it should be designed to fail likewise on all models. 
> >>Perhaps
> >>with SIE?
> >
> > There is nothing new here, Paul.  One of the original design points for 
> > S/360 was to separate machine behavior from the programming interface.  You 
> > want to be able to change and optimize the machine behaviors over time 
> > without screwing up the interface.
> >
> > This is precisely why you see "model-dependent" in the documentation - so 
> > you DON'T build an expectation.  And it's why you can still run programs 
> > written in 1965.
>
> There are two terms used in the Principles of Operation - "model
> dependent" and "unpredictable". It may be that the use of these terms
> has changed slightly, but I have always read the former as imposing a
> weaker constraint on the programmer than the latter. If a behaviour is
> "model dependent" it is presumably consistent on that model, and it
> would be possible, if fairly unlikely, that a program could discover
> the behaviour and exploit it. This is certainly not the case for
> "unpredictable" results, which can vary from one execution to the
> next.
>
> Regardless, I disagree strongly with Paul on this in general; I think
> the notion of not overspecifying behaviour is a very good one. IBM has
> historically done an amazing job of writing the Principle of Operation
> so that it specifies the required behaviour of the machine, and
> clarifies certain possible variations that should not be relied on.
> And they are very quick to correct errors and unclear writing on those
> few occasions it arises.
>
> > As STOC Usage Note 2 states, if the store is skipped because of the 
> > condition code, the operand might not be fetched into cache.  But it is a 
> > matter of implementation as to exactly when the circuitry triggers things 
> > like PER storage-alteration events or set the page change bit.  As the 
> > machines get smarter, the accuracy of those events improves.   While the 
> > machine may over-indicate (a false positive) an event, it will never 
> > under-indicate an event.
>
> I agree, though one must be careful with the notions of over and
> under. For example the change bit is never under set, but the
> reference bit may well be.
>
> I think Dave's original question was quite reasonable, though: what
> *are* these instructions good for in the real world (or rather, under
> what circumstances do they provide a performance advantage compared to
> BC + L or ST) if not for the sort of usage he suggests?

I can easily think of many applications although not necessarily C. A lot of 
the newer facilities seem to be targeted at Java.

Regards,
Henry

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

Re: Usefullness (or not) of STOC/LOC instructions?

[Henry Willard]

"McKown, John" wrote:

> I guess what Paul was really disappointed in, is that C uses binary zero as 
> the NULL pointer. And it might be nice to be able to use the STOC command to 
> store a value with:
>
> L   R2,INTVAL
> LT  R1,POINTER
>   STOC  R2,0(,R1),NZ
>
> instead of:
>
> LT  R1,POINTER
> JZ  AROUND
> L   R2,INTVAL
> ST  R2,0(,R1)
> AROUND DS   0H
>
> for the C construct:
>
> if (POINTER != NULL) *POINTER=INTVAL;
>
> I don't know what the C compiler actually generates for that particular code 
> sequence. But the STOC almost seems made-to-order for it.

For the simple non-optimized case, yes, but the C compiler rarely generates 
such simple code for this once optimization is applied. After the compiler 
moves things around to avoid the storage access penalties and address 
interlocks the use of STOC may not be most reasonable choice. Also the 
instruction description points out that the branching code may perform better 
than the conditional store. This is also model dependent.

Regards,
Henry

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

Re: Usefullness (or not) of STOC/LOC instructions?

[John Gilmore]

FWIW, I agree with all of the spirit and almost all of the substance
of Tony Harminc's post.

I must, however, add that "unpredictable" is sometimes in some IBM
publications used as a polite euphemism for "It's too complicated to
explain here, and you wouldn't understand anyway".

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: Usefullness (or not) of STOC/LOC instructions?

[Kirk Talman]

might a lurker ask questions?

if one rearranges the code at bottom as this, is the load of R2 "cheaper" 
because it can be done in parallel w/the LT?  is it worth doing if the JZ 
is taken?

is 0(,R1) preferred to 0(R1) because of cost or esthetics?

LT   R1,POINTER
L   R2,INTVAL
JZ   AROUND
ST   R2,0(,R1)
 AROUND DS0H

> From: "McKown, John" 

>L   R2,INTVAL
>LT   R1,POINTER
>   STOC   R2,0(,R1),NZ
> 
> instead of:
> 
>LT   R1,POINTER
>JZ   AROUND
>L   R2,INTVAL
>ST   R2,0(,R1)
> AROUND DS0H
> 
> for the C construct:
> 
>if (POINTER != NULL) *POINTER=INTVAL;


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

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

Re: Usefullness (or not) of STOC/LOC instructions?

[Scott Fagen]

On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin  wrote:

>It requires that software developers
>test on every available and possible future system.  Simply, it's irresponsible
>not to have made the behavior consistent across models.

Think Java.  The JVM can construct different instruction sequences (JIT 
compile) based on the the underlying hardware, determined when the JVM is 
started.

Scott Fagen
Chief Architect - Mainframe
CA Technologies

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

Re: Usefullness (or not) of STOC/LOC instructions?

[Tony Harminc]

On 28 November 2012 13:54, Alan Altmark  wrote:
> On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin  
> wrote:
>
>>But what plausible use do you envision that anyone or any group at IBM might
>>have for the "model dependent" character?  It requires that software 
>>developers
>>test on every available and possible future system.  Simply, it's 
>>irresponsible
>>not to have made the behavior consistent across models.  If it's going to fail
>>on some models, it should be designed to fail likewise on all models. Perhaps
>>with SIE?
>
> There is nothing new here, Paul.  One of the original design points for S/360 
> was to separate machine behavior from the programming interface.  You want to 
> be able to change and optimize the machine behaviors over time without 
> screwing up the interface.
>
> This is precisely why you see "model-dependent" in the documentation - so you 
> DON'T build an expectation.  And it's why you can still run programs written 
> in 1965.

There are two terms used in the Principles of Operation - "model
dependent" and "unpredictable". It may be that the use of these terms
has changed slightly, but I have always read the former as imposing a
weaker constraint on the programmer than the latter. If a behaviour is
"model dependent" it is presumably consistent on that model, and it
would be possible, if fairly unlikely, that a program could discover
the behaviour and exploit it. This is certainly not the case for
"unpredictable" results, which can vary from one execution to the
next.

Regardless, I disagree strongly with Paul on this in general; I think
the notion of not overspecifying behaviour is a very good one. IBM has
historically done an amazing job of writing the Principle of Operation
so that it specifies the required behaviour of the machine, and
clarifies certain possible variations that should not be relied on.
And they are very quick to correct errors and unclear writing on those
few occasions it arises.

> As STOC Usage Note 2 states, if the store is skipped because of the condition 
> code, the operand might not be fetched into cache.  But it is a matter of 
> implementation as to exactly when the circuitry triggers things like PER 
> storage-alteration events or set the page change bit.  As the machines get 
> smarter, the accuracy of those events improves.   While the machine may 
> over-indicate (a false positive) an event, it will never under-indicate an 
> event.

I agree, though one must be careful with the notions of over and
under. For example the change bit is never under set, but the
reference bit may well be.

I think Dave's original question was quite reasonable, though: what
*are* these instructions good for in the real world (or rather, under
what circumstances do they provide a performance advantage compared to
BC + L or ST) if not for the sort of usage he suggests?

> It would be unforgivable if the architects baked in

I'm sure this was going to say something interesting...

Tony H.

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

Re: Usefullness (or not) of STOC/LOC instructions?

[McKown, John]

I guess what Paul was really disappointed in, is that C uses binary zero as the 
NULL pointer. And it might be nice to be able to use the STOC command to store 
a value with:

L   R2,INTVAL
LT  R1,POINTER
  STOC  R2,0(,R1),NZ

instead of:

LT  R1,POINTER
JZ  AROUND
L   R2,INTVAL
ST  R2,0(,R1)
AROUND DS   0H

for the C construct:

if (POINTER != NULL) *POINTER=INTVAL;

I don't know what the C compiler actually generates for that particular code 
sequence. But the STOC almost seems made-to-order for it. But, given the OP's 
original message, this results in an S0C4-4, on zPDT, due to storage protection 
causing a PIC 004. I don't know how zPDT actually implements the zArch, but if 
it is totally software, I really don't understand why it generates a PIC 004. 
Unless it is designed to be the "most restrictive" and generate the "least 
desirable" model dependent operations so that the developer is force to write 
code which is most likely runnable on any zArch (of the appropriate level).

If anybody wants to complain about "model dependent" behavior, read up on the 
ARM architecture. You almost need to target your code for each vendor's 
implementation.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Alan Altmark
> Sent: Wednesday, November 28, 2012 12:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Usefullness (or not) of STOC/LOC instructions?
> 
> On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin
>  wrote:
> 
> >But what plausible use do you envision that anyone or any group at IBM
> >might have for the "model dependent" character?  It requires that
> >software developers test on every available and possible future
> system.
> >Simply, it's irresponsible not to have made the behavior consistent
> >across models.  If it's going to fail on some models, it should be
> >designed to fail likewise on all models. Perhaps with SIE?
> 
> There is nothing new here, Paul.  One of the original design points for
> S/360 was to separate machine behavior from the programming interface.
> You want to be able to change and optimize the machine behaviors over
> time without screwing up the interface.
> 
> This is precisely why you see "model-dependent" in the documentation -
> so you DON'T build an expectation.  And it's why you can still run
> programs written in 1965.
> 
> Where conditional execution is involved, the machine often tries to
> avoid unnecessary work.  This is what out-of-order execution and
> pipelining are all about.  If the machine decides NOT to do something,
> then the machine MAY not detect certain conditions.  Nonetheless, the
> instruction yields the expected result.
> 
> See "Sequence of Storage References" in Ch. 5 of the POP, particularly
> "Divisible instruction execution."  Sometimes part of the instruction
> can be run while a data fetch is in progress.  Note that most data
> reference (load or store) requires intermediate fetches to get ART and
> DAT entries, etc.  Some of this parallelism is needed to counter the
> distance- and cache-related effects of accessing memory.
> 
> As STOC Usage Note 2 states, if the store is skipped because of the
> condition code, the operand might not be fetched into cache.  But it is
> a matter of implementation as to exactly when the circuitry triggers
> things like PER storage-alteration events or set the page change bit.
> As the machines get smarter, the accuracy of those events improves.
> While the machine may over-indicate (a false positive) an event, it
> will never under-indicate an event.
> 
> It would be unforgivable if the architects baked in
> 
> Alan Altmark
> IBM
> 
> --
> 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: Usefullness (or not) of STOC/LOC instructions?

[Alan Altmark]

On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin  wrote:

>But what plausible use do you envision that anyone or any group at IBM might
>have for the "model dependent" character?  It requires that software developers
>test on every available and possible future system.  Simply, it's irresponsible
>not to have made the behavior consistent across models.  If it's going to fail
>on some models, it should be designed to fail likewise on all models. Perhaps
>with SIE?

There is nothing new here, Paul.  One of the original design points for S/360 
was to separate machine behavior from the programming interface.  You want to 
be able to change and optimize the machine behaviors over time without screwing 
up the interface.

This is precisely why you see "model-dependent" in the documentation - so you 
DON'T build an expectation.  And it's why you can still run programs written in 
1965.

Where conditional execution is involved, the machine often tries to avoid 
unnecessary work.  This is what out-of-order execution and pipelining are all 
about.  If the machine decides NOT to do something, then the machine MAY not 
detect certain conditions.  Nonetheless, the instruction yields the expected 
result.

See "Sequence of Storage References" in Ch. 5 of the POP, particularly 
"Divisible instruction execution."  Sometimes part of the instruction can be 
run while a data fetch is in progress.  Note that most data reference (load or 
store) requires intermediate fetches to get ART and DAT entries, etc.  Some of 
this parallelism is needed to counter the distance- and cache-related effects 
of accessing memory. 

As STOC Usage Note 2 states, if the store is skipped because of the condition 
code, the operand might not be fetched into cache.  But it is a matter of 
implementation as to exactly when the circuitry triggers things like PER 
storage-alteration events or set the page change bit.  As the machines get 
smarter, the accuracy of those events improves.   While the machine may 
over-indicate (a false positive) an event, it will never under-indicate an 
event.

It would be unforgivable if the architects baked in 

Alan Altmark
IBM

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

Re: "New" way to do UCB lookups

[Steve Thompson]

From:   Paul Gilmartin 
To: IBM-MAIN@listserv.ua.edu, 
Date:   11/28/2012 11:52 AM
Subject:Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 





And consider the job:

//WHATEVER JOB ...
//*
//STEP1  EXEC  PGM=BPXBATCH,PARM='SH sleep '
//*
//STEP2  EXEC  PGM=IEFBR14,COND=(0,LE)
//SYSUT1  DD   DISP=MOD,DSN=M42TOM.LINKLIB
//
... I can monopolize your data set while not using it for several
hours, preventing any of your use of it.  The design shouldn't
allow that.


Then a 44 magnum should not be allowed to discharge when pointed at  _ 
(fill in with your|their|my  foot|head|knee  etc.).

YOU created a BATCH job that needs certain resources that YOU determined 
prior to submitting the JOB. The system scheduled and then ran the JOB 
based on how you have the system defined and set up.

You effectively loaded a side-arm in a crowded room, cocked it, and 
pointed it and pulled the trigger.

Now you want to blame the manufacturer for it taking your knee off. Or 
killing all the power in the room.

Would you like some cheese with your whine?


Opinions expressed by this poster do not necessarily reflect those of 
poster's employer.

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

Re: "New" way to do UCB lookups

[Paul Gilmartin]

On Wed, 28 Nov 2012 10:19:04 -0600, Tom Marchant wrote:

>On Wed, 28 Nov 2012 00:30:24 -0600, Paul Gilmartin wrote:
>
>>If I _own_ a thing, you shouldn't be able to
>>do anything that prevents my doing what I want with it.
>
>So if you own a data set and you have permitted me to read it, 
>you should be able to delete that data set while I am reading it?
> 
If needed, yes.  I can certainly do likewise with a UNIX file, although
the space isn't reclaimed until you close it, and I don't know whose
quota it counts again in the meantime.

Last week I needed to delete and rebuild a linklib that a colleague
had allocated.  Possibly since July.  When he came back this week,
he readily cancelled the job -- it was a test he had largely forgotten.

If JCL allowed UNIX directories in STEPLIB concatenations, the
problem wouldn't have occurred.

And consider the job:

//WHATEVER JOB ...
//*
//STEP1  EXEC  PGM=BPXBATCH,PARM='SH sleep '
//*
//STEP2  EXEC  PGM=IEFBR14,COND=(0,LE)
//SYSUT1  DD   DISP=MOD,DSN=M42TOM.LINKLIB
//
... I can monopolize your data set while not using it for several
hours, preventing any of your use of it.  The design shouldn't
allow that.

-- gil

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

Re: Space allocation was Re: "New" way to do UCB lookups

[John Gilmore]

Clark Morris wrote:


So far as I can tell, other than making requests for a big quota, the
application developers
don't need to deal with space allocation in the other environments and
definitely not on a file by file basis.


and I think this should be conceded.

What is not so clear is that this is not a defect rather than a merit.

Long ago, I remember being regaled over and over again with statements
that adversely compared the great simplicity of a FORTRAN compilation
under UNIVAC's EXEC 8 with the 'gratuitous' complexity of this same
operation under OS/360.

I investigated and found that it was indeed much easier to compile a
FORTRAN program under EXEC 8; but a price had to be and was paid for
this simplicity.  It was hard to do much of anything else.

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

Space allocation was Re: "New" way to do UCB lookups

[Clark Morris]

On 27 Nov 2012 22:07:05 -0800, in bit.listserv.ibm-main you wrote:

 On 11/27/2012 at 08:35 PM, John McKown  
 wrote: 
>> IIRC, quotas can be implemented on some of the file systems in Linux.
>
>Most of them, in fact.
>
But there is no equivalent of the SPACE parameter in scripts for any
of those environments that I have seen.  It appears to be more like
something done under the covers by DF/SMS in z/OS and solely under the
control of the systems administration groups.  So far as I can tell,
other than making requests for a big quota, the application developers
don't need to deal with space allocation in the other environments and
definitely not on a file by file basis.

Clark Morris

>
>Mark Post
>

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

Re: "New" way to do UCB lookups

[Tom Marchant]

On Wed, 28 Nov 2012 00:30:24 -0600, Paul Gilmartin wrote:

>If I _own_ a thing, you shouldn't be able to
>do anything that prevents my doing what I want with it.

So if you own a data set and you have permitted me to read it, 
you should be able to delete that data set while I am reading it?

-- 
Tom Marchant

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

Re: OMVS su -

[Hunkeler Peter (KIUP 4)]

>"su -" is considered good practice in other unix environments because 
>root's environment is likely to be quite different to a normal user's 
>environment.
[snip]
>So "su -" is good practice to ensure that you get an environment that
is 
>intended for use with UID 0.

Unfortunately, on z/OS UNIX you typically have more than one userid
having uid=0.

While not perfect, the different path and other settings could be set
from the "uid=0" section of the ENV script I posted. Maybe by sourcing a
shared script to help those with "su" authority to set the same values.
(The script would be readable my UID=0 only).

Mark: Thanks for the remark regarding $ENV. I missed to add it.

--
Peter Hunkeler

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

Re: "New" way to do UCB lookups

[John Gilmore]

I have grown weary of responding to Paul Gilmartin's moral outrage of
the day, but today's does require some comment.  He writes:


If I _own_ a thing, you shouldn't be able to do anything that prevents
my doing what I want with it.  RACF is badly oblivious to this.


This is a bad design notion.  (It is also bad law; the state can
invoke eminent domain to take my property away from me for purposes
that I may disapprove.)  MVS and its immediate antecedents have,
properly in my view, always judged that many operations must be
virtualizable.

The functioning of LOAD and DELETE provide a convenient example of
what this impliesIf I LOAD a reentrant program that is not already
present in storage, it is loaded and its usage/invocation count is
increased from zero to one.  If instead it is already present in
storage, having been loaded by someone else, its usage count is
increased by one.  If I then DELETE that program, its usage count is
reduced by one; and only if that count is thus reduced to zero, i..e.,
if no one else is currently using it, is the storage occupied by this
program recovered for reuse.

Paul's notion that the absolutist property-rights doctrines of
19th-century robber-baron capitalism provide an appropriate
system-design paradigm has a fatal flaw.  It prevents sharing those
resources.

Like many of his other comments, this one makes sense for a literally
'personal' computer, one used by a single person.  It is radically
inappropriate to a mainframe, the resources of which are shared by
many people.

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: OMVS su -

[Mark Zelden]

On Wed, 28 Nov 2012 09:05:26 +0100, Hunkeler Peter (KIUP 4) 
 wrote:

>>a) the alias's in my .profile get lost after doing a "su"
>>b) I like to see a different command prompt to remind me
>
>Below is my "ENV" script, which is run whenever a s(sub)shell starts. It
>tests for the current uid and sets the shell prompt variable PS1
>accordingly. It also set my aliases.
>Note that variables HOSTNAME, HOSTREL, MYLOCALE and MYCODEPAGE are set
>in my .profile. 
>



What may not be clear from Peter's post is that you have to specify the name 
of that script in the ENV environment variable.   So in my .profile I have
this (in addition to some other exports - which should remain in .profile
and not in the "ENV" script):

# set up my environment
export ENV=$HOME/@myenv


Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: RMF Spreadsheet Reporter

[Ron Wells]

tks for reply...
was asking question as to how you did the batch...
like where the parm's/control card info was stored...see the batch it 
submits..gather it is getting the info from somewhere..





From:   Shane Ginnane 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/28/2012 03:51 AM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



Sorry Ron, are you making a statement or asking a question ?.

As it happens I didn't progress much, despite trying several iterations of 
(z/OS) batch machinations, both before and after that post of mine you 
quoted.
Interesting that this client has a working monthly report - modifying that 
caused it to break also ...

I needed to put something in place that would be useful when I left. The 
reporter just doesn't cut it any more IMHO.
I suspect Andrew may have a new customer soon.

Shane ...

On Tue, 27 Nov 2012 06:59:54 -0600, Ron Wells  wrote:

>Shane
>you have an example of what ys did for batch processing...as what is
>needed and not needed from all the jcl and STUFF generated..
>gather the rmfpp parms can then be altered without jumping around in the
>gui mess.
>
>yes...seems strange the way it is setup...would be nice to reclac the
>intervals for weekly/monthly roll up reporting by the service classes

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: TS7740 and VTS B20

[Darth Keller]

OpenTech (now RocketSoftware)'s TapeCopy can handle moving HSM tapes too - 
 it updates the CDS's with no issue.  We used it for multiple migrations. 
We also use the VDR function to backup the ML2 tapes and restore them at 
DR also  - no issues.



/
Hello again.
Forgot to mention that it's not just HSM with it's own internal tape 
catalog you need to watch out for, there are some report archiving 
products that have it too.

Infopac/mobius/viewdirect by asg sofware is one such (opentech's tapecopy 
can handle this i believe) and i'm seem to remember CA-Despatch was 
another.
These products have there own tape copying / report copying utilities 
(probably an add on cost) but may well be slower than something like 
tapecopy.

As the Phil Esterhaus used to say at the end of the roll call on Hill 
Street Blues, "Hey! let's be careful out there"

Dave


This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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

Re: NETSOL CBT 1981 edition question

[Shmuel Metz (Seymour J.)]

In
,
on 11/27/2012
   at 06:11 PM, "Cifani, Domenic"  said:

>When I try to run the Assembly for CMDSUB it fails looking for a
>Macro called RPLUSFLD, or at least I believe it's a macro.

Why? Didn't you read the error message or look it up?

>the assembly error.

Is that the only one?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: Parsing

[Shmuel Metz (Seymour J.)]

In <3904dc44-8ee9-4a19-8f0e-39023f49b...@yahoo.com>, on 11/27/2012
   at 09:22 AM, Scott Ford  said:

>I also, if memory servers me Cobol was also at Unisys in some sort

There was no Unisys in the 1960's, but both Burroughs and UNIVAC had
COBOL compilers.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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: OMVS su -

[Andrew Rowley]

On 27/11/2012 7:39 PM, Hunkeler Peter (KIUP 4) wrote:


Why do you do a "su -" instead of simply "su"?

I consider the dash option to be useful only when switching to another
identity as in "su - another.userid". You're changing the MVS userid as
well as the UNIX uid, so it is sensible to also setup the shell
environment to lokk as if you had logged in with that userid.


"su -" is considered good practice in other unix environments because 
root's environment is likely to be quite different to a normal user's 
environment.


Typically the directories in the PATH are much more restrictive, and 
there may be directories added that contain programs that are only used 
by root e.g. /usr/sbin. A regular user might have the current directory 
in their PATH, root should not.


It is considered a security exposure if any directory (or any of the 
parent directories) in root's PATH is writable by a non-root user.


So "su -" is good practice to ensure that you get an environment that is 
intended for use with UID 0.


Regards

Andrew Rowley


--
and...@blackhillsoftware.com
+61 413 302 386

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

Re: RMF Spreadsheet Reporter

[Shane Ginnane]

Sorry Ron, are you making a statement or asking a question ?.

As it happens I didn't progress much, despite trying several iterations of 
(z/OS) batch machinations, both before and after that post of mine you quoted.
Interesting that this client has a working monthly report - modifying that 
caused it to break also ...

I needed to put something in place that would be useful when I left. The 
reporter just doesn't cut it any more IMHO.
I suspect Andrew may have a new customer soon.

Shane ...

On Tue, 27 Nov 2012 06:59:54 -0600, Ron Wells  wrote:

>Shane
>you have an example of what ys did for batch processing...as what is
>needed and not needed from all the jcl and STUFF generated..
>gather the rmfpp parms can then be altered without jumping around in the
>gui mess.
>
>yes...seems strange the way it is setup...would be nice to reclac the
>intervals for weekly/monthly roll up reporting by the service classes

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

Re: TS7740 and VTS B20

[David Devine]

Hello again.
Forgot to mention that it's not just HSM with it's own internal tape catalog 
you need to watch out for, there are some report archiving products that have 
it too.

Infopac/mobius/viewdirect by asg sofware is one such (opentech's tapecopy can 
handle this i believe) and i'm seem to remember CA-Despatch was another.
These products have there own tape copying / report copying utilities (probably 
an add on cost) but may well be slower than something like tapecopy.

As the Phil Esterhaus used to say at the end of the roll call on Hill Street 
Blues, "Hey! let's be careful out there"

Dave



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

Re: Use of FCWITHDRAW with EMC Dasd

[Walter Marguccio]

> From: Lizette Koehler 
> Subject: Use of FCWITHDRAW with EMC Dasd

> ADR287I (001)-DDTFP(01), FCWITHDRAW WAS ISSUED FOR VOLUME XX
> ON UNIT A051 BECAUSE THE VOLUME WAS NOT INITIALIZED, RETURN CODE 1 

> And I am not sure if this is an issue. 

From the dss manual:

"FCWITHDRAW specifies that if the volume that is dumped is the target volume of
a FlashCopy relationship, the relationship is withdrawn when the dump has
successfully completed"

Is your source volume the target volume of a FC relationship ? If not, then the 
keyword
here would make no sense, would it ?

Explanation for ADR287I claims that 

"Following a successful DUMP operation, DFSMSdss attempted to 
invoke ICKDSF to initialize the source volume of the DUMP operation    
because the FCWITHDRAW keyword was specified."

If your goal is to obtain a successfull DUMP of the volume, you've got one.
In this case I wouldn't see the rc=1 as an issue.


Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany


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

Re: OMVS su -

[Hunkeler Peter (KIUP 4)]

>a) the alias's in my .profile get lost after doing a "su"
>b) I like to see a different command prompt to remind me

Below is my "ENV" script, which is run whenever a s(sub)shell starts. It
tests for the current uid and sets the shell prompt variable PS1
accordingly. It also set my aliases.
Note that variables HOSTNAME, HOSTREL, MYLOCALE and MYCODEPAGE are set
in my .profile. 


start of ENV script (next line) -
# This is is the shell initialization script pointed to by ENV.   
#  
if test $(id -u) = 0   
then   
 export PS1='$LOGNAME @ $HOSTNAME($HOSTREL) $MYLOCALE.$MYCODEPAGE
$PWD #> '   
else   
 export PS1='$LOGNAME @ $HOSTNAME($HOSTREL) $MYLOCALE.$MYCODEPAGE
$PWD $> '   
fi 
   
set -o vi  
set -o logical 
alias ps='ps -ef -ojobname,user,xasid=ASID -opid,ppid,stime,tty=TTY
-oargs'
alias psuid='ps -ef -opid,ppid,uid,ruid,gid,rgid -oargs'   
   
   
if test X"$TERM" = "X" -o X"$TERM" = "Xdumb"   
then   
   alias clear="printf '\f'"   
else   
   alias clear='tput clear'
fi 
- end of ENV sctipt (previous line)---


--
Peter Hunkeler

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