현재 단락 이름을 가져 오는 방법은 무엇입니까?

Question

COBOL에서 현재 단락 이름을 가져 오는 방법을 알고 싶습니다 (MVS Enterprise COBOL V4.2 사용).

의 내가 PROCEDURE 부문이 코드가 있다고 가정 해 봅시다 : 나는 현재 단락의 이름에 액세스 할 수 있도록하고 싶습니다

MAIN-LOGIC. 
     MOVE SPACE TO ABT-MSG 
     PERFORM PARAGRAPH-1 
     PERFORM PARAGRAPH-2 
     GO TO CLOSE-PROGRAM. 
    * 
    * SEARCH FOR A VALUE IN AN ARRAY AND GET THE RELATED INDEX 
    * 
    PARAGRAPH-1. 
     MOVE 42 TO SEARCH-VALUE 
     PERFORM VARYING I-SEARCH FROM 1 BY 1 
      UNTIL SOME-ARRAY(I-SEARCH) = SEARCH-VALUE 
     IF (I-SEARCH = MAX-ARRAY-POSITION) 
      MOVE SEARCH-ABORT TO ABT-MSG 
      MOVE 'PARAGRAPH-1' TO ABT-LOC 
      GO TO CLOSE-PROGRAM 
     END-IF 
     END-PERFORM 
     DISPLAY 'VALUE WAS FOUND AT POSITION ' I-SEARCH '.'. 
    * 
    * STORE A NEW VALUE AT THE END OF AN ARRAY 
    * 
    PARAGRAPH-2. 
     MOVE 42 TO STORAGE-VALUE 
     ADD 1 TO I-STORAGE 
     IF (I-STORAGE > MAX-ARRAY-POSITION) 
     MOVE STORAGE-ABORT TO ABT-MSG 
     MOVE 'PARAGRAPH-2' TO ABT-LOC 
     GO TO CLOSE-PROGRAM 
     END-IF 
     MOVE STORAGE-VALUE TO SOME-ARRAY(I-STORAGE). 
    * 
    * CLOSE THE PROGRAM 
    * 
    CLOSE-PROGRAM. 
     IF ABT-MSG > SPACE 
     DISPLAY ABT-MSG 
     DISPLAY '(FOUND IN ' ABT-LOC ')' 
     MOVE 20 TO RETURN-CODE 
     ELSE 
     DISPLAY SUCCESS-MESSAGE 
     END-IF 
     STOP RUN. 

을 (및 ABT-LOC에 저장) 대신 쓰기 필요없이. 'CURR-PARA-NAME'등과 같은 COBOL 시스템 변수가 있습니까?

감사합니다.

------ UPDATE 1 -------

나는 그것이 더 구체적으로 만들기 위해 내 코드 예제를 업데이트했습니다. 실제 COBOL 프로그램에서 SEARCH-ABORT 및 STORAGE-ABORT 가능성이 여러 가지 있음을 알고 있습니다 (많은 배열로 작업하고 있습니다).

나는 코드를 가능한 한 잘 만들고 싶다. 따라서 현재 단락의 이름을 쓰지 않고 코드에 액세스하려고한다.

다시 한 번 감사드립니다.

------- 업데이트 2 ------ 다음

