On the performance of COBOL programs in large vs. mini computers

McIntyre

1989

CPU processing speed is rapidly increasing on PCs, resulting in a widening gap between disk access and CPU speed. The performance of three common disk caching systems are examined in an effort to determine a technique for reducing the gap. RAM Disk DOS 3.3 provides a device driver named VDISK that allows some of the memory to be used as a simulated disk drive. While this kind of RAM disk has several operational disadvantages, it is a useful comparison tool since VDISK implements a zero-wait disk with no seek 246

Section: Discussionmentioning

confidence: 99%

Caching and other disk access avoidance techniques on personal computers

McIntyre

1989

“…The reason for the worsening factor as file size increases could be the slow seek times on the PC AT hard disk: Schoeffler and Pechura (2] have shown that, as files get larger, the average random access time also increases since more cylinder boundaries have to be crossed. The PC AT disk is at a distinct disadvantage when it comes to crossing cylinder boundaries: Average seek time is 52 ms on the PC AT disk versus 25 ms on the mainframe.…”

Section: Input/outputmentioning

confidence: 99%

COBOL on a PC: a new perspective on a language and its performance

1987

Self Cite

A comparison of Cobol performance on the PC AT Enhanced versus an IBM 370 mainframe suggests that high-quality PC compiler implementations-combined with the new language features of the Cobol 85 Standardare improving the PC environment for Cobol to the point where serious applications can now be developed and debugged on the PC, either to be run on the PC itself or for eventual uploading to a mainframe.

Cobol vs. PL/1

1984

An analysis of execution time performance of Cobol vs. PL/1 code-as generated by two compilers and tested by a benchmark written originally in Cobol-provides insights into the relative complexity and shape of their corresponding language functions. COBOL VS. PLI1: SOME PERFORMANCE COMPARISONS PAUL J. JALICSThe benchmark program was implemented in both languages and written so as to use identical data types and language facilities where they exist and close approximations elsewhere. Measured results from eleven separate tests were then used to evaluate the relative merits of code generated for each language in that particular area. The results in some cases were quite surprising and required the running of additional experiments to explain the outcome.The original benchmark was written in Cobol and is called BNCl. Subsequently, three PL/1 versions were created: BNC6, BNC7 and BNC8. BNC6 is the original translation; Cobol COMP-3 items were interpreted as PIC '9' items and PERFORMS as PROCEDURE calls. BNC7 interprets Cobol COMP-3 items as FIXED DECI-MAL and enumerates multiple occurrences of sections of code PERFORMed in Cobol rather than use PROCE-DURES. Finally, BNC8 is similar to BNC7 but uses PROCEDURE calls to implement PERFORM. BNC6 can be thought of as a Cobol programmer's conservative translation whereas BNC7 and BNC8 are translations more favorable to PL/1. In all three PL/1 versions, data-items were translated exactly wherever possible, e.g., COMP to FIXED BINARY, PIC to PIC, etc.The benchmark breaks down into 11 separate tests each of which is timed separately using an assembler © 1984 ACM 0001-0782/84/0300-0216 7511