开云体育

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.

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.

SVS 1.7K has VTAM and VSAM, but I don't know that we have any SVS application that uses VTAM. TSO doesn't, it's still TCAM-only on SVS. The copy we have includes VTAM, but part of TCAM is missing and other parts seem to be backlevel, as though the installation it came from didn't use TSO. VSAM is present, but it seems a bit fragile: my sysgen hack that uses a JOBCAT containing DLIBs defined as NONVSAM objects didn't work reliably on SVS because after a while, the VSAM catalogs would break even though they should have only been getting accessed for LOCATEs, so I think I eventually gave up on trying to use them and just cataloged DLIBs in the system CVOL catalog.

SVS didn't come with any free compilers, but IBM explicitly documented that most of the free OS compilers would work on SVS (for some reason, that included COBOL F, which had already been withdrawn by the time SVS was available).

--
Kevin

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

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

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,

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

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

The SVS that we have here is "bare bones" as a plain vanilla IBM SCP distribution, built from some SVS 1.7K DLIBs we were able to recover. It is notably incomplete due to the lack of TSO. Also, unlike OS/360 MVT, SVS did not come with any "free" compilers, etc., as by that time, IBM was charging for each compiler as a separate program product.

We also have HASP II Version 4.0 for SVS ... Kevin Leonard is working on getting HASP II Version 4.1 ready for distribution.

Of course, you can install pretty much all the compilers from OS/360 MVT, and the OS/360 SORT utility (IERRCO00), and Jay Moseley's "compilers pack" etc. on your SVS system, once you get it installed and running.

In the next few weeks, we hope to recover additional DLIBs for SVS 1.7, including the missing TSO DLIBs. As soon as that work is completed and it is tested, we will announce it here on the H390-OSVS list.

Hope that helps,

Mark S. Waterbury

Mark Waterbury once said on the hercules-390 goup:

SVS ran very well on a 370 model 158 with 2MB of main storage, circa 1976 or so, running batch and also supporting CICS/VS for on-line applications. No TSO, though, as that was known to be a performance hog.

One of the selling points of CMS was it could run as twice many users of TSO on the same hardware.

SVS 1.7, with the VSAM ICR (independent component release) to support VSAM datasets for use by CICS/OS/VS 1.1.1. BTAM was used with CICS/VS for local terminals, not VTAM. (mainly due to lack of 3705 hardware.)

What does the SVS version in this group's archive have? (Does it have basic VTAM and VSAM?)

-ahd-

(cross-posting this message here on behalf of Andreas Geissbuehler)

INTERCOMM Preservation Project Update

Last May, many of you expressed interest in helping to save the INTERCOMM TeleProcessing Monitor software, the most successful third-party TP monitor competing with CICS in the 1970s and 1980s.

I was the assistant and bug fixer, z/OS sysprog and Unix Flex/ES sysop, working for the last person who was supporting INTERCOMM. I had a copy of the last and to the best of my knowledge the only complete set of hard copy manuals and machine readable development, product release and support material for releases 9, 10 and 11. I asked and the owners of INTERCOMM agreed to release the product to the hobby computer community.

Mark Waterbury volunteered to scan the hard copy library into PDF format documents. Meanwhile Jay Maynard built a 3380 disk and a ready to run "turnkey" INTERCOMM R9 configured for the TK4- MVS 3.8j System. The manuals and the disk image can now be downloaded, see "Update:" on the INTERCOMM Group home page at [email protected]

Whether you would like to learn, design and write your own online transaction processing system, or to offer suggestions and share your recollections, or perhaps just to refresh your memory of INTERCOMM, I would like to invite you to join the newly created <[email protected]>.

You may know someone who worked in an INTERCOMM shop; please encourage them to join [email protected] to share their recollections and experiences.

Andreas Geissbuehler

Thank you!
Roberto

El jue, 24 mar 2022 a las 0:22, Fish Fish (<david.b.trout@...>)
别蝉肠谤颈产颈ó:

I agree!! *VERY* cool!!

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

mail: fish@...

Very cool!

Hi Guys

On top of Richard Cornwell excelent IBM360 simulator I've added a Model 370/145 and 370/148 Cpu panel + i/o devices
They runs (among others) OS/VS1 Release 6 and OS/VS1 Release 6.7

The sources to build are available at

There are also .zip files with Test Run Software Kits ready to run (OS/VS1 but also VM/370, MVT etc). Windows only (sorry)
I 'm trying to make control panel and visuals as close as possible to real think. Please feel free to tell me what noes not match the looking of original HW.

Enjoy
Best Regards
Roberto

The wiki says, it is starter system in files section, but I can see only dist tape and jcl for gen system, it is not ctl files for dasdload.
I am wrong?

Hi Gary,

I have put the OSVS1 auto build script in:



This will not work with Hercules, but with SimH IBM360.

IBM360 simH is available at:



I found an issue that VTP does not like dial based 3270's. It
complains if the device is not connected.

I will update the build to 3.8 when you update it. I had to combine
some of the generation jobs to work from clean install.

Rich

--
==========================================================================
Richard Cornwell
rich@...

LinkedIn:
==========================================================================

Rich.
Yes, please send me your auto build job. I will include it with my VTP 3.8 update!
Thanks,
Gary

I got VTP 3.7 to run on my version of OS/VS1, under SimH 360 simulator. I can make auto build job available if there is interest.

Rich

I got through the first part of Kevin Leonard's gen process. I did run into
some issues, though...
1) The biggest issue is that the starter system only has 4 3350s defined. I
discovered this was a problem while getting g04-init-dasd-misc to run. I
wound up unmounting the WORK61 volume at 14B and using that for PERM73
instead.
2) The starter system needs to be IPLd from a 3215 console at 01F. Thai is
because that address needs to be online at IPL time so the SPECIFY HARDCOPY
message can be replied to with "r 00,'hardcpy=01f,all,cmds)'". Replying
SYSLOG instead of 01F there results in the SPECIFY HARDCOPY message being
repeated. You can have a 3270 console connected at 010, and once the system
is up, switch to it with "v 010,mstcons".
3) The supplied stage 1 has display consoles defined, and so a 6.7 genned
with that deck can't be IPLd: you have to have the 3270 online at IPL time
or else you get a 00F wait state, and if you have it online the DIDOCS bug
gets you. I'm about to rerun the stage 1 with the 3270 consoles removed.
Maybe the usermod can be applied before the gen is run? Haven't looked at
that yet.

--
Jay Maynard