컴파일러 옵션을 사용하여 zOS에서 COBOL 프로그램을 컴파일합니다. PGMN (LM), DLL, EXPORTALL 이렇게하면 컴파일시 NODYNAM이됩니다. 이 컨텍스트에서 다른 부속 프로그램에 CALLS를 강제로 동적으로 (즉, 런타임에 해석) 강제로 사용할 수있는 다른 일부 매개 변수가 있습니까? 이것을 수행하기 위해 CALL 변수 이름 접근법을 사용할 수 있지만 DB2 호출 인터페이스 인 DSNELI와 같은 시스템 루틴에서는이를 수행 할 수 없다는 것을 알고 있습니다.DLL zOS dynamic
가져 오기 옵션과 관련이 있습니까?
감사합니다.
모든 DLL은 NODYNAM을 준수해야합니다. 이것은 피할 수 없습니다. NODYNAM을 사용하여 지적한대로 은 CALL var-name 접근 방식을 사용하여 동적 프로그램 호출을 배제하지 않습니다. 로컬에서 개발 한 루틴에 동적 호출 을 사용하는 경우에는 프로그램에 정적 링크 된 모듈이없는 모든 이점을 유지합니다.
CALL 'DSNELI'과 같은 정적 링크 된 시스템 모듈에 대해 덜 염려하십시오. 실행 시간에 적절한 언어 인터페이스 모듈을 동적으로로드하는 스텁 프로그램입니다. Universal Language Interface을 참조하십시오.
일반적으로 말하면, 해당 시스템 루틴에 대한 호출이 고정되어 있어야합니다. 루틴은 런타임시 "실제"루틴을 찾는 스텁 인 경향이 있습니다.
DLL은 새로운 기능입니다. 우리 매장에서는 모든 일괄 프로그램이 DYNAM으로 컴파일됩니다. 이는 런타임에 시스템 루틴 호출도 해결된다는 것을 의미합니다. 이는 우리가 DLL을 사용할 때 계속해서 활용하고 싶다는 긍정적 인 함의가 있음을 의미합니다. – ChuckLeviton
그리고 시스템 루틴 호출은 런타임시에도 계속 해결 될 것입니다. – cschneid
DLL 처리기는 정적이어야합니다. DLL 모듈을로드 할 때 DYNAM처럼 작동합니다. – zarchasmpgmr
예, DSNELI 대신 DSNULI를 사용하면 런타임시 올바른 DB2 호출 연결 기능이 필요합니다. 해당 페이지에 따르면 성능 오버 헤드가 있지만 잘하면 첫 번째 SQL 문에서 한 번만 것입니다. – ChuckLeviton
@ChuckLeviton 다른 동적으로 참조 된 참조와 마찬가지로 가장 큰 오버 헤드 히트가 첫 번째 호출에 있다고 생각합니다. 그 후에 오버 헤드는 무시할 수 있어야합니다. – NealB
내가 듣고 싶었던 바로 그 덕분에! – ChuckLeviton