Principles of Operation

fsword7

Oct 17, 2002

Hello folks:

I have two POO manuals about System/360 and zArch. I was looking
for 370 and 390 POO manuals through IBM library but ended up zArch
POO manual (PDF file). Does anyone have information about 370 and
390 POO manuals?

I have a question for you. Will OS/360, MVS 3.8, DOS/VS, and VM/370
R6 work on latest zArch? If not, which processor? 370? 390?

Thank you!

-- Tim Stark

1:51 am

gah@...

Oct 17, 2002

Tim Stark wrote:

> I have two POO manuals about System/360 and zArch. I was looking
> for 370 and 390 POO manuals through IBM library but ended up zArch
> POO manual (PDF file). Does anyone have information about 370 and
> 390 POO manuals?

> I have a question for you. Will OS/360, MVS 3.8, DOS/VS, and VM/370
> R6 work on latest zArch? If not, which processor? 370? 390?

Most people who read this probably don't recognize your name. I have
read in other groups about your PDP-10, VAX, and other emulators.

Having learned S/370 Assembler before PDP-10, I found it easy
to learn to use the 10. Many of the addressing modes are similar,
though you do have to get used to the idea of a base register.
The PDP-10 has a relocation register so that all programs run
relative to virtual address 0. On S/360 and succussors, under most
OS, programs are not loaded at a fixed virtual address and must
be able to execute where they are loaded. (CMS always load at the
same virtual address.)

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

Is the IBM publications site.

S/370 Principles of Operation is still being sold, GA22-7000-10
for $11.25 plus tax. UPS ground shipping is included. It is a pretty
good sized book for that price.

370/XA is SA22-7085-1 for $33.50, again plus tax but shipping included.

ESA/370, SA22-7200-00 for $41.06.

ESA/390, SA22-7201-07 for $32.25, also available in BookManager
or PDF format for download. This is over 1000 pages of 8.5x11 paper,
and again plus tax but shipping included.

ESA/390, slightly older version, SA22-7201-06 is only $14.75, less
than half the price for almost the same thing. Also, these are
bound paperback books, not loose-leaf like many of the older manuals.

Good luck!

-- glen

10:09 pm

Re: Principles of Operation

Jay Maynard

Oct 17, 2002

On Thu, Oct 17, 2002 at 03:09:33PM -0700, gah@... wrote:
> Tim Stark wrote:
> > I have a question for you. Will OS/360, MVS 3.8, DOS/VS, and VM/370
> > R6 work on latest zArch? If not, which processor? 370? 390?

All of these must run in 370 mode; aside from possibly a P/390 (one of
these days, I must see about trying to get them to run on mine), Hercules is
the only system you're likely to be able to find that will run them.

> Most people who read this probably don't recognize your name. I have
> read in other groups about your PDP-10, VAX, and other emulators.

I sure didn't. Welcome, Tim!

11:01 pm

Re: Principles of Operation

fsword7

Oct 21, 2002

--- In hercules-390@y..., gah@u... wrote:
> Having learned S/370 Assembler before PDP-10, I found it easy
> to learn to use the 10. Many of the addressing modes are similar,
> though you do have to get used to the idea of a base register.
> The PDP-10 has a relocation register so that all programs run
> relative to virtual address 0. On S/360 and succussors, under most
> OS, programs are not loaded at a fixed virtual address and must
> be able to execute where they are loaded. (CMS always load at the
> same virtual address.)

Yeah. It is more easy to learn how to use PDP-10 because PDP-10
assembly language is more simple. Later PDP-10 now has pager
and many programs always start at virtual address 0.

Yes, I am developing my TS10 emulator that emulates PDP-10, PDP-11,
and VAX systems. I successfully booted TOPS-10/20 and OpenVMS on it.

Ok thank for a listing of POO manuals. I was able find them execpt
one (370-XA). It gave me error message with wrong product number.
Now I have a copy of ESA/390 POO manual (PDF file). Is S/370, 370-
XA, and ESA/370 are compitable with ESA/390 architecture? If not, I
will order them soon.

About 370-XA, I believe that it is extended address feature with 2K
or 4K paging right?

What is difference between S/370, 370-XA, ESA/370, and ESA/390?

Thank you!

Tim Stark

3:00 am

Re: Principles of Operation

John Alvord

Oct 21, 2002

On Mon, 21 Oct 2002 03:00:40 -0000, "fsword7" <sword7@...>
wrote:

>--- In hercules-390@y..., gah@u... wrote:
>> Having learned S/370 Assembler before PDP-10, I found it easy
>> to learn to use the 10. Many of the addressing modes are similar,
>> though you do have to get used to the idea of a base register.
>> The PDP-10 has a relocation register so that all programs run
>> relative to virtual address 0. On S/360 and succussors, under most
>> OS, programs are not loaded at a fixed virtual address and must
>> be able to execute where they are loaded. (CMS always load at the
>> same virtual address.)
>
>Yeah. It is more easy to learn how to use PDP-10 because PDP-10
>assembly language is more simple. Later PDP-10 now has pager
>and many programs always start at virtual address 0.
>
>Yes, I am developing my TS10 emulator that emulates PDP-10, PDP-11,
>and VAX systems. I successfully booted TOPS-10/20 and OpenVMS on it.
>
>Ok thank for a listing of POO manuals. I was able find them execpt
>one (370-XA). It gave me error message with wrong product number.
>Now I have a copy of ESA/390 POO manual (PDF file). Is S/370, 370-
>XA, and ESA/370 are compitable with ESA/390 architecture? If not, I
>will order them soon.
>
>About 370-XA, I believe that it is extended address feature with 2K
>or 4K paging right?
>
>What is difference between S/370, 370-XA, ESA/370, and ESA/390?
>

S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
addressing. But there are scores of differences, mostly downward
compatible, at each level.... new features, new instructions, etc.

john

7:08 am

Re: Principles of Operation

Greg Price

Oct 21, 2002

On Mon, 21 Oct 2002 00:08:34 -0700, John Alvord wrote:

>>
>>What is difference between S/370, 370-XA, ESA/370, and ESA/390?
>>
>
>S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
>addressing. But there are scores of differences, mostly downward
>compatible, at each level.... new features, new instructions, etc.
>
>john

Actually, I think the biggest change brought in by XA was the new
I/O architecture. I believe it was needed to remove the bottleneck
of funnelling every I/O through specific locations in fixed low core
(PSA). The XA way of I/O has carried though to z/OS.

A smaller change was the new 31-bit addressing mode. However, since
the OS takes care of the low-level I/O management, 31-bit addressing
became the change that occupied most programmers' time.

So, if you are a programmer moving your software up to XA, 31-bit
stuff is the big issue.

If you are designing a compatible processor or updating an emulator
for XA the new I/O architecture will require greater conceptual change.

(As implied by John above, XA did away with 2K pages.
Segments became 1MB instead of 64KB.)

Well, that's my theory, anyway....

Cheers,
Greg P.

7:43 am

Re: Re: Principles of Operation

Jay Maynard

Oct 21, 2002

