ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DB/C Newsletter ³ ³ October 1992 ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Editor's Notes Several readers have suggested that we include articles about some of the more basic aspects of DB/C. When writing this newsletter, we have targeted experienced DB/C programmers and have left out those readers that are new to DB/C. Beginning with this issue, we will attempt to include more material useful to less experienced DB/C programmers. The first article is about one of the most powerful aspects of DB/C - address variables. As far as we know, address variables are not available on any other DATABUS compilers, so it is not surprising that even experienced DATABUS programmers are not familiar with the concept of address variables. I hope the article is useful to you. We've run fresh out of hints, so the Tips Tips Tips ... column is missing from this issue. If you have anything to contribute to this column, please send it to us. DNW X3J15 Status ANSI Standard DATABUS has moved one step closer to completion. The X3J15 technical committee has finally brought the Working Draft Standard to a vote. The vote (technically called a Letter Ballot) is whether or not to forward the Working Draft Standard to X3 (the parent committee) so that X3 can officially declare the document a Draft-Proposed Standard. The vote is expected to be completed by October 15. The committee expects that the vote will be unanimous to forward the document to X3. A separate, non-official document called The Rationale is included with the Standard. This document was also created by X3J15. Its purpose is to explain why the standard is as it is - why things were added, changed and deleted from your favorite dialect of DATABUS. The Rationale is required reading to understand the standard. The standard itself is quite technical and does not contain any explanations or examples. When the documents are forwarded to X3, they are published for public review. The first public review period lasts for 4 months. During this time anyone with an interest in DATABUS may obtain a copy of the standard and may send one or more letters to X3 with recommendations or objections about the Draft-Proposed Standard. These letters are then forwarded to X3J15 for review and response. The response may be to change the Draft-Proposed Standard or to explain why a change is not made. Public review is very important, because it is last time that individuals can have an impact on the standard. If you would like to get a copy of the Draft-Proposed Standard, you can obtain it from X3 (which is funded and overseen by CBEMA - the Computer Business Equipment Manufacturer's Association), which is located in Washington, DC. Subject, Wills & Company will also be glad to provide you with a copy. Contact Judi at Subject, Wills & Company. (The documents are large, so there will be a small fee to cover the cost of copying and shipping.) DB/C In Use The application profile this month is about the DB/C applications running at Mary Free Bed Hospital and Rehabilitation Center, located in Grand Rapids, Michigan. Mary Free Bed Hospital is an 80 bed facility dedicated to long term patient rehabilitation, particularly in the areas of strokes, brain injuries, spinal injuries and certain pediatric conditions. In some ways, it is similar to other hospitals, but in other ways has very special data processing needs. A Novell Netware based network of IBM PC's is the primary computer system. There are approximately 150 PC's connected to the network providing various types of software for users. About 50 of the PC'S are used primarily by applications written in DB/C. All data entry of service provision is handled by applications written in DB/C. The service details are then transferred to a (COBOL) software package that handles all invoicing and receivables. All details are saved in a database of service details that is multiple DB/C files. Various DB/C programs are available to provide reports for analysis of this database. The most unique application at Mary Free Bed Hospital is the "expert system" that provides the therapy documentation for medical records. This application is completely written in DB/C. Therapy documentation is a written summary of the progress and final prognosis of each individual case. These written summaries were traditionally dictated by the therapist, and transcribed by clerical people using a word processor. The content and quality of each summary varied depending on many factors. The "expert system" therapy documentation system automates this process. A database of questions has been created the is structured into dialog tree. Each node of the tree is a question. Depending on the answer to the question, other nodes in the tree are activated - that is, other pertinent questions are asked. Each of these questions attempts to cause a quantified answer to result. Answers may be simple yes/no answers, or they may be scaled answers (like how many steps can a patient walk before becoming too tired). The dialog tree structure guarantees that all pertinent questions will be asked. When a dialog is complete, a complete, formal therapy documentation narrative is created and printed on a high quality laser printer. There are two major benefits from adoption of this system. The first benefit is that it is a time saver. Therapist's time is valuable. The second benefit is that all summaries are of the same high quality. They all use correct medical terminology and they do not contain vague statements or omissions. The system has been a great success. The primary author of the "expert system" is Tim Jenks. He credits DB/C for making it possible to for him to create and maintain this system in a cost effective manner. Tim Jenks is also the chairman of the International DATABUS Users Group (see the article below). DB/C Basics - Address Variables An address variable contains a pointer to another variable of the same type. After an address variable is assigned a value (that is, an address of another, non-address variable), then the address variable may be used inter- changeably with the variable to which it points. In other words, references made to an address variable work in the same manner as references made to the variable pointed to by the address variable. An address variable is defined like any other variable, except it has an @ as its operand. Here is an example of a definition of a character address variable: VAR1 CHAR @ Address variables are assigned pointer values by several verbs, including MOVEADR and CALL. The MOVEADR verb assigns the address of a specified source variable to an address variable. Here is an example: VAR1 DIM @ VAR2 INIT "HELLO" MOVEADR VAR2 TO VAR1 DISPLAY VAR1 The result of executing this program is that HELLO is displayed. The CALL and ROUTINE verbs also work with address variables. Here is an example: NUM1 FORM " 1" NUM2 FORM " 2" ANUM1 FORM @ ANUM2 FORM @ CALL FUNCTION USING NUM1, NUM2 DISPLAY "NUM1=", NUM1, ", NUM2=", NUM2 STOP FUNCTION ROUTINE ANUM1, ANUM2 DISPLAY "ANUM1=", ANUM1, ", ANUM2=", ANUM2 ADD ANUM1 TO ANUM2 RETURN This program causes the routine FUNCTION to be called with two parameters. The CALL statement contains the two parameters, NUM1 and NUM2. The ROUTINE statement specifies two target address variables that correspond with the parameters on the CALL statement. When the CALL statement is executed, control is transferred to the ROUTINE statement. When the ROUTINE statement executes, the address of each variable in the CALL list is moved into the corresponding address variable in the ROUTINE list. An implicit MOVEADR operation is performed for each parameter. When this program is executed, the following is displayed on the screen: ANUM1=1, ANUM2=2 NUM1=1, NUM2=3 There is a special type of address variable called a typeless address variable. It is defined like this: VAR1 VAR @ A typeless address variable contains a pointer to any type of non-address variable. MOVEADR is used to load and store pointers in typeless address variables. Here is an example: MSG INIT "HELLO WORLD" VAR1 VAR @ CVAR1 DIM @ MOVEADR MSG TO VAR1 MOVEADR VAR1 TO CVAR1 RESET CVAR1 TO 6 APPEND "EARTH" TO CVAR1 RESET CVAR1 DISPLAY MSG When this program executes, HELLO EARTH is displayed. Note that when CVAR1 is being manipulated with RESET and APPEND, the variable MSG is actually the variable that is being altered. Also note that MOVEADR can contain an address variable as its first operand. The address it references is not the address of the address variable, but is the address contained in the address variable. More specifically, if the source operand of a MOVEADR statement is a non-address variable, then its address is moved to the destination. If the source operand of a MOVEADR statement is an address variable (either typeless or otherwise), the address contained in that variable is moved to the destination. An address variable can only contain a pointer to a non-address variable. The TYPE statement has been enhanced to allow inspection of the type of address that is stored in a typeless address variable. LABEL variables and program label constants may also be stored into a typeless address variable. The verbs MOVEVL and MOVELV accomplish this. We'll leave that discussion for a future article. IDUG Update The International DATABUS Users Group (IDUG) Conference and Exhibition has been scheduled for January 24-26 in Phoenix, Arizona. Note that this is one day earlier than the dates given in last month's newsletter. The preliminary schedule for the conference includes vendor specific conferences on January 24th. An opening reception is scheduled for the night of the 24th. The keynote address will be at 9:00 am on January 25th. Various break-out sessions and forums are scheduled for the 25th and 26th. The exhibition will feature booths of various vendors of DATABUS products and services. Subject, Wills & Company will be very involved in the conference and will have a booth at the exhibition. Plan to attend - it is a worthwhile event. For more information contact Tim Jenks at (616) 242-0209. DB/C Class Schedule The next DB/C class is scheduled to begin October 26 at the Oak Brook, Illinois office of Subject, Wills & Company.