Content-Length: 680575 | pFad | https://ko.wikipedia.org/wiki/%EC%BD%94%EB%B3%BC

코볼 - 위키백과, 우리 모두의 백과사전 본문으로 이동

코볼

위키백과, 우리 모두의 백과사전.

코볼(Kobol)에 대해서는 배틀스타 갈락티카 문서를 참고하십시오.
코볼
COBOL
CODASYL에 대한 코볼 60 보고서의 책 표지 (1960년 4월)
패러다임절차적, 명령형, 객체 지향
설계자하워드 브롬버그, 하워드 디스카운트, 버넌 리브스, 진 E. 사멧, 윌리엄 셀든, 거트루드 티어니
개발자CODASYL, ANSI, ISO
발표일1959년(65년 전)(1959)
최근 버전ISO/IEC 1989:2014
최근 버전 출시일2014년
자료형 체계약한 타이핑/강한 타이핑
파일 확장자.cbl, .cob, .cpy
주요 구현체
GnuCOBOL, IBM COBOL, 마이크로 포커스 비주얼 코볼
ACUCOBOL-GT, COBOL-IT, COBOL/2, DEC COBOL-10, DEC VAX COBOL, DOSVS COBOL, Fujitsu COBOL, Hitachi COBOL2002, HP3000 COBOL/II, IBM COBOL SAA, IBM COBOL/400, IBM COBOL/II, IBM Enterprise COBOL, IBM ILE COBOL, IBM OS/VS COBOL, ICL COBOL, isCOBOL, Micro Focus COBOL, Microsoft COBOL, Realia COBOL, Ryan McFarland RM/COBOL, Ryan McFarland RM/COBOL-85, Tandem (NonStop) COBOL85, Tandem (NonStop) SCOBOL, UNIVAC COBOL, Unisys MCP COBOL74, Unisys MCP COBOL85, Unix COBOL X/Open, Visual COBOL, Wang VS COBOL
영향을 받은 언어
AIMACO, C++,[a] COMTRAN, FACT, FLOW-MATIC, 스몰토크[a]
영향을 준 언어
코볼스크립트,[3] PL/I[4]

코볼(COBOL, COmmon Business-Oriented Language, 사무 지향 보통 언어)은 사무용으로 설계된, 영어와 같은 컴퓨터 프로그래밍 언어이다. 절차적, 명령형 언어이고, 2002년부터는 객체 지향 언어이다.[5]

코볼은 주로 비즈니스, 금융, 회사/정부 관리 시스템에 주로 사용된다. 1997년 가트너 그룹은 총 200,000,000,000줄의 코볼이 현존하며 모든 비즈니스 프로그램의 80%를 실행한 것으로 예측하였다.[6]

코볼은 지금도 메인프레임 컴퓨터의 레거시 응용 프로그램들에 사용되고 있으며 대용량 일괄 처리 및 트랜잭션 처리와 같은 작업에 쓰인다. 그러나 숙련된 코볼 프로그래머가 은퇴하고 인기가 시들어가면서 프로그램들은 새로운 플랫폼으로 이관돼 현대의 언어로 다시 작성되거나 소프트웨어 패키지로 대체되는 추세이다.[7] 코볼 대부분의 프로그래밍은 순수하게 기존의 응용 프로그램들을 관리하는 데 있다.[8]

코볼은 1959년에 CODASYL이 설계하였으며 부분적으로는, 코볼의 어머니로 불리는 그레이스 호퍼의 이전 프로그래밍 언어 디자인을 기반으로 한다.[9][10][11] 데이터 처리를 위해 이식 가능한 프로그래밍 언어를 만들려는 미국 국방부 노고의 일부이기도 하다. 임시방편으로 의도했던 미국 국방부가 발빠르게 컴퓨터 제조업체에게 그것을 제공하도록 강제한 결과 널리 채택되었다.[12] 1968년 표준화되어 그 뒤로 4차례 개정되었다. 확장에는 구조적, 객체 지향 프로그래밍의 지원을 포함한다. 현재 표준은 ISO/IEC 1989:2014이다.[13]

코볼은 영어와 비슷한 문법을 갖고 있으며, 자체 문서화 및 높은 가독성을 염두에 두고 설계되었다. 그러나 문법이 장황하고 300개가 넘는 예약어를 사용한다. y = x;처럼 현대의 간결한 문법과 달리, 코볼은 더욱 영어와 같은 문법을 갖고 있다. (이 경우 MOVE x TO y). 코볼 코드는 4개의 디비전(IDENTIFICATION, ENVIRONMENT, DATA, PROCEDURE)으로 나뉘며 이 안에 엄격한 계층적 섹션, 문단, 문장들을 포함한다. 대형 표준 라이브러리가 부족하며 이 표준은 43개의 문들과 87개의 함수, 그리고 하나의 클래스만을 규정한다.

학계의 컴퓨터 과학자들은 코볼이 만들어졌을 때 일반적으로 사무용 응용 프로그램들에 관심이 없었으며 설계에도 참여하지 않았다. 코볼은 문법의 장황함, 설계 과정, 구조화 프로그래밍 지원 부족으로 비판을 받아왔으며 이음매가 없고 이해하기 어려운 프로그램들을 만들어냈다.

코볼보다 먼저 개발된 포트란(FORTRAN)은 주로 과학기술 계산용인 반면 비슷한 시기에 탄생된 코볼은 대량 데이터 처리를 위한 업무처리 및 관리 분야용으로 자리잡게 된다. 코볼과 포트란은 프로그램밍 언어 역사에서 고급 기술언어의 원점이 되고 있다.

역사 및 사양

[편집]

배경

[편집]

1950년대 말 컴퓨터 사용자와 제조업체는 프로그래밍의 비용이 치솟는 것을 걱정하기 시작했다. 1959년 조사에 따르면 데이터 처리 설치에서 프로그래밍의 평균 비용은 $800,000 (미국 달러)이고 새로운 하드웨어에서 실행할 수 있도록 프로그램을 변환하는데 드는 비용은 $600,000였다. 새로운 프로그래밍 언어들이 빠르게 확산되는 가운데, 동일 조사에서 하나로 통일된 사무 지향 언어가 사용된다면 변환은 훨씬 저렴해지고 빨라질 것이라는 결과가 나왔다.[14]

caption
그레이스 호퍼. COBOL의 선구자격인 FLOW-MATIC의 발명가.

1959년 4월 학계, 컴퓨터 사용자들, 제조업체들의 대표들이 펜실베니아 대학교에서 통일된 사무 언어에 대한 정식 회의를 조성하기에 이르렀다.

영어와 같은 데이터 처리 언어 FLOW-MATIC을 개발한 그레이스 호퍼를 포함하여 진 사멧, 솔 곤(Saul Gorn)이 대표로 참석했다.[15][16]

이 단체는 미국 국방부에 통일된 사무 언어를 만들기 위해 지원해줄 것을 요청하였다. 대표단은 미국 국방부의 데이터 시스템 연구 스태프 총괄을 맡던 찰스 A. 필립스에게 감명을 주었는데, 그는 이들이 미국 국방부의 문제들을 꼼꼼하게 이해하였다고 생각하였다. 미국 국방부는 225대의 컴퓨터를 운영했고 추가로 175대를 주문하였으며 이 컴퓨터들 상에 프로그램을 구현하는데 $200,000,000를 지출하였다. 이식 가능한 프로그램들은 시간을 절약하고, 비용을 줄이며 현대화를 쉽게 할 수 있었다.[17]

필립스는 이 회의를 지원하는데 동의하였고 대표단에게 의제의 초안을 작성하는 일을 부여하였다.[18]

코볼 60

[편집]

취리히 알골 58 회의가 있은지 정확히 한 해 뒤인 1959년 5월 28, 29일에 펜타곤에서 회의가 열렸고 사무를 위한 공용 프로그래밍 언어를 만드는 것을 논의하였다. 41명의 사람들이 참석하였고 당시 의장은 필립스였다.[19] 미국 국방부는 각기 다른 컴퓨터에서 동일한 데이터 처리 프로그램들을 실행할 수 있는지에 대해 걱정하였다. 당시 유일한 주류 언어였던 포트란은 이러한 프로그램들 작성에 필요한 기능들이 부족했다.[20]

대표들은 은행업, 보험 분야에서 공과금, 재고 관리에 이르기까지 다양한 환경에서 동작할 수 있는 언어를 열정적으로 기술하였다. 더 많은 사람들이 프로그래밍할 수 있어야 하고 새로운 언어는 동시대 기술의 제약을 받아서는 안 된다는 데 대하여 대표자 전원이 동의하였다. 언어는 최대한 영어를 사용하여야 하고 변경이 가능해야 하며 기계와는 독립적이어야 하고 사용하기 쉬워야 한다는 데 대하여 다수가 동의하였다.[21]

이 모임을 통해 운영 위원회와 중장기 위원회들이 설립되었다. 단기 위원회는 9월부터 3개월 동안 중간 언어를 위한 사양을 만들어냈으며 그 뒤 다른 위원회들에 의해 개선되었다.[22][23] 그러나 공식 임무는 기존 프로그래밍 언어들의 장단점을 식별하는 것이었고 명백하게 이들에게 새로운 언어를 만들라고 지시하는 것은 아니었다.[20]

기한은 단기 위원회에 의해 불신 속에 마감되었다.[24] 베티 홀버튼(Betty Holberton)이라는 한 구성원은 3개월 기한을 둔 것이 역겨울 만큼 낙천주의적이라고 기술했으며 이 언어가 임시방편이 될지에 대해서는 의심을 품었다.[25]

운영 위원회는 6월 4일 만나 협의회를 CODASYL(Committee on Data Systems Languages)라는 이름으로 정하고, 집행 위원회를 설립할 것을 동의하였다.[26]

단기 위원회는 여섯 곳의 컴퓨터 제조업체와 세 군데의 정부 기관으로 이루어져 있었다. 여섯 곳의 제조업체들은 버로스(Burroughs), IBM, 미니애폴리스-하니웰 (하니웰 연구소), RCA, 스페리 랜드(Sperry Rand), 실베이니아 일렉트릭 프로덕츠였다. 세 군데의 정부 기관들은 미국 공군, 해군의 데이비드 테일러 모델 베이슨(David Taylor Model Basin), 국립표준국(현재의 미국 국립표준기술연구소)이었다.[27] 이 위원회의 위원장은 미국 국립표준국의 조지프 웨그스타인(Joseph Wegstein)이었다. 데이터 설명, 문(文), 기존의 응용 프로그램, 사용자 경험을 조사하면서 작업이 개시되었다.[28]

이 위원회는 주로 FLOW-MATIC, AIMACO, COMTRAN이라는 프로그래밍 언어들을 조사하였다.[20][29] FLOW-MATIC 언어는 특히 영향력이 있었는데 그 까닭은 그것이 내부에 구현되었기 때문이기도 하지만 그 밖의 이유로는 AMIACO가 단지 사소한 변경만으로 그것을 파생시켰기 때문이다.[30][31] FLOW-MATIC의 발명가 그레이스 호퍼는 또한 그 위원회에 기술 고문 역할을 하였다.[24] FLOW-MATIC이 코볼에 기여한 주된 사항으로는 긴 변수 이름, 명령어를 위한 영어 낱말, 데이터 기술 및 명령의 구분이다.[32]

