{"title":"A VSAM PL/I interface","authors":"Brian S. Ramsey, R. Cannon","doi":"10.1145/503643.503703","DOIUrl":null,"url":null,"abstract":"The IBM Language Reference Manual for the PL/I Optimizing Compiler states that an interface for using Virtual Storage Access Method (VSAM) data sets exists. It places no restrictions on what can be done other than to say that VSAM data sets should be treated just as Indexed Sequential Access Method (ISAM) data sets. At least that is how it is supposed to work. In working with VSAM clusters and related components, however, the PL/I interface did not function as expected. A brief background on how this problem was discovered and a description of the error will be presented. In addition, the description of a new interface and its advantages and disadvantages will be presented. The system on which the development was performed is an IBM S/370-]68 running under MVS release 3.7E. Release 3.0 of the PL/I Optimizing Compiler was the subject of the work. Brian S. Ramsey is currently a cadet in the Air Force ROTC program. Approximately one year ago, he attempted to revise the cadet administration programs. At that time, the programs were designed to run with ISAM data sets, ISAM providing keyed access to the cadet records. In addition to the primary data set, two other ISAM data sets were used as inverted files to maintain secondary keys. The Virtual Storage Access Method allows the representation of an indexed sequential file, thus providing keyed and sequential access on the primary key, together with the capability to define secondary keys and to access records on those keys. By using VSAM rather than ISAM, the primary data set and the two data sets used for secondary access could be merged into a single VSAM data set. In this manner, maintenance of the directories for secondary access, until then the responsibility of the application program, would be transferred to the access method. In order to effect the transfer it was necessary to create a VSAM base cluster and two alternate indexes. After designing the initial specifications, the VSAM cluster was built and loaded. The alternate indexes were then built and related to the base cluster. The next step was to design programs to test the feasibility of using VSAM. It was during this phase that the bug was discovered. The program to test the Alternate Indexes opened the file for direct access using the following declare statement: DCL VS FILE DIRECT KEYED UPDATE ENV(VSAM); The file could not be opened. The reason given was that the Alternate Index was an organization incapable of direct keyed access. No reason could be found in the manuals for this type of error, so a small assembler language program was written to determine whether direct keyed access through an alternate index could be achieved. Using identically coded Access Control Blocks (ACBs),the program opened, used keyed access to read a record, and closed both the base cluster and one alternate index. No error occurred during this test. This experiment would seem to indicate that the PL/I interface has difficulty recognizing alternate indexes. The use of VSAM Alternate Indexes should be transparent to the user. Transparency was one of the principal reasons for creating alternate indexes. If the use is not transparent to the user, or if the user must make special allowances for the use of an alternate index, then why not just leave the alternate indes as a VSAM base cluster? When coding in assembler language, the use of alternate indexes is transparent to the programmer. This should also hold true for the higher level languages. Since PL/I did not meet this standard, the need for a better interface between VSAM and PL/I became apparent. The new interface was designed to make its use simple and similar to existing PL/I file operations. The interface could be accessed by the \"CALL\" statement in PL/I, in much the same manner as a call from PL/I to IMS. The user of this interface, though, would have a symbolic macro facility available to him to ease the coding of the subroutine calls. The macro expansion would be accomplished using the PL/I preprocessor facility. The interface was designed to consist of a series of modules that would use PL/I control blocks and structures as much as possible. The most interesting and perhaps challenging aspect of the interface was the manner in which it would handle errors. Normally, one would design a module to return a condition code indicating success or failure of the module's function. This would require a test after each subroutine call to check whether the request was satisfied or not. While this is not a bad method of checking for errors, the handling of errors by the interface would ideally be done using PL/I's own error handler. When any one of the interface I/O routines detects an error, a call is made to the interface error handler. The interface error handler then, if possible, translates the error into a PI/I oncode. Any errors which cannot be translated into PL/I on-conditions are to be translated into the ERROR on-code. Once the error has been translated, a parameter list is set up and a call is made to PL/I's error handler. This permits the","PeriodicalId":166583,"journal":{"name":"Proceedings of the 16th annual Southeast regional conference","volume":"4 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1978-04-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the 16th annual Southeast regional conference","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/503643.503703","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0
Abstract
The IBM Language Reference Manual for the PL/I Optimizing Compiler states that an interface for using Virtual Storage Access Method (VSAM) data sets exists. It places no restrictions on what can be done other than to say that VSAM data sets should be treated just as Indexed Sequential Access Method (ISAM) data sets. At least that is how it is supposed to work. In working with VSAM clusters and related components, however, the PL/I interface did not function as expected. A brief background on how this problem was discovered and a description of the error will be presented. In addition, the description of a new interface and its advantages and disadvantages will be presented. The system on which the development was performed is an IBM S/370-]68 running under MVS release 3.7E. Release 3.0 of the PL/I Optimizing Compiler was the subject of the work. Brian S. Ramsey is currently a cadet in the Air Force ROTC program. Approximately one year ago, he attempted to revise the cadet administration programs. At that time, the programs were designed to run with ISAM data sets, ISAM providing keyed access to the cadet records. In addition to the primary data set, two other ISAM data sets were used as inverted files to maintain secondary keys. The Virtual Storage Access Method allows the representation of an indexed sequential file, thus providing keyed and sequential access on the primary key, together with the capability to define secondary keys and to access records on those keys. By using VSAM rather than ISAM, the primary data set and the two data sets used for secondary access could be merged into a single VSAM data set. In this manner, maintenance of the directories for secondary access, until then the responsibility of the application program, would be transferred to the access method. In order to effect the transfer it was necessary to create a VSAM base cluster and two alternate indexes. After designing the initial specifications, the VSAM cluster was built and loaded. The alternate indexes were then built and related to the base cluster. The next step was to design programs to test the feasibility of using VSAM. It was during this phase that the bug was discovered. The program to test the Alternate Indexes opened the file for direct access using the following declare statement: DCL VS FILE DIRECT KEYED UPDATE ENV(VSAM); The file could not be opened. The reason given was that the Alternate Index was an organization incapable of direct keyed access. No reason could be found in the manuals for this type of error, so a small assembler language program was written to determine whether direct keyed access through an alternate index could be achieved. Using identically coded Access Control Blocks (ACBs),the program opened, used keyed access to read a record, and closed both the base cluster and one alternate index. No error occurred during this test. This experiment would seem to indicate that the PL/I interface has difficulty recognizing alternate indexes. The use of VSAM Alternate Indexes should be transparent to the user. Transparency was one of the principal reasons for creating alternate indexes. If the use is not transparent to the user, or if the user must make special allowances for the use of an alternate index, then why not just leave the alternate indes as a VSAM base cluster? When coding in assembler language, the use of alternate indexes is transparent to the programmer. This should also hold true for the higher level languages. Since PL/I did not meet this standard, the need for a better interface between VSAM and PL/I became apparent. The new interface was designed to make its use simple and similar to existing PL/I file operations. The interface could be accessed by the "CALL" statement in PL/I, in much the same manner as a call from PL/I to IMS. The user of this interface, though, would have a symbolic macro facility available to him to ease the coding of the subroutine calls. The macro expansion would be accomplished using the PL/I preprocessor facility. The interface was designed to consist of a series of modules that would use PL/I control blocks and structures as much as possible. The most interesting and perhaps challenging aspect of the interface was the manner in which it would handle errors. Normally, one would design a module to return a condition code indicating success or failure of the module's function. This would require a test after each subroutine call to check whether the request was satisfied or not. While this is not a bad method of checking for errors, the handling of errors by the interface would ideally be done using PL/I's own error handler. When any one of the interface I/O routines detects an error, a call is made to the interface error handler. The interface error handler then, if possible, translates the error into a PI/I oncode. Any errors which cannot be translated into PL/I on-conditions are to be translated into the ERROR on-code. Once the error has been translated, a parameter list is set up and a call is made to PL/I's error handler. This permits the