|
  
SafeAccess Operation
This section discusses how SafeAccess works. Understanding how SafeAccess works will enable you to take full advantage of what SFS can offer your installation. It can be very costly to migrate to SFS, primarily due to the application changes that are necessary. These changes are due to the fact that many of the access methods (LINK, ACCESS, DETACH, QUERY DISK, etc.) either do not apply when data resides in SFS, or have very different inputs and outputs when the data is in SFS.
Compare, for example, LINKing and ACCESSing a minidisk with the single step of ACCESSing an SFS directory.
* LINK and ACCESS a minidisk:
cp link maint 190 490 RR
Ready;
acc 490 t
DMSACP723I T (490) R/O
Ready;
* ACCESS an SFS Directory:
access safepool:hall.temp z
DMSACR723I Z (SAFEPOOL:HALL.TEMP) R/O
Ready;
Or compare the output of a QUERY DISK command from a minidisk with one from SFS:
* File mode A is a minidisk:
query disk a
LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL
HALL 191 A R/W 25 3380 4096 29 215-06 3535 3750
Ready;
* File mode G is an SFS directory
query disk g
LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL
- DIR G R/O - - 4096 74 - - -
Ready;
* Now we're better off with QUERY ACCESSED:
query accessed z
Mode Stat Files Vdev Label/Directory
Z R/O 69 DIR TGIB:HALL.TEMP
Ready;
Both of these examples illustrate how applications have to be updated to use different procedures for gaining access to data or obtaining information about accessed data. During an SFS migration, you need to update your applications to use these different commands and expect different outputs. But what if, instead, we could change the interfaces so that applications could continue to LINK and ACCESS data that now resides in SFS?
SafeAccess is designed to allow users and applications to use existing minidisk access methods to obtain access to data in SFS and to get responses from their access attempts and queries that are in a minidisk format. You tell SafeAccess, either through the SafeAccess migration facility or via the SafeAccess ADD command, that a particular minidisk is now in SFS. This includes providing the userid/virtual address of the minidisk, the SFS directory that will contain the data, and all of the minidisk attributes that an application would expect for the minidisk when a QUERY is issued against the minidisk. SafeAccess maintains a database of SACDISKs, SACLINKs, and SDEVs. From this database, it can produce all of the information required to fill in, for example, the output from a QUERY DISK command.
SafeAccess uses CP and CMS Interceptions to modify command behavior. Chapters 3 and 4 discuss how CP and CMS Interceptions work, which commands and functions are modified, what the modifications are, and how they interact to eliminate application changes during an SFS migration. CP and CMS Interceptions work together. Both must be in place to achieve the desired behavioral changes in minidisk access methods. SafeAccess is used to migrate CMS data from minidisks to SFS and, of course, will only work with CMS data that is accessed with CMS methods. CP interceptions are used to create, query and delete SDEVs (although the applications "think" that they are creating, querying, and deleting VDEVs). CMS Interceptions are used to provide CMS access, query, listfile, and release of SDEVs (although the applications "think" that they are accessing, querying, and releasing VDEVs). CP Interceptions hide the fact that a virtual minidisk doesn't exist (and is now in SFS) while CMS Interceptions hide the fact that an SFS Directory has been accessed when the application "thinks" that it has a minidisk accessed.
Hypothetical example of a session involving a SACDISK.
In this example we assume that OLDAPP 200 was a minidisk that contained OLDAPP's code and data and that users would use the OLDAPP EXEC to gain access to and use the services of OLDAPP. We also assume that OLDAPP 200 has been migrated to SFS with SafeAccess and now resides in the SFS Directory: OURPOOL:OLDAPP.SACDISKS.SD200. and that file pool OURPOOL is controlled by SafeSFS.
- User JILL requires the use of OLDAPP. She issues the OLDAPP command. Perhaps it resides on the Y-Disk, or a copy that she has on her A-Disk that she modified for some reason. The point here is that she uses the same application that she always has, even though the data is now in SFS.
- OLDAPP issues a CP LINK OLDAPP 200 500 RR.
SafeAccess intercepts the LINK command and asks the SafeAccess server to determine if JILL is allowed to have READ access OURPOOL:OLDAPP.SACDISKS.SD200.
If JILL can only get access by supplying a password, then she will be prompted for the password and password checking will be enforced.
If access is allowed, SafeAccess creates an SDEV in JILL's virtual machine that represents a minidisk linked at 500.
If access is not allowed, the LINK command would generate the appropriate link failed response and return code, which would allow OLDAPP to do whatever error recovery it normally does when a user isn't allowed access.
Note that if JILL has SFS Write authorization, but issued a R/O link, SafeSFS will change JILL's authorization to this directory to READ while she has it actively linked.
- Assuming that the LINK completed successfully, OLDAPP will likely ACCESS the minidisk at some point. Assume that it issues ACCESS 500 P. SafeAccess intercepts the ACCESS command, determines that the device is an SDEV and translates the ACCESS 500 P command into the ACCESS OLDAPP.SACDISKS.SD200. P command. The ACCESS OLDAPP.SACDISKS.SD200. P command is then processed by CMS.
SafeAccess has already enforced access control, so there is no danger that the ACCESS will fail due to not being authorized. That concern was handled back at LINK time. This is important to note because applications written for LINK/ACCESS usually have "not authorized" error handling after the LINK command, not after the ACCESS command.
- OLDAPP does its job, interacting with the data on the simulated minidisk (now an SFS directory).
- When the application completes it releases and detaches the disk. SafeAccess intercepts these commands and updates the access rule in SFS and removes the SDEV.
Note that if JILL logs off the system, SafeAccess will update the access rules and remove the SDEV.
The CP commands and functions that are intercepted by SafeAccess are discussed in detail in Chapter 3 "SafeAccess CP Component". The CMS commands and functions that are intercepted by SafeAccess are discussed in detail in Chapter 4 " SafeAccess CMS Component". Please refer to these chapters for more information.
|
