Method and system for wrapping single files for burning into compact disk

A system and method for transforming specialized data files of a first computer system into industry-standard byte-stream files usable for a second system or other systems. First and second programmatic interfaces of the first system can take the specialized format native data files and transform them into standard formatted byte-stream data files for placement in a storage media of a second computer system which can then be initiated to use a CD Writer package to cause the data files to burned on to a CD-ROM. This CD-ROM can then provide the byte-stream data file for use in many different types of platforms.

FIELD OF THE INVENTION 
This system relates to methods for enabling data files which are organized 
in a first format to be reformatted and subsequently burned onto a Compact 
Disk to enable the data to be transported and utilized in networks 
utilizing different data formats. 
BACKGROUND OF THE INVENTION 
In the usage of modern computer systems and networks, the situation arises 
where systems having one proprietary protocol and data format are 
connected to systems having different data formats and protocols. Thus in 
order to provide for system integration in different networks, it is 
necessary that there be provided a system or method whereby the data 
formats of a first system can be transferred to and utilized by the 
network of a differently oriented system. 
For example, the Unisys A Series computer systems involve a Central 
Processing Unit and memory together with storage such as disk storage 
which operates under the control of a Master Control Program. These A 
Series systems use a particular format for the data files compatible with 
the A Series software which can be placed on CD-ROMS. Thus, the CD-ROMs 
which contain this A Series software contain an image of a formatted tape 
which can be utilized only by the A Series systems. 
However, when it is desirable to integrate a first system such as the A 
Series systems for operation with other platforms such as an NT system, 
then problems arise in that the second system such as the NT system, 
utilizes formats which are not compatible with the software formats of the 
A Series system, which is the first system. 
Presently, the software for a first system, such as an A Series system, is 
utilized by providing methods to burn CD disks from a Library Maintenance 
formatted tape. This method has the limitation in that it limits the type 
of files that are burned into CD-ROMs to those of the native A Series 
files. 
Now, in order to provide for system integration where an A Series system is 
to be coupled to a NT system, which overall system would be designated as 
a Unisys ClearPath system, the desirability here would be to make and use 
a single CD-ROM disk which would carry both the A series software and at 
the same time carry the NT software. 
Thus in this regard, a method is needed to couple the A Series files with 
their native attributes and also arrange them in a format capable of being 
stored on a particular media such as a CD-ROM which will also hold the 
readable software for the NT system. 
The A Series systems have files with specialized attributes which are 
designated for example, as FILEKIND, CREATIONDATE, and RELEASEID. These 
are defined in the Section denoted "Glossary Terms". 
As a result, the Unisys A Series systems will provide a programmatic 
interface to its Master Control Program (MCP) which will provide a 
mechanism for "wrapping" and for "unwrapping" files. 
Wrapping is a term which is used to define the process of packaging an A 
Series file, along with its Disk File Header information and a checksum 
(and optionally a digital signature), as a byte-stream data file, so that 
it can be transported across heterogeneous networks and non-A Series 
specific media, while still maintaining its native A Series attributes. 
Unwrapping is a term used to define the process of taking a previously 
"wrapped file" and coupling it with the information from its original Disk 
File Header (DFH) in order to restore the original native A Series file, 
as it existed prior to being wrapped. 
Thus, the problem of a software and file format which is oriented to one 
system can now be transformed in order to provide a format that is 
utilizable not just for a first system, but also for a first and second 
system, whereby the second system would not ordinarily be compatible with 
the first system. 
The presently described system and method provides for taking a first 
program format such as used in Unisys A Series systems and developing a 
second generalized format for burning into a CD-ROM such that now this 
second program format is compatible for both NT and other systems in 
addition to A Series systems. 
SUMMARY OF INVENTION 
An algorithmic sequence is implemented in software for providing and 
developing single files in a standard format on industry-standard Compact 
Disks (CD-ROMs) which disk files can be viewed from either a NT platform, 
an IBM platform, UNIX platform or other platforms including a Unisys A 
Series platform using an industry-standard format. 
Thus, a company or a person could provide themselves with a Compact Disk 
Writer Module allowing the person to first receive data by File Transfer 
Protocol or other data transmission over the Internet, to receive the file 
data information and then burn it into a Compact Disk. The Compact Disk 
can be used then to insert the file into the local platform. 
The present system is applicable in the Unisys ClearPath environment which 
involves a situation where two systems are connected to and communicating 
with each other, for example, such as that both a Microsoft NT platform 
and a Unisys A Series platform can both read from the same Compact Disk in 
a compatible fashion. Thus, this makes it possible to put the NT platform 
software and the A Series platform software all on the same Compact Disk 
(CD-ROM). 
With the use of such a uniform standard Compact Disk, an operator can load 
and use the NT platform in order to pull the files he needs by using an 
"Install" procedure which utilizes the information on the Compact Disk. 
Likewise, a person using the Unisys A Series platform can also pull the 
files from the CD-ROM by using an "Unwrap" command in order to load and 
utilize the A Series software from the Compact Disk.

