开云体育

I worked on MVT and then went straight to MVS - never in my life used
an SVS system. So I've never thought about how TSO worked in the large
single address space. I imagine it still had SWAP dataset(s), but did
it really swap from/to *virtual* storage, with effectively double
paging? Or was it the norm to make the TSO region(s) run V=R? Or
something else I'm not thinking of...?

Tony H.

Hi, Tony,

In SVS, it specifically prohibits you from running TSO in a V=R region,

Also, they got rid of "swapping" in the sense of those swap data sets used in OS/360 MVT. Instead, what you do is to reserve a certain percentage of the total paging space for use by TSO. When TSO is inactive, of course batch can also use that page space. Then, when a TSO user goes into a "long wait" their pages are eligible to be "stolen" in the usual way by the paging subsystem, to make room for other pages needed for other TSO users, etc.

Also, you could put certain TSO commands, such as EDIT, in the LPA, so they would be shared by all TSO users.

Hope that helps,

Mark

On Fri, 10 Mar 2023 at 13:31, Mark Waterbury <mark.s.waterbury@...> wrote:

Hi, Tony,

In SVS, it specifically prohibits you from running TSO in a V=R region,

Yeah - I thought that one was unlikely for a few reasons.

Also, they got rid of "swapping" in the sense of those swap data sets used in OS/360 MVT.
Instead, what you do is to reserve a certain percentage of the total paging space for use by
TSO. When TSO is inactive, of course batch can also use that page space. Then, when a
TSO user goes into a "long wait" their pages are eligible to be "stolen" in the usual way by
the paging subsystem, to make room for other pages needed for other TSO users, etc.

Interesting... I'm still not getting this entirely, though. In MVT
TSO, for a given TSO region, all users shared the same address range,
and each user's space was swapped in and out. So necessarily there
were multiple unrelated chunks of storage in the same swap dataset
with the same main storage address range. I have no recollection of
what the swap datasets looked like, but I don't think they were
page-oriented, and they must have always swapped the entirety of
GETMAINed storage (because there were no change/reference bits to know
if pages were in use).

If the swap datasets are gone in SVS, then it sounds as though there
must have been some private interface to the paging system to be able
to write out multiple pages with the same address range, i.e. Multiple
Virtual Storages... :-)

Hmmm... Does SVS have VIO? I think that came only with MVS, but it
sounds like something that would require a similar interface.

Also, you could put certain TSO commands, such as EDIT, in the LPA, so they would be
shared by all TSO users.

I think even MVT allowed for that. Wait - does MVT even have an LPA?
There is JPA, but that's not global.

Hope that helps,

It does - thanks.

Tony H.

Hi, Tony,

Look here:


The last two manuals on that page will answer ALL of your questions about how TSO worked on SVS. :-)

Each TSO user, at LOGON time, is allocated a REGION, the size of which is of course controlled by their LOGON PROC. That region is a contiguous chunk of the total 16 MB virtual address space of SVS, but because it is TSO, the SVS supervisor ensures that this region is paged to the "TSO" reserved page space.

There is never a full region "roll-out" or "roll-in" like the swapping in MVT, because in MVT, you had a fixed number of pre-allocated "slots" for TSO users to run in, so they had to swap out that entire space, or all of it that you used, to make way for the next tSO user to get swapped in. In SVS, they just leave it to "demand paging" to steal any pages needed. Then, when it is "your turn" to get dispatched again, you will just demand page in any of your pages that were "stolen."

What you can see with SVS is that it is an evolutionary step towards MVS 2.0 and above, where TSO became an integral part of the OS, no longer "optional." The only "option" about TSO in MVS is whether or not you use it.

Hope that helps,

Mark

Arrrrggghhh - the nightmares are starting again LOL !!!
When the system I was on switched from R21 MVT to SVS, there were endless meetings about moving from the drum TSO swap devices to TSO page devices using said drums (and someone wanted PLPA there too). The question was (I think) how to reformat the volumes over a weekend and make the change and hope you didn't need to go back the other way. ISTR about two months of spotty TSO response until a couple of PTFs and changes to channel layout fixed most of the problems (until MVS - a story for another time).

On Fri, Mar 10, 2023 at 02:08 PM, S. L. Garwood wrote:

Arrrrggghhh - the nightmares are starting again LOL !!!

My night wares is soon as i think of OS complexity vs VM. For example, add devices to VM, change one file, assemble, rebuild the nucleus, install it, and IPL. Five steps, you're done in ten minutes. I *still* don't know how to "just add a device" on any version of OS.

