Java в CICS - соединение JDBC типа 2 выдает ошибку SQLCODE = -922, SQLSTATE = 42505, токены ошибок = PLAN ACCESS; 00F30034

В коде Java при попытке установить соединение с помощью драйвера типа 2.

String jdbcUrl = "jdbc:default:connection";

Connection connection = DriverManager.getConnection(jdbcURL);

Я получаю сообщение об ошибке ниже.

com.ibm.db2.jcc.am.SqlSyntaxErrorException: [jcc] [50053] [12311] [3.69.56] Исключение T2zOS: [jcc] [T2zos] T2zosConnection.flowConnect: execConnect: 1425: ошибка SQL механизма DB2, SQLCODE = -922, SQLSTATE = 42505, токены ошибок = PLAN ACCESS; 00F30034 ERRORCODE = -922, SQLSTATE = 42505

Мои свойства DB2Conn:

 i DB2Conn                                                                     
 STATUS:  RESULTS - OVERTYPE TO MODIFY                                         
Db2conn        Accountrec( Txid )     ***Authid(          )  Authtype( Sign )***  Comauthid(          )   Comauthtype( Cuserid )  Comthreadlim( 0001 )   Comthreads(0000)  Connecterror( Abend )   Connectst( Connected )                                                      
Db2groupid(      )   ***Db2id( DB2  )***   Db2release(1010)  Drollback(Rollback)                                                         
Msgqueue1( CSMT )  Msgqueue2(      ) Msgqueue3(      ) Nontermrel( Norelease )                                                     
Plan( DEFAULT  )  Planexitname(          )  Priority( Equal )  Purgecyclem( 00 )                                                           
Purgecycles( 30 )        Resyncmember(              )   Reuselimit( 01000 )                                                         
***Signid( ABCDCICS )***

java jdbc db2 db2-zos cics
person kushwah_a    schedule 03.02.2017    source источник
comment
Попробуйте поискать в Google SQLCODE 922: google.com.au/   -  person Bruce Martin    schedule 03.02.2017
comment
Спасибо, Брюс .... Но поскольку SignId - это идентификатор моего региона, целесообразно ли запрашивать доступ к нему или мне нужно беспокоиться о чем-то с точки зрения безопасности? Я новичок в CICS и все еще пытаюсь в нем разобраться. Зачем соединению JDBC нужен доступ к плану (по умолчанию)?   -  person kushwah_a    schedule 03.02.2017
comment
Я добавил ответ ниже   -  person Bruce Martin    schedule 04.02.2017
comment
Был ли дан ответ на этот вопрос одним из приведенных ниже ответов?   -  person Ben Cox    schedule 12.05.2017

Ответы (3)


arrow_upward
1
arrow_downward

Согласно руководству, SQLCODE -922 означает, что у вас нет разрешения на использование ресурса, в вашем конкретном случае - PLAN ACCESS. Что касается разрешения, вышеупомянутое руководство предлагает следующее (выделено мной):

Если тип ошибки - «ДОСТУП К ПЛАНУ», то ID авторизации, связанный с этим подключением, не авторизован для использования указанного имени плана или указанное имя плана не существует. Обратитесь к системному администратору.

person mustaccio    schedule 03.02.2017
comment
Да, руководство я видел, но я хочу знать, какие именно требования мне нужно предъявить системному администратору. Должен ли я беспокоиться о безопасности транзакций и безопасности пользователей по отношению к DB2 Connections, или я могу просто попросить предоставить доступ к ABCDCICS, который является идентификатором моего региона? - person kushwah_a; 03.02.2017

arrow_upward
0
arrow_downward

Это ответ на комментарий (а не на исходный вопрос):

Спасибо, Брюс .... Но поскольку SignId - это идентификатор моего региона, целесообразно ли запрашивать доступ к нему или мне нужно беспокоиться о чем-то с точки зрения безопасности? Я новичок в CICS и все еще пытаюсь в нем разобраться. Зачем соединению JDBC нужен доступ к плану (по умолчанию)

Вышесказанное можно было бы развить в отдельный вопрос.