밥 베머가 발명한 IBM의 COMTRAN 언어는 그레이스 호퍼의 동료들이 만든 단기 위원회에 의해[33] FLOW-MATIC의 경쟁 언어로 간주되었다.[34][35] 기능들 중 일부는 코볼에 포함되지 않았는데, IBM이 설계 과정을 지배한 것처럼 보이지 않게 하기 위함이었고,[22] 1981년에 진 사멧은 그녀 자신을 포함해서 "강력한 반IBM 편견"이 일부 위원회 구성원들에게 있음을 언급했다.[36] 한 사례로 COMTRAN 설명서의 저자이자 중기 위원회 구성원이었던 로이 골드핑거가 그의 언어를 지원하고 대수식 이용을 장려하기 위해 소위원회 회의에 참석했는데, 그 뒤 그레이스 호퍼는 단기 위원회에 메모를 보내면서 영어가 기반이 되는 언어를 만들겠다는 스페리 랜드의 노력을 재차 강조했다.[37] 1980년에 그레이스 호퍼는 코볼 60이 95% FLOW-MATIC으로 되어 있으며 COMTRAN은 매우 적은 부분에서 영향을 주었다고 언급하였다.[38] 코볼에 포함된 COMTRAN의 기능들은 공식들,[39] PICTURE 절,[40] GO TO의 필요성을 제거하는 개선된 IF 문, 더 강력한 파일 관리 시스템을 포함하였다.[34]

이 위원회의 노고가 유용했는지에 대해서는 큰 논란의 대상이 되었다. 일부 구성원들이 이 언어가 너무 많은 절충이 있었고 위원회의 설계에 따른 결과물이라고 생각한 반면, 다른 구성원들은 조사된 세 개의 언어들 보다 더 낫다고 느꼈다. 일부는 이 언어가 너무 복잡하다고 생각했고 다른 이들은 너무 단순하다고 여겼다.[41] 논란이 되는 기능들은 일부분이 데이터 처리 사용자들에게 쓸모 없거나 너무 고급적인 기능들로 간주되었다. 이러한 기능들에는 불 대수, 공식, 테이블 서브스크립트(subscripts, indices)가 포함되었다.[42][43] 논란의 다른 관점으로는 키워드를 문맥에 대응할 것인지에 대한 것이었다.[42] 문맥에 의존적인 키워드들은 거부되었지만 이러한 접근은 나중에 PL/I에 사용되었고, 부분적으로는 2002년부터 코볼에 사용되었다.[44] 당시 일부 존재하였던 운영 체제와의 상호 작용과 기능(순수하게 수학적이었고 데이터 처리용은 아닌 것으로 간주)에 대한 고려가 거의 없었다.[45][46]

이 사양들은 9월 4일 집행 위원회에 제시되었으나, 기대에는 한참 못미쳤다. 조지프 웨그스타인은 "여기에 러프 스팟(rough spot)이 포함되어 있고 일부 추가가 필요하다"고 언급했고 나중에 밥 베머는 이들을 잡동사니로 기술하였다. 소위원회는 12월까지 그것을 개선하라는 지시를 받았다.[24]

9월 중순 회의에서 위원회는 새로운 언어의 이름을 논의하였다. 제안된 이름으로는 "BUSY" (비즈니스 시스템: Business System), "INFOSYL"(정보 시스템 언어: Information System Language), "COCOSYL"(공용 컴퓨터 시스템 언어: Common Computer Systems Language)를 포함하였다[47] 코볼(COBOL)이라는 이름은 밥 베머가 제안하였다.[48][49]

10월에 중기 위원회는 로이 넛이 만든 FACT 언어 사양의 사본을 받았다. 이 언어의 기능들은 위원회에 매우 큰 감명을 주었고, 그것으로 기본 코볼에 대한 결의안을 통과시켰다.[50] 이것은 사양에 대해 잘 진척시켜온 단기 위원회에게는 충격이었다. 기술적으로 우위에 있었음에도 FACT는 이식성을 염두에 두지도 않았고, 제조업체나 사용자 합의를 통해 만들어지지도 않았다. 증명할만한 구현체 또한 부족하였으므로,[24] FLOW-MATIC 기반 코볼의 지지자들이 이 결의안을 뒤집을 수 있었다. RCA 대표 하워드 브롬버그(Howard Bromberg) 또한 FACT를 차단함으로써 코볼 구현체에 대한 RCA의 노고가 물거품이 되지 않게 하였다.[51]

'그러면 어떠한 이름을 새기고 싶으십니까?'
나는 '당신을 위해 여기에 쓰겠습니다'라고 말했고 그 이름을 COBOL이라고 썼다.
'그 이름의 뜻이 무엇입니까?'
'글쎄요, 이것은 폴란드 이름입니다. 우리는 이름을 줄였고 불필요한 수많은 표기법을 없앴습니다.'

“
”
하워드 브롬버그 - 어떻게 코볼 묘비를 구매했는가[52]

곧 이 위원회는 너무 방대해져 진행 속도를 더 낼 수 없었다. 실망감을 느낀 하워드 브롬버그는 COBOL이라 새겨진 $15의 묘비를 구매하고 찰스 필립스에게 보내 그의 불만을 드러냈다.[b][52][54] 소위원회가 구성되어 기존 언어들을 분석하였는데, 여기에는 6명의 인원으로 이루어졌다:[20][55]

  • 윌리엄 셀든(William Selden), 거트루드 티어니(Gertrude Tierney) (IBM),
  • 하워드 브롬버그(Howard Bromberg), 하워드 디스카운트(Howard Discount) (RCA),
  • 버넌 리브스(Vernon Reeves), 진 E. 사멧(Jean E. Sammet) (Sylvania Electric Products)

소위원회는 사양을 만드는 일로 대부분을 보냈고, 최종 사양을 생산하기 앞서 단기 위원회가 그들의 일을 검토하고 수정하는 일을 맡았다.[20]

COBOL. Report to Conference on Data Systems Languages including initial specifications for a Common Business Oriented Language (COBOL) for programming digital electronic computers. Department of Defense, April 1960.
코볼 60 보고서 표지

1960년 1월 3일 집행 위원회는 이 사양을 승인하였고 정부 인쇄소에 전달되어 "COBOL 60"으로 인쇄되었다. 이 언어에 언급된 목적은 효율적이고 이식 가능한 프로그램들이 쉽게 작성될 수 있게 함으로써 사용자들이 적은 노력과 비용을 들여 새로운 시스템으로 이전할 수 있게 하고 미숙한 프로그래머들도 적절히 쓸 수 있게 하기 위함이다.[56] CODASYL 집행 위원회는 사용자들과 업체들로부터의 질문에 답하고 사양을 확장하고 개선할 목적으로 나중에 코볼 유지보수 위원회를 창설하였다.[57]

1960년 동안 코볼 컴파일러를 만들 예정인 제조업체의 수가 늘어났다. 9월까지 다섯 곳 이상의 제조업체가 CODASYL (벤딕스, 컨트롤 데이터 코퍼레이션, 제너럴 일렉트릭(GE), 내셔널 캐시 레지스터, 필코)에 참여하였고 대표되는 모든 제조업체들이 코볼 컴파일러를 발표하였다. GE와 IBM은 코볼을 자신들의 언어들인 GECOM과 COMTRAN에 각각 통합하였다. 반면, 인터내셔널 컴퓨터스 앤드 태뷸레이터스(International Computers and Tabulators)는 그들의 언어인 CODEL을 코볼로 대체할 예정이었다.[58]

그 와중에 RCA와 스페리 랜드는 코볼 컴파일러를 만드는 일을 하였다. 최초의 코볼 프로그램은 8월 17일 RCA 501에서 수행되었다.[59] 12월 6일, 7일에 동일한 코볼 프로그램(사소한 변경사항이 있긴 하지만)이 RCA 컴퓨터, Remington-Rand 유니박 컴퓨터에서 실행되어 이들의 호환성을 입증하였다.[60]

오늘날 모든 코볼 참조 매뉴얼에는 다음과 같이 인쇄되어 있다:

코볼은 산업 표준이며 어떠한 컴퓨터나 회사 그룹의 재산도, 어느 단체나 단체 그룹의 소유도 아니다.

프로그래밍 시스템과 언어의 정확성과 기능에 관해 기여한 자나 CODASYL 코볼 위원회가 표현, 암시한 부분에 대해서는 어떠한 보증도 없다. 또, 이와 연관된 어떠한 기여자나 위원회에 의해 어떠한 책임도 물을 수 없다. 여기에 사용된, 저작권 보호를 받는 자료의 저자와 저작권자는 아래와 같다:

FLOW-MATIC (trademark of Unisys Corporation), Programming for the UNIVAC (R) I and II, Data Automation Systems, copyrighted 1958, 1959, by Unisys Corporation; IBM Commercial Translator Form No. F28-8013, copyrighted 1959 by IBM; FACT, DSI 27A5260-2760, copyrighted 1960 by Minneapolis-Honeywell.

이들은 코볼 사양의 일부나 전체에 대해 이 자료의 이용을 허가함. 이러한 권한은 프로그래밍 설명서나 비슷한 출판물의 코볼 사양의 재생산 및 이용으로 확장됨.[61]

코볼-61 ~ 코볼-65

[편집]

코볼이 10년이 지나면 존재할 가능성은 없어 보인다.

익명 - 1960년 6월[62]

수많은 논리적 결함들이 코볼 60에 발견되었는데, GE의 찰스 캐츠는 이에 대해 모호하게 해석되지 않는다고 경고하였다. 마지못한 단기 위원회는 완전한 정리를 단행하였고 1963년 3월 코볼의 문법이 알골의 것처럼 정의가 가능해졌으나 의미적인 모호성(semantic ambiguities)은 여전히 남아있다고 보고되었다.[58]

초기 코볼 컴파일러들은 원시적이었고 속도가 느렸다. 1962년 미국 해군 평가는 분당 3-11개 문의 컴파일 속도를 지적했다. 1964년 중순에는 분당 11-1000개의 문으로까지 증가하였다. 메모리가 늘어나면서 속도가 급격하게 빨라졌고 컴파일 비용이 다양해졌다. 문 당 비용은 $0.23에서 $18.91 사이였다.[63]

1962년 말에 IBM은 코볼이 그들의 주 개발 언어가 되고 COMTRAN의 개발은 중단할 것이라 선언하였다.[63]

코볼 사양은 출판 이후로 5년 안에 3번 개정되었다. 코볼-60은 1961년에 코볼-61으로 대체되었다. 그 뒤 코볼-61 확장 사양으로 1963년에 대체되어 정렬 및 보고서 작성 기능이 도입되었다.[64] 추가된 기능들은 하니웰이 1959년 말 단기 위원회에 편지를 보내 확인된 결함들을 수정하였다.[59] 코볼 에디션 1965는 사양에 대해 더 명확히 하고 대용량 기억 장치의 파일들과 표를 다룰 수 있는 기능을 소개하였다.[65]

코볼-68

[편집]

버전 간 비호환성을 극복하기 위해 코볼을 표준화하는 작업이 시작되었다. 1962년 말 ISO와 미국 스탠더드(현재의 ANSI)는 표준을 만드는 그룹들을 설립하였다. ANSI는 1968년 8월 《USA Standard COBOL X3.23》을 만듦으로써 차기 버전들의 주춧돌이 되었다.[66] 이 버전은 ANS(American National Standard) 코볼로 알려져 있으며 1972년에 ISO에 채택되었다.[67]

코볼-74

[편집]

1970년에 코볼은 전 세계에서 가장 널리 쓰이는 프로그래밍 언어가 되었다.[68]

ANSI 위원회와 독립적으로 CODASYL 프로그래밍 언어 위원회는 언어 개선에 착수했다. 이들은 1968년, 1969년, 1970년, 1973년에 새로운 버전들을 기술하였고, 여기에 새로운 프로그램 간 통신, 디버깅, 파일 병합 기능, 개선된 문자열 관리, 라이브러리 포함 기능과 같은 변경 사항을 포함하였다.[69] CODASYL이 ANSI 위원회와 독립적이었으나, ANSI는 《CODASYL Journal of Development》를 사용하여 구현을 보증하는데 충분히 대중적인 기능들을 식별하게 하였다.[70] 프로그래밍 언어 위원회는 또한 ECMA와 일본 코볼 표준 위원회와도 연계하였다.[69]

그러나 프로그래밍 언어 위원회는 잘 알려지지 않았다. 부사장이었던 William Rinehuls는 코볼 커뮤니티의 2/3이 위원회의 존재조차 모르고 있다고 불평하였다. 또, 무료로 이용이 가능한 변경 사항 제안, 회의록과 같은 공용 문서를 만들 자금이 부족할 정도로 빈약했다.[71]

