Cobol到Java翻译中的数据类型转换方法

将Cobol代码迁移到新的平台，如Java是减轻Cobol代码维护负担的一个有效方法．怎样将Cobol数据平滑迁移到新平台则是必须解决的基本问题之一．以前的大部分研究工作都直接将Cob01数据映射到现代程序设计语言中的基本数据类型，比如int，float等．但是，这种简单映射并不能保持原来的Cobol语义，从而导致目标码并不能与原来的代码运行一致．首先利用数据抽象技术对Cobol数据进行初步建模，在此基础上进一步提出了一个纯Java的功能等价的封装方法，可以有效地将Cobol数据描述映射到Java类型系统．该方法已经在一个Cobol2Java翻译系统——C2J翻译器中得到实现，并且应用于一个近400万行的真实银行商用系统．实验结果表明，此方法可以在保持功能等价的情况下，将Cobol数据无需手工干预地迁移到Java平台．     

The programming language standards scene, ten years on Paper 4: Cobol

This paper, one of a simultaneously published set on ten years of activity in programming language standards, describes the developments in standardization of the programming language Cobol which have taken place in the period 1983–1993.     

自动化的Cobol 2 Java遗产代码迁移技术

随着下一代网格环境的来临,如何将遗产代码迁移到新的平台成为一个亟待解决的问题,该文提出了一种将cobol源代码自动地,功能等价地迁移到Java平台的方法。     

Array handling in cobol compilers

Since Cobol is essentially a byte-oriented language, certain practical problems arise when implementing it on a word-oriented machine. The particular problem of handling arrays with SYNCHRONIZED clauses is discussed here and a method put forward for solving it.     

遗产代码迁移中的用户界面自动转换技术

随着Internet计算技术的迅速发展,将遗产系统迁移到Web平台逐渐成为一种必需.传统的遗产代码通常使用字符终端界面,它与Web图形界面在界面显示和用户交互方面都有着显著的不同.本文实现了一种基于停止等待协议的方法可以将这种字符界面自动化地迁移到Web图形界面.实验表明,此方法可以显著地增加整个转换过程的自动化程度.     

Cobol minefield detection

In Cobol, procedures can be programmed in ways that lead to unexpected behaviour and reduced portability. This behaviour is recognized as so‐called ‘mines’: programming practices containing hidden dangers and requiring extreme caution. Cobol mines can be created intentionally or by a programming error, and can be tripped at an unforeseen moment. This leads to minefields in source code with unseen hazards, which complicate understanding and maintenance, and which can lead to costly breakdowns of business critical software systems. We discuss Cobol mines and the dangers that come with them, having implemented a mine detector for Cobol. Our detector was deployed in an industrial situation, and a number of minefields were found in production systems. By restructuring a complex legacy application, we argue that code restructuring can be used to combat minefields. Copyright © 2006 John Wiley & Sons, Ltd.     

The Amsterdam Toolkit for Language Archaeology

GRK — the Grammar Recovery Kit — illustrates options for automation and corresponding tool support in the context of developing quality language references that readily cater for the derivation of parsers.GRK provides the proof-of-concept for two notions: (i) semi-automatic grammar recovery; (ii) language-reference re-engineering. GRK's support for semi-automatic grammar recovery means that GRK can be used to obtain a relatively correct and complete as well as implementable grammar from a language reference. GRK's support for language-reference re-engineering means that GRK can be used to update the original language reference such that it reflects the completed and corrected grammar knowledge.As of today, GRK is particularly fit for Cobol archaeology, more specifically for IBM's VS Cobol II. That is, GRK offers a fully mechanised process, where IBM's reference is used as an input, and the output is a transformed language reference whose grammar portions are correct and complete. (The recovery required several hundreds of simple transformation steps in order to deliver a grammar that is fit for parser derivation.) As a byproduct, GRK also generates a slow, Prolog-based parser. Via export to GRK's sibling, GDK (the Grammar Deployment Kit), a reasonably fast, btyacc-based parser can be generated as well. Both parsers accept all of the VS Cobol II code that is at our avail (several millions of lines of code).     

A comparison of Cobol, Fortran, PL-I and Spitbol

Spitbol, the compiler version of the symbol manipulation language Snobol 4, is compared with the well-known higher-level languages of Cobol, Fortran and PL-I. An algorithm for searching and insertion into a binary tree was chosen for a comparison standard and programmed in each language. Development and computer costs were then compared for the four languages. Although a single comparison does not prove one language superior to another, this comparison does suggest that Spitbol should at least be considered when choosing a programming language for non-numeric applications.