Mainframe Unbreakable

zVlad · Post by **zVlad** » 03 Sep 2003 12:21

Dmitry67.

1 Если две MVS шарят один диск, то как разрешаются конфликты ? В системах типа Windows процессы общаются не напрямую с диском а через файловую систему. В случае двух MVS, сидящих на одном виртуальном диске, возможно чтение диска в несогласованном состоянии и игнорирование блокировок файлов

Во-первых, процессы MVS заботают не с дисками на прямую, а с файловой системой. Много лет назад МФ позволяли образовывать много машинные комплексы и разделять диски. Это значит, что одна и таже дисковая подсистема могла быть подключена одновременно к нескольким МФ (кстати к одному и тому же МФ несколькими каналами ввода-вывода - для распараллеливания и надежности). Читать данные можно было без проблем, писать на один и тот же диск в разные наборы данных (файлы по вашему) тоже (это удивительно, но легко объяснимо особенностями файловой системы MVS). Писать на один и тот же диск в разные наборы данных - но проблем. Но вот писать в один и тот же набор - можно, но поскольку это делалось без блокировок, то сами понимаете. Потом это все было развито в так называемый Sysplex, где подерживаются блокировки. Так обстоят дела с реальными дисками - также дела обстоят и с виртуальными дисками, поскольку, не забываем никогда, VM - это полный функциональный аналог реального МФ.

Кстати, MVS или VM под VM - это не продукшн комбинации. Это используется временно, для тестирования, для перевода на новую версию и т.к. Продукшн VM инсталяция будет иметь на виртуальных машинах CMS (для выполнения чиста VM приложений), GCS (для выполнения адаптированных под VM MVS-приложений), и Linux. Дело в том что МФ может быть логически разбит на партиции (LPAR) и в каждой партиции может выполняться своя ОС. Это надо понимать так, что на уровне микрокода в МФ есть нечто вроде VM. Количество партиций - от 1 до десятков.

Встречный вопрос: а что случиться с двумя Windows, если они шарят один виртуальный диск?

2 Cache диска (не аппаратный) работает на уровне VM, MVS или обоих ?

Файловая система MVS cache не имела (как сейчас точно не знаю). Каждая программа запрашивала буфер, в котором накапливалась информация в процессе ввода-вывода. Иными словами не каждая оп-ция с точки зрения программы выливалась в обращение к устройству ввода-вывода.

3 Какие ограничения на объем виртуального и физического адресного пространства VM и MVS ? Чтобы под VM работали сотни Linux, сама VM Должна быть 64 bit, right ?

Когда я последний раз работал с VM, то это было на МФ с 32 Мб реальной памяти. Тогда я мог сконфигурировать ВМ с памятью до 2Гб. Ныне zSeries (это как современные МФ называются) - 64 разрядные, и соответственно zVM, and zOS (это как современные ОС МФ называются) тоже 64 разрядные. Хотя я с твоим "должна быть 64 разрядной" не совсем согласен, совсем не обязательно это.

Спасибо

VYLE · Post by **VYLE** » 03 Sep 2003 12:31

zVlad - возможно я немного сильно выразился. Приношу извинения. Но Ваш пример с привелигированными командами и svc 107 не показывает никаких преимуществ, потому как абсолютно аналогичные вещи реализованы и используются на регулярной основе в Windows и других ( я не говорю о ДОС и клонах).
Вирусы используют другие техники.
И как я уже упоминал в ранних версиях MVT из-за ошибки ОС можно было получить режим супервизора, особым образом сформировав параметры вызова одного из svc. (для сведения публики - команда SVC xx анлогична команде INT xx на x86)

Dmitry67 · Post by **Dmitry67** » 03 Sep 2003 12:54

zVlad wrote:Встречный вопрос: а что случиться с двумя Windows, если они шарят один виртуальный диск?

Такого быть не может
Файловая система NT работает всегда c локальным устройством
Если ктото допустим подключился по сети 'к диску', то на самом деле он подключился не к диску а к 'файловой системе', то есть все запросы идут через файловую систему этой машины
Соответственно она в курсе всего и разруливает все конфликты

VYLE · Post by **VYLE** » 03 Sep 2003 13:24

Dmitry67 wrote:Еще вопросы

1 Если две MVS шарят один диск, то как разрешаются конфликты ? В системах типа Windows процессы общаются не напрямую с диском а через файловую систему. В случае двух MVS, сидящих на одном виртуальном диске, возможно чтение диска в несогласованном состоянии и игнорирование блокировок файлов

Когда я последний раз работал с VM - там каждой ОС выделялись либо отдельные диски либо отдельные разделы на диске.

zVlad · Post by **zVlad** » 03 Sep 2003 15:13

Whole story about network file systems in MVS is as follow:

-----------------------------------------------
With the OS/390 NFS server, you can remotely access MVS/ESA conventional data sets or OS/390 UNIX files from workstations, personal computers, and
other systems that run client software for the Sun NFS version 2
protocols, the Sun NFS version 3 protocols, and the WebNFS protocols over TCP/IP network.
The OS/390 NFS server acts as an intermediary to read, write, create or delete OS/390 UNIX files and MVS data sets that are maintained on an MVS host system. The remote MVS data sets or OS/390 UNIX files are mounted from the host processor to appear as local directories and files on the client system. This server makes the strengths of an MVS host processor -- storage management, high-performance disk storage, security, and centralized data -- available to the client platforms.
With the OS/390 NFS client you can allow basic sequential access method (BSAM), queued sequential access method (QSAM), virtual storage access method (VSAM), and OS/390 UNIX users and applications transparent access | to data on systems which support the Sun NFS Version 2 protocols and the | Sun NFS Version 3 protocols. The remote NFS Server can be an MVS, UNIX**, AIX, OS2, or other system. The OS/390 NFS client is implemented on OS/390 UNIX and implements the client portion of the Sun NFS Version 2 protocols | and the Sun NFS Version 3 Protocols.
---------------------------------------------------------
1.2 Using OS/390 UNIX Files

The Network File System server enables the client user remote access to OS/390 UNIX files from a client workstation.
OS/390 UNIX provides a Hierarchical File System (HFS) for MVS. The HFS file system is similar to a UNIX** file system. All OS/390 UNIX files reside in a directory, which in turn is a file in a higher level directory. The highest level directory is called the root directory.
When client users mount files from your server system, you use a common HFS prefix to distinguish OS/390 UNIX files from conventional MVS data sets. You see OS/390 UNIX files in a standard UNIX format on your workstation, but the files are stored on an MVS host system.
----------------------------------------------------------
1.3 Using Conventional MVS Data Sets

Using the Network File System, you can access conventional MVS data sets from a client workstation, personal computer, or any client system using software for the NFS protocol.
In MVS, a file is called a data set. The Network File System allows client users to mount conventional MVS data sets from their workstations. It presents the information to them in the form of a UNIX (or AIX), OS/2, or DOS file, though the information is actually stored on an MVS-owned DASD.
The files for an operating system are organized into a file system. The UNIX, OS/2, and DOS environments use a file system which is a hierarchy of directories. Conventional MVS, in contrast to OS/390 UNIX, uses a non-hierarchical file system in which groups of data sets are referred to by specifying a high-level qualifier (HLQ).
The MVS HLQ can include the first (leftmost) qualifier of data sets, or the first and second qualifiers, or the first, second, and third qualifiers, and so on. For example, SMITH is the HLQ for the files named SMITH.TEST.DATA and SMITH.PROJ7.SCHED, while SMITH.TEST is the HLQ of SMITH.TEST.DATA and SMITH.TEST.DOCS.
--------------------------------------------------------