Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] SSD



On 05/31/2012 04:54 PM, Jack Coats wrote:
>> Sounds like you used VM370. With IBM VM370 using a OS/VS1 guest, there
>> were several interesting options. I found that disabling paging on
>> OS/VS1 gave me much better performance. Another thing was print
> OS/VS2 solved some of those issues and enhanced paging and swapping greatly.
>
>> spooling. IBM OS/VS1 had a terrible spooling algorithm, and VM370 worked
>> much better (with a few custom patches). This was crazy because it was
>> double spooling.
> I worked with one of the developers of HASP at NASA... basically kept IBM from
> being kicked out of NASA and saved the corporate bacon. ... When at Amoco,
> we had a project to back out the over 16,000 documented patches from VM when
> IBM started closing down their assembler source (they still provided the SPL but
> no compiler :)
>
> Some IBM mainframes had firmware assist for
>> VM370/OS/VS1.
> I though it was interesting finding a terminal (3270 style) built INSIDE some of
> the 3xxx generation mainframes.  Looking over the IBM SEs shoulder, we were
> able to help them with the VM commands when they had problems (but that was
> very seldom).  The single chip mainframe was a reality then, but it was still
> chilled water cooled and took LOTS of power in the day.
>
> There were some other interesting tricks. Our software had
>> been migrated from Burroughs MCP that had dynamic drive allocation. When
>> a job needed a tape drive it requested it. On IBM's OS/VS1 this was not
>> possible. Tape drives for a job step had to be allocated upon initiation
>> of the job step. What we did on VM370 was to allocate more logical
>> drives than physical, so for instance, if we needed 6 tapes during a job
>> step, we allocated 6 drives, then when a program opened a tape, the
>> operator could simply reassign.
> At Amoco they wrote their own tape library system.  When we "decoupled" TLS
> from our internals modifications it was harder to use.  But except for reading
> seismic data and doing backups we had little tape use (but seismic lines
> would run hundreds of tapes for a single line)
>
> i have to admit when our data center was closed down, I made a 'last walk' down
> the length of the mainframe computer room.  So much time, so much effort,
> so much money, so many missed times with the family for the 'corporate good'. :(
>
> Moved on to Unix (solaris at the time), helped build data centers for other
> companies.  Still hard work, but I missed (and still miss) the mainframes.
> They were my 'techno babies'.
>

Back when I lived in Texas I went to a SHARE meeting in Denver where
Amaco made a VM370 presentation where they were able to demonstrate that
throughput was significantly better under VM370/DOSVS than it was under
DOSVV alone. I had similar experience with VM370/OS/VS1.
OS/VS2 was a stopgap OS. It was the Virtual Memory upgrade to OS/MVT.
IBM rewrote OS/VS2 and called it MVS. In our case, MVS and OS/VS2 were
too heavy for our system (originally a 137).
If I recall the Amaco case, they ran 2 instances of DOSVS, one for
interactive and 1 for batch.

In the case of PC virtualization, though you have different processor
designs, and a virtualization system that uses the Host OS services
(except for native implementations such as ESX).

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org