When VSAM file is empty and a read is attempted, under 6.4 status code 116 is returned if PUT follows, otherwise 160 is returned. Release 11.6 always returns 160. Upgrade compares of existing applications fail.
When coding a GET statement without coding a PUT within the same program, if the ESDS file is empty, both 6.4 and 11.6 return a VSAM RC=160. This matches what the IBM documentation says is the VSAM return code for an empty file. An interesting fact here is that the 160 is actually returned during OPEN processing and really has nothing to do with a GET or PUT statement. This actually highlights one of the architectural differences between 6.4 and 11.6 in that 6.4 did an OPEN for all defined files without a DEFER parameter at the start of a JOB activity and 11.6 only opens those files actually used within the JOB activity and does the OPEN at the first I/O statement. As an aside, with an empty VSAM file, Easytrieve 11.6 sets the file status to end-of-file so an “IF EOF file-name” returns TRUE. That behavior does not occur within 6.4.
When a GET and a PUT are used within the same program in 6.4, the GET statement returns a code of 116 which basically says the file isn’t opened which makes some sense since the OPEN really occurred at the start of the JOB activity. With the difference being when the file is actually opened, 11.6 returns the real result of the OPEN as the return code for the GET (e.g. RC=160).
Creating a fix to return 160 in all cases for 6.4 would adversely affect existing compiled programs so will not be created and application will be changed to check for status non-zero or 160.