1974년 ANSI는 (ANS) 코볼의 개정판을 출판하였으며, 여기에는 파일 조직, DELETE 문[72], 세그먼트 모듈[73]과 같은 새로운 기능들이 포함되었다. NOTE 문, EXAMINE 문(INSPECT 문으로 대체), 구현자 정의 랜덤 액세스 모듈(새로운 순차 및 상대 입출력 모듈로 대체)과 같은 기능들이 제거되었다. 44개의 변경 사항으로 이루어져 있고 새로운 표준과 호환되지 않은 기존의 문들을 나열하였다.[74] 보고서 작성 기능은 혹평을 받아 코볼에서 물러났지만 표준이 출판되기 전에 복귀되었다.[75][76] 나중에 ISO는 1978년에 갱신된 표준을 채택하였다.[67]

코볼-85

[편집]

1978년 7월, 코볼 74를 개정하는 작업이 시작되었다. 제안된 표준(일반적으로 코볼-80으로 알려져 있음)은 이전 것과는 상당히 달랐으므로 비호환성 및 변환 비용에 대한 걱정을 야기하였다. 1981년 1월, 트래블러스 인슈런스(Travelers Insurance)의 수석 부사장 조지프 T 브로피(Joseph T. Brophy)는 표준 위원회를 고소하겠다고 위협하였는데 그 까닭은 코볼-74와 상위 호환이 되지 않았기 때문이다. 브로피는 그들의 40,000,000줄이나 되는 코드의 변환을 "비생산적"이고 "프로그램 자원 중 완전한 쓰레기"라고 기술하였다.[77] 그 해의 나중에 DPMA(Data Processing Management Association)는 이것은 새로운 표준에 강하게 반하는 것이며, 엄두도 못 낼 정도로 높은 변환 비용과 기능 강화가 사용자에게 강제되었다고 언급하였다.[78][79]

공식적인 최초 검토 기간 동안 위원회는 2,200개의 응답을 받았으며 이 가운데 1,700개가 부정적인 형태의 편지들이었다.[80] 그 밖의 응답들은 코볼-80이 그들의 시스템에 설치할 수 있는지의 상세한 영향도 분석에 대한 것이었다. 변환 비용이 코드 한 줄에 적어도 50 센트가 들 것으로 예측되었다. 12개도 채 안 되는 응답에서는 제안된 표준을 선호한다는 의견이었다.[81]

1983년 DPMA는 새로운 표준에 대한 반대를 철회하고 대중이 걱정하는 사항들에 대한 위원회의 응답을 언급하였다. 같은 해에 미국 국립표준국의 연구에 따르면 제안된 표준은 문제점이 거의 없을 것으로 결론을 내렸다.[79][82] 한 해 더 지나 코볼-80 컴파일러가 코볼-74 프로그램들의 변환에 일부 문제가 있었던 DEC VAX 사용자들에게 공개되었다. 새로운 EVALUTE 문과 인라인 PERFORM이 단순해진 제어 흐름와 디버깅 덕분에 특히 잘 받아들여져 생산성이 향상되었다.[83]

1985년 말에 ANSI는 개정된 표준을 출판하였다. 60개의 기능들이 변경되거나 사용을 권장하지 않는 쪽으로 바뀌었고 다음과 같은 기능들이 포함되었다:[84][85]

  • 범위 종단자 (END-IF, END-PERFORM, END-READ 등)
  • 내재된 프로그램(nested programs)
  • CONTINUE 문 - no-operation 문
  • EVALUTE 문 - switch 문
  • INITIALIZE 문
  • 인라인 PERFORM 루프 - 이전에 반복체는 별도의 프로시저에 정의하여야 했음
  • 참조 수정 - 부분열(substring) 접근 허용
  • 입출력 상태 코드

이 표준은 같은 해에 ISO에 채택되었다.[67] 두 개의 개정안이 1989년(내장 함수 도입)과 1993년(기타 수정 사항 제공)에 공개되었다. ISO는 표준의 주 소유권과 개발을 최종적으로 취득하기 전에 1991년과 1994년에 각각 개정안들을 채택하였다.[67]

코볼 2002 및 객체 지향 코볼

[편집]

1990년대 초에 완전한 리비전의 차기 코볼에 객체 지향을 추가하는 작업이 시작되었다.[1][2] 객체 지향 기능들은 C++과 스몰토크로부터 가져왔다. 초기에는 1997년에 이 리비전이 완수될 것으로 예측했으며 ISO 위원회 초안(Committee Draft)은 1997년에 이용이 가능하게 되었다. 마이크로 포커스, 후지쯔, IBM을 포함한 일부 업체들은 완전한 리비전의 초안에 기반한 객체 지향 문법을 도입하였다. 마지막으로 승인된 ISO 표준은 2002년 말에 승인되어 출판되었다.[86]

후지쯔/GT소프트웨어[87], 마이크로 포커스, 레인코드(RainCode)는 닷넷 프레임워크를 대상으로 한 객체 지향 코볼 컴파일러를 도입하였다.

기타 수많은 기능들이 있었으며, 이 가운데 다수가 《CODASYL COBOL Journal of Development since 1978》에 언급되었고 코볼-85에 포함될 기회는 놓치게 되었다.[88] 이러한 다른 기능들은 다음을 포함한다:[89][90]

3개의 정정 사항이 표준에 출판되었다. (2006년에 2개, 2009년에 1개)[91]

코볼 2014

[편집]

2003년과 2009년 사이에 3개의 기술 보고서가 생산되었으며, 코볼을 위한 오브젝트 완성(object finalization), XML 처리, 콜렉션 클래스를 기술하고 있다.[91]

코볼 2002의 지원 수준은 매주 낮았다. 즉, 이 표준을 온전히 지원하는 컴파일러가 전무했다. 마이크로 포커스는 그 이유를 새로운 기능에 대한 사용자 수요가 적고 컴파일러 적합성을 테스트하는데 쓰였던 미국 국립표준기술연구소(NIST) 테스트 제품군이 철폐되었기 때문으로 보았다. 표준화 과정 또한 속도가 느렸고 자원이 부족했다.[92]

코볼 2014는 다음의 변경 사항을 포함한다:[93]

  • 이식 가능한 산술 결과물들은 IEEE 754 자료형으로 치환됨
  • 주된 기능이 선택 사항이 됨. (예: 객체 지향, VALIDATE 기능, 보고서 작성 기능, 화면 핸들링 기능)
  • 메소드 오버로딩
  • 동적 캐퍼시티 테이블 (코볼 2002 초안으로부터 제거된 기능)[94]

레거시

[편집]

코볼 프로그램들은 정부와 기업체에 고루 사용되며 z/OS, VME, 유닉스, 윈도우와 같은 다양한 운영 체제에서 구동된다. 1997년 가트너 그룹은 전 세계 비즈니스의 80%가 200,000,000,000줄 이상의 코드의 코볼을 실행하였고 한 해에 5,000,000,000줄 이상이 작성되고 있다고 보고했다.[95]

20세기 말 무렵, 2000년 문제(Y2K) 해결을 위해 코볼 프로그래밍 노력이 상당 부분 집중되었으며 가끔은 10년 전에 시스템을 개발했던 동일 프로그래머들에 의해 수행되었다. 코볼 코드를 고치는데 필요한 일정 수준의 노력이 상당량의 비즈니스 지향 코볼에 전가되었는데, 사무 응용 프로그램들이 날짜를 사용하는 정도가 심했기 때문이다. 그 외에 고정 길이 데이터 필드에도 영향을 주었다.

2006년과 2012년에 컴퓨터월드 조사에 따르면 조직 중 60%가 코볼을 (C++, 비주얼 베이직 닷넷보다 더) 사용하였으며 코볼은 자사 내부 소프트웨어 다수에 사용되었다.[8][96] 관리자 중 36%가 코볼로부터 이관할 예정이라고 언급했으며, 25%는 값이 더 저렴해진다면 그러할 의향이 있다고 밝혔다. 일부 기업체는 그들의 코볼 프로그램들을 유지보수하면서도 그들의 시스템을 값비싼 메인프레임에서 더 값싼 더 현대적인 시스템으로 이관해오고 있다.[8]

기능

[편집]

문법

[편집]

코볼은 영어와 같은 문법을 가지고 있으며, 프로그램 안의 거의 모든 것을 기술하는데 사용된다. 예를 들어, 조건은 x IS GREATER THAN y로 표현할 수 있고, 더 간결하게는 x GREATER y나 x > y로 표현할 수 있다. 더 복잡한 조건들은 반복되는 조건과 변수들을 제거하여 축약할 수 있다. 이를테면 a > b AND a > c OR a = d는 a > b AND c OR = d로 줄일 수 있다. 영어와 같은 문법을 지닌 코볼은 300개의 예약어가 있다.[97][c] 일부 예약어는 대체가 가능하고 단복수를 표현하는 낱말도 마치 영어의 구문처럼 바꾸어 사용할 수 있다. 이를테면 IN과 OF 키워드는 번갈아 사용할 수 있는데, 이는 IS와 ARE, VALUE와 VALUES도 그러하다.

각 코볼 프로그램은 4개의 어휘 항목을 이룬다; 워드, 리터럴, 픽처(PICTURE) 문자, 구분자(separator). 워드에는 예약어와 사용자 정의 식별자를 포함한다. 이들은 최대 31개 문자 길이로 되어 있으며 문자, 숫자, 하이픈(-), 언더바(_)를 포함할 수 있다. 리터럴은 숫자(예: 12)와 문자(예: 'Hello!')를 포함한다.[99] 구분자는 공백 문자와 콤마, 세미콜론을 포함하고 그 뒤에 공백이 온다.[100]

코볼 프로그램은 4개의 구역으로 나뉜다: IDENTIFICATION DIVISION, ENVIRONMENT DIVISION, DATA DIVISION, PROCEDURE DIVISION. IDENTIFICATION DIVISION은 소스 요소의 이름과 종류를 정의하며 여기서 클래스와 인터페이스가 지정된다. ENVIRONMENT DIVISION은 이를 실행하는 시스템에 의존하는 프로그램 기능을 정의하는데, 이를테면 파일과 문자 집합을 들 수 있다. DATA DIVISION은 변수와 매개변수를 선언하는데 쓰인다. PROCEDURE DIVISION은 프로그램의 문을 포함한다. 각 구역은 섹션으로 다시 구분되며 섹션은 여러 문단으로 이루어진다.

코드 포맷

[편집]

코볼은 두 가지 포맷으로 작성할 수 있다: 고정 포맷 (기본값), 자유(free) 포맷. 고정 포맷의 경우 코드는 특정 이름에 맞추어 정렬하여야 한다. 코볼 2002까지는 아래와 같았다:

이름 컬럼 용도
시퀀스 번호 영역 1–6 본래 카드/줄 번호에 사용되었으나 컴파일러는 이 영역을 무시한다.
지시자 영역 7 여기에는 다음의 문자가 허용된다:
  • * – 주석
  • / – 새로운 문서의 소스 목록에 출력할 주석
  • - – 계속행(continuation line). 이전 줄의 워드나 리터럴을 계속하여 처리한다.
  • D – 디버그 모드에서 사용되는 줄, 그 밖의 이용에서는 무시됨
영역 A 8–11 여기에는 다음을 포함한다: DIVISION, SECTION, 프로시저 헤더; 01과 77 레벨 번호, 파일/보고서 서술자
영역 B 12–72 영역 A에 허용되지 않는 기타 코드
프로그램 이름 영역 73– 역사적으로는 천공 카드에 최대 80컬럼까지 사용했으며, 카드에 속하는 프로그램이나 시퀀스를 식별하는데 사용된다.

코볼 2002에서 영역 A와 B는 컬럼 255로 병합, 확장되었으며 프로그램 이름 영역은 제거되었다.[101]

