"Peter Smithson" <[log in to unmask]> wrote: > In article <[log in to unmask]>, [log in to unmask] > says... > > > I strongly discourage the use of the COBOL intrinsics (the old "CK" > > procedures). Do not use them unless you have a really good reason. > > Why? Several reasons: 1. The "CK" procedures were a temporary solution created back in the 1970s to allow the use of KSAM/3000 from the old HP COBOL/3000 product, which did not implement COBOL's "Indexed I-O" module. That was before HP COBOL II existed. COBOL/3000 itself has been obsolete for many years. 2. HP discourages the use of the "CK" procedures. They are still documented in Appendix A of the "Using KSAM XL" manual, but note this wording: "COBOL compilers (COBOL 68 and earlier) required special intrinsics to access keyed files. The following intrinsics are provided only for the maintenance of COBOL 68 or earlier COBOL programs using KSAM structures. Note. Do not use these intrinsics for new programming. Current COBOL file access modules provide KSAM file access." 3. Access to KSAM using the standard COBOL statements provided by HP COBOL II/iX has been tested very thoroughly. Before each release of MPE/iX, and before the release of each power patch, the compiler and run time-libraries are tested against the COBOL Compiler Validation Suite, as well as a regression test suite maintained by HP. 4. The COBOL II/iX compiler is still supported. When there are changes in MPE/iX that might affect COBOL, for example the recent introduction of KSAM64, the compiler is tested against those changes and modified as necessary. (Yes, COBOL II/iX was updated to provide support for KSAM64 files.) 5. If you avoid using extensions to the standard (like allowing duplicates on the prime record key), accessing KSAM files using the standard COBOL statements is highly portable. The "CK" procedures are not. 6. I have this general philosophy. If there are two ways of doing something, and one method has its syntax and semantics thoroughly specified by an ANSI or ISO standard, and is highly portable, whereas the other method is home-grown, less thoroughly specified, and non-portable, you should have a good reason to choose the nonstandard approach. In the case of the "CK" procedures, a good reason would be if you have lots of ancient COBOL programs that already use them, and you have no intention of porting those programs to another platform. Other than that case, I'm hard pressed to think of a decent reason to use them. Walter * To join/leave the list, search archives, change list settings, * * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *