왜 코볼에 대한 경멸? [닫은]

사람들이 COBOL을 언급 할 때 보통 코골이 또는 신음 소리를냅니다. COBOL에 대해 잘 모르지만 일부 프로그램이 작성된 것을 보았습니다. 나는 그것이 장황하고 내 눈과 같은 시작되지 않은 눈에 이해할 수 없다는 것을 알 수 있습니다. 그러나 실제로 모든 프로그래밍 언어가 평신도에게 완전한 횡설수설이 아닙니까?

나는 그것이 작동하고 잘 작동하며 설계된 산업에서 여전히 널리 사용되고 있음을 이해합니다. 좋은 언어의 특징이 아닌가? COBOL의 문제점은 무엇입니까?

COBOL은 내가 배운 첫 번째 언어 중 하나입니다. 수많은 Basic, 3-4 개의 어셈블러 언어 및 Forth의 변형을 무시하면 처음 5 개 언어로 파스칼과 동시에 배웠습니다. IOW, 나는 언어를 사용한 개인적인 경험으로부터 대답하고 있습니다.

편집 나는 고대의 경험을 말해야한다 . 80 년대 말 이후로 나는 그 언어를 전혀 사용하지 않았지만, 나는 새로운 책을 샀다. 그러나 나는 지난 20 년 동안 언어가 어떻게 진화했는지 전혀 모른다.

물론, 많은 사람들을 위해, 그것은 이다 또한 훨씬 더 써드 손 패스 나 다운 태도 일을 - "오래된 나쁜"그냥 그 jonsca 이미 설명했다 볼 수 있습니다. 그러나 근본적인 문제가 있습니다.

너무 간결한 것은 실제 문제입니다. 코드를 이해하는 데 너무 많은 혼란이 있습니다. 이것은 지금까지 가장 큰 문제입니다. 상기 보는 사람들 MOVE, ADD그리고 MULTIPLY공포 등의 진술은 사실이의 약간 과장된보기가 - COMPUTE문은 다른 언어에서 할당에 더 가깝다. 그러나 모든 부서와 섹션에는 여전히 많은 혼란이 있습니다. COBOL에서 처음 배운 것 중 하나는 항상 A4 길이의 표준 SKELETON.COB를 복사하여 시작하는 것이 었습니다.

COBOL는 않는 몇 가지 흥미로운 기능을 가지고 있지만, 이러한 기능 (예 : PIC일)은 DBMS가 아닌 프로그래밍 언어의 더욱 일부 일을하는 경향, 그리고 그것은 나에게 보인다 일반적으로 그 책임을 분리 할 수있는 더 좋은 방법. 또한 다른 언어로 된 일부 라이브러리 는 이에 필적하는 것을 사용합니다 PIC(예 : C 표준 라이브러리의 printf 및 scanf). 아마도 최고는 유지되었지만 최악은 떨어졌습니다.

또한 모든 멋진 기능에는 하나 이상의 견딜 수없는 기능이있었습니다. 예를 들어 루프가 아무리 사소한 경우에도 바디를 별도의 절차로 이동해야합니다. PERFORM ... UNTIL ...및 이와 유사한 문은 있습니다 하나의 문 - 구조를 차단하지. 어떤 의미에서, COBOL은 구조적 프로그래밍이 발명되기 전의 구조적 프로그래밍의 맛 이었습니다 . GO TO하지만. (최소한 COBOL을 사용할 때) 사용은 권장되지 않았지만, 특히 루프는 잘 처리되지 않았습니다.

사실, COBOL 이후 가장 많이 생각 나게 한 언어 는 ... dBase입니다. Ashton-Tate dBase III +에서와 같이. 요즘 사람들은 xBase라는 일반적인 이름을 가진 현재 죽어 가거나 죽어가는 클론 (Clipper, FoxPro 등)을 기억할 가능성이 더 높으며 xHarbour에는 여전히 살아있는 자손이 있습니다. 요점은 이것들은 데이터베이스 언어이지만 SQL과는 다르다는 것입니다.

그럼에도 불구 하고 특정 데이터베이스에서 작동 하는 모든 COBOL 프로그램에 해당 데이터베이스 사양의 사본이 포함되어야하고 사본이 일치하지 않을 수있는 경우에도 데이터베이스가 자체 구조를 알고있는 xBase의 경우에는 해당되지 않습니다.