코볼 2002는 또한 자유 포맷 코드를 도입하였다.[101] 자유 포맷 코드는 마치 더 새로운 프로그래밍 언어들에서처럼 파일의 어느 열에나 위치할 수 있다. 주석은 *>을 이용하여 지정하며 어느 곳에서 위치해도 되고 고정 포맷 소스 코드에도 사용할 수 있다. 계속행은 존재하지 않으며 >>PAGE라는 지시자는 / 지시자를 대체한다.[102]

IDENTIFICATION DIVISION

[편집]

IDENTIFICATION DIVISION은 다음의 코드 개체를 식별하고 클래스나 인터페이스의 정의를 포함한다.

객체 지향 프로그래밍

[편집]

클래스와 인터페이스라는 개념은 2002년 이후로 코볼에 포함되고 있다. 클래스에는 클래스 메소드와 변수, 인스턴스 오브젝트를 포함하는 팩토리 오브젝트(factory object)와 인스턴스 메소드와 변수를 포함하는 인스턴스 오브젝트(instance object)들을 갖고 있다.[103] 상속과 인터페이스들은 다형성을 제공한다.

제네릭 프로그래밍 지원은 매개변수 방식의 클래스들을 통해 제공되며, 클래스나 인터페이스를 사용하여 예를 들 수 있다. 오브젝트들은 특정한 종류에 제한을 두기 위해 참조용으로 저장된다. 이른바 두 종류의 메소드가 있다.: INVOKE 문 (CALL과 매우 비슷하게 동작), 인라인 메소드 호출(함수를 사용하는 것과 비슷).[104] 

*> 아래의 것들은 동등하다.
INVOKE my-class "foo" RETURNING var
MOVE my-class::"foo" TO var *> 인라인 메소드 호출

코볼은 메소드를 숨기는 방식은 제공하지 않는다. 클래스 데이터는 숨길 수 있지만, 사용자가 그것에 접근하지 못하도록 PROPERTY 절 없이 선언한 경우에야 가능.[105] 메소드 오버로드는 코볼 2014에 추가되었다.[106]

ENVIRONMENT DIVISION

[편집]

ENVIRONMENT DIVISION에는 CONFIGURATION SECTION과 INPUT-OUTPUT SECTION을 포함한다. CONFIGURATION SECTION은 통화 기호, 로케일, 문자 집합과 같은 변수 기능들을 지정하는데 사용한다. INPUT-OUTPUT SECTION은 파일 관련 정보를 포함한다.

파일

[편집]

코볼은 세 개의 파일 포맷, 즉 오거나이제이션(organization)을 지원한다: 순차(sequential), 색인(indexed), 상대(relative). 순차 파일에서 레코드들은 연속적이며 순차적으로 가로질러야 하는데, 이는 마치 연결 리스트와 비슷하다. 색인 파일들은 하나 이상의 색인을 갖고 있어서 레코드들이 임의 접근을 가능하게 하고 이들에 저장을 가능케 한다. 각 레코드는 고유 키를 가지고 있어야 하지만 다른 대안이 되는 레코드 키들은 꼭 고유하지 않아도 된다. 색인 파일들의 구현체들은 업체에 따라 다르지만, C‑ISAM와 VSAM과 같은 공통 구현체들은 IBM의 ISAM에 기반을 두고 있다. 색인 파일들과 비슷한 상대 파일들은 고유 레코드 키를 가지고 있으나 대안 키들이 존재하지는 않는다. 상대 레코드의 키는 서열적인 위치를 지니는데, 이를테면 10번째 레코드는 10의 키를 가진다. 다시 말해, 5의 키를 지닌 레코드를 만들 때에는 (비어있는) 선행 레코드들이 만들어져야 한다. 또, 상대 파일들은 순차 및 임의 접근이 가능하다.[107]

공통 비표준 확장으로 줄 단위의 순차 방식(line sequential organization)이 있으며 텍스트 파일을 처리하는데 쓰인다. 파일 안의 레코드들은 새 줄 단위로 끝을 맺으며 그 길이는 다양하다.[108]

DATA DIVISION

[편집]

DATA DIVISION은 여섯 개의 섹션으로 나뉘며 각기 다른 항목들을 선언한다. 파일 레코드의 경우 FILE SECTION, 정적 변수의 경우 WORKING-STORAGE SECTION, 매개변수와 반환값의 경우 LINKAGE SECTION, 텍스트 기반 사용자 인터페이스의 경우 REPORT SECTION과 SCREEN SECTION이 있다.

데이터 집합

[편집]

코볼의 데이터 항목들은 데이터 항목이 다른 것의 일부인지를 지시하는 줄 번호를 사용하여 계층적으로 선언한다. 더 높은 수준의 번호에 위치한 항목은 더 낮은 번호의 항목에 종속된다. 번호 1을 가진 최상위 데이터 항목들은 레코드(record)라고 한다. 종속된 데이터 집합을 지닌 항목들은 그룹 항목(group item)이라고 하며, 이들을 기초 항목(elementary item)이라 부르지는 않는다. 표준 데이터 항목들을 기술하는데 쓰이는 계층적 번호들은 1부터 49 사이에 위치한다.[109][110] 

       01  some-record.                   *> 집합 그룹 레코드 항목
           05  num            PIC 9(10).  *> 기초 항목
           05  the-date.                  *> 집합 하위 그룹 레코드 항목
               10  the-year   PIC 9(4).   *> 기초 항목
               10  the-month  PIC 99.     *> 기초 항목
               10  the-day    PIC 99.     *> 기초 항목

위의 예에서 기초 항목 num과 그룹 항목 the-date는 레코드 some-record에 종속되어 있지만 기초 항목 the-year, the-month, the-day은 그룹 항목 the-date의 일부분이다.

종속 항목들은 IN (또는 OF)이라는 키워드를 함께 사용하면 동일 이름의 항목을 구분할 수 있다. 이를테면 위의 예제 코드가 다음의 예제 코드와 나란히 있다고 하자: 

       01  sale-date.
           05  the-year       PIC 9(4).
           05  the-month      PIC 99.
           05  the-day        PIC 99.

the-year, the-month, the-day라는 이름들은 그 자체로 혼동이 있는데, 그 이유는 the-date에 위치한 항목들과 the-date에 위치한 항목들이 동일한 이름으로 정의되어 있기 때문이다. 특정 데이터 항목(예를 들어 sale-date 그룹에 속하는 항목의 하나)을 지정하려면 프로그래머는 the-year IN sale-date 또는 the-year OF sale-date를 사용하면 된다. (이러한 문법은 마치 최근의 언어에서 지원되는 닷 노테이션/dot notation과 비슷함)

그 밖의 데이터 수준

[편집]

66이라는 수준의 번호는 항목의 구조화와는 관계 없이 이전에 정의된 항목들을 다시 묶는 것을 선언하기 위해 쓰인다. RENAMES 절과 함께 쓰이는 이 데이터 수준은 거의 쓰이지 않으며[111] 1988년 경의 오래된 프로그램들에서나 흔히 볼 수 있다. 계층적, 논리적 구조의 데이터를 무시하는 이 기능은 이용이 권장되지 않았으며 수많은 설치본들에서 이의 사용을 금하였다.[112] 

       01  customer-record.
           05  cust-key            PIC X(10).
           05  cust-name.
               10  cust-first-name PIC X(30).
               10  cust-last-name  PIC X(30).
           05  cust-dob            PIC 9(8).
           05  cust-balance        PIC 9(7)V99.

       66  cust-personal-details   RENAMES cust-name THRU cust-dob.
       66  cust-all-details        RENAMES cust-name THRU cust-balance.

77 수준의 번호는 그 항목이 단독적임을 나타내며 이러한 상황에서 1이라는 수준 번호와 동등하다. 이를테면 다음의 코드는 두 개의 77 수준 데이터 항목 property-name, sales-region을 선언하며, 이들은 다른 어떠한 데이터 항목들과도 종속되지 않고 독립적인, 그룹에 속하지 않은 데이터 항목들이다: 

       77  property-name      PIC X(80).
       77  sales-region       PIC 9(5).

88 수준의 번호는 조건명을 선언하며, 부모 데이터 항목이 그 VALUE 절안에 지정된 값들의 하나를 포함할 때 참이다.[113] 이를테면 다음의 코드는 두 개의 88 수준의 조건명 항목들을 정의하며, wage-type 데이터 항목의 현재 문자 데이터 값에 따라 참이냐 거짓이냐가 결정된다. 해당 데이터 항목에 'H'라는 값이 포함되는 경우 조건명 wage-is-hourly은 참이지만, 'S'나 'Y'라는 값이 포함되면 조건명 wage-is-yearly가 참이다. 데이터 항목에 그 밖의 다른 값이 포함되어 있으면 조건명은 거짓이다. 

       01  wage-type          PIC X.
           88  wage-is-hourly VALUE "H".
           88  wage-is-yearly VALUE "S", "Y".

자료형

[편집]

표준 코볼은 다음의 자료형을 제공한다:[114]

자료형 샘플 선언 참고
영문자 PIC A(30) 레터와 공백만 포함
영숫자 PIC X(30) 어떠한 문자도 포함
불린 PIC 1 USAGE BIT 0과 1이라는 이진 숫자 형태로 저장된 데이터
색인 USAGE INDEX 테이블 요소를 참조하는데 사용
내셔널 PIC N(30) 영숫자와 비슷하지만 확장 문자 집합을 이용 (예: UTF-8)
숫자 PIC 9(5)V9(5) 숫자만 포함할 수 있음
오브젝트 USAGE OBJECT REFERENCE 오브젝트나 NULL을 참조할 수 있음
포인터 USAGE POINTER

자료형 안전은 코볼 안에서 변칙적이다. 수치 데이터는 각기 다른 표현들과 크기들로 조용히 변환되며 영숫자 데이터는 숫자와 그룹 데이터를 포함하여 문자열로 저장될 수 있는 어떠한 데이터 항목에라도 올 수 있다.[115] 반면에 오브젝트 참조들과 포인터들은 동일한 종류의 항목들로부터만 할당을 받을 수 있으며 이들의 값들은 그 종류에 제한을 받는다.[116]

PICTURE 절
[편집]

PICTURE 또는 PIC 절은 문자들의 문자열로, 각각이 데이터 항목의 일부분임과 동시에 무엇이 포함될 것인지를 대표한다. 일부 PICTURE 문자들은 데이터의 종류 및 얼마나 많은 문자열이나 숫자들을 메모리에 차지하게 할 것인지를 지정한다. 이를테면 9은 10진수를 가리키며 S는 항목이 부호가 있음을 가리킨다. 그 밖의 PICTURE 문자들(삽입 및 편집 문자)은 어떻게 항목이 형식을 가져야 하는지를 지정한다. 이를테면 일련의 + 문자들은 문자의 위치뿐 아니라 선두가 되는 부호가 어떻게 마지막 문자 데이터 내에 위치할 것인지를 정의한다. 즉, 맨 오른쪽에 있는 숫자가 아닌 문자는 항목의 부호를 포함하겠지만, 이 위치의 왼쪽에 있는 +에 일치하는 다른 문자 위치들은 공백을 포함하는 식이다. 반복되는 문자들은 PICTURE 문자 뒤의 괄호에 숫자를 넣어서 더 간결하게 지정할 수 있다. 이를테면 9(7)는 9999999와 같다. (9)와 부호 (S)만을 포함하는 PICTURE 사양들은 순수하게 숫자 데이터 항목들만 정의하고 있지만, 영문자(A)나 영숫자(X)를 포함하는 PICTURE 사양들은 영숫자 데이터 항목을 정의한다. 그 밖의 형식의 문자로는 편집된 숫자(edited numeric)나 편집된 영숫자(edited alphanumeric) 데이터 항목들로 정의된다.[117]

예
PICTURE 절 입력값 출력값
PIC 9(5) 100 00100
"Hello" "Hello" (이것은 유효하지만, 미정의 동작을 일으킨다)[115]
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 절
[편집]

