This is a good article. Click here for more information.

코볼

COBOL
배틀스타 갈락티카의 가상의 행성 코볼과 혼동하지 말 것.
코볼
COBOL Report Apr60.djvu
COBOL 60은 CODASYL에 보고(1960년 4월)
패러다임절차, 필수, 객체 지향, 범용
설계자Howard Bromberg, Norman Discount, Vernon Reves, Jean E. Sammet, William Selden, Gertrude Tierney, Grace[1] Hopper의 간접적 영향 있음
개발자CODASYL, ANSI, ISO/IEC
처음 등장한1959년; 63년 전 (연방)
안정된 릴리스
ISO/IEC 1989: 2014/2014
타이핑 분야약하고 정적인
파일 이름 확장자.cbl,.cob,.cpy
주요 구현
GnuCOBOL, IBM COBOL, Micro Focus Visual COBOL
사투리
COBOL/2, DEC COBOL-10, DEC VAX COBOL, DOSVS COBOL, Envyr ICOBOL, 후지쯔 COBOL, 히타치 COBOL2002, HP3000 COBOL/II, IBM COBOL SAA, IBM COBOL/400, IBM COIe COBOL, Realia COBOL, Ryan McFarland RM/COBOL, Ryan McFarland RM/COBOL-85, Tandem(논스톱) SCOBOL, UNIVAC COBOL, Unis MCP74
영향을 받다
이니셜:AIMACO, COMTRAN, 팩트, 플로우매틱
COBOL 2002:[a]C++, 에펠, 스몰톡
영향받은
CobolScript,[5] EGL,[6] PL/I,[7] PL/B[8]

COBOL(/cobbll, -bːl/, "공통 비즈니스 지향 언어"의 약자)은 비즈니스용으로 설계된 컴파일된 영어 같은 컴퓨터 프로그래밍 언어입니다.이것은 필수적이고 절차적이며 2002년부터 객체 지향적인 언어입니다.COBOL은 주로 기업과 정부의 비즈니스, 재무 및 관리 시스템에서 사용됩니다.COBOL은 여전히 대규모 배치 및 트랜잭션 처리 작업과 같은 메인프레임 컴퓨터에 배치된 애플리케이션에 널리 사용됩니다.그러나 그 인기가 떨어지고 경험이 풍부한 COBOL 프로그래머들의 은퇴로 인해 프로그램은 새로운 플랫폼으로 이행되고 있으며 현대 언어로 다시 쓰이거나 소프트웨어 [9]패키지로 대체되고 있습니다.COBOL의 대부분의 프로그래밍은 현재 단순히 기존 애플리케이션을 유지하기 위한 것이지만,[10] 많은 대형 금융 기관들은 2006년까지도 여전히 COBOL의 새로운 시스템을 개발하고 있었습니다.

COBOL은 1959년 CODASYL에 의해 설계되었으며 부분적으로 그레이스 호퍼가 설계한 프로그래밍 언어 FLOW-MATIC에 기초하고 있다.데이터 처리를 위한 휴대용 프로그래밍 언어를 만들기 위한 미국 국방부의 노력의 일환으로 만들어졌습니다.원래는 임시방편으로 여겨졌지만, 국방부가 즉시 컴퓨터 제조업체들에게 그것을 제공하도록 강요했고, 결과적으로 널리 [11]채택되었다.그것은 1968년에 표준화되었고 그 이후로 4번 개정되었다.확장에는 구조화 및 객체 지향 프로그래밍 지원이 포함됩니다.현재 표준은 ISO/IEC 1989:[12]2014입니다.

