1. We have WebSphere in house. Can a transformed system use WebSphere?

Yes. LeTS can generate standard Java Bean components or EJB components to work with WebSphere or other application servers such as BEA's WebLogic or the open source JBOSS. Most of the differences between the various application servers is in the implementation details, not the form of the Java classes run on them.

2. We have a strict set of naming standards that must be followed. How is this handled during a transformation project?

Naming standards are implemented in two ways by the LeTS transformation process:

• Cobol names are transformed to Java names using a default algorithm (for example, Cobol data name CURRENT-DATE becomes Java name currentDate). This algorithm can be altered to fit user naming standards (for example, Cobol data name CURRENT-DATE becoming Java name Current_Date).
• Naming standards may be implemented by synonyming. Synonyming is implemented by means of a synonym list of the form "new_name=old-name". During the transformation whenever old-name is processed it is automatically replace by new_name. The synonym algorithm will repeat the synonym search up to seven times so quite sophisticated naming standards may be implemented.

3. We have strict coding standards. Can your transformation process include these standards?

In general yes. The Java code generated by the LeTS transformation process is specified in a "code format table". The format entries may be altered to implement some coding standards. More advanced standards may be implemented by writing customized generation code. Please contact us for additional information

4. Why are all the Cobol data fields transformed to Java objects? Wouldn't it be more efficient to use the Java primitives where possible?

Cobol data fields are transformed to objects because a Cobol data field is not simply a storage area for data. Cobol data fields carry additional information such as edit pictures, storage classes, alignment information, etc. If we implemented a Cobol comp field as a Java primitive integer then every time the data was accessed we would have to code the editing, alignment, blank when zero, etc features in the mainline code. One of the advantages of an object oriented language like Java is that we can encapsulate these behaviors in the data object. Then we can use the data object without having to worry about the various behaviors. They will be handled by methods in the data object without the developer having to repeatedly recode them.