No abstract

A smart card runtime environment must provide the proper transaction support for the reliable update of data, especially on multiapplication cards like the Java Card. The transaction mechanism must meet the demands by the applications and the system itself within the minimal resources offered by current smart card hardware. This paper presents the current transaction model implied by the Java Card 2.1 specification, highlights its shortcomings and presents a detailed discussion of possible implementation schemes and their optimizations. It especially addresses the problem of object instantiations within a transaction in the Java Card 2.1 specification and presents an effective solution.

In this final of three related articles about smart card technology, the authors discuss the JavaCard, a much-hyped technology that is finally taking off as a multiapplication smart card. Mobile Computing I n the smart card world, JavaCard has been one of the most hyped products around for years. The main reason for the hype is Java-Card's potential. Not only would it let all Java programmers develop smart card code, but such code could be downloaded to cards that have already been issued to customers. This flexibility and post-issuance

An Operating System is described which will run on a wide variety of configurations of the I.C.T. 1900, and can handle a large number of online console users while at the same time running several offline (background) jobs. The system is not oriented towards either mode and can be either a batch processing system (such as the ATLAS Supervisor, IBSYS, or GECOS), or a multiaccess system (resembling, to the user, CTSS or MULTICS), or both simultaneously, depending on the installation, which can adjust the Schedulers. Both online users and offline jobs use a common Command Language. The system includes a Multilevel device-independent File Store.

This is the first of two papers on the design of the low-level internal structure of the ICL GEORGE 3 operating system. After a discussion of the background and ancestry of the system, descriptions of the core allocation system, the chapter changer and the co-ordinator are given. An attempt has been made to give the reasoning behind the decisions made in the early design stages. KEY WORDS Operating system design GEORGE 3