All Terrain Thinking

A Compendium of things I think are Important

Generally Speaking, Think on this...

IBM VSAM - Not quite spam, A functional explanation

Overview Structure of VSAM Master Catalog User Catalog VSAM Data Space VSAM File IDCAMS Program Summary

---

Excerpted from Operating DOS/VSE in a VM Environment by Frank Whittle
Overview	In order to access data on a disk, a programmer normally invokes an access method. By using one of the commercially available access methods the programmer is relieved of the many complex and intricate details required to store and retrieve data from disk. Some of these details include setting record size, determination of available disk space for record storage, writing data to the disk, locating data on disk and retrieving data from the disk. Without an available access method, the programmer would be required to write enormous amounts of code in each program to write and retrieve data from a disk. The importance of choosing a powerful and reliable access method must be given high priority in the field of information processing. VSAM (Virtual Storage Access Method) is a powerful product from IBM which is widely used today. VSAM allows both direct and sequential processing of both fixed and variable length data records. In an earlier chapter, the sequential access method was introduced. Although much less complex than VSAM, the sequential method only allows sequential access which means processing the stored records in succession. For example, to process the one hundredth record, one must first retrieve the first 99 records. In addition, to update a sequential file is a complex and time consuming matter as the transaction and the master records must be sorted in order and then each transaction must be recorded against the master file. The major advantage of using the VSAM access method is the ability to access the records directly. This simply means that a record can be retrieved without having to process the preceding records. In addition to this advantage, VSAM allows for a comprehensive storage protection and utilizes storage very efficiently. Many of the newer IBM disk drives will only support VSAM storage which has virtually eliminated the popular ISAM (Indexed Sequential Access Method) for direct access from many installations. To create and maintain files under VSAM, IBM supplies the Access Method Services program. This large and powerful program is executed through the IDCAMS load module. Therefore, to utilize this service program one must issue the following job step: // EXEC IDCAMS,SIZE=AUTO This program will now accept a large number of functions to allow building, printing, maintaining and deleting VSAM files. We will return to these functions shortly but first let us analyze the structure of VSAM.
Structure of VSAM
Master Catalog	The structure of VSAM evolves around four basic concepts: the master catalog, the user catalog, the data space and , of course, the file itself which is commonly referred to as a cluster. The master catalog is a required file which must be defined using the IDCAMS program. Every file which is to be used must be under the control of the master catalog. The information stored for each file allows for VSAM access to the file, password authorization and statistics for the many operations which may be performed on the file. In addition, the master catalog contains information concerning the physical environment of the VSAM files which include the type of DASD being used and the location of and allocation of available free space. This information, of course is kept current as files are expanded, reduced, created or deleted. Through the master catalog, VSAM is capable of organizing and distributing the DASD space which has been allocated. VSAM, upon request from an application program will locate, open and close a requested file and in doing so will check passwords and insure that the master catalog information is correct as it pertains to the requested file. Since the master catalog is itself a file, it must be provided the required DLBL an EXTENT statements under DOS/VSE. During IPL, the supervisor is informed of the existence of the master catalog through the CAT command and the master catalog is always assigned the system logical unit SYSCAT. The file-id and the appropriate volume containing the master catalog must be placed on the DLBL and EXTENT statements for the file. The DLBL must specify IJSYSCT as the filename and both the DLBL and EXTENT statements are normally stored in the standard label cylinder.
User Catalog	User catalogs are not required in a VSAM installation but their use is encouraged to provide better data integrity and security. The user catalogs have the same structure and contain most of the same information as the master catalog but appear at a lower level then the master catalog. When user catalogs are being used, the master catalog will point to the appropriate user catalog instead of pointing to the file. The user catalog will then point to the VSAM file. One may think of this as a three level access path. As evidenced in figure 1, the file request will pass through the master catalog on the first level, the user catalog on the second level and finally finish up on the third level at the proper file. The usefulness of implementing user catalogs is that if a user catalog gets destroyed (or partially destroyed) only the files under that catalog will be affected. Therefore, the catalog can be rebuilt without affecting the vast majority of files (and users). Likewise, if the master catalog is destroyed, the user catalogs are not affected. The benefits of implementing user catalogs in a VSAM environment obviously outweigh the additional overhead costs which include extra space and a more complex file access path.
VSAM Data Space	The area on a DASD volume which is allocated to VSAM is called the VSAM data space. This data space may occupy the entire volume or may simply occupy a portion of a specific volume. This space must be defined to the catalog through an Access Method Service command and must be define on the VTOC of the system. By defining this space to the catalog, you are giving VSAM complete control of this area. VSAM will then manage this space according to the requirements of the files when they are created. One interesting note is that the individual files will be defined in the appropriate VSAM catalog but each file will not appear on the VTOC. Instead, the name given to the area of the entire VSAM data space will appear on the VTOC. This area will, more than likely, contain many VSAM files.
VSAM File	The VSAM file or cluster is also defined through the Access Method Services program and will contain the data records supplied by the user. VSAM files can be organized by a key field in a logical sequence (key-sequenced organization), in the physical sequence in which they are entered into the file (entry-sequenced organization) or according to their relative record numbers in the file (relative-record organization). A VSAM file can be read or updated either sequentially or directly by key. Before we examine these various file organizations in more detail, let us first examine how VSAM physically stores data. The space occupied by a VSAM cluster is divided into contiguous areas called control intervals (CI). The control interval is the basic unit of data transmission under VSAM. This means that when a record is requested from a VSAM file the entire control interval which contains the requested record is transferred to main storage. Every control interval in a file is of the same length although the length can be different for different files. The programmer can choose a control interval size or may let VSAM specify it. If the programmer decides to choose the size of the control interval, he should keep in mind that the control interval must contain an integral number of physical records. Normally, the system programmer should be consulted before choosing a control interval size, otherwise let VSAM choose the size. The control intervals are grouped together to form control areas. When a file is defined the number of control intervals in a control area is specified and this number is the same for all the control areas in the file. The control area is the amount of space which VSAM will allocate when a file is enlarged. The space allocated to a file is always increased by an integral number of control areas. Figure 2 shows the relationship between files,control areas and control intervals. Let us now return to an examination of the various file organizations attainable under VSAM. The entry-sequenced files (ESDS for entry sequence data set) are organized according to their entry in the file. Therefore, records entered yesterday will be stored physically before the records entered today. The entry sequence file is accessed sequentially and , in general cannot be accessed directly unless the user knows the displacement of the record from the beginning of the file (This is commonly referred to as the RBA or relative byte address. The first record in a file has a RBA of 0 and the second record has an RBA equal to the length of the first record. This,by the way,is how VSAM eventually locates records, however, calculating the RBA is rarely done by a programmer.). An ESDS file is quite restrictive in that no keys are recognized, the length of the records are fixed, and records cannot be physically deleted. In addition, free space is not distributed throughout the file and all new records must be placed at the physical end of the file. Since no direct access is available through the use of a key, no index is required. In COBOL an ESDS file is described through the following select clause: SELECT file-name ASSIGN to SYSnnn[-class][-device]-AS[-name] ORGANIZATION IS SEQUENTIAL... Another file organization which is available under VSAM is the relative record organization. The relative-record files (RRDS) are stored according to their relative position in the file. The file can be thought of as a set of mailboxes all of the same size. Each mailbox is assigned a relative record number and is capable of storing only one record with that same number. The amount of space occupied by a RRDS file is fixed since the area for the record areas (mailboxes) must be set aside even if it is not occupied at present.Both sequential and direct access is supported under the RSDS organization and one may update records, delete records and add records into available record areas. The major advantage of this organization is that it allows direct access without the need for an index. The disadvantages, however, are quite serious in that the major disadvantage is that space must be set aside for records even when those records are not presently being stored. Additional restraints upon the RSDS organization is that it does not support variable length records because of the fixed size record areas and it does not support access by different keys (commonly referred to as alternate indexes). In COBOL, the relative record file is described through the following select clause: SELECT file-name ASSIGN to SYSnnn[-class][-device]-DA[-name] ORGANIZATION IS RELATIVE... The third type of organization is the key-sequence organization. This is probably the most popular and powerful organization available under VSAM. The key-sequenced files (KSDS) contain a key field in each record. The programmer must choose the key field and insure that it is unique. VSAM will then organize the file according to the ascending sequence of this field. Depending on the application, the key field will, of course, be different. Some examples of key fields include social security numbers, part numbers, student numbers... Access to a key-sequenced file can either be sequential or direct based upon the key value. Adding or deleting records under this organization is particularly efficient since at the time of file definition free space can be distributed throughout the file. This is a major advantage over previous direct access methods (ISAM in particular) in that no serious performance degradation results and the file does not have to be frequently reorganized when records are added, deleted, lengthened or shortened. Under this organization, variable length records are supported and space is reclaimed when records are shortened or deleted and this space becomes available to the file. The KSDS organization does, however, requires an index.The index is automatically built when a KSDS file is defined and the index will store the keys in a compressed form to save space. A cluster in KSDS organization is defined as both the index and the data area of the file. The index correlates the key field to the appropriate relative byte address of the record (remember RBA?). Some restrictions do exist in the use of the key field. The length and the relative position of the key must be the same for every record in the file and the programmer,obviously, cannot change the value of the key field. It should be noted that the index structure under VSAM is quite complex and that the index is itself file which consists of a number of levels. As shown in figure 3, each level of the index contains an index record which contain one or more index pointers. These pointers point to the location of the records in the next lower level. The lowest level is commonly called the sequence set. There is one sequence set for each control area and its' pointers point to the control intervals in that control area. The higher levels of the index are normally referred to as the index set. In addition to having only one prime index, it is possible to define an alternate index. With an alternate index the file can be accessed by a different key. This allows multiple users to access the file with different keys without having multiple copies of the file. A key-sequenced file is described in a COBOL program with the following SELECT clause: SELECT file-name ASSIGN TO SYSnnn[-class][-device][-name] ORGANIZATION IS INDEXED... RECORD KEY IS...
IDCAMS Program	The access method services program IDCAMS allows the user to determine and manage the VSAM environment. Some of the services which are performed through the IDCAMS program include: * Defining catalogs * Defining files,catalogs... * Deleting files,catalogs... * Listing files * Converting files to VSAM * Creating backup files Once again, the IDCAMS program is executed through the statement: // EXEC IDCAMS,SIZE=AUTO Notice that the size parameter must be included to allow for space required by VSAM in the partition in which it runs. Through IDCAMS, there are two types of commands which may be utilized. One type of command are the FUNCTIONAL commands which request some file management action to be accomplished. Some of these commands include DEFINE, DELETE, LISTCAT, PRINT,VERIFY and REPRO. The second type of command available under IDCAMS is the MODAL commands. These commands are used to specify options, delimit functional command sequences, and test condition codes. Some of these MODAL commands include IF,THEN,ELSE,DO,END,SET and PARM. The general structure of a command under IDCAMS is verb parameters terminator It is vital that the proper language syntax is utilized in constructing the IDCAMS commands. This syntax is straight forward and the reader is encouraged to grasp the basic syntax requirements before attempting to utilize VSAM. The following points summarize the basic syntax of the language: Verbs must be separated from the parameters by at least one separator A separator is a blank or a comment A comment is any string of characters preceded by /* and followed by */ Commands must lie between column 2 and column 72 To continue a command to the next line a hyphen must be placed before column 73 and it must be the last non-blank character on that line A terminator indicates the end of the command A terminator can be a semicolon or simply the absence of the continuation character (the hyphen). If a semicolon is used as a terminator, all the characters to the right of the semicolon are ignored. Let us now try to utilize this syntax and cover some basic functional commands. The first step in creating a VSAM file system is to define the master catalog. We should note that by defining the master catalog, we are also defining the VSAM space. The following command is used to define the master catalog: DEFINE MASTERCATALOG (BLOCKS(number) FILE(name) NAME(entryname) VOLUME(volser) [MASTERPW(password)] [UPDATEPW(password)}] [FOR(days)|TO(date) where: BLOCKS- specifies the number of blocks available to the master catalog FILE- name must correspond to the file name of the DLBL statement. For the mastercatalog it must be IJSYSCT. NAME- entryname assigns a name to the mastercatalog. It may consist of from 1 - 44 alphanumeric characters. However,every eight characters must be separated by a period. This name will match the file-id of the corresponding DLBL statement. VOLUME- volser indicates which volume will contain the mastercatalog. This parameter can be from one to six characters. MASTERPW- one to eight character password which will allow all operations to be performed on the catalog. UPDATEPW- this password will allow only read and write access to the catalog FOR|TO- specifies either the number of days which the catalog is to be retained or the date to which the catalog must be retained. The following is an example of a jobstream to define a mastercatalog. Note that the DLBL and EXTENT statements, although included here, are normally kept on the standard label area. // JOB DEFMAST // DLBL IJSYSCT,'this.is.my.master,catalog',,VSAM // EXTENT SYSCAT,DAP000,1,0,500,200 // EXEC IDCAMS,AUTO DEFINE MASTERCATALOG- (NAME(this.is.my.master.catalog)- FILE(IJSYSCT)- VOLUME(DAP000)- BLOCKS(100)- MASTERPW(master)- FOR(120)) /* /& To define the space which is to be managed by VSAM, we once again use the DEFINE command. The format of the command is: DEFINE SPACE (BLOCKS(number) FILE(name) VOLUMES(volser1[volser2..])) [CATALOG(catname[/password]]) where: BLOCKS - number of blocks allocated to the space FILE - name associated with the filename on the DLBL statement VOLUMES- lists the volume serial numbers of the volumes to be used CATALOG- identifies the catalog to which the space is defined Assuming that the DLBL and extent statements for the master catalog are already on the standard label area, the following is a sample jobstream which will define space for the previously created master catalog. // JOB DEFSPACE // ASSGN SYS007,240 // DLBL AREA,,,VSAM // EXTENT SYS007,DAP000,1,0,200,400 // EXEC IDCAMS,SIZE=AUTO DEFINE SPACE - (FILE(AREA) - VOLUMES(DAP000)- BLOCKS(400)- CATALOG(THIS.IS.MY.CATALOG/MASTER) We now have a master catalog and 400 blocks of space defined for this catalog on volume DAP000. It should be noted that the above jobs are normally only run once and will probably already be implemented in an organization. One should check with the system programmer to be sure that the procedure has been accomplished and to get the name of the master catalog and the extents of the defined space. Also, the systems programmer should inform you of all naming conventions in place. It may occur that the user will require a usercatalog. If this is the case, the DEFINE command can be used to define the USERCATALOG. The format of the command is similar to the DEFINE MASTERCATALOG command except that a master catalog must already be defined. The format for the command to define a user catalog is: DEFINE USERCATALOG (BLOCKS(number) FILE(dname) NAME(entryname) VOLUME(volser) [UPDATEPW(password)] [MASTERPW(password)]) [CATALOG(name of master catalog[/password])] The parameters are the same as specified for the definition of the master catalog except for the CATALOG entry which is used to supply the name of the master catalog. The application programmer will normally be responsible for defining his/her own entries in the master catalog. The DEFINE CLUSTER command is utilized for this purpose. DEFINE CLUSTER (NAME(entryname) BLOCKS(number) VOLUMES(volser) RECORDSIZE(average maximum) [INDEXED|NONINDEXED|NUMBERED] [FREESPACE(cipercent capercent)] [KEYS(length offset)] [READPW(password)] [FOR(days)|TO(date)] [UPDATEPW(password)]) [CATALOG(catname[/password] NAME - entryname is the name of the cluster to be defined. It follows the same naming restrictions as the catalog name. This name is also in the file-id field of the DLBL statement (when one is required) BLOCKS - specifies the number of blocks for the cluster INDEXED|NONINDEXED|NUMBERED - for key-sequenced files the INDEXED option is chosen, for entry-sequenced files the NONINDEXED option and for relative-record files the NUMBERED option is required. The default is INDEXED. FREESPACE - specifies the amount (in percent) of free space per control interval (cipercent) and per control area (capercent) for a key-sequenced file. The default is 0 percent. KEYS - this parameter specifies the size of the key field (length) and the offset of the key from the beginning of the record. Allowable key lengths are from 1 to 255 bytes. This parameter is only used for key-sequenced files. READPW - read level password UPDATEPW - update level password RECORDSIZE - specifies the average length of the logical records in the file (av) and the maximum length of the records (max). VOLUMES - this parameter specifies the volumes to contain the cluster CATALOG - identifies the catalog under which this file will be defined FOR|TO - specifies the amount of time for which the file is to be retained See the define CATALOG command for more details. The default is 0 retention days. A sample jobstream to define a cluster is: // JOB DEFCLUST // EXEC IDCAMS,SIZE=AUTO DEFINE CLUSTER- (NAME(FIRST.SAMPLE)- VOLUMES(DAP000)- FREESPACE(15 3)- BLOCKS(60)- INDEXED- KEYS(9 10)- RECORDSIZE (25 25)- CATALOG(THIS.IS.MY.CATALOG/MASTER) This jobstream will define a cluster under our previously defined catalog. It will occupy 60 blocks, be indexed and the key field will be 9 characters long and reside at an offset of 10 characters from the beginning of the record.Notice that the DLBL and EXTENT statements for the master catalog were not included since they are assumed to be on the standard label area. Also, notice that no DLBL or EXTENT statements were required for the cluster since only entries in the master catalog were created. It is important to note that no records were placed in the file with this jobstream. There are two commands which can be used to print under VSAM. The LISTCAT command is used to display entries in a catalog and the PRINT command is used to display records in a file. The format of the LISTCAT command is: LISTCAT [CLUSTER|SPACE] [CATALOG(catname[/password])] [ENTRIES(entryname[/password])] [NAME|ALL] CLUSTER|SPACE - specifies either the names of all the clusters in the catalog are to be listed or entries for all volumes containing data space are to be listed. CATALOG - specifies the name of the catalog (see define space). ENTRIES - lists information for cluster specifies in entryname parameter. NAME|ALL - Name option specifies the name and type of all entries are to be listed. The ALL option lists all the information in the catalog. The following is a sample jobstream using the LISTCAT command: // JOB LISTALL // EXEC IDCAMS,SIZE=AUTO LISTCAT ENTRIES(FIRST.SAMPLE)- ALL /* /& The above job will list all the information pertaining to the file first.sample. The PRINT command is used to print the contents of the VSAM files and is somewhat more complex than the LISTCAT command. The format of the PRINT command is: PRINT INFILE (dname[/password]) [CHARACTER|DUMP|HEX] [FROMADDRESS(address)|FROMKEY(key)|FROMNUMBER(number)|SKIP(COUNT)] [TOADDRESS(address)|TOKEY(key)|TONUMBER(number)|COUNT(count)] INFILE - dname specifies the filename which appears on the DLBL statement CHARACTER|DUMP|HEX - determines the format of the output. Character implies that each byte be printed as a character, dump signifies that each byte be printed both as a character and in hexidecimal and hex indicates that each byte only be printed in hexidecimal. The default is DUMP. FROMADDRESS (address)| FROMKEY(key)| FROMNUMBER(number)|SKIP(count) - this parameter is used to specify the first record in the file to be printed. The FROMADDRESS option is chosen for KSDS or ESDS files. It refers to the RBA of the first record to be printed. The FROMKEY option is only used for KSDS files. It specifies the key of the first record to be printed. The listing will commence with the first record encountered whose key begins with the characters specified. The FROMNUMBER option is used with RRDS files and refers to the relative-record number of the first record to be printed. Finally, the SKIP option is used to specify the number of records to be skipped before the first record is printed. This option can be used with all file organizations. The default, if nothing is specified, is that the listing will commence with the first record. TOADDRESS(address)|TOKEY(key) TONUMBER(number)|COUNT(count) - this parameter is used to specify the last record to be printed from the file. The parameters are the same for the FROM options previously stated with one exception. The COUNT option specifies the number of records to be printed. The default is that the listing will terminate with the last record in the file. An example of the PRINT command is: // JOB LIST // DLBL MYFILE,'FIRST.SAMPLE',,VSAM // EXEC IDCAMS,SIZE=AUTO PRINT INFILE(MYFILE)- CHARACTER- SKIP(10)- COUNT(100) /* /& Another command available under VSAM is the DELETE command. The DELETE command can be used to delete mastercatalogs, usercatalogs, clusters, and files. Caution is of course urged when using this command because of the obvious power. The format of the DELETE command is: DELETE (entryname[/password][entryname[/password]...]|volser]) [CLUSTER|MASTERCATALOG|SPACE|USERCATALOG] [CATALOG(catname[/password])] [PURGE|NOPURGE] [FILE(dname)]) entryname - specifies the name of the object to be deleted. This object may be a catalog or a file. More than one file may be deleted at a time, however, only one catalog at a time may be deleted. When a cluster is deleted, all the components associated with the cluster are deleted. The password may be required if the object was defined with a password requirement. volser - the volume serial number is required when deleting a data space. All the empty data spaces on the specified volume will be deleted. CLUSTER|MASTERCATALOG|SPACE|USERCATALOG - specifies the type of object which is to be deleted. Only one type can be deleted at a time. CATALOG - This specifies the catalog under which the objects to be deleted are presently defined. The dname entry is the same as the filename of the DLBL statement which identifies the objects to be deleted. The dname entry is not required for deletion of the mastercatalog. The default is the deletion of the MASTERCATALOG. PURGE|NOPURGE - the PURGE option specifies that the object will be deleted regardless of the retention date. The NOPURGE option will not allow the deletion to occur unless the retention date has expired. NOPURGE is the default. FILE - the dname entry is the filename on the DLBL statement. The DLBL statement is only required when deleting VSAM spaces. An example of a jobstream which will delete all the entries in a file and the associated index is: // JOB DELETE // EXEC IDCAMS,SIZE=AUTO DELETE FIRST.SAMPLE- CLUSTER- PURGE /* /& Sometimes a problem with the system or an errant program may disrupt the information in the catalog for a specific file. The VERIFY command exists to correct the information so that it will actually reflect the proper file structure. The format of the VERIFY command is: VERIFY FILE(dname[/password]) where dname represents the filename on the DLBL statement which identifies the object to be verified. The master password may be required if the file was defined with this restriction. A sample jobstream to verify a file is: // JOB VERFILE // DLBL MYFILE,'FIRST.SAMPLE',,VSAM // EXEC IDCAMS,SIZE=AUTO VERIFY FILE(MYFILE) /* /& The last command we will look at in VSAM is the REPRO command. The REPRO command is quite useful in that it allows one to copy files and create backup copies of important files. It will allow the user to copy files from VSAM to VSAM, ISAM to VSAM, VSAM to SAM, ISAM to SAM, SAM to VSAM, SAM to SAM. In addition, it can merge two VSAM files together. The format of the REPRO command is: REPRO INFILE ([dname[,ENVIRONMENT(subparameters)]]|[dname[/password]]) OUTFILE(dname[,ENVIRONMENT(subparameters)]|[dname[/password]]) [REPLACE|NOREPLACE] INFILE (dname[/password] - this option is used when the input file is a VSAM file. The entry dname matches the DLBL statement for the file to be copied. INFILE (dname,ENVIRONMENT(subparameters) - this option is required when the file to be copied is not a VSAM file. The subparameters are those listed below: RECORDFORMAT(format) - this is a required parameter for a non-VSAM file. The format entry must be chosen from : VALUE MEANING FIXUNB Fixed,unblocked FIXBLK Fixed,blocked VARUNB Variable,unblocked VARBLK Variable,blocked SPNUNB Variable spanned,unblocked SPNBLK Variable spanned, blocked UNDEF Undefined BLOCKSIZE(size) - indicates the blocksize for non-VSAM files. RECORDSIZE(size) - indicates the length of the record in bytes. The default is that the record size is equal to the block size for FIXUNB, FIXBLK and UNDEF files. The record size is equal to blocksize minus 4 for VARUNB, VARBLK, SPNUNB and SPNBLK files. OUTFILE(dname[/password]) - is used for output files which are VSAM. (see INFILE for details). OUTFILE(dname,ENVIRONMENT(subparameters) - is used for non-VSAM output files. Subparameters are the same as for INFILE. REPLACE|NOREPLACE - indicates whether an input record which has has a same key will replace a record in the output file with the same key. For relative-record files the record with the same relative record number will replace the output record if the REPLACE option is chosen. The default is NOREPLACE. A sample jobstream which will back up a VSAM file is: // JOB BACK // DLBL INORIG,'FIRST.SAMPLE',,VSAM // DLBL OUTBACK,'SECOND.SAMPLE',,VSAM // EXEC IDCAMS,SIZE=AUTO REPRO INFILE(INORIG)- OUTFILE(OUTBACK) /* /& This chapter has been intended as an overview to utilizing VSAM. It has presented the major topics of VSAM but it is not intended to be a complete reference. The reader is strongly encouraged to have access to the IBM VSAM manuals listed in the back of this text. VSAM is a large and complex subject and to study it in detail could easily require a separate book. The jobstreams provided in the chapter are only samples, however, they have been carefully selected because they are similar to the jobstreams which will be run many times by a user of VSAM.
Summary	CHAPTER SUMMARY This chapter described the Virtual Storage Access Method under DOS/VSE. The concepts behind VSAM processing were discussed followed by a discussion of the three types of files available under VSAM: ESDS, RSDS and KSDS. The differences as well as the similarities between the three were discussed and the advantages of each were analyzed. In addition to discussing these file types, the first part of the chapter introduced the basic structures in VSAM including the Master Catalog, the User Catalog and the Cluster. The reader was then provided an in-depth and comprehensive coverage of the processing language which supports VSAM and the various functions which can be performed. Each statement was analyzed individually and all the available options and parameters were presented. Numerous jobstreams were included as samples which utilized the statements. After completing the chapter, the reader should be able to define, utilize, and delete any structure under VSAM. In addition to discussing the statements, the chapter also presented all the necessary JCL statements which are required to use VSAM under DOS and it examined the file handling changes which occur in a COBOL program in order for it to use VSAM.

Prior | Tell us what you think | Next

Add to Your Social Bookmarks: Del.icio.us Digg Furl Reddit Simpy Spurl Y! MyWeb - Netscape - StumbleUpon StumbleUpon