IMWin technical specifications.

IMWIN is a highly sophisticated program, where the user can "tailor" conversions via a lot of options.

It uses some purpose-built hardware, i.e. an 8-bit ISA controller implementing a 80186 microprocessor, and two types of data separators (this will allow you to have all supported drives in one box).

If the conversion of disks is not required, you can do without the ISA controller, and have a dongle system instead.

Logically, a conversion goes through 3-4 steps, depending on the functions required.

As an example, we will discuss a file conversion from 5.25" CP/M wordprocessor disks to a 3420 medium (reel-to-reel tape), to be used for microfiche, with intermediate storage on a harddisk.

Step 1: reading the CP/M disk

As PC's cannot read CP/M disks, we need the relevant floppy drive (typically 5.25", connected to a special controller (a 80186-based InterMedia-developped controller), plus the handler needed to read the disk physically. Furthermore, we need the handler to read the format in question, as there is an abundance of CP/M formats (so far we have found about 500 really different formats, plus umpteen variants).

The purpose of these handlers is to deliver data to Step 2 in a civilized way, so we get all data sectors in the right order, etc. However, the content of the file is not important at this stage.

Step 2: converting the data

At this stage, we don't care on how the data originally was presented. We just know, that we get a stream of bytes.

These bytes can have very strange appearances, and to handle those, we can use up to 6 translation tables and 1 protocol.

Each translationtable has the following possibilities:

Convert 1 character to 0..32 others
examples: Unix 0x0D can be converted to DOS 0x0D0A; conversion of national characters;
Convert 1..32 characters to 0..32 others
example: convert all dates from 1999.10.01 to 1999.09.30
Convert 1..32 characters to something else, depending on conditions
A typical example is the conversion of text originating from word processors. A characacter string like 1,3 can mean either one-point-three, but also underline & italic in a specific word processor. In other words, 1,3 must be handled in a specific way, depending on whether it is within an escapesequence (e.g. <esc>0,1,3,P,XT,font=11<esc>) or it is a part of some text in the document, e.g. " It has been noticed that 1,3 percent of the smokers has a nice mother-in-law". Many of the texts originating from a word processor can only be processed via a special program, which is called a protocol (Windows DLL). This will ensure that all (documented) functions will be converted to an intermediate file format. As output protocol read the intermediate and convert it to the appropriate format, it will in fact enable a conversion from e.g. Screentyper or Notis WP to HTML format.

At present, IMWin supports some 80-90 different word processorformats on the inputside, and about 30 on the output side.

Protocols come in two flavours: user-defineable and "fixed in concrete"

The unmodifyable ones are programmed for one task only, e.g. converting 6 bit character sets to 8 bit character set, or automatic EBCDIC-ASCII conversion, or for handling a specific word processor format, or for UNZIPping files.

The user-defineable ones are the Record Reformatter, the Sort and the Validate Protocol

The functions these protocols are defined by the user. We can take the Validate protocol as en example: its function is to read the data presented to step 2, modify/validate it in some way, and write it to the harddisk.

However, exactly WHAT it does with the data (checking social security numbers, postcodes, date validity checking, seeing if a company if blacklisted, or whatever), is defined by the user.

Step 3: storing on harddisk

It is always recommended to save the data to a disk, so reruns don't need the input media.

Step 4: converting the data to ASA format

Normally, the data is copied in a very simple way, e.g. a 0x0C (formfeed) is converted to '1'. However, we will also have to handle fixed length lines, multiple skip, channel skipping, etc.

A protocol and/or translationtables can therefore be appropriate, depending on the format of the data, as read from the disk.

Step 5: writing the data to a reel-to-reel tape

Here we find again a multitude of possitibilities, such as:

which drive to write to (QIC, DAT, Exabyte, 3480, …)
do I want standard labels or ASCII labels
which characterset do I need to use

Apart from the conversion proper, a number of very useful routines are implemented:

drop a specified number of bytes from the start of the file (useful if specific headers are used)
ignore specified filenames / extensions (useful in avoiding COM and EXE files)
only convert specified filenames / extensions (e.g. *.DAT, *.TXT, ...)
split files (e.g. when writing to media / operating systems which dont support multi volume)
automatic rename
automatic serialization (very useful if customers send files with the same filename, like ORDERS.DAT. This will avoid files being overwritten unintentionally)
scheduler (perform specific tasks at a given time)
automatic running
support of barcodes
media duplication

Application notes.

Automatic media conversion.

We have developped some very fancy routines using automatic running and barcode support.

Originally developped for the now demised Octopus system back in 1988, the system is still in production, but now modified/rewritten for InterMedia use.

The problem to be solved, was this: "We receive an undefined (but large) number of floppies and streamers every day, we don't want to sort through them, and we want to automatize it as much as possible. Same procedure for output."

The physical handling of disks was very easy, as autoloaders were readily available. Mounting barcode scanners inside the autoloaders, made it possible to generate customized autorun routines, as the barcode could contain data like customer number, format name, project number, or whatever was appropriate. In short: disks could be tossed into the autoloader, regardless of format, project, disk format, and the generated autorun routines would place the converted data in the proper directories.

When the input part had finished, a number of special-purpose disks (standard disks without data, but with specialized barcodes) were loaded, which would e.g. copy data to a tape, or send data to the mainframe.

The output part of the project was similar: the mainframe would deliver all data in one file, we had to split it up, write appropriate barcode labels, attach them to the proper media, and write the data to the media.

Front-end for audit purposes

With all respect for audit programs like IDEA and ACL, we must admit that their conversion routines do not live up to what external auditors need in many cases, which is illustrated by the fact that most of the Big 5 either have InterMedia systems or use us as a service bureau.

Front-end for microfiche and laserprint generation

Customers all over Europe have selected InterMedia in order to be able to service the largest possible number of customers, who have decided to outsource print jobs and/or microfiche generation.

Data collection system

We have sold various system, e.g. to Danish Tax authorities, which do not use IMWin in the way it was originally intended, but "merely" as a data collection system. The system will also generate a daily or weekly tape, containing all data (project related) collected during the week, for processing on the mainframe.

Other users use an abridged version, solely to read 1 format, e.g. standard labelled IBM tapes.