USAGE 절은 데이터가 저장되는 포맷을 선언한다. 자료형에 따라 PICTURE 절을 보완하거나 해당 절 대신 사용할 수 있다. 포인터와 오브젝트 참조를 선언하는데 사용할 수 있지만, 대개는 수치 자료형을 지정하기 위해 존재한다. 이러한 수치 자료형은 다음과 같다:[118]

  • 이진값: 최소 크기가 PICTURE 절 또는 USAGE 절 (예: BINARY-LONG)에 의해 지정됨
  • USAGE COMPUTATIONAL: 데이터는 구현체가 정의한 임의의 포맷으로 저장됨. USAGE BINARY와 동일.
  • USAGE DISPLAY: 기본값. 데이터가 문자열로 저장됨.
  • 부동소수점: 구현체 의존 포맷이거나 IEEE 754를 따름.
  • USAGE NATIONAL: 데이터가 확장 문자 집합을 이용하여 문자열로 저장됨.
  • USAGE PACKED-DECIMAL: 데이터는 가능한 작은 10진 형식으로 저장됨. (일반적으로 묶음 이진화 십진법으로 저장됨.)

보고서 작성기

[편집]

보고서 작성기(report writer)는 보고서를 작성하기 위한 선언형 기능이다. 프로그래머는 보고서 레이아웃 및 보고서를 만들어내는데 필요한 데이터만 지정하면 되며, 페이지 나누기, 데이터 형식 지정, 머릿말과 꼬릿말과 같은 것들을 다루기 위해 코드를 작성할 필요는 없다.[119]

보고서는 보고서 파일들에 연결되며, 이 파일들은 보고서 작성기 문들을 통해서만 기록이 가능하다. 

       FD  report-out REPORT sales-report.

각 보고서는 DATA DIVISION의 REPORT SECTION에 정의된다. 보고서는 보고서의 머릿말, 꼬릿말, 상세 사항을 정의하는 보고서 그룹들로 나뉜다. 보고서들은 계층적 제어 차단(control break)을 두고 동작한다. 제어 차단은 키 변수가 값을 변경할 때 발생한다. 이를테면 고객 주문이 상세히 적힌 보고서를 만들 때 프로그램이 다른 고객의 주문에 도달하게 되면 제어 차단이 일어난다. 아래는 판매원의 판매 정보를 제공하고 유효하지 않은 레코드를 경고하는 보고서를 설명한 예이다: 

       RD  sales-report
           PAGE LIMITS 60 LINES
           FIRST DETAIL 3
           CONTROLS seller-name.

       01  TYPE PAGE HEADING.
           03  COL 1                    VALUE "Sales Report".
           03  COL 74                   VALUE "Page".
           03  COL 79                   PIC Z9 SOURCE PAGE-COUNTER.

       01  sales-on-day TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "Sales on".
           03  COL 12                   PIC 99/99/9999 SOURCE sales-date.
           03  COL 21                   VALUE "were".
           03  COL 26                   PIC $$$$9.99 SOURCE sales-amount.

       01  invalid-sales TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "INVALID RECORD:".
           03  COL 19                   PIC X(34) SOURCE sales-record.

       01  TYPE CONTROL HEADING seller-name, LINE + 2.
           03  COL 1                    VALUE "Seller:".
           03  COL 9                    PIC X(30) SOURCE seller-name.

위의 보고서 설명은 아래의 레이아웃을 기술한다: 

Sales Report                                                             Page  1

Seller: Howard Bromberg
  Sales on 10/12/2008 were $1000.00
  Sales on 12/12/2008 were    $0.00
  Sales on 13/12/2008 were   $31.47
  INVALID RECORD: Howard Bromberg             XXXXYY

Seller: Howard Discount
...
Sales Report                                                            Page 12

  Sales on 08/05/2014 were  $543.98
  INVALID RECORD: William Selden      12O52014FOOFOO
  Sales on 30/05/2014 were    $0.00

4개의 문들이 보고서 작성기를 제어한다: INITIATE는 인쇄를 위해 보고서 작성기를 준비한다. GENERATE는 보고서 그룹을 인쇄한다. SUPPRESS는 보고서 그룹의 인쇄를 숨긴다. TERMINATE는 보고 처리를 끝낸다. 위의 판매 보고서의 예를 기준으로 PROCEDURE DIVISION은 다음의 모습과 같이 되어 있다: 

           OPEN INPUT sales, OUTPUT report-out
           INITIATE sales-report

           PERFORM UNTIL 1 <> 1
               READ sales
                   AT END
                       EXIT PERFORM
               END-READ

               VALIDATE sales-record
               IF valid-record
                   GENERATE sales-on-day
               ELSE
                   GENERATE invalid-sales
               END-IF
           END-PERFORM

           TERMINATE sales-report
           CLOSE sales, report-out
           .

PROCEDURE DIVISION

[편집]

프로시저

[편집]

PROCEDURE DIVISION(통틀어 프로시저로 호칭)에 위치한 섹션과 문단은 레이블과 단순한 함수로 사용할 수 있다. 다른 디비전들과 달리 문단은 섹션 안에 꼭 올 필요는 없다.[120] 실행은 프로그램의 프로시저를 통해 종료가 될 때까지 내려간다.[121] PERFORM 동사를 사용하면 프로시저를 함수로 쓸 수 있다. 이를 통해 제어권을 특정한 범위의 프로시저들에 넘긴 다음 마지막에 다다를 때에만 복귀한다.

PROCEDURE DIVISION. PERFORM update-screen. GOBACK. fix-screen SECTION. MOVE "Error fixed" TO screen-line. PERFORM update-screen. update-screen SECTION. IF invalid-screen, GO TO fix-screen. END-IF.
화면이 유효하지 않을 때 지뢰를 끌어안게 된다.

특이한 제어 흐름은 지뢰를 만들어낼 수 있는데, 여기서 지뢰는 수행된 프로시저의 제어권을 예측하지 못한 시간대에 예측하지 못한 장소로 돌아오는 문제를 야기한다. 프로시저들은 세 가지 방법으로 접근할 수 있다: 1) PERFORM 문으로 호출, 2) GO TO 문으로 넘어옴, 3) 윗 문단의 아랫 부분으로 빠지면서 수행되는 실행을 통해. 이들을 결합해 사용하면 미정의 동작을 일으켜 지뢰를 만들어낸다.

구체적으로 말해 일정 범위의 프로시저들의 실행으로 말미암아, 이미 수행된 프로시저 범위의 과거 문을 제어 흐름이 통과하는 상황에서 발생한다.[122][123]

이를테면 옆 그림의 코드에서 지뢰는 화면이 유효하지 않을 때 update-screen의 끝으로 이동한다. 화면이 유효하지 않으면 제어권은 fix-screen 섹션으로 넘어가며, 완료 시 update-screen을 수행한다. 이러한 재귀 현상은 미정의 동작을 일으켜서, 수행 중인 프로시저들이 두 개가 존재하게 된다. 이 지뢰는 update-screen 끝에 도달할 때 폭파되며, 두 위치 중 한 곳으로 돌아올 수 있음을 의미한다:

  • 최초의 PERFORM 문
  • fix-screen의 PERFORM 문. 여기서 update-screen로 빠지면서 끝에 다다를 때 최초의 PERFORM으로 돌아온다.

문

[편집]

코볼 2014를 기준으로 47개의 문들이 있으며(verb/동사라고 함)[124] 다음의 넓은 분류로 묶을 수 있다: 제어 흐름, 입출력, 데이터 조작, 보고서 작성기. 보고서 작성기 문들은 보고서 작성기 섹션에서 다룬다.

제어 흐름
[편집]

코볼의 조건문으로는 IF와 EVALUATE가 있다. EVALUATE는 마치 여러 개의 값들과 조건들을 평가하는 기능이 추가된 switch와 비슷한 문이다. 의사결정표를 구현하는데 사용할 수 있다. 이를테면 다음은 CNC 선반을 제어하는데 쓰일 수 있다. 

EVALUATE TRUE ALSO desired-speed ALSO current-speed
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN desired-speed
        PERFORM slow-down-machine
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
        PERFORM speed-up-machine
    WHEN lid-open ALSO ANY ALSO NOT ZERO
        PERFORM emergency-stop
    WHEN OTHER
        CONTINUE
END-EVALUATE

PERFORM 문은 조건이 참이 될 때까지 실행하는 반복문을 정의한다. (다른 언어들의 wihle과는 다름) 프로시저들이나 일정한 범위의 프로시저들을 호출하기 위해서도 쓰인다. (프로시저 단락 참고) CALL와 INVOKE는 각각 하위 프로그램들과 메소드를 호출한다. 하위 프로그램/메소드의 이름은 리터럴이나 데이터 항목이 되는 문자열 안에 포함된다.[125] 매개변수들은 참조에 의해서나 내용을 통해서나(사본이 참조에 의해 전달될 때) 값에 의해(프로토타입을 이용할 수 있는 경우에만) 전달할 수 있다.[126] CANCEL은 하위 프로그램들을 메모리로부터 해제한다. GO TO 절들은 프로그램이 지정된 프로시저로 건너뛰게 한다.

GOBACK 문은 반환문이며 STOP 문은 프로그램을 정지시킨다. EXIT 문에는 각기 다른 형식이 있다: 반환문, break 문, continue 문, 끝 표시기(end marker) 또는 프로시저를 빠져나는 기능으로 사용할 수 있다.[127]

예외는 RAISE 문을 통해 발생시킬 수 있으며 PROCEDURE DIVISION의 DECLARATIVES 부분에 정의되는 핸들러(declarative로 부름)에 의해 포착된다. DECLARATIVES는 USE 문으로 시작하는 섹션들이며, 다루어져야 할 오류를 지정한다. 예외는 이름이나 오브젝트가 될 수 있다. RESUME은 DECLARATIVE 안에서 사용할 수 있으며, DECLARATIVES 밖의 프로시저나 예외를 일으킨 지점 이후의 문으로 건너뛸 수 있다. 다른 언어들과는 달리 포착되지 못한 예외들은 프로그램을 끝내지 못하며 프로그램은 영향을 받지 않은 채로 계속 실행된다.

입출력
[편집]

파일 입출력은 자체 기술되는 OPEN, CLOSE, READ, WRITE 문들에 의해 처리되며, 이들은 다음의 세 가지와 나란히 쓰인다: REWRITE는 레코드를 업데이트한다. START는 특정 키로 레코드를 찾음으로써, 접근할 차기의 레코드를 선택한다. UNLOCK은 마지막으로 접근한 레코드의 락을 해제한다.

사용자 상호 작용은 ACCEPT와 DISPLAY를 이용하여 수행된다.

데이터 조작
[편집]

다음의 동사들은 데이터를 조작한다:

  • INITIALIZE: 데이터 항목을 이들의 기본값으로 설정한다.
  • MOVE: 값을 데이터 항목들로 할당한다.
  • SET: 15개의 형식이 있다. 테이블 서브스크립트를 수정하고 오브젝트 참조를 할당하며 테이블 용적을 변경하는 등의 일을 한다.[128]
  • ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE: 공식의 결과를 변수에 할당하는 COMPUTE와 함께 산술을 처리한다.
  • ALLOCATE, FREE: 동적 메모리를 처리한다.
  • VALIDATE: DATA DIVISION의 항목 설명에 지정된대로 데이터를 확인하고 분산한다.
  • STRING, UNSTRING: 전자의 경우 문자열을 이어 붙이고, 후자의 경우 문자열을 나눈다.
  • INSPECT: 문자열 안에 지정된 부분열의 인스턴스를 치환하거나 검수한다.
  • SEARCH: 테이블을 훑어보며 조건을 만족하는 첫 엔트리를 찾는다.

파일과 테이블은 SORT를 이용하여 정렬하고 MERGE 동사는 파일을 병합하고 정렬한다. RELEASE 동사는 정렬할 레코드를 제공하고 RETURN은 정렬된 레코드를 순서대로 검색한다.