COBOL 문장은 영어와 유사한 구문을 가지고 있으며, 자체 문서화와 가독성이 뛰어나도록 설계되었습니다.그러나 그것은 장황하고 300개 이상의 예약어를 사용한다.다음과 같은 현대적이고 간결한 구문과는 대조적으로y = x; 의 구문에는, 이 있습니다(이 경우는, COBOL 의 구문입니다.MOVE x TO yCOBOL 코드는 섹션, 단락 및 문장의 엄격한 계층을 포함하는 4개의 디비전(식별, 환경, 데이터 및 프로시저)으로 분할됩니다.대형 표준 라이브러리가 없기 때문에 이 표준에는 43개의 문, 87개의 함수 및 1개의 클래스만 명시되어 있습니다.

학계의 컴퓨터 과학자들은 COBOL이 만들어졌을 때 일반적으로 비즈니스 애플리케이션에 관심이 없었고 설계에 관여하지 않았습니다. COBOL은 입력과 출력에 중점을 두고 처음부터 비즈니스용 컴퓨터 언어로 설계되었으며,[13] 데이터 유형은 숫자와 문자열뿐이었습니다.COBOL은 장황함, 설계 과정, 구조화된 프로그래밍에 대한 지원 부족 등으로 인해 평생 비판을 받아왔다.이러한 약점 때문에, 알기 어려운 일원적이고 장황한(영어와 같은) 프로그램이 생깁니다.

최근 몇 년 동안 COBOL [14]운영을 클라우드 [15]컴퓨팅으로 마이그레이션하는 것에 대한 관심이 높아지고 있지만, COBOL은 메인프레임의 비즈니스 운영을 위한 프로그래밍 언어로 간주되어 왔습니다.

및

★★★

1950년대 후반, 컴퓨터 사용자들과 제조사들은 증가하는 프로그래밍 비용에 대해 우려하기 시작했다.1959년의 조사에 의하면, 데이터 처리의 인스톨에서는, 프로그래밍에 평균 미화 80만달러가 소요되어 새로운 하드웨어로 프로그램을 실행하기 위한 번역에는 60만달러가 소요된다고 합니다.새로운 프로그래밍 언어가 점점 더 빠른 속도로 보급되고 있을 때, 같은 조사에서 공통의 비즈니스 지향 언어를 사용하면 변환이 훨씬 저렴하고 [16]빨라질 것이라고 나타났습니다.

1959년 4월 8일, 메리 K. Burroughs Corporation의 컴퓨터 과학자인 Hawes는 펜실베니아 대학의 학계, 컴퓨터 사용자 및 제조업체 대표자 회의를 소집하여 공통 비즈니스 [17]언어에 대한 공식적인 회의를 조직했습니다.대표자로는 Grace Hopper(영어와 유사한 데이터 처리 언어 FLOW-MATIC의 발명자), Jean Sammet 및 Saul Gorn이 [18][19]있었다.

4월 회의에서 이 단체는 국방부(DoD)에 공통 비즈니스 언어를 만드는 노력을 후원해 줄 것을 요청했다.대표단은 찰스 A에게 깊은 인상을 남겼다.Phillips,[20] DoD의 데이터 시스템 리서치 스태프는 DoD의 문제를 '철저하게' 이해하고 있다고 생각했습니다.국방부는 225대의 컴퓨터를 운영했으며 추가로 175대의 컴퓨터를 주문했으며 이 컴퓨터에서 실행할 프로그램을 구현하는 데 2억 달러 이상을 지출했다.휴대용 프로그램은 시간을 절약하고 비용을 절감하며 [21]현대화를 용이하게 합니다.

찰스 필립스는 그 회의의 주최에 동의하고 대표단에게 [22]의제 초안을 작성하라고 명령했다.

60 60

1959년 5월 28일과 29일(정확히 취리히 ALGOL 58 회의 후 1년 후)에 펜타곤에서 비즈니스용 공통 프로그래밍 언어의 작성에 관한 회의가 열렸다.41명이 참석했고 Phillips가 [23]의장을 맡았다.국방부는 서로 다른 컴퓨터에서 동일한 데이터 처리 프로그램을 실행할 수 있는지 우려했다.당시 유일한 주류 언어였던 FORTRAN은 이러한 [24]프로그램을 작성하는 데 필요한 기능이 부족했습니다.

대표자들은 은행, 보험, 공공요금, 재고관리 등 다양한 환경에서 사용할 수 있는 언어를 열정적으로 설명했습니다.그들은 더 많은 사람들이 프로그래밍을 할 수 있어야 하고 새로운 언어가 현대 기술의 한계에 의해 제한되어서는 안 된다는 것에 만장일치로 동의했다.대다수의 사람들은 영어를 최대한 사용하고, 변화가 가능하며, 기계에 의존하지 않고, 사용하기 쉬워야 한다는 [25]데 동의하였다.

그 결과 운영위원회와 단기, 중기, 장기위원회가 설치되었다.단기 위원회는 중간 언어에 대한 명세서를 작성하도록 9월(3개월)에 주어졌으며, 그 후 다른 위원회가 [26][27]이를 개선하였다.그러나 이들의 공식 임무는 기존 프로그래밍 언어의 장점과 단점을 파악하는 것이었으며 새로운 [24]언어를 만들도록 명시적으로 지시하지는 않았다.그 마감일은 단기 [28]위원회에서 불신에 부쳐졌다.베티 홀버튼이라는 한 멤버는 3개월간의 기한을 "대단한 낙관주의"라고 표현했고, 그 언어가 정말 임시방편이 [29]될 수 있을지 의심했다.

운영위원회는 6월 4일 회의를 열고 전체 활동을 데이터 시스템 언어 위원회(CODASYL)로 명명하고 집행 [30]위원회를 구성하기로 합의했습니다.

이 단기 위원회는 6개의 컴퓨터 제조업체와 3개의 정부 기관을 대표하는 위원들로 구성되었다.6개의 컴퓨터 제조업체는 Burroughs Corporation, IBM, Miniapolis-Honeywell(Honeywell Labs), RCA, Sperry Rand 및 Sylvania Electric Products였습니다.세 개의 정부 기관은 미국 공군, 해군의 데이비드 테일러 모델 분지, 그리고 국립 표준국(현재의 국립 [31]표준 기술 연구소)이었다.위원회는 미국 국립표준국의 조셉 웨그스타인이 의장을 맡았다.작업은 데이터 설명, 문장, 기존 애플리케이션 및 사용자 [32]경험을 조사하는 것으로 시작되었습니다.

위원회는 주로 FLOW-MATIC, AIMACO 및 COMTRAN 프로그래밍 [24][33]언어를 조사했다.FLOW-MATIC 언어는 구현되어 있고 AIMACO가 약간의 [34][35]변경만을 수반하는 파생어였기 때문에 특히 영향력이 있었다.FLOW-MATIC의 발명가인 Grace Hopper는 [28]또한 위원회의 기술 고문으로 일했다.COBOL에 대한 FLOW-MATIC의 주요 기여는 긴 변수 이름, 명령어를 위한 영어 단어, 데이터 설명과 [36]명령의 분리였다.호퍼는 때때로 "코볼의 어머니" 또는 "코볼의 할머니"[37][38][39]로 불리기도 하지만, 코볼의 대표 디자이너인 진 삼메트는 호퍼가 "코볼의 어머니, 창조자, 개발자가 아니었다"[40][1]고 말했다.

Bob Bemer에 의해 발명된 IBM의 COMTRAN 언어는 Grace [43]Hopper의 동료로 구성된 단거리 위원회에서 FLOW-MATIC의[41][42] 경쟁자로 간주되었습니다.IBM이 설계 프로세스를 [26]지배한 것처럼 보이지 않도록 COBOL에 일부 기능이 통합되지 않았으며, 1981년 Jean Sammet은 일부 위원회 위원(자신 포함)[44]으로부터 "강력한 반IBM 편견"이 있었다고 말했다.한편 콤란어 매뉴얼 작성자이자 중급위원이었던 로이 골드핑거가 소위원회에 출석해 언어를 지원하고 대수식 사용을 장려하자 그레이스 호퍼는 스페리 랜드의 영어 [45]기반 언어 창작을 위한 노력을 다시 한 번 강조하는 메모를 단기위원회에 보냈다.1980년 그레이스 호퍼는 "COBOL 60은 95% FLOW-MATIC"이며, COMTRAN은 "극소"의 영향을 미쳤다고 논평했다.게다가 그녀는 일이 FLOW-MATIC와 COMTRAN의 영향을 받았다고 주장할 것이라고 말했다.그것은 단지, 「다른 사람을 기쁘게 하기 위해서(그들이)[46] 우리를 쓰러뜨리지 않게 하기 위해서」.COBOL에 통합된 COMTRAN의 기능에는 공식,[47][48] 조항, 개선된 기능이 포함되었습니다.IFGO TOS의 필요성을 배제하고 보다 견고한 파일 관리 시스템을 [41]구축했습니다.

위원회의 업무 유용성은 큰 논쟁의 대상이었다.몇몇 구성원들은 그 언어가 너무 많은 타협점을 가지고 있고 위원회의 설계 결과라고 생각했지만, 다른 구성원들은 그것이 조사된 세 가지 언어보다 더 낫다고 느꼈다.어떤 사람들은 그 언어가 너무 복잡하다고 느꼈고, 다른 사람들은 [49]너무 단순하다고 느꼈다.논란의 여지가 있는 기능에는 데이터 처리 사용자에게 쓸모없거나 너무 고급이라고 생각되는 기능이 포함되어 있습니다.이러한 기능에는 부울식, 공식 및 표(인덱스)[50][51]가 포함됩니다.또 다른 논란의 포인트는 키워드를 문맥에 맞게 할 것인지와 [50]가독성에 미치는 영향이었다.상황에 맞는 키워드는 거부되었지만, 이 접근법은 나중에 PL/I에서 사용되었고 2002년부터 부분적으로 [52]COBOL에서 사용되었습니다.상호 작용, 운영 체제와의 상호 작용(그 당시에는 거의 존재하지 않았다) 및 기능(순수하게 수학적이고 데이터 [53][54]처리에는 쓸모가 없다고 생각됨)은 거의 고려되지 않았다.

사양은 9월 4일에 집행위원회에 제출되었습니다.Joseph Wegstein은 "거친 부분이 포함되어 있어 몇 가지 추가가 필요하다"고 언급했고, Bob Bemer는 나중에 "호지팟지"라고 표현했다.소위원회는 그것을 [28]개선하기 위해 12월까지 주어졌다.

9월 중순 회의에서 위원회는 새로운 언어의 이름을 논의했다.제안사항으로는 "BUSY"(비즈니스 시스템), "INFOSYL"(정보 시스템 언어), "COCOSYL"(공통 컴퓨터 시스템 언어)[55] 등이 있습니다.밥 베머는 나중에 그것이 그의 [58][59][60]제안이었다고 주장했지만 누가 "코볼"[56][57]이라는 이름을 만들었는지 불분명하다.

중급위원회는 10월 로이 너트가 작성한 FACT 언어 사양 사본을 받았다.그 특징은 위원회에 깊은 인상을 남겼기 때문에 그들은 [61]COBOL을 기반으로 하는 결의안을 통과시켰다.이는 사양에 대해 좋은 진전을 보였던 단기 위원회에 타격이 되었다.Fact는 기술적으로 우수하지만 휴대성을 염두에 두거나 제조사와 사용자의 합의를 통해 작성되지 않았습니다.또한 FLOW-MATIC 기반 COBOL의 지지자들이 결의안을 뒤집을 수 있도록 하기 위해 입증 가능한 [28]구현이 부족했다.RCA의 하워드 브롬버그 대표도 COBOL 구현에 대한 RCA의 작업이 [62]헛되지 않도록 FACT를 차단했다.

위원회가 너무 커서 더 이상의 진전이 빨리 이루어지기 힘들다는 것이 곧 분명해졌다.실망한 하워드 브롬버그는 "코볼"이 새겨진 15달러짜리 묘비를 사서 찰스 필립스에게 보내 [b][64][65]불쾌감을 표시했다.기존 언어를 분석하기 위한 소위원회가 구성되었으며,[24][66] 6명으로 구성되었다.

소위원회는 사양서 작성 작업을 대부분 수행하였고, 최종 [24]사양서를 작성하기 전에 단기 위원회에 작업 검토 및 수정을 맡겼습니다.

이 규격은 1960년 1월 8일 집행위원회에 의해 승인되어 정부 인쇄소로 보내졌고, 정부 인쇄소는 COBOL 60으로 인쇄했다.이 언어의 명시적인 목표는 효율적이고 휴대용 프로그램을 쉽게 작성할 수 있도록 하고 사용자가 최소한의 노력과 비용으로 새로운 시스템으로 이동할 수 있도록 하며 경험이 부족한 [67]프로그래머에게 적합하도록 하는 것이었습니다.CODASYL 집행위원회는 이후 COBOL 유지관리 위원회를 만들어 사용자와 공급업체의 질문에 답변하고 사양을 [68]개선 및 확장했습니다.

1960년 동안, COBOL 컴파일러를 만들려는 제조업체들의 목록이 증가하였다.9월까지 5개 제조업체가 CODASYL(Bendix, Control Data Corporation, General Electric(GE, National Cash Register, Philco)에 추가로 가입했으며, 모든 제조업체가 COBOL 컴파일러를 발표했습니다.GE와 IBM은 각각 COBOL을 그들만의 언어인 GECOM과 COMTRAN으로 통합할 계획이었다.대조적으로, International Computers and Tabulators는 그들의 언어인 CODEL을 COBOL로 [69]대체하려고 계획했다.

한편, RCA와 Sperry Rand는 COBOL 컴파일러를 만드는 일을 했습니다.최초의 COBOL 프로그램은 RCA [70]501에서 8월 17일에 실행되었다.12월 6일과 7일, RCA 컴퓨터와 레밍턴-랜드 유니백 컴퓨터에서 (약간의 변경에도 불구하고) 동일한 COBOL 프로그램이 실행되어 호환성이 [71]달성될 수 있음을 증명했다.

COBOL 매뉴얼에 (COBOL 참조 매뉴얼)에서 .

COBOL은 산업 언어이며, 회사나 회사 그룹, 또는 조직이나 조직의 자산이 아닙니다.

CODASYL COBOL 위원회는 프로그래밍 시스템과 언어의 정확성과 기능에 대해 명시적이든 암시적이든 어떠한 보증도 하지 않습니다.또한 기여자 또는 위원회는 이와 관련하여 어떠한 책임도 지지 않습니다. 및 과 같습니다.

FLOW-MATIC(Unisys Corporation), UNIVAC(R)II, Data Automation Systems, Unisys Corporation, 1958, 1959, Unisys Corporation, IBM Commercial Translator Form No. F28-8013, 1959, IBM 팩트.

그들은 COBOL 사양에서 이 재료의 전체 또는 일부를 사용하도록 특별히 승인했습니다.이러한 허가는 프로그래밍 매뉴얼 또는 유사한 [72]출판물에 COBOL 규격을 복제하고 사용하는 데까지 확대됩니다.

에서 COBOL-65COBOL-61(COBOL-65)로

10시 10분

Anonymous, June 1960[73]

COBOL 60에서 많은 논리적 결함이 발견되어 GE의 Charles Katz는 이를 명확하게 해석할 수 없다고 경고했습니다.마지못한 단기 위원회는 완전한 정리를 제정했고 1963년 3월, 의미 모호성은 [69]남아있지만 코볼의 구문은 ALGOL의 구문과 같이 정의 가능하다고 보고되었다.

초기 COBOL 컴파일러는 원시적이고 느렸다.1962년 미 해군 평가에서는 분당 3~11개의 문장이 편집되는 속도가 발견되었습니다.1964년 중반에는 분당 11-1000개의 스테이트먼트로 증가했습니다.메모리를 늘리면 속도가 급격히 빨라지고 컴파일 비용이 크게 달라지는 것으로 관찰되었습니다. 즉, 명세서당 비용은 $0.23에서 $18.91 [74]사이였습니다.

1962년 말, IBM은 COBOL이 그들의 주요 개발 언어가 될 것이며 COMTRAN의 개발이 [74]중단될 것이라고 발표했다.

COBOL 규격은 발행 후 5년간 세 차례 개정됐다.COBOL-60은 1961년에 COBOL-61로 대체되었다.그 후 1963년 COBOL-61 확장 사양으로 대체되어 분류 및 보고서 작성 기능이 [75]도입되었습니다.추가된 시설은 1959년 말 허니웰이 단기 [70]위원회에 보낸 서한에서 확인한 결함을 수정했다.COBOL Edition 1965는 사양을 더욱 명확히 하고 대용량 스토리지 파일과 [76]테이블을 처리하는 기능을 도입했습니다.

버전 간의 호환성을 극복하기 위해 COBOL을 표준화하기 위한 노력이 시작되었다.1962년 말 ISO와 미국 표준 협회(현재의 ANSI)는 표준을 제정하기 위해 그룹을 결성했습니다.ANSI는 1968년 8월에 USA Standard COBOL X3.23을 생산하여 이후 버전의 [77]주춧돌이 되었다.이 버전은 American National Standard(ANS) COBOL로 알려져 있으며 1972년에 ISO에 [78]의해 채택되었습니다.

COBOL-74

1970년까지 COBOL은 세계에서 [79]가장 널리 사용되는 프로그래밍 언어가 되었다.

ANSI 위원회와는 별도로 CODASYL 프로그래밍 언어 위원회는 언어 개선에 힘쓰고 있었다.이들은 1968년, 1969년, 1970년 및 1973년의 새로운 버전을 설명했는데, 여기에는 개선된 문자열 처리 및 라이브러리 포함 기능뿐만 아니라 새로운 프로그램 간 통신, 디버깅 및 파일 병합 기능 [80]등의 변경사항이 포함됩니다.CODASYL은 ANSI 위원회와는 독립적이었지만,[81] CODASYL Journal of Development는 ANSI에 의해 구현이 보증될 만큼 널리 사용되는 기능을 식별하기 위해 사용되었다.프로그래밍 언어 위원회는 ECMA 및 일본 COBOL 표준 [80]위원회와도 연락을 취했습니다.

그러나 프로그래밍 언어 위원회는 잘 알려지지 않았다.윌리엄 라인헐스 부통령은 코볼 커뮤니티의 3분의 2가 위원회의 존재를 모른다고 불평했다.회의록이나 변경안 등 공문서를 자유롭게 이용할 [82]수 있는 자금도 부족했다.

1974년에, ANSI는 파일 조직과 같은 새로운 기능을 포함하는 (ANS) COBOL의 개정 버전을 발표했습니다.DELETE스테이트먼트와 세그멘테이션모듈을 [84]참조해[83] 주세요.삭제된 기능에는NOTE 「」, 「」,EXAMINE로 )INSPECT및 구현자 정의 랜덤 액세스모듈(새로운 순차적 I/O모듈 및 관련 I/O모듈로 대체되었습니다).이는 44개의 변경사항으로 구성되었으며, 이로 인해 기존 문구가 [85]새로운 기준서와 호환되지 않게 되었다.보고서 작성자는 COBOL에서 퇴출될 예정이었으나 기준이 [86][87]발표되기 전에 복직됐다.ISO는 이후 [78]1978년에 업데이트된 표준을 채택했다.

COBOL-85

1978년 6월 COBOL-74 개정 작업이 시작되었다.제안된 표준(일반적으로 COBOL-80이라고 함)은 이전 표준과 크게 달라 비호환성 및 전환 비용에 대한 우려를 낳았다.1981년 1월, 여행자 보험의 수석 부사장인 조셉 T. 브로피는 COBOL-74와 상위 호환성이 없다는 이유로 표준 위원회를 고소하겠다고 위협했다.Brophy씨는, 지금까지의 4000만 행의 코드 베이스의 변환은 「생산적이지 않다」, 「프로그래머 [88]자원의 완전한 낭비」라고 설명했습니다.그해 말, DPMA(Data Processing Management Association)는 "사용자에게 [89][90]강요된" 변환 비용과 향상된 기능을 들어 새로운 표준에 "강력히 반대"한다고 밝혔습니다.

1차 공개심사 기간 동안 위원회는 2,200건의 답변을 받았는데, 이 중 1,700건이 부정적인 [91]서신이었다.다른 응답은 COBOL-80이 시스템에 미치는 영향에 대한 자세한 분석이었다. 전환 비용은 코드 한 줄당 최소 50센트가 될 것으로 예상됐다.제안된 [92]기준에 찬성하는 응답은 12명 미만이었다.

ISO TC97-SC5는 빔 에빙크하이젠의 주도로 1979년에 국제 COBOL 익스퍼트 그룹을 설치했다.이 그룹은 미국을 포함한 많은 나라의 코볼 전문가들로 구성되었다.이것의 목표는 새로운 COBOL 기능의 필요성에 관해 ANSI와 나머지 세계 간의 상호 이해와 존중을 달성하는 것이었다.3년 후 ISO는 그룹의 지위를 WG 4 COBOL이라는 공식 워킹 그룹으로 변경했습니다.그룹은 대부분의 제안을 ANSI가 수행했던 COBOL 표준의 1차 소유권과 개발을 맡았다.

1983년 DPMA는 국민의 우려에 대한 위원회의 대응성을 들어 이 기준에 대한 반대를 철회했다.같은 해, 미국 표준국(National Bureau of Standards) 연구는 제안된 표준이 거의 [90][93]문제를 일으키지 않을 것이라는 결론을 내렸다.1년 후, DEC는 VAX/VMS COBOL-80을 출시했는데, COBOL-74 프로그램의 변환이 거의 문제를 일으키지 않는다고 언급했다.새로운EVALUATE 및 " " " "PERFORM제어 흐름과 [94]디버깅이 간소화되어 특히 반응이 좋았고 생산성이 향상되었습니다.

두 번째 공개 리뷰는 1,000개(주로 부정적인)의 반응을 이끌어 냈고, 마지막 리뷰는 25개만 끌어냈는데, 이때까지 많은 우려가 [90]해소되었다.

표준의 몇 851985로 하였다.1985년

60개의 기능이 변경 또는 폐지되었으며 다음과[95] 같은 [96][97]115개의 기능이 추가되었습니다.

  • 터미네이터 「스코프 터미네이터」)END-IF,END-PERFORM,END-READ의 개요)
  • 서브
  • CONTINUE, no-operation 스테이트먼트
  • EVALUATE, switch 스테이트먼트
  • INITIALIZE 할 수
  • " "PERFORM본체 – .
  • 수 있습니다.
  • I/O 태 i i i

새로운 [78]표준은 ANSI를 포함한 모든 국가 표준 기구에 의해 채택되었다.

1989년과 1993년에 두 가지 개정안이 뒤따랐는데, 첫 번째 개정안은 내적 기능을 도입하고 다른 개정안은 수정을 [78]제공하였다.

및 COBOL 2002

