On/Off Capacity on Demand for z990

[Dmitry67]

Для SQL server On/off capacity demand не совместимо с лицензионной политикой M$ которая берет за процессоры

Это я не про мейнфрейм разумеется а ваапще

[flip_flop]

Для SQL server On/off capacity demand не совместимо с лицензионной политикой M$ которая берет за процессоры

Это я не про мейнфрейм разумеется а ваапще

Если прочитать Ваше утверждение буквально, может сложиться впечатление, что изощренная фирма М$ берет за процессоры ... вместо фирм производителей процессоров

[Dmitry67]

А что )то идея
Представьте
M$ объединяется с Intel и делает такой маркетинговый ход
Софт - бесплатен (во всяком случае уровня Home, Win+Office), воруй не хочу
Плата - только за процессоры (соответственно в цене процессора накрутка)
Linux в такой ситуации обречен

[Palych]

Ет все фигня. Чарджить надо за каждый такт процессора. Хочешь быстрее - плати больше.

[slozovsk]

А вот в JCL никаких проблем с рассчетом стоимости не было
//PARM.LKED=NOXREF
//FORT SYSIN.DD

Вот что я помню

надо свою лепту внести

Первая перфокарта - JOB, затем EXEC, а потом уже и DD

[slozovsk]

Ет все фигня. Чарджить надо за каждый такт процессора. Хочешь быстрее - плати больше.

Я это уже предлагал. Причем не только за такты, но и за длинну jmp и т.д.

[zVlad]

Я тут придумал хлесткую метафору по поводу разных подходов ИБМ и МС.
.............
А ИБМ - неутомимо двигает научную мысль вперед, постоянно придумывает филосовский камень, продавая побочные продукты своих изысканий. При етом кажный продукт обявляется священным, чудотворным и неприкосновенным. Вокруг етих продуктов образуется каста жрецов, передающих из поколение в поколение предания о мироточаших буклетах ИБМ 360...

И ведь что интересно - ни те ни другие не могут жить друг без друга...

Интересную Вы предложили метафору. Только вот насчет касты жрецов Вы угадали с точностью до наоборот. Поясню.
Большинству МФ специалистов (мне в том чмсле) не чужды другие технологии, другие системы, новые языки и т.д. Unix на МФ есть(пару лет назад я сидел в нем безвылазно несколько месяцев), ООП, Java тоже есть, WebServer, TCP/IP опять же есть. Вообще то перечисленное не является "другим" - это все нынче и МФ-ское тоже.
На столах у нас Windows (жаль что не OS/2), настроить который, проинсталлировать продукт, решить несложную проблему - пожалуйста. Мы постоянно пользуемся РС программами работающими с МФ как с сервером. Видел я и МФ специалистов, которые многим называвшим себя "РС специалистами" в вопросах РС могли дать 100 очков вперед. Когда я только пришел в фирму где сейчас работаю в списке продуктов за которые я полностью отвечал числились: Oracle Gateway and SQL*NET, приходилось и со службой сервиса Oracle общаться. Потом Оракл (как сервер для репликации) был заменен на SQL Server, довольно часто приходится общаться с Сonsole Manager-ом и Query Analyzer-ом, делать несложные манипуляции с базой на SQL Server-e.
А вот не МФ специалисты при упоминании МФ как правило могут произнести внятно ровно одну фразу - "это дорого" и уже на вопрос "что дорого? Цена за киллограм, или кубический фут?" ответить не могут. Некоторые вспоминают далекую молодость, когда они (как правило в институте) прогнали несколько пакетных заданий. Вот и все. Ну и кто же жрецы, колдуны, ограничивающие свое общения произнесением заклинаний типа "МФ скоро вымрет"?

[zVlad]

........
x For more information, take a look at linux/Documentation/cpu-freq or x
x at <http://www.codemonkey.org.uk/projects/cpufreq/> x
x x
x If in doubt, say N. x
x
Похоже?

Конечно нет.
Евгений, а почитать ссылку, которую я привел в сабже? Для меня эта технология так же нова как и для Вас.

[zVlad]

А вот в JCL никаких проблем с рассчетом стоимости не было
//PARM.LKED=NOXREF
//FORT SYSIN.DD

Вот что я помню

надо свою лепту внести

Первая перфокарта - JOB, затем EXEC, а потом уже и DD

Невозможно передать словами мой шок когда я после нескольких лет работы с VM вернулся к MVS, к JCL. Перед этим я считал себя весьма опытным в JCL. Но то во что JCL (плюс JES) оказался развит к настоящему времени - не поддается описанию. На звание специалиста я удже не претендую. Единственно что могу - это решать проблеммы и находить нужные возможности.
Такого языка управления пакетными заданиями как в MVS нет больше ни на одной платформе.
А JOB, EXEC и DD до сих пор естественно там.

[Dmitry67]

zVlad, я не понял последный пост
То есть JCL еще там есть ? И используется ?
То есть Ваш пост это ирония ?

[zVlad]

zVlad, я не понял последный пост
То есть JCL еще там есть ? И используется ?
То есть Ваш пост это ирония ?

