开云体育

Hi again folks!

Thanks to the points you gave me last week, I managed to make through (more or less) to the point on the README where I'm suposed to IPL the new generated system (FMGEN67, which I keep at 148), perform the first time a r 00,'auto=cold' and then, apparently, keep on sending the remaining jobs...
The thing is that, while I don't have any clue of some step having gone wrong until now, once I have IPLd 148 and the format is done, the resulting IPLd system doesn't seem to be friendly either... I'm unable to send any job with this system, I feel its kind of incomplete.

More specifically, I miss any message indicating a job entry started on any partition, no IEF403I INITSWA STARTED or IEF005I PARTITION WAITING FOR WORK messages. In fact, a whole IPL handshake now is quite brief (and discouraging):

HHC01018I 0:001F COMM: client 10.112.10.61 devtype 3215: connected
IEA775I REAL STORAGE LIMITED TO 8192K
IEA760A SPECIFY VIRTUAL STORAGE SIZE

IEA103I DATASET SYS2.LINKLIB NOT FOUND BY LOCATE
IEA130I LINK LIBRARY DATA SETS NOT FOUND
SYS2.LINKLIB
IEA761I PAGE=(V=PAGE73,BLK=8192)
IEE054I DATE=95.177,CLOCK=14.44.20
IEE054I DATE=95.177,CLOCK=14.44.20,GMT
IEA764I NIP01,CMD01,DFN01,JES01,SET01,SMF01
IEA765I DEVSTAT=ALL
IEA101A SPECIFY SYSTEM AND/OR SET PARAMETERS FOR RELEASE 06.7 OS/VS1

IEA103I DATASET SYS1.DUMP NOT FOUND BY LOCATE
IEA135A SPECIFY SYS1.DUMP TAPE UNIT ADDRESS OR NO

IEA208I SYS1.DUMP FUNCTION INOPERATIVE
IEE140I SYSTEM CONSOLES
CONSOLE/ALT COND AUTH ID AREA ROUTCD
30E/01F H CMDS 05 ALL
010/01F N ALL 01 Z,A ALL
01F/009 M ALL 02 ALL
009/010 N ALL 03 ALL
011/010 N ALL 04 Z,A 1-13,15-16
30E/01F A NONE 05 NONE
IEF032I PARMLIB VALUES TAKEN FOR JES
IEE101A READY
IEE029I JLPRM=(U)
IEF249I FOLLOWING P/R AND RSV VOLUMES ARE MOUNTED
FGEN67 ON 148 (P/R-PRV)
PERM73 ON 14C (P/R-STR)
WORK73 ON 14D (P/R-PUB)
FDLB67 ON 248 (P/R-PRV)
PAGE73 ON 351 (P/R-PRV)
IEE052I MONITOR JOBNAMES,T ** FROM CMD01 AT IPL
IEE009I LOG NOW RECORDING ON DATA SET X
IEE052I MONITOR DSNAME ** FROM CMD01 AT IPL
IEE360I SMF NOW RECORDING ON SYS1.MANX ON 148. TIME=14.44.35
IEE048I INITIALIZATION COMPLETED


I feel as if I'm missing something... at this point on the README, I should execute g12 JCL, where g15 is indeed (as I understand by JCL contents) dealing with SYS2.LINKLIB, however, it seems as if this system does expect SYS2.LINKLIB there... Does someone remember how should one proceed after g11 and/or cold IPLing the new system? I have tried statring initiator but it doesn't work, I'm stuck here.

Thank you very much in advance.
Regards.

Hi folks.