범위 종단

[편집]

IF, READ와 같은 일부 문들은 스스로가 문들을 포함할 수 있다. 이러한 문들은 두 가지 방법으로 끝을 맺는다:

  1. 포함이 끝나지 않은 모든 문들을 모두 종료하는, 암묵적 종단(implicit termination)을 가리키는 구두점(.)
  2. 가장 가까이 일치하는 개방된 문의 끝을 맺는 범위 종단자
*> 종단자 구두점 (암묵적 종단)
IF invalid-record
    IF no-more-records
        NEXT SENTENCE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE.

*> 범위 종단자 (명시적 종단)
IF invalid-record
    IF no-more-records
        CONTINUE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE
        END-READ
    END-IF
END-IF

구두점으로 끝나는 내재(nested)된 문들은 버그의 근원이 된다.[129][130] 이를테면 다음의 코드를 살펴보자: 

IF x
    DISPLAY y.
    DISPLAY z.

여기서 조건 x가 참일 때 y와 z를 모두 보여주는 것이 프로그래머의 의도이다. 그러나 실제로는 IF 문에서 실수로 DISPLAY y 뒤에 구두점을 잘못 넣었기 때문에 x의 값이 무엇인지에 관계 없이 z가 표시된다.

또 다른 버그로는 허상 엘스 문제의 결과인데, 두 개의 IF 문들이 하나의 ELSE에 연결될 수 있을 때 나타난다. 

IF x
    IF y
        DISPLAY a
ELSE
    DISPLAY b.

위의 부분에서 ELSE는 IF x문이 아니라 IF y 문에 연결되며 버그가 발생한다. 명시적 범위 종단자들이 도입되기 전까지 이러한 버그를 예방하려면 ELSE NEXT SENTENCE를 안쪽 IF 뒤에 위치시켜야 했다.

자체 수정 코드

[편집]

원래의 코볼 사양은 악명이 높은  ALTER X TO PROCEED TO Y  문을 지원하였고, 이를 위해 수많은 컴파일러들이 자체 수정 코드를 생성하였다. X와 Y는 프로시저의 레이블이고, ALTER 문 뒤에 실행되는 프로시저 X 안의 하나의  GO TO  문은  GO TO Y 를 의미한다. 수많은 컴파일러들이 이를 지원하지만[131] 코볼 1985 표준에서는 이용하지 않을 것을 권고하였고 2002년에 삭제되었다.[132]

Hello world

[편집]

코볼의 Hello world 프로그램은 다음과 같다. 

       IDENTIFICATION DIVISION.
       PROGRAM-ID. hello-world.
       PROCEDURE DIVISION.
           DISPLAY "Hello, world!"
           .

HELLO, WORLD

[편집]

지금은 유명한 《C 프로그래밍 언어》(The C Programming Language)라는 책의 Hello world 프로그램 예제가 1978년 첫 출판되었을 때, 비슷한 메인프레임 코볼 프로그램 예제가 80컬럼의 천공 카드와 천공 카드 리더를 사용할 가능성이 매우 높은 JCL을 통해 제출되었다.

아래는 DATA DIVISION이 비어있으며 MVS 3.8J이 구동되는 시스템/370 허큘리스 에뮬레이터와 GNU/리눅스를 통해 테스트되었다. 2015년 7월에 작성된 이 JCL은 제이 무슬리(Jay Moseley)의 허큘리스 강좌와 샘플에서 가져온 것이다.[133] 동시대의 코볼 프로그래밍을 유지한 채 HELLO, WORLD은 모두 대문자로 표시된다. 

//COBUCLG JOB (001),'COBOL BASE TEST', 00010000
// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) 00020000
//BASETEST EXEC COBUCLG 00030000
//COB.SYSIN DD * 00040000
 00000* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR 00190000
// DD DSNAME=SYS1.LINKLIB,DISP=SHR 00200000
//GO.SYSPRINT DD SYSOUT=A 00210000
// 00220000

JCL을 제출한 뒤 MVS 콘솔은 다음을 보여주었다: 

    19.52.48 JOB    3  $HASP100 COBUCLG  ON READER1     COBOL BASE TEST
    19.52.48 JOB    3  IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG  ISSUED
    19.52.48 JOB    3  $HASP373 COBUCLG  STARTED - INIT  1 - CLASS A - SYS BSP1
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSLIB   DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEFACTRT - Stepname  Procstep  Program   Retcode
    19.52.48 JOB    3  COBUCLG    BASETEST  COB       IKFCBL00  RC= 0000
    19.52.48 JOB    3  COBUCLG    BASETEST  LKED      IEWL      RC= 0000
    19.52.48 JOB    3  +HELLO, WORLD
    19.52.48 JOB    3  COBUCLG    BASETEST  GO        PGM=*.DD  RC= 0000
    19.52.48 JOB    3  $HASP395 COBUCLG  ENDED

콘솔의 10번째 줄에 결과를 위해 색으로 강조 표시되었으며, 이 강조 표시 색은 실제 콘솔 출력의 일부분은 아니다.

비평과 옹호

[편집]

구조의 결여

[편집]

1970년대에 프로그래머들은 구조적이지 않은 스파게티 코드를 구조적 프로그래밍 패러다임으로 옮기기 시작하였다. 컴퓨터 과학자이자 튜링상을 받은 에츠허르 데이크스트라는 "코볼을 이용하는 일은 마음을 무력하게 만든다. 이에 대한 교리는 범죄 공격으로 여겨진다."고 강조하면서 편집장에게 보내는 "어떻게 우리가 상처를 줄 수 있는 진실을 이야기하는가?"라는 제목의 1975년 편지에서 동시대 코볼의 일부를 비평하였다.[134]

스파게티 코드의 한 가지 이유는 GO TO 문이다. GO TO 문을 코볼 코드에서 제거하려는 시도는 그러나 난해한 프로그램들을 만들고 코드 품질을 떨어트렸다.[135] GO TO 문은 대체적으로 PERFORM 문과 프로시저로 대체되었는데 이로 말미암아 모듈식 프로그래밍을 촉진시켰고[135], 강력한 반복 기능으로 손쉬운 접근을 가능케 했다. 그러나 PERFORM 문은 오직 프로시저와 함께 쓰일 수 있으므로 반복문은 이들이 사용하는 곳에 위치되지 않아 프로그램을 이해하기 더 어렵게 만들게 된다.[136]

코볼 프로그램들은 이음매가 없고 모듈성이 결여된 점으로 악명이 높았다.[137] 코볼 코드는 프로시저를 통해서만 모듈성을 이룰 수 있어 대형 시스템에서는 부적절한 것으로 알려져 있었다. 데이터로의 접근을 제한하는 것이 불가능하였는데, 다시 말해 프로시저 하나가 어떠한 데이터 항목이라도 접근하여 수정할 수 있었다. 게다가 매개변수를 프로시저에 보내는 방법이 없었는데, 이를 빠트린 것을 두고 진 사멧은 위원회의 최대 실수로 간주하였다.[138] 또다른 복합적 문제는 PERFORM THRU 기능에서 비롯한다. 제어권이 어떠한 프로시저로 점프할 수 있고 어떠한 프로시저로부터 반환을 받을 수 있다는 것을 말하며, 이는 난해한 제어 흐름을 만들고 프로그래머가 하나의 입구, 하나의 출구(single entry, single exit) 규칙을 무너뜨릴 가능성이 있다.[139]

이러한 상황은 코볼이 더 많은 기능을 채용하면서 개선되었다. 코볼-74는 하부 프로그램들을 추가하여 프로그래머들에게 각 프로그램 부분이 접근할 수 있는 데이터를 제어하는 기능을 제공하였다. 그 뒤로 코볼-85는 내재형 하위 프로그램(nested subprogram)을 추가하여 프로그래머들이 하위 프로그램들을 숨길 수 있게 하였다.[140] 데이터와 코드의 추가적인 제어는 2002년에 도입되어 객체 지향 프로그래밍, 사용자 지정 함수, 사용자 지정 자료형이 포함되었다.

호환성 문제

[편집]

코볼은 이식성이 높은, 공통으로 쓰이는 언어를 목표로 개발된 언어였다. 그러나 2001년까지 대략 300개의 방언이 만들어졌다.[141]

코볼-85는 그 이전의 버전들과 완전히 호환되지 못했고 이에 대한 개발은 논란이 있었다. 트래블러스 인슈런스(Travelers Insurance)의 CIO 조지프 T. 브로피는 막중한 프로그래밍 비용을 들이는 코볼 사용자들에게 새로운 표준의 구현을 알리는 일을 진두지휘하였다.[142] 그 결과 ANSI 코볼 위원회는 2,200장 이상의 편지를 받았는데 대부분 부정적이었고 위원회가 변경을 취할 수 밖에 없게 만들었다. 한편, 코볼-85로의 전환은 그 뒤의 수년 동안 생산성 증가를 가져올 것으로 여겨졌고 변환 비용을 정당화시킬 수 있었다.[143]

장황한 문법

[편집]
COBOL: /koh′bol/, n.

공룡 메인프레임에 별 생각 없는 일들을 하기 위해 코드 그라인더들이 사용하는 빈약하고 장황하고 힘없는 언어. [중략] 그 이름 자체는 혐오나 공포의 의식 없이는 좀처럼 언급되지 않는다.

“
”

코볼 문법은 장황하다는 이유로 자주 비판을 받아왔다. 지지자들은 이것이 코드를 자체 문서화하여 프로그램 유지보수를 쉽게 하기 위한 것이라고 말한다.[145] 또, 코볼은 프로그래머들이 배우고 쓰기 쉽게 하기 위해 만들어졌지만[146] 관리자들과 같은 비기술 종사자들에게도 읽힌다. 가독성에 대한 열망으로 인해 명사, 동사, 절, 문장, 섹션, 디비전과 같은 영어와 비슷한 문법과 구조 요소들을 이용하게 되었다.[147][148][149][150] 코볼 프로그램을 유지보수하는 사람들은 1984년까지는 이해하기 어려운 코드를 다루는데 고심해야 했으며[149] 코볼-85의 주요 변경 사항들은 유지보수를 쉽게 할 수 있게 도와준다.[80]

단기 위원회 구성원인 진 사멧은 "전문 프로그래머에게 제공하려는 시도는 거의 없었다. 주된 관심거리가 프로그래밍인 사람들은 코볼을 매우 언짢게 생각하는 경향이 있다."고 언급하며 그녀는 이를 코볼의 장황한 문법 때문인 것으로 보았다.[151]

컴퓨터 과학 공동체와의 분리

[편집]

코볼 공동체는 늘 컴퓨터 과학 공동체와는 분리되어 왔다. 어떠한 학술 컴퓨터 과학자들도 코볼의 설계에 참여하지 않았다. 위원회에 속한 전원이 상업 분야나 정부 쪽 출신이었다. 당시 컴퓨터 과학자들은 코볼 개발이 씨름하던 상용 파일 처리 문제 보다 수치 분석, 물리학, 시스템 프로그래밍과 같은 분야에 더 관심이 많았다. 진 사멧은 우아하지 못함, 설계 과정에 참여할 영향력 있는 컴퓨터 과학자들의 부족, 사무용 데이터 처리를 업신여기는 것 때문에 코볼의 인기가 없던 것을 초기의 잘난체 반응 때문인 것으로 보았다.[152]

코볼 사양은 새로운 배커스-나우르 표기법이 아닌, 고유한 표기법이나 메타 언어를 사용했는데 그 이유는 이를 들었던 위원회 구성원들이 얼마 없었기 때문이었다. 이로 인해 가혹한 비평을 받았다.[153][154][155][58]