When the system I was on switched from R21 MVT to SVS, there were endless
meetings about moving from the drum TSO swap devices to TSO page devices using
said drums (and someone wanted PLPA there too).

I keep thinking under Hercules, virtual storage systems (VM, SVS, MVS, maybe even OS/MVT w/TSO) should have 2305 paging devices. Obviously, 16M systems won't page much, and the emulated 2305 units won't be faster than any other OTHER device (all using the same disk for backing store), but shops loved those devices in the real world.

16MB systems on OS/VS1, DOS/VS, possibly SVS should never page. The object of these systems was to present a virtual 16MB system to the users. If you had 16MB it would be essential V=R all the time.

Hi, Richard,

With any virtual memory system, more real "backing store" main memory is always "better" as less actual paging in and out (from disk or drum) will be required.

In the 1970s, customers almost never had 16 MB of "real" memory on any models of IBM 370, so for example on a 158-3 we had 2 MB of real memory; later after upgrading with 3rd party (Memorex) memory, it was increased to 6MB of real memory. I think the largest amount of memory I ever heard of on a model 168 was 8 MB. By the late 1970s, with Amdahl's 470 series and IBM's 3033, we start to see the possibility of machines with 16 MB or more of real memory. And of course special hardware or microcode was required to allow for > 16 MB of real memory. The virtual address space remained at a maximum of 16 MB (24 bits) until the arrival of 370 Extended Architecture (XA), with the possibility of 31-bits of virtual address space was introduced, in the early 1980s.

I think the Functional Characteristics manuals for the various models describe the maximum configurations.

Mark S. Waterbury

Mark,

My point was that OS/VS1, DOS/VS and SVS did not provide virtual memory in the sense we now think of it. Sort of like MVS where you could have jobs totally more then 16MB running at one time. Or on a VM system where you could have multiple machines bigger then 16MB combined. OS/VS1, DOS/VS just provided you with a virtual 16MB IBM370. Obviously more physical memory the better, however you will not be able to run anything bigger then a 16MB system. So there would be no difference between say DOS/360 on a 16MB system and DOS/VS on a 16MB system other then the overhead of paging hardware.

Rich

Richard,

You are correct. IBM never intended DOS/VS, or OS/VS1 or OS/VS2 Rel. 1 as a long-term solution; they were a "first step" into the world of virtual memory. Having 16 MB of address space total available greatly alleviated many of the problems that DOS/360 and OS/360 suffered from, with typically less than 512K of core memory for DOS/360, and less than 1 MB of core for OS/360. This was especially troublesome for MVT, where running many jobs with different region sizes would end up fragmenting whatever small amount of real core memory was available; and this problem was so bad that it often required an (unplanned) IPL to "fix" it.

IBM first introduced the S/370 product line without virtual memory. Once the decision was taken to offer models with DAT, IBM had to scramble to convert DOS/360 to DOS/VS and OS/360 MFT to OS/VS1 and MVT to OS/VS2.

VM/370 and OS/VS2 Rel. 2 and above (MVS) really began to show the potential of virtual memory with multiple address spaces. Of course, it took IBM a few more years to get MVS to "settle down" -- Release 2 was unstable and even Release 3.0 had issues; it was not until MVS 3.6 and 3.7 that it settled down by the mid-1970s, and then we started to see larger numbers of shops converting to MVS.

Even so, DOS/VS and OS/VS1 and SVS remained quite popular for far longer than I think IBM ever anticipated.

Mark

On Sat, Mar 11, 2023 at 02:34 PM, Richard Cornwell wrote:

[...]
So
there would be no difference between say DOS/360 on a 16MB system and DOS/VS
on a 16MB system other then the overhead of paging hardware.

Agreed. Actually, DOS/VS (pre-VSE) would stop paging at just a bit over 8MB.

Pre-VSE, DOS/VS included real storage in the virtual address area but did not use it for virtual applications. See p.3-4 of DOS/VS System Management Guide Release 34, GC33-5371-6, Apr 1977, for a discussion and p. 1-9 for a diagram.

On a 16MB DOS/VS system, all partitions would run in real address space, so no paging. At 8mb, partitions would run either as real partitions (no paging) or as virtual partitions (8mb virtual address space backed by nearly 8MB real storage).

One could conceive of a workload on an 8MB system with several large real mode partitions reducing the page pool for a single 8MB virtual partition to the point where the virtual partition would thrash, but that's a bit contrived.

