|
|
Safe
Software and Sears Team Up for Success! |
| |
|
By Adrian
Clark of Sears Canada |
| |
| |
We saw the
potential benefits of SFS, but SFS issues prevented full implementation. |
|
 |
At
Sears Canada, we have been watching IBM's development of the VM/ESA Shared
File System (SFS) since its early incarnations under VM/SP. We started
limited use of SFS under VM/XA for managing the promotion of code from
development, to QA, to our production systems. Over 80% of our 16,000 VM
users are also Office Vision users. Until IBM supported SFS as an "A disk",
we had no big plans for exploiting SFS. When we saw opportunities for exploiting
SFS, we realized we had to do something about the authorizations. We had
VM programmers that often granted authorizations incorrectly. This would
go unnoticed until some time down the road when the original files were
replaced by maintenance procedures and the authorizations for the original
files disappeared. We looked at front-ending the IBM commands with our
own panel driven interface, but this meant additional development and support
efforts for our lightly staffed VM group and it didn't really provide all
the flexibility that an SFS External Security Manager could provide.
|
|
|
SafeSFS
solves the SFS issues and allows us to reap the benefits of SFS! |
|
|
We evaluated SafeSFS and were quite surprised
with some of the data that it unveiled. We had seven filepools with only
760 userids enrolled and we already had 75,768 SFS authorizations. We projected
that we would have over 1.5 million SFS authorizations after fully implementing
SFS. SafeSFS allowed us to delete these SFS authorizations and provide the identical
authorizations through SafeSFS rules. The SafeSFS rules looked a lot like
the VM:SecureTM rules that our users are already used to. We felt that
deleting the rules from the SFS catalogue was important because VM:BackupTM
had to extract all these authorizations via CSL routines when we backed
up SFS. The CSL routines are very slow and this would eventually have caused
significant delays in backups and greatly extended restore times at our
disaster recovery site (or onsite if we ever have a DASD failure).
|

