(1) >>-java--com.ibm.pdq.tools.StaticBinder-------------------------> (2) >-------- -url--jdbc--:--db2--:--//--server--+---------+--/--database--> '-:--port-' >-- -username--user-ID-- -password--password--------------------> >-- -archive-- -filename--+-.ear-+------------------------------> +-.jar-+ +-.war-+ '-.zip-' >--+------------------------------------------------------------------------+--> | (3) | +-| DBRM options |-------------------------------------------------------+ +- -bindOptions-- -"--bind-options--"--+-------------------------------+-+ | '- -verifyPackages--+-DETAIL--+-' | | '-SUMMARY-' | '- -verifyPackages--+-DETAIL--+------------------------------------------' '-SUMMARY-' >--+-----------------------------+--+----------------+----------> | .-FALSE-. | | (4) | '- -differenceOnly--+-TRUE--+-' '-| -grant |-----' >--+--------------------------+--+-----------------------+------> '- -isolationLevel--+-CS-+-' | (5) | +-RR-+ '-| Trace options |-----' +-RS-+ '-UR-' >--+--------------------------+-------------------------------->< | .-FALSE-. | '- -showDetails--+-TRUE--+-'
해당 옵션의 목록 및 설명은 BIND command를 참조하십시오.
StaticBinder 유틸리티가 DBRM 파일을 생성한 후 해당 파일을 데이터 세트에 복사해야 합니다. 디폴트 DBRM 데이터 세트 이름은 prefix.DBRMLIB.DATA이며 여기서 prefix는 사용자에 대해 TSO 프로파일에 지정된 상위 레벨 규정자입니다. prefix는 일반적으로 TSO에서의 사용자 ID입니다.
DBRM 데이터 세트가 존재하지 않는 경우 이를 작성해야 합니다. DBRM 데이터 세트에는 모든 SQL문을 보관하기 위한 스페이스 및 각 호스트 변수 이름과 일부 헤더 정보를 위한 추가 스페이스가 필요합니다. 헤더 정보에는 대략 각 DBRM에 대해 두 개의 레코드, 각 SQL 레코드용으로 20바이트 및 각 호스트 변수용으로 6바이트가 필요합니다. DBRM의 정확한 형식은 prefix.SDSNMACS 라이브러리에서 DBRM 맵핑 매크로인 DSNXDBRM을 참조하십시오.
다음 구문 다이어그램은 DBRM 파일 생성 옵션을 설명합니다.
.-FALSE-. >>- -generateDBRM--+-TRUE--+-- -outputDBRMPath--path-----------><
생성된 DBRM 파일의 루트 이름은 Configure 유틸리티를 실행할 때 지정한 루트 패키지 이름입니다.
디폴트는 FALSE입니다.
예를 들어, capture.pdqxml이라고 하는 pureQueryXML 파일에 대해 StaticBinder 유틸리티를 실행했다고 가정하겠습니다. 유틸리티는 패키지 MYPKGA, MYPKGB 및 MYPKGC를 작성합니다. 그러면 사용자는 capture.pdqxml에서 명령문 세트 MYPKGA를 수정하고 디폴트값 FALSE로 -cleanConfigure 옵션을 사용하여 이 파일에 대해 Configure 유틸리티를 실행합니다. Configure 유틸리티는 새 일관성 토큰을 명령문 세트에 지정합니다. 이 세트가 변경되었기 때문입니다. MYPKGA의 새 버전을 바인드하기 위해 다시 capture.pdqxml에서 StaticBinder 유틸리티를 실행하는 경우 -differenceOnly TRUE를 지정합니다. 유틸리티는 MYPKGA만 리바인드하고 다른 두 패키지는 리바인드하지 않습니다.
.-,--------------------. V | >>- -grant-- "--grantees--(----+-authorization-ID-+-+--) - "--->< '-PUBLIC-----------'
Linux, UNIX 및 Windows용 DB2 데이터베이스: USER, GROUP 및 ROLE 키워드를 사용할 수 있습니다. 이들 키워드에 관한 정보는 GRANT(패키지 특권) 명령문을 참조하십시오.
z/OS용 DB2: ROLE 키워드를 사용할 수 있습니다. 이 키워드에 관한 정보는 GRANT(패키지 특권)를 참조하십시오.
제한사항:
분리 레벨은 패키지에 있는 모든 SQL문에 적용됩니다. 분리 레벨을 JDBC 및 SQLJ용 IBM® 데이터 서버 드라이버의 Connection.setTransactionIsolation() 메소드를 통해 설정하면, pureQuery는 정적으로 실행된 명령문의 해당 분리 레벨을 무시합니다.
>>-+------------------------+--+---------------------------+--->< '- -traceFile--file-name-' | .-OFF-----. | '- -traceLevel--+-ALL-----+-' +-SEVERE--+ +-WARNING-+ +-INFO----+ +-CONFIG--+ +-FINE----+ +-FINER---+ '-FINEST--'
예를 들어, myApp.pdqxml이라는 pureQueryXML에서 구성 유틸리티를 실행했다고 가정합니다. 유틸리티를 실행했을 때 -collection, -pkgVersion 및 -rootPkgName 옵션에 대한 값이 제공되었으며 유틸리티는 이들 값을 pureQueryXML 파일에 저장했습니다. 이 파일의 이름을 지정하는 StaticBinder 유틸리티를 실행하면 유틸리티가 DB2 패키지를 작성합니다.
나중에 StaticBinder 유틸리티가 pureQueryXML 파일에서 작성한 패키지 목록을 볼 수 있습니다. 유틸리티를 실행 시, -verifyPackages 옵션을 사용하여 DETAIL 값을 지정하고 다시 파일 이름을 제공할 수 있습니다.
-collection, -pkgVersion 및 -rootPkgName 옵션 값이 StaticBinder 유틸리티를 이전에 실행했을 때와 같다면, 유틸리티가 해당 패키지를 찾아 나열합니다.
하지만 먼저 StaticBinder 유틸리티를 실행하고 -collection, -pkgName 및 -rootPkgName 값을 변경한 후 구성 유틸리티를 myApp.pdqxml에서 실행하면, StaticBinder 유틸리티가 이들 옵션의 새 값과 일치되는 패키지를 찾지 못합니다. 보고서에서 StaticBinder 유틸리티는 찾고 있는 패키지가 없다고 보고합니다.
구성 유틸리티를 pureQueryXML 파일에서 실행한 다음 StaticBinder 유틸리티를 실행한 후, 파일에서 다시 구성 유틸리티를 실행하지 않고 -collection, -pkgVersion 및 -rootPkgName에 대해 다른 값을 제공하지 않았다는 전제 하에서 -verifyPackages 옵션이 동작합니다.
이 옵션은 -bindOptions 옵션과 함께 지정할 수 있습니다. 하지만 StaticBinder 유틸리티는 패키지를 바인드하지 않습니다. 패키지를 작성할 때 이 옵션을 사용하여 콜렉션을 지정한 경우 -bindOptions만을 사용하여 검증할 패키지 콜렉션을 지정하십시오.