그렇다면 COBOL을 고려하면 COBOL은 그렇게 받아 들일 수 없습니다. 그러나 이것이 아닌 것은 데이터 구조를 작성하기위한 언어입니다. 이것이 CB 대 파스칼 거룩한 전쟁 시대에 COBOL이 많은 고통을 겪었던 이유 일 수 있습니다. 양측은 COBOL이 이진 트리를 다시 발명하는 데 좋지 않다는 데 동의 할 수 있습니다.

아, 그리고 내가 결코 잊지 않을 것 중 하나는 첫 번째 COBOL 교과서가 SORT명령의 범위를 벗어났다고 명령을 설명하지 않은 방법 입니다. 분명히 저자는 정렬 아이디어에 대처할 수 없었습니다. 코볼 학생들이 생각할 수있는 작은 작은 생각 이상이라고 생각했다 . 그런 종류의 일 때문에 코볼을 진지하게 받아들이 기가 매우 어려워졌습니다.

이것의 이상한 측면은 Jackson Structured Programming이었다. 나는 또한 거의 동시에, 특히 COBOL과 함께 사용하도록 배워야했다. 이 중 일부는 입력에 대한 구조 다이어그램을 그린 다음 출력에 대한 구조 다이어그램을 그린 다음 코드의 중간 구조 다이어그램을 그리는 것이 었습니다. 정렬은 이미 해결 된 문제 일 것으로 예상되었으므로 이러한 방식으로 정렬 알고리즘을 도출 할 수 없었습니다. 따라서 권장되는 교과서에서 정렬의 전체 개념이 작은 작은 생각을 넘어서면서 동시에 수십 가지 정렬 알고리즘과 같은 것을 배우고 파스칼에서 구현하는 방법을 배우는 것이 이상했습니다.

JSP가 처리 할 수있는 문제점은 아마도 COBOL이 상대적으로 잘 수행 할 수있는 것들에 대한 좋은 안내서 일 것입니다. 그렇다고해서 반드시 JSP 나 COBOL이 이러한 문제를 처리하는 좋은 방법이라는 것을 의미하지는 않습니다.

2014 년 7 월 30 일 편집

나는 이것으로 명성을 얻었고 여기에 나에게 상기시켜줍니다. 그리운 향수를 불러 일으키는 고대 책 수집으로 인해 이제 WRT SORT명령을 수정 할 수 있습니다 .

COBOL을 배울 때 원래 권장 텍스트로 사용했던이 책은 Ray Welland의 "COBOL의 기술 프로그래밍"이었습니다. COBOL 85는 다루지 않습니다 (여전까지 본 적이없는 "COBOL-85의 방법론 프로그래밍"이후 버전).

kindall은 아래에 "OS와 함께 제공되는 정렬 유틸리티를 사용하여 입력 파일을 읽기 전에 정렬하거나 생성 한 후 출력 파일을 정렬해야했습니다"라고 말합니다. 그 답장에서 "OS와 함께왔다"라는 점을 놓쳤다. Kindall은 유닉스 철학 AFAICT와 비슷한 것을 제안했습니다 .COBOL은 비트에 적합하고 다른 유틸리티에는 정렬 유틸리티와 같은 OS 유틸리티가 있으며 비트를 서로 붙일 수있는 배치 / 스크립팅 / 쉘 언어를 사용합니다. 이것은 대화 형 소프트웨어가 존재하지 않는 고대 세계에서 훨씬 더 의미가 있으므로 어쨌든 배치 작업 (따라서 "배치 언어")을 제출해야합니다.

다음은 "COBOL의 프로그래밍 방식"의 165-166 페이지에서 인용됩니다.

순서가 지정된 직렬 파일을 사용한다는 것은 파일 내에서 레코드를 키별로 지정된 순서로 정렬하는 수단이 필요하다는 것을 의미합니다. 대부분의 대형 컴퓨터 시스템에는 키를 구성하는 각 데이터 항목의 위치, 유형 및 크기에 따라 파일을 정렬하는 정렬 유틸리티가 있습니다.

COBOL 프로그램 내에서 레코드를 정렬하는 기능도 있지만 다음 두 가지 이유로이 책의 범위를 벗어납니다.

(a) 운영 체제에 대한 인터페이스는 종종 매우 복잡하며 시스템마다 다릅니다.

