************************************* * * * DB/C Newsletter * * May 1996 * * * ************************************* Editor's Notes Last month was a busy month for me. I taught the DB/C 9 Advanced Class three times (in Oak Brook, Germany and Switzerland) and I also attended the X3J15 meeting (the ANSI PL/B Technical Committee meeting). I enjoyed meeting with the many experienced DB/C programmers in the three classes. There wasn't any big news from the X3J15 meeting, but there was an interesting side discussion that is worth sharing. The topic was Electronic Data Interchange (EDI). Many major companies in the USA are starting to use X12-based EDI for all of their sales orders, purchase orders, invoices, and other data transmissions. The X12 standards specify the exact format of many different types of records: orders, shipment confirmations, invoices, credit memos, etc. These record formats are specialized for different industries and types of processes. The X12 standards are quite complicated, but DB/C, by using the BINARY option on the FILE variable, is capable of reading and writing files that use any of the X12 record formats. If you are interested in finding out more about these standards, you should contact Gary Raymond at Infopro (gary@sysmaker.com). In about six weeks we will begin beta testing of DB/C 9.1. We are looking for beta testers for these three environments: MS-DOS 6.x (not Windows 3.x), Mac OS, and OS/2. If you are interested, contact us at dbc@swc.com. This month's article addresses four of the common misconceptions that people have about DB/C. don.wills@swc.com Some Common Misconceptions about DB/C 1. You have to have DB/C or DATABUS experience to effectively use DB/C. Not true. DB/C is a very simple programming language that happens to have a moderately large number of verbs. The large number of verbs tends to scare new programmers, but once the basic concepts are learned, the plethora of verbs is viewed as a benefit, not a liability. Many companies that use DB/C have found that hiring well-trained programmers is the key. Many good programmers have become proficient with DB/C in just a few weeks by just reading the orange DATABUS book and DB/C Programmer's Reference. Attending a DB/C training class also helps, but is not necessary. DB/C is just a tool. Good tools are measured by their power, their ease of use, and their ease of learning. DB/C fares well in each of these measures. 2. Interpreted code like DB/C runs slow. Not true. In the early years of computers, interpreted programming languages were slow. But in those days, the word 'interpreted' meant that each source program line was translated from the source text file at run time. For many years the Basic programming language worked in this manner. Today, only scripting languages use the source interpreted approach. DB/C, as well as Visual Basic, PowerBuilder, Oracle Forms and Progress, are pseudo-code interpreted languages. What this means is that source programs are compiled into intermediate pseudo-code which is then run by a run-time monitor. For business-type applications, this approach provides excellent performance on today's computers. 3. FILEPI is slow and DB/C programs should be changed to use record locking. Not true. In real world environments, FILEPI provides excellent performance in all but the largest environments. In addition, FILEPI provides several benefits that record locking does not provide. In systems of up to 100 users, FILEPI is never a performance problem. In systems with more than 100 users, record locking might be considered, but only in a situation where one file is being used constantly by most or all of the users. FILEPI got a bad reputation from the Datapoint RMS NQDQ implementation. In that environment even 20 users could experience delays. But DB/C uses the operating system locking functions that are noticeably better than NQDQ and have also improved dramatically in the last few years. In addition, FILEPI has some benefits. It does not suffer from possible deadlock. A FILEPI cannot last for more than a few hundred milliseconds, so an operator's inaction can't hold up others. The longest wait for a FILEPI to be granted is usually less than a couple of seconds, even in systems with a large number of users. 4. If you use an AIM index on a file, you don't need to use any ISAM indexes. Usually not true. When a programmer first understands the power and ease of use of AIM, the first reaction is to AIM all of the index key fields and then not use any index files. The first problem with this is that AIM does not return records in any particular order, so if you need key-sequential access (READKS) to your file, AIM won't work. Even if you don't need key-sequential access, you should probably still use an index for exact lookups. Performance in an AIM index is negatively affected by a large number of key fields, so reducing the number of key fields by adding indexes for exact lookup fields is the best approach. DB/C Class Schedule Class Date Location DB/C 9 Fundamentals September 1996 (tentative) Oak Brook, IL DB/C 9 Advanced Features October 1996 (tentative) Oak Brook, IL For information, contact Judi Tamkevic at: voice 708.572.0240 fax 708.572.0390 email dbc@swc.com