1997년 Gartner Group은 총 2,000억 개의 COBOL 라인이 존재하며, 이는 [c][98]전체 비즈니스 프로그램의 80%를 실행한다고 추산했습니다.

1990년대 초, COBOL의 다음 전면 개정에서 객체 지향 기능을 추가하는 작업이 시작되었습니다. 객체 지향 기능은 C++와 Smalltalk에서 [2][3]가져왔습니다.최초 추정치는 1997년까지 이 개정판을 완성할 예정이었고 1997년까지 ISO 위원회 초안(CD)을 구할 수 있었다.일부 벤더(Micro Focus, Fujitsu 및 IBM 포함)는 전체 개정판의 초안을 기반으로 객체 지향 구문을 도입했습니다.최종 승인된 ISO 표준은 2002년 [99]말에 승인되어 공표되었습니다.

Fujitsu/GTSoftware,[100] Micro Focus 및 RainCode는 를 대상으로 객체 지향 COBOL 컴파일러를 도입했습니다.NET 프레임워크

CODASYL COBOL Journal of Development 1978년 이후 CODASYL COBOL-85에 [101]포함될 기회를 놓쳐버린 많은 새로운 기능들이 있었다.기타 기능은 다음과 같습니다.[102][103]

2006년에 2건, [104]2009년에 1건 등 3건의 코리젠다가 표준으로 발표되었다.

2014 COBOL 2014

2003년과 2009년 사이에 COBOL의 [104]객체 최종화, XML 처리 및 수집 클래스를 설명하는 3개의 기술 보고서가 작성되었습니다.

COBOL 2002는 지원 부족으로 어려움을 겪었습니다. 즉, 표준을 완전히 지원하는 컴파일러는 없었습니다.Micro Focus는 새로운 기능에 대한 사용자의 요구 부족과 컴파일러 적합성을 테스트하기 위해 사용되었던 NIST 테스트 스위트의 폐지가 원인임을 알게 되었습니다.표준화 과정 또한 느리고 [105]자원이 부족한 것으로 나타났다.

COBOL 2014에는 다음과 같은 [106]변경 사항이 포함되어 있습니다.

  • 휴대용 연산 결과는 IEEE 754 데이터 유형으로 대체되었습니다.
  • 이 선택사항이 VALIDATE, 및 , " " "
  • 동적 용량 테이블(COBOL [107]2002 드래프트에서 삭제된 기능)

★★★★★

COBOL 프로그램은 정부 및 기업에서 전 세계적으로 사용되며 z/OS, z/VSE, VME, Unix, OpenVMS 및 Windows와 같은 다양한 운영 체제에서 실행됩니다.1997년에 Gartner Group은 전 세계 비즈니스의 80%가 COBOL을 기반으로 운영되고 있으며,[108] 연간 2,000억 줄 이상의 코드가[c] 작성되고 50억 줄 이상이 작성되고 있다고 보고했습니다.

20세기 말 무렵, 2000년 문제(Y2K)는 상당한 코볼 프로그래밍 노력의 초점이 되었으며, 때로는 수십 년 전에 시스템을 설계한 프로그래머에 의해 이루어지기도 했습니다.COBOL 코드를 수정하는 데 필요한 특정 수준의 노력은 비즈니스 애플리케이션이 날짜를 많이 사용하기 때문에 비즈니스 지향 COBOL의 많은 양 및 고정 길이 데이터 [109]필드에 기인합니다.일부 연구에서는 "Y2K 소프트웨어 수리 비용의 24%가 코볼"[110]의 탓이라고 합니다.Y2K를 위해 이러한 프로그램을 정리한 후 2003년 조사에 따르면 많은 프로그램이 여전히 [111]사용되고 있는 것으로 나타났습니다.저자들은 이 조사 데이터가 "다른 언어 및 기술과의 통합이 채택되지 않는 한 (다음) 10년 동안 애플리케이션 개발에서 COBOL의 중요성이 점차 낮아질 것"[112]을 시사한다고 말했다.

2006년과 2012년 Computerworld 조사(독자 352명)에서는 조직의 60% 이상이 COBOL(C++ 및 Visual Basic 이상)을 사용하고 있는 것으로 나타났습니다.NET)와 그 절반의 경우 COBOL이 내부 [10][113]소프트웨어의 대부분을 위해 사용되었습니다.관리자 중 36%는 COBOL에서 이행할 계획이라고 답했고 25%는 더 저렴하다면 이행하고 싶다고 답했습니다.대신 일부 기업은 COBOL [10]프로그램을 유지하면서 시스템을 고가의 메인프레임에서 보다 저렴한 최신 시스템으로 마이그레이션하고 있습니다.

2016년 하원 증언에 따르면 코볼은 여전히 많은 [114]연방 기관에서 사용되고 있다.2017년 로이터는 은행 시스템의 43%가 여전히 2200억 줄 이상의 COBOL 코드를 [115]사용하고 있다고 보고했습니다.

2019년에는 은퇴로 인해 COBOL 프로그래머의 수가 급격히 감소하여 여전히 대량 트랜잭션 처리를 위해 메인프레임 시스템을 사용하는 기업과 정부 조직에서 기술 격차가 임박했습니다.새로운 언어로 시스템을 재작성하려는 노력은 코드 유지보수의 아웃소싱과 마찬가지로 비용이 많이 들고 문제가 있음을 입증했으며, 따라서 COBOL에서 더 많은 사람들을 훈련시키자는 제안이 [116]지지되고 있다.

COVID-19 대유행과 그에 따른 실업률 급증 동안, 미국의 몇몇 주에서는 실업급여 관리에 사용되는 기존 시스템을 지원할 숙련된 COBOL 프로그래머가 부족하다고 보고했다.이러한 시스템의 대부분은 대유행 이전에 보다 현대적인 프로그래밍 언어로 변환하는 과정에 있었지만,[117] 그 과정은 보류되어야만 했다.마찬가지로, 미국 국세청은 코로나 바이러스 지원,[118] 구제 및 경제 보안법에 의해 의무화된 수천만 달러의 지급액을 지출하기 위해 COBOL 기반의 개인 마스터 파일에 서둘러 패치를 적용했다.

★★★★★

문문

COBOL은 프로그램의 거의 모든 것을 설명하는 데 사용되는 영어와 유사한 구문을 가지고 있습니다.를 들어, 조건을과 같습니다.x IS GREATER THAN y또는 보다 간결하게 말하면x GREATER y ★★★★★★★★★★★★★★★★★」x > y으로써 보다 복잡한 을 " 수 . 반복된 조건과 변수를 제거함으로써 더 복잡한 조건을 "축소"할 수 있습니다.를 들어, 「」라고 하는 것은,a > b AND a > c OR a = d 말하면 되다a > b AND c OR = d이 영어와 같은 구문을 지원하기 위해 COBOL에는 300개 이상의 [119][d]키워드가 있습니다.일부 키워드는 같은 단어의 단순한 대체 또는 복수 철자이며, 이는 보다 영어다운 문장과 절을 제공한다.IN ★★★★★★★★★★★★★★★★★」OF는, 「키워드」와 할 수 있습니다.TIME ★★★★★★★★★★★★★★★★★」TIMES , , , , 입니다.VALUE ★★★★★★★★★★★★★★★★★」VALUES

각 COBOL 프로그램은 단어, 리터럴, 그림 문자열(see PIGE 절 참조) 및 구분 기호 등 4개의 기본 어휘 항목으로 구성됩니다.단어에는 예약된 단어와 사용자 정의 식별자가 포함됩니다.최대 31자로 문자, 숫자, 하이픈 및 밑줄을 포함할 수 있습니다.리터럴에는 숫자가 포함됩니다(예:12및 문자열(예:'Hello!') 구분자에는 공백 문자, 쉼표 및 세미콜론 뒤에 [122]공백이 포함됩니다.[121]

COBOL 프로그램은 식별부, 환경부, 데이터부 및 프로시저부의 4개의 부문으로 분할된다.식별 부문은 소스 요소의 이름과 유형을 지정하고 클래스 및 인터페이스를 지정합니다.환경 부문은 파일 및 문자 집합과 같이 실행 중인 시스템에 따라 달라지는 모든 프로그램 기능을 지정합니다.데이터 분할은 변수 및 매개 변수를 선언하는 데 사용됩니다.절차 부문에는 프로그램의 문장이 포함되어 있습니다.각 섹션은 단락으로 구성된 섹션으로 세분됩니다.

COBOL의 구문은 보통 괄호, 괄호, 막대 및 밑줄을 사용하여 고유한 메타 언어로 기술됩니다.메타 언어는 원래 COBOL 사양에 맞게 개발되었습니다.그 당시에는 배커스-나우르 형태가 존재했지만 위원회는 그것에 [123]대해 듣지 못했다.

COBOL
★★ ★★ ★★
대문자로 표시 » ★★★★
치다 » .
''' { } 할 수 입니다.
괄호 괄 ] [ ] 할 수 .
할 수 .
★★★★★★★★★★★★★★★★」 } { } 하나 이상의 옵션을 선택할 수 있습니다.모든 옵션은 한 번만 선택할 수 있습니다.
] [ ] 0으로 하다모든 옵션은 한 번만 선택할 수 있습니다.

를 들어, 다음 에 대해 .ADD " statement트트 statement statement statement:

은 다음과 변형을 합니다.

 1  。 x  1 , a , b  。 x  , y , z    a , b  。 c       ★★★  ★★★          ★★★★★" "오류"  end end end end   a  。 b      않다  ★★★  ★★★          ★★★★★' '오류 없음'       ★★★  ★★★          ★★★★★" "오류"

( )

COBOL 고정(무료)고정 형식에서는 코드를 특정 영역에 맞게 정렬해야 합니다(펀치된 카드를 사용하지 않음).

름 name 。 » 。
영역 " " " " 1~6 카드 번호 편집후 하기 위해 하게 한다)에되었던 이 됩니다.
영역 '''」 7 사용할 수 는 다음과 같습니다.
  • * 행 - ★★★★★
  • /– 소스 리스트의 새 페이지에 인쇄되는 코멘트
  • - 또는 - 앞줄의 단어 또는 리터럴.
  • D하게 되어 있습니다.그 이외의 됩니다.그 이외의 경우는 무시됩니다.
A 역 A 8-11 은 다음과 같은 내용을 담고 있습니다.DIVISION,SECTION 헤더 및 와 파일 기술자 " " " (01 " 77 " " " " " / " " ) 。
B 역 B 12-72 A에서 허용되지
[ name ] [ ] 73~ 에는 펀치카드의되었습니다.

COBOL 2002에서 영역 A와 B는 프로그램 텍스트 영역을 형성하기 위해 병합되었으며, 현재는 구현자 정의 컬럼으로 [124]종료됩니다.

COBOL 2002는 COBOL 2002에 있습니다.새로운 프로그래밍 언어에서처럼 파일의 모든 열에 자유 형식 코드를 배치할 수 있습니다.는 하다, 하다, 하다를 사용합니다.*>임의의 장소에 배치할 수 있으며 고정 형식의 소스 코드에서도 사용할 수 있습니다.하지 않으며, '계속행'은 없습니다.>>PAGE는 "directive"를 합니다./인디케이터.[124]

식별 부문은 다음과 같은 코드 엔티티를 식별하며 클래스 또는 인터페이스의 정의를 포함한다.

프로그래밍

클래스와 인터페이스는 2002년부터 COBOL로 되어 있습니다.클래스에는 클래스 메서드와 변수를 포함하는 팩토리 개체와 인스턴스 메서드와 [125]변수를 포함하는 인스턴스 개체가 있습니다.상속 및 인터페이스는 다형성을 제공합니다.범용 프로그래밍 지원은 파라미터화된 클래스를 통해 제공되며, 모든 클래스 또는 인터페이스를 사용하도록 인스턴스화할 수 있습니다.객체는 특정 유형으로 제한될 수 있는 참조로 저장됩니다.메서드를 호출하는 방법에는 두 가지가 있습니다.INVOKE 즉 '문은 '문: 동작은 '문'입니다.CALL또는 [126]함수를 사용하는 것과 유사한 인라인 메서드 호출을 사용합니다. 

*> > > > > > > > > > > > > >    "foo" "foo"  ★★★★★★★★★★★★★★★★★」 하지 않다  ★★★★  "foo" "foo"  。 하지 않다  메서드 *> 인라인 메서드 호출*>

COBOL은 메서드를 숨기는 방법을 제공하지 않습니다.단, 클래스 데이터는 절 없이 선언함으로써 숨길 수 있습니다.이것에 의해,[127] 유저는 액세스 할 수 없게 됩니다.COBOL [128]2014에서 메서드 오버로드가 추가되었습니다.

환경 부문에는 구성 섹션과 입출력 섹션이 포함됩니다.설정 섹션은 통화 기호, 로케일, 문자 집합 등의 변수 기능을 지정하기 위해 사용됩니다.입출력 섹션에는 파일 관련 정보가 포함되어 있습니다.

★★★

COBOL은 시퀀셜, 인덱스 및 relative의 3가지 파일 형식을 지원합니다.순차 파일에서는 레코드는 연속적이며 링크된 목록과 마찬가지로 순차적으로 통과해야 합니다.인덱스 파일에는 레코드를 임의로 액세스하고 정렬할 수 있는 인덱스가 하나 이상 있습니다.각 레코드에는 하나의 키가 있어야 하지만 다른 레코드 키는 고유할 필요가 없습니다.C-ISAM 및 VSAM과 같은 일반적인 구현은 IBM의 ISAM을 기반으로 하지만 인덱스 파일의 구현은 벤더마다 다릅니다.인덱스 파일과 같은 상대 파일에는 고유한 레코드 키가 있지만 대체 키는 없습니다.상대 레코드의 키는 서수 위치입니다. 예를 들어, 10번째 레코드의 키는 10입니다.즉, 키가 5인 레코드를 작성하려면 (빈) 이전 레코드를 작성해야 할 수 있습니다.상대 파일도 순차적 액세스와 [129]랜덤 액세스를 모두 허용합니다.

일반적인 비표준 확장자는 텍스트 파일을 처리하는 데 사용되는 조직입니다.파일 내의 레코드는 줄바꿈으로 종료되며 길이가 [130]다를 수 있습니다.

division data division(데이터 분할)

데이터 분할은 서로 다른 항목을 선언하는 6개의 섹션으로 분할됩니다.파일 레코드의 경우 파일 섹션, 정적 변수의 경우 작업 스토리지 섹션, 자동 변수의 경우 로컬 스토리지 섹션, 파라미터 및 반환 값의 경우 링크 섹션, 보고서 섹션 및 화면 섹션, 텍스트 기반의 사용자 인터페이스의 경우 화면 섹션입니다.

★★★★★★★

COBOL의 데이터 항목은 데이터 항목이 다른 항목의 일부인지 여부를 나타내는 레벨 번호를 사용하여 계층적으로 선언됩니다.상위 레벨 번호를 가진 항목은 하위 레벨 번호를 가진 항목에 종속됩니다.레벨 번호가 1인 최상위 데이터 항목을 라고 합니다.하위 집계 데이터가 있는 항목을 "라 하고, 그렇지 않은 항목을 "라 합니다. 표준 데이터 항목을 설명하는 데 사용되는 레벨 번호는 1에서 49 [131][132]사이입니다. 

       01   레코드.                    항목*> 집계 그룹 레코드 항목*> 집계 그룹 레코드 항목            05              PIC 9(10).  *> > 기 * * *            05  .                   항목*> 집계(서브)                10     PIC 9(4).   *> > 기 * * *                10   달  PIC 99.     *> > 기 * * *                10      PIC 99.     *> > 기 * * *

예에서는 " " " 입니다.num 그룹 and and and and "the-date에 되어 있다some-record while 、 [ items ], 「 」the-year,the-month , , , , 입니다.the-day 항목의 입니다.the-date

은 '부재하다'로 할 수 .IN (오류)OF 를 지정합니다). 키워드를 지정합니다.를 들어, 예를 보겠습니다. 예를 들어, 코드 예시는 과 같습니다.

       01  .            05         PIC 9(4).            05   달      PIC 99.            05          PIC 99.

