Access intents

 

When a program opens a file, it must specify how it intends to work with the records in the file: read, add, update, delete, or a combination of these.

Of course, to successfully perform these operations, the job, user or both running the program must have the corresponding data authorities. The iSeries™ server does not check to make sure all data authorities exist when the file is opened, but it does check for each required data authority when the corresponding I/O operation is done using the file. The System/36™ does check these data authorities at open time; therefore, a program may no longer work using a remote file on a System/36, even though the requester's data authorities to the remote file are the same as for a local file (which will work).

For example, assume that a program is used by two groups of users on an iSeries server to access the same local iSeries file. Group A has only *READ authority, while group B has *READ, *ADD, and *UPDATE. The program always opens the file for *READ, *ADD, and *UPDATE. But it has a read only logic path that is used when a member of group A calls the program. In this way, no authority exceptions are encountered, even though exceptions would be created if members of group A attempted to add or update records. Now, if this program is redirected to a remote System/36 file to which members of both user groups have the same data authorities as they had to the local iSeries file, the program might not work for members of group A. This is because the System/36 may reject requests to open the file when the requester does not have data authorities matching those specified in the access intent list accompanying the open request.

 

Parent topic:

Work with access methods for DDM