음. 나는 그것을 할 수없는 것 같다. (내 프로그램의 사용자는 아마 사용하지 않는 디버그 메시지를 거부 할 것이다. - 정보를 얻기 위해 나는 50 년 된 프로그램을 상향 GO TO와 같은 매우 나쁜 프로그래밍 실습으로 다시 작성하고있다. 폴 스루 로직 (Fall-Through Logic), ALTER (얼터너티브) 등이 있으며, 결국 같은 결과물을 얻고 싶습니다.

걱정하지 마십시오. 나는 오늘 밤 울지 않을 것입니다. 이것은 내 코드에 대한 심미적 인 개선이었으며, 나는 그것을 사용하지 않고 살 수있었습니다 (내 코드는 이미 내가 기반한 것보다 훨씬 더 예쁘다).

시간 내 주셔서 감사 드리며 좋은 시간 되시길 ... Stack Overday!

Answer 1

당신이 의사 코드 "뭔가 나쁜 일이 생겼으니"나는 예외가 있다고 가정합니다. 이 경우에는 표준 (COBOL 2002, COBOL 2014) 함수 EXCEPTION-LOCATION이 도움이 될 수 있습니다 (실제 문자열은 구현 자 정의이지만 단락이있을 수 있다고 가정합니다. 예를 들어 GnuCOBOL 형식은 program-id, paragraph [또는 단락 OF 섹션 또는 섹션, 프로그램에 따라 다름], 소스 행]).

COBOL 컴파일러가이 함수에서이 정보를 제공하고 이미 문제가되는 부분에 예외가없는 경우 subtract 1 from unsigned-var 또는 이와 비슷한 방법으로 만듭니다.

Bill은 이미 말했듯이 (또는 암시 적으로) : 식별자로 레이블 이름을 사용해야하는 경우 사용되는 실제 COBOL 컴파일러가 가장 중요한 부분이되는 질문입니다.

는 (실제 COBOL 컴파일러가 알려진 후) 편집

:

IBM MVS 기업 COBOL은 EXCEPTION-LOCATION 기능이 없습니다.그러므로 나는 하나의 내장 된 솔루션을 참조하십시오

DECLARATIVES. 
debug-declaratives SECTION. 
    USE FOR DEBUGGING ON ALL PROCEDURES. 
debug-par. 
    MOVE debug-name TO current-procedure. 
END DECLARATIVES. 

을하지만 이것은 단지 활성화되어있는 프로그램은 I가하지 않는 것이 좋습니다 (5 월 발생하는 디버깅 메시지를 많이 일으키는) 디버깅 모드에서 실행되는 경우 실제 사용은입니다.

매크로를 제공하는 편집기를 사용하거나 실제 소스에서 쉘 스크립트를 실행하여 컴파일러에 전달한 소스를 나중에 만들어보십시오.

Answer 2

Simon Sobisch이 대답에 올바르게 표시 했으므로 "디버깅 선언문"을 사용하면 Simon Sobisch이 원하는대로 정확하게 수행 할 수 있습니다. 그 일을하기 위해 답을 나중에 보아라.하지만 아무도 프로덕션 프로그램에 이것을 허락해서는 안된다.

COBOL은 컴파일 된 언어이므로 컴파일러에서 사용할 수없는 경우 데이터 이름 또는 프로 시저 이름 (단락 또는 SECTION)에 자동으로 액세스 할 수 없습니다. 위의 경우를 제외하고는 그렇지 않습니다.

이렇게하면 세 가지 접근 방식이 있습니다. 수동으로 수행하는 것입니다. (정확하게 복숭아를 피우려면 다른 사람이 리터럴을 변경하지 않고 코드를 복사하거나 위치를 옮길 것입니다.); 필드를 올바른 레이블로 자동 채우기 위해 사전 처리 (프로그램 또는 편집기 사용); 다른 일을하는 것.

당신은 내재적으로 첫 번째를 할인하고 있으므로 다시 올바르게 믿습니다. 두 번째를 고려해 봅시다. 같은 단락/SECTION에 모두 "비즈니스 오류"인 두 개, 세 개 또는 여덟 개가있는 경우 (일반적으로 이러한 유형의 것은 "무결성 오류"가 더 많으며, 존재하지 않아야하므로 계속하지 마십시오) ?

"사전 처리"솔루션은 더 추악 해지기 시작합니다.

그 밖의 방법은 무엇입니까?

