CL 및 RPG 프로그램 조합을 사용하여 작성된 저장 프로 시저가 있습니다. iSeries에서 로컬로 호출 될 때 모두 정상입니다. 외부 적으로 (예를 들어 SQL 프론트 엔드에서) 호출 될 때 RPG 프로그램은 스풀 파일이 다른 (임의?) 작업 번호 및 사용자 아래에 표시되기 때문에 생성하는 스풀 파일에 hadle을 가져올 수 없습니다. 작업은 QUSRWRK 서브 시스템에서 QUSER로 실행되지만 스풀 파일은 연결 풀 (예 : USERA)에서 외부 연결이 이루어진 사용자 ID를 가져옵니다.iSeries 저장 프로시 듀어 - 스풀 파일 출력에서 핸들을 얻는 방법?
작업이 실행될 때 해당 대기열에서 마지막 스풀 피엘을 가져 오는 대신에 올바른 sppol 파일에서 안정적으로 핸들을 얻을 수있는 방법이 있습니까?
좀 더 자세한 정보가 필요하지만 몇 가지 가정을합니다. 내가 잘못했다고 생각하면 분명히하십시오.
QUSRWRK 동작의 QUSER가 정확합니다. 이제 SQL 서버 (또는 유사한 서버)를 실행 중입니다. 모든 연결은이 설정에서 실행됩니다.
몇 가지 접근법이 있습니다.
1)이 모든 작업이 하나의 작업에서 실행된다고 가정합니다. 작업 내용은 "* '를 사용하여 작동합니다.
2) 다른 옵션은 RTVJOBA CURUSER (& ME)를 사용하는 것입니다. 현재 사용자는 로그인 한 사람입니다. 사용자는이 경우 작동하지 않을 것입니다.
RPG 프로그램을 수정할 수있는 경우 Program Status Data Structure에서 작업 정보를 검색 할 수 있지만 File Information Data Structure에는 열린 피드백 영역의 스풀 파일 번호가 있지만 QUSER 작업에 대한 작업 정보가 무엇인지는 확실하지 않습니다. 당신이 필요로하는) USERA 작업 (당신이 필요로하는 것)에 대한 것입니다. 스풀 파일 번호는 후속 Print API 호출을 처리하기에 충분할 수 있습니다.
작업 자체는 알고 있거나 찾을 수 있습니다 (이전 답변 참조). 다른 모든 것이 실패하면 프로그램을 수정하여 필요한 정보를 제공하는 대기열에 메시지를 배치하십시오. 여가 시간에 그것을 읽으십시오.
.
QZDASOINIT 작업에서 실행중인 저장 프로시 듀어를 실행중인 경우, 프로그램 상태 데이터 구조를 통해 스풀 된 출력에 액세스 할 수 없습니다. 이러한 스풀 파일은 user/QPRTJOB이라는 작업에 있습니다. 여기서 user는 저장 프로시 듀어를 실행하는 "현재 사용자"입니다. 스풀 파일에 액세스하려면 api QSPRILSP를 실행하여 스풀 파일을 가리키는 구조를 확보하십시오.
IBM의 정보 센터에 비헤이비어와 API 모두 잘 설명되어 있습니다.
서버 작업 (예 : ODBC/JDBC 용 데이터베이스 서버 인스턴스)은 시스템 사용자 프로파일 하에서 실행됩니다. 저장된 procs의 경우 시스템 사용자는 일반적으로 QUSER입니다. 작업 내에서 생성 된 객체는 일반적으로 작업 사용자가 소유합니다.
서버 작업은 일반적으로 다른 사용자의을 대신하여 작업을 수행합니다. 연결을 설정할 때 어떤 사용자에게 서버 작업을 지시합니다. (그리고 평생 동안 주어진 서버 작업은 여러 사용자를 대신하여 작동 할 수 있습니다.)
특히 스풀링 된 출력의 경우 스풀링 하위 시스템이 "웹 "우리가 원격 데이터베이스에 연결하는 상당수의 사용자를 갖기도 전에.사용자에서 사용자로 간단하게 전환하는 동작은 스풀링 서브 시스템의 구성 부분이 아니며 특정 작업 사용자 또는 연결 사용자가 스풀 파일을 소유해야하는시기를 IBM이 판별 할 수도 없습니다. (스풀링은 데이터베이스 연결의 주요 요소가 아닙니다.) IBM은 "교환 된 사용자"출력을 a job named QPRTJOB에 수집하도록 디폴트로 설정하여 스풀링이 사용자와 연관된 출력 방법을 조정했지만 사용자가 원하는 방식에 맞지 않습니다 출력을 처리하는 최신 RPG 프로그램.
그러나 스풀링 된 출력을 생성하는 저장 프로 시저를 작성하면 proc가 출력을 소유 한 사용자를 선택하여 동일한 작업 내에서 유지하도록 선택할 수 있습니다. 는 iSeries 네비게이터 '실행 SQL 스크립트'기능에 붙여 넣을 수 있습니다 이러한 예 호출을 고려 : 당신이 한 세트로 실행하면, 그들은 CPF9899에 대한 메시지 설명의 특성을 보여주는 출력을 스풀 만들
call qsys2.qcmdexc ('OVRPRTF FILE(*PRTF) SPLFOWN(*JOB) OVRSCOPE(*JOB)' , 48);
call qsys2.qcmdexc ('DSPMSGD RANGE(CPF9899) MSGF(QCPFMSG) OUTPUT(*PRINT)' , 51);
call qsys2.qcmdexc ('DLTOVR FILE(*PRTF) LVL(*JOB)' , 28);
. 나중에 확인하면 QUSER가 QPMSGD라는 스풀 파일을 소유하고 있으며 이는 리모트 데이터베이스 요청을 처리하는 QZDASOINIT 작업 내에 상주한다는 것을 알아야합니다. 해당 작업 내의 RPG 프로그램은이 경우 "* LAST"스풀 파일을 쉽게 찾을 수 있습니다. 또한 첫 x 째와 마지 막 CALL을 h 제하고 이제 중간 점만 실행하면, 다음 스풀 파일을 소유하고 있음을 발견해야합니다.
(QUSER이 IBM 기본 인 시스템이 다른 사용자 프로필을 사용하는 경우, 대체 그 "QUSER"에 대한 사용자..)
권장 사항 :
적절한 OVRPRTF 명령을 실행하기 위해 SP를 변경작업을 캡처하고 출력이 생성 된 후 DLTOVR을 발행해야하는 출력을 스풀링하기 전에.
테스트 절차를 만들려면 여기에 표시된 것과 비슷한 명령을 사용할 수 있습니다. 다른 OVRSCOPE() 설정과 FILE (* PRTF) 또는 특별히 명명 된 파일을 사용하여 실험하십시오. 또한 오버라이드 명령의 앞뒤에 출력을 만들어서 어떻게 다르게 동작하는지 확인하십시오.
SP 작업이 끝나면 서버 작업이 다른 사용자를 처리 할 수도 있습니다 (또는 나중에 다른 SP가 호출 될 수 있음). 따라서 DLTOVR이 실행되고 있는지 확인하십시오. (그것이 OVRPRTF에 가깝게 유지하는 한 가지 이유입니다.)