★★the-year,the-month , , , , 입니다.the-day두 개 이상의 데이터 항목이 이러한 이름으로 정의되어 있기 때문에 그 자체로 모호합니다.항목을 하는 경우(를 들어, 「」에 포함되는 중 ).sale-date는 ""를 사용합니다.the-year IN sale-date한 것)the-year OF sale-date은 대부분의 언어에서 되는 ' 표기법합니다).

데이터

레벨 번호 66은 이전에 정의된 항목의 재분류를 선언하기 위해 그 항목의 구조화 방식과 관계없이 사용된다.이 데이터 레벨은, 관련지어도 참조되고 있는 것으로, 거의 사용되지[133] 않고, 1988년경에는 주로 낡은 프로그램에서 볼 수 있었습니다.계층 구조 및 논리 구조 데이터를 무시하는 기능은 사용을 권장하지 않으며 많은 설치에서 사용을 [134]금지하고 있음을 의미합니다. 

       01   레코드.            05   스 cust            PIC X(10).            05   객 cust고.                10  cust-first-name() PIC X(30).                10   cust cust cust cust cust  PIC X(30).            05              PIC 9(8).            05   밸런스        PIC 9(7) V99.                    66      변경  객 cust고  .        66   cust cust cust         변경  객 cust고   밸런스.

이 0177 level-number는 level-number 01 level-number에 합니다.를 들어, 다음 는 두 개의 항목인 를를들음음음음음음음음 음음음77, for two for for two two two two two two two two two two를 합니다.property-name ★★★★★★★★★★★★★★★★★」sales-region으로서 다른 항목과는 않음)

       77        PIC X(80).        77   지역       PIC 9(5).

88 level-number는 상위 데이터 항목에 에서 지정된 값 중 하나가 포함되어 있을 때 true(이른바 88-level)를 선언합니다.VALUE절을 클릭합니다.[135]예를 들어, 다음 코드는 의 현재 문자 데이터 값에 따라 true 또는 false인88 레벨의 조건명 항목을 2개 정의합니다.wage-type itemdata 에 값이 포함되어 있는 'H', condition-namewage-is-hourly 값이 true일 true가 .'S' ★★★★★★★★★★★★★★★★★」'Y', condition-namewage-is-yearly 두 조건 false입니다.데이터 항목에 다른 값이 포함되어 있으면 두 조건 이름이 모두 false입니다. 

       01            PIC X.            88  이 되다  ★★'하.            88  이 되다  ★★의 , 'Y'.

(「」)

표준 COBOL은 다음과 같은 데이터 [136]유형을 제공합니다.