글쎄, 우리가 수년 동안 많은 어려움을 겪고 있습니다. 대답은 프로그램 내에서 고유 한 오류 번호입니다. 개별 오류는 잘 명명하고 번호를 부여 할 수 있습니다. 잘 - 명명 된 오류 참조는 "잘못"사용하기가 어렵습니다. 새로운 오류를 추가 할 때 기존 번호를 복제하기가 어렵습니다. 또는 다른 방법으로 말하자면, 복제하기는 쉽지만 테스트에서 두드러지게 쉽게 발견 할 수 있습니다 - "이봐, 그건 1234가 만들어 졌어, 틀렸어".

데이터 이름 (및 연관된 텍스트)은 단락 이름보다 더 나은 문제점을 나타냅니다. (인위적인 경우를 제외하고는 무엇을 의미합니까? 오류는 바로 그 위치입니다). 오류 참조는 프로그램에서 매우 쉽게 찾을 수 있으며 실제로는 더 이상 필요하지 않은 경우를 제외하고 프로 시저 이름을 쉽게 찾을 수 있습니다.

오류 번호가있는 프로그램이 수동으로 유지 관리되는 MOVE 'literal'to some-standard-name 프로그램의 부적합보다 중요한지 여부는 알 수 없습니다. 그러나 당신은 내가 어느 것을 선호하고 추천하는지 짐작할 수 있습니다.

이제 DECLARATIVES가있는 Enterprise COBOL에서이를 수행하는 방법.

IDENTIFICATION DIVISION. 
    PROGRAM-ID. STAB39. 
    ENVIRONMENT DIVISION. 
    CONFIGURATION SECTION. 
    SOURCE-COMPUTER. FRED DEBUGGING MODE. 

    DATA DIVISION. 
    WORKING-STORAGE SECTION. 
    01 W-WHEN-COMPILED      PIC X(8)BX(8). 
    01 ABT-LOC        PIC X(30). 


    PROCEDURE DIVISION. 
    DDECLARATIVES. 
    DSOME-SECTION SECTION. 
    D USE FOR DEBUGGING ON ALL PROCEDURES 
    D . 
    DSOME-PARA. 
    D MOVE DEBUG-NAME TO ABT-LOC 
    D . 
    DEND DECLARATIVES. 
    STARTING-UP SECTION. 
     DISPLAY 
       ABT-LOC 
    D DISPLAY 
    D   "IT IS STARTING UP" 
     MOVE WHEN-COMPILED   TO W-WHEN-COMPILED 
     DISPLAY 
       "STAB39 " 
       W-WHEN-COMPILED 
     . 
    A-PARA. 
     DISPLAY 
       ABT-LOC 
     PERFORM 
     10 TIMES 
    D  DISPLAY 
        "ITERATING" 
     END-PERFORM 
     . 
    ANOTHER-PARA. 
     DISPLAY 
       ABT-LOC 
     PERFORM      THE-PARA 
            10 TIMES 
     PERFORM      THE-SECOND-PARA 
     GOBACK 
     . 
    THE-PARA. 
     DISPLAY 
       ABT-LOC 
     . 
    THE-SECOND-PARA. 
     DISPLAY 
       ABT-LOC 
     . 

일부 노트 :

소스 - 컴퓨터 단락을 켜, 내장 디버깅 기능 COBOLs을 사용하는 데 필요합니다. 그래서 환경부와 구성 부문도 필요합니다. 이 예에서 "컴퓨터 이름"인 FRED는 필수 사항이지만 관련이 없습니다. 당신이 좋아하는 애완 동물이나 친척, 또는 거기에 아무것도 넣어 후 컴퓨터를 "이름"수, 그냥 뭔가 있어야합니다.

선언문은 절차부의 시작 부분에만 지정할 수 있습니다. 그들은 SECTION 내에 있어야하며 모든 행동은 SECTION에 속하는 단락 내에 있어야합니다. SECTION과 단락의 이름은 부적절하지만 어쨌든 의미가 있습니다.

