Sun Java 2 V1.4 SDK or equivalent.
The utility of the data processed and stored on
IBM iSeries and AS/400 systems may be extended by copying the data to other
platforms, where additional processing capability is available. IBM systems
employ proprietary encoding schemes to store data and reformatting this data
for use on other platforms requires a description of its structure to guide
conversion. The structure of data stored on IBM systems is described using a
proprietary language that may be interpreted and translated to produce the
equivalent data structure description in a common standard language employed on
other platforms.
Users of the iSeries Data Migration
Toolkit (DMK) enables users of these IBM systems to easily migrate their
data files to any other platform, or into the Java environment of their iSeries
systems. It is a collection of tools, executing on these other platforms, that
translate physical file Data Description Specifications (DDS) into equivalent
Extensible Markup Language (XML) descriptions, and create Java programs from
these data structure descriptions for reformatting iSeries binary data for
loading into files or databases, or for analysis. The XML descriptions enable
these other platforms to have the equivalent record structure description
capability that DDS provides for the iSeries systems. The toolkit uses and
generates standard Java as distributed freely by Sun in their SDK. The DMK is
platform-independent and no software other than a text editor and the SDK are
required. A DMK for System/38 DDS and data may be special ordered.
DDS source files and binary data files are copied
from the iSeries or AS/400 system over the user's local area network (LAN) into
a connected system. If LAN connectivity to the AS/400 is not available, the
source files and binary data are copied to removable media readable by the
target system. DDS source file encoding translation from EBCDIC into ASCII is
normally automatically provided by the means used for copying between systems.
Custom translators for iSeries source files with encodings untranslatable into
UTF-8 may be special ordered.
Physical
file DDS source files written in the proprietary IBM specification
language are translated into XML, using tags derived from the DDS language. The
entire DDS specification is translated.
Specifications and overrides referencing previously translated field reference
files are substituted when the resulting XML description
is next used. An example Java program for reading and processing XML is
included. The program uses the Simple API for XML (SAX) to read and parse the
XML.
DDS field
reference files, the data dictionary feature of DDS, are first converted to XML, then translated
into Document Type Definition (DTD) files to provide substitution entities for
XML file descriptions coded with substitutable references. Changes to the field
reference XML are propagated to referencing descriptions when next used. This
DMK feature parallels the use of field reference files on iSeries systems.
The generated XML descriptions are used by the
toolkit to produce ANSI SQL Data Definition Language (DDL) schemas. The schema generator utilizes a
commonly-used subset of DDS positional and keyword
parameters. Date and time fields are described as plain text fields, because
correct date and time translation depends on the combination of source locale
and the target database. Custom implementation of these and other keywords may
be provided on special order.
The DMK generates Java source code programs from XML file descriptions for
conversion of iSeries binary data into Unicode comma-delimited text. The
conversion programs translate binary data field-by-field and record-by-record.
Fields are translated according to their data types and other specifications
from the subset mentioned. Text field translation is dependent
on the encoding configuration of the source iSeries system as specified by DDS
CCSID keyword parameters or as specified by the user. EBCDIC single-byte
character (SBCS) and double-byte (DBCS) to Unicode conversions are supported
through Java classes from the Java SDK. Some 40 national EBCDIC encodings
and their variants are directly supported. Custom encodings may be special
ordered.
The Java conversion programs are easily adaptable
by programmers to reformat data files into XML for export to other
environments, or for direct insertion of records into flat files, or rows into
relational tables, without intermediate loader files. An alternative use of the
method allows XML-described fixed record length binary data files from any
source to be translated, including non-IBM multi-byte encodings. Custom conversion
program generators may be special ordered.
iSeries programming languages permit the use of
special characters (asterisks, etc.) in file, record and field names. Such characters
are usually illegal or have special meaning in other programming languages,
including Java. The DDS translator provides default or user-defined
substitution of such characters.
Use of the DDS ALIAS keyword parameter allows the
toolkit to optionally substitute long data field names in DDL schema for the
abbreviations imposed by the fixed form DDS field name specification. Custom
logic for file, record and field name substitution may also be developed on
special order.
Purchase the toolkit now. Responsive email
support is free for toolkit licensees.
If you prefer, send us your
DDS files for processing with the toolkit procedures.
Field Type |
Data Conversion |
Text |
yes |
Zoned Decimal |
yes |
Binary |
yes |
Floating point |
yes |
Hexadecimal |
special order |
Date |
alphanumeric |
Time |
alphanumeric |
Timestamp |
alphanumeric |
Keyword Parameter |
Description |
Translated Into XML |
Translated Into DTD |
Used In Data Conversion |
ABSVAL |
Absolute Value |
yes |
|
|
ALIAS |
Alternative Name |
yes |
yes |
|
ALTSEQ |
Alternative Collating Sequence |
yes |
|
|
ALWNULL |
Allow Null Value |
yes |
|
|
CCSID |
Coded Character Set Identifier |
yes |
|
yes |
CHECK |
Check |
yes |
yes |
|
CHKMSGID |
Check Message Identifier |
yes |
yes |
|
CMP |
Comparison |
yes |
yes |
|
COLHDG |
Column Heading |
yes |
yes |
|
COMP |
Comparison |
yes |
yes |
|
DATFMT |
Date Format |
yes |
yes |
special |
DATSEP |
Date Separator |
yes |
yes |
special |
DESCEND |
Descend |
yes |
|
|
DFT |
Default |
yes |
|
|
DIGIT |
Digit |
yes |
|
|
EDTCDE |
Edit Code |
yes |
yes |
|
EDTWRD |
Edit Word |
yes |
yes |
|
FCFO |
First-Changed First-Out |
yes |
|
|
FIFO |
First-In First-Out |
yes |
|
|
FLTPCN |
Floating-Point Precision |
yes |
yes |
yes |
FORMAT |
Format |
yes |
|
yes |
LIFO |
Last-In First-Out |
yes |
|
|
NOALTSEQ |
No Alternative Collating
Sequence |
yes |
|
|
RANGE |
Range |
yes |
|
|
REF |
Reference |
yes |
|
yes |
REFFLD |
Referenced Field |
yes |
|
yes |
REFSHIFT |
Reference Shift |
yes |
yes |
|
TEXT |
Text |
yes |
no |
|
TIMFMT |
Time Format |
yes |
yes |
special |
TIMSEP |
Time Separator |
yes |
yes |
special |
UNIQUE |
Unique |
yes |
|
yes |
UNSIGNED |
Unsigned |
yes |
|
|
VALUES |
Values |
yes |
|
|
VARLEN |
Variable-Length Field |
yes |
yes |
yes |
ZONE |
Zone |
yes |
|
|
CCSID |
SDK Support |
Description |
37 |
Cp037 |
US, Canada, Netherlands, Portugal,
Brazil, New Zealand, Australia |
256 |
|
Netherlands |
273 |
Cp273 |
Austria, Germany |
277 |
Cp277 |
Denmark, Norway |
278 |
Cp278 |
Finland, Sweden |
280 |
Cp280 |
Italy |
284 |
Cp284 |
Catalan/Spain, Spanish Latin
America |
285 |
Cp285 |
United Kingdom, Ireland |
290 |
|
Japan Katakana (extended) range |
297 |
Cp297 |
France |
300 |
|
Japan, English |
420 |
Cp420 |
Arabic |
423 |
|
Greece |
424 |
Cp424 |
Hebrew |
500 |
Cp500 |
Belgium, Canada, Switzerland, International
Latin-1 |
833 |
|
Korea (extended range) |
834 |
|
Korea Host DBCS |
835 |
|
DBCS Traditional Chinese Host |
838 |
Cp838 |
Thailand extended SBCS |
870 |
Cp870 |
Latin 2 Multilingual |
871 |
Cp871 |
Iceland |
875 |
Cp875 |
Greek |
880 |
|
Cyrillic Multilingual |
892 |
|
EBCDIC, OCR A |
893 |
|
EBCDIC, OCR B |
905 |
|
Turkey Latin-3 |
918 |
Cp918 |
Pakistan (Urdu) |
924 |
|
Latin 9 |
930 |
Cp930 |
Japanese Katakana-Kanji mixed
with 4370 UDC, superset of 5026 |
933 |
Cp933 |
Korean Mixed with 1880 UDC,
superset of 5029 |
935 |
Cp935 |
Simplified Chinese Host mixed
with 1880 UDC, superset of 5031 |
937 |
Cp937 |
Traditional Chinese Host mixed
with 6204 UDC, superset of 5033 |
939 |
Cp939 |
Japanese Latin Kanji mixed with
4370 UDC, superset of 5035 |
1025 |
Cp1025 |
Multilingual Cyrillic: Bulgaria,
Bosnia, Herzegovina, Macedonia (FYR) |
1026 |
Cp1026 |
Latin-5 Turkey |
1027 |
|
Japanese (Latin) Extended |
1069 |
|
Latin 4 |
1087 |
|
Symbol Set (Adobe) |
1097 |
Cp1097 |
Iran (Farsi)/Persian |
1110 |
|
Latin 2 Multilingual |
1112 |
Cp1112 |
Baltic Multilingual |
1113 |
|
Latin 6 |
1122 |
Cp1122 |
Estonia |
1123 |
Cp1123 |
Ukraine |
1130 |
|
Vietnamese |
1132 |
|
Lao |
1136 |
|
Hitachi Katakana |
1137 |
|
Devanagari |
1140 |
Cp1140 |
Variant of Cp037 with Euro
character |
1141 |
Cp1141 |
Variant of Cp273 with Euro
character |
1142 |
Cp1142 |
Variant of Cp277 with Euro
character |
1143 |
Cp1143 |
Variant of Cp278 with Euro
character |
1144 |
Cp1144 |
Variant of Cp280 with Euro
character |
1145 |
Cp1145 |
Variant of Cp284 with Euro
character |
1146 |
Cp1146 |
Variant of Cp285 with Euro
character |
1147 |
Cp1147 |
Variant of Cp297 with Euro character
|
1148 |
Cp1148 |
Variant of Cp500 with Euro
character |
1149 |
Cp1149 |
Variant of Cp871 with Euro
character |
1153 |
|
Latin 2 Multilingual with euro |
1154 |
|
Cyrillic Multilingual with euro |
1155 |
|
Turkey with euro |
1156 |
|
Baltic Multi with euro |
1157 |
|
Estonia with euro |
1158 |
|
Cyrillic, Ukraine with euro |
1164 |
|
Vietnamese with euro |
1165 |
|
Latin 2 EBCDIC/Open Systems |
1364 |
|
EBCDIC |
1388 |
|
EBCDIC |
4396 |
|
Japanese Host DB including 1880 |
5026 |
|
EBCDIC, Subset of 933 |
5035 |
|
EBCDIC |
5123 |
|
EBCDIC |
8482 |
|
Host SBCS Katakana |
9030 |
|
Thailand |
28709 |
|
SBCS Traditional Chinese Host
(w/ euro update) |
The AS/400 source code examples referenced
on this page are from "Application System/400 Application Development by
Example", SC41-9852-00, International Business Machines Corporation, 1991.
A* MLGREFP - Mailing list field reference file
A R MLGREFR TEXT('Mailing list ref')
A MLACCT 5 0 COLHDG('Account' +
A 'number')
A EDTCDE(X)
A MLTYPE 1 COLHDG('Type')
A VALUES('1' '2' '3' +
A '4' '5' '9')
A TEXT('Acct type- +
A 1=Bus 2=Gov 3=Org +
A 4=Sch 5= Pvt 9=Oth')
A MLNAME 20 COLHDG('Name')
A MLSRCH 10 COLHDG('Search')
A TEXT('Search field for +
A name search')
A MLADDR 20 COLHDG('Addr')
A MLCITY 20 COLHDG('City')
A MLSTAT 2 COLHDG('State')
A VALUES('AL' 'AK' 'AZ' +
A 'AR' 'CA' 'CO' 'CT' +
A 'DE' 'DC' 'FL' 'GA' +
A 'HI' 'ID' 'IL' 'IN' +
A 'IA' 'KS' 'KY' 'LA' +
A 'ME' 'MD' 'MA' 'MI' +
A 'MN' 'MS' 'MO' 'MT' +
A 'NE' 'NV' 'NH' 'NJ' +
A 'NM' 'NY' 'NC' 'ND' +
A 'OH' 'OK' 'OR' 'PA' +
A 'RI' 'SC' 'SD' 'TN' +
A 'TX' 'UT' 'VT' 'VA' +
A 'WA' 'WV' 'WI' 'WY')
A MLZIP 5 0 COLHDG('ZIP' 'code')
A EDTCDE(X)
This file is automatically generated from the
XML field reference and does not need to be updated manually.
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY mlgrefp_mlgrefr_mlacct '
<fmt type="P" length="5" edtcde="X"></fmt>
<colhdg>Account</colhdg>
<colhdg>number</colhdg>
'>
<!-- Acct type- 1=Bus 2=Gov 3=Org 4=Sch 5= Pvt 9=Oth -->
<!ENTITY mlgrefp_mlgrefr_mltype '
<fmt type="A" length="1"></fmt>
<colhdg>Type</colhdg>
<value>1</value>
<value>2</value>
<value>3</value>
<value>4</value>
<value>5</value>
<value>9</value>
'>
<!ENTITY mlgrefp_mlgrefr_mlname '
<fmt type="A" length="20"></fmt>
<colhdg>Name</colhdg>
'>
<!-- Search field for name search -->
<!ENTITY mlgrefp_mlgrefr_mlsrch '
<fmt type="A" length="10"></fmt>
<colhdg>Search</colhdg>
'>
<!ENTITY mlgrefp_mlgrefr_mladdr '
<fmt type="A" length="20"></fmt>
<colhdg>Addr</colhdg>
'>
<!ENTITY mlgrefp_mlgrefr_mlcity '
<fmt type="A" length="20"></fmt>
<colhdg>City</colhdg>
'>
<!ENTITY mlgrefp_mlgrefr_mlstat '
<fmt type="A" length="2"></fmt>
<colhdg>State</colhdg>
<value>AL</value>
<value>AK</value>
<value>AZ</value>
<value>AR</value>
<value>CA</value>
<value>CO</value>
<value>CT</value>
<value>DE</value>
<value>DC</value>
<value>FL</value>
<value>GA</value>
<value>HI</value>
<value>ID</value>
<value>IL</value>
<value>IN</value>
<value>IA</value>
<value>KS</value>
<value>KY</value>
<value>LA</value>
<value>ME</value>
<value>MD</value>
<value>MA</value>
<value>MI</value>
<value>MN</value>
<value>MS</value>
<value>MO</value>
<value>MT</value>
<value>NE</value>
<value>NV</value>
<value>NH</value>
<value>NJ</value>
<value>NM</value>
<value>NY</value>
<value>NC</value>
<value>ND</value>
<value>OH</value>
<value>OK</value>
<value>OR</value>
<value>PA</value>
<value>RI</value>
<value>SC</value>
<value>SD</value>
<value>TN</value>
<value>TX</value>
<value>UT</value>
<value>VT</value>
<value>VA</value>
<value>WA</value>
<value>WV</value>
<value>WI</value>
<value>WY</value>
'>
<!ENTITY mlgrefp_mlgrefr_mlzip '
<fmt type="P" length="5" edtcde="X"></fmt>
<colhdg>ZIP</colhdg>
<colhdg>code</colhdg>
'>
<?xml version="1.0" encoding="UTF-8"?>
<!-- MLGREFP - Mailing list field reference file -->
<file name="mlgrefp">
<!-- Mailing list ref -->
<record name="mlgrefr">
<field name="mlacct">
<fmt type="P" length="5" edtcde="X"></fmt>
<colhdg>Account</colhdg>
<colhdg>number</colhdg>
</field>
<!-- Acct type- 1=Bus 2=Gov 3=Org 4=Sch 5= Pvt 9=Oth -->
<field name="mltype">
<fmt type="A" length="1"></fmt>
<colhdg>Type</colhdg>
<value>1</value>
<value>2</value>
<value>3</value>
<value>4</value>
<value>5</value>
<value>9</value>
</field>
<field name="mlname">
<fmt type="A" length="20"></fmt>
<colhdg>Name</colhdg>
</field>
<!-- Search field for name search -->
<field name="mlsrch">
<fmt type="A" length="10"></fmt>
<colhdg>Search</colhdg>
</field>
<field name="mladdr">
<fmt type="A" length="20"></fmt>
<colhdg>Addr</colhdg>
</field>
<field name="mlcity">
<fmt type="A" length="20"></fmt>
<colhdg>City</colhdg>
</field>
<field name="mlstat">
<fmt type="A" length="2"></fmt>
<colhdg>State</colhdg>
<value>AL</value>
<value>AK</value>
<value>AZ</value>
<value>AR</value>
<value>CA</value>
<value>CO</value>
<value>CT</value>
<value>DE</value>
<value>DC</value>
<value>FL</value>
<value>GA</value>
<value>HI</value>
<value>ID</value>
<value>IL</value>
<value>IN</value>
<value>IA</value>
<value>KS</value>
<value>KY</value>
<value>LA</value>
<value>ME</value>
<value>MD</value>
<value>MA</value>
<value>MI</value>
<value>MN</value>
<value>MS</value>
<value>MO</value>
<value>MT</value>
<value>NE</value>
<value>NV</value>
<value>NH</value>
<value>NJ</value>
<value>NM</value>
<value>NY</value>
<value>NC</value>
<value>ND</value>
<value>OH</value>
<value>OK</value>
<value>OR</value>
<value>PA</value>
<value>RI</value>
<value>SC</value>
<value>SD</value>
<value>TN</value>
<value>TX</value>
<value>UT</value>
<value>VT</value>
<value>VA</value>
<value>WA</value>
<value>WV</value>
<value>WI</value>
<value>WY</value>
</field>
<field name="mlzip">
<fmt type="P" length="5" edtcde="X"></fmt>
<colhdg>ZIP</colhdg>
<colhdg>code</colhdg>
</field>
</record>
</file>
A* MLGMSTP - Mailing list master physical file
A REF(MLGREFP)
A UNIQUE
A R MLGMSTR TEXT('Mailing list +
A master record')
A MLACCT R
A MLTYPE R
A MLNAME R
A MLSRCH R
A MLADDR R
A MLCITY R
A MLSTAT R
A MLZIP R
A K MLACCT
This is what is seen internally by the XML
parser when the XML is read. Substitutions are inserted automatically into the
XML from the reference DTD.
<?xml version='1.0' encoding='UTF-8'?>
<file name="mlgmstp" unique="yes">
<record name="mlgmstr">
<field name="mlacct">
<fmt type="S" length="5" edtcde="X"></fmt>
<colhdg>Account</colhdg>
<colhdg>number</colhdg>
</field>
<field name="mltype">
<fmt type="A" length="1"></fmt>
<colhdg>Type</colhdg>
<value>1</value>
<value>2</value>
<value>3</value>
<value>4</value>
<value>5</value>
<value>9</value>
</field>
<field name="mlname">
<fmt type="A" length="20"></fmt>
<colhdg>Name</colhdg>
</field>
<field name="mlsrch">
<fmt type="A" length="10"></fmt>
<colhdg>Search</colhdg>
</field>
<field name="mladdr">
<fmt type="A" length="20"></fmt>
<colhdg>Addr</colhdg>
</field>
<field name="mlcity">
<fmt type="A" length="20"></fmt>
<colhdg>City</colhdg>
</field>
<field name="mlstat">
<fmt type="A" length="2"></fmt>
<colhdg>State</colhdg>
<value>AL</value>
<value>AK</value>
<value>AZ</value>
<value>AR</value>
<value>CA</value>
<value>CO</value>
<value>CT</value>
<value>DE</value>
<value>DC</value>
<value>FL</value>
<value>GA</value>
<value>HI</value>
<value>ID</value>
<value>IL</value>
<value>IN</value>
<value>IA</value>
<value>KS</value>
<value>KY</value>
<value>LA</value>
<value>ME</value>
<value>MD</value>
<value>MA</value>
<value>MI</value>
<value>MN</value>
<value>MS</value>
<value>MO</value>
<value>MT</value>
<value>NE</value>
<value>NV</value>
<value>NH</value>
<value>NJ</value>
<value>NM</value>
<value>NY</value>
<value>NC</value>
<value>ND</value>
<value>OH</value>
<value>OK</value>
<value>OR</value>
<value>PA</value>
<value>RI</value>
<value>SC</value>
<value>SD</value>
<value>TN</value>
<value>TX</value>
<value>UT</value>
<value>VT</value>
<value>VA</value>
<value>WA</value>
<value>WV</value>
<value>WI</value>
<value>WY</value>
</field>
<field name="mlzip">
<fmt type="S" length="5" edtcde="X"></fmt>
<colhdg>ZIP</colhdg>
<colhdg>code</colhdg>
</field>
<key name="mlacct"></key>
</record>
</file>
Standard ANSI SQL Data Definition Language
schema used for relational table definition.
CREATE TABLE mlgmstp (
mlacct SMALLINT(5),
mltype CHAR(1),
mlname CHAR(20),
mlsrch CHAR(10),
mladdr CHAR(20),
mlcity CHAR(20),
mlstat CHAR(2),
mlzip SMALLINT(5)
)
<?xml version="1.0" encoding="UTF-8"?>
<!-- MLGMSTP - Mailing list master physical file -->
<!DOCTYPE file SYSTEM "mlgrefp.dtd">
<file name="mlgmstp" unique="yes">
<!-- Mailing list master record -->
<record name="mlgmstr">
<field name="mlacct">
&mlgrefp_mlgrefr_mlacct;
</field>
<field name="mltype">
&mlgrefp_mlgrefr_mltype;
</field>
<field name="mlname">
&mlgrefp_mlgrefr_mlname;
</field>
<field name="mlsrch">
&mlgrefp_mlgrefr_mlsrch;
</field>
<field name="mladdr">
&mlgrefp_mlgrefr_mladdr;
</field>
<field name="mlcity">
&mlgrefp_mlgrefr_mlcity;
</field>
<field name="mlstat">
&mlgrefp_mlgrefr_mlstat;
</field>
<field name="mlzip">
&mlgrefp_mlgrefr_mlzip;
</field>
<key name="mlacct"></key>
</record>
</file>
This is the Java source program for converting
binary data copied from the iSeries, into a comma-delimited format suitable for
loading into a relational table.
// Cmlgmstp.java - convert iSeries binary file to loader format (Aug 17, 1999)
// usage: java Cmlgmstp iSeries-filename aposfilp_'member-name'
import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;
public class Cmlgmstp {
static final int BUFFER_LENGTH = 518;
static String newLine = new String(System.getProperty("line.separator"));
static byte buffer[] = new byte[BUFFER_LENGTH];
static int bytesRead = 0;
static String line = "";
static long recordsOutput = 0;
public static void main(String args[]) {
if (args.length < 2) {
System.err.println("usage: java Cmlgmstp binary-filename mlgmstp-'member-name'");
System.exit(-1);
}
FromIBM.decoder(new sun.io.ByteToCharCp037());
try {
BufferedInputStream in = new BufferedInputStream(new FileInputStream(args[0]));
BufferedWriter out = new BufferedWriter(new FileWriter(args[1]));
while (true) {
bytesRead = in.read(buffer, 0, BUFFER_LENGTH);
if (bytesRead == -1) {
in.close();
out.close();
System.out.println(args[0] + " converted to " + args[1] + ", "
+ recordsOutput + " records" + newLine);
System.exit(0);
}
FromIBM.start();
line = "";
line = FromIBM.convert(line, buffer, 'P', 5, 0); // mlacct
line = FromIBM.convert(line, buffer, 'A', 1, 0); // mltype
line = FromIBM.convert(line, buffer, 'A', 20, 0); // mlname
line = FromIBM.convert(line, buffer, 'A', 10, 0); // mlsrch
line = FromIBM.convert(line, buffer, 'A', 20, 0); // mladdr
line = FromIBM.convert(line, buffer, 'A', 20, 0); // mlcity
line = FromIBM.convert(line, buffer, 'A', 2, 0); // mlstat
line = FromIBM.convert(line, buffer, 'P', 5, 0); // mlzip
out.write(line + newLine);
recordsOutput++;
}
}
catch (IOException exception) {
exception.printStackTrace(System.err);
}
catch (Exception exception) {
exception.printStackTrace(System.err);
}
System.exit(-1);
}
}
You should
carefully read the DMK User License before purchasing the iSeries
Data Migration Toolkit.
Purchase
and receive the iSeries Data Migration Toolkit by email for USD $100.00
The
following files are included in the DMK (in file dmk.jar).
File |
Description |
p2x.class |
Physical file DDS to XML
translator |
x2d.class |
XML to reference DTD translator |
x2s.class |
XML to DDL schema translator |
FromIBM.class |
iSeries binary data translator |
xml.java |
Example XML parser |
index.html |
iSeries Data Migration Toolkit
(DMK) |
p2x.html |
Physical file DDS to XML
translator documentation |
x2d.html |
XML to reference DTD translator
documentation |
x2s.html |
XML to DDL schema translator
documentation |
FromIBM_index.html |
iSeries binary data translator
documentation |
xml.html |
Example XML parser documentation |
download_ibm.html |
Downloading files from iSeries |
<other>.html |
Other documentation files |
1. Unless
you have a different license agreement signed by CyberPlan, your use of
CyberPlan Software indicates your acceptance of this license agreement and
warranty.
You should carefully read the File Processing Services Agreement before
purchasing services using the iSeries Data Migration Toolkit.
Send us your DDS files for
processing with the iSeries Data Migration Toolkit at USD $10.00 per file.
Include all necessary DDS field reference files in the total file count.
Instructions for copying, preparing and sending us your files via email will be
displayed after your order is processed.
iSeries
binary file conversions are not included. Email us with your requirements for
on-site project pricing.
Unless you have a different File
Processing Services agreement signed by CyberPlan, your use of CyberPlan
processing services indicates your acceptance of this processing services
agreement and warranty.
Select the files you require and download
them onto the system that you will be using for sending the files. Attach the
files to an email message directed to v5234647@hotmail.com. The return address
on the email should be the same as the one used to place your processing order
with us.
In the email message, list the
files that you are sending, identifying the file type:
If you have made a special order
you may send us unprocessed binary files. Please also identify these as such.
If you value the privacy of the
files that you are transmitting, please use any of the common compression
utilities that permit encryption of the files with a password, WinZip for
example; write us that the files are protected and with which utility program;
and send us the password by a separate email.
If your source code contains trade
secrets or other confidential information, we can provide you with software
that will replace comments and meaningful names in your code with generated
numbered sequential tags, before you send the code to us. After receiving the
results from us a reverse transformation restores the original text in the
processed files from archived dictionaries.
Detailed documentation on network
connectivity and file transfer between your iSeries and connected systems
should be used as a reference. Only a brief outline using the FTP (File
Transfer Protocol) follows.
If not already done, add the address
and computer name of the iSeries to the hosts file:
The entries in the hosts file will look like the following:
127.0.0.1 localhost
128.0.0.6 as400
Verify that the local machine
TCP/IP address is valid for the network you are connecting to. Execute the ping program to test the connection to
the iSeries. For example, if the name of the iSeries is as400 and is listed in
the hosts file,
then execute the following command:
ping as400
If you
are properly connected, you should see the message "Reply from ..."
every few seconds. If "Request
timed out" appears, there is a problem with the
connection.
FTP is used to copy source files
between machines. FTP equates an AS/400 library to a UNIX or Windows directory.
FTP further equates a source file and its members to UNIX or Windows plain text
files in the following way:
QDDSSRC <member> ::=
QDDSSRC.<member>
CyberPlan's migration practice is
to retain the iSeries library structure as lowercase subdirectories of an
application root directory.
From the command line in UNIX or
Windows run the following FTP commands:
ftp as400 (login to FTP)
password: (enter as400 password)
prompt (toggle off prompting for each file transferred)
ascii (toggle on EBCDIC to ASCII conversion)
For every library containing source
code:
cd <change directory of iSeries sending library>
lcd <change directory of each local receiving directory>
To copy all members of all iSeries
source files:
gets QDDSSRC.*
gets QCMDSRC.*
gets QCLSRC.*
gets QRPGSRC.*
gets QCBLSRC.*
gets <your source file>.*
Sometimes the FTP EBCDIC to ASCII
translation is inadequate for full representation in Unicode. You may special
order a custom EBCDIC source file encoding translator that operates on binary
files copied unchanged from the iSeries, as shown below.
The procedure for downloading data
or binary (untranslated) files is similar to source file downloading. Switch to
untranslated transmission:
binary (toggle off EBCDIC to ASCII conversion)
Change to the required libraries
and directories as above, and transfer your data files:
gets <your file>.* (to copy all members of the file)
get <your file>.<member> (to copy a member of a file)
Copyright © 2002 by CyberPlan. All rights reserved.
Last
revision on Nov 12, 2002