데이터 ★★ 예시 " " " ★★★★★
''' PIC A(30) 을 사용하다
숫 alphanum PIC X(30) 을 사용법
(부울) PIC 1 USAGE BIT 0과 1의 형식으로 이진수로 저장된 데이터입니다.
★★ USAGE INDEX 이치노
★★★★★ PIC N(30) 영숫자와 비슷하지만 UTF-8과 같은 확장 문자 집합을 사용합니다.
자 PIC 9(5)V9(2) 그럼 7은 7=5+2)이면 된다 'V는.'V'는 고정 소수점 숫자에 암묵적인 소수점을 찾습니다.
★★ USAGE OBJECT REFERENCE 또는 「」의 할 수 있습니다.NULL
★★★ USAGE POINTER

COBOL에서는 타입 안전성이 가변적입니다.숫자 데이터는 다른 표현과 크기 간에 자동으로 변환되며, 숫자 및 그룹 데이터를 [137]포함하여 문자열로 저장할 수 있는 모든 데이터 항목에 영숫자 데이터를 배치할 수 있습니다.반대로 오브젝트 참조 및 포인터는 같은 유형의 항목에서만 할당할 수 있으며 그 값은 특정 [138]유형으로 제한될 수 있습니다.

픽토르 ★★

A PICTURE (오류)PIC각할 수 구는 문자열로, 각 문자는 데이터 항목의 일부와 포함할 수 있는 내용을 나타냅니다.일부 그림 문자는 항목의 유형과 항목이 메모리에서 차지하는 문자 또는 숫자 수를 지정합니다.를 들면, 「」라고 하는 은,9 10진수입니다.S항목에 서명되었음을 나타냅니다.다른 그림 문자(호출 문자 및 문자)는 항목의 형식을 지정합니다.예를 들어, 일련의+ 선두 문자를 최종 에서 어떻게 되어 있습니다.또, 그 의 문자 에는, 「마지막 문자 데이터」에 하는 문자 됩니다.과과같같같같다다+이 위치의 왼쪽에 공백이 포함됩니다.에 괄호로 숫자를 지정함으로써 할 수 림; a문 repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated그 repeated repeated repeated그 repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated repeated 。 예를 들어 다음과 같습니다.9(7) 9999999(. 숫자만 포함)를 사양(.9 ) 및 ( ))S) 문자는 순수 데이터 항목을 정의하며 이미지 사양은 영문자를 포함합니다( ).A영숫자)X) 문자는 데이터 항목을 정의합니다.또는 데이터 [139]항목을 정의하는 다른 형식 문자의 존재.

»
PICTURE 조 clause §의 값: 출력 ★★★★★
PIC 9(5) 100 00100
"Hello" "Hello"(이는 합법이지만 정의되지 않은 [137]동작이 발생합니다.)
PIC +++++ -10 " -10" 선두 공백) (「」를 참조해 주세요).
PIC 99/99/9(4) 31042003 "31/04/2003"
PIC *(4)9.99 100.50 "**100.50"
0 "****0.00"
PIC X(3)BX(3)BX(3) "ABCDEFGHI" "ABC DEF GHI"
사용방법 »

USAGE절은 데이터가 저장되는 형식을 선언합니다.에 따라 할 수 .PICTURE절을 클릭합니다.포인터와 오브젝트 참조를 선언하는 데 사용할 수 있지만 대부분 숫자 유형을 지정하는 데 사용됩니다.수치 형식은 다음과 같습니다.[140]

  • 는 ""로됩니다. 여기서 최소 사이즈는PICTURE 또는 "a"에 USAGE「」의 절BINARY-LONG.
  • USAGE COMPUTATIONAL되는 모든 형식으로 할 수 의 경우, 데이터 격납은 「실장에 상당합니다.을 사용하다USAGE BINARY
  • USAGE DISPLAY됩니다(데이터는 과 같습니다
  • IEEE 754 입니다.
  • USAGE NATIONAL
  • USAGE PACKED-DECIMAL여기서 데이터는 가능한 최소 10진수 형식으로 저장됩니다(일반적으로 2진수 코드화된 10진수).

라이터

보고서 작성기는 보고서 작성을 위한 선언적 기능입니다.프로그래머는 보고서 레이아웃과 보고서 작성에 필요한 데이터만 지정하면 되기 때문에 페이지 나누기, 데이터 포맷, 제목과 [141]풋팅 등의 처리를 위해 코드를 쓸 필요가 없습니다.

보고서는 보고서 작성기 문을 통해서만 쓸 수 있는 파일인 보고서 파일과 관련지어집니다. 

       FD  출력  .

각 보고서는 데이터 부서의 보고서 섹션에 정의됩니다.보고서는 보고서의 제목, 기초 및 세부사항을 정의하는 보고서 그룹으로 분할됩니다.보고서는 계층에 따라 작동합니다.제어 중단은 주요 변수가 값을 변경할 때 발생합니다.예를 들어, 고객의 주문을 상세하게 설명하는 보고서를 작성할 때 프로그램이 다른 고객의 주문에 도달하면 제어 중단이 발생할 수 있습니다.다음은 영업 사원의 매출을 제공하고 유효하지 않은 레코드에 대해 경고하는 보고서의 설명 예입니다.

                    페이지  ★★★ 60  ★★★★             번째  정보 3             .         01   ★★★★★ 페이지  ★★★★★.            03   1                     ★★ 보고서.            03   74                    ★★.            03   79                   PIC Z9  ★★★ .         01   판매  ★★★★★  정보 ,  »+ 1.            03   3                     ★★"판매 개시일".            03   12                   PIC 99/99/9999  ★★★ .            03   21                    ★★were.            03   26                   PIC $9.99 러러  ★★★ .         01    ★★★★★  정보 ,  »+ 1.            03   3                     ★★ 레코드 "비활성 레코드:".            03   19                   PIC X(34)  ★★★ .         01   ★★★★★  ★★★  ★★★★★  ,  »+ 2.            03   1                     ★★.            03   9                    PIC X(30)  ★★★ .

레이아웃에 설명합니다.배치는 다음과 .

 1일: Howard  102008년  $0 2008년 12월  Bromberg  Bromberg 2008년 10월 12일 매출액 $0.★★★★★★★★★★★... 판매  페이지 의 매출액은 Selden  12월 14일, 2014년 8월 5일, William Selden 12O52014년0 2014, $5, $30 FOOO 매 0.00입니다.

4성명은 보고서 작성:보고서 작성자는 다음 4개의 스테이트먼트에의해 제어됩니다를 조절한다.INITIATE,는 건 보고서 작성자의인쇄를 준비합니다 인쇄를 위한 보고서 작성을 준비한다.GENERATE,는 건 보고서그룹을 인쇄합니단 보고서 그룹 인쇄합니다.SUPPRESS,;그리고 보고서그룹의 인쇄를 억제합니단 보고서 그룹의 인쇄 억제된다.TERMINATE, 신고 처리를 종결한다.보고서 처리를 종료합니다.위의 판매 보고서 예를 들어, 절차 이:위의 판매 보고서 예에서 절차 부문은 다음과 같습니다처럼 보일지도 모른다

           OPEN열다. INPUT입력 sales판매의 , OUTPUT산출량  출력            INITIATE개시하다               PERFORM수행하다 UNTIL까지 1 <><><>고객명>>님 1                READ읽어주세요                     하고 있다  end                         ★★★★                  ★★★★★                                   만약이다  valid valid                     ★★★★★  판매                 않다                     ★★★★★                 end-if  、 if             퍼포먼스               。               ,  출력            .

Report Writer 기능의 용도는 크게 다른 경향이 있었습니다.어떤 조직에서는 광범위하게 사용하고 있는 경우와 [142]전혀 사용하지 않는 경우가 있었습니다.또한, Report Writer의 구현은 품질에 따라 다양하며,[142] 로우엔드의 구현은 런타임에 과도한 양의 메모리를 사용하는 경우가 있습니다.

★★★★

절차 부문의 섹션과 단락(일반적으로 절차라고 함)은 라벨 및 단순한 서브루틴으로 사용할 수 있습니다.다른 부서와 달리 단락은 섹션에 [143]있을 필요가 없습니다.프로그램이 [144]종료될 때까지 프로그램의 절차를 통해 실행이 중단됩니다.절차를 서브루틴으로 사용하려면PERFORM동사가 사용됩니다.

A PERFORM이 코드에 과 다소 합니다.PERFORM단, 파라미터 전달 또는 결과값 반환 메커니즘은 제공되지 않습니다.서브루틴이 다음과 같은 간단한 문을 사용하여 호출되는 경우PERFORM subroutine프로시저의 control은 호출된 프로시저의 마지막에 반환됩니다. ★★★★★★★★★★★★★★.PERFORM는, 복수의 인접 프로시저에 걸친 일련의 범위를 호출하기 위해서 사용되는 경우가 있습니다. 해서 하는 예요.PERFORM sub-1 THRU sub-n ★★★★

. .                     ★★★★★★★★★★★★★★★★」. .      ★★★★★'. .      ★★★★★. .      ★★★★★.

은 「AAB C입니다.

PERFORM, 에는 콜 스택, 콜 스택, 콜 스택, 콜 의 개념이 존재하지에서도, 과는 다릅니다.그 결과, 네스트된 호출이 가능합니다(코드 시퀀스는PERFORM'는 'ed'를 할 수 .PERFORM스테트트먼먼트자자자) 단, 양쪽 호출에 의해 동일한 코드의 일부가 실행되는 경우에는 각별한 주의가 필요합니다.이 문제는 내부 호출의 코드가 외부 호출의 종료점에 도달했을 때 발생합니다. 더 형식적으로 말하면 가 A의 입니다.PERFORM이전에 호출되었지만 아직 완료되지 않은 호출은 COBOL 2002 표준에 의해 동작이 정의되지 않았다고 공식적으로 규정되어 있습니다.

그 이유는 COBOL이 "복귀 주소"가 아닌 "계속 주소"라고 불리는 것과 함께 작동하기 때문입니다.제어 플로우가 어느 하나의 순서의 마지막에 도달하면, 계속 주소가 검색되어 그 주소로 제어가 전송 됩니다.실행되기 하면, 경우는, 프로시저의 속행 주소가 개시됩니다.PERFORM스테이트먼트가 발생하고 제어가 프로그램을 통해 위에서 아래로 흐릅니다. ★★★★★★★★★★★★★★★★★PERFORM프로시저의 )가 됩니다(「착신 범위」의 는, 「착신 범위」의 마지막 프로시저).PERFORM THRU사용되었습니다).이렇게 하면 제어는 마지막에 콜사이트로 돌아갑니다원래 값이 저장되었다가 나중에 복원되지만 저장 위치는 하나뿐입니다.두 개의 중첩된 호출이 겹치는 코드로 동작하는 경우, 이러한 호출은 여러 [145][146]가지 방법으로 서로의 연속 주소 관리를 방해할 수 있습니다.

다음 예(Verman & Verhoeven 2006에서 발췌)는 이 문제를 나타내고 있습니다.

LABEL 1  11.      ★★★★★ '1'      LABEL 2  22  LABEL 3        ★★★★★★★★★★★★★★★★」. LABEL 2  22.      ★★★★★      LABEL 3    4 4 label4. LABEL 3 .      ★★★★★ '3'.  4 4 label4.      ★★★★★ '4'.

은 '1 2 34될 할 수 : '표시된 후 두 '1 2 3 4 3'이 .PERFORM그러면 "3"과 "4"가 표시되고 첫 번째 호출은 "3"으로 계속됩니다.COBOL을 사용하다보다는 첫 번째가 더 낫습니다.PERFORM에서는, 「계속 의에 「 주소」를 합니다.LABEL3 콜 됩니다.LABEL1두 . . . .PERFORM을 ''의 합니다.LABEL4, , 의, 의, but의 주소는 변경되지 않습니다.LABEL3디폴트 계속으로 상정하고 있습니다. 내부 했을 때LABEL3PERFORM그러면 프로그램이 "1 2 3"만 인쇄하지 않게 됩니다.컴파일러와 COBOL 에서는 두 의 TinyCOB가 됩니다.OL 컴파일러와 같은 일부 코볼 구현에서, 두 가지 요소는PERFORM문장은 서로 간섭하지 않으며 출력은 "1 2 3 4 3"입니다.따라서 이러한 경우의 동작은 놀랄 뿐만 아니라 [146]휴대성이 없습니다.

이 제한의 특별한 결과는 다음과 같습니다.PERFORM재귀 코드를 쓰는 데 사용할 수 없습니다.이것을 설명하는 또 하나의 간단한 예(Verman & Verhoven 2006에서 약간 간략화): 

     ★★★★ 1  。 A      LABEL  label 。       ★★★★★★★★★★★★★★★★」. LABEL  label 。.      A     만약이다 A < > 3          1  。 A          LABEL  label 。     end-if  、 if      ★★★★★'.

출력은 "1 2 3 END END"로 예상할 수 있으며, 실제로 일부 COBOL 컴파일러가 그렇게 됩니다.그러나 IBM COBOL과 같은 일부 컴파일러는 "1 2 3 END END END..." 등을 인쇄하고 "END"를 끝없이 반복 인쇄하는 코드를 생성합니다.주소를 은 한정되어 있기 할 수 은, 「」에의입니다.DISPLAY 'END'를 클릭합니다.[146]

COBOL 2014에는 47개의 문(일명 ')[147]이 있으며, 제어 흐름, I/O, 데이터 조작 및 보고서 작성기로 분류할 수 있습니다.보고서 작성자의 진술은 보고서 작성자 섹션에서 다룹니다.

흐름

COBOL의 조건문은 다음과 같다.IF ★★★★★★★★★★★★★★★★★」EVALUATEEVALUATE는 여러 값과 조건을 평가하는 기능이 추가된 스위치와 같은 스테이트먼트입니다.이는 의사결정표를 구현하기 위해 사용할 수 있습니다.예를 들어 CNC 선반을 제어하기 위해 다음 항목을 사용할 수 있습니다.

  ,  속도 ,  속도      을 닫다 ,  속도  (최대 속도) ,  ★★★★★  않다  속도           업 머신      을 닫다 ,  속도  (최대 속도) ,  크다  않다  속도           (슬로우다운 머신)      을 열다 ,  ,  않다  ★                          END-Evaluate의 평가

PERFORM스테이트먼트는 조건이 true가 될 때까지 실행되는 루프를 정의하기 위해 사용됩니다(다른 언어에서는 true가 아닌 경우).또, 콜 프로시저 또는 프로시저의 범위에도 사용됩니다(자세한 것에 대하여는, 순서 섹션을 참조해 주세요). CALL ★★★★★★★★★★★★★★★★★」INVOKE서브프로그램과 메서드를 각각 호출합니다.하위 프로그램/메서드의 이름은 리터럴 또는 데이터 [148]항목일 수 있는 문자열에 포함됩니다.매개변수는 참조, 내용(복사본이 참조로 전달되는 경우) 또는 값(프로토타입이 [149]사용 가능한 경우에만)으로 전달될 수 있습니다. CANCEL메모리로부터 서브 프로그램을 언로드 합니다. GO TO를 지정하면 프로그램이 지정된 프로시저로 넘어갑니다.

GOBACKstatement는 return 스테이트먼트이며,STOP이치노EXIT스테이트먼트에는 리턴 스테이트먼트, 브레이크 스테이트먼트, Continue 스테이트먼트, 엔드마커 또는 [150]프로시저를 종료하기 위한6가지 형식이 있습니다.

에 의해 예외가 발생합니다.RAISE또는 에서 정의된 핸들러에 의해 검출된 스테이트먼트DECLARATIVES절차 부서의 일부입니다.선언문은 다음과 같이 시작하는 섹션입니다.USE처리할 오류를 지정하는 문입니다.을 사용하다 RESUME 뒤에 외부 됩니다.DECLARATIVES다른 언어와는 달리, 검출되지 않은 예외는 프로그램을 종료하지 않을 수 있으며 프로그램은 영향을 받지 않고 진행할 수 있습니다.

I/O

I 는, 기술 「I/O」에 됩니다.OPEN,CLOSE,READ , , , , 입니다.WRITE세 가지 설명하겠습니다.REWRITE ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★」START를 사용하여 또, 「 」 、 「 」 、 「 」 。UNLOCK마지막으로 접근한 레코드에 대한 잠금을 해제합니다.

은 을 사용하세요.ACCEPT ★★★★★★★★★★★★★★★★★」DISPLAY

데이터 ★★

하는 동사는

  • INITIALIZE이치노
  • MOVE데이터 항목에 값을 할당합니다. MOVE CONPORATING은 대응하는 같은 이름의 필드를 할당합니다.
  • SET15가지 형식으로 구성되어 있습니다.인덱스 수정,[151] 오브젝트 참조 할당, 테이블 용량 변경 등이 가능합니다.
  • ADD,SUBTRACT,MULTIPLY,DIVIDE , , , , 입니다.COMPUTECOMPUTE을 사용하다
  • ALLOCATE ★★★★★★★★★★★★★★★★★」FREE동적 메모리를 처리합니다.
  • VALIDATE데이터 분할의 항목 설명에 지정된 대로 데이터를 검증하고 배포합니다.
  • STRING ★★★★★★★★★★★★★★★★★」UNSTRING각각 스트링을 연결 및 분할합니다.
  • INSPECT문자열 내에서 지정된 하위 문자열의 인스턴스를 집계하거나 대체합니다.
  • SEARCH이 명령어는 조건을 충족하는 첫 번째 엔트리를 테이블에서 검색합니다.

및 은 " " 를 사용하여 됩니다.SORT 및MERGE마지RELEASE하고, 동사는 정렬할 레코드를 제공합니다.RETURN는 정렬된 레코드를 순서대로 가져옵니다.

를 들어, '하다'와 같은이 있습니다.IF ★★★★★★★★★★★★★★★★★」READ에는, 그 자체에 문장이 포함되어 있는 경우가 있습니다.이러한 문장은 두 가지 방법으로 종료할 수 있습니다. 마침표()implicit termination는 모든 종료되지 않은 문을 종료하거나 스코프 터미네이터는 가장 가까운 일치 오픈 문을 종료합니다. 

 기간 종료 터미네이터 기간("암시적 ") 만약이다  효 invalid     만약이다  이상 참을 수 없다         에.  장 sentence sentence sentence      않다         판독  파일             하고 있다  end   이상 참을 수 없다  。 .   종료 범위 터미네이터("명시 ") 만약이다  효 invalid     만약이다  이상 참을 수 없다               않다         판독  파일             하고 있다  end   이상 참을 수 없다  。           ★★★★★     end-if  、 if end-if  、 if

마침표로 끝나는 중첩된 문은 [152][153]버그의 일반적인 원인입니다.예를 들어, 다음의 코드를 조사합니다.

만약이다 x      y.      z.

여기에서는, 다음의 정보를 표시하는 것을 목적으로 하고 있습니다.y ★★★★★★★★★★★★★★★★★」z 「」의 경우x하지만 지지,는, ,지,,,,지,,,지,z이 무엇이든 표시됩니다.x 이유는IF가 에러 뒤에 .DISPLAY y

또 다른 버그는 행잉 else의 문제로 인해 발생합니다.IF에는, 「어느 쪽인가 하면」이라고 할 수 있습니다.ELSE

만약이다 x     만약이다 y          a  않다      b.

fragment에서는 fragment가ELSEIF y합니다.IF x스테이트먼트, 버그를 발생시킵니다. 터미네이터가하려면 " " 필요합니다.ELSE NEXT SENTENCE IF를 클릭합니다.[153]

수정

높은 「코볼」(1959)이 되고 있습니다.ALTER X TO PROCEED TO Y많은 컴파일러가 자기 인식 코드를 생성한 스테이트먼트입니다. X ★★★★★★★★★★★★★★★★★」Y "" " " " " " " " " " 입니다.GO TOX 후에 ALTER는 ""를 의미합니다.GO TO Y대신.많은 컴파일러가 여전히 [154]이 버전을 지원하지만 COBOL 1985 표준에서는 더 이상 사용되지 않는 것으로 간주되어 2002년에 [155]삭제되었습니다.

ALTER문장은 "문맥의 해석"을 저해하고 프로그램의 전체적인 논리를 [156]이해하기 어렵게 만들었기 때문에 평가되지 않았다.교과서 저자 대니얼 D.로서. 맥크라켄은 1976년 "이 프로그램을 본 적이 없는 사람은 가능한 한 빨리 이 프로그램에 익숙해져야 하며, 때로는 프로그램이 실패했기 때문에 심각한 시간 압박을 받기도 한다.프로그램 전체의 미지의 장소에 미지의 수의 ALTER 스테이트먼트가 존재하는 것처럼, 문단 자체의 GO TO 스테이트먼트를 보면, 가장 용감한 프로그래머의 [156]심장은 공포에 떨게 됩니다.

, ★★★★★★

COBOL의 "Hello, world" 프로그램:

        ★★★★★ .        PROGRAM-ID . .        . .             ★★★★★안녕,상아!            .

1978년 C Programming Language의 "Hello, World!" 프로그램 예가 처음 공개되었을 때 유사한 메인프레임 COBOL 프로그램 샘플이 JCL을 통해 제출되었을 것입니다.아마도 펀치 카드 리더와 80개의 컬럼 펀치 카드를 사용하고 있을 것입니다.아래 목록은 빈 DATA Division을 사용하여 MVS 3.8J를 실행하는 Linux 및 System/370 Hercles 에뮬레이터를 사용하여 테스트되었습니다.2015년 7월에 작성된 JCL은 Jay Mosely가 [157]진행하는 헤라클레스 튜토리얼과 샘플에서 파생되었습니다.그 시대의 COBOL 프로그래밍에 맞추어 HELLO, WORLD는 모두 대문자로 표시됩니다. 

//   »  )001 TEST 'COBOL' ,                                 00010000 //              ★★★★=A ,=A , LEVEL MSG 레레= )1 ,1)                        00020000 // EXEC                                                  00030000 //★★. DD *                                                        00040000  00000* ★★  †  ★★★                                  00050000  01000  ★★★★★ .                                         00060000  01100 PROGRAM-ID . 안녕하세요..                                             00070000  02000  ★★ .                                            00080000  02100  ★★★  ★★★★.                                           00090000  02110 .  GNULINUX GNUX.                                      00100000  02120 .  .                                      00110000  02200 .                                                   00120000  02210     ★★★★ IS .                                            00130000  03000  .                                                   00140000  04000 . .                                              00150000 04100 00-.                                                         00160000  04110      ★★★★★ 'HELLO, WORLD'  upon .                           00170000  04900       ★★★★★★★★★★★★★★★★」.                                                    00180000 //가 되다.SYSLIB  sys sys DD  이름=SYS1SYS1.★★★ ,= ★★★                            00190000 //            DD  이름=SYS1SYS1.LINKLIB  link link ,= ★★★                           00200000 //GO★★★★★★★★★★★★★★★★★★. DD SYSOUT  sys sys=A                                               00210000 //                                                                      00220000

에는 JCL "MVS "D" 가 

    19.52.48 JOB 3 $HASP 100 COBUCLG ON 리더1 COBOL BASE TEST 19.52.48 JOB 3 IEF677I JOB 3 $HASP373 COBULG STARTED - INIT 1 - CLASA - SYS BSP 19.52.481에 대한 경고 메시지.H DD 문 누락 19.52.48 JOB 3 IEFACTRT - 스텝네임 Procstep 프로그램 재코드 19.52.48 JOB 3 COBUCLG BASETEST COB IKFCBL00 RC= 0000 19.52.48 JOB 3 COBULG BASETEST L IEKED3 +  WORLD .52.48 JOB 3 + WORLD 3  PGM*. 19.52.48 JOB 3 COBULCLG BASETEST GO PGM=*. RC= 193 $ DD RC= 0000 19.52.48 JOB 3 $HASP395 COBULCLG »

위의 콘솔의 10행은 효과를 위해 강조 표시되어 있지만 강조 표시되어 있는 것은 실제 콘솔 출력의 일부가 아닙니다.

및

★★★★★★

1970년대에 구조화된 프로그래밍 패러다임의 채택은 점점 더 널리 퍼지고 있었다.뛰어난 컴퓨터 과학자인 Edsger Dijkstra는 1975년 출판된 Communications of the ACM의 편집자에게 "How do we tell through through that hape that hapter?"라는 제목의 편지를 썼는데, 그는 COBOL과 다른 여러 현대 언어에 대해 비판적이었고, "COBOL의 사용은 정신을 마비시켰다"[158]고 언급했습니다.Dijkstra의 발언에 대한 출판된 반대 의견에서 컴퓨터 과학자인 Howard E.톰킨스는 구조화되지 않은 코볼은 "구조화 코볼이 잘 가르쳐진 적이 없는 프로그래머에 의해 작성되는 경향이 있다"고 주장하면서, 이 문제가 주로 [159]훈련의 하나라고 주장했다.

스파게티 코드의 한 가지 원인은GO TO「」. 「」를 삭제하려고 .GO TO그러나 COBOL 코드의 s는 복잡한 프로그램과 코드 [160]품질 저하를 초래했다. GO TO는 주로 다음 명령어로 대체되었습니다.PERFORM모듈러[160] 프로그래밍을 촉진하고 강력한 루프 설비에 쉽게 접근할 수 있도록 하는 스테이트먼트와 프로시저.하지만,PERFORM루프 본체가 사용된 위치에 위치하지 않도록 프로시저에서만 사용할 수 있기 때문에 프로그램을 [161]이해하기 어렵습니다.

COBOL 프로그램은 획일적이고 모듈화가 [162]부족한 것으로 악명이 높았다.COBOL 코드는 대형 시스템에 적합하지 않은 프로시저를 통해서만 모듈화할 수 있었다.데이터에 대한 액세스를 제한하는 것은 불가능했습니다. 즉, 절차는 모든 데이터 항목에 액세스하고 수정할 수 있습니다.게다가, 절차로 매개변수를 넘길 수 있는 방법이 없었고, Jean Sammet은 위원회의 가장 큰 [163]실수로 간주되었다.또 다른 합병증은 할 수 있는 능력에서 비롯되었다.PERFORM THRU특정 절차 순서이는 제어가 어떤 프로시저에서도 점프하거나 복귀할 수 있다는 것을 의미하며 복잡한 제어 플로우를 생성하고 프로그래머가 싱글 엔트리 싱글 출구 규칙을 [164]어길 수 있도록 합니다.

이러한 상황은 COBOL이 더 많은 기능을 채택함에 따라 개선되었습니다.COBOL-74는 하위 프로그램을 추가하여 프로그래머들에게 프로그램의 각 부분이 접근할 수 있는 데이터를 제어할 수 있는 능력을 주었다.그 후 COBOL-85는 중첩된 하위 프로그램을 추가하여 프로그래머들이 하위 프로그램을 [165]숨길 수 있게 했다.데이터와 코드에 대한 추가적인 제어는 객체 지향 프로그래밍, 사용자 정의 함수 및 사용자 정의 데이터 유형이 포함된 2002년에 이루어졌다.

그럼에도 불구하고 매우 중요한 레거시 COBOL 소프트웨어는 비구조화 코드를 사용하므로 유지보수가 불가능하게 되었습니다.코드의 간단한 부분이라도 수정하는 것은 너무 위험하고 비용이 많이 들 수 있습니다.이는 알려지지 않은 [166]장소에서 알려지지 않은 방법으로 사용될 수 있기 때문입니다.

호환성 문제

COBOL은 휴대성이 뛰어난 "공통" 언어입니다.하지만 2001년까지 약 300개의 사투리가 만들어졌다.[167]한 가지 사투리의 원천은 표준 자체였다: 1974년 표준은 하나의 필수 핵과 11개의 기능 모듈로 구성되었으며, 각각 두세 가지 수준의 지원을 포함하고 있다.이는 104,976개의 공식 [168]변형을 허용했다.

COBOL-85는 이전 버전과 완전히 호환되지 않았고, 그 개발은 논란이 있었다.Travelers Insurance의 CIO인 Joseph T. Brophy는 COBOL 사용자에게 새로운 [169]표준을 구현하는 데 드는 막대한 재프로그래밍 비용을 알리기 위해 앞장섰습니다.그 결과, ANSI COBOL 위원회는 대중으로부터 2,200통 이상의 서한을 받았는데, 대부분 부정적이었다.한편, COBOL-85로의 전환은 향후 생산성을 향상시켜 전환 비용을 정당화할 [170]것으로 생각되었다.

상세 구문

COBOL: /kohbolbol/, n.

코드그라인더들이 공룡의 메인프레임에서 지루한 생각 없는 일을 하기 위해 사용하는 나약하고 장황한 언어입니다.[...] 그 이름 자체가 혐오나 공포의 의식적인 표현 없이는 거의 언급되지 않습니다.

The Jargon File 4.4.8.[171]

COBOL 구문은 장황함으로 인해 종종 비판을 받아왔다.지지자들은 이것이 코드를 스스로 문서화하고 프로그램 [172]유지보수를 용이하게 하기 위한 의도였다고 말한다.COBOL은 프로그래머가 배우고 [173]사용하기 쉬우면서도 [174][175][176][177]매니저와 같은 비기술적인 직원이 읽을 수 있도록 고안되었습니다.가독성에 대한 욕구는 명사, 동사, 절, 문장, 섹션, 나눗셈과 같은 영어와 유사한 구문과 구조 요소를 사용하게 했다.그러나 1984년까지 COBOL 프로그램의 유지보수는 "이해할 수 없는[176]" 코드를 다루는데 어려움을 겪었고,[91] COBOL-85의 주요 변경사항은 유지보수를 용이하게 하기 위해 있었다.

단거리 위원회 위원인 Jean Sammet은 "전문 프로그래머의 입맛에 맞추려는 시도는 거의 없었다. 사실 프로그래밍이 주된 관심사인 사람들은 코볼에 매우 불만족스러워하는 경향이 있다"고 지적했는데, 코볼의 장황한 [178]구문 때문이라고 한다.

컴퓨터 사이언스 커뮤니티로부터의 격리

COBOL 커뮤니티는 항상 컴퓨터 과학 커뮤니티로부터 고립되어 왔다.COBOL의 설계에 참여한 학계의 컴퓨터 과학자는 없었다.위원회 위원들은 모두 상업이나 정부에서 왔다.당시 컴퓨터 과학자들은 COBOL 개발이 [179]다루었던 상업적 파일 처리 문제보다 수치 분석, 물리 및 시스템 프로그래밍과 같은 분야에 더 관심이 있었다.Jean Sammet은 COBOL의 비인기적인 이유로 COBOL의 초기 "snob reaction"을 들었다. 이는 COBOL의 미숙함, 설계 과정에 영향력 있는 컴퓨터 과학자들의 참여 부족, 그리고 비즈니스 데이터 [180]처리에 대한 경멸 때문이다.COBOL 규격은 위원회가 몰랐던 새로운 배커스-나우르 형식이 아닌 독특한 표기, 즉 메타 언어를 사용하여 구문을 정의하였다.이는 "엄격한"[181][182][69] 비판을 초래했다.

이후 COBOL은 이를 다루는 자료 부족으로 어려움을 겪었고, 1963년까지 (리처드 D와 함께) 입문서가 출판되었다.1966년 [183]COBOL에 관한 대학 교과서를 출판한 어윈.1985년까지 [123]의회 도서관에는 FORTRAN에 관한 책이 2배, BASIC에 관한 책이 4배 더 많았다.대학교수들은 "무역학교"[184]의 성격을 가진 코볼 대신 더 현대적이고 최신의 언어와 기술을 가르쳤다.1984년 CODASYL COBOL 위원회 의장 도널드 넬슨은 "학문은..."코볼을 증오한다"와 컴퓨터 공학과 졸업생들은 "코볼을 증오한다"[185]고 말했다.

1980년대 중반까지, COBOL은 다른 언어 사용자(예: FORTRAN 또는 어셈블리러)로부터 비즈니스 커뮤니티에서 COBOL에 대한 상당한 겸손함이 있었으며, 이는 COBOL이 비도전적인 [186]문제에만 사용될 수 있음을 암시한다.

2003년, COBOL은 미국의 정보 시스템 커리큘럼의 80%를 차지했는데, 이는 C++ [187]및 Java와 같은 비율입니다.10년 후 Micro Focus가 실시한 여론조사에 따르면 대학 학계의 20%가 COBOL이 시대에 뒤떨어지거나 죽었다고 생각했으며, 55%는 학생들이 COBOL이 시대에 뒤떨어지거나 죽었다고 생각한다고 응답했다.또한 같은 여론조사에서 60%가 코볼을 가르쳐야 한다고 생각했음에도 불구하고 [188]코볼 프로그래밍을 교과 과정에 두고 있는 학자는 25%에 불과한 것으로 나타났습니다.

설계 프로세스에 대한 우려

표준 위원회의 능력에 대한 의구심이 제기되어 왔다.단기 위원 하워드 브롬 베르크. Bydgoszcz의 독일명.는" 작은 통제"이 개발 과정을 생각하고 이 인사의 불연속성 그리고...재능의 부족에 시달리고 있다고 말했다."[79]장 사멧과 제롬 가펑클은 또한 변화가 표준의 한 개정에서 도입한 다음, 최대한의 변화에 되돌아올 거라고 언급했다.그는 [189]객관적 증거에 관해 표준 위원회에 있었다.

COBOL-85는 [190]기대보다 5년 늦게,[2] COBOL 2002는 5년 늦게, COBOL 2014는 6년 [99][191]늦게 도착하는 등 COBOL 규격은 여러 차례 지연에 시달렸다.지연에 대처하기 위해 표준 위원회는 다음 표준 개정을 기다리는 것보다 더 빨리 기능을 추가할 수 있는 선택적 부록을 만들 수 있도록 허용했습니다.그러나 일부 위원들은 시행 간의 [192]비호환성과 이 기준서의 빈번한 수정에 대한 우려를 제기하였다.

다른 언어에 대한 영향

COBOL의 데이터 구조는 후속 프로그래밍 언어에 영향을 미쳤다.그 기록과 파일 구조는 PL/I와 Pascal에 영향을 미쳤고,REDEFINES조항은 파스칼의 변종 기록의 전신이었다.데이터베이스 관리 시스템 개발에 앞서 명확한 파일 구조 정의가 이루어졌으며 집계된 데이터는 Fortran의 [123]어레이에 비해 크게 발전했습니다. PICTURE데이터 선언이 PL/I에 포함되었으며 약간의 변경이 있었다.

코볼COPY설비는 "비록"[193]으로 간주되지만 포함 [123]지침의 개발에 영향을 미쳤다.

휴대성과 표준화에 중점을 두었기 때문에 COBOL로 작성된 프로그램은 휴대할 수 있었고 다양한 하드웨어 플랫폼과 [194]운영체제로 언어를 확산시킬 수 있었습니다.또, 명확하게 정의된 부문 구조는 환경 부문에 대한 외부 참조의 정의를 제한하고, [195]특히 플랫폼 변경을 단순화합니다.

「 」를 참조해 주세요.

메모들

  1. ^ 특히 COBOL 2002의 객체 [2][3][4]지향 기능에 영향을 미쳤습니다.
  2. ^ 그 묘비는 현재 컴퓨터 [63]역사 박물관에 있다.
  3. ^ a b 독자는 1997년 가트너 그룹의 연구가 유명한 "2000억 줄의 코볼" 인용문과 함께 널리 언급되고 있지만 실제 보고서는 [196]찾기 어렵다는 점에 유의해야 한다.게다가[197] 「이 숫자에 가트너가 관여하고 있는 것은, Y2K 버그를 수정하는 데 회선당 1달러, 합계 3000억달러의 비용이 드는 것을 예측한 1995년의[198] 조사뿐」이라고 하는 추측도 있어, 리포트의 오해의 원인이 되고 있습니다.
  4. ^ 벤더 고유의 확장에 의해, 많은 실장에서는 1,100개 이상의 [120]키워드가 인식됩니다.

레퍼런스

인용문

  1. ^ a b Sammet, Jean E. (March 2000). "The real creators of Cobol". IEEE Software. 17 (2): 30–32. doi:10.1109/52.841602. ISSN 1937-4194. The Short-Range Committee worked diligently from June 1959 on, but there were great difficulties in having a fairly large committee try to create a programming language. In November, the Short-Range Committee chair appointed six people to develop specifications for consideration: William Selden and Gertrude Tierney (IBM), Howard Bromberg and Norman Discount (RCA), and Vernon Reeves and Jean E. Sammet (Sylvania Electric Products). We worked for two full weeks (including some round-the-clock sessions) in November 1959 and sent the proposed specifications to the full Short-Range Committee, which accepted almost all of them. After some editing (by the same six people), we turned in the specifications as a final report in December to the Executive Committee, which accepted them in January 1960. After some further editing, the Government Printing Office issued Cobol 60. [...] [Grace Hopper] did not participate in its work except through the general guidance she gave to her staff who were direct committee members. Thus, while her indirect influence was very important, regrettably the frequent repeated statements that "Grace Hopper developed Cobol" or "Grace Hopper was a codeveloper of Cobol" or "Grace Hopper is the mother of Cobol" are just not correct.
  2. ^ a b c Saade, Henry; Wallace, Ann (October 1995). "COBOL '97: A Status Report". Dr. Dobb's Journal. Archived from the original on 22 April 2014. Retrieved 21 April 2014.
  3. ^ a b Arranga, Edmund C.; Coyle, Frank P. (February 1998). Object-Oriented COBOL. Cambridge University Press. p. 15. ISBN 978-0132611404. Object-Oriented COBOL's style reflects the influence of Smalltalk and C++.
  4. ^ Arranga, Edmund C.; Coyle, Frank P. (March 1997). "Cobol: Perception and Reality". Computer. 30 (3): 127. doi:10.1109/2.573683. ISSN 0018-9162.
  5. ^ Imajo, Tetsuji; et al. (September 2000). COBOL Script: a business-oriented scripting language. Enterprise Distributed Object Computing Conference. Makuhari, Japan: IEEE. doi:10.1109/EDOC.2000.882363. ISBN 0769508650.
  6. ^ Ho, Wing Hong (7 May 2007). "Introduction to EGL" (PDF). IBM Software Group.
  7. ^ Radin, George (1978). Wexelblat, Richard L. (ed.). The early history and characteristics of PL/I. History of Programming Languages. Academic Press (published 1981). p. 572. doi:10.1145/800025.1198410. ISBN 0127450408.
  8. ^ "What is PL/B - The Programming Language for Business?". sysmaker.com. Infopro, Inc. Retrieved 22 April 2022. ... conversion to an alternate, extended COBOL or to ANSI COBOL is very difficult, if at all possible
  9. ^ Mitchell, Robert L. (14 March 2012). "Brain drain: Where Cobol systems go from here". Computerworld. Retrieved 9 February 2015.
  10. ^ a b c Mitchell, Robert L. (4 October 2006). "Cobol: Not Dead Yet". Computerworld. Retrieved 27 April 2014.
  11. ^ Ensmenger, Nathan L. (2009). The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. MIT Press. p. 100. ISBN 978-0262050937. LCCN 2009052638.
  12. ^ "ISO/IEC 1989:2014". ISO. 26 May 2014. Retrieved 7 June 2014.
  13. ^ Ferguson, Andrew. "A History of Computer Programming Languages". cs.brown.edu.
  14. ^ "COmmon Business Oriented Language".
  15. ^ Groenfeldt, Tom. Forbes https://www.forbes.com/sites/tomgroenfeldt/2022/05/18/covid-accelerates-banks-mainframe-migration-to-cloud/. {{cite magazine}}:누락 또는 비어 있음 title=(도움말)
  16. ^ Beyer 2009, 페이지 282
  17. ^ Gürer, Denise (1 June 2002). "Pioneering Women in Computer Science". SIGCSE Bull. 34 (2): 175–180. doi:10.1145/543812.543853. ISSN 0097-8418. S2CID 2577644.
  18. ^ Beyer 2009, 페이지 281~282.
  19. ^ Sammet 1978a, 페이지 200
  20. ^ Flahive, Paul (24 May 2019). "How COBOL Still Powers The Global Economy At 60 Years Old". Texas Public Radio. Archived from the original on 24 May 2019. Retrieved 19 July 2019. (Grace Hopper) Nicknamed Grandma Cobol, the code was based on some of her earlier work. She said — after hearing the rumors — one of her collaborators went out and bought a granite tombstone. "He had the word COBOL cut in the front of it. Then he shipped it express collect to Mr. Phillips in the pentagon." The prank on Charles Phillips, a leader for the project at the defense department, got the attention of the powers that be and was a turning point she said. COBOL would go on to become the most widely used and longest lasting computer languages in history.
  21. ^ Beyer 2009, 페이지 283
  22. ^ Beyer 2009, 페이지 284
  23. ^ "Early Meetings of the Conference on Data Systems Languages". IEEE Annals of the History of Computing. 7 (4): 316–325. 1985. doi:10.1109/MAHC.1985.10047. S2CID 35625728.
  24. ^ a b c d e Sammet 2004, 페이지 104
  25. ^ Beyer 2009, 페이지 286
  26. ^ a b 코너 1984, 페이지 ID/9
  27. ^ Sammet 1978a, 페이지 201
  28. ^ a b c d 베머 1971, 페이지 132
  29. ^ Beyer 2009, 페이지 288
  30. ^ Sammet 1978a, 페이지 203
  31. ^ CODASYL 1969, § I.2.1.1.
  32. ^ 샘트 1978a, 페이지 204
  33. ^ CODASYL 1969, § I.1.2.
  34. ^ Beyer 2009, 페이지 290
  35. ^ Sammet, Jean (1978). "The Early History of COBOL". ACM SIGPLAN Notices. 13 (8): 121–161. doi:10.1145/960118.808378. S2CID 10743643.
  36. ^ 샘트 1978a, 페이지 217
  37. ^ Adams, Vicki Porter (5 October 1981). "Captain Grace M. Hopper: the Mother of COBOL". InfoWorld. Vol. 3, no. 20. p. 33. ISSN 0199-6649.
  38. ^ Betts, Mitch (6 January 1992). "Grace Hopper, mother of Cobol, dies". Computerworld. 26 (1): 14.
  39. ^ Lohr, Steve (2008). Go To: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Maverick Scientists, and Iconoclasts—The Programmers Who Created the Software Revolution. Basic Books. p. 52. ISBN 978-0786730766.
  40. ^ "Pioneering software engineer and Cobol co-designer".
  41. ^ a b Beyer 2009, 페이지 292
  42. ^ 1971년 베머, 131페이지
  43. ^ Beyer 2009, 페이지 296
  44. ^ Sammet 1978a, 221페이지
  45. ^ Beyer 2009, 페이지 291
  46. ^ "Oral History of Captain Grace Hopper" (PDF). Computer History Museum. December 1980. p. 37. Archived from the original (PDF) on 25 December 2017. Retrieved 28 June 2014.
  47. ^ Sammet 1978a, 페이지 218
  48. ^ 마르코티 1978a, 페이지 268
  49. ^ Sammet 1978a, 페이지 205–206.
  50. ^ a b Sammet 1978a, 그림 8.
  51. ^ Sammet 1978a, 페이지 230–231.
  52. ^ ISO/IEC JTC 1/SC 22/WG 4 2001, 페이지 846.
  53. ^ Sammet 1978a, 페이지 220
  54. ^ Sammet 1978a, 228페이지
  55. ^ Sammet 1978a, 페이지 210
  56. ^ Bemer 1971, 132페이지: 우리는 "COBOL"이라는 약자를 만든 것을 인정하는 사람을 찾을 수 없다.
  57. ^ Sammet 1978a, 페이지 210: 다음날, COBOL이라는 이름이 마침내 COMMon Business Oriented Language의 약자로 동의되었습니다. 유감스럽게도, 제 노트에는 누가 그런 제안을 했는지 나와 있지 않습니다.
  58. ^ Sullivan, Patricia (25 June 2004). "Computer Pioneer Bob Bemer, 84". The Washington Post. p. B06. Retrieved 28 June 2014.
  59. ^ "THE COBOL REPORT - Interview with Bob Bemer - the Father of COBOL". Archived from the original on 2 April 2018.
  60. ^ "THE COBOL REPORT - Interview with Bob Bemer - the Father of COBOL". Archived from the original on 23 December 2003.
  61. ^ Beyer 2009, 페이지 293
  62. ^ Beyer 2009, 페이지 294
  63. ^ COBOL Tombstone. Computer History Museum. 1960. Retrieved 29 June 2014.
  64. ^ "The Story of the COBOL Tombstone" (PDF). The Computer Museum Report. 13: 8–9. Summer 1985. Archived (PDF) from the original on 3 April 2014. Retrieved 29 June 2014.
  65. ^ 1971년 베머, 130쪽
  66. ^ Beyer 2009, 페이지 289
  67. ^ CODASYL 1969, § I.1.1.
  68. ^ 1976년 브라운, 페이지 47
  69. ^ a b c 베머 1971, 페이지 133
  70. ^ a b Beyer 2009, 페이지 297
  71. ^ Williams, Kathleen Broome (10 November 2012). Grace Hopper: Admiral of the Cyber Sea. US Naval Institute Press. ISBN 978-1612512655. OCLC 818867202.
  72. ^ Compaq Computer Corporation:Compaq COBOL 참조 설명서, 주문 번호:AA – Q2G0F – TK 2000년 10월, 페이지 xvii;후지쯔 주식회사:Net Cobol Language Reference, 버전 15, 2009년 1월, IBM Corporation:엔터프라이즈 COBOL for z/OS Language Reference, 버전 4 릴리즈 1, SC23-8528-00, 2007년 12월
  73. ^ Garfunkel, Jerome (11 November 1984). "In defense of Cobol". Computerworld. 18 (24): ID/19.
  74. ^ a b 베머 1971, 페이지 134
  75. ^ 1976년 브라운, 페이지 48
  76. ^ CODASYL 1969, § I.2.2.4.
  77. ^ CODASYL 1969, § I.2.3.
  78. ^ a b c d Follet, Robert H.; Sammet, Jean E. (2003). "Programming language standards". In Ralston, Anthony; Reilly, Edwin D.; Hemmendinger, David (eds.). Encyclopedia of Computer Science (4th ed.). Wiley. p. 1467. ISBN 978-0470864128.
  79. ^ a b Beyer 2009, 페이지 301
  80. ^ a b 1976년 브라운, 페이지 49
  81. ^ 1976년 브라운, 52페이지
  82. ^ Taylor, Alan (2 August 1972). "Few Realise Wasted Resources of Local DP Schools". Computerworld. 6 (31): 11.
  83. ^ Triance, J. M. (1974). Programming in COBOL: A Course of Twelve Television Lectures. Manchester University Press. p. 87. ISBN 978-0719005923.
  84. ^ 클라인 2010, 페이지 16
  85. ^ Baird, George N.; Oliver, Paul (May 1977). "1974 Standard (X3.23–1974)". Programming Language Standards—Who Needs Them? (PDF) (Report). Department of the Navy. pp. 19–21. Archived (PDF) from the original on 7 January 2014. Retrieved 7 January 2014.
  86. ^ Culleton, John R., Jr. (23 July 1975). "'Spotty' Availability A Problem..." Computerworld. 9 (30): 17.
  87. ^ Simmons, Williams B. (18 June 1975). "Does Cobol's Report Writer Really Miss the Mark?". Computerworld. 9 (25): 20.
  88. ^ Shoor, Rita (26 January 1981). "User Threatens Suit Over Ansi Cobol-80". Computerworld. 15 (4): 1, 8.
  89. ^ Shoor, Rita (26 October 1981). "DPMA Takes Stand Against Cobol Draft". Computerworld. 15 (43): 1–2.
  90. ^ a b c Gallant, John (16 September 1985). "Revised Cobol standard may be ready in late '85". Computerworld. 19 (37): 1, 8.
  91. ^ a b "Expert addresses Cobol 85 standard". Computerworld. 19 (37): 41, 48. 16 September 1985.
  92. ^ Paul, Lois (15 March 1982). "Responses to Cobol-80 Overwhelmingly Negative". Computerworld. 16 (11): 1, 5.
  93. ^ Paul, Lois (25 April 1983). "Study Sees Few Problems Switching to Cobol-8X". Computerworld. 17 (17): 1, 6.
  94. ^ Gillin, Paul (19 November 1984). "DEC users get head start implementing Cobol-80". Computerworld. 18 (47): 1, 6.
  95. ^ ClearPath Enterprise Servers (April 2015). "COBOL ANSI-85 Programming Reference Manual" (PDF). public.support.unisys.com. Unisys. Retrieved 29 April 2022.
  96. ^ 가펑클 1987, 150페이지
  97. ^ Roy, M. K.; Dastidar, D. Ghost (1 June 1989). "Features of COBOL-85". COBOL Programming: Problems and Solutions (2nd ed.). McGraw-Hill Education. pp. 438–451. ISBN 978-0074603185.
  98. ^ Robinson, Brian (9 July 2009). "Cobol remains old standby at agencies despite showing its age". FCW. Public Sector Media Group. Retrieved 26 April 2014.
  99. ^ a b "COBOL Standards". Micro Focus. Archived from the original on 31 March 2004. Retrieved 2 September 2014.
  100. ^ "NetCOBOL for .Net". netcobol.com. GTSoftware. 2013. Archived from the original on 8 July 2014. Retrieved 29 January 2014.
  101. ^ "A list of Codasyl Cobol features". Computerworld. 18 (37): ID/28. 10 September 1984. Retrieved 8 June 2014.
  102. ^ ISO/IEC JTC 1/SC 22/WG 4 2001, 부록 F.
  103. ^ 클라인 2010, 페이지 21
  104. ^ a b "JTC1/SC22/WG4 – COBOL". ISO. 30 June 2010. Archived from the original on 14 February 2014. Retrieved 27 April 2014.
  105. ^ Billman, John; Klink, Huib (27 February 2008). "Thoughts on the Future of COBOL Standardization" (PDF). Archived from the original (PDF) on 11 July 2009. Retrieved 14 August 2014.
  106. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, 부록 E.
  107. ^ Schricker, Don (2 December 1998). "J4: COBOL Standardization". Micro Focus. Archived from the original on 24 February 1999. Retrieved 12 July 2014.
  108. ^ Kizior, Ronald J.; Carr, Donald; Halpern, Paul. "Does COBOL Have a Future?" (PDF). The Proceedings of the Information Systems Education Conference 2000. 17 (126). Archived from the original (PDF) on 17 August 2016. Retrieved 30 September 2012.
  109. ^ White, Doug (12 July 1998). "Frequently Asked Questions (FAQ) About the Y2K Problem". homepages.wmich.edu. Retrieved 29 April 2022. Thus, the main problem of Y2K is the problem of incorrect results when date mathematics are conducted.
  110. ^ Kappelman, Leon A. (2000). "Some strategic Y2K blessings". IEEE Software. 17 (2): 42–46. doi:10.1109/52.841605.
  111. ^ Car & Kizior 2003, 페이지 16
  112. ^ Car & Kizior 2003, 페이지 10
  113. ^ "Cobol brain drain: Survey results". Computerworld. 14 March 2012. Retrieved 27 April 2014.
  114. ^ Powner, David A. (25 May 2016). "Federal Agencies Need to Address Aging Legacy Systems" (PDF). Government Accountability Office. p. 18. Archived from the original (PDF) on 15 June 2016. Retrieved 19 July 2019. Several agencies, such as the Department of Agriculture (USDA), DHS, HHS, Justice, Treasury, and VA, reported using Common Business Oriented Language (COBOL)—a programming language developed in the late 1950s and early 1960s—to program their legacy systems. It is widely known that agencies need to move to more modern, maintainable languages, as appropriate and feasible.
  115. ^ "COBOL blues". Reuters. Retrieved 8 April 2020.
  116. ^ Teplitzky, Phil (25 October 2019). "Closing the COBOL Programming Skills Gap". IBM Systems Magazine, IBM Z. Retrieved 11 June 2020.
  117. ^ Lee, Alicia (8 April 2020). "Wanted urgently: People who know a half century-old computer language so states can process unemployment claims". CNN. Retrieved 8 April 2020.
  118. ^ Long, Heather; Stein, Jeff; Rein, Lisa; Romm, Tony (17 April 2020). "Stimulus checks and other coronavirus relief hindered by dated technology and rocky government rollout". The Washington Post. Retrieved 19 April 2020.
  119. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.9.
  120. ^ "Reserved Words Table". Micro Focus Visual COBOL 2.2 COBOL Language Reference. Micro Focus. Retrieved 3 March 2014.
  121. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.3.1.2.
  122. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.3.2.
  123. ^ a b c d Shneiderman 1985, 349페이지
  124. ^ a b ISO/IEC JTC 1/SC 22/WG 4 2001, © F.2.
  125. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, © D.18.2.
  126. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, © D.18.
  127. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, 페이지 108.
  128. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, 페이지 896.
  129. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, © D.2.1.
  130. ^ "File Organizations". File Handling. Micro Focus. 1998. Archived from the original on 4 March 2016. Retrieved 27 June 2014.
  131. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.5.1.2.
  132. ^ 커틀러 2014, 부록 A.
  133. ^ Hubbell, Thane (1999). Sams Teach Yourself COBOL in 24 hours. SAMS Publishing. p. 40. ISBN 978-0672314537. LCCN 98087215.
  134. ^ 맥크래큰 & 골든 1988, § 19.9.
  135. ^ 커틀러 2014, § 5.8.5.
  136. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.5.2.
  137. ^ a b ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.24.
  138. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.35.
  139. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 13.18.40.
  140. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 13.18.60.3.
  141. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, 페이지 855.
  142. ^ a b 1976년 맥크라켄, 338페이지
  143. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.4.
  144. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.6.3.
  145. ^ Field, John; Ramalingam, G. (September 1999). Identifying Procedural Structure in Cobol Programs (PDF). PASTE '99. doi:10.1145/381788.316163. ISBN 1581131372.
  146. ^ a b c Veerman, Niels; Verhoeven, Ernst-Jan (November 2006). "Cobol minefield detection" (PDF). Software: Practice and Experience. 36 (14). doi:10.1002/spe.v36:14. Archived from the original (PDF) on 6 March 2007.
  147. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.
  148. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, © 14.9.4, 14.9.22.
  149. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.6.5.2.2.
  150. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.13.1.
  151. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, 제14.9.35.1조.
  152. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, 페이지 899.
  153. ^ a b 맥크래큰 & 골든 1988, § 8.4.
  154. ^ 에 대한 컴파일러 지원 예시ALTER는, 다음과 같이 표시됩니다.
    • Tiffin, Brian (18 September 2013). "September 2013". GNU Cobol. Archived from the original on 5 May 2014. Retrieved 5 January 2014.
    • "The ALTER Statement". Micro Focus Visual COBOL 2.2 for Visual Studio 2013 COBOL Language Reference. Micro Focus. Retrieved 5 January 2014.
    • "ALTER Statement (Nucleus)" (PDF). COBOL85 Reference Manual. Fujitsu. November 1996. p. 555. Archived from the original (PDF) on 6 January 2014. Retrieved 5 January 2014.
    • "ALTER Statement". Enterprise COBOL for z/OS Language Reference. IBM. June 2013. Retrieved 5 January 2014.
  155. ^ ISO/IEC JTC 1/SC 22/WG 4 2001, © F.1.
  156. ^ a b 맥크라켄 1976, 페이지 355
  157. ^ Moseley, Jay (17 January 2015). "COBOL Compiler from MVT". Retrieved 19 July 2015.
  158. ^ Dijkstra, Edsger W. (18 June 1975). "How do we tell truths that might hurt?". University of Texas at Austin. EWD498. Archived from the original on 2 May 2017. Retrieved 29 August 2007.
  159. ^ Tompkins, H. E. (1983). "In defense of teaching structured COBOL as computer science". ACM SIGPLAN Notices. 18 (4): 86–94. doi:10.1145/948176.948186. S2CID 33803213.
  160. ^ a b Riehle 1992, 125페이지
  161. ^ Shneiderman 1985, 349~350페이지.
  162. ^ Coughlan, Michael (16 March 2014). Beginning COBOL for Programmers. Apress. p. 4. ISBN 978-1430262534. Retrieved 13 August 2014.
  163. ^ Sammet 1978b, 페이지 258
  164. ^ Riehle 1992, 페이지 126
  165. ^ Riehle 1992, 127페이지
  166. ^ "COBOL and Legacy Code as a Systemic Risk naked capitalism". 19 July 2016. Retrieved 23 July 2016.
  167. ^ Lämmel, Ralf; Verhoef, Chris (November–December 2001). "Cracking the 500-language problem" (PDF). IEEE Software. 18 (6): 79. doi:10.1109/52.965809. hdl:1871/9853. Archived from the original (PDF) on 19 August 2014.
  168. ^ Howkins, T. J.; Harandi, M. T. (April 1979). "Towards more portable COBOL". The Computer Journal. 22 (4): 290. doi:10.1093/comjnl/22.4.290.
  169. ^ 가펑클 1987, 페이지 11
  170. ^ 가펑클 1987, 페이지 15
  171. ^ Raymond, Eric S. (1 October 2004). "COBOL". The Jargon File, version 4.4.8. Archived from the original on 30 August 2014. Retrieved 13 December 2014.
  172. ^ 1976년 브라운, 53페이지
  173. ^ CODASYL 1969, § II.1.1.
  174. ^ Shneiderman 1985, 350페이지
  175. ^ 샘트 1961, 페이지 381
  176. ^ a b 코너 1984, 페이지 ID/10
  177. ^ 마르코티 1978a, 페이지 263
  178. ^ 코너 1984, 페이지 ID/14
  179. ^ 샘트 1961, 페이지 380
  180. ^ 마르코티 1978a, 페이지 266
  181. ^ Sammet 1978b, 페이지 255
  182. ^ Shneiderman 1985, 348-349페이지.
  183. ^ "COBOL Logic and Programming, third edition 1974". Archived from the original on 5 March 2016. Retrieved 25 February 2016.
  184. ^ Shneiderman 1985, 페이지 351
  185. ^ "An interview: Cobol defender". Computerworld. 18 (37): ID/29–ID/32. 10 September 1984. Retrieved 8 June 2014.
  186. ^ Pratt, Terrence W.; Zelkowitz, Marvin V. (1984). Programming Languages: Design and Implementation (2nd ed.). Englewood Cliffs, N.J. : Prentice Hall. ISBN 0136780121.
  187. ^ Car & Kizior 2003, 13페이지
  188. ^ "Academia needs more support to tackle the IT skills gap" (Press release). Micro Focus. 7 March 2013. Retrieved 4 August 2014.
  189. ^ Sammet, Jean; Garfunkel, Jerome (October 1985). "Summary of Changes in COBOL, 1960–1985". Annals of the History of Computing. 7 (4): 342. doi:10.1109/MAHC.1985.10033. S2CID 17940092.
  190. ^ Cook, Margaret M. (June 1978). Ghosh, Sakti P.; Liu, Leonard Y. (eds.). Data Base Facility for COBOL 80 (PDF). 1978 National Computer Conference. Anaheim, California: AFIPS Press. pp. 1107–1112. doi:10.1109/AFIPS.1978.63. LCCN 55-44701. Retrieved 2 September 2014. The earliest date that a new COBOL standard could be developed and approved is the year 1980 [...].
  191. ^ "Resolutions from WG4 meeting 24 – June 26–28, 2003 Las Vegas, Nevada, USA". 11 July 2003. p. 1. Archived from the original (doc) on 8 March 2016. Retrieved 29 June 2014. a June 2008 revision of the COBOL standard
  192. ^ Babcock, Charles (14 July 1986). "Cobol standard add-ons flayed". Computerworld. 20 (28): 1, 12.
  193. ^ 마코티 1978b, 페이지 274
  194. ^ 이는 다음에서 확인할 수 있습니다.
  195. ^ Coughlan, Michael (2002). "Introduction to COBOL". Retrieved 3 February 2014.
  196. ^ "Gartner Group Studies". 1997-2001.state.gov. Year 2000 Program Management Office. 2000. Retrieved 23 April 2022.
  197. ^ Engelmann, Viktor (8 April 2021). "COBOL Fact-Check". cobsolete.de. COBSOLETE. Retrieved 23 April 2022.
  198. ^ "What Will the Future Hold". CIO. International Data Group. 15 December 1995 – 1 January 1996. p. 82.

원천

External links