Ordinary databses have records whose fields are numerical or short text items (e.g., age, birth date, address, job title, salary). An object database has records whose fields are more general. For example, a paperless admissions office might be operated by scanning in the submitted application forms and storing those scanned images as graphic image data. The database would have some conventional fields (e.g., name, address, high school, GPA), but would also have some fields whose contents were objects. Behind the scenes, we might find that the graphic image data would be stored in a file of its own, and that the database management system software would really just record the filename of that graphic image data file, but when viewed as a database, the field is the graphic object.
Object databases can be implemented with a wide variety of items for the fields: graphic images, as we have already mentioned; software update installers; complete movies; etc.
In dealing with existing systems, not only must the software be changed, but the existing data files will need to be converted, too. This conversion will need to be done with an awareness of any special codes (e.g., all spaces, all zeros, all nines) that may have been used for "unknown" or "last record in file" or other such purposes. The special codes will need to be re-defined, and the values translated.
Many computer systems, from the personal to the datacenter, provide backup software that will store copies of files that have been changed since the last backup. This obviously requires comparison of date data, and therefore will be sensitive to Y2K problems or other "time bombs."
The original X12 EDI standard used a two-digit year format! An old EDI implementation is therefore highly suspect.
Despite their similar sounds, "telecommuting" is a very different concept from "telecommunications." The latter is one of the tools used to accomplish the former.
Although a telecommuter will not have to deal with the distractions of the water cooler and other social interactions at a regular workplace, there are other distractions: letting the dog out, answering the doorbell, etc.
The savings of telecommuting are partially offset by the costs. For example, instead of being able to share a fax machine with others working at the same location, a telecommuter is especially likely to need his or her own fax machine. Also possibly needed, and perhaps costing more when provided at a remote location, are
Face-to-face meetings between telecommuters and regular in-office staff on a regular basis can be a key to sustained success with telecommuting. Depending on the working environment and travel distance, this may be best done with one-day every week or month, or with one week every quarter.
Why do we care about atomicity? Suppose two customers are looking to reserve a seat on an airline flight that has only one seat still available. By chance, it is possible that both travel agents will press the key signalling that the customer does want the ticket at virtually the same time. The system must be designed so that this "collision" is detected and dealt with, so that one customer gets the reservation and knows it, and the other does not, and is told that the seat was sold to someone else while they were talking.
How can atomicity be accomplished? There must be some mechanism, in hardware that supports the software concept of a "lock," and the TPS or its underlying database must make use of those software locks to coordinate access to data structures. For example, some hardware has a single machine language instruction to read the value in a particular RAM address, test it, modify it, and write it back to that address. Using such a read-test-modify-write instruction, it is easy to build operating system support for locks. A particular memory address is set aside for each record in the database. When a travel agent wants to make a reservation, the software checks the value of the lock address. If no one else is using it, the new value written shows all others that it is now in use. Because this is a single, atomic, machine language instruction, no other user of the system can interfere with it, and when the other travel agent tries to make the reservation, the software will detect that the record is locked, and either wait for the other transaction to be completed, or signal the collision right away. As soon as all steps of modifying that data record are completed, the lock is released.
The term "race condition" is used in computer science to refer to situations in which the order of execution can change the outcome - it is a race between competing processes. Usually a race condition is a software bug! If locks are used consistently, then race conditions can be prevented. Multiprocessor computer systems, in which there are multiple CPUs sharing RAM and I/O devices, are becoming more and more common. Operating systems for multiprocessors must provide even more elaborate mechanisms to prevent race conditions between the multiple CPUs. Atomicity of a machine language instruction by itself is adequate only for uni-processors!
Fault-tolerant computing refers to hardware and software systems that are designed to provide the greatest degree of reliability possible. Typically this involves:
An example of this sort was the difficulties that OARnet experienced in the mid-1990s, when all of their links to the internet were through the same vendor. They had multiple connections, by different paths to different parts of the country, so that no one inept backhoe operator could take them all out at once, but the electronics at every connection point were from the same vendor, and they routinely all went bonkers at once, isolating OARnet from the rest of the internet.
The first space shuttle flight was repeatedly delayed because the synchronization of the multiple redundant computers was not assured.
- Read
- Permitted to see and to make a copy.
- Write
- Permitted to create and modify.
- Execute
- Permitted to copy an executable program into RAM memory and execute it, but not to make a copy on disk.
- Delete
- Permitted to delete the item.
Each of these activities is specified for each of a handful of user categories (not all operating systems provide all of these categories):
- System
- Specific components of the operating system. This does not restrict access by the systm manager's privileged account.
- Owner
- The person who owns the item.
- Group
- In situations where the internal user ID number is split into group and user parts, this would apply to anyone having a group number matching that of the owner.
- World
- Anyone on the system at all.
A more sophisticated method goes under the name of Access Control Lists (ACLs). An ACL controls access (hence its name) to a specific resource: a file, a folder of files, a disk drive, etc. Some operating systems provide for ACLs only for some types of resources. Each ACL consists of a sequence of Access Control Entries (ACEs), in which the order of the entries may be important (Windows NT V 4 does not pay attention to the order of the entries). Each ACE consists of two parts:
When ACLs are in use, the ACL is scanned to find the first ACE whose identifier part matches the user attempting access. Permission for the requested activity is then granted or denied, based on the second part of that ACE. If an ACL has multiple ACEs that would match a given user, it is only the first one that matters. For example, you can give everyone but a single individual access to an item by having the first ACE deny it to that one person, and the next ACE grant it to everyone. (As mentioned above, the Windows NT V4 implementation of ACLs denies access to a user if there is any matching ACE that denies access, regardless of order.)
Some systems that have ACLs enhance their utility by providing the possibility to grant identifiers to a process above and beyond the login ID. These may include identifiers granted to the person (effectively creating groups) or to the process (based, for example on interactive, batch, or network status). This can be used to achieve fine-grained controls on access to system resources.
How do interrupts work? There are several steps:
The precise techniques by which these steps are accomplished are designed into the CPU and interface circuits, and depend on the bus structure that connects them.
The problem with interrupts is the "overhead" of performing all those steps. Just getting ready to deal with the interrupt and returning from it may well take a hundred CPU cycles, in addition to the work done by the service routine itself.
The alternative to interrupts is called "polling," in which, whenever there is a pending I/O operation the CPU checks each I/O interface in turn to see whether it is ready for the next step, and keeps checking so long as there is pending I/O. This permits quicker response to the I/O activity at the expense of accomplishing nothing else while the I/O is pending.
DMA controllers are designed to be able to transfer data from the peripheral device to memory, without interrupting the CPU. They may block CPU access to memory during the transfer, but that causes much less delay than having the CPU handle the data itself: perhaps ten CPU cycles instead of the several hundred CPU cycles typical of interrupt context-switching overhead and the interrupt service routine.
Priority and class-based scheduling are particularly robust for mixed workload, general purpose systems, serving a combination of interactive and batch jobs.
Erasing magnetic media for security is a business in its own right, both providing the service and providing equipment for customers who do not want to permit the magnetic media to leave their premises with any possibility that the data might be recovered.
Dick Piccard revised this file (http://oak.cats.ohiou.edu/~piccard/mis300/ediextra.htm) on October 27, 1998.
Please E-Mail comments or suggestions to "piccard@ohio.edu".