在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:db2引擎SQL错误，SQLCODE=-922，SQLSTATE=42505，错误标记=PLAN ACCESS；00F30034错误代码=-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 )***
根据手册，SQLCODE-922意味着您没有对资源使用的授权，在您的特定情况下是PLAN ACCESS。关于决议，上述手册建议(重点矿)：
如果错误类型为"PLAN ACCESS"，则与此连接关联的授权ID无权使用指定的计划名称，或者指定的计划名不存在请与系统管理员联系。
这是对注释(而不是原始问题)的回答：
谢谢Bruce。。。。但是，既然SignId是我所在地区的ID，那么请求访问它是否明智，或者我需要担心什么从安全角度来看？我是CICS的新手，仍在努力了解它。为什么JDBC连接需要访问计划(默认)
以上内容可以扩展为一个单独的问题。
Cobol/Cics/Db2的解释
我的知识是10年前的，以Cobol Cics为基础，与此同时，情况发生了变化。我将尝试以一种非常简单的方式解释Cics-CobolDB2中的工作原理(可能会有一些小的错误或更改)。希望这将提供一些后台信息
在MainframeCobol DB2中，数据库访问类似于java中的SQLJ。当编译Cobol/DB2程序时，它被拆分为2；Cobol部分和SQL部分(DBRM)。SQL部分(DBRM)，实习生通过绑定成为包/计划。包/计划是一种特殊类型的CompiledSQL过程的奇特名称。
So
Calls Accesses DB
Cobol-Program <-----------> Package/Plan <-----------------> Data Base
(Special SQL Procedure)
在Cobol/DB2中，需要数据库访问的包/计划。所发生的事情是，您允许用户访问某些程序(可能通过菜单系统)，而拥有实际DB访问权限的是程序/计划。计划只允许获得他们需要的东西。用户不需要(通常也不会)任何DB访问权限。
Java
您的Java访问是建立在现有Cobol接口之上的。
据推测，您的Java SQL正被传递给执行DynamicDB2调用的Plan(SQL过程)。正是此计划(SQL过程)需要数据库访问。
使用SQL过程进行数据库访问可能是值得的？？？
为什么Cobol/DB2以这种方式工作
这听起来可能很复杂，但：
在Cobol的许多站点，这在很大程度上是自动的。通常有编译/绑定程序设置，一切自动发生
通常，对于Cobol计划，数据库访问路径是在
Bind时间制定的。Cobol/DB2将继续使用相同的访问路径，直到下一个Bind。这就形成了一个稳定的系统。我在一家从Mainframe Cobol/DB2迁移过来的公司工作到Unix/Oracle软件包。在大型机上，大多数情况下，每件事都能顺利运行，而在Oracle中，每隔10分钟的程序就会运行6个小时，并造成混乱。
如果您使用JDBC，DB2将在运行时评估访问路径
对于Cobol/DB2来说，这一切的工作方式有着真正的原因。这是一个遗憾的是，SQLJ没有成功。它与CICS的配合会比JDBC更好。
链接
一些链接可能是有用的
- 在db2中尝试Google程序和计划之间的关系
- 计划与一揽子计划的说明
- 编译/绑定/计划
- 更多计划/套餐
JDBC不同于从z/OS获取数据库信息的许多其他方法，因为它是动态的，即查询不提前知道，并且在运行时进行解析和分析(尽管像PreparedStatement这样的东西允许进行一些预编译，而且通常更安全)。
相比之下，大多数COBOL等SQL调用(以及SQLJ)都是静态。程序被编译，它们包含的SQL语句同样作为包(命名为<collectionID>.*以将它们区分为不同的集合)绑定到数据库，然后在运行时由ID引用。包被绑定到计划中。，引用一组包的高级方式。在每一个级别上，都可以进行大量的自定义，以及可以应用的访问控制权限——正如你所知，因为这就是你所遇到的。
您可能认为静态方式是在z/OS上与DB2交互的"默认"方式。这意味着，即使您可能使用动态SQL(JDBC)，它实际上仍然使用包和计划，但在这种情况下，包能够执行动态SQL。默认情况下，包的集合ID和计划名称都是NULLID。我怀疑您没有使用此计划的权限。
我建议您自己或与数据库管理员一起需要采取的步骤是：
- 确保数据库已设置为启用JDBC。有人已经在那个数据库上使用JDBC了吗？检查JDBC包是否已经存在，很可能集合ID为
NULLID。如果没有，请按照说明启用它们，特别要注意DB2Binder步骤 - 确保你有能力使用该计划。我所说的"您"是指CICS区域运行请求的用户ID。可能是因为该用户没有使用
NULLID计划的权限 - 如果所有其他方法都失败了，请进行更深入的问题诊断。查看请求是否记录在数据库的作业中，以及是否可以查看请求是使用哪个计划发出的。在Java端设置跟踪，查看请求是如何发出的