DESCRIPTION OF PREFERRED EMBODIMENT 
Referring to FIG. 1B, there is seen a drawing of the major elements 
involved in the present system. 
A first system is shown, for example, such as a Unisys A Series computer 
operating system which involves a Central Processing Unit 14, a main 
memory 18, a microcode memory 16 which is managed by the MCP 10 (Master 
Control Program). The CPU 14 is also supported by a storage media 20, Disk 
A, which will be enabled to carry an original file 21, designated MY/FILE 
which is formatted suitably for the first system such as the A Series 
computer system, and Disk B,22, which will be enabled to carry a new file 
designated MY/NEW/FILE, which is formatted for transport to a second 
system. 
Now, in the sense of integrating to other systems, there is seen a second 
system called the "NT System 30" (alternatively a UNIX, IBM or other 
system) which is a platform developed by the Microsoft Corporation of 
Redlands, Wash. The NT System 30 is seen having a storage medium 24 such 
as Disk C, which will eventually be provided with a resultant file 25 
designated C:.backslash.MY.backslash.NEW.backslash.FILE (Item 25). 
The Central Processing Unit 14 is provided with a WFL (Work Flow Language) 
compiler 15 which is an interpretive language capable of taking User 
instructions and translating them into Operating System (O.S.) procedure 
calls. The CPU has a relationship to the NT system 30 through use of a NX 
services unit 50. 
NX/Services is a software unit used to integrate MCP operations with NT 
platform operations through the use of a Microsoft (MS) Standard RPC 
(Remote Procedure Call) interface. 
The WFL compiler 15 is an interpretive compiler which provides a new 
language syntax using the word "Wrap". 
The Operator Terminal 8 of FIG. 1B, is the operator interface in which an 
operator would enter a command such as "WRAP MY/FILE", which is the file 
21 sitting in Disk A and MY/NEW/FILE which is the file 23 (FIG. 1B) 
residing in Disk B. This command is transmitted through the MCP (or Master 
Control Program 10) in order to initiate the action of the WFL compiler 
program 15. 
The compiler 15 then calls the MCP.sub.-- FILEWRAPPER program 36 whereby 
the compiler passes the parameters as input to this software program. The 
MCP.sub.-- FILEWRAPPER program 36 will then take the original MY/FILE 21 
from Disk A, 20 and convert it to a new file designated MY/NEW/FILE 23 and 
deposit this into the storage disk B,22. 
The MCP.sub.-- FILEWRAPPER software 36 will communicate with the MCP.sub.-- 
WRAPPER 38 program indicating that the data should be processed or 
wrapped. 
Thus, the MCP.sub.-- WRAPPER program communicates back to disk A and gets 
the Disk File Header information (DFH) which contains the native A Series 
attribute information for the file, and the MCP.sub.-- WRAPPER actually 
operates to Read the file on Disk A and transmits this data to the 
MCP.sub.-- WRAPPER 38 Program. 
The MCP.sub.-- WRAPPER Program 38 then packages the information of the Disk 
File Header with the data and passes it back to the output procedure of 
MCP.sub.-- FILEWRAPPER 36 with a command to - - - Write this out to 
storage Disk B, 22, as the new file. As a result, there is now a data file 
provided onto the storage Disk B, 22. This file, MY/NEW/FILE, is now 
available to the NT system platform 30 from the file 23 residing on Disk 
B, 22. 
Another example of a problem that arises is the situation where there are 
two separate and different A Series computers, whereby the first computer 
has data and information (files) which it is desired to give or present 
for use by the second computer system. Normally, if the first system file 
is in object code, it is then necessary to put it on a tape and mail it to 
the second computer User or alternatively, to have the first system and 
second system connected to each other through a proprietary network 
connection. However, this is sometimes a long and cumbersome process, when 
it would be most desirable to be able to transmit it electronically to the 
second user through an open network such as e-mail or FTP (File Transfer 
Protocol). 
Thus in the present system, the first computer system user would take his 
file and do his wrapping operation using the WFL WRAP, or Work Flow 
Language wrapping. 
Thus, a "new file" such as MY/NEW/FILE 23 can be generated and this new 
file can then be downloaded into a personal computer, such as in the 
second system, NT 30 and sent via Internet mail to the second user, or 
this data file can be burned into a CD-ROM and mailed to the second user. 
It should be noted that once the new file 23 has been placed on storage 
Disk B, 22, then by the use of the NX services 50, this new file 23 can be 
transmitted to the NT system 30. Thus, the NT system with its hard Disk 
C,24, can now receive and utilize the new file (as 
C:.backslash.MY.backslash.NEW.backslash.FILE) which came from the storage 
Disk B,22. 
Another problem aspect involved is when an operator wishes to take a file 
from a first system, such as an A Series system program and copy it into a 
UNIX box or an NT box - - - that information cannot normally be 
transported because of the format and protocol differences. 
Thus, the specialized structure and format of the A Series native files 
which normally could not be moved across a network, would have to be 
reconstituted and stored as part of the data in the data file and then 
made into a regular character data file of a common format such that any 
operating system can read it. This would be a byte-stream data file which 
could be read by any platform, whether it be a UNIX box, an IBM box, or a 
NT box. Thus, resultantly there is now a file that any platform can read. 
In what is called the "Unwrapping" operation, all the time-stamped dates 
are reapplied, all the disk, row, address information is supplied, the 
file is rewritten row for row, segment for segment, exactly as it looked 
on the original system. Thus, if there were "spaces" at the end of the 
segment on the original file, there will also be the same spaces at the 
end of this segment on the resultant file. This is so because all this 
information is in the file's Disk File Header. 
Thus, what has been accomplished is to take a first original native file 
and repackage it, by burning the file into a CD-ROM, so it can be 
transported anywhere to a second location, and then be loaded to act like 
the original file. 
One method of getting system software out from the originator to a customer 
is on a Compact Disk, that is a CD-ROM, which has specially formatted 
arrangements in order to transmit A Series software. However, these files 
often are not always in industry standard format. 
Customers often ask saying that they have a Compact Disk writer on their PC 
and they want to know - - - "how do I format a file so that I can 
distribute software to my other terminals" or to other customers that they 
have in their area? 
Thus, the present system allows these recipients to download these files to 
their personal computer and then burn them into a Compact Disk and send 
them to their local co-workers or to their other customers. The burned-in 
files on the Compact Disk are burned using Industry Standard format for 
compatibility to other systems platforms, such as NT system platforms, 
UNIX system platforms, IBM system platforms, DEC System platforms and 
Unisys A Series system platforms. 
Thus, the present system operates such that operators using the A Series 
systems can unwrap their files directly from an industry standard 
compatible Compact Disk, so that the file is usable just by putting the 
Compact Disk into the A Series system and giving it the command to "Unwrap 
Files". The files and software can then be received for utilization. 
The present system requires the packaging of native files of a first 
computer system such as a Unisys A Series system, in such a way as to 
allow them to co-exist on the same CD-ROM media, as none-native (A Series 
computer system) files. This packaging of files also allows for the 
transport of the native (A Series) files across heterogeneous networks, 
while still maintaining information on their native (A Series) attributes. 
Previously CD-ROM's contained native A Series software on CD disks which 
were burned from a library maintenance formatted tape. However, this 
limited these types of files to only be useful for native A Series systems 
which are formatted for native A Series files. The present system provides 
an expanded ability for burning the native A Series files of software for 
a first computer system onto CD-ROM disks which will be compatible with 
suitable files for a second computer system, such as a Microsoft NT system 
and other platforms. 
The native formatting of A Series files had attributes such as FILEKIND, 
CREATIONDATE, and RELEASEID, which now need to be placed in a format 
capable of being stored on a disk media which is using an 
industry-standard file format. 
As mentioned earlier, "Wrapping" is a term used to define the process of 
packaging a native A Series file (first computer system) along with its 
Disk File Header information, (plus either a checksum, or optionally a 
digital signature), as a byte-stream data file (FILESTRUCTURE=STREAM, 
MAXRECSIZE=1, FRAMESIZE=8) so that it can be transported across 
heterogeneous networks and non-A Series specific media, while still 
maintaining its native A Series attributes. 
The "digital signature" is created using an industry-standard public 
key/private key signaturing algorithm which provides a measure of security 
in that it allows a user confidence as to where the file originated from. 
The present system encompasses the Master Control Program (MCP), the Work 
Flow Language (WFL) program, and the FILEDATA work necessary to wrap files 
by packaging them into new, byte-stream files (wrapping) and later 
restoring them to their original native A Series format when needed for A 
Series systems (Unwrapping). 
NEW WFL SYNTAX: This involves a new work flow language syntax, so that 
arrangements are made in the WFL compiler 15 to support the new syntax 
which will have some similarity to a previous Library Maintenance MOVE 
command. The new syntax allows a User to wrap either a single file, a list 
of files, or a directory of files, in addition to subsequently enabling 
the unwrapping of these files, by specifying both the input file and the 
output file, or the directory title and location. 
ADDED PROGRAMMATIC INTERFACES (MCP.sub.-- Filewrapper 36): A programmatic 
interface is provided that will allow the User-Caller to pass a native A 
Series file's title and location as "input" along with an "output" file, 
title and location. The "output" file will be a "byte-stream" file with a 
beginning data block containing (i) an identification stream; (ii) the 
original files Disk File Header information; (iii) the file itself as 
byte-stream data; and (iv) an ending block containing either a checksum or 
digital signature. 
Thus, the added programmatic interface allows the caller to pass 
byte-stream file's title and location as input, along with an output file 
title and location if needed, for use of the "unwrapping" process. The 
"resultant file" will be a native A Series file created with the output 
file and location, but also containing the data and all of the native A 
Series attributes of the original file. 
SINGLE PROCEDURE CALL: This first programmatic interface will allow input 
and output directory names to be passed in order to wrap or unwrap a 
directory of files with a single procedural call. This also allows for a 
single output "container file" to be created from multiple input files. 
SECOND PROGRAMMATIC INTERFACE (MCP-WRAPPER 38): This interface is created 
to allow a caller to pass the A Series file's title and location as 
"input", together with an "output" procedure. The data returned to the 
caller's output procedure will be a stream of data with (i) a beginning 
data block containing an identification string; (ii) the original file's 
Disk File Header information; (iii) the file itself as byte-stream data; 
and (iv) an ending block containing a checksum or a digital signature. 
Functionally, the second programmatic interface will also allow the caller 
to pass an input procedure, along with the title and location of an output 
file. The data passed to the input procedure here would consist of a 
stream of data, with a beginning data block containing the identification 
string, the original file's Disk File Header (DFH) information, the file 
itself as "byte-stream data", and also an ending block containing the 
checksum or the digital signature, which is basically the same information 
that was passed to the output procedure when the file was originally 
wrapped. Here, the "resultant file" will be a native A Series file created 
with the output file title and location, but containing the data and all 
of the native A Series attributes of the original file. 
NEW FILEDATA SYNTAX: New syntax has been added to the FILEDATA LFILEs 
command in order to specify that the file being interrogated is a 
WRAPPEDDATA file. If this is a WRAPPEDDATA file, then FILEDATA will report 
the "attributes" of the native A Series file contained within the wrapped 
data file, rather than the attributes of the "wrapped" data file itself. 
WFL WRAP COMMAND: This is the work flow language wrap command usable in a 
first system computer such as the Unisys A Series computer system which 
can be executed to initiate the action of taking specialized formatted 
native A Series files and turning them into byte-stream files which can 
later be burned onto CD-ROM disks. Thus, the software files of a first 
computer platform, such as the Unisys A Series system, can now be made 
able to coexist on the same data CD-ROM's as other types of software which 
is not A Series software. 
KEYSFILES: The system will provide the use of A Series KEYSFILE which will 
also be wrapped using the new WFL syntax. This resulting file will also be 
burned onto the CD-ROM. Normally, the Unisys A Series KEYSFILES are 
shipped on separate tapes from the rest of the software releases, so that 
in the present situation, the newly wrapped KEYSFILE will be shipped on a 
separate data CD-ROM separate from the rest of the A Series release 
software files. 
The A Series KEYSFILE is a file on each A Series system used to store 
License Key information for the individual system in order to determine 
which of the Unisys licensed features the user has purchased for use on 
that system. 
The new WFL UNWRAP syntax can be used to unwrap the KEYSFILE off of the CD, 
while copying it into the A Series system. Once the file (as KEYSFILE) has 
been copied onto the A Series system, then a IK MERGE can be performed. IK 
MERGE is the system command used to merge the data from the new KEYSFILE 
(unwrapped from the CD ROM on to Disk) on the A Series system into the 
system's current KEYSFILE. 
CHECKSUM: A checksum is calculated for the Disk File Header (DFH) for every 
file as it is wrapped. This ensures that there is no unintentional 
corruption of the Disk File Header as the file is shipped across a 
network. It also provides the receiver of the file some measure of 
confidence as to the origin of the file. 
In addition to the checksum for the Disk File Header, a checksum is also 
calculated for the entire context of the file including the Disk File 
Header (DFH). 
SIGNATURE AND CHECKSUM (PREVENTION OF CORRUPTION): The checksum will not 
normally be sufficient to ensure that a Disk File Header has not been 
intentionally corrupted, since the checksum algorithm is not protected and 
is fairly easy to reproduce. There is significant overhead to validate the 
Disk File Header if there were no protection of the structure, other than 
the simple checksum. Thus, without any real protection for the Disk File 
Header, it would be necessary to create an entirely new Disk File Header 
for the original file, and then separately validate every attribute of the 
header before it could be considered trustworthy for application. 
The Master Control Program (MCP) 10, FIG. 1B, will assume that a Disk File 
Header is a valid piece of data. However, it is necessary to validate the 
Disk File Header before the rest of the file has even been retrieved, 
since even the information regarding the "size" of the file is stored in 
the Disk File Header. In order to insure that there was no intentional 
corruption while the file was in transit and also provide the "receiver" 
of the file with some insurance that the sender of the file was indeed 
that who the receiver expected it to be, a digital signature may be 
requested when the file is wrapped by specifying a private key with which 
to identify the signature file while wrapping. The receiver "must" specify 
the file's public key in order to verify the file when unwrapping it. 
PUBLIC/PRIVATE KEYS FOR SIGNATURING: A KEYS generation utility is provided 
as a separate utility to generate public/private key pairs to be used when 
signing files. Public/Private key pairs are generated using the new 
utility in order to be used by the wrapping interfaces for signaturing 
files. 
WRAPPEDDATA FILE FORMAT: With reference to FIG. 3, there will be seen the 
format of the WRAPPEDDATA FILE which will be a simple byte-stream file. 
This file, as seen in FIG. 3, will contain several sections. The first 
section (i) is the word UNISYS "000010" which will be "EBCDIC" data used 
to indicate that this is likely to be a Wrapped file. The number 
associated with this identifier may be changed if the format of this file 
is changed. 
The second block (ii) labeled "options" contains the options used when 
wrapping the file, such as the identifier to be used to locate the "public 
key" information in order to verify a file containing a digital signature. 
The third block of FIG. 3 is (iii) designated as the Disk File Header, 
which involves a copy of the actual A Series Disk File Header for the 
file. This will become the actual Disk File Header for the file when it is 
restored to its native format after a "unwrap" operation. Additionally in 
block (iii), there is seen the Header checksum, which is a separate 
checksum for the Disk File Header itself. 
The fourth block (iv) of FIG. 3 indicates "the file" which involves the 
contents of the file itself, written as byte-stream data. 
The fifth block (v) of FIG. 3, is designated as "checksum" or "digital 
signature", which will be either the checksum or the signature calculated 
for the file and the disk file header combined, using a private key from a 
public/private key pair. A "options" signal will indicate whether this is 
a signature, or it is a checksum. 
DSAKEYSFILE FILE FORMAT: The new system involves a keys file called 
"SYSTEM/DSAKEYSFILE". This file is stored and managed similarly to the 
manner of existence on earlier A Series systems which used the 
"SYSTEM/KEYSFILE". This file is used to store records of ID, software 
level, public key, PQG. These involve the following: 
(i) ID: This is a unique and meaningful EBCDIC string with a length of up 
to 17 characters which is used for external display and for identifying 
the set. 
(ii) Software Level: This is a real number that identifies the software 
level involved. 
(iii) Public Key: This is a DSA key generated along with a private key 
based on certain prime numbers designated P, Q, G. This key is 
subsequently used in the "Unwrap" process of the A Series software. 
(iv) P,Q,G: These are prime numbers generated by a special utility. For a 
given set of (P,Q,G), there are a variety of public and private key pairs 
which can be generated. 
INTERFACE OPERATIONS: This system involves new work flow language (WFL 
commands) designated as WRAP and UNWRAP which are provided to allow Users 
a simple method of invoking the new interfaces of this system. 
There are two new FILEKIND values created to identify the files of the new 
format. These will help to prevent users from accidentally using the WRAP 
syntax to act on a file that has already previously been wrapped. 
There is basically now provided two new programmatic interfaces designated 
as (i) MCP.sub.-- FILEWRAPPER and also (ii) MCP.sub.-- WRAPPER. These 
programmatic interfaces are exported out of the Master Control Program 
(MCP) 10. 
FILEKIND: This involves a set of values which will aid in identifying files 
that have been wrapped as long as the files have never left the 
environment of the first computer system, that is to say, the A Series 
computer. Once the file has then been copied into a non-A Series system, 
and then back on to the A Series system, this information is lost. The 
main purpose of new FILEKIND value is to ensure that a user does not 
accidentally attempt to WRAP an already WRAPPED file, as would be the case 
if a WFL WRAP command was executed on a directory of files and then the 
system did a Halt/Load before all of the files of a directory were 
wrapped. If the job were to restart after the Halt/Load, the WRAP command 
would begin to act on the directory over from the very beginning. If a 
file is encountered with a FILEKIND or with a WRAPPEDDATA value, that file 
will be skipped, and an error message will be issued for the file 
indicating that the file had already been previously wrapped. 
WORK FLOW LANGUAGE (WFL): The work flow language syntax is provided to 
allow a user easy access to the new programmatic interfaces. The new WFL 
commands permit the user to access the new interfaces to institute a wrap 
or an unwrap action without having to know the layout of the interfaces or 
having to create a program to call up these interfaces. 
TASKSTRING: This is a data structure that contains private or public key 
information for either signaturing or for verifying the signature of the 
file. Thus, for a "Unwrap" operation, the TASK STRING will be used to 
specify the public key that should be used to verify the signature that 
was calculated when the file was wrapped. Then conversely, for the WRAP 
operation, the TASK STRING is used to specify the "private key" that 
should be used to calculate the signature of the file. 
MCP.sub.-- FILEWRAPPER INTERFACE: The newly developed MCP.sub.-- 
FILEWRAPPER program is used for work flow language support and User 
programs. A User can call this program specifying either a "Wrap" or an 
"Unwrap" action along with the title and the location of both the input 
files and the output files. Of course, the input file specified for a 
"Wrap" operation must not have a FILEKIND of WRAPPEDDATA. Further, the 
caller must have the proper privilege for both the input and the output 
files or directories. 
The MCP.sub.-- FILEWRAPPER program involves procedures which return errors. 
These errors are returned as display messages if the procedure is called 
from the Word Flow Language (WFL). 
MCP.sub.-- WRAPPER INTERFACE: When this interface program is called to 
"Wrap" a file, it takes a standard form name for an existing A Series 
file, along with an output, or Write, procedure. The A Series files Disk 
File Header (DFH) will be checksum passed the output procedure as data 
along with the checksum. Then the file itself will be read and passed on 
to the output procedure as data. Finally, there will be provided 
(optionally) a calculated digital signature or a checksum for the entire 
file which will be passed to the output procedure as data. 
When the MCP.sub.-- WRAPPER program copies a file from disk (i.e. "Wraps" 
the file), it updates the files COPY SOURCE time-stamp in the Disk File 
Header (DFH) of the A Series file that has been wrapped. 
One of the parameters for the MCP.sub.-- WRAPPER is the procedure 
designated IOWRAP. IOWRAP is the procedure being passed, either as an 
output or a WRITE procedure for Wrap or an input or READ procedure for the 
Unwrap. The parameters for IOWRAP involve (i) LGTH which indicates the 
length of array data in bytes; (ii) DATA is the array containing the data 
to be WRITTEN when for wrapping or READ for unwrapping. 
It is significant to note that a Disk File Header (DFH) can involve data up 
to about 20,000 words long. Thus, the IOWRAP parameter procedure must be 
able to handle at least 20,000 words in the data array in one call. 
DSAKEYSFILE: The wrapping routine upon recognizing that a digital signature 
is required, obtains the P,Q,G, values from the active DSAKEYSFILE. It 
then provides these values, along with the User-furnished private key, to 
the DSA "signing" routine. This routine, after signaturing the file, 
returns two large integers designated R and S. These two integers can be 
stored within the file by the wrapping process. 
When this file is unwrapped, the unwrapping routine gets the P,Q,G values 
from the active DSAKEYSFILE. The file's R and S values, along with P,Q and 
G, and the User-supplied public key, are then passed on to the DSA 
signature verification routine. If there is no User-supplied public key, 
the public key from the active DSAKEYSFILE is used. 
The DSAKEYSFILE is an unblocked file which consists of records whose 
maximum record size is 60 words in length. The general information record 
contains miscellaneous data about the file, for example, version, number 
of search table records, number of key entries, etc. This record is then 
followed by one or more search table records which in turn, contain a 
number of four word search entries. Following the search table records are 
the data records with each containing a different set of [ID, software, 
public key, P,Q,G]. 
The main purpose of the DSAKEYSFILE is to store the P,Q,G primes used when 
creating public and private key pairs. It is also used to store frequently 
used public keys which are normally about 60 characters long, so the 
caller of Unwrap does not need to enter this character string every time 
an Unwrap process is requested on a digitally signatured file. 
This procedure involves a further procedure entitled "GET.sub.-- DSA.sub.-- 
PQGKEY" which obtains the corresponding set of [P,Q,G, public key] from 
the active DSAKEYSFILE and returns that set to the caller. 
FIG. 3 is an illustration of a WRAPPEDDATA file format which will be seen 
as a simple byte-stream file. This file shown in FIG. 3 will be seen to 
have a format of five different sections designated (i), (ii), (iii), (iv) 
and (v). 
(i) The word "UNISYS000010" will be EBCDIC data that would be used to 
indicate that this is likely to be a WRAPPED file. The number associated 
with this identifier may change if the format of this file changes. 
(ii) "Options" contains the options used when wrapping the file such as an 
indication of whether the entire file has been signatured, or checksummed 
along with the public key identifier for the file's signature. 
(iii) The Disk File Header is a copy of the actual A Series Disk File 
Header for the file. This will become the actual Disk File Header for the 
file when it is restored to its native format during unwrap. The Header 
checksum is a separate checksum for the Disk File Header itself. 
(iv) "The File" is the contents of the file itself, written as byte-stream 
data. 
(v) "Checksum" or "Digital Signature" will be either the checksum or the 
signature calculated for the file and the Disk File Header combined, using 
a private key from a public/private key pair. The "options" will indicate 
whether this is a signature or a checksum. 
ALGORITHMIC SEQUENCE FOR BURNING A COMT DISK INTO A STANDARD INDUSTRY 
FORMAT: FIGS. 2A (2A1, 2A2, 2A3, 2A4) and 2B illustrate the various 
sequential steps involved in programming a file which is taken from a 
first format system, such as an A Series file, and converting it to a 
standard industry format file which is compatible for other platforms, 
such as the NT platform. 
Referring to FIG. 2A-1, the source User will initiate the operation at 
marker cycle 101 for developing the Compact Disk by entering at step (a) 
the command WFL WRAP MY/FILE AS MY/NEW/FILE from Disk A to Disk B. 
At step (b), this command is parsed and passed from the WFL compiler 15 
over to the operating system 10 and into the program 36 designated 
MCP.sub.-- FILEWRAPPER. 
At step c(i), the MCP.sub.-- FILEWRAPPER program will then verify the names 
of the files, then open up a new file MY/NEW/FILE to be outputted: it will 
verify the options and then call step (e) as seen in FIG. 2A-1. 
At step (cii) FIG. 2A-4, the MCP.sub.-- FILEWRAPPER program will close and 
save the output file when the MCP.sub.-- WRAPPER program returns to the 
MCP.sub.-- FILEWRAPPER. It will then loop back to (c1). 
At step (d) an output procedure is executed which provides for an array of 
data file information and whereby this array is written to an output file 
(MY/NEW/FILE). Additionally, any I/O errors are returned to the User or 
caller. 
At step (e) of FIG. 2A-1 (which was invoked from step (c1) there is 
involved the MCP.sub.-- WRAPPER operation. At step (e) FIG. 2A-1, the 
software operation involves verifying the input file title, and opening 
the file; verifying the options for wrapping the file; verifying FIG. 2A 
the file license applicability by calling the operating system and 
verifying the feature key. 
Then subsequently, (as seen in FIGS. 2A-2 through 2A-4) the step (e) 
involves a series of sub-steps going from (e) (i) over to (e) (xii). These 
involve the following: 
At step (e) (i), FIG. 2A-2 the MCP-WRAPPER operation will copy the input 
files and send a Disk File Header to an intermediate local storage array 
in memory. This array provides temporary data storage so that there is no 
chance of accidentally acting on the "real" DFH or data for the file. 
Then at step (e)(ii), the MCP.sub.-- WRAPPER operation will add a checksum 
to the end of the array. 
At step (e) (iii), the program will save the checksum in a local variable, 
and then at step (e) (iv), it will call the output procedure (d) in order 
to Write the Disk File Header (DFH) to the output data file. 
Continuing from step (c) of FIG. 2A-1 which has called in the MCP.sub.-- 
WRAPPER operation step (e), it will be seen that the output procedure (d) 
is invoked by this step (e) at e (iv), FIG. 2A-2, MCP.sub.-- WRAPPER 
operation to pass the input file data over to be written to the new 
byte-stream data file at step (d), FIG. 2A-2. 
At step (e)(v), FIG. 2A-3, the software will cause a Read of the input file 
using disk row addresses of the Disk A, one at a time, until there are no 
more disk row addresses for the file. When the disk row addresses are 
exhausted, the software will proceed to step (e) (viii). Then at step (e) 
(vi), the program will pass information in the array onto the output 
procedure (d) in order to Write the array information to the output file. 
For descriptive purposes, the "input" file is the file being "Read", 
(MY/FILE) while the "output" file is the new file being created or written 
(MY/NEW/FILE). 
At step (e) (vii), the program calculates the running checksum for each row 
and adds this on to the checksum variable. Using the local checksum 
variable, a checksum is calculated for the entire file as it is being 
repackaged. This checksum will reside in the file and be later used by the 
unwrap operation to verify that the file was not unintentionally corrupted 
while transferring across a second system platform. 
Then at step (e) (viii), the program will call the output procedure (d) 
FIG. 2A-4 and pass the checksum to write the checksum value over to the 
output data file, (Disk B). 
At step (e) (ix), FIG. 2A-4, the program will close the input file, and at 
step (e) (x), will update the time-stamp information for the original file 
(A Series DFH Attribute Information). 
At step (e)(xi), the program will set time-stamps in the disk file header 
(DFH) for the input file (Disk A) and then return [step e(xii)] to the 
MCP.sub.-- FILEWRAPPER procedure from where it was called. 
MCP.sub.-- FILEWRAPPER continues at c(ii), FIG. 2A-4, and will then close 
and save the output file (MY/NEW/FILE) on Disk B. 
MCP.sub.-- FILEWRAPPER will then continue on to process the next file in 
its list (if there is one) by returning to c(i), FIG. 2A-1. Otherwise, if 
there are no new files to process, then MCP.sub.-- FILEWRAPPER will Exit, 
thus returning (with any error information) to its Caller. This completes 
the operation for marker cycle 101. 
Now referring to FIG. 2B, the source user will initiate at (f) the 
operation (marker cycle 102 of FIG. 1A) to drag the file (MY/NEW/FILE), 
using the Microsoft Explorer program, from the shared Disk B,22 over to 
the local Disk C,24 where it becomes 
C:.backslash.MY.backslash.NEW.backslash.FILE. Then Source User 8, using 
marker channel cycle 103 will initiate the CD Writer package. 
The shared disk would be a LAN connected Disk B owned by the first system, 
that the PC has access to. 
At step (g), on marker cycle 103 (of FIG. 1A and FIG. 2B), the User 8 will 
execute (within the client terminal 30), a CD-WRITER package in order to 
burn the file onto a Compact Disk, 34. 
At step (h), FIG. 2B, the Compact Disk 34, once it has been burned with the 
files, can be removed and delivered to a customer-client terminal for that 
party's PC (Personal Computer) platform. 
Described herein has been a method and system whereby native specialized 
files in a first computer system, can use the operating system of the 
first computer system together with first and second programmatic 
interfaces therein in order to transform a file (native to the first 
system) into a standard byte-stream file which is utilizable by many other 
types of computer platforms (second system), and which byte-stream files 
can be burned into a CD-ROM which is then available for utilization by 
multiple numbers of other system platforms. 
While other variations and embodiments of the described method may be 
implemented for various purposes, the invention is defined by the 
following claims appended herein.