On Mon, Oct 21, 2002 at 03:00:40AM -0000, fsword7 wrote:
> Yes, I am developing my TS10 emulator that emulates PDP-10, PDP-11,
> and VAX systems. I successfully booted TOPS-10/20 and OpenVMS on it.

I might have to try that...Will your VAX emulator run NetBSD? If so, there's
a whole new level of emulation fun we can have: Hercules under NetBSD on
your emulator under some other OS...

> Ok thank for a listing of POO manuals. I was able find them execpt
> one (370-XA). It gave me error message with wrong product number.
> Now I have a copy of ESA/390 POO manual (PDF file). Is S/370, 370-
> XA, and ESA/370 are compitable with ESA/390 architecture? If not, I
> will order them soon.

370/XA and ESA/370 are, I believe, proper subsets of ESA/390. There's a
chapter in the ESA/390 POO that lists the things added at each level.

S/370, OTOH, is not. There are quite a few differences.

> About 370-XA, I believe that it is extended address feature with 2K
> or 4K paging right?

370/XA is basically ESA/390 without the access register facility. ARs can be
viewed as adding a memory segment address to each general register, with 2
GB segments. (At least that's how I got my head around it when it was first
announced.)

> What is difference between S/370, 370-XA, ESA/370, and ESA/390?

As Greg Price said, the real difference between S/370 and 370/XA was in the
I/O subsystem. In S/370, I/Os are directed to one of (potentially) 16
channels, with a parameter that told the channel which device the operation
was directed to. As Greg mentioned, that became a bottleneck, as well as
being more complicated than necessary. 370/XA moved that layer of complexity
out to the hardware, and all a program had to specify was a device number to
which the I/O should be sent.

The other, more visible difference is in the addressing. In S/360, addresses
were 24 bits long. When virtual addressing was added to make S/370, the
address was split into three pieces, referred to as segment, page, and byte.
The size of the segment and page parts were selected by two bits in a
control register; segments could be either 1 MB or 64 KB, while pages could
be either 2 or 4 KB. I don't know why they did this, nor do I know why
different OSes selected different sizes. (AFAIK, no 370 OS used 1 MB
segments; DOS/VS and (IIRC? Help?) VS/1 used 2K pages, and VM/370 and MVS
used 4K pages.) 370/XA did away with 64K segments and 2K pages, and if you
set the control register to try to use those sizes, you get a specifiacation
check.

There's one more difference: Late in the life of S/370, when the 3033 CPU
was introduced (1978 or so), they added the S/370 Extended Facility. As well
as allowing access to two address spaces at once, a few other changes were
made, including a change in the size of a storage block protected by one
storage key. The original S/360 implemented 2 KB blocks, and this was
originally carried forward to S/370. The extended facility changed this
block size to 4 KB. This is mainly significant because all of the public
domain IBM OSes expect 2K blocks and break mysteriously if the system
implements a 4K block size.

9:01 am

Re: Principles of Operation

Hall, Ken

Oct 21, 2002

I'd be more inclined to go with 31 bit virtual as the big selling point,
although the I/O changes were important too. They moved control of path
management to the microcode, making dynamic multiple
path I/O support workable. The original name for it was "Queueing in channel",
since you'd start an I/O operation and let the microcode worry about how and
when it got done.

I don't remember any "low core" limitation. Each I/O operation was (still is)
hung on a control block called a UCB, one per device. The only thing that
changed is that instead of starting a channel
program on a device via a particular path, you start it on an abstraction called
a "subchannel", which is assigned through the IOCP process.

Originally, if you had multiple channels defined for a device (at first, DASD
was the only kind of device you could do this with, although 3480 tape drives
came later), the OS would decide which
channel to use based on which was free at the time. But an I/O operation isn't
all one function. You can start a seek, release the channel, and have an
interrupt come back when it's done. Then you
start the transfer. Problem was, if you started a seek on a channel, and then
disconnected, that channel might be busy actually transferring data for someone
else when it came time for the interrupt
to come back, so you waited, even if there were other channels available to the
same device. "Dynamic path selection", which appeared in XA with the first IOCP
mechanism, allows the interrupt to come
back on any path connected to the device. Then you got into issues like how
many internal paths a string of 3380's had, depending on configuration. A
properly configured string of 3380's or 3390's
could do four simultaneous data transfers from any four devices in the string.
Current "virtual" DASD devices can do even more, but still suffer from internal
pathing limitations.

On overview, (if I recall correctly), the various versions went something like
this:

