Позвольте задать несколько вопросов:
- "документ" трактуется как неструктурированная последовательность байтов?
- наборы данных какой организации и структуры предлагается использовать для хранения документов? если документ рассматривается как неструктурированная последовательность байтов, то наиболее подходящей организация IMHO это VSAM LDS, хотя можно использовать и PS RECFM=V.
- Не будет ли достаточно набора VSAM KSDS для хранения "карточек документа"?

Сам по себе документ является XML документом, композитным (состоит из других XML документов). Включает в себя как текстовые элементы так и графические. 
Также допускается применение документов PDF, MS Word, OpenOffice, RTF, да что угодно.
У нас такого зоопарка пока нет. Но не у нас такой зоопарк есть. Описание то сделано с живой системы.
Пока предполагается к использованию последовательный набор данных с RECFM=U.
Честно говоря, не вижу смысла во VSAM LDS - на z/OS эти документы обрабатывать не предполагается. Их надо отдать (ftp) на клиентскую часть (MS, Linux) и пусть с ним делают, что хотят. Зачем VSAM?
Для реализации "карточек" документов можно использовать и KSDS. В оригинале используется СУБД не от IBM, и среда исполнения (монитор транзакций, считай) не от IBM. Можно сделать на KSDS, с использованием любого монитора транзакций. Но смысла нету - проще взять продукт, имеющий и СУБД, и монитор транзакций, как и поступили при создании системы, с которой я это "срисовывал". Учитывая некоторые особенности рабочей нагрузки (на эту тему есть Концепция развития, уже готова, обсуждается, если вычищу из неё привязку к конкретному заказчику, то можно будет опубликовать и здесь), и структуру входных документов (иерархическая, довольно сильно разветвлённая), и порядок работы с документами, то лучше не брать РСУБД (этот вариант уже сделан, ничего хорошего), а взять то же, что в уже работающей системе, ну или IMS от IBM (и СУБД, и монитор транзакций). В случае с IMS встаёт один технологический вопрос - отсутствие LIKE предикатов, но зато под z/OS есть реализация PCRE (perl-compatible regular expression), что куда как круче чем "убогий" (в сравнении)  LIKE. Так что вопрос решаемый.
Так что по "карточкам" документов всё, имхо, зависит от самих документов, их структуры и от порядка работы с ними - от запросов к ним, как будут искать. В моём случае 99% запросов примитивны, по 4 атрибутам. Но 1% гораздо сложнее, поиск по множеству атрибутов, при чём в каком-то случае допускается одна ошибка в атрибуте, в другом случае допускается две ошибки в атрибуте. Так что кроме PCRE в полный рост встаёт что-то типа алгоритма Дамерау-Ливенштайна.
Если есть желание создать свою "субд" - можно использовать только VSAM и монитор транзакций.

спасибо.
 VSAM LDS с концептуальной точки зрения наиболее точно соответствует неструктурированной последовательности байтов (файлу) и имеет незначительные накладные расходы. При использовании последовательных наборов (RECFM=U или V) меня немного смущает то, что файлу придается искусственная структура, которой у него изначально не было (кстати, а какой BLKSIZE предполагается?) Не совсем понятно, чем U лучше чем V? Отсутствием RDW?
Каким образом обеспечивется целостность данных? Не рассматривалась ли возможность помещения файла в какой-нибудь контейнер перед передачей с целью обеспечения как его целостности, так и аутентификации (например, сжатие rar/zip/bzip/terse...)? IMHO "карточка документа" есть мета-данные, не рассматривалась ли возможность хранить их в виде XML?

В текущей (описанной мною) реализации клиент на windows получает файлы (MS Word, допустим) посредством ftp, да и отправляет их на "хранение" на мейнфрейм тоже посредством ftp. В нашей реализации клиент windows будет получать файл по ftp, есть объяснение, как это сделать с VSAM ? Ну или сформулирую по-другому - зачем здесь VSAM? 

Но windows не смущается, а получив по ftp свой же файл, работает с ним, не замечая того факта, что пока файл был набором данных z/OS , у него была какая-то там неведомая windows структура.

В описаной системе регламентом, приложением, довольно интересно и, я бы сказал, своеобразно но просто. В нашей системе в зависимости от того, "кто" будет создавать набор данных (windows или z/OS), будет и разный подход. В случае если windows создаёт набор данных (по ftp), то события создания набора данных и создания карточки документа будут асинхронны, и целостность будет обеспечиваться логикой приложения (регламентом работы приложения), в случае если windows просто вызывает транзакцию IMS, передавая ей входящий документ формата XML, то мы (вместе с art) рассматривали схему обеспечения целостности (соответствие между карточкой документа и набором данных) и там всё совсем просто. Если именно такого рода целостность имелась в виду.