선언문에 SECTION이 있어야하므로 첫 번째 프로 시저 레이블이 SECTION이 아닌 경우 정보 진단 메시지가 표시됩니다. 이것은 당신의 프로그램에서 단락들에 대한 SECTIONS를 사용할 필요가 없다. 더 이상의 효과가 없다.

7 열의 D는 "디버깅 라인"을 나타냅니다. 이 줄은 SOURCE-COMPUTER 단락을 사용하여 디버깅을 설정하면 생성 된 코드 만 가져옵니다.

프로그램은 GO TO을 제외하고 단락의 모든 사용을 연습합니다 (이 예에서는 SECTION 사용이 동일하지 않습니다). GO TO TO (GO TO TO) 된 단락은 다른 참조와 동일한 결과를 산출하지만 내 프로그램에서 GO TO를 볼 수 없습니다 :-)

"트랩"하려는 프로 시저의 이름을 지정할 수 있습니다 "모든 절차"를 사용하는 대신 선언문을 사용하십시오.

디버깅 절차가 여러 개있을 수 있으며 원하면 디버그 절차에 광범위한 코드를 포함 할 수 있습니다 (예 : 테스트 조건 설정).

이 기능은 COBOL에 오랫동안 존재 해 왔지만 특정 "디버깅 제품"이 출시되면서 널리 사용되지는 않았다고 말할 수 있습니다.

이 프로그램을 설치하는 것만으로는 충분하지 않습니다. 기본값이 아닌 경우 "런타임"에 DEBUG가 설정되어 있어야합니다. z/OS의 런타임은 언어 환경이라고하며 여러 언어로 공유됩니다 (쉬운 언어 간 통신을 가능하게합니다). 언어로는 C/C++, PL/I 및 Java는 물론 COBOL이 있습니다. HLASM/Assembler 프로그램을 "LE Compliant"로 만들어서 사용할 수있는 언어 환경 루틴과 매크로가 있습니다.

사이트의 런타임 옵션을 기본값으로 확인하려면 가장 쉬운 방법은 실행 JCL에 CEEOPTS DD 문을 포함시키는 것입니다.

//CEEOPTS DD * 
    RPTOPTS(ON) 

이것은 당신의 "영토"(러닝 환경)에 사용되는 모든 옵션을 나열하고 각 옵션에서 공급되는 위치를 표시합니다.

OPTION 열에 NODEBUG이 표시되면 COBOL 디버깅이 기본적으로 해제되어 있습니다. 특정 실행에 대해 전원을 켜려면 :

//CEEOPTS DD * 
    DEBUG 

이 모든 D 표지 디버깅 라인과 실행 디버깅 DECLARATIVES을 수 있습니다.

이렇게하면 원하는대로 작동하지만 아무도 프로덕션으로 디버깅하는 프로그램을 허용하지 않으므로 원하는 용도로 사용할 수 없습니다.

우선 순위 순으로 오류 번호 (및 테스트), 자동화, 수작업으로 코딩 된 프로 시저 이름 리터럴을 권장합니다.

IBM은 모든 해당 제품을 문서화하고 Enterprise COBOL V4.2 용 문서 (언어 참조 및 프로그래밍 안내서)와 z/OS 릴리스 용 언어 환경 (여러)을 찾을 수 있습니다.

마지막으로 하나. 정상적인 처리 흐름을 "중단"하기 위해 GO TO를 사용하지 마십시오. PERFORM을 사용하십시오.논리적으로도 PERFORM을 반환 할 수는 없습니다. GO TO을 사용하면 실행에 눈에 띄는 영향을 쉽게 줄 수있는 GO TO가 포함 된 단락/절에 대한 컴파일러 최적화가 해제됩니다. 이는 IBM COBOL이 CALL 사이에 PERFORMed paragraphs/SECTIONs의 상태가 유지되지 않도록 보장하기 전과는 다른 조언입니다. 그 당시 올바른 조언은 GO TO를 사용하는 것이 었습니다. 더 이상 올바른 조언이 아닙니다.