(b) 정렬 모듈은 ANS '74 COBOL의 선택적 부분이며 소규모 컴퓨터의 경우 COBOL 시스템에서 구현되지 않을 수 있습니다.

따라서 파일을 지정된 순서로 정렬 할 수있는 기능이 있다고 가정하고 해당 파일을 업데이트하는 문제가 고려됩니다.

요컨대, kindall은 정확합니다-일반적으로 정렬은 COBOL 외부에서 수행된다는 가정이었습니다. 작은 컴퓨터의 경우 1974 년경에 프로그래밍 언어에서 정렬을 배제하는 것이 실제로 정당화되었을 수도 있습니다.

위에서 말한 것은 기본적으로 책을 버려서 사실을 확인할 수없는 약 20 년 후에 얻은 것입니다.

그래도 나는 1988 년과 1989 년에 1974 년 표준 (1985 년 표준이 아닌)을 다루는이 권장 책에서 COBOL을 공식적으로 공부했다는 점을 지적해야합니다. "학생을위한 COBOL"(Parkin, Yorke, Barnes)- COBOL 85를 다루는 첫 번째 판은 1990 년까지 출판되지 않았습니다. 확실하지는 않지만 "Methodical Programming"의 COBOL 85 판이 1994 년까지 출판되지 않았다고 생각합니다.

그러나 이것이 반드시 코볼 세계가 발을 끌고있는 것은 아닙니다. 새로운 표준 채택은 지금도 모든 언어에 시간이 걸립니다.

오늘 대부분의 COBOL을 작성하면서 보냈는데 현재 의견을 줄 수 있다고 생각합니다.

먼저 나쁜 것들 :-

• 함수 호출이 없습니다. 현대 COBOL에는 일부 내장 기능이 있지만 사용자가 직접 작성하는 것은 심각한 엔지니어링 작업입니다.
• 서브 루틴 호출에서 유형 검사가 없습니다. 서브 루틴 호출에서 무엇이든 전달하거나 전달할 수 없으며, 호출 된 서브 루틴은 올바른 매개 변수를 가지고 있다고 가정하며 누락되거나 유효하지 않은 매개 변수를 감지 할 방법이 없습니다.
• 라이브러리가 없습니다. 아무 제로도 없습니다. 표준 라이브러리도없고 쉽게 사용할 수있는 라이브러리도 없습니다. commomplace 작업을 계속해서 반복해서 코딩하게됩니다.
• 모든 것이 키워드로 구현됩니다. 언어 작성자에게는 라이브러리 개념이 없기 때문에 모든 새로운 기능은 XML 지원을 위해 PARSE 및 RENDER와 같은 새로운 키워드로 구현됩니다.

오해, 즉 그 비판은 일반적으로 유효하지 않거나 관련이없는 사랑하는 옛 언어에 대해 평준화되었다.

• 다변. 따라서 몇 가지 추가 문자를 입력하십시오! 심각한 문제는 아닙니다. 많은 경우에 COBOL은 Java보다 덜 장황합니다.

• "COBOL FILES"이 용어는 많이 사용됩니다. COBOL이 모든 파일 형식 및 파일 구성에 대해서만 처리 할 수있는 것은 없습니다.

• 멀티 스레딩이 없습니다. COBOL이 번성하는 환경에서 멀티 스레딩은 일반적으로 CICS 나 IMS와 같은 응용 프로그램 컨테이너에 맡겨져 있으며, 그보다는 좋지 않은 프로그래머보다는 응용 프로그램 컨테이너에 적합합니다.

그리고 좋은 것들-COBOL의 일부 측면은 다른 언어보다 우수합니다.