Нет, за ненадобностью, и за противоречие регламенту - входящий документ с ЭЦП должен быть сохранён как есть, без преобразований. Поместить в контейнер - надо переподписать новый документ. Конечно, можно, предусмотрев операцию в регламенте (выделив для такого рода специальную ЭЦП) но зачем? Смысл? 

Особенно прикольно будет в нашем случае - на входящие XML данные мы создаём XML метаданные
Здесь достаточно вспомнить, зачем нужна карточка документа. Она нужна для того, чтобы иметь возможность составить список оригинальных документов, удовлетворяющих критериям отбора, заданным пользователем, и предоставить список пользователю, в ожидании, какой оригинал он затребует. То ест карточка документа состоит из поисковых атрибутов. И составить этот список во временные рамки согласно ТЗ, для количества одновременно работающих пользователей согласно ТЗ.
Если кто-то решит, что для составления карточки оригинального документа ему удобно использовать XML, хранить этот XML, и делать по нехилому  массиву хранящихся XML поиск (миллиарды, как порядок, за время жизни системы по ТЗ), для  составления списка документов, удовлетворяющих заданным критериям  - не вижу препятствий, если кому-то так будет удобно и будет работать эффективно.
Довольно простая прикидка показывает, что XML не самая компактная структура для хранения поисковых атрибутов. Можно компактнее. На таком количестве хранимых документов каждый  лишний байт это уже порядка гигабайты оверхеад. А XML даёт куда как больше "лишних" байт.
Но вполне возможно, что это допустимо в каких-то случаях, всё может быть. Но это явно не наш случай.

 
это рассуждения с позиций "идейной чистоты") понятно, что получив оригинальный файл, пользователю совершенно безразлично, где и как он хранился.


Не совсем понятно, каким образом помещение документа в конверт (контейнер) может противоречить регламенту. При передаче документа с помощью ftp он неизбежно преобразуется в транспортную форму (пакеты TCP), и это регламенту не противоречит... Использование же такого контейнера, как, например, amaterse/pcterse, позволит использовать для хранения набор нанных PS RECFM F LRECL 1024, что IMHO несколько лучше, чем V или U.
Извините, если все мои рассуждения выглядят наивно, так как я не знаком со спецификой задачи.

Да познакомится с задачей можно (в индивидуальном порядке, несколько наших товарищей уже познакомились).
Рассуждения не наивные, отнюдь, идея мне понравилась, сейчас буду её думать... Ведь после извлечения из контейнера, пользователь (с помощь приложения) может проверить ЭЦП, и удостовериться в целостности файла... Идея здравая. Закрепить в регламенте... И вполне может быть.

мне часто приходится решать, так сказать, обратную задачу, а именно, использовать PC для хранения данных z/OS (обычно, как промежуточное хранилище при передаче данных с одного z/OS на другой, когда прямая связь между этими z/OS невозможна). В этом случае  контейнер необходим. Это может быть:
- TRANSMIT (PS, PDS, PDSE);
- AMATERSE (PS, PDS, PDSE);
- IDCAMS + AMATERSE (VSAM);
- DFDSS + AMATERSE (универсальный способ);
- GIMZIP (решение от IBM, формат Electronic Service Delivery).

осталось только найти такое решение, которое бы было достаточно простым, позволяло делать на PC то, что можно сделать на PC, не нагружая мейнфрейм.
Достаточно простым - ну, например, для применения в .net среде.
С этой точки зрения может оказаться проще использовать, допустим, связку GZIP и BASE64.
Надо думать и искать.

IMHO ZIP+BASE64, так как известный мне портированный GZIP в z/OS оперирует только с файлами, но не с наборами данных, так что в случае использования GZIP+BASE64 придется выполнять дополнительные телодвижения в виде OGET/OPUT.

Спасибо за предупреждение, не придётся самому рыться.

увы, потому мы в свое время и не стали его использовать.... оказалось не очень удобно в нашей системе хранения документов.

кстати, по поводу BLKSIZE я встречал такую формулу
BLKSIZE = INT(trak/2/LRECL)*LRECL
то есть целое от пол дорожки разделить на LRECL умножить на LRECL

BLKSIZE=0 и пусть управление данными само считает оптимальный размер блока

Только для SMS-managed наборов, но это как раз и будет.

Кроме GDG, в документе для внешнего пользования по непонятным причинам (читай - по разгильдяйству) отсутсвует пункт про важность SMF в деле восстановления каталога. Для тех, кто в теме, сие и так понятно, но в аннотации указано, что документ для тех, кто не в теме, то есть для наших молодых коллег-ИБМеров, кторые не хеллоуворд и всё такое прочее Для суровых, так сказать, ИТшников