MVS SP1 - Repackaged MVS 3.8J plus SE feature and other options, as a
billable product
MVS XA (SP2) - 31 bit addressing and IOCP (path management in microcode, as
above)
ESA-V1 (SP3 - Dataspaces and hiperspaces, expanded storage
ESA-V2 (SP4) - Dynamic reconfiguration (might have been in SP3), ESCON, System
Managed Storage
ESA-V3 (SP5) - Open edition as an option (later standard), Basic SYSPLEX (via
CTC),
parallel SYSPLEX later
OS/390 V1 (SP6) - Repackaging, Open Edition enhancements, more parallel SYSPLEX
features
OS/390 V2 (SP7) - Beginning of 64 bit real storage support as an option, 9672
support,
IP networking integrated with OE (now called USS)
zOS V1.1 - Another repackaging, basically OS/390 2.10 with new label
zOS V1.2 - Required 64 bit, removal of legacy code
zOS V1.3 - Additional 64 bit support, removal of more legacy code, additional
dynamic reconfig options, lots of Internet-related stuff and security
changes

Basically, the various "major" versions went with various processor offerings.
Each version of hardware and software would overlap with each other to provide a
relatively seamless migration path,
where you never had to upgrade both hardware and software at once.

For example:

303x-308x - SP1-SP2 (high end 4381's also supported XA)
308x-309x - SP1-SP4 (later 3090 models supported ESCON)
309x-9x21 - SP2-SP6 (later 9021's supported coupling links)
9x21-9672 - SP4-SP7
9672-2064 - SP7-zOS

Current zOS versions require a 9672 "G5" or better. This was the cause for a
minor revolt among users a couple of years ago, since it basically rendered most
of the water cooled boxen (and even some
fairly recent vintage 9672's) still floating around the leasing market obsolete.
IBM tried to use Y2K as a breakpoint to force everyone to new hardware and
software, and was mostly successful.

> -----Original Message-----
> From: Greg Price [mailto:greg.price@...]
> Sent: Monday, October 21, 2002 3:43 AM
> To: hercules-390@yahoogroups.com
> Subject: Re: [hercules-390] Re: Principles of Operation
>
>
> On Mon, 21 Oct 2002 00:08:34 -0700, John Alvord wrote:
>
> >>
> >>What is difference between S/370, 370-XA, ESA/370, and ESA/390?
> >>
> >
> >S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
> >addressing. But there are scores of differences, mostly downward
> >compatible, at each level.... new features, new instructions, etc.
> >
> >john
>
> Actually, I think the biggest change brought in by XA was the new
> I/O architecture. I believe it was needed to remove the bottleneck
> of funnelling every I/O through specific locations in fixed low core
> (PSA). The XA way of I/O has carried though to z/OS.
>
> A smaller change was the new 31-bit addressing mode. However, since
> the OS takes care of the low-level I/O management, 31-bit addressing
> became the change that occupied most programmers' time.
>
> So, if you are a programmer moving your software up to XA, 31-bit
> stuff is the big issue.
>
> If you are designing a compatible processor or updating an emulator
> for XA the new I/O architecture will require greater
> conceptual change.
>
> (As implied by John above, XA did away with 2K pages.
> Segments became 1MB instead of 64KB.)
>
> Well, that's my theory, anyway....
>
> Cheers,
> Greg P.
>
>
>

2:21 pm

Re: Principles of Operation

Mark Perry

Oct 21, 2002

Hi Ken,
z/OS 1.2 does not "require" 64bit support - I have it running fine on a G5
and z/OS 1.3 too. I have z/OS 1.4 running on a G7 (z900) but I think that
that too may run on a G5. The next release z/OS 1.5 will I believe require
zArchitecture as a minimum hardware level.

I just checked the Installation planning Guide to confirm what I just said
is true - see http://publibz.boulder.ibm.com/epubs/pdf/e0z2b131.pdf

Identifying processor (server) requirements

z/OS V1R4 runs on all IBM Eserver zSeries servers, which are:

v IBM 2066 Eserver zSeries 800 (z800).

v IBM 2064 Eserver zSeries 900 (z900).

v IBM 7060 S/390 Multiprise 3000 Enterprise Server.

v IBM 9672 S/390 Parallel Enterprise Server - Generation 5 (G5) and
Generation

6 (G6). Driver 26 (licensed internal code version 1.6.2) or later is
required to

support architectural enhancements required by z/OS, which are shown below.

In the future: z/OS V1R5 is planned to run on the same IBM servers as z/OS

V1R4. However, many functions of z/OS V1R5 will not be available when
running

on older technology servers, specifically, the G5, G6, and Multiprise 3000
servers.

z/OS.e V1R4 runs on the following IBM server:

v IBM 2066 Eserver zSeries 800 (z800). The z800 must run in LPAR mode (not

basic mode).

Ciao
Mark
-----Original Message-----
From: Hall, Ken (ECSS) [mailto:KeHall@...]
Sent: 21 October 2002 16:22
To: 'hercules-390@yahoogroups.com'
Subject: RE: [hercules-390] Re: Principles of Operation

I'd be more inclined to go with 31 bit virtual as the big selling point,
although the I/O changes were important too. They moved control of path
management to the microcode, making dynamic multiple
path I/O support workable. The original name for it was "Queueing in
channel", since you'd start an I/O operation and let the microcode worry
about how and when it got done.

I don't remember any "low core" limitation. Each I/O operation was (still
is) hung on a control block called a UCB, one per device. The only thing
that changed is that instead of starting a channel
program on a device via a particular path, you start it on an abstraction
called a "subchannel", which is assigned through the IOCP process.

Originally, if you had multiple channels defined for a device (at first,
DASD was the only kind of device you could do this with, although 3480 tape
drives came later), the OS would decide which
channel to use based on which was free at the time. But an I/O operation
isn't all one function. You can start a seek, release the channel, and have
an interrupt come back when it's done. Then you
start the transfer. Problem was, if you started a seek on a channel, and
then disconnected, that channel might be busy actually transferring data for
someone else when it came time for the interrupt
to come back, so you waited, even if there were other channels available
to the same device. "Dynamic path selection", which appeared in XA with the
first IOCP mechanism, allows the interrupt to come
back on any path connected to the device. Then you got into issues like
how many internal paths a string of 3380's had, depending on configuration.
A properly configured string of 3380's or 3390's
could do four simultaneous data transfers from any four devices in the
string. Current "virtual" DASD devices can do even more, but still suffer
from internal pathing limitations.

On overview, (if I recall correctly), the various versions went something
like this:

MVS SP1 - Repackaged MVS 3.8J plus SE feature and other
options, as a
billable product
MVS XA (SP2) - 31 bit addressing and IOCP (path management in
microcode, as above)
ESA-V1 (SP3 - Dataspaces and hiperspaces, expanded storage
ESA-V2 (SP4) - Dynamic reconfiguration (might have been in SP3),
ESCON, System
Managed Storage
ESA-V3 (SP5) - Open edition as an option (later standard), Basic
SYSPLEX (via CTC),
parallel SYSPLEX later
OS/390 V1 (SP6) - Repackaging, Open Edition enhancements, more
parallel SYSPLEX features
OS/390 V2 (SP7) - Beginning of 64 bit real storage support as an
option, 9672 support,
IP networking integrated with OE (now called USS)
zOS V1.1 - Another repackaging, basically OS/390 2.10 with new
label
zOS V1.2 - Required 64 bit, removal of legacy code
zOS V1.3 - Additional 64 bit support, removal of more legacy
code, additional
dynamic reconfig options, lots of Internet-related stuff
and security
changes

Basically, the various "major" versions went with various processor
offerings. Each version of hardware and software would overlap with each
other to provide a relatively seamless migration path,
where you never had to upgrade both hardware and software at once.

For example:

303x-308x - SP1-SP2 (high end 4381's also supported XA)
308x-309x - SP1-SP4 (later 3090 models supported ESCON)
309x-9x21 - SP2-SP6 (later 9021's supported coupling links)
9x21-9672 - SP4-SP7
9672-2064 - SP7-zOS

Current zOS versions require a 9672 "G5" or better. This was the cause
for a minor revolt among users a couple of years ago, since it basically
rendered most of the water cooled boxen (and even some
fairly recent vintage 9672's) still floating around the leasing market
obsolete. IBM tried to use Y2K as a breakpoint to force everyone to new
hardware and software, and was mostly successful.

> -----Original Message-----
> From: Greg Price [mailto:greg.price@...]
> Sent: Monday, October 21, 2002 3:43 AM
> To: hercules-390@yahoogroups.com
> Subject: Re: [hercules-390] Re: Principles of Operation
>
>
> On Mon, 21 Oct 2002 00:08:34 -0700, John Alvord wrote:
>
> >>
> >>What is difference between S/370, 370-XA, ESA/370, and ESA/390?
> >>
> >
> >S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
> >addressing. But there are scores of differences, mostly downward
> >compatible, at each level.... new features, new instructions, etc.
> >
> >john
>
> Actually, I think the biggest change brought in by XA was the new
> I/O architecture. I believe it was needed to remove the bottleneck
> of funnelling every I/O through specific locations in fixed low core
> (PSA). The XA way of I/O has carried though to z/OS.
>
> A smaller change was the new 31-bit addressing mode. However, since
> the OS takes care of the low-level I/O management, 31-bit addressing
> became the change that occupied most programmers' time.
>
> So, if you are a programmer moving your software up to XA, 31-bit
> stuff is the big issue.
>
> If you are designing a compatible processor or updating an emulator
> for XA the new I/O architecture will require greater
> conceptual change.
>
> (As implied by John above, XA did away with 2K pages.
> Segments became 1MB instead of 64KB.)
>
> Well, that's my theory, anyway....
>
> Cheers,
> Greg P.
>
>
>

Yahoo! Groups Sponsor
ADVERTISEMENT

Community email addresses:
Post message: hercules-390@yahoogroups.com
Subscribe: hercules-390-subscribe@yahoogroups.com
Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
List owner: hercules-390-owner@yahoogroups.com

Files and archives at:
http://groups.yahoo.com/group/hercules-390

Get the latest version of Hercules from:
http://www.conmicro.cx/hercules

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Non-text portions of this message have been removed]

5:23 pm

Re: Principles of Operation

Hall, Ken

Oct 21, 2002

Yeah, technically you're right. It's a fine point. (I knew this was gonna come
up.)

Under the licensing rules, if you HAVE 64-bit capable hardware, you HAVE to run
in 64 bit mode. This has been the case since 1.1. But they are still providing
that overlap upgrade path I mentioned
for now.

It appears they even took out the ARCHMODE option in LOADxx on 1.3 because the
last time I tested, it got flagged as an error.

We're in a similar situation here. Our production boxes are 2064's, but our
Disaster recovery boxes are G6's. We don't expect to get away with this much
longer.

> -----Original Message-----
> From: Mark Perry [mailto:mark.perry@...]
> Sent: Monday, October 21, 2002 1:24 PM
> To: hercules-390@yahoogroups.com
> Subject: RE: [hercules-390] Re: Principles of Operation
>
>
> Hi Ken,
> z/OS 1.2 does not "require" 64bit support - I have it running
> fine on a G5
> and z/OS 1.3 too. I have z/OS 1.4 running on a G7 (z900) but
> I think that
> that too may run on a G5. The next release z/OS 1.5 will I
> believe require
> zArchitecture as a minimum hardware level.
>
>
> I just checked the Installation planning Guide to confirm
> what I just said
> is true - see http://publibz.boulder.ibm.com/epubs/pdf/e0z2b131.pdf
>
>
>
> Identifying processor (server) requirements
>
> z/OS V1R4 runs on all IBM Eserver zSeries servers, which are:
>
> v IBM 2066 Eserver zSeries 800 (z800).
>
> v IBM 2064 Eserver zSeries 900 (z900).
>
> v IBM 7060 S/390 Multiprise 3000 Enterprise Server.
>
> v IBM 9672 S/390 Parallel Enterprise Server - Generation 5 (G5) and
> Generation
>
> 6 (G6). Driver 26 (licensed internal code version 1.6.2) or later is
> required to
>
> support architectural enhancements required by z/OS, which
> are shown below.
>
> In the future: z/OS V1R5 is planned to run on the same IBM
> servers as z/OS
>
> V1R4. However, many functions of z/OS V1R5 will not be available when
> running
>
> on older technology servers, specifically, the G5, G6, and
> Multiprise 3000
> servers.
>
> z/OS.e V1R4 runs on the following IBM server:
>
> v IBM 2066 Eserver zSeries 800 (z800). The z800 must run in
> LPAR mode (not
>
> basic mode).
>
>
>
>
>
> Ciao
> Mark
> -----Original Message-----
> From: Hall, Ken (ECSS) [mailto:KeHall@...]
> Sent: 21 October 2002 16:22
> To: 'hercules-390@yahoogroups.com'
> Subject: RE: [hercules-390] Re: Principles of Operation
>
>
> I'd be more inclined to go with 31 bit virtual as the big
> selling point,
> although the I/O changes were important too. They moved
> control of path
> management to the microcode, making dynamic multiple
> path I/O support workable. The original name for it was
> "Queueing in
> channel", since you'd start an I/O operation and let the
> microcode worry
> about how and when it got done.
>
> I don't remember any "low core" limitation. Each I/O
> operation was (still
> is) hung on a control block called a UCB, one per device. The
> only thing
> that changed is that instead of starting a channel
> program on a device via a particular path, you start it on
> an abstraction
> called a "subchannel", which is assigned through the IOCP process.
>
> Originally, if you had multiple channels defined for a
> device (at first,
> DASD was the only kind of device you could do this with,
> although 3480 tape
> drives came later), the OS would decide which
> channel to use based on which was free at the time. But an
> I/O operation
> isn't all one function. You can start a seek, release the
> channel, and have
> an interrupt come back when it's done. Then you
> start the transfer. Problem was, if you started a seek on
> a channel, and
> then disconnected, that channel might be busy actually
> transferring data for
> someone else when it came time for the interrupt
> to come back, so you waited, even if there were other
> channels available
> to the same device. "Dynamic path selection", which appeared
> in XA with the
> first IOCP mechanism, allows the interrupt to come
> back on any path connected to the device. Then you got
> into issues like
> how many internal paths a string of 3380's had, depending on
> configuration.
> A properly configured string of 3380's or 3390's
> could do four simultaneous data transfers from any four
> devices in the
> string. Current "virtual" DASD devices can do even more, but
> still suffer
> from internal pathing limitations.
>
> On overview, (if I recall correctly), the various versions
> went something
> like this:
>
> MVS SP1 - Repackaged MVS 3.8J plus SE feature and other
> options, as a
> billable product
> MVS XA (SP2) - 31 bit addressing and IOCP (path management in
> microcode, as above)
> ESA-V1 (SP3 - Dataspaces and hiperspaces,
> expanded storage
> ESA-V2 (SP4) - Dynamic reconfiguration (might have
> been in SP3),
> ESCON, System
> Managed Storage
> ESA-V3 (SP5) - Open edition as an option (later
> standard), Basic
> SYSPLEX (via CTC),
> parallel SYSPLEX later
> OS/390 V1 (SP6) - Repackaging, Open Edition enhancements, more
> parallel SYSPLEX features
> OS/390 V2 (SP7) - Beginning of 64 bit real storage
> support as an
> option, 9672 support,
> IP networking integrated with OE (now called USS)
> zOS V1.1 - Another repackaging, basically OS/390
> 2.10 with new
> label
> zOS V1.2 - Required 64 bit, removal of legacy code
> zOS V1.3 - Additional 64 bit support, removal of
> more legacy
> code, additional
> dynamic reconfig options, lots of
> Internet-related stuff
> and security
> changes
>
> Basically, the various "major" versions went with various processor
> offerings. Each version of hardware and software would
> overlap with each
> other to provide a relatively seamless migration path,
> where you never had to upgrade both hardware and software at once.
>
> For example:
>
> 303x-308x - SP1-SP2 (high end 4381's also supported XA)
> 308x-309x - SP1-SP4 (later 3090 models supported ESCON)
> 309x-9x21 - SP2-SP6 (later 9021's supported coupling links)
> 9x21-9672 - SP4-SP7
> 9672-2064 - SP7-zOS
>
> Current zOS versions require a 9672 "G5" or better. This
> was the cause
> for a minor revolt among users a couple of years ago, since
> it basically
> rendered most of the water cooled boxen (and even some
> fairly recent vintage 9672's) still floating around the
> leasing market
> obsolete. IBM tried to use Y2K as a breakpoint to force
> everyone to new
> hardware and software, and was mostly successful.
>
>
>
> > -----Original Message-----
> > From: Greg Price [mailto:greg.price@...]
> > Sent: Monday, October 21, 2002 3:43 AM
> > To: hercules-390@yahoogroups.com
> > Subject: Re: [hercules-390] Re: Principles of Operation
> >
> >
> > On Mon, 21 Oct 2002 00:08:34 -0700, John Alvord wrote:
> >
> > >>
> > >>What is difference between S/370, 370-XA, ESA/370, and ESA/390?
> > >>
> > >
> > >S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
> > >addressing. But there are scores of differences, mostly downward
> > >compatible, at each level.... new features, new
> instructions, etc.
> > >
> > >john
> >
> > Actually, I think the biggest change brought in by XA was the new
> > I/O architecture. I believe it was needed to remove the
> bottleneck
> > of funnelling every I/O through specific locations in
> fixed low core
> > (PSA). The XA way of I/O has carried though to z/OS.
> >
> > A smaller change was the new 31-bit addressing mode.
> However, since
> > the OS takes care of the low-level I/O management, 31-bit
> addressing
> > became the change that occupied most programmers' time.
> >
> > So, if you are a programmer moving your software up to XA, 31-bit
> > stuff is the big issue.
> >
> > If you are designing a compatible processor or updating
> an emulator
> > for XA the new I/O architecture will require greater
> > conceptual change.
> >
> > (As implied by John above, XA did away with 2K pages.
> > Segments became 1MB instead of 64KB.)
> >
> > Well, that's my theory, anyway....
> >
> > Cheers,
> > Greg P.
> >
> >
> >
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
>
>
>
> Community email addresses:
> Post message: hercules-390@yahoogroups.com
> Subscribe: hercules-390-subscribe@yahoogroups.com
> Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> List owner: hercules-390-owner@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.conmicro.cx/hercules
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W4wwlB/TM
> --------------------------------------------------------------
> -------~->
>
> Community email addresses:
> Post message: hercules-390@yahoogroups.com
> Subscribe: hercules-390-subscribe@yahoogroups.com
> Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> List owner: hercules-390-owner@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.conmicro.cx/hercules
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

5:56 pm

Re: Principles of Operation

fsword7

Oct 21, 2002

--- In hercules-390@y..., Jay Maynard <jmaynard@c...> wrote:
> I might have to try that...Will your VAX emulator run NetBSD? If
so, there's
> a whole new level of emulation fun we can have: Hercules under
NetBSD on
> your emulator under some other OS...

Yes, my ts10 (MicroVAX 3900) emulator supports NetBSD 1.6 as well.
I tried test it before. It requires Linux or FreeBSD to run ts10
emulator.

> 370/XA and ESA/370 are, I believe, proper subsets of ESA/390.
There's a
> chapter in the ESA/390 POO that lists the things added at each
level.
>
> S/370, OTOH, is not. There are quite a few differences.

Yeah. I read almost entire 1000-pages ESA/390 POO manual (PDF file)
and found information at end of the POO manual show differences
between S/370, 370-XA, and ESA/370. They are downward-compitable.
They show new features and new instructions each level.

370/390 series has 64-bit PSW status register. S/360 has different
PSW status register. Latest z/Architecture has 128-bit PSW status
register. 370 and 390 series have almost same 64-bit PSW status
register. 370-XA and later now has paging system with protection
modes.

I did not see any access mode like kernel, executive, supervisor,
and user mode that can be found in DEC/Intel systems. Hmmm. Do
they uses multi-ring level access mode?

Well, I have everything about POO manuals from S/360 to
z/Architecture.

Does anyone have information about Linux/390 system? I am
interested in that.

Thank you for your help!

Tim Stark

11:15 pm

Re: Principles of Operation

Steve Oswald

Oct 21, 2002

See
http://www-1.ibm.com/servers/eserver/zseries/zos/installation/bimodal.html.

They have also provided for z/OS bimodal support 2064/2066 on a limited basis.
The caveat is that you must covert to 64bit mode within 6 months.

Regards,
Steve Oswald

On Monday 21 October 2002 05:56 pm, Hall, Ken (ECSS) wrote:
> Yeah, technically you're right. It's a fine point. (I knew this was gonna
> come up.)
>
> Under the licensing rules, if you HAVE 64-bit capable hardware, you HAVE to
> run in 64 bit mode. This has been the case since 1.1. But they are still
> providing that overlap upgrade path I mentioned for now.
>
> It appears they even took out the ARCHMODE option in LOADxx on 1.3 because
> the last time I tested, it got flagged as an error.
>
> We're in a similar situation here. Our production boxes are 2064's, but
> our Disaster recovery boxes are G6's. We don't expect to get away with
> this much longer.
>
> > -----Original Message-----
> > From: Mark Perry [mailto:mark.perry@...]
> > Sent: Monday, October 21, 2002 1:24 PM
> > To: hercules-390@yahoogroups.com
> > Subject: RE: [hercules-390] Re: Principles of Operation
> >
> >
> > Hi Ken,
> > z/OS 1.2 does not "require" 64bit support - I have it running
> > fine on a G5
> > and z/OS 1.3 too. I have z/OS 1.4 running on a G7 (z900) but
> > I think that
> > that too may run on a G5. The next release z/OS 1.5 will I
> > believe require
> > zArchitecture as a minimum hardware level.
> >
> >
> > I just checked the Installation planning Guide to confirm
> > what I just said
> > is true - see http://publibz.boulder.ibm.com/epubs/pdf/e0z2b131.pdf
> >
> >
> >
> > Identifying processor (server) requirements
> >
> > z/OS V1R4 runs on all IBM Eserver zSeries servers, which are:
> >
> > v IBM 2066 Eserver zSeries 800 (z800).
> >
> > v IBM 2064 Eserver zSeries 900 (z900).
> >
> > v IBM 7060 S/390 Multiprise 3000 Enterprise Server.
> >
> > v IBM 9672 S/390 Parallel Enterprise Server - Generation 5 (G5) and
> > Generation
> >
> > 6 (G6). Driver 26 (licensed internal code version 1.6.2) or later is
> > required to
> >
> > support architectural enhancements required by z/OS, which
> > are shown below.
> >
> > In the future: z/OS V1R5 is planned to run on the same IBM
> > servers as z/OS
> >
> > V1R4. However, many functions of z/OS V1R5 will not be available when
> > running
> >
> > on older technology servers, specifically, the G5, G6, and
> > Multiprise 3000
> > servers.
> >
> > z/OS.e V1R4 runs on the following IBM server:
> >
> > v IBM 2066 Eserver zSeries 800 (z800). The z800 must run in
> > LPAR mode (not
> >
> > basic mode).
> >
> >
> >
> >
> >
> > Ciao
> > Mark
> > -----Original Message-----
> > From: Hall, Ken (ECSS) [mailto:KeHall@...]
> > Sent: 21 October 2002 16:22
> > To: 'hercules-390@yahoogroups.com'
> > Subject: RE: [hercules-390] Re: Principles of Operation
> >
> >
> > I'd be more inclined to go with 31 bit virtual as the big
> > selling point,
> > although the I/O changes were important too. They moved
> > control of path
> > management to the microcode, making dynamic multiple
> > path I/O support workable. The original name for it was
> > "Queueing in
> > channel", since you'd start an I/O operation and let the
> > microcode worry
> > about how and when it got done.
> >
> > I don't remember any "low core" limitation. Each I/O
> > operation was (still
> > is) hung on a control block called a UCB, one per device. The
> > only thing
> > that changed is that instead of starting a channel
> > program on a device via a particular path, you start it on
> > an abstraction
> > called a "subchannel", which is assigned through the IOCP process.
> >
> > Originally, if you had multiple channels defined for a
> > device (at first,
> > DASD was the only kind of device you could do this with,
> > although 3480 tape
> > drives came later), the OS would decide which
> > channel to use based on which was free at the time. But an
> > I/O operation
> > isn't all one function. You can start a seek, release the
> > channel, and have
> > an interrupt come back when it's done. Then you
> > start the transfer. Problem was, if you started a seek on
> > a channel, and
> > then disconnected, that channel might be busy actually
> > transferring data for
> > someone else when it came time for the interrupt
> > to come back, so you waited, even if there were other
> > channels available
> > to the same device. "Dynamic path selection", which appeared
> > in XA with the
> > first IOCP mechanism, allows the interrupt to come
> > back on any path connected to the device. Then you got
> > into issues like
> > how many internal paths a string of 3380's had, depending on
> > configuration.
> > A properly configured string of 3380's or 3390's
> > could do four simultaneous data transfers from any four
> > devices in the
> > string. Current "virtual" DASD devices can do even more, but
> > still suffer
> > from internal pathing limitations.
> >
> > On overview, (if I recall correctly), the various versions
> > went something
> > like this:
> >
> > MVS SP1 - Repackaged MVS 3.8J plus SE feature and other
> > options, as a
> > billable product
> > MVS XA (SP2) - 31 bit addressing and IOCP (path management in
> > microcode, as above)
> > ESA-V1 (SP3 - Dataspaces and hiperspaces,
> > expanded storage
> > ESA-V2 (SP4) - Dynamic reconfiguration (might have
> > been in SP3),
> > ESCON, System
> > Managed Storage
> > ESA-V3 (SP5) - Open edition as an option (later
> > standard), Basic
> > SYSPLEX (via CTC),
> > parallel SYSPLEX later
> > OS/390 V1 (SP6) - Repackaging, Open Edition enhancements, more
> > parallel SYSPLEX features
> > OS/390 V2 (SP7) - Beginning of 64 bit real storage
> > support as an
> > option, 9672 support,
> > IP networking integrated with OE (now called USS)
> > zOS V1.1 - Another repackaging, basically OS/390
> > 2.10 with new
> > label
> > zOS V1.2 - Required 64 bit, removal of legacy code
> > zOS V1.3 - Additional 64 bit support, removal of
> > more legacy
> > code, additional
> > dynamic reconfig options, lots of
> > Internet-related stuff
> > and security
> > changes
> >
> > Basically, the various "major" versions went with various processor
> > offerings. Each version of hardware and software would
> > overlap with each
> > other to provide a relatively seamless migration path,
> > where you never had to upgrade both hardware and software at once.
> >
> > For example:
> >
> > 303x-308x - SP1-SP2 (high end 4381's also supported XA)
> > 308x-309x - SP1-SP4 (later 3090 models supported ESCON)
> > 309x-9x21 - SP2-SP6 (later 9021's supported coupling links)
> > 9x21-9672 - SP4-SP7
> > 9672-2064 - SP7-zOS
> >
> > Current zOS versions require a 9672 "G5" or better. This
> > was the cause
> > for a minor revolt among users a couple of years ago, since
> > it basically
> > rendered most of the water cooled boxen (and even some
> > fairly recent vintage 9672's) still floating around the
> > leasing market
> > obsolete. IBM tried to use Y2K as a breakpoint to force
> > everyone to new
> > hardware and software, and was mostly successful.
> >
> > > -----Original Message-----
> > > From: Greg Price [mailto:greg.price@...]
> > > Sent: Monday, October 21, 2002 3:43 AM
> > > To: hercules-390@yahoogroups.com
> > > Subject: Re: [hercules-390] Re: Principles of Operation
> > >
> > > On Mon, 21 Oct 2002 00:08:34 -0700, John Alvord wrote:
> > > >>What is difference between S/370, 370-XA, ESA/370, and ESA/390?
> > > >
> > > >S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
> > > >addressing. But there are scores of differences, mostly downward
> > > >compatible, at each level.... new features, new
> >
> > instructions, etc.
> >
> > > >john
> > >
> > > Actually, I think the biggest change brought in by XA was the new
> > > I/O architecture. I believe it was needed to remove the
> >
> > bottleneck
> >
> > > of funnelling every I/O through specific locations in
> >
> > fixed low core
> >
> > > (PSA). The XA way of I/O has carried though to z/OS.
> > >
> > > A smaller change was the new 31-bit addressing mode.
> >
> > However, since
> >
> > > the OS takes care of the low-level I/O management, 31-bit
> >
> > addressing
> >
> > > became the change that occupied most programmers' time.
> > >
> > > So, if you are a programmer moving your software up to XA, 31-bit
> > > stuff is the big issue.
> > >
> > > If you are designing a compatible processor or updating
> >
> > an emulator
> >
> > > for XA the new I/O architecture will require greater
> > > conceptual change.
> > >
> > > (As implied by John above, XA did away with 2K pages.
> > > Segments became 1MB instead of 64KB.)
> > >
> > > Well, that's my theory, anyway....
> > >
> > > Cheers,
> > > Greg P.
> >
> > Yahoo! Groups Sponsor
> > ADVERTISEMENT
> >
> >
> >
> >
> > Community email addresses:
> > Post message: hercules-390@yahoogroups.com
> > Subscribe: hercules-390-subscribe@yahoogroups.com
> > Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> > List owner: hercules-390-owner@yahoogroups.com
> >
> > Files and archives at:
> > http://groups.yahoo.com/group/hercules-390
> >
> > Get the latest version of Hercules from:
> > http://www.conmicro.cx/hercules
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-->
> > Get 128 Bit SSL Encryption!
> > http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W4wwlB/TM
> > --------------------------------------------------------------
> > -------~->
> >
> > Community email addresses:
> > Post message: hercules-390@yahoogroups.com
> > Subscribe: hercules-390-subscribe@yahoogroups.com
> > Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> > List owner: hercules-390-owner@yahoogroups.com
> >
> > Files and archives at:
> > http://groups.yahoo.com/group/hercules-390
> >
> > Get the latest version of Hercules from:
> > http://www.conmicro.cx/hercules
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
>
>
> Community email addresses:
> Post message: hercules-390@yahoogroups.com
> Subscribe: hercules-390-subscribe@yahoogroups.com
> Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> List owner: hercules-390-owner@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.conmicro.cx/hercules
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
Steven J. Oswald
Systems Consulting Engineer
OzTech Systems Consulting, Inc.
steve@...
Phone: (815) 337-1036
Cell: (815) 715-4065

6:27 pm

Re: Principles of Operation

Jay Maynard

Oct 21, 2002

On Mon, Oct 21, 2002 at 11:15:01PM -0000, fsword7 wrote:
> Yeah. I read almost entire 1000-pages ESA/390 POO manual (PDF file)
> and found information at end of the POO manual show differences
> between S/370, 370-XA, and ESA/370. They are downward-compitable.
> They show new features and new instructions each level.

More or less downward compatible. Problem programs (what you'll think of as
userland) writen for S/370 are generally runnable on ESA, but there are some
gotchas. System programs may or may not be.

> I did not see any access mode like kernel, executive, supervisor,
> and user mode that can be found in DEC/Intel systems. Hmmm. Do
> they uses multi-ring level access mode?

Not really. There are two different protection mechanisms on all of the IBM
mainframe systems. One is the system state, either supervisor or problem
(controlled by a bit in the PSW). Some instructions may only be executed in
supervisor state; in problem state, they produce a privileged operation
exception. The other is the storage protect key, controlled by 4 bits in the
PSW and by a 4-bit key associated with each block of storage (either 2K or
4K, as I discussed earlier). If the keys don't match, writes to that block
of storage fail with a protection exception; reads also fail if the fetch
protect bit is set for that block. The exception is that a PSW storage key
of 0 matches everything, and never fails.

> Does anyone have information about Linux/390 system? I am
> interested in that.

Matt? You're the expert... :-)

11:43 pm

Re: Principles of Operation

Hall, Ken

Oct 22, 2002

I had heard this was an unpopular situation, but I wasn't aware they had backed
off on it. Interesting.

> -----Original Message-----
> From: Steve Oswald [mailto:steve@...]
> Sent: Monday, October 21, 2002 2:28 PM
> To: hercules-390@yahoogroups.com
> Subject: Re: [hercules-390] Re: Principles of Operation
>
>
> See
> http://www-1.ibm.com/servers/eserver/zseries/zos/installation/
> bimodal.html.
>
> They have also provided for z/OS bimodal support 2064/2066 on
> a limited basis.
> The caveat is that you must covert to 64bit mode within 6 months.
>
> Regards,
> Steve Oswald
>
> On Monday 21 October 2002 05:56 pm, Hall, Ken (ECSS) wrote:
> > Yeah, technically you're right. It's a fine point. (I knew
> this was gonna
> > come up.)
> >
> > Under the licensing rules, if you HAVE 64-bit capable
> hardware, you HAVE to
> > run in 64 bit mode. This has been the case since 1.1. But
> they are still
> > providing that overlap upgrade path I mentioned for now.
> >
> > It appears they even took out the ARCHMODE option in LOADxx
> on 1.3 because
> > the last time I tested, it got flagged as an error.
> >
> > We're in a similar situation here. Our production boxes
> are 2064's, but
> > our Disaster recovery boxes are G6's. We don't expect to
> get away with
> > this much longer.
> >
> > > -----Original Message-----
> > > From: Mark Perry [mailto:mark.perry@...]
> > > Sent: Monday, October 21, 2002 1:24 PM
> > > To: hercules-390@yahoogroups.com
> > > Subject: RE: [hercules-390] Re: Principles of Operation
> > >
> > >
> > > Hi Ken,
> > > z/OS 1.2 does not "require" 64bit support - I have it running
> > > fine on a G5
> > > and z/OS 1.3 too. I have z/OS 1.4 running on a G7 (z900) but
> > > I think that
> > > that too may run on a G5. The next release z/OS 1.5 will I
> > > believe require
> > > zArchitecture as a minimum hardware level.
> > >
> > >
> > > I just checked the Installation planning Guide to confirm
> > > what I just said
> > > is true - see
> http://publibz.boulder.ibm.com/epubs/pdf/e0z2b131.pdf
> > >
> > >
> > >
> > > Identifying processor (server) requirements
> > >
> > > z/OS V1R4 runs on all IBM Eserver zSeries servers, which are:
> > >
> > > v IBM 2066 Eserver zSeries 800 (z800).
> > >
> > > v IBM 2064 Eserver zSeries 900 (z900).
> > >
> > > v IBM 7060 S/390 Multiprise 3000 Enterprise Server.
> > >
> > > v IBM 9672 S/390 Parallel Enterprise Server - Generation
> 5 (G5) and
> > > Generation
> > >
> > > 6 (G6). Driver 26 (licensed internal code version 1.6.2)
> or later is
> > > required to
> > >
> > > support architectural enhancements required by z/OS, which
> > > are shown below.
> > >
> > > In the future: z/OS V1R5 is planned to run on the same IBM
> > > servers as z/OS
> > >
> > > V1R4. However, many functions of z/OS V1R5 will not be
> available when
> > > running
> > >
> > > on older technology servers, specifically, the G5, G6, and
> > > Multiprise 3000
> > > servers.
> > >
> > > z/OS.e V1R4 runs on the following IBM server:
> > >
> > > v IBM 2066 Eserver zSeries 800 (z800). The z800 must run in
> > > LPAR mode (not
> > >
> > > basic mode).
> > >
> > >
> > >
> > >
> > >
> > > Ciao
> > > Mark
> > > -----Original Message-----
> > > From: Hall, Ken (ECSS) [mailto:KeHall@...]
> > > Sent: 21 October 2002 16:22
> > > To: 'hercules-390@yahoogroups.com'
> > > Subject: RE: [hercules-390] Re: Principles of Operation
> > >
> > >
> > > I'd be more inclined to go with 31 bit virtual as the big
> > > selling point,
> > > although the I/O changes were important too. They moved
> > > control of path
> > > management to the microcode, making dynamic multiple
> > > path I/O support workable. The original name for it was
> > > "Queueing in
> > > channel", since you'd start an I/O operation and let the
> > > microcode worry
> > > about how and when it got done.
> > >
> > > I don't remember any "low core" limitation. Each I/O
> > > operation was (still
> > > is) hung on a control block called a UCB, one per device. The
> > > only thing
> > > that changed is that instead of starting a channel
> > > program on a device via a particular path, you start it on
> > > an abstraction
> > > called a "subchannel", which is assigned through the IOCP process.
> > >
> > > Originally, if you had multiple channels defined for a
> > > device (at first,
> > > DASD was the only kind of device you could do this with,
> > > although 3480 tape
> > > drives came later), the OS would decide which
> > > channel to use based on which was free at the time. But an
> > > I/O operation
> > > isn't all one function. You can start a seek, release the
> > > channel, and have
> > > an interrupt come back when it's done. Then you
> > > start the transfer. Problem was, if you started a seek on
> > > a channel, and
> > > then disconnected, that channel might be busy actually
> > > transferring data for
> > > someone else when it came time for the interrupt
> > > to come back, so you waited, even if there were other
> > > channels available
> > > to the same device. "Dynamic path selection", which appeared
> > > in XA with the
> > > first IOCP mechanism, allows the interrupt to come
> > > back on any path connected to the device. Then you got
> > > into issues like
> > > how many internal paths a string of 3380's had, depending on
> > > configuration.
> > > A properly configured string of 3380's or 3390's
> > > could do four simultaneous data transfers from any four
> > > devices in the
> > > string. Current "virtual" DASD devices can do even more, but
> > > still suffer
> > > from internal pathing limitations.
> > >
> > > On overview, (if I recall correctly), the various versions
> > > went something
> > > like this:
> > >
> > > MVS SP1 - Repackaged MVS 3.8J plus SE
> feature and other
> > > options, as a
> > > billable product
> > > MVS XA (SP2) - 31 bit addressing and IOCP (path
> management in
> > > microcode, as above)
> > > ESA-V1 (SP3 - Dataspaces and hiperspaces,
> > > expanded storage
> > > ESA-V2 (SP4) - Dynamic reconfiguration (might have
> > > been in SP3),
> > > ESCON, System
> > > Managed Storage
> > > ESA-V3 (SP5) - Open edition as an option (later
> > > standard), Basic
> > > SYSPLEX (via CTC),
> > > parallel SYSPLEX later
> > > OS/390 V1 (SP6) - Repackaging, Open Edition
> enhancements, more
> > > parallel SYSPLEX features
> > > OS/390 V2 (SP7) - Beginning of 64 bit real storage
> > > support as an
> > > option, 9672 support,
> > > IP networking integrated with OE (now
> called USS)
> > > zOS V1.1 - Another repackaging, basically OS/390
> > > 2.10 with new
> > > label
> > > zOS V1.2 - Required 64 bit, removal of legacy code
> > > zOS V1.3 - Additional 64 bit support, removal of
> > > more legacy
> > > code, additional
> > > dynamic reconfig options, lots of
> > > Internet-related stuff
> > > and security
> > > changes
> > >
> > > Basically, the various "major" versions went with
> various processor
> > > offerings. Each version of hardware and software would
> > > overlap with each
> > > other to provide a relatively seamless migration path,
> > > where you never had to upgrade both hardware and
> software at once.
> > >
> > > For example:
> > >
> > > 303x-308x - SP1-SP2 (high end 4381's also supported XA)
> > > 308x-309x - SP1-SP4 (later 3090 models supported ESCON)
> > > 309x-9x21 - SP2-SP6 (later 9021's supported coupling links)
> > > 9x21-9672 - SP4-SP7
> > > 9672-2064 - SP7-zOS
> > >
> > > Current zOS versions require a 9672 "G5" or better. This
> > > was the cause
> > > for a minor revolt among users a couple of years ago, since
> > > it basically
> > > rendered most of the water cooled boxen (and even some
> > > fairly recent vintage 9672's) still floating around the
> > > leasing market
> > > obsolete. IBM tried to use Y2K as a breakpoint to force
> > > everyone to new
> > > hardware and software, and was mostly successful.
> > >
> > > > -----Original Message-----
> > > > From: Greg Price [mailto:greg.price@...]
> > > > Sent: Monday, October 21, 2002 3:43 AM
> > > > To: hercules-390@yahoogroups.com
> > > > Subject: Re: [hercules-390] Re: Principles of Operation
> > > >
> > > > On Mon, 21 Oct 2002 00:08:34 -0700, John Alvord wrote:
> > > > >>What is difference between S/370, 370-XA, ESA/370,
> and ESA/390?
> > > > >
> > > > >S/370 had 2K and 4K pages. The big deal in 370-XA was 31 bit
> > > > >addressing. But there are scores of differences,
> mostly downward
> > > > >compatible, at each level.... new features, new
> > >
> > > instructions, etc.
> > >
> > > > >john
> > > >
> > > > Actually, I think the biggest change brought in by XA
> was the new
> > > > I/O architecture. I believe it was needed to remove the
> > >
> > > bottleneck
> > >
> > > > of funnelling every I/O through specific locations in
> > >
> > > fixed low core
> > >
> > > > (PSA). The XA way of I/O has carried though to z/OS.
> > > >
> > > > A smaller change was the new 31-bit addressing mode.
> > >
> > > However, since
> > >
> > > > the OS takes care of the low-level I/O management, 31-bit
> > >
> > > addressing
> > >
> > > > became the change that occupied most programmers' time.
> > > >
> > > > So, if you are a programmer moving your software up
> to XA, 31-bit
> > > > stuff is the big issue.
> > > >
> > > > If you are designing a compatible processor or updating
> > >
> > > an emulator
> > >
> > > > for XA the new I/O architecture will require greater
> > > > conceptual change.
> > > >
> > > > (As implied by John above, XA did away with 2K pages.
> > > > Segments became 1MB instead of 64KB.)
> > > >
> > > > Well, that's my theory, anyway....
> > > >
> > > > Cheers,
> > > > Greg P.
> > >
> > > Yahoo! Groups Sponsor
> > > ADVERTISEMENT
> > >
> > >
> > >
> > >
> > > Community email addresses:
> > > Post message: hercules-390@yahoogroups.com
> > > Subscribe: hercules-390-subscribe@yahoogroups.com
> > > Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> > > List owner: hercules-390-owner@yahoogroups.com
> > >
> > > Files and archives at:
> > > http://groups.yahoo.com/group/hercules-390
> > >
> > > Get the latest version of Hercules from:
> > > http://www.conmicro.cx/hercules
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo!
> Terms of Service.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > > ------------------------ Yahoo! Groups Sponsor
> > > ---------------------~-->
> > > Get 128 Bit SSL Encryption!
> > > http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W4wwlB/TM
> > > --------------------------------------------------------------
> > > -------~->
> > >
> > > Community email addresses:
> > > Post message: hercules-390@yahoogroups.com
> > > Subscribe: hercules-390-subscribe@yahoogroups.com
> > > Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> > > List owner: hercules-390-owner@yahoogroups.com
> > >
> > > Files and archives at:
> > > http://groups.yahoo.com/group/hercules-390
> > >
> > > Get the latest version of Hercules from:
> > > http://www.conmicro.cx/hercules
> > >
> > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> >
> >
> > Community email addresses:
> > Post message: hercules-390@yahoogroups.com
> > Subscribe: hercules-390-subscribe@yahoogroups.com
> > Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> > List owner: hercules-390-owner@yahoogroups.com
> >
> > Files and archives at:
> > http://groups.yahoo.com/group/hercules-390
> >
> > Get the latest version of Hercules from:
> > http://www.conmicro.cx/hercules
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
> --
> Steven J. Oswald
> Systems Consulting Engineer
> OzTech Systems Consulting, Inc.
> steve@...
> Phone: (815) 337-1036
> Cell: (815) 715-4065
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W4wwlB/TM
> --------------------------------------------------------------
> -------~->
>
> Community email addresses:
> Post message: hercules-390@yahoogroups.com
> Subscribe: hercules-390-subscribe@yahoogroups.com
> Unsubscribe: hercules-390-unsubscribe@yahoogroups.com
> List owner: hercules-390-owner@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.conmicro.cx/hercules
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

1:04 pm

Re: Principles of Operation

Jay Maynard

Oct 22, 2002

On Tue, Oct 22, 2002 at 09:04:14AM -0400, Hall, Ken (ECSS) wrote:
> I had heard this was an unpopular situation, but I wasn't aware they had
> backed off on it. Interesting.

They backed off for one simple reason: it was hurting z/OS and z/Series
adoption rates. The 6-month migration period answers a LOT of DP managers'
concerns with going to 64-bit capable systems while still on OS/390.

1:33 pm