나중에 코볼은 코볼을 아우르는 자료의 부족으로 고통을 받았다. 소개 서적들이 등장하는데 1963년까지 그러하였다. 미국 의회도서관에는 포트란의 경우 코볼의 2배 분량의 서적이, 베이직의 경우 코볼의 4배 분량의 서적이 있었다.[156] 대학 교수들은 직업 학교용으로 간주된 코볼 대신 더 현대적인, 최신식의 언어들과 테크닉을 가르쳤다.[157] CODASYL 코볼 위원회의 의장인 도널드 넬슨은 1984년에 "학계가 ... 코볼을 싫어한다"고 말했고 컴퓨터 과학 동문들은 "'코볼이 싫다'라는 것을 그들에게 주입시켰다"고 말했다.[158] 마이크로 포커스의 2013년 조사에 따르면 대학 학계의 20%는 코볼은 구식이거나 죽었다고 생각했으며 55%는 그들의 학생들이 코볼이 구식이거나 죽었다고 생각하였다고 믿었다. 동일 조사에서 60%가 코볼을 가르쳐야 한다고 생각함에도 불구하고 학계의 25%만이 그들의 교육과정에 코볼 프로그래밍이 있었다.[159] 반면, 2003년 코볼은 미국에서 정보 시스템 교육과정의 80%에 특별히 포함되었는데 이는 C++와 자바의 비율과 동일하다.[160]

설계 과정에 대한 걱정

[편집]

설계 과정이 효과적인지에 대한 의구심이 있었다. (가끔은 코볼에 참여한 사람들까지도) 단기 위원회 구성원 호워드 브롬버그는 개발 과정에서 통제가 거의 없었으며 "소속 인원의 지속성이 없고 ... 재능의 부족으로 홍역을 치렀다"고 말했다.[68]

코볼 표준들은 수차례 지연으로 인해 고통을 받아왔다: 코볼-85는 희망했던 날보다 5년은 더 늦었고[161] COBOL 2002도 5년이 늦었으며,[1] COBOL 2014는 6년이 늦었다.[86][162] 지연을 방지하기 위해 표준 위원회는 다음 표준 리비전을 기다리지 않고 더 빨리 추가 기능을 더 빠르게 추가하는 선택적인 부록을 만드는 것을 허용하였다. 그러나 일부 위원회 구성원들은 구현체와 표준의 잦은 수정 간에 따르는 비호환성에 대해 걱정을 드러냈다.[163]

다른 언어들에 미친 영향

[편집]

코볼의 자료 구조는 뒤에 나온 프로그래밍 언어들에 영향을 주었다. 레코드와 파일 구조는 PL/I과 파스칼에 영향을 주었고, REDEFINES 절은 파스칼의 변종 레코드의 이전 것이었다. 분명한 파일 구조 정의들은 데이터베이스 관리 시스템의 개발보다 앞섰고 수집된 데이터는 포트란의 배열보다 훨씬 더 앞선 것이었다.[156]

원시적인 수준으로 간주되긴 하지만[164] 코볼의 COPY 기능은 include 지시자의 개발에 영향을 미쳤다.[156]

이식성과 표준화에 초점을 둠에 따라 코볼로 작성된 프로그램들은 이식이 가능하였고 언어가 다양한 하드웨어 플랫폼과 운영 체제에 안착할 수 있었다.[165] 게다가 잘 정의된 디비전 구조는 ENVIRONMENT DIVISION의 외부 참조 정의를 제한함으로써 특히 플랫폼 변경을 단순화하는 일에 기여하였다.[166]

같이 보기

[편집]
Portal icon기술 포털

참고

[편집]
  1. ↑ 가 나 Specifically influenced COBOL 2002's object-oriented features.[1][2]
  2. ↑ 묘비는 현재 컴퓨터 역사 박물관에 있다.[53]
  3. ↑ Vendor-specific extensions cause many implementations to have far more: one implementation recognizes over 1,100 keywords.[98]

각주

