Hi,
I was reading the manual for an explanation of CPU lock:
CPU lock -- provides MVS-recognized (valid) disablement for I/O and
external interrupts.
The manual gives a further explanation:
MVS does not guarantee preservation of the interrupt status of
programs that explicitly disable for I/O
Brad,
Using the APPL class would be an effective means of governing entry into
ViewDirect. Starting with the .SOURCE(RACF) member as Ken advised, you
simply need to modify the RACROUTE REQUEST=VERIFY macro therein to include
the APPL=applid parameter. The inclusion of this parameter prompts the
In [EMAIL PROTECTED], on 11/07/2007
at 02:32 PM, Phil Payne [EMAIL PROTECTED] said:
Back then, though, IBM perceived the lack of a stack as a marketing
_adantage_. The competition (Burroughs, CDC, ICL) was all stack-based.
No. Not even Burroughs was all stack based and CDC wasn't at all. To
In [EMAIL PROTECTED],
on 11/07/2007
at 03:42 PM, Timothy Sipples [EMAIL PROTECTED] said:
And one also wonders
whether it would have been so easy for the large EBCDIC installed base
What latge EBCDIC install base? EBCDIC was new on the S/360.
As we all know,
No.
EBCDIC puts the letters in
On Wed, 21 Nov 2007 18:14:56 +0800 Johnny Luo [EMAIL PROTECTED]
wrote:
:I was reading the manual for an explanation of CPU lock:
:CPU lock -- provides MVS-recognized (valid) disablement for I/O and
:external interrupts.
:The manual gives a further explanation:
:MVS does not guarantee
On Tue, 20 Nov 2007 18:16:25 -0500 Jack Schudel [EMAIL PROTECTED]
wrote:
:http://www.tachyonsoft.com/inst390m.htm
:lists when the various instructions became available.
:For example:
: ADRN B2C0 Add with Rounding4361
: ADTR B3D2 Add
Sridhar,
Theoretically, you could just apply the templates for the target z/OS
release to the old database and reIPL with it. This assumes the database in
the restructured format introduced with RACF 1.9 (MVS/ESA). However, there
are many other factors that would determine whether your system
In a message dated 11/21/2007 5:31:09 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
:The manual gives a further explanation:
:MVS does not guarantee preservation of the interrupt status of
:programs that explicitly disable for I/O and external interrupts
:through the STNSM
On Wed, 21 Nov 2007 09:41:06 EST (IBM Mainframe Discussion List)
[EMAIL PROTECTED] wrote:
:In a message dated 11/21/2007 5:31:09 A.M. Central Standard Time,
:[EMAIL PROTECTED] writes:
::The manual gives a further explanation:
::MVS does not guarantee preservation of the interrupt status of
On Wed, 21 Nov 2007 18:14:56 +0800, Johnny Luo
[EMAIL PROTECTED] wrote:
I was reading the manual for an explanation of CPU lock:
CPU lock -- provides MVS-recognized (valid) disablement for I/O and
external interrupts.
The manual gives a further explanation:
MVS does not guarantee preservation
In a message dated 11/21/2007 9:23:22 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Nucleus is not going to page fault. And if STARTIO fails before it gets the
UCB lock, no harm - no foul - since nothing is in the middle.
So there are zero defects now in the nucleus? I doubt it.
On Wed, 21 Nov 2007 09:41:06 EST, IBM Mainframe Discussion List
[EMAIL PROTECTED] wrote:
There must be more to it than that. ...snipped...
Another clue is that in the PSA DSECT the comment on the PSASYMSK byte
says This field will be used in conjunction with the STNSM instruction to
place
-snip--
So there are zero defects now in the nucleus? I doubt it. A disabled
page
fault is easy to handle - just ABEND the current piece of work and
move right
along. What happens next depends on what the current piece of work was.
Even if the nucleus
--snip-
:http://www.tachyonsoft.com/inst390m.htm
:lists when the various instructions became available.
:For example:
: ADRN B2C0 Add with Rounding4361
: ADTR B3D2 Add z9-BC
--snip--
Translation: IBM's use of the STNSM to disable interrupts explicitly
within the nucleus
is rife, so why do they externally document that it should not be done?
unsnip--
The first reason I
In [EMAIL PROTECTED], on 11/20/2007
at 12:09 AM, Ed Gould [EMAIL PROTECTED] said:
Colocation providers reflect on robbery at CI Host
Chickens coming home to roost? Google for C I Host or CIHOST' in
news.admin.net-abuse.* and then ask whether anybody is surprised.
--
Shmuel (Seymour
In [EMAIL PROTECTED], on 11/19/2007
at 10:39 PM, Capomaestro [EMAIL PROTECTED] said:
I am looking at a project that will require the mapping of PLI load
modules. I am searching for long lost CSECTs of a sunsetted product.
PL/I load modules are like any other load modules; the CSECT names are
In [EMAIL PROTECTED], on 11/20/2007
at 09:37 PM, Shane [EMAIL PROTECTED] said:
On Tue, 2007-11-20 at 13:28 +0200, Gadi (well disguised)
While I will admit that my new reader also doesn't handle RFC 2047
encoding, I'd hardly call it hidden, although his choice of windows-1255
instead of
On Wed, 21 Nov 2007 06:37:32 -0500, Robert S. Hansel (RSH)
[EMAIL PROTECTED] wrote:
Theoretically, you could just apply the templates for the target z/OS
release to the old database and reIPL with it. This assumes the database in
the restructured format introduced with RACF 1.9 (MVS/ESA).
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
Sent: Wednesday, November 21, 2007 4:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Dataset-held message to TSO user
In [EMAIL PROTECTED], on 11/16/2007
at
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant
Sent: Wednesday, November 21, 2007 11:18 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: What is 'MVS-recognized' disablement?
On Wed, 21 Nov 2007 10:51:09 EST, IBM Mainframe
I was reading the manual for an explanation of CPU lock:
CPU lock -- provides MVS-recognized (valid) disablement for I/O and
external interrupts.
The manual gives a further explanation:
MVS does not guarantee preservation of the interrupt status of
programs that explicitly disable for I/O
Of course the nucleus is designed not to page-fault while
disabled. One way
that is guaranteed is by being sure that every byte ever
touched by disabled
code is fixed before doing the disabling operation.
If I'm not mistaken, the nucleus is fixed and non-swappable.
Some of it is
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris
Sent: Wednesday, November 21, 2007 11:45 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: What is 'MVS-recognized' disablement?
snip
In reality it is likely that less and less
On Wed, 21 Nov 2007 05:40:51 -0800 (PST), in
bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] wrote:
Hello all,
This question is about z/os and pkzip.
Used versions; z/os 1.7.1 and PKZIP(R) for zSeries,
Version 8.2.0 -
02/06/06 15.01 LVL(4)
I've been looking around
On Nov 21, 2007, at 11:22 AM, McKown, John wrote:
--SNIP---
In [EMAIL PROTECTED], on 11/16/2007
at 06:49 PM, Ed Gould [EMAIL PROTECTED] said:
Point of curiosity here. Why not just change it to PUTLINE ?
Because then it would no longer work.
That should fix the problem,
On Tue, 20 Nov 2007 15:44:46 -0400, Shmuel Metz (Seymour J.)
[EMAIL PROTECTED] wrote:
...
And one also wonders
whether it would have been so easy for the large EBCDIC installed
base
What latge EBCDIC install base? EBCDIC was new on the S/360.
...
I wondered about that, too, but assumed he
Ed Gould wrote:
Thanks... I was under the misunderstanding that TPUT would not work in
batch. They have apparently fixed it.
That was *never* the issue. The problem was that the TPUT was being
issued from an MPF on the system where the contention message was issued
... not necessarily the
On Wed, 21 Nov 2007 13:55:07 -0600 Ed Gould [EMAIL PROTECTED] wrote:
:Thanks... I was under the misunderstanding that TPUT would not work
:in batch. They have apparently fixed it.
TPUT works in batch, in that you can send a message to a logged on TSO user.
TPUT does not go to SYSTSPRT.
The results of the query command are in the system log. Can you use
SDSF to get the details you want from there?
-Original Message-
From: Barry Gilder [mailto:snip]
Sent: Tuesday, November 20, 2007 8:01 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Retrieving current HSM AutoDump processing
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/21/2007
05:14:56 AM:
I was reading the manual for an explanation of CPU lock:
CPU lock -- provides MVS-recognized (valid) disablement for I/O and
external interrupts.
The manual gives a further explanation:
MVS does not
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/21/2007
10:51:09 AM:
I still do not understand the necessity for the warning about
MVS-guaranteed
disablement's requiring a system lock's being held. One result of
acquiring
a system lock is the turning on of a super bit.
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/21/2007
12:44:50 PM:
If I'm not mistaken, the nucleus is fixed and non-swappable.
Some of it is
even designed to run with DAT off.
I wonder why? Is there something in fixed memory which would otherwise
be unavailable
Jim Mulder said;
It means that if you do a SETLOCK RELEASE for the CPU lock
or a spin lock, or invoke some other function which does a
SETLOCK RELEASE for the CPU lock or a spin lock, that may cause
SETLOCK RELEASE to enable. SETLOCK RELEASE for the CPU lock
or a spin lock will enable if
34 matches
Mail list logo
