Electrical computers and digital processing systems: interprogra – Device driver communication
Reexamination Certificate
2000-06-08
2004-07-20
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Device driver communication
C703S024000
Reexamination Certificate
active
06766520
ABSTRACT:
BACKGROUND
This invention is primarily directed to the emulation of tape drive systems, their activity and data files as software objects, and is useful particularly to support legacy software that requires tape drive systems in their normal operation. The inventive concepts are particularly suitable for modern object oriented applications, and is well suited to use in Windows-based (operating systems of Microsoft Corporation) computing. The concepts defined by the embodiments described have wider application to the field of emulation of peripheral hardware systems generally, however.
A problem with computer systems over time is that legacy systems software is designed for the legacy system hardware and that hardware gets updated and replaced without a redesign of the legacy software. This creates a problem for the user who is using the computer for a number of tasks and cannot afford to have a rewrite of the legacy software accomplished, but needs new hardware for his other computing needs. A particular case in point is with Unisys Corporation's 2200 series computer systems that used to have tape drives as the boot volume required for start-up of the-system. For a computer system user who needs to continue to use system or application software or both that require the 2200 computer, but who can no longer maintain such a system, a way to emulate the processor functions would enable him to run his 2200 legacy software on, for example a WINDOWS (Microsoft Corporation Operating System trade name) computer system, if the system also had a processor emulator for emulating the 2200 system. A way to do this is available in a software or hardware based 2200 processor emulator. However, as mentioned before, some of this software will rely on the existence of a magnetic tape drive system that was available with the legacy hardware, and rewriting old software is not the most productive use of coding resources.
(Processor emulation too is known, see for example U.S. Pat. No. 5,751,982, Morley, in which software emulation of a microprocessor is described. Too, emulation of processors via plug compatible emulation hardware is also known, as for example are seen in U.S. Pat. Nos. 5,497,456 and
5,727,217.)
Accordingly there are substantial business needs or reasons to have tape drive peripheral emulators available in software.
A number of attempts have been made to emulate various features of tape drives and are described in the patent art. For perhaps the closest example, see U.S. Pat. No. 5,297,124 issued to Plotkin, et al. In this patent, a disk drive is made to emulate a tape drive in a “plug compatible” fashion. Accordingly it requires a hardware interconnect device containing a processor, RAM, ROM, and supporting components to produce tape drive like responses for the host computer system addressing the Plotkin et al disk drive acting like a tape drive.
Earlier a patent issued to Kantner, U.S. Pat. No. 4,511,963, which described how to deal with the echo (verification) transmissions between the tape drive and the processor, among other things.
Brikner and Sankey in U.S. Pat. No. 4,727,512 described another interface system for allowing a computer system with a standard tape drive interface to communicate image data with such a computer, and Osterlund, in U.S. Pat. No. 4,775,969 described how to store and retrieve tape drive formatted data from an optical disk drive.
All these four patent references are incorporated herein hereby, in their respective entireties, for the disclosure they provide of the relevant features stated therein.
However, none of the art appears to have developed a tape drive emulator that was simply operating in software available to the computer system to be used by other software programs, legacy or otherwise, in the same computer system.
Unisys Corporation has developed simulators before too, but these were not developed as software objects, and therefore would require invocation of a processor simulator to enable a tape drive simulation. The tape drive simulators thus provided were not available for other uses, nor were they directly accessible by programs that did not go through the processor emulator to address them. Because of the tight coupling of the various parts of the emulation subsystems, the programming and use flexibility of having an emulated peripheral be a software object was unobtainable. For example, once a system with instruction processor (emulated or otherwise) was set up having associated emulated memory, and emulated input output (I/O) processor, the number of peripherals, or processors for that matter was set. With an object oriented design, once the class is determined, new instances of the software object subsystems (tape drives, disk drives, et cetera) can be created and used without having to redesign or reconfigure the system. Further, no external resources were available to the prior design system by Unisys. In the object design, this limitation will not exist.
Another important feature of a tape (or other legacy peripheral) emulator would be to allow the user to transfer tape files from remote systems to a Windows workstation without having a tape drive on the workstation, and having the ability to transfer the files back to the remote system (for example a legacy Unisys 2200 computer system with a CUSC70 tape drive) would also be valuable. Because the emulator would be built to use the Windows I/O to access files the emulator would be able to read from any standard Windows compatible peripheral device, including the ubiquitous CD-ROM, DVD or any other device with a Windows driver. The old emulator designs for Unisys legacy systems (a full systems emulation software suite called FLIT) were limited in use to reading from 2200 peripheral devices. One example would be the Windows operating system and accessory software file location features could be taken advantage of by software running an emulator in accord with this invention to find files in any peripheral to be used by the emulator. Further, other programs can communicate with the inventive emulator using the standard object oriented interfaces. These interfaces are commonly called object properties, methods, and events. Obviously these adaptabilities were not available when using a tape emulator as part of a 2200 system emulation.
Accordingly, if a tape drive emulator were developed as a software object, these limitations would be ameliorated and the transition from legacy systems to modern systems could be made more practical and efficient.
In an object oriented programming (OOP) environment, the software system within a computer system facilitates the actions of the instances of objects within it. The environment also allows for the programmer creation of classes of objects from which programs or users can create object instances. Programs can operate outside of the OOP environment and the OOP environment can receive and send messages to such outside programs in order to facilitate use by such outside program entities of the instances within the OOP environment. The outside program entity would need to know the name or other addressable feature of the object instance, and the object instance would be able to respond only if the OOP or the instance itself could address the outside program entity. Entities within the OOP environment also, of course, can pass messages between themselves as facilitated by the OOP environment. Addressing is typically done by sending a message bearing the name of the entity being contacted and the name (or other addressing link feature) of the sending entity can be in the message or kept track of by the OOP environment. Thus reply messages can be easily returned to the sending objects or outside program entities. The messages themselves can carry instructions or changes to properties of the object instance being addressed, or can even call for the destruction of the object instance. Objects, outside entities, programmers and users can all create object instances using predefined classes, and programmers, outside program entities, object insta
Anderson Dave Q.
Johnson Kurt N.
Rieschl Michael J.
An Meng-Al T.
Atlass Michael B.
Starr Mark T.
Unisys Corporation
Zhen Li B.
LandOfFree
Tape drive emulation software objects, and emulation of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Tape drive emulation software objects, and emulation of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Tape drive emulation software objects, and emulation of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3204076