ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DB/C Newsletter ³ ³ July 1992 ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Editor's Notes We hope you enjoy this issue of the DB/C Newsletter. We are not getting much feedback about the newsletter, even though we know there have been quite a number of people that have read and downloaded both previous issues. Please leave us a message in the Newsletter Feedback just so we know you are actually reading it and that is at least somewhat informative. Thanks. DNW The DB/C 8.0 Report Writer The DB/C Report Writer is a new feature of the upcoming release of DB/C. This report generator is targeted for use primarily by end users. It is designed to be easy to learn and easy to use. The main menu for the DB/C Report Writer looks like this: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ MENU ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ Run Report ³ ³ Define report ³ ³ Set system code ³ ³ Change system options ³ ³ Quit ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The DB/C Report Writer is an application that generates custom-designed reports. It lets the user accomplish work faster by facilitating the design, modification and generation of reports. It is easy to create professional looking reports in minutes. These reports can be sent directly to a printer, spooled to a file, or displayed on the terminal screen. To design a report, the user chooses the fields to be printed (or displayed) from a list of choices. The user chooses the sort order of the file and the selection criteria in a similar fashion. Other features include calculated fields, breaks between groups of records, subtotals and grand totals, field formatting, multi-file access (with implied links), optimized use of indexes, multi-line fields, and more. The DB/C Report Writer is written in DB/C 8.0, so it is easy to integrate into existing systems by just adding it to the menu of already existing systems. It uses the same Data Dictionary as the Fast Programming system that is also included with DB/C 8.0. It also uses the same user interface as programs generated with Fast Programming, so that end users will not have to learn different user interfaces for the report generator and for their application software. The DB/C Report Writer will be available in the first beta test release of DB/C 8.0. The first beta test release is scheduled for July 15. DB/C In Use When Turtle and Hughes, Inc. decided to move its operations to a new hardware environment four years ago, the company wanted to preserve its investment in DATABUS applications. Turtle and Hughes is an electrical equipment wholesaler based in Linden, New Jersey. Their DATABUS applications were running on a Datapoint DOS ARC system. Julius Szelagiewicz, Director of Information Systems explains: "We had outgrown or Datapoint hardware completely. We had to do something about hardware, and the amount of money Datapoint wanted to charge was a lot." Initially, Turtle and Hughes thought that it would have to convert to RMS because Datapoint DOS "was basically dead at the time," according to Szelagiewicz. However, the company recognized that RMS would be impractical. "Where we were running 16 terminals, RMS would only support four terminals," said Szelagiewicz. "It would cost us $100,000 just to be in the same place with RMS." Turtle and Hughes decided to replace its Datapoint equipment, but wanted to retain its DATABUS applications. "We tried to stay with DATABUS because we had so many man hours invested in programs," said Szelagiewicz. "The switch had to be very, very easy. We wanted a simple conversion and not a lot of programming effort." Rather than converting to RMS, Turtle and Hughes selected DB/C as their DATABUS programming environment. The company wanted to be able to run its applications on different computer platforms. DB/C would allow Turtle and Hughes to run its DATABUS applications on many hardware platforms without requiring conversion. "We chose the system software even before we chose the hardware," said Szelagiewicz. "We didn't know where we were going [in terms of a hardware selection]." Szelagiewicz remarked that the fact that a DB/C DATABUS application "basically runs on anything without any changes ... is almost unbelievable." Speed was also a major issue. Turtle and Hughes currently has sub-second response time. "At the time, it was not possible to do that with anything else. There was nothing that fast," said Szelagiewicz. He cites speed as one of the best features of DB/C. Currently, the company's business applications are running on a Hewlett Packard HP 9000 UNIX computer system. There are five branch offices and 120 terminals connected to the system. The remote terminals are connected to the HP 9000 with multiplexed, leased phone lines. Turtle and Hughes currently employees three DATABUS programmers to support and enhance the system. Szelagiewicz credits the team at Subject, Wills & Company with part of the success of DB/C at Turtle and Hughes. "It is not a stagnant language. They keep building on it and it's getting better. It is an excellent programming tool," he added. Book Preview: "The DATABUS Programming Language" The book titled "The DATABUS Programming Language", published by Software Science Press (aka Subject, Wills & Company) will be available by the end of July. The authors are Dan Felder, a well-known, west coast based DATABUS programmer, and Don Wills, editor of this newsletter. It is a 362 page, soft-bound book that retails for $35. The quote on the back cover of the book describes it well. Here it is: "The DATABUS business programming language is a superb, interactive 3GL that is in widespread use worldwide on numerous platforms, operating systems, and networks. More than a dozen companies now offer compilers, translators, productivity tools, and code generators for DATABUS. In this age of on-line systems and networking, it is fitting that DATABUS now begins to emerge as the most portable multi-vendor standard business language. The authors of this book have done a marvelous job of documenting this powerful language as specified in the draft of the forthcoming ANSI Standard." Gary D. Raymond Chairman X3J15 - Accredited Committee to Develop an ANSI Standard for the DATABUS Programming Language The book will be available from Subject, Wills & Company. Orders will be taken beginning July 15 with first shipments expected by August 1. Please note that payment may be made by credit card, by COD or prepaid by check. Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips This month's Tips column contains several helpful hints. 1. To speed up the compilation process, add the -Y parameter to the DBCMP command line. This option causes errors only to display. It suppresses the display of line numbers and file includes. It turns out that a large percentage of the clock time to compile is spent displaying the line numbers. This is true for all versions of DB/C, including the MS-DOS versions. 2. Setting the index blocksize to a value other than the default of 512 can improve indexed file read and write performance. The blocksize is set by the -B parameter of the INDEX command. Other values are 1024 and 2048. READ performance is maximized by have an index tree with the smallest number of levels. You can check the number of levels of an index tree by using the -I and -X option with FILECHK. If the number of levels of a read-mostly file is smaller with a larger blocksize, you should use the larger blocksize. READKS and READKP performance is also improved by increasing the blocksize. WRITE performance is sometimes decreased by increasing the blocksize, so you should test your application before you increase the blocksize. 3. If you decrease the number of directories in your DBC_FILEPATH, DBC_DBCPATH, and etc., your OPEN and CHAIN verb performance will improve. This is a simple tip that goes against the concept of keeping your system organized by keeping related files in separate directories. Unfortunately, each time an OPEN occurs, the DB/C run-time actually attempts an open on each directory in the DBC_FILEPATH, etc. If the file is found in the last directory in the list, there will have been several failed opens before the last one that succeeded. PREPARE is even worse because it needs to check all directories for an existing file before creating the new file. 4. The verbs SET, CLEAR and TEST have been designed for use as flag manipulation verbs. Define a flag variable as FORM 1. SET OURFLAG changes the value of OURFLAG to 1 CLEAR OURFLAG changes the value of OURFLAG to 0 TEST OURFLAG sets or clears the EQUAL (ZERO) flag 5. When running DB/C on RS-232 connected terminals (UNIX, VMS, etc.), you can improve performance by ending each DISPLAY statement with a semicolon. The semicolon suppresses the implicit *N that is done at the end of each DISPLAY statement. On most terminals the implicit *N is actually a cursor positioning escape sequence which contains 3 or more characters. The performance improvement is most noticeable on dial-up terminals. Don't just blindly add semicolons though - be sure that your application does not use the assumed *N for the cursor position of the next KEYIN or DISPLAY statement. DB/C Class Schedule The next DB/C training class is tentatively scheduled for September 14, 15, and 16 at the Oak Brook training facility of Subject, Wills & Company.