************************************* * * * DB/C Newsletter * * February 1998 * * * ************************************* News and Comments The focus of this month's DB/C Newsletter is once again Java. There is an ongoing war of words between Microsoft and the various Java proponents. The battle is being waged to win the throne of programming language dominance. Microsoft's entrant is Visual Basic and its sibling Visual Basic for Applications. Sun and IBM are the primary forces behind Java. Some industry pundits have ceded the entire software industry to Microsoft. In their view, Bill Gates is omnipotent - whatever he produces succeeds and destroys all other products. We don't believe that. At Subject, Wills & Company, our preferred platform solution is UNIX. And if you ask us which LAN software is better, we'll tell you Novell Netware, even as we wholeheartedly embrace NT Server. I don't think we're alone. With DB/C JX, Subject, Wills & Company is making a big commitment to Java. This is the reason for our first article this month - On the Reasons for Choosing Java. If you plan to move your DATABUS applications into the Java world, you should consider DB/C JX. It's a great conversion tool as well as a viable long term Java-based solution. We are in the final phases of beta testing DB/C JX. It will be moved into production in next 60 days. To help you understand DB/C JX, the second article provides an overview of the issues involved in moving from traditional DB/C or DATABUS to DB/C JX. Another new product, DB/C FS, is also being beta tested, although progress on it is slower than we had hoped. We will cover DB/C FS in depth in future DB/C Newsletters. don.wills@swc.com On the Reasons for Choosing Java When Java was introduced a few years ago, it was labeled "the language of the Internet". Netscape implemented Java as the portable solution to the need for a programming language in their web browser. Many people don't distinguish between the web (more correctly the World Wide Web) and the Internet; people think they are one and the same. This is why Java got its label as "the language of the Internet". That perception of Java is changing. It is seen as outgrowing its Internet roots. Java is now accepted as a powerful application programming language that can be applied to various types of problems. Java is a general purpose programming language. DB/C and COBOL are special purpose programming languages, designed for use in business application programming. There is a trend to adapt general purpose languages for use in business systems. An example of this is Visual Basic. Microsoft has added business-oriented features to make VB attractive to MIS decision makers. With their technical and marketing muscle, Microsoft has been quite successful in selling Visual Basic as a business application programming language. Java is also being adapted for use in business applications. IBM has 2400 programmers working on Java, on all of its platforms including OS/390, OS/400, AIX and OS/2. The IBM San Francisco project is an example of IBM's commitment to Java. San Francisco is the code name of a complete set of Java-based business applications that IBM is working on. For more information, see http://www.ibm.com/java/sanfrancisco/. The big question is this: Will Java succeed in becoming the dominant general purpose programming language in business applications? We believe that it will. On a technical basis, Java is far superior to C++ and Visual Basic. I've detailed Java's technical features previously, so I won't reiterate them. Yes, there are examples of superior technologies that failed to succeed in the marketplace - VHS vs. Betamax is a prime example. But there are many more examples where the better technology won - FM vs. AM is just one. What is interesting about the VHS vs. Betamax comparison is that the dominant company in consumer electronics (Sony) didn't make its standard "open" enough. It tried to control the VCR market with Betamax. Sony's failure to license Betamax to others, while JVC licensed VHS to anyone, is the primary reason for VHS's success. The interesting comparison is that Microsoft is acting like Sony and Sun is acting like JVC. Higher education provides another indication that Java will succeed. At the University of Illinois, several programming languages have been taught in the introductory programming courses. Twenty-five years ago, engineers and business majors were taught FORTRAN and computer science majors were taught PL/1 in their respective introductory programming courses. Over the years, the introductory programming language for computer science majors was changed to Pascal, then C, and recently C++. This year it was changed to Java. Over the next several semesters, more courses will be taught in Java and less will be taught in C and C++. Also of interest, the introductory computer science course for business majors has essentially become a class that teaches Microsoft Office with some coverage of Visual Basic for Applications (VBA) as used with Excel. Business majors don't actually learn how to write programs any more. The bottom line is that many qualified Java programmers will enter the job pool in the next few years. As TCP/IP and UNIX have showed us, open standards, whether formal or defacto, that are embraced by many companies tend to succeed in the long run. And proprietary, single vendor products, while attractive in the short term, generally fade over the years. In the long run Java will join TCP/IP and UNIX as a successful open standard. Preparing for DB/C JX The Java environment actually consists of three things: the Java compiler, the Java Virtual Machine (JVM), and the Java runtime classes. The major feature of Java is that the JVM and the Java runtime classes provide excellent portability. In a pure Java development environment, Java source code is compiled into portable Java class files. These class files can then be run by the JVM with the assistance of the Java runtime classes. There are JVMs for all major operating systems and dozens of other environments. With DB/C JX, DB/C (or DATABUS) source programs are compiled into Java class files. From this point on, development and deployment of DB/C JX programs is exactly the same as Java programs. The JVM can't distinguish between class files created from Java source programs and class files created by DB/C JX from DB/C source programs. DB/C JX provides a high level of compatibility with DB/C 9.1 and older versions of DB/C. Here is a list of incompatibilities that you may encounter when converting to DB/C JX Release 1.0: 1. DB/C GUI programming is not supported in DB/C JX 1.0. 2. There is no CHAIN utility. 3. The inline utilities have fewer features than the DB/C 9.1 utilities. 4. There are portability problems with ROLLOUT and EXECUTE. 5. File I/O may be unavailable to local disks. 6. The UPDATAB, WRITAB and partial WRITE statements are not available. 7. The SEARCH statement has some limitations. 8. Common variables have some limitations. 9. There are minor differences in the object-oriented features. 10. Printer support may be limited depending on operating system. 11. The DB/C JX compiler is more restrictive about acceptable syntax. 12. The runtime performance is slower than DB/C 9.1. Here are some general strategies for dealing with each of these issues. 1. DB/C GUI programming is not supported in DB/C JX 1.0. The first option is to wait for DB/C JX 2.0 which will offer full support for the DB/C 9.1 GUI programming constructions (DEVICE and RESOURCE variables, PREP, QUERY, CHANGE, etc.). The second option is to write the GUI interface code in Java and call DB/C code from the Java programs. The Java to DB/C JX and DB/C JX to Java interfaces are robust. 2. There is no CHAIN utility. 3. The inline utilities have fewer features than the DB/C 9.1 utilities. The lack of CHAIN and the limitations of the utilities is the major compatibility issue. Unfortunately, some environments (for example the IBM Network Computer Series 1000) don't have a command shell or operating system executables. Thus you are dependent on the DB/C inline utilities for functions like INDEX, AIMDEX, SORT and REFORMAT. Unlike DB/C 9.1, the DB/C inline utilities are actually built into DB/C JX; they are not separate executables. You will need to rewrite sections of your programs to use the DB/C JX inline utilities. 4. There are portability problems with ROLLOUT and EXECUTE. The ROLLOUT and EXECUTE statements have always had portability problems between operating systems. These statements present even greater portability problems in Java runtime environments. The best approach is to not use them. 5. File I/O may be unavailable to local disks. There are two different runtime options available for handling file I/O. The portable way to do file I/O is by using DB/C FS. DB/C FS is a file and database server for DB/C type files (including all file types and both isam and AIM indexes). DB/C FS even provides execution support of the inline utilities. The DB/C FS server runs on a Windows NT or UNIX computer. The Java class files (the DB/C JX compiled programs) communicate with DB/C FS via TCP/IP. This allows the DB/C programs to work in any Java environment, including inside web browsers and in diskless network computer stations. This approach is 100% portable on the client side, but does require DB/C FS on NT or UNIX. The second option is to use the DB/C JX native operating system file I/O pack. This is a non-portable library (.DLL file in Windows, .so file in UNIX) that provides all file I/O including execution of the inline utilities. Initially,f DB/C JX 1.0 will only provide native file I/O for Windows 95, Windows NT 4.0, HP-UX, IBM RS/6000 AIX, SCO Open Server and LINUX. Support for additional operating systems will be added in the future. 6. The UPDATAB, WRITAB and partial WRITE statements are not available. These verbs can be easily emulated with a small DB/C routine. 7. The SEARCH statement has some limitations. The contiguous nature of the search variables of the SEARCH statement presents some real problems in DB/C JX. If your SEARCH statement search list start variable is an address variable, your program needs to be changed to not use an address variable. Otherwise, you don't need to change your program, but you do need to specify the maximum number of variables that any search statement in your program will search with the -c=nnn compiler option. If the number of variables in your search statement is constant, then if you change the third operand in the search statement to a decimal constant, you don't need to specify the -c option. 8. Common variables have some limitations. There are two limitations. First, all common variables need to be specified with the asterisk, even in the first program that defines them. Second, common variables must be contiguous as the first variables of your program. 9. There are minor differences in the object-oriented features. The object-oriented features of DB/C JX use the Java object model. Most significantly, these means that each class exists in a separate .class file. In DB/C 9.1, multiple classes can exist in a single .DBC file. In DB/C JX, you can still specify multiple classes in a single source file, but multiple class files will be created. Because class lookup uses the Java class lookup model, the MODULE=dbcfilename operand of the CLASS DEFINITION statement is ignored. 10. Printer support may be limited depending on operating system. Just as with file I/O, there are two options for printer support. The first option is to use the 100% Pure Java printer support. This method does not allow for spooling and other print features like escape sequences. The second option is to use the native printer library that is provided with DB/C JX. As with file I/O, this native printer library is only provided for Windows 95, NT and some UNIX environments. 11. The DB/C JX compiler is more restrictive about acceptable syntax. Generally this shouldn't be an issue, but the DB/C JX compiler is completely new (it's written in Java) and thus flags some syntax errors that DB/C 9.1 doesn't. One example is EXTEND DIM1 BY -1. DB/C 9.1 allows this and ignores the BY -1, whereas DB/C JX flags this as an error. 12. The runtime performance is slower than DB/C 9.1. Java virtual machines are getting faster, but they aren't as fast as DB/C 9.1. One suggestion is to define variables as INT variables instead of FORM variables whenever possible. INT is implemented as the native Java integer type, while FORM is implemented with the Java BigDecimal class. The performance difference is great. This should give you some idea of the conversion effort necessary to move to DB/C JX. ***************************************************************************** Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you when it is produced, just send an email message to 'request@swc.com' and put the line 'subscribe dbcnews' in the body of the email message (omit the ' characters). The newsletter will be delivered to the email address from which the message was sent. To stop delivery, put the line 'unsubscribe dbcnews' in the body of the message.