[편집]
  1. ↑ 가 나 다 Saade, Henry; Wallace, Ann (October 1995). “COBOL '97: A Status Report”. 《Dr. Dobb's Journal》. 2014년 4월 22일에 원본 문서에서 보존된 문서. 2014년 4월 21일에 확인함. 
  2. ↑ 가 나 Arranga, Edmund C.; Coyle, Frank P. (February 1998). 《Object-Oriented COBOL》. Cambridge University Press. 15쪽. ISBN 978-0132611404. Object-Oriented COBOL's style reflects the influence of Smalltalk and C++. 
  3. ↑ Imajo, Tetsuji; 외. (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. 
  4. ↑ Radin, George (1978). Wexelblat, Richard L., 편집. 《The early history and characteristics of PL/I》. History of Programming Languages. Academic Press (1981에 출판됨). 572쪽. doi:10.1145/800025.1198410. ISBN 0127450408. 
  5. ↑ Oliveira, Rui (2006). 《The Power of Cobol》. City: BookSurge Publishing. ISBN 0-620-34652-3. 
  6. ↑ Robinson, Brian (2009년 7월 9일). “Cobol remains old standby at agencies despite showing its age”. 《FCW》. Public Sector Media Group. 2014년 4월 27일에 원본 문서에서 보존된 문서. 2014년 4월 26일에 확인함. 
  7. ↑ Mitchell, Robert L. (2012년 3월 14일). “Brain drain: Where Cobol systems go from here”. 《Computerworld》. 2015년 2월 9일에 확인함. 
  8. ↑ 가 나 다 Mitchell, Robert L. (2006년 10월 4일). “Cobol: Not Dead Yet”. 《Computerworld》. 2014년 4월 27일에 원본 문서에서 보존된 문서. 2014년 4월 27일에 확인함. 
  9. ↑ Porter Adams, Vicki (1981년 10월 5일). “Captain Grace M. Hopper: the Mother of COBOL”. 《InfoWorld》 3 (20): 33. ISSN 0199-6649. 
  10. ↑ Betts, Mitch (1992년 1월 6일). “Grace Hopper, mother of Cobol, dies”. 《Computerworld》 26 (1): 14. ISSN 0010-4841. 
  11. ↑ 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. 52쪽. ISBN 978-0786730766. 
  12. ↑ Ensmenger, Nathan L. (2009). 《The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise》. MIT Press. 100쪽. ISBN 978-0262050937. LCCN 2009052638. 
  13. ↑ “ISO/IEC 1989:2014”. ISO. 2014년 5월 26일. 2014년 6월 7일에 확인함. 
  14. ↑ Beyer 2009, 282쪽.
  15. ↑ Beyer 2009, 281–282쪽.
  16. ↑ Sammet 1978a, 200쪽.
  17. ↑ Beyer 2009, 283쪽.
  18. ↑ Beyer 2009, 284쪽.
  19. ↑ “Early Meetings of the Conference on Data Systems Languages”. 《IEEE Annals of the History of Computing》 7 (4): 316. 1985. doi:10.1109/MAHC.1985.10047. 
  20. ↑ 가 나 다 라 마 Sammet 2004, 104쪽.
  21. ↑ Beyer 2009, 286쪽.
  22. ↑ 가 나 Conner 1984, ID/9쪽.
  23. ↑ Sammet 1978a, 201쪽.
  24. ↑ 가 나 다 라 Bemer 1971, 132쪽.
  25. ↑ Beyer 2009, 288쪽.
  26. ↑ Sammet 1978a, 203쪽.
  27. ↑ CODASYL 1969, § I.2.1.1.
  28. ↑ Sammet 1978a, 204쪽.
  29. ↑ CODASYL 1969, § I.1.2.
  30. ↑ Beyer 2009, 290쪽.
  31. ↑ Sammet, Jean (1978). “The Early History of COBOL”. 《ACM SIGPLAN Notices》 (Association for Computing Machinery, Inc.) 13 (8): 121–161. doi:10.1145/960118.808378. 2010년 1월 14일에 확인함. 
  32. ↑ Sammet 1978a, 217쪽.
  33. ↑ Beyer 2009, 296쪽.
  34. ↑ 가 나 Beyer 2009, 292쪽.
  35. ↑ Bemer 1971, 131쪽.
  36. ↑ Sammet 1978a, 221쪽.
  37. ↑ Beyer 2009, 291쪽.
  38. ↑ “Oral History of Captain Grace Hopper” (PDF). 컴퓨터 역사 박물관. December 1980. 37쪽. 2017년 12월 25일에 원본 문서 (PDF)에서 보존된 문서. 2014년 6월 28일에 확인함. 
  39. ↑ Sammet 1978a, 218쪽.
  40. ↑ Marcotty 1978, 268쪽.
  41. ↑ Sammet 1978a, 205–206쪽.
  42. ↑ 가 나 Sammet 1978a, Figure 8.
  43. ↑ Sammet 1978a, 230–231쪽.
  44. ↑ ISO/IEC JTC 1/SC 22/WG 4 2001, 846쪽.
  45. ↑ Sammet 1978a, 220쪽.
  46. ↑ Sammet 1978a, 228쪽.
  47. ↑ Sammet 1978a, 210쪽.
  48. ↑ Sullivan, Patricia (2004년 6월 25일). “Computer Pioneer Bob Bemer, 84”. 《The Washington Post》. B06면. 2014년 6월 28일에 확인함. 
  49. ↑ Bemer, Bob. “Thoughts on the Past and Future”. 2014년 5월 16일에 원본 문서에서 보존된 문서. 2014년 6월 28일에 확인함. 
  50. ↑ Beyer 2009, 293쪽.
  51. ↑ Beyer 2009, 294쪽.
  52. ↑ 가 나 “The Story of the COBOL Tombstone” (PDF). 《The Computer Museum Report》 (The Computer Museum) 13: 8–9. Summer 1985. 2014년 4월 3일에 원본 문서 (PDF)에서 보존된 문서. 2014년 6월 29일에 확인함. 
  53. ↑ “COBOL Tombstone”. 컴퓨터 역사 박물관. 2014년 6월 29일에 확인함. 
  54. ↑ Bemer 1971, 130쪽.
  55. ↑ Beyer 2009, 289쪽.
  56. ↑ CODASYL 1969, § I.1.1.
  57. ↑ Brown 1976, 47쪽.
  58. ↑ 가 나 다 Bemer 1971, 133쪽.
  59. ↑ 가 나 Beyer 2009, 297쪽.
  60. ↑ Williams, Kathleen Broome (2012년 11월 10일). 《Grace Hopper: Admiral of the Cyber Sea》. US Naval Institute Press. ISBN 978-1612512655. OCLC 818867202. 
  61. ↑ Compaq Computer Corporation: Compaq COBOL Reference Manual, Order Number: AA–Q2G0F–TK October 2000, Page xviii; Fujitsu Corporation: Net Cobol Language Reference, Version 15, January 2009; IBM Corporation: Enterprise COBOL for z/OS Language Reference, Version 4 Release 1, SC23-8528-00, December 2007
  62. ↑ Garfunkel, Jerome (1984년 11월 11일). “In defense of Cobol”. 《Computerworld》 18 (24): ID/19. 
  63. ↑ 가 나 Bemer 1971, 134쪽.
  64. ↑ Brown 1976, 48쪽.
  65. ↑ CODASYL 1969, § I.2.2.4.
  66. ↑ CODASYL 1969, § I.2.3.
  67. ↑ 가 나 다 라 Follet, Robert H.; Sammet, Jean E. (2003). Ralston, Anthony; Reilly, Edwin D.; Hemmendinger, David, 편집. 《Programming language standards》. 《Encyclopedia of Computer Science》 4판 (Wiley). 1467쪽. ISBN 0470864125. 
  68. ↑ 가 나 Beyer 2009, 301쪽.
  69. ↑ 가 나 Brown 1976, 49쪽.
  70. ↑ Brown 1976, 52쪽.
  71. ↑ Taylor, Alan (1972년 8월 2일). “Few Realise Wasted Resources of Local DP Schools”. 《Computerworld》 6 (31): 11. 
  72. ↑ Triance, J. M. (1974). 《Programming in COBOL: A Course of Twelve Television Lectures》. Manchester University Press. 87쪽. ISBN 0719005922. 
  73. ↑ Klein 2010, 16쪽.
  74. ↑ Baird, George N.; Oliver, Paul (May 1977). 〈1974 Standard (X3.23–1974)〉. 《Programming Language Standards — Who Needs Them?》 (PDF) (기술 보고서). 19–21쪽. 2014년 1월 7일에 원본 문서 (PDF)에서 보존된 문서. 2014년 1월 7일에 확인함. 
  75. ↑ Culleton, John R., Jr. (1975년 7월 23일). “'Spotty' Availability A Problem...”. 《Computerworld》 9 (30): 17. ISSN 0010-4841. 
  76. ↑ Simmons, Williams B. (1975년 6월 18일). “Does Cobol's Report Writer Really Miss the Mark?”. 《Computerworld》 9 (25): 20. ISSN 0010-4841. 
  77. ↑ Shoor, Rita (1981년 1월 26일). “User Threatens Suit Over Ansi Cobol-80”. 《Computerworld》 15 (4): 1, 8. ISSN 0010-4841. 
  78. ↑ Shoor, Rita (1981년 10월 26일). “DPMA Takes Stand Against Cobol Draft”. 《Computerworld》 15 (43): 1–2. ISSN 0010-4841. 
  79. ↑ 가 나 Gallant, John (1985년 9월 16일). “Revised Cobol standard may be ready in late '85”. 《Computerworld》 19 (37): 1, 8. ISSN 0010-4841. 
  80. ↑ 가 나 “Expert addresses Cobol 85 standard”. 《Computerworld》 19 (37): 41, 48. 1985년 9월 16일. ISSN 0010-4841. 
  81. ↑ Paul, Lois (1982년 3월 15일). “Responses to Cobol-80 Overwhelmingly Negative”. 《Computerworld》 16 (11): 1, 5. ISSN 0010-4841. 
  82. ↑ Paul, Lois (1983년 4월 25일). “Study Sees Few Problems Switching to Cobol-8X”. 《Computerworld》 17 (17): 1, 6. 
  83. ↑ Gillin, Paul (1984년 11월 19일). “DEC users get head start implementing Cobol-80”. 《Computerworld》 18 (47): 1, 6. ISSN 0010-4841. 
  84. ↑ Garfunkel 1987, 150쪽.
  85. ↑ Roy, M. K.; Dastidar, D. Ghost (1989년 6월 1일). 〈Features of COBOL-85〉. 《COBOL Programming: Problems and Solutions》 2판. McGraw-Hill Education. 438–451쪽. ISBN 978-0074603185. 
  86. ↑ 가 나 “COBOL Standards”. Micro Focus. 2004년 3월 31일에 원본 문서에서 보존된 문서. 2014년 9월 2일에 확인함. 
  87. ↑ “NetCOBOL for .Net”. 《netcobol.com》. GTSoftware. 2013. 2014년 7월 8일에 원본 문서에서 보존된 문서. 2014년 1월 29일에 확인함. 
  88. ↑ “A list of Codasyl Cobol features”. 《Computerworld》. 1984년 9월 10일. ID/28쪽. ISSN 0010-4841. 2014년 6월 8일에 확인함. 
  89. ↑ ISO/IEC JTC 1/SC 22/WG 4 2001, Annex F.
  90. ↑ Klein 2010, 21쪽.
  91. ↑ 가 나 “JTC1/SC22/WG4 - COBOL”. ISO. 2010년 6월 30일. 2013년 9월 2일에 원본 문서에서 보존된 문서. 2014년 4월 27일에 확인함. 
  92. ↑ Billman, John; Klink, Huib (2008년 2월 27일). “Thoughts on the Future of COBOL Standardization” (PDF). 2015년 9월 23일에 원본 문서 (PDF)에서 보존된 문서. 2014년 8월 14일에 확인함. 
  93. ↑ ISO/IEC JTC 1/SC 22/WG 4 2010, Annex E.
  94. ↑ Schricker, Don (1998년 12월 2일). “J4: COBOL Standardization”. Micro Focus. 1999년 2월 24일에 원본 문서에서 보존된 문서. 2014년 7월 12일에 확인함. 
  95. ↑ Kizior, Ronald J.; Carr, Donald; Halpern, Paul. “Does COBOL Have a Future?” (PDF). 《The Proceedings of the Information Systems Education Conference 2000》 17 (126). 2016년 8월 17일에 원본 문서 (PDF)에서 보존된 문서. 2012년 9월 30일에 확인함. 
  96. ↑ “Cobol brain drain: Survey results”. 《Computerworld》. 2012년 3월 14일. 2014년 4월 27일에 원본 문서에서 보존된 문서. 2014년 4월 27일에 확인함. 
  97. ↑ ISO/IEC JTC 1/SC 22/WG 4 2010, § 8.9.
  98. ↑ “Reserved Words Table”. 《Micro Focus Visual COBOL 2.2 COBOL Language Reference》. Micro Focus. 2014년 3월 3일에 확인함. 
  99. ↑ ISO/IEC JTC 1/SC 22/WG 4 2010, § 8.3.1.
  100. ↑ ISO/IEC JTC 1/SC 22/WG 4 2010, § 8.3.2.
  101. ↑ 가 나 ISO/IEC JTC 1/SC 22/WG 4 2001, § F.2.
  102. ↑ ISO/IEC JTC 1/SC 22/WG 4 2010, § D.2.
  103. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.18.2.
  104. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.18.
  105. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, 108쪽.
  106. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, 896쪽.
  107. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.2.1.
  108. ↑ “File Organizations”. 《File Handling》. Micro Focus. 1998. 2016년 3월 4일에 원본 문서에서 보존된 문서. 2014년 6월 27일에 확인함. 
  109. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.5.1.2.
  110. ↑ Cutler 2014, Appendix A.
  111. ↑ Hubbell, Thane (1999). 《Sams Teach Yourself COBOL in 24 hours》. SAMS Publishing. 40쪽. ISBN 978-0672314537. LCCN 98087215. 
  112. ↑ McCracken & Golden 1988, § 19.9.
  113. ↑ Cutler 2014, § 5.8.5.
  114. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 8.5.2.
  115. ↑ 가 나 ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.24.
  116. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.35.
  117. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 13.18.40.
  118. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 13.18.60.3.
  119. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, 855쪽.
  120. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.4.
  121. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.6.3.
  122. ↑ Field, John; Ramalingam, G. (September 1999). 《Identifying Procedural Structure in Cobol Programs》 (PDF). PASTE '99. doi:10.1145/381788.316163. ISBN 1581131372. 
  123. ↑ Veerman, Niels; Verhoeven, Ernst-Jan (November 2006). “Cobol minefield detection” (PDF). 《Software—Practice and Experience》 (Wiley) 36 (14). doi:10.1002/spe.v36:14. 2007년 3월 6일에 원본 문서 (PDF)에서 보존된 문서. 
  124. ↑ ISO/IEC JTC 1/SC 22/WG4 2014, § 14.9.
  125. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, §§ 14.9.4, 14.9.22.
  126. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § D.6.5.2.2.
  127. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.13.1.
  128. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, §14.9.35.1.
  129. ↑ ISO/IEC JTC 1/SC 22/WG 4 2014, 899쪽.
  130. ↑ McCracken & Golden 1988, § 8.4.
  131. ↑ Examples of compiler support for ALTER can be seen in the following:
  132. ↑ ISO/IEC JTC 1/SC 22/WG 4 2001, § F.1.
  133. ↑ Moseley, Jay (2015년 1월 17일). “COBOL Compiler from MVT”. 2015년 7월 22일에 원본 문서에서 보존된 문서. 2015년 7월 19일에 확인함. 
  134. ↑ Dijkstra, Edsger W. (2006). “E. W. Dijkstra Archive: How do we tell truths that might hurt? (EWD498)”. University of Texas at Austin. 2017년 5월 2일에 원본 문서에서 보존된 문서. 2007년 8월 29일에 확인함. 
  135. ↑ 가 나 Riehle 1992, 125쪽.
  136. ↑ Shneiderman 1985, 349–350쪽.
  137. ↑ Coughlan, Michael (2014년 3월 16일). 《Beginning COBOL for Programmers》. Apress. 4쪽. ISBN 1430262532. 2014년 8월 13일에 확인함. 
  138. ↑ Sammet 1978b, 258쪽.
  139. ↑ Riehle 1992, 126쪽.
  140. ↑ Riehle 1992, 127쪽.
  141. ↑ Lämmel, Ralf; Verhoef, Chris (November–December 2001). “Cracking the 500-language problem” (PDF). 《IEEE Software》 18 (6): 79. doi:10.1109/52.965809. 2014년 8월 19일에 원본 문서 (PDF)에서 보존된 문서. 
  142. ↑ Garfunkel 1987, 11쪽.
  143. ↑ Garfunkel 1987, 15쪽.
  144. ↑ Raymond, Eric S. (2004년 10월 1일). “COBOL”. 《The Jargon File, version 4.4.8》. 2014년 8월 30일에 원본 문서에서 보존된 문서. 2014년 12월 13일에 확인함. 
  145. ↑ Brown 1976, 53쪽.
  146. ↑ CODASYL 1969, § II.1.1.
  147. ↑ Shneiderman 1985, 350쪽.
  148. ↑ Sammet 1961, 381쪽.
  149. ↑ 가 나 Conner 1984, ID/10쪽.
  150. ↑ Marcotty 1978, 263쪽.
  151. ↑ Conner 1984, ID/14쪽.
  152. ↑ Marcotty 1978, 266쪽.
  153. ↑ Sammet 1978b, 255쪽.
  154. ↑ CODASYL 1969, § 2.2.5.
  155. ↑ Shneiderman 1985, 348–349쪽.
  156. ↑ 가 나 다 Shneiderman 1985, 349쪽.
  157. ↑ Shneiderman 1985, 351쪽.
  158. ↑ “An interview: Cobol defender”. 《Computerworld》. 1984년 9월 10일. ID/29–ID/32쪽. ISSN 0010-4841. 2014년 6월 8일에 확인함. 
  159. ↑ “Academia needs more support to tackle the IT skills gap” (보도 자료). Micro Focus. 2013년 3월 7일. 2014년 8월 4일에 확인함. 
  160. ↑ Carr & Kizior 2003, 13쪽.
  161. ↑ Cook, Margaret M. (June 1978). Ghosh, Sakti P.; Liu, Leonard Y., 편집. “Data Base Facility for COBOL 80” (PDF) (보도 자료). Anaheim, California: AFIPS Press. 1107–1112쪽. doi:10.1109/AFIPS.1978.63. LCCN 55-44701. 2014년 9월 2일에 확인함. The earliest date that a new COBOL standard could be developed and approved is the year 1980 [...]. 
  162. ↑ “Resolutions from WG4 meeting 24 - June 26-28, 2003 Las Vegas, Nevada, USA”. 2003년 7월 11일. 1쪽. 2016년 6월 9일에 원본 문서 (doc)에서 보존된 문서. 2014년 6월 29일에 확인함. a June 2008 revision of the COBOL standard 
  163. ↑ Babcock, Charles (1986년 7월 14일). “Cobol standard add-ons flayed”. 《Computerworld》 20 (28): 1, 12. 
  164. ↑ Marcotty, Michael (1978). Wexelblat, Richard L., 편집. 《Full text of all questions submitted》. History of Programming Languages. Academic Press (1981에 출판됨). 274쪽. doi:10.1145/800025.1198371. ISBN 0127450408. (구독 필요). 
  165. ↑ This can be seen in:
  166. ↑ Coughlan, Michael (2002). “Introduction to COBOL”. 2015년 11월 8일에 원본 문서에서 보존된 문서. 2014년 2월 3일에 확인함. 

참고 문헌

[편집]

외부 링크

[편집]
위키미디어 공용에 관련된
미디어 분류가 있습니다.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=코볼&oldid=38337220"








 ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://ko.wikipedia.org/wiki/%EC%BD%94%EB%B3%BC

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy