Остается непонятным также, как активировать старую среду для модуля, компилированного в MVS, почему STEPLIB недостаточно. Quote Akonev: Или тащить среду исполнения в каждую новую версию MVS/OS3890/zOS. Последнее проверено и работает для старого советского PL/I даже в последних версиях z/OS.
Возможно, Александр расскажет нам подробнее, как именно это достигается?
Речь шла именно о старом советском PL/1 который был унаследован от TKS системы. там все достаточно просто, в LNKLST или в STEPLIB цеплялась библиотека (типа PL1.LINKLIB) с модулями, префиксы которых были IHE и IEM. C исполняемыми модулями никаких манипуляции не производилось. Хотя имеется и прецедент использования версии V2R3M0 Здесь возможностей для путаницы гораздо больше, загрузочных библиотек аж штук по-моему семь. PLI.V2R3M0.SIBMBASE и PLI.V2R3M0.PLIBASE цепляются к SYSLIB при компиляции, а для STEPLIB-а должны использоваться PLI.V2R3M0.PLILINK и PLI.V2R3M0.SIBMLINK Скорее всего у топик стартера в LNKLST указана CEE.SCEERUN, а указание SIBMBASE было ошибочным А за это
Григорию за ссылку на APAR - спасибо, отлично, как всегда .
По существу вопроса имею заявить следующее. Некоторое время назад имел опыт переноса старой задачи в zOS. В силу древности PL тащили вместе с загрузочными библиотеками и всей средой выполнения, несмотря на наличие в новой системе LE. То есть делали именно то, что предлагал Александр. Задача заработала, да, но обработка исключительных ситуаций в новой системе в процессе работы задачи отличалась от старой системы. Причиной было то, что куча модулей LE было в различных частях LPA, что неудивительно, и получали управление ДО того, как могли бы получить управление одноименные модули в старой перетащенной среде выполнения PL. Правда, до потери сообщений дело не дошло, чего не было, того не было, а вот текст сообщений в разных системах отличались. Так что перенос среды выполнения не всегда помогает, а курочить систему, подменяя в LPA новые библиотеки старыми было страшновато. В общем, смирились с происходящим и ограничились нормально работающей программой, ибо задача стояла не отлов исключительных ситуаций, а избегание таковых.
вот это странно и, по-моему, серъезнее потери сообщений. У LE чуть ли не сто run-time параметров, и их применение довольно часто помогает при поиске ошибок. На данный момент создается впечатление, что у Вас работает какой-то конгломерат из старых (PL/I 2.3) и более новых (MLE) run-time модулей.
Quote
akost: курочить систему, подменяя в LPA новые библиотеки старыми было страшновато
а, собственно, почему? run-time PL/I на работоспособность системы влиять не может. Только до полного выяснения ситуации я бы не подменял новые библиотеки старыми а просто убрал бы все, касающееся PL/I из LPA и LNKLST, что и предлагаю сделать
P.S. Вы переход на более современный компилятор (PL/1 Enterprise или хотя бы MLE PLI for MVS and VM) не рассматриваете? Или мешают нетехнические проблемы?
Сообщение отредактировал Gregory - Пт, 01.06.2012, 10:59
Gregory, akost, AKonev, спасибо вам всем за ответы, коментарии. Похоже проблемы-то и не было. Решение лежало на поверхности. Я ступила слегка. Просто надо было в LNKLST поменять местами PLI с CEE. Gregory, Вы были правы. Спасибо всем!
IBM537I 'ONCODE'=8097 DATA EXCEPTION IN STATEMENT 188 AT OFFSET +00035E IN PROCEDURE WITH ENTRY K0102A0 ____________________________________________________
Видите ли, Gregory, постепенно вымираем. Вернее нас убивают потихоньку. Новых разработок нет, не позволяют. Что есть, все в SAP на HP! Прикладники только на старые программы "заплаты ставят" и кое-где подправляют. В основном выполняем старые загрузочные. Но пока у них идет процесс перевода в SAP, то мы поддерживаем работоспособность, с надеждой, что со временем стратегия может измениться (по отношению к MF)