• 데이터 구조. COBOL에는 복잡한 데이터 구조 및 홀수 데이터 유형을 정의하기위한 간결하고 유연한 구문이 있습니다.
• 십진 산술. 적절한 반올림 등으로 회계사에 의해 이해되는 십진 산술, 즉 산술을 기본적으로 지원합니다.
• 시간과 함께 움직이기. COBOL의 일부 측면은 놀랍도록 현대적입니다. 내장 XML 지원, OO 프로그래밍 지원, Java 클래스 사용 기능 등
• DB2, CICS 등과의 통합. 이는 IBM의 메인 프레임 COBOL에만 적용되지만 (지금까지는 여전히 가장 큰 COBOL 덩어리가 실행 중임) DB2, CICS 및 기타 메인 프레임 환경과의 통합으로 데이터베이스 백업과 같은 것을 쉽게 코딩 할 수 있습니다. 다른 환경보다 웹 서비스.
• 화면 처리. AS / 400 및 MicroFocus Cobol에서 구현 된 표준 화면 처리 기능이 뛰어납니다.
• 공연. 수년 동안 COBOL 컴파일러는 고성능 실행 파일을 생성 해 왔습니다. 기본 C 및 기본 어셈블러 만이 IBM 메인 프레임에서 COBOL을 이겼습니다.

그래서 1950 년대에위원회가 구성한 것을 위해 아주 잘 해냈습니다. 기존 애플리케이션이 COBOL로 구현되어 작업을 수행하는 경우 다시 작성할 이유가 없습니다. 그러나 정말로 좋은 이유가 없다면 COBOL을 사용하는 새로운 프로젝트에 대한 정당성이 보이지 않습니다.

이것은 아마도 지크 스트라 (Jikkstra)에게 달려 있습니다. Djikstra는 "COBOL의 사용은 마음을 망칠 뿐이므로 그 가르침은 범죄 행위로 간주되어야한다"고 말했다. 코볼은 순진하고 구조화되지 않았으며 장황한 것으로 여겨졌다. 코드를 자체적으로 변경하는 기능 (코볼 프로그래머들 사이에서도 권장되지 않는 관행)으로 디버깅이나 추적이 매우 어려운 것으로 간주되었습니다.

그러면 버전 간에도 큰 비 호환성 문제가 있습니다.

언어에 대한 Wikipedia의 비판 및 방어 섹션을 읽으십시오-http: //en.wikipedia.org/wiki/COBOL#Criticism_and_defense

나이와 장황은 일반적으로 사람들이 신음하는 것들입니다.

COBOL을 설계 할 때 IBM의 주된 목표는 "은행 관리자가 프로그램을 작성할 수 있어야한다는 것"이라고 생각합니다. 이 목표는 분명히 언어의 설계 방식에 중대한 영향을 미쳤으며 이제는 진화했습니다.

분명히 다른 어떤 언어보다 더 많은 COBOL이 있습니다. 그러나 거의 20 년 동안 IT 분야에서 근무한 후 (뱅킹 분야에서 15 명) 구현 된 단일 시스템을 본 적이 없습니다.

COBOL의 문제점은 무엇입니까?

아무것도.

나는 사람들이 오래된 것이 나쁘다는 선입견을 가지고 있다고 생각합니다. 여전히 많이 사용 중이며, 반세기 동안 코드에 필요한 유지 보수 작업이 충분할 것이라고 확신합니다.

1997 년 가트너 그룹 (Gartner Group)은 전 세계 비즈니스의 80 %가 COBOL에서 2 천억 줄 이상의 코드가 존재하고 매년 약 50 억 줄의 새로운 코드로 실행되었다고보고했다. ( wikipedia 를 통해 )

코딩에서는 항상 작업에 가장 적합한 도구를 선택해야하며 특정 하드웨어와 결혼 한 특정 산업에서는 언어가 최적입니다. 나는 그것이 인기가 있다고 들었던 은행에서 일한 적이 없지만 Sean의 대답은 그렇지 않다는 것을 나타냅니다.

구식 코드가 오래되어 보이는 데 문제가있는 경우 UI 또는 웹 인터페이스를 때릴 수있는 한 대부분의 사용자는 그 차이를 알지 못합니다.

COBOL은 적용이 제한되어 있기 때문에 사람들은 싫어합니다. 회사와 정부의 비즈니스, 재무 및 관리 시스템을 위해 설계되었습니다.

이들 모두 공통점이 무엇입니까? 데이터. 많은 데이터.

누가 데이터를 처리하고 아침 식사를 위해 많은 파일을 갖도록 설계 되었습니까? 당신은 COmmon 비즈니스 지향 언어 를 말할 수 있습니까 ?

50 년 전 COBOL은 관리 할 데이터가 많은 대기업에 가장 적합했습니다. 오늘날 많은 양의 데이터를 관리하는 더 좋은 방법이 있으므로 COBOL은 더 이상 관련이 없습니다. 아니면?