Being an absolute noob... I went through the process of building 6.0.
It was extensively documented, pdf, screenshots...impossible to fail... and when I saw the 6.7 README as the sole reference, I was very excited to give that a try, expecting issues and doubts (that's how I learn the most :-) and using the 6.0 experience to 'fill the gaps'... but I failed to figure out through the UCBs.

I also was keen to try sysgenning 6.7 because, although I somehow managed to IPL 6.0 under VM/370 (Inspired by a Moshix Youtube channel video) , I felt the whole thing was missing stuff, and I though that 6.7, with those instructions to include compilers, etc were the way to go.
So far, I never (AFAIK) experienced any issue regarding 3270s on 6.0 (maybe because I ran it atop VM).

Anyways, thank you very much for your help... this is very nice!

Hi!

Now it I see things somehow more clear.
Also, that command: d u,,,000,256 is very very interesting! I like it!
Now all this confirms what I was thinking... but, since that commands apears to yield a kind of 'map' of expected CUU<->Device-Type i feel more confident on be able to go further.

As a side note, I've not (still) experienced any issues regarding terminals... but after reading around about the 3270s, telneting IPL and so, I feel I will get onto it at some time.
By the way, I'm carefully taking notes of all I do, so, in the event of finally making my way through, I expect having everythin noted, just in case.

Thank you very much!

Jay:

You're right on all counts: the starter system has a very limited set of UCBs, and the documentation for using the starter system is inadequate. I'm inclined to leave the starter system as much as possible the way IBM built it, so people can have a fairly genuine experience of using the starter system, but the peculiarities need to be better documented. I don't know if the VS1 6.7 3270 console problem is present in 6.0 -- I don't think it is, but I'm not sure -- but without an actual hardcopy console device, IPLing with a graphic console would require SYSLOG, and I don't think the starter system supports SYSLOG, so we're stuck with the printer/keyboard console IPL. We could document switching to a graphic console after IPL as you note. The documentation definitely needs work. Thanks for your thoughts, and let us know what else you run into. I hope at some point to start working on building a more permanent "turnkey" VS1 system, and definitely want to make the document more robust as part of that process.

--
Kevin

Greetings. Thanks for taking the time to post.

Basically, there needs to be more documentation about using the starter system. I fought through using the starter system by doing a lot of hand-waving, as my old math teacher used to call it, but neglected to document my leaps of faith. Those holes need to be filled in.

The starter system doesn't have a lot of devices. One device it's missing is a 3350 at 14C. Another that's missing is a 3350 at 248. I put PERM73 at 14C and FDLB67 at 248 because that's where I wanted them to be in the generated system, but that won't work on the starter system. Thus when you issued a VARY 14C,ONLINE command, you got an error message because the starter system doesn't have a UCB at 14C. I can't find a stage 1 for the starter system, but here's a DISPLAY U of all the devices in the system:

d u,,,000,256
181650 0000 IEE450I 18.16.50 UNIT STATUS 014
014 UNIT TYPE STATUS VOLSER VOLSTATE UNIT TYPE STATUS VOLSER VOLSTATE
014 002 3211 OFFLINE 004 3211 OFFLINE
014 009 3215 OFFLINE 00A 1442 OFFLINE
014 00C 2540 O 00D 2540 O
014 00E 1403 O 00F 1403 OFFLINE
014 010 3158 OFFLINE 011 3213 OFFLINE
014 012 3505 OFFLINE 013 3525 OFFLINE
014 014 3158 OFFLINE 015 3213 OFFLINE
014 016 3203 OFFLINE 017 3203 OFFLINE
014 018 3800 OFFLINE 019 3066 OFFLINE
014 01A 3036 OFFLINE 01B 3036 OFFLINE
014 01C UND OFFLINE 01D UND OFFLINE
014 01F 3215 C 118 3800 OFFLINE
014 130 2314 OFFLINE 131 2314 OFFLINE
014 132 2314 OFFLINE 133 2314 OFFLINE
014 134 2314 OFFLINE 148 3350 OFFLINE
014 149 3350 O FGEN60 PUB/RSDNT 14A 3350 O FDLB60 PUB/RSDNT
014 14B 3350 OFFLINE 150 3330 S DLIBA1 PUB/RSDNT
014 151 3330 OFFLINE 152 3330 OFFLINE
014 153 3330 OFFLINE 154 3330 OFFLINE
014 158 33301 OFFLINE 159 33301 OFFLINE
014 15A 33301 OFFLINE 15B 33301 OFFLINE
014 180 2400 OFFLINE 181 2400 OFFLINE
014 182 2400 OFFLINE 183 2400 OFFLINE
014 1C0 3340 OFFLINE 1C1 3340 OFFLINE
014 1C2 3340 OFFLINE 1C3 3340 OFFLINE
014 1D0 2305 OFFLINE 202 3211 OFFLINE
014 209 3215 OFFLINE 20C 2540 OFFLINE
014 20D 2540 OFFLINE 20E 1403 OFFLINE
014 218 3800 OFFLINE 219 3066 OFFLINE
014 21F 3215 OFFLINE 230 2314 OFFLINE
014 231 2314 OFFLINE 232 2314 OFFLINE
014 233 2314 OFFLINE 234 2314 OFFLINE
014 280 2400 OFFLINE 281 2400 OFFLINE
014 282 2400 OFFLINE 283 2400 OFFLINE
014 330 2314 OFFLINE 331 2314 OFFLINE
014 332 2314 OFFLINE 333 2314 OFFLINE
014 334 2314 OFFLINE 380 2400 OFFLINE
014 381 2400 OFFLINE 382 2400 OFFLINE
014 383 2400 OFFLINE 480 2400 O /REMOV
014 481 2400 O /REMOV 482 2400 OFFLINE
014 483 2400 OFFLINE
014 IEE452I UNIT STATUS NUMBER OF UNITS REQUESTED EXCEEDS NUMBER AVAILABLE

The documentation needs to be improved. Until I can get to that, what you can do is mount any DASD volume at any UCB address of the same device type. Thus any 3350 can go at any 3350 address (148 through 14B are possibilities). Physically attach the DASD to Hercules at the Hercules console:

attach 0148 3350 dasd/work73.14d.cckd

Vary the device online to VS1 at the VS1 console:

v 148,online

and set the volume use characteristic at the VS1 console with the VS1 MOUNT command:

m 148,vol=(sl,work73),use=public

For a work volume, PUBLIC is the appropriate use; for most other volumes, PRIVATE is probably appropriate.

Definitely need better documentation for the starter system.

--
Kevin

Hi.

Somehow sorry to resurect an old post... I missed this one and created one which, essentialy is an ask for help because I'm stuck on your first issue in your list.

I'm quite confused on the actual setup of the starting system regarding the 4 DASDs initialization.
Reading your post makes me feel that maybe those notes I found on the .cmd file were, indeed, outdated or misleading, because I don't fugure out what is the picture at that point:

Do you remember which was the arrangement (hercules .conf CUUs -> files and/or hercules attach CUU -> file commands, and the vary/mount commands?

Cheers!

Hi Folks!

I'm having troubles in my way through the Sartting system instructions for OS VS1 6.7.
Overall, the absence of a pdf with plenty of screenshots makes it more challenging and fun... but I'm stuck:

The problem is that I'm confused on the actual CUUs, disks, vary and mount commands that are needed to have in place before running g04-init-dasd-misc.jcl

Until that point, I've pretty much make it on my own, but, at some point, looking at the contents of g00-create-dasd.cmd for a 'map' of which arrangement on the whole system get confusing... because I see that the mount commands for the starter system do not match exactly the CUUs of hercules conf, and/or reference volumes/DASDs (dliba1 or work61) that I don't figure out at which point are used, if at all...
Sure, I tried to get a working 'map' of consisten CUUs <-> DASD content <-> mount volume , but at some point I was shocked as the started system replied to me at the console:

v 14c,online
IEE313I 14C UNIT REF INVALID

... and I have absolutely no clue of why 14C seems to not go online.
on the hercules side, the attach command does work:

HHC01603I attach 014c 3350 dasd/work73.14d.cckd
HHC00414I 0:014C CCKD file dasd/work73.14d.cckd: model 3350 cyls 560 heads 30 tracks 16800 trklen 19456

As it should, since that CUU is free... so, from a noob perspective, it looks like the starter system either doesn't like the hardware emulated at 14C or 14C at all.

Other than that, I would have those needed DASDs/Volumes mounted:

v 148,online
IEE302I 148 ONLINE
v 14c,online
IEE313I 14C UNIT REF INVALID
v 14b,online
IEE302I 14B ONLINE
v 151,online
IEE302I 151 ONLINE

But I feel that I have to fix this before continuing.

Any clues? Has anyone a more specific 'map' of harcules CUUs -> DASD image -> vary/mount on the starter system?

Thank you very much in advance.

Regards!

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

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.

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

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

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

Hi, Joe,

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

The first two manuals on this page:


Mark

Fish,

Have you seen the ECPS:VSE PrincOps?

Joe

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

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

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

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

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

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