|
| |
|
SafeSFS
reduces our costs and saves us much
more than the cost of the product! |
When we examined the rules that were generated
by the SafeSFS conversion utility, several other things became obvious:
1. Many extra rules for our service machines
were added unnecessarily because we forgot to add the "NEWREAD" or "NEWWRITE"
authorization. The native SFS GRANT command is confusing and difficult
to use. Users frequently made errors when attempting to GRANT authorities
in SFS. Since IBM's SFS authorization really only works at the file level,
no one had authorizations to the files that were added to the directory
after the initial IBM authorization was entered with incorrect parameters.
This caused many problems and would have required system administrators
to get involved to correct them. With SafeSFS, users may use the fullscreen
or dirlist/filelist interfaces to create SafeSFS rules. SafeSFS rules are
easy to create and have easily understandable, English like syntax. This
prevents problems with incorrect or missing authorizations and saves the
cost of system administrator time.
2. Someone had to enter most of these
commands and there were many more that would need to be entered as we rolled
out SFS. We estimated that if only 11% of our users required rules, similar
to the current percent of users with rules, this would add about 1.2 million
IBM SFS grants. This was far too many for our small catalogue disks. We
conservatively estimated the salary cost to deploy SFS using IBM's authorization
scheme would be over $199,000.
3. We also realized early in the SafeSFS
evaluation that we could get rid of 98% of the rules by defining SYSTEM
wide rules and ACIGROUP level rules. This virtually eliminates the enormous
administration costs. These factors made it easy to justify the software
cost for SafeSFS. By implementing it early in our SFS deployment, we avoided
having large SFS catalogues that would be difficult to reclaim space from and
our backup times didn't degrade to the point where we were getting
unacceptable backup windows. |
| |
|
SafeSFS provides
new functionality and allows
us to improve our business procedures! |
|
Our first wide spread use of SFS was for providing
information bulletins near all our POS (Point of Sale) terminals. These
users run on a VM id that provides no access to CMS resources, but they
often need to print out a bulletin. The base for this code was OV/VM's
BBOARD system. The obvious way to allow easy printing was to place $$PRNT$$
$FILE$s on each user's directory with only their local printer in it. These
updates were to be performed by an End User who knew where all the printers
were and what userids were in that area. With the native IBM SFS authorizations,
we would have to create an empty or dummy $$PRNT$$ file, then give the
user the authorization to write to that file. We would have to do this
every time a new store was opened or divisions were moved around in the
existing stores. This solution appeared to be too error prone and was never
implemented. When we installed SafeSFS, we were able to set-up a single
ACIGROUP rule allowing the appropriate person to update the $$PRNT$$ file
for all of the users. This moved all the administration to a single person,
the one responsible for the task, and saved us from having to add the one
authorization to each of the 3000+ members of this ACIGROUP. It also solved
problems that occur when users are converted from just using bulletins
to a full-blown OV/VM id. We simply change their ACIGROUP and the administrative
person no longer has the authority to change their OV/VM printer file.
|
| |
|
SafeSFS allows
us to fully deploy our Intranet! |
|
Our next SFS opportunity came along when VM
wanted to participate in the Intranet. While some users had access to the
Internet, there was no common method for users to publish web pages internally.
We put a web server on VM and felt that SFS was a better way to go than
mini-disk, so we decided that the web server would serve out data from
a user's .WEB directory. With native SFS, we could enroll a user in SFS,
create a .WEB directory for them, and then do a GRANT AUTH ... (NEWREAD
to the .WEB directory for the web server. This would work until the user
created a new directory and forgot to grant the authorization to the web
server. Then administrators would have to get involved to assist the users
with authorizations for the new directory. With SafeSFS, we were able to
add a single GLOBAL rule that allowed the web server and it's worker machines
to read the .WEB directory and all subdirectories. This let us remove thousands
of file level rules that are no longer required and avoid the administrative
headaches associated with creating and maintaining them. |
|
SafeSFS allows
us to use SFS for OV/VM and dramatically reduce DASD usage! |
|
This year we will be rolling out OV/VM 1.4
and at that time we can move a large portion of our users to SFS.
This allows us to reclaim the DASD free space that is present on each user's
"A disk". We estimate that about 30% of our DASD use is free space that
we can now recover. This amounts to about 42 gigabytes of DASD.One of IBM's
OV/VM requirements for "SFS toleration" is that no two users can be writing
to the same OV file at the same time. To prevent this happening accidentally,
we have added a SafeSFS rule to REJECT anyone other than the owner from
reading or writing to OFSLOGfl files and a few other files in the root
directory. With SafeSFS, this "* OFSLOGfl" file specification works with
existing and future files. With IBM's native SFS, only existing notelogs
would be protected if we tried to implement the same sort of protection.
New notelogs would not be protected. If a user does want to share a notelog,
then they can create a subdirectory to contain it and share it from there.
|
 |
| |
|
SafeSFS makes
everyone's job easier and reduces administrative costs! |
|
SafeSFS continues to provide cost savings
through reduced administration costs. The GLOBAL and ACIGROUP level rules
that are in place have replaced tens of thousands of IBM SFS authorizations.
With the original installation of SafeSFS, we looked at the list of existing
SFS rules that was generated by the SafeSFS conversion utility. We found
that by using SafeSFS GLOBAL & ACIGROUP level rules, we could get rid
of 98% of the existing SFS authorizations. |
| |
|
SafeSFS reveals
hidden problems and prevents future expense! |
|
Examination of the SafeSFS SFS conversion
utility output also revealed problems where a user was supposed to have
access to all files in a directory, but the conversion utility had generated
"REJECT" rules for many of the files. This turned out to be caused by users
forgetting to specify NEWWRITE access. Users could only see the files that
were in place at the time the original authorization was done. |
| |
|
SafeSFS saves
us the costs associated with updating applications! |
|
Applications that update files via a temporary
file and then an ERASE and RENAME caused the IBM SFS authorizations for
the files to disappear. SafeSFS rules saved having to make any application
changes and the SFS catalogue disk remains small. With SafeSFS you can
give a user access to a few thousand files in a directory in a few seconds
instead of waiting for a "GRANT AUTH * * ..." to slowly run through granting
access to each individual file. |
| |
|
SafeSFS facilitates
Y2K projects while maintaining security! |
|
SafeSFS was also beneficial for Y2K scanning.
A consultant would require SFS ADMIN authorization prior to SafeSFS. This
would allow them to scan every file without a lot of GRANTs, but also gave
them write access to the files. In this case SafeSFS prevented a potential
breech of security or loss of data. |
| |
|
Purchasing SafeSFS
was an easy decision for Sears! |
|
SafeSFS allows us to save enormous amounts
of money in the areas of SFS administration, system resources, security,
and user training expenses. These cost savings greatly exceed the cost
of SafeSFS itself. SafeSFS also solves the problems we expect with native
SFS and allows us to proceed with SFS migration and implementation. We
received the added benefits of a product that is easy to use and provides
new functionality. We expect to realize even more benefits from SafeSFS
as we move forward with our use of VM/ESA and SFS. All of this made the
decision to purchase SafeSFS an easy one for Sears.
|
| |
|