Mainframe Unbreakable

SVK · Post by **SVK** » 02 Sep 2003 12:51

zVlad wrote:2. Какие средства есть в VM для синхронизации и обмена информацией разных виртуальных машин ?
...... VM - это иная чем MVS ОС. Причем MVS может выполняться под VM но не наоборот. Перечислить средства я не берусь их очень много было когда я практиковал в VM (это было в 96).

Насчет VM - это во многом вопрос терминологии. Практически термин Address Space используемый в MVS это эквивалент VM в данном контексте. Однако эта комбинация слов не используется в MVS только потому, чтобы не путаться с совершенно отдельной OS, называемой VMS (Virtual Memory System? кажется), которая как раз и оперирует понятиями Virtual Machines. (Её подобие было даже в ЕС ЭВМ, но там называлась СВМ - Система Виртуальных Машин).

Кроме того, что MVS и VMS в принципе разработаны совершенно независимо, "с нуля", у них разница начинается "от головы": MVS по архитектуре выглядит, как одна OS, которая выделяет по запросам множество Address Space для работы внутри них как системных процессов, так и пользовательских программ. VMS наоборот, имитирует множество отдельных виртуальных машин, в виртуальную память каждой из которых загружается отдельная копия OS VM, которая управляет системными или клиентскими программами только внутри этой VM.

Во всех системах есть много разных средств взаимодействия между Address Spaces и/или Virtual Machines. VMS настолько хорошо имитирует отдельные машины, что в любой из VM можно загрузить отдельную копию MVS.

SVK · Post by **SVK** » 02 Sep 2003 12:57

zVlad wrote:Dmitry67, кратко:

4. DB2 работает в отжельной VM ? Сколько VM она занимает ?
Не готов ответить. Давно не косался DB2 под VM. Узнаю - доложу.

Видимо, вопрос касается DB2 в MVS - там в качестве VM выступает Address Space. DB2 использует 5 или более Address Space, в зависимости от конфигурации.

Dmitry67 · Post by **Dmitry67** » 02 Sep 2003 13:20

SVK wrote:
zVlad wrote:Dmitry67, кратко:

4. DB2 работает в отжельной VM ? Сколько VM она занимает ?
Не готов ответить. Давно не косался DB2 под VM. Узнаю - доложу.

Видимо, вопрос касается DB2 в MVS - там в качестве VM выступает Address Space. DB2 использует 5 или более Address Space, в зависимости от конфигурации.

1 А кто использует DB2 из других VM, связывается с ней по сети ?
2 А правда что под VM можно запустить саму VM ?

zVlad · Post by **zVlad** » 02 Sep 2003 15:00

Correct name is VM – Virtual Machine. VMS – name for DEC OS, for VAX. More accurate names for IBM VM (due to it is very common term, VM) were VM/370, VM/SP, VM/ESA, and finally zVM.
Central part of VM IBM called CP (Control Program) is not exactly OS, because the only purpose of this is to create VMs and handle them. You can have only CP on your machine, and then you must set up any OS available for IBM MF in order to run problem programs. It could be MVS, VSE (now also Linux).
Actually, VM has another component, called CMS – Conversational Monitoring System. Combination CP/CMS is an truly OS. Many problem programs run on VM under CMS. CMS has two modes: batch, and dialog.
One day long time ago, GCS – Group Control System was invented – to run MVS programs in VM. GCS is a light version of MVS for VM.
Dmitry67, yes you can run VM under VM, and again and again and again. No limits of nesting.
“А кто использует DB2 из других VM, связывается с ней по сети ? “ – there are many ways to use DB2, simplest ways all people know are ODBC, and JDBC. You can use DB2 in the same manner as you use MS SQL. For example from MS Access. But, once again, there are many (4-5) ways to use DB2. I’ll shed light on it latter.

SVK · Post by **SVK** » 02 Sep 2003 15:21

Dmitry67 wrote:
SVK wrote:Видимо, вопрос касается DB2 в MVS - там в качестве VM выступает Address Space. DB2 использует 5 или более Address Space, в зависимости от конфигурации.

1 А кто использует DB2 из других VM, связывается с ней по сети ?

А. Под управлением MVS все программы используют DB2 только из других Address Space, в том числе и физически с других компьютеров, связанных различными способами (от SYSPLEX до реально разнесенных систем объединенных в какую-либо WAN). Почти независимо от "распределенности" самой DB2 для запросов к ней имеется несколько вариантов генерации SQL (от статических Embedded SQL до JDBC), которые отличаются в основном гибкостью настройки против эффективности выполнения. См. краткую ссылку здесь:

http://www-3.ibm.com/cgi-bin/db2www/dat ... HDRCLIODBC

Использовать при этом сеть или нет - во многих случаях происходит почти "прозрачно" для прикладной программы - на усмотрение MVS (или компонентов DB2), которые выбирают способ физической передачи запроса между клиентом и DB2, или нужной частью распределенной DB2.