정부를 고려해 봅시다. 정부는 어떤 데이터를 추적해야합니까? 사람들의 신분증, 출생 증명서, 의료 기록, 세금 (오… 네 ... 세금) 등. 그리고 그들은이 정보를 현재와 50 년 전에 무기한 보유해야합니다.

사람들은 또한 일부 답변에서 은행을 화해했으며 실제로 은행은 COBOL을 많이 사용합니다. 왜? 다른 유형의 회사와 달리 은행에는 일반적으로 역사가 있기 때문입니다. 일부는 수백 년 동안 존재합니다 ( 예 : 이와 같이 ).

즉, 현재는 2011 년 10 월 7 일 현재 50 년 동안의 일부 데이터가 여기에 있어야합니다. 이제 SQL Server와 C # 또는 Oracle과 Java가 있지만 50 년 전에는 COBOL과 파일이있었습니다.

시간이 지남에 따라 정부와 은행의 데이터가 점점 커지고 시스템을 마이그레이션하는 데 점점 더 많은 비용이 듭니다. 즉, 비즈니스가 발전함에 따라 COBOL로 유지되고 구성이 유지되고 발전해야합니다. 일부 은행은 천천히 마이그레이션하는 반면 다른 은행은 메인 프레임 앞에 멋진 Web2.0 인터페이스를 고수합니다 (c # 및 Java가 주로 사용됨). 레거시 코드를 말할 수 있습니까? (COBOL은 (최고의) 레거시 코드와 밀접한 관련이 있습니다.이 코드 중 일부는 수십 년 동안 많은 사람들이 접한 것입니다-프로그래머가 싫어하는 또 다른 것 : D).

그리고 지금 당신은 활동의 틈새가 있습니다. COBOL은 이제 응용 프로그램이 제한되었으며 경험이 영향을받습니다 .

그리고 COBOL에 참여하는 사람들은 결국 당신이 해마다 해마다 같은 일을 반복해서 반복하고 깨어날 때 사람들이 이제 더 이상 시장에서 경쟁력이 없다는 것을 알게 되었습니다. 사람들은 이제 PHP, Java, C #을 원하기 때문입니다. , REST, jQuery 및 은행 만이 COBOL 직원을 찾습니다.

이 시점에서 수요는 공급보다 낮으며 절단을하지 않는 사람들은 다른 것으로 이동해야합니다. (복사 - 붙여 넣기하지의 COBOL 발전의 기본 스타일과 큰 대형 생산성을 차지 믿을 수) 지금 COBOL 정말 마음을 무력화 않기 때문에 그들은 후배로 시작해야합니다 그들은 하루가 COBOL 집어 저주 '와 돈을 t에 대한 공포 이야기를 할 기회를 잃지 마십시오. :). 그러나 요즘에는 더 이상 요구되지 않는 구세대 언어에 대한 이야기를 들려 줄 수 있지만 불행한 사람은 그 언어에 붙어 있습니다. 오 잘 ...

PS 와 COBOL은 다른 사람들이 언급 한 다른 모든 이유로 나쁩니다 :)

PS2. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.정말? 그리고 하루는 어떻게 그것을 측정 했습니까? 그들은 모든 회사를 한마디로 갔고 그들이 몇 줄의 COBOL을 가지고 있는지 또는 무엇을 물었습니까?

두 가지 기능.

• ALTER 문은 순수한 악이다. 보다 현대적인 COBOL 응용 프로그램에서는 거의 사용되지 않지만 "IF-GOTO"구조보다 더 효율적이기 때문에 "오래된 시대"에 많이 사용되었습니다. 컴퓨터에 32K의 RAM 만 있으면 각 명령이 중요합니다. 다른 목적지를 갖도록 GOTO 문을 수정했습니다.

  이것은 코드 자체가 상태가 좋기 때문에 일부 코드를 불투명하게 만들었습니다.

• 데이터 구조에서 REDEFINES 절 ( unionC 에서처럼 )은 영구적 인 문제입니다. "자유 조합"이라는 용어, 즉 판별자가없는 오버레이 된 데이터 구조는 문제를 요약하는 방법입니다. 두 개의 REDEFINES 별명은 데이터로 쉽게 구별 할 수 없습니다. 프로그램 로직을 광범위하게 읽는 것만으로 바이트의 두 가지 대체 해석의 의미 를 결정할 수 있습니다.

  코드 없이는 데이터를 이해할 수 없기 때문에 많은 데이터 구조가 불투명 해졌습니다.