Расшифровка Cobol / Cics / Db2

Моим знаниям 10 лет, они основаны на Cobol-Cics, но за это время все изменилось. Я постараюсь очень просто объяснить, как все работает в Cics Cobol DB2 (могут быть незначительные неточности или изменения). Надеюсь, это даст некоторую справочную информацию

В мэйнфрейме Cobol DB2 доступ к базе данных аналогичен SQLJ в java. Когда программа Cobol / DB2 компилируется, она делится на 2 части; Часть Cobol и часть SQL (DBRM). Часть SQL (DBRM), которую стажер выполняет Связывание, становится Пакет / план. пакет / план - это красивое название для особого типа Compiled процедуры SQL.

 So
 
                      Calls                      Accesses DB
     Cobol-Program <-----------> Package/Plan  <----------------->   Data Base
                           (Special SQL Procedure)

В Cobol / DB2 это Пакет / План, которому нужен доступ к базе данных. Происходит то, что вы даете пользователям доступ к определенным программам (возможно, через систему меню), и именно программы / планы имеют фактический доступ к БД. Планы получают доступ только к тому, что им нужно. Пользователям не нужен (и обычно не предоставляется) доступ к БД.

Ява

Доступ к Java осуществляется поверх существующих интерфейсов Cobol.

Предположительно ваш Java SQL передается в Plan (процедура SQL), который выполняет Dynamic вызов DB2. Именно этот план (процедура SQL) требует доступа к базе данных.

Может, стоит использовать SQL-процедуры для доступа к БД ???

Почему Cobol / DB2 работает именно так

Это может показаться запутанным, но:

  • В Cobol на многих сайтах все происходит автоматически. Обычно настраиваются процедуры Compile / Bind, и все происходит автоматически.

  • Обычно для планов Cobol пути доступа к базе данных разрабатываются в Bind раз. Cobol / DB2 будет использовать те же пути доступа до следующего Bind. Это делает систему стабильной.

    Я работал в компании, которая перешла с мэйнфреймов Cobol / DB2 на пакет Unix / Oracle. На мэйнфреймах по большей части все работало без сбоев, в то время как в Oracle время от времени 10-минутная программа выполнялась в течение 6 часов и приводила к хаосу.

  • Если вы используете JDBC, DB2 будет оценивать пути доступа во время выполнения.

Для Cobol / DB2 есть реальные причины того, как все это работает. Жаль, что SQLJ не подействовал. Он бы лучше работал с CICS, чем с JDBC.

Ссылки

Некоторые ссылки, которые могут быть полезны

person Bruce Martin    schedule 04.02.2017

arrow_upward
0
arrow_downward

JDBC отличается от многих других методов получения информации о базе данных из z / OS, потому что он динамический, то есть запросы не известны заранее и анализируются и анализируются во время выполнения (хотя такие вещи, как _ 1_ позволяет также выполнить некоторую предварительную компиляцию как в целом безопаснее).

Напротив, большинство вызовов SQL (а также SQLJ) COBOL и т. Д. Являются статическими. Программа компилируется, и в равной степени содержащиеся в ней операторы SQL привязываются к базе данных как пакеты (которым присвоены имена <collectionID>.*, чтобы различать их по разным коллекциям), а затем упоминается во время выполнения по идентификатору. Пакеты связаны в планы., Высокоуровневые способы обращения к набору пакетов. На каждом из этих уровней можно выполнить множество настроек, а также применить разрешения на управление доступом - как вы знаете, поскольку именно с этим вы сталкиваетесь.

Статический способ - это то, что вы можете рассматривать как «стандартный» способ взаимодействия с DB2 на z / OS. Это означает, что даже если вы используете динамический SQL (JDBC), он по-прежнему использует пакеты и планы, но в этом случае пакеты могут выполнять динамический SQL. По умолчанию идентификатор коллекции пакетов и имя плана равны NULLID. Я подозреваю, что у вас нет доступа для использования этого плана.

Я предлагаю шаги, которые вам нужно предпринять самостоятельно или вместе с администратором базы данных:

person Ben Cox    schedule 13.02.2017