Browse Prior Art Database

Saving Essential Object Information Through Java Object Serialization and Java Compression, Storing the Java Object Essentials on a Non-Java System

IP.com Disclosure Number: IPCOM000123892D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 2 page(s) / 142K

Publishing Venue

IBM

Related People

Furze, M: AUTHOR [+2]

Abstract

In the original implication of the Host On Demand 5250 emulator, the Save command, and its corresponding Restore command design was implemented incorrectly. The object information was stored in an array, on the PC, while sending an index into the array to the host AS/400. The save command is supposed to be received by the terminal (or terminal emulator in this case) and the response to the command should be all the information needed by the terminal to restore it to its state at that moment. The information is then returned to the terminal in the form of the Restore command, with the data in exactly the same state it was in when the terminal sent it in the reply to the Save command. Our first implementation showed a flaw shortly after release.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Saving Essential Object Information Through Java Object Serialization
and Java Compression, Storing the Java Object Essentials on a Non-Java
System

   In the original implication of the Host On Demand 5250
emulator, the Save command, and its corresponding Restore command
design was implemented incorrectly.  The object information was
stored in an array, on the PC, while sending an index into the array
to the host AS/400.  The save command is supposed to be received by
the terminal (or terminal emulator in this case) and the response to
the command should be all the information needed by the terminal to
restore it to its state at that moment.  The information is then
returned to the terminal in the form of the Restore command, with the
data in exactly the same state it was in when the terminal sent it in
the reply to the Save command.  Our first implementation showed a
flaw shortly after release.  The index limit to the array of saved
objects was originally 10, and a customer soon ran into that limit.
The first temporary correction was to move the limit up to 100, and
then to 10000.  The severity of the problem escalated when a
customer application regularly reached this boundary.  When the
boundary was reached, the Save/Restore function would no longer
function, and the emulation program simply hung.  In addition, the
memory objects of saved data required system resource.

   The 5250 architecture requires that the data be saved on
the host in order to insure proper "clean up" of unused Save data.
Each host program is responsible for the data received by the
response to the Save command.  The data collected by the Save
command does not have to be used with a corresponding Restore
command.  When the host program finishes executing, and exits, the
program, and all the objects it owns are released and returned to
free memory.  The program not only does not notify the terminal of
the discarding of the extra saved data, it can not notify the
terminal, as the objects are discarded automatically.  It is easily
conceivable that a user written application, especially one used for
order entry to a common data base could save several screen images
for a single order, requiring the operator to use only 30 to 50
keystrokes.  One customer had operators who could reach the limit in
3 hours of order taking.

   The challenge was to transform the data into a data
stream, or string of bits at the lowest level of the definition that
could be transmitted to the host in response to a Save command, and
when the host returned the data in a Restore command the data stream
could be used to restore the emulation program to its state at the
time of the Save command.

   The solution is basically twofold.  First, the data
gathered into the object to be saved is Serialized using Java
functions which transform functional objects into a stream, this
stream can later be used to restore the object that we began with.
The second layer of processing is compr...