영어와 비슷한 구문의 가독성은이 두 구성으로 인해 무너졌습니다.

[저는 짧은 답변은 귀하의 중요하고 흥미로운 질문을 무시한다는 경고를 받았습니다. 이 일을 무시하면 자세한 내용을 물어볼 수 있습니다. 또는 중재자가 삭제할 수 있도록 플래그를 지정하십시오.]

몇 년 동안 COBOL로 프로그래밍했습니다. 구문은 오늘날의 언어와 비교할 때 간단하며 진행 방법을 배우기 위해 많은 이론이 필요하지 않습니다. COBOL은 IBM의 CICS (온라인 트랜잭션 관리 시스템)와 매우 잘 작동하며 프로그래머는 사용자 수를 1에서 수천으로 확장하기 위해 코드에주의해야합니다. CICS는 화면과 함께 화면 단위 (창 없음)로 작동하는 문자 기반 GUI를 제공했습니다. 메인 프레임에서 (IBM의 GDDM)을 사용하여 차트를 표시 할 수 있습니다. COBOL은 인덱스 파일 (VSAM 및 ISAM)은 물론 DB2 (SQL 기반 관계형) 및 IMS와 통신 할 수 있습니다. COBOL / CICS는 매우 강력한 환경이며 몇 주 후에 배울 수 있습니다. 즉, 기술이 아닌 비즈니스에 중점을 두므로 8 시간 중 7 시간 동안 MVM, JavaScript 등을 배우지 않는 코딩 작업을 수행하게됩니다.

COBOL의 문제는 나쁜 마케팅으로 인해 타사의 툴 및 프로그래밍 환경 개발에 대한 관심이 부족합니다. 또한 인터페이스와 같은 Windows에 대한 지원이 부족하여 1993 년 이후로 인기가 떨어졌습니다. 메인 프레임 비용으로 인해 고객은 UNIX 및 DOS에서 COBOL의 대안 및 컴파일러를 찾을 수있었습니다. C 언어는 이식성이 뛰어나고 COBOL이 거의 가지고 있지 않은 OS 기능에 직접 액세스 할 수 있었기 때문에 많은 빛을 끌었습니다.

VB, DBase, FoxPro 및 Clipper와 같은 언어는 DOS의 COBOL보다 PC에서 '데이터베이스'에 액세스하는 더 나은 방법을 사용하여 COBOL을 잃었습니다. CICS는 DOS 또는 UNIX에서 오랫동안 저렴하지 않았으므로 이러한 환경에서는 그 가치가 없었습니다.

오늘날 COBOL은 .NET에서 지원되지만 메인 프레임 (및 AS / 400)을 제외한 모든 플랫폼에서 완전히 의존하는 수많은 미션 크리티컬 애플리케이션으로 인해 여전히 잃어버린 것 같습니다. 그것.

허, 나는 80 년대 초에 대학에 갔고 사람들은 그때도 코볼에 대해 조롱했다. 가장 큰 문제는 간단한 "Hello, world!"입니다. COBOL의 경우 아마도 50 개가 넘으며 그 중 95 %가 상용구입니다. 매우 우아하거나 매력적인 언어는 아닙니다. 또한 어제 문제를 처리하도록 설계되었으며 1970 년 이후에 개발 된 개발 패러다임에 실제로 적합하지 않습니다. 보고서가 머리글과 바닥 글이있는 끝이없는 열인 경우 보고서 생성 언어는 상당히 좋습니다. 어딘가에 그래프 나 로고를 붙이려면 잊어 버리십시오. "데이터 처리"유형 작업을위한 가장 빠른 언어라고 생각합니다 (5M ATM 트랜잭션으로 고정 형식 파일을 가져와 각각에 대해 간단한 균형 조정을 수행함). 하지만 더 많은 개발자들이 더 이상 그런 종류의 일을합니까? 그리고 오늘날 많은 시스템이 XML 또는 JSON을 사용하므로 COBOL을 사용하여 이와 비슷한 것을 구문 분석하려고하는 것을 싫어합니다 (실제로 COBOL에서 일반적으로 구문 분석하는 것을 싫어합니다!)