旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � February/March 1994 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Notes We were hoping to dedicate the February Newsletter to the topic of DB/C support using the Internet. However, technical problems have delayed getting many of the Internet pieces in place. We were left without a topic for the February Newsletter. That's why you are reading the February/March Newsletter. We hope to fully explore the Internet in the April Newsletter. We also plan to get back to the monthly schedule for publishing the Newsletter. Our Internet e-mail is functional. Here are some of our addresses: dbc@swc.com don.wills@swc.com jamie.findlay@swc.com john.petro@swc.com dwight.luetscher@swc.com judi.tamkevic@swc.com PLEASE NOTE: Send all messages for ordering software, for getting keys, and for all support questions and bug reports to dbc@swc.com. We will log all messages to dbc@swc.com and will respond quickly. Messages sent to an actual person (like john.petro@swc.com) might sit around for days because that person is on vacation or is otherwise occupied. The topic of this month's Newsletter is DB/C 9. The text of this article is from a presentation at the U.K. DATABUS User Group meeting being held on March 15th near Birmingham, England. DNW The Philosophy and Future of DB/C The DATABUS programming language is at a crossroads. The world of business data processing has been dominated by character mode applications. The first character mode applications were batch- oriented. It was for these batch-oriented applications that COBOL was invented. Interactive character mode applications became important later. DATABUS was invented to make programming these types of applications possible. Character mode applications are still very important in business data processing, but new types of applications are becoming important. These new types of applications will make all character mode applications look really antique. The most obvious difference between applications of today and new applications is the Graphical User Interface (GUI). Users are demanding that business-oriented applications look and feel like the other software that they are familiar with - word processing, spread sheets, etc. There is one large advantage for applications that all look the same. The advantage is that training is minimal because operators are already familiar with many elements of the user interface. In the early years of the automobile industry, there were many car makers and no standards. In some cars the brake was a pedal; in other cars it was a lever. The accelerator may have been a knob, a lever or a pedal. The location of these items was different in many cars. A driver was not able to operate different models of cars without a certain amount of training. Even after learning how to operate all the different models, a driver still wasn't able to optimally operate most cars. Think about your brake reflex when you are about to run into another car. What if each different car or truck you drove had a different braking action? You wouldn't be able to instinctively activate the brake because you first had to recall where it was located. The same logic applies to using and operating software. If people are to be really proficient at using software, they must be able to act and react instinctively. A standard user interface (like a GUI) provides for this. Several changes have been made to computers to support a GUI. The most obvious change is the addition of a mouse. It's important to note that a mouse usually slows down a proficient operator. A well-designed GUI application allows for operation without using the mouse. A GUI application fully supports the mouse for use by less experienced operators. But as users become more proficient with their specific application, they can use function keys (or other special keystrokes) to speed up interaction with the software. Another obvious change to computers (for GUI applications) is the addition graphical elements like multiple fonts, icons, charts, pictures, etc. Graphical elements may or may not bring new functionality to an application, but they make almost any application look a lot better. In the near future, there will be other changes to computers that will bring new features into business applications. One of the most important new features will be the use of audio in application software. Audio will be used for both input and output. Audio input comes in two forms. The first is audio recording for storage, forwarding and retrieval (like voice mail). The newer form of audio input is speech recognition. Audio output also comes in two forms. This first is audio playback of previously recorded material. The second is text- to-speech. Audio recording for messaging and playback is here now. However, it is not as important as speech recognition and text-to-speech. A company called JABRA makes a product called the Ear PHONE that is a one-piece earphone/microphone. It currently works with Macintosh AV computers to allow speech input and output to completely control the computer. The Ear PHONE is currently connected to the Macintosh with a wire, but JABRA will be releasing a wireless version of the same product within the next 12 months. Just think about walking around your office building with a JABRA in your ear, talking to your computer saying things like: "TELL INVENTORY LEVEL FOR PART 123456", "TELL CURRENT AR BALANCE FOR ABC COMPANY", "SEND AR STATEMENT TO ABC COMPANY BY FAX", "TELL STATUS TEXT MAILBOX", "TELL STATUS VOICE MAILBOX", "SEND VOICE MESSAGE TO JOE". The applications are limitless. Handwriting recognition is another area where computer technology is making great strides. The Apple Newton is currently capable of doing 95% or better correct recognition, in real time, on a computer the size of a VHS cassette tape run by 4 AAA batteries. This computer contains 4MB of ROM operating system and 640KB of RAM. Future Newtons will contain more memory, will have faster and better recognition, and will contain built-in wireless communications. The impact of these little computers on business applications will be large. Another important change is in the area of communications. Electronic Data Interchange (typically referred to as EDI) is here now. EDI defines standards for businesses to sending and receive orders, acknowledgments, invoices, etc. by communications. EDI actually defines message formats, communications protocols, and all other aspects of message transfer. Currently, EDI is typically being done using point- to-point communication via modem. In the future, EDI will be done with general purpose messaging and E-Mail systems connected via the Internet and other common networks. Message transfer will be become less expensive and very common. Whatever the underlying technology, EDI will grow and become the primary means for routine transactions between businesses. FAX transmission, reception and storage is another important technology that is now becoming tightly integrated with business data processing. The reason I made my initial statement about DATABUS being at a crossroads is because of the impact of these technologies. New technologies will require changes to existing programs, and will mandate new designs for application systems of tomorrow. The question is: Will DATABUS be capable of handling your needs with respect to these new technologies? The answer to that question is NO, DATABUS, by itself, will not be of any use in dealing with these new technologies. However, before I say anything else, let me assure you that DB/C will provide you with what you need to incorporate these new technologies. Why did I say DATABUS won't provide what you need? The answer is that DATABUS is the language defined by the ANSI Standard (and soon to be ISO Standard). It is a common subset of the verbs and operations of the four major DATABUS compiler vendors. X3J15 is the committee that worked for over 4 years to create the Standard. X3J15 is currently considering two work proposals for projects to enhance DATABUS. The first project is to add SQL to DATABUS. This should be completed and standardized within 18 months. The second project is to add several new features like record locking, CALL with parameters and separately compiled modules to DATABUS. This second project definition specifically excludes work on GUI enhancements to DATABUS. Work on this second project is scheduled to be completed within 36 months. No other projects are scheduled or contemplated. The resulting DATABUS Standard will not address GUI, audio, mail, FAX or any other advanced technologies. Subject, Wills & Company realizes the importance of providing a DATABUS compiler that meets your needs. The current release of DB/C provides full compatibility with Standard DATABUS, but also provides many additional features. If you aren't familiar with DB/C, here is a brief summary of advanced features that it currently contains: It has a source debugger. It provides object level compatibility between UNIX, MS-DOS, Windows, Macintosh, OS/2 and VMS. It allows for separately compiled modules and modules can be dynamically loaded and unloaded It provides for address variables. It implements CALL with parameters to local or external routines. It allows for variables with local scope only. It provides for user-defined verbs, written in DB/C or C. It supports serial and program-to-program communications. It supports all aspects of GUI programming, including support of DDE and the clipboard. Several new variables types are used for GUI programming: QUEUE, IMAGE, RESOURCE, DEVICE As sophisticated as these features are, DB/C needs additional features to provide the capability to include the new technologies that we've discussed. Before I talk about new features, I'd like to present the framework for how we decide what to put into DB/C. That framework is really the philosophy of DB/C. A simple statement of the philosophy of DB/C is this: DB/C exists to provide you, the programmer, with the most portable programming language available for business applications, so that you may provide the end-user with sophisticated, satisfying applications. What is a sophisticated, satisfying application? My definition is that it is an application that the end-user thinks is better than any other, however it is measured. An end-user may compare applications in terms of terms of response time, ease of use, completeness of features, use of SQL, use of a GUI, etc. DB/C will provide for whatever is important in the end-user's mind. Many end-users believe that using an object-oriented programming language is important. The next release of DB/C will provide a complete implementation of all aspects of an object-oriented language, including: data hiding, classes, multiple levels of inheritance, polymorphism, dynamic binding, etc. Many end-users believe that using a GUI is important. The next release of DB/C will provide for much more sophisticated GUI applications than it is currently capable of. Many end-users believe that using an SQL database is preferable to using an indexed file system. The next release of DB/C will provide for a much easier interface to SQL. Many end-users believe that using a 4GL is preferable to using a 3GL. The next release of DB/C will provide enhanced 4GL tools to meet this need. End-users will be impressed with applications that integrate mail, FAX, and audio. The next release of DB/C will provide for easy integration of these technologies. No matter how an end-user measures an application, we want DB/C to be perceived as providing superior applications, WHILE STILL MAINTAINING COMPLETE PORTABILITY. There currently several very nice 4GL tools available to the programmer. They allow for rapid application prototyping and they create really great looking applications. The newer 4GL tools are usually targeted at the GUI environment. Why should you choose DB/C instead of one of the 4GLs? There are several reasons, but two reasons are most important. The first reason for why you should choose DB/C is that its portability is almost always superior to a 4GL. Since DB/C Version 1, portability has been paramount. As can be seen today, its portability is unsurpassed. I don't use the word unsurpassed lightly. What unsurpassed means is that no other language is better. I challenge anyone to find a more portable language that is commonly used for business applications. The second reason for why you should choose DB/C is this: The reality of a 4GL is that it almost always contains a 3GL to deal with the situations that the 4GL can't deal with. Whether the 4GL is PowerBuilder, Microsoft Access, Informix 4GL, or whatever, it always contains a 3GL to handle the complicated details. In most cases, the 3GL included in a 4GL is a proprietary language with limited features and capabilities. (As a note - in many cases the language looks a lot like DATABUS, but without the breadth of capability.) In small applications, the 3GL inside a 4GL doesn't matter much. But in larger applications, quite a bit of 3GL coding must be done. As the application gets bigger, the coordination and control between the 3GL and the 4GL parts becomes inconvenient at best and in many cases causes maintenance to become very hard. Don't get me wrong - programmer tools are a necessity. The question is this: Should your application revolve around the screens and report layouts painted with the 4GL, or should your application revolve around the processing logic and data flow that is more easily understood in a 3GL program? You may think you can have it both ways, but you can't. If you've ever dealt with PowerBuilder, you will know what I mean. All of the logic and action of a program is hidden behind the buttons on the painter screens. There is no place to go look for things like program logic. The system consists of little snippets of code hidden behind buttons, edit controls, etc. The big picture is missing. When the big picture is not obvious, little maintenance issues become major headaches. Other issues like source code control are also very hard to address in a 4GL. I've given a broad overview of the direction of DB/C. In the remainder of my talk, I'll give a little more detail about our plans for DB/C Release 9. SEND and RECV will be enhanced to support TCP/IP directly. This can be used to implement EDI. The new verbs SENDMAIL and RECVMAIL will allow for direct sending and receiving of E-mail. The actual mail interface will be appropriate for the operating system. For example, in Windows, the Microsoft MAPI interface will be used, whereas in UNIX the POP3 protocol (which interfaces with UNIX SENDMAIL) will be used. Printing will be enhanced to support PCL and PostScript output directly. This can be used to format pages for direct output to many FAX interfaces. The verbs RECORDAUDIO, PLAYAUDIO and SPEAKAUDIO will allow for audio input and output. The object-oriented features of DB/C 9 will include a new data type - OBJECT, as well as new verbs with names like CLASS, CLASSEND, METHOD, MAKE, and DESTROY. The object-oriented features will be integrated with user-defined verbs, or they may be used directly without using user-defined verbs. More information about the object-oriented features of DB/C 9 is available in the January 1994 DB/C Newsletter. Many enhancements are included for GUI programming, including: support for icons, icon buttons, lock buttons, allow changes to the pointer, sophisticated edit control formatting, tabbing in list boxes, enhanced TIFF image file support, and more. There are numerous enhancements to the Report Writer, including allowing multiple files to be logically merged, CONTAINS and STARTS WITH selection operators, a GUI version of the Report Writer, subtotal/total only reports, test mode, enhanced page formatting and break control, support for additional data types, and more. The are many enhancements to the Fast Programming user-defined verbs. The most important enhancement is the addition of dual- use verbs for GUI/character mode portability. For example, there will be two user-defined verbs named DIALOG that have the exact same syntax and function, except that one is GUI and the other is character mode. A complete set of date manipulation verbs is a new feature of DB/C 9. The ODBC interface will be standard in DB/C to make integration of SQL easy. There are numerous other small changes such as support for MOVE LIST TO LIST, support for program labels in CALL parameter lists, a new CLEARLABEL verb, better support for mixed character sets on a network, and the ability to specify an environment file on a command line. I hope that this shows you that choosing DB/C is a great decision. Thank you for your time. DB/C Class Schedule The next DB/C class is scheduled for May 2nd through 5th. The class is held in the Oak Brook, Illinois office of Subject, Wills & Company. For more information, contact Judi Tamkevic at (708) 572-0240 or at dbc@swc.com