Дмитрий, Вы меня все сремя поражаете непредсказуемостью Вашей реакции.
Не только JCL, но все что было создано за 40 лет сохранено и многократно развито.
Попробую предсказать Ваш следующий пост. Вы наверное скажете что пакетная обработка - это безнадежно устаревшая технология? Осмелюсь с Вами не согласиться. Пакетная обработка была, есть и будет. Всякая регулярная работа с продолжительностью больше некоторой уместно выполнять как пакетное задание.
Может быть я не прав и Вы спросите "Что и перфокарты до сих пор используются?" Нет, перфокарты уже не используются, хотя опять же для совместимости с программами, написанными может быть в 1964 году, в VM-е поддерживаются виртуальные перфокарточные устройства. Которые и в современных программах используются для простейшего обмена данными между виртуалными машинами. Представляете, я работаю на ВМ "VOVA", а Вы на ВМ "DIMA". Я хочу послать Вам данные. Есть много способов как это сделать. Простейший команды:

SPOOL PUNCH TO DIMA
PUNCH MYFILE TEXT

А Вы на своей ВМ сначала получаетет сообщение что Вам на Ваше устройство считывания перфокарт поступил файл и Вы:

READ VOVA TEXT

А JCL - это возможность использовать все возможности системы в пакетном задании, а также возможность управления самими пакетными заданиями. Пример:

//SYSIN DD DSN=/usr/lpp/Internet/WebApps/Doc/pub/index.html

С нетерпением жду Ваших дальнейших, оригинальных вопросов, Дима.

[Dmitry67]

Разумеется нужно иметь возможность выполнять чтото долго и неинтерактивно.

Но при чем здесь такой ужас как JCL ? То же самое можно добится и более новыми средствами. Вы соглсаситесь что синтаксис его ужасен ?

Давайте сравним с UNIX например
Типа скопировать из каталога все файлы содержащие подстроку, скопировать в другой и назначить права какие нибудь. Сравним какой нибудь шелл на UNIX и JCL

[Palych]

Интересную Вы предложили метафору. Только вот насчет касты жрецов Вы угадали с точностью до наоборот. Поясню.
Большинству МФ специалистов (мне в том чмсле) не чужды другие технологии, другие системы, новые языки и т.д.
...
А вот не МФ специалисты при упоминании МФ как правило могут произнести внятно ровно одну фразу - "это дорого"...

Ну так на то они и жрецы чтобы обладать знаниями, недоступными толпе.
В свою очередь толпа всегда подозревает, что обьем етих знаний не так уж и велик и глубок, и жрецы просто водят их за нос, стараясь сохранить привелегированное положение.
Проверить ето предположение толпа не может, поетому вынуждена мириться с етими "выскочками", а фразы типа "жрецы маст дай" произностатся на как бы в сторону, невзначай - а вдруг и вправду превратят в лягушку...
Так и достигается баланс и всеобщая гармония. ...До тех пор пока одна из сторон не перегибает палку. Тогда или МФ оказываются на свалках, или вся инфраструктура предприятия рушится...
Так что - моя метафора всесильна, потому что она верна!

[zVlad]

Разумеется нужно иметь возможность выполнять чтото долго и неинтерактивно.

Но при чем здесь такой ужас как JCL ? То же самое можно добится и более новыми средствами. Вы соглсаситесь что синтаксис его ужасен ?

Давайте сравним с UNIX например
Типа скопировать из каталога все файлы содержащие подстроку, скопировать в другой и назначить права какие нибудь. Сравним какой нибудь шелл на UNIX и JCL

What you mean saying "..такой ужас как JCL ".
"...Вы соглсаситесь что синтаксис его ужасен ?" Of course, I don't agree. For those sizes and funtionalities for which JCL syntax was invented - it is the best. I would say JCL (by the way there is also JECL - for JES2) is huge, that's true. But look at generic description of DD card:

12.1.1 Syntax

// [ddname ] DD [positional-parameter][,keyword-parameter]...[comments]
[procstepname.ddname]

, or JOB card:

20.1.1 Syntax
//jobname JOB positional-parameters[,keyword-parameter]... [comments]│
//jobname JOB

Don't you think it is real simple and clear syntax. What you need to know is just what parameter(s) is to be used. For DD card, for example, you can choose from 63 parameters some of them could have their own parameters.

Example for "...Типа скопировать из каталога все файлы содержащие подстроку, скопировать в другой и назначить права какие нибудь. Сравним какой нибудь шелл на UNIX и JCL :" would be useless because JCL is strictly Job Control Language. JCL doen't have anything to copy or to change rights nothing like that.
I could give an example of how to create batch job which will run program (or utility) to copy files and change rights. But I'm afraid it is not what you actually meant, isn't it? Unix script isn't an analog for JCL at all.
But what you mean as an analog for Unix script should be TSO CLIST or REXX and could look like:

/*REXX*/
/* */
if syscalls('ON')>3 then
do
say 'Unable to establish the SYSCALL environment'
return
end

mode = 777
uid = 'dima'
"mkdir /u/sivb/" mode
"chown /u/sivb (uid)"

IP.2 = "192.112.112.20"
SAY 'USERID TO MAKE FTP CONNECTION:' USERID()
QUEUE ascii
Queue "cd /u/sivb/
QUEUE "get dinosaur_1_1.jpg"
QUEUE quit
"FTP "IP.2
"chattr dinosaur_1_1.jpg" st_mode 775

EXIT

[Dmitry67]

Ну если JCL это не шелл то для чего он нужен ?
Что он может дать ?
Это просто навороченная команда порождения процесса где задается куча параметров ?