And this point is also a bit contrived, as 16MB is a small system today, and an 8mb DOS/VS system at the time would be unthinkably unlikely. But the point does illustrate an early design of virtual and real address spaces that we would think quite odd today. IBM did too; DOS/VSE separated the virtual and real address spaces (pre-AF; p.29, Introduction to DOS/VSE, GC33-5370-6, Jan 1979).

Steve

DOS/VSE also brought support for ECPS:VSE which put all paging into hardware. The CPU did not use a page table, but kept the translations in a special array.

If there is a IPL tape for DOS/VSE it might be interesting to add ECPS:VSE support to my IBM370 emulator.

Rich

Richard Cornwell wrote:

[...]

If there is a IPL tape for DOS/VSE it might be interesting
to add ECPS:VSE support to my IBM370 emulator.

I've been wanting to add such support to Hercules for *years* now.

Unfortunately however, I have yet been able to find an ECPS:VSE version of DOS/VSE. :(

Until such a version of DOS/VSE is located, adding ECPS:VSE to Hercules (and to your IBM370 emulator as well) would be a complete waste of time. :(

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Fish,

Have you seen the ECPS:VSE PrincOps?

Joe

Hi, Joe,

It is basically the 4300 Principles of Operations for ECPS:VSE mode ...

The first two manuals on this page:


Mark

We know how to implement ECSP:VSE, problem is without any software to run on it, it is kind of pointless to implement it.

Rich

Richard Cornwell wrote:

We know how to implement ECSP:VSE, problem is without any software
to run on it, it is kind of pointless to implement it.

Precisely!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Sat, Mar 11, 2023 at 12:20 PM, Mark Waterbury wrote:

Having 16 MB of address space total available greatly alleviated many of the
problems that DOS/360 and OS/360 suffered from, with typically less than 512K
of core memory for DOS/360, and less than 1 MB of core for OS/360.

512K? *snort*

DOS/360 could run 16K (1/32 of 512K).

This was
especially troublesome for MVT, where running many jobs with different region
sizes would end up fragmenting whatever small amount of real core memory was
available; and this problem was so bad that it often required an (unplanned)
IPL to "fix" it.

I've read that MVT regions needed four times the region they were expected to need (the working set?); this was also alleviated by the 16M virtual address space.

Of course, once customers grew into (and stressed) their virtual systems with multiple address spaces (MVS & VM), their priority was real storage relief, which is how MVS and VM/HPO with 16 MB virtual addressability got 64 MB real memory on the late 1970's hardware.

Even so, DOS/VS and OS/VS1 and SVS remained quite popular for far longer than I think IBM ever anticipated.

z/DOS lives! (I think it's got a cottage down the beach from Frodo.)

On Sun, Mar 12, 2023 at 01:21 PM, Drew Derbyshire wrote:

512K? *snort*

DOS/360 could run 16K (1/32 of 512K).

True. And OS/360 could run in 64K. (OS/360 Sysgen manual for R13, Sept 67.)

DOS/360 would IPL in 16K but even with the distribution system supervisor, which supported no more than 10 devices and did not include storage protection among other things, took six of that. A simple 103-line COBOL demo program included with the distribution materials took 13K (linked size including runtime and LIOCS), so that's a no-go. One could certainly do better with Assembly. Although you couldn't use the big Assembler F (44K), or even the 14K Assembler D. You were left with the 10K Assembler D.

I do not have operational OS/360 experience, but I will speculate that OS/360 on 64K was a similar experience. Documentation for later releases stopped talking about 64K.

To round out this discussion of smaller memory machines, in the 1960s, even into early 1970s, core memory was the single most expensive component of IBM mainframe systems. So, the smaller shops could not afford that much memory, hence the need and continued demand for the small systems (DOS/360, DOS/VS for the smaller 370 models.)

Of course, the large shops who could afford the larger machines like a 360-65 could afford more core memory, so it became feasible to run OS/360 MVT ...

But the absolute limits on the amount of real storage were a real impediment to applications development -- you had to resort to using overlays or dividing your large jobs into multiple job steps etc., and often the by software had to be designed to use large "work files" to manipulate large amounts of data, in lieu of more available memory.

This was all greatly alleviated with the advent of virtual memory.

With the S/370, IBM transitioned from core memory (on the earliest 370 models) to semiconductor memory, and this helped to significantly reduce the cost per megabyte, over the next several years. For example, by about 1977 or 1978, my employer was able to acquire 4MB of add-on memory from MEMOREX, for the 158-3 for only ~$50,000. :-o