Хотя у актуальной версии zOS несчастливый номер, в ней появились некоторые вполне счастливые возможности.
Среди них (дальше огромная цитата):
JCL cataloged and in-stream procedures may now have data set as DD * or DD DATA included
INCLUDE members may also contain DD * or DD DATA data
(the above two points are for JES2 shops only)
The JOB statement adds parameter JOBRC=MAXRC JOBRC=LASTRC JOBRC=(STEP,stepname[.procstepname])
DD statements for multiple volume tape files may now contain: FREEVOL={END|EOV} to indicate when a volume should be released for use by another job
ISPF / Dialog Manager
* EDIT and VIEW support user written line command macros * DIRLIST service has new parameter FROM(pathname) for positioning list on first display * DSINFO and LMDLIST populate two new dialog variables: ZDSCJOBN - create job name; ZDSCSTPN - create step name * DSLIST (ISPF 3.4) has new line command: AL - allocate a file with attributes of filename command is typed over
The vi and ex commands support two new flags:
-B to suppress automatic codepage conversion for tagged files -W to identify codepages for data and editor for non-tagged files
z/OS UNIX has a new command, 'script' that will capture all commands and responses in a text file for later processing
The z/OS UNIX 'tsocmd' command will propogate file descriptors 10-99 to the TSO command processor if you set BPXWRFT=YES
LE (Language Environment) enhances the CEEPIPI services by supporting multiple 'main' environments and by providing calls to set and get the CAA user word value
ну так постепенно, неспеша вносятся изменения в святую святых - JCL. еще пару десятков лет, и разработают новую вменяемую файловую систему (наряду с традиционной), чтобы не резать сотни дисков и преодолеть ограничение в 65 000 дорожек для набора данных...
Allocating a Large Format Data Set. Large format data sets are sequential data sets that can grow beyond 65 535 tracks (4369 cylinders) |up to 16,777,215 tracks per volume. Large format data sets can be system-managed or not. You can allocate a large format data set using the DSNTYPE=LARGE parameter on the DD statement, dynamic allocation (SVC 99), TSO/E ALLOCATE, or the access method services ALLOCATE command. The SMS data class can also provide the DSNTYPE value of LARGE, if the data set does not have another DSNTYPE specified or a DSORG value other than PS or PSU Правда, как всегда немного условностей, читать такой файл может любая программа, а вот для того что бы делать запись в него, надо специальным образом программировать, используя расширенный DEB. Да и логические диски теперь резиновые, опять же CU должен быть 2107.
ключевое место тут - sequential data sets а если DA?))) на которых стоят важные серьезные продукты, типа ADABAS. Могу еще добавить. У нас есть системы, где лежит много мелких наборов на диске - около 40 тыс на диске 3390-9. попробовали поиспользовать диски 3390-27, и файловая система (vtoc+vvds) не дала использовать весь такой большой диск - в книжке только про использование VSAM на таких дисках. ну и так далее.
Ну да, конечно, с ограничениями на BDAM согласен, их столько, что даже надежды на их будущее снятие нет. Опять же метод доступа входит в перечень IBM, не рекомендованного к использованию. А ликвидировать BDAM, как это было сделано с ISAM, у IBM вряд ли получится.
Да? Я предвкушаю. Но там будет еще интереснее - у меня из 4 миллионов единиц хранения около 2 с половиной миллионов имеют размер меньше 100 килобайт, то есть пара дорожек. Для традиционных дисков выделение места идет до дорожки. А на EOV (вроде!) до цилиндра. То есть ради 60 килобайт брать более 700 Кб, почти на порядок больше. Если бы это было на RVA или на EMC, то пофиг, они уплотняют на уровне дисков и хвосты не простаивают. А на DS8X00 - статическое выделение, так что места жалко!
PDSE изучался, не вариант из-за проблем с динамической реорганизацией набора - нужно тогда на каждый набор отдельный диск, и еще нужно будет хранить где-то соответствие нашего файлика тому набору, где он лежит, то есть дублировать каталог. Тут уж рукой подать к BLOB, если уж быть последовательным. Ну нафиг.
и чем это проблемнее чем перегон сотни файликов? И чем вообще плох один набор на одном диске, если диск большой? И почему не работать с мемберами напрямую? Зачем нужны соответствия? С мемберами только одна проблема, их нельзя апдейтить и удлинять одновременно. (разное открытие)
Главная проблема при работе с разделами библиотечного набора состоит в том, что нужно задавать имя набора в виде имя-библиотеки(имя-раздела). Это другая нотация - сейчас просто хранятся длинные имена последовательных наборов в виде уровень1.уровень2.уровень3 и так далее. Для этого надо будет переделывать приложения, коих, для доступа к хранилищу, много. Зато проблема удлинения по месту меня вообще не пугает, у нас просто убивают набор и пересоздают заново с новым содержимым и старым именем.
Полистал тут немножко книжки Description: Starting with z/OS® V1R12, additional non-VSAM data set types in the extended addressing space (EAS) are supported. This includes support for sequential (BASIC or LARGE), partitioned (PDS or PDSE), Catalogs, and BDAM data sets in EAS. Before z/OS V1R12, any program trying to open one of these types of non-VSAM data sets that have been allocated with extended attribute DSCBs (format 8 DSCB from a z/OS V1R12 system) failed with abend IEC144I 313-0C. Now on a z/OS V1R12 system, applications can open these non-VSAM data sets allocated with extended attribute DSCBs with standard BSAM, BPAM and QSAM access. In many cases, application programs will function as usual. However, application programs that reference the data set extents found in the DEB or access the DSCB or its extents must change to either support format 8 DSCBs and 28-bit cylinder addressing or to abend when they encounter such data sets.
DA позволяет с помощью EXCP-програм делать охрененно быстрый доступ к данным, потому и жив до сих пор, и применяется в ADABAS и других продуктах. При этом если ISAM полностью перекрывается VSAM без потери качества (ну правда, какая разница - виртуальные номера блоков в индексах или физические? виртуальные даже удобнее - можно набор двигать, и вообще. но логика поиска остается железной и программы в реальной жизни не очень нуждаются в переделке), то альтернативы BDAM просто нет. VSAM-ом такое можно подыграть очень ограниченно, при этом придется полностью изменить логику доступа к данным, выкинув EXCP. А вот VBS - действительно архаика, была придумана не от хорошей жизни в ранних системах хранения с короткой дорожкой.
В Linear программам надо уходить. Прыгай себе страницами и работай как с памятью. И двигать все можно. А для пользователей по старинке FB80. (хоть бы до 160 растянули)
RRDS, VRRDS отличная замена BDAM в стиле REGIONAL(1), для PL/I программ изменения вообще будут минимальны. Насчет linear согласен, а для вновь разрабатываемых программ использовать BDAM, по-моему, неправильно.
Спасибо за обзор!
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