Б. DB2 для VM (OS называется VM/ES на самом деле) является частью многоплатформной DB2/UDB, которая реализована также для AIX, Windows, Linux, VM/ES, и кажется HP-UX. До сих пор IBM не смогла объединить их по реализации также с DB2/390, хотя внешние атрибуты и способы взаимной передачи запросов относительно приведены в соответствие.

Dmitry67 wrote:2 А правда что под VM можно запустить саму VM ?

Вообще, я еще давно слышал краем уха про такой эксперимент, как подтверждение виртуозности реализации виртуальной машины. Но точно сейчас не помню, и не уверен, что любая версия так сработает сейчас.

Во всяком случае в некоторых попадавшихся раньше фрагментах кода управляющих программ VM/ES встречались яные места для "спец. имитации" других OS:

IF (загружена MVS) THEN { особая обработка }

А также в управляющих программах MVS есть подобное:

IF (загружена в Виртуальную Машину) THEN { кое-что специальное }

В некоторых местах эти вставки сделаны для эффективности, но с большой вероятностью без некоторых из них MVS под VM не станет работать. А VM под VM также без такого скорее всего не заработает.

Post by **Flying Hen** » 02 Sep 2003 17:00

Хм, почитал я все это и сделал для себя такой вывод: таки да, mainframes более устойчивы к вирусам по сравнению с писюковой платформой. Просто, насколько я помню, все червяки, которые в последнее время ходили по сети, в том или ином виде использовали срыв стека как ключевой элемент проникновения в систему, даже если вирус скриптовой. Если mainfraim архитектура действительно не позволяет делать срыв стека, то это очень серьезный аргумент в пользу security. Хотя, с другой стороны, наверняка существуют другие методы взлома, специфичные для платформы. То, что один человек сделал, другой всегда сломать сможет :wink:

tengiz · Post by **tengiz** » 02 Sep 2003 20:34

Flying Hen wrote:Хм, почитал я все это и сделал для себя такой вывод: таки да, mainframes более устойчивы к вирусам по сравнению с писюковой платформой. Просто, насколько я помню, все червяки, которые в последнее время ходили по сети, в том или ином виде использовали срыв стека как ключевой элемент проникновения в систему, даже если вирус скриптовой. Если mainfraim архитектура действительно не позволяет делать срыв стека, то это очень серьезный аргумент в пользу security.

Нет, это не так. Проблема есть только у Intel 386 архитектуры в комбинации с Windows/Linux/FreeBSD и заключается она не в наличии аппаратного стека, а в том, что процессору разрешено выполнять код, находящийся на стеке - именно в этом и заключается взлом через buffer overrun. К сожалению из-за переносимости ядер указанных выше операционных систем не все возможности аппаратной защиты i386 можно полноценно использовать. Так как на страничном уровне у i386 отсутствует атрибут защиты "читать(писать), но не исполнять", а сегменты, где это элементарно делается, не поддерживаются другими популярными микропроцессорами, то и получается, что некоторые ошибки программистов, в частности, buffer overrun, нечем прикрыть. У Itanium такой проблемы уже нет. Так же как и у PowerPC или у Alpha.

zVlad · Post by **zVlad** » 02 Sep 2003 22:09

SVK wrote: "Во всяком случае в некоторых попадавшихся раньше фрагментах кода управляющих программ VM/ES встречались яные места для "спец. имитации" других OS:

IF (загружена MVS) THEN { особая обработка }....."

VM (CP - Control Program) is not capable to recognize if OS on certain VM is say MVS, or VM. Instead, we are able to choose some options for certain VM and say CP to use special processing modes. For example, if we know that MVS will run on VM1 we can say something and prevent from shadow paging, and so on...

"А также в управляющих программах MVS есть подобное:

IF (загружена в Виртуальную Машину) THEN { кое-что специальное }
......."

Unlike previouse "IF" this one is absolutaly correct. First byte in PSW on VM is always x'FF'. And this is used when MVS is IPL-ed on VM for better performance.

"В некоторых местах эти вставки сделаны для эффективности, но с большой вероятностью без некоторых из них MVS под VM не станет работать. А VM под VM также без такого скорее всего не заработает."

Not correct, restrictions to run MVS, and VM under VM are strictly related to hardware, VM host version, and MVS/VM guest version. If you want, for example, to run 64-addressing version of VM on VM host system without it then you will fall, and so on...

zVlad · Post by **zVlad** » 03 Sep 2003 00:47

Tengiz, докладываю: 17 страниц прочитаны. i386 имеет все необходимое для защиты вычислительных процессов. Проблемы с защитой возникают от того, что некоторые операционные системы ".... К сожалению из-за переносимости ядер указанных выше операционных систем не все возможности аппаратной защиты i386 можно полноценно использовать.....".

Последнее было для меня полной неожиданностью, так как в мире МФ таких проблем нет и все что делается на аппаратном уровне в полной мере (100%) используется ОС-ами.

Dmitry67 · Post by **Dmitry67** » 03 Sep 2003 08:25

Еще вопросы

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

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

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

Спасибо

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