DECUS U. S. Chapter SIGs Newsletter, Volume 5, Number 4 December 1989 Wombat Examiner, Volume 11, Number 4 ---------------------------------------------------------------- Call for Product Improvement Requests (PIRs) T. Chris Wool, PIR Editor ---------------------------------------------------------------- Again this year, the DATATRIEVE/4GL SIG is operating a Product Improvement Request System. This is your opportunity to pass on to the DATATRIEVE and 4GL developers your ideas for improving the various products. The range of PIRs is broad - from specific "nit-picking" about syntax to long range goals and directions. You can influence the development of the products only to the extent that you participate in the PIR process. A significant number of today's features in DATATRIEVE were originally PIRs. The PIR process starts with the submission of Product Improvement Requests. These requests are compiled, and then submitted to the SIG membership. The membership votes on the relative importance of the PIRs. The ranked PIRs are then sent to Digital for their review, comments, and action. In the back of this issue of the SIGs Newsletter is a PIR Submission Form. If you wish to submit a PIR, please complete the form and return it to the address on the form no later than January 29, 1990. This is you last change for this year to submit a product improvement request for VAX-DATATRIEVE, DATATRIEVE-11, RALLY, and TEAMDATA. ---------------------------------------------------------------- From the Editor's Pen ---------------------------------------------------------------- This is your last change to turn in your Special RALLY PIR ballot. Your ballot must be received by Chris Wool by December 15, 1989. You have a little long (until January 29, 1990) to get in your PIRs for the next round. Don't miss this opportunity to "communicate" directly to the developers. This month a new column has been starting in the Wombat Examiner and 4GL Dispatch. The column is "The RALLY Check Point." This column, like the "Dear Wombat Wizard" column, is written by various individuals and is designed to answer specific questions or problems and give tips on the use of RALLY. The first few columns over the next few months are contributed by Digital employees from the Northern District Professional Software Services and will be edited for the Wombat Examiner and 4GL Dispatch by Associate Editor Lorey B. Kimmel. We are looking forward to the interest in RALLY and we will try to rise to the challenge of dealing with material in the newsletter in a "new language." Again so quickly we are approaching the end of another year. The staff of the Wombat Examiner and 4GL Dispatch extends to you warmest seasons greetings. Have a happy and safe new year. At the end of a year and the beginning of a new one, we take stock, count our blessings, and discharge our debts. I am indebted to the staff of the Wombat Examiner and 4GL Dispatch for their good work and fine support over the last year. To Steve Cordiviola, Pat Scopelliti, Herb Reines, Richard Copeland, Lorey Kimmel, and Bart Lederman, thanks! You have made my job a lot easier and a lot more fun than it would have been without you. Joe H. Gallagher, Ph. D. Editor "About the Authors" The material in this months RALLY Check Point column is taken from "VAX RALLY Hints and Techniques" produced and created by Digital employees in Australia, New Zealand, Canada, Europe, and the US; the material was edited and compiled by Ian Smith, Marg Williams, and Vince Moran of Digital's Northern District Professional Software Services and edited for the Wombat Examiner and 4GL Dispatch by Associate Editor Lorey B. Kimmel. ----------------------------------------------------------------- The RALLY Check Point ----------------------------------------------------------------- PROBLEM: Confirm record on DELETE When the delete record action is taken by the user (e.g. when they press the REMOVE key) the application needs to confirm that the user actually wanted to perform that action. For example, display a prompt confirming that the record is to be deleted. SOLUTION: An ADL procedure needs to be run at the BEFORE DELETE action site. You should also create a standard confirm form/report (or task) which can be run from other form/reports in your application. Do a FORK to execute the special form/report. It will read a variable field and store the value in a global variable (CONFIRM_DELETE_YN). This form/report field should have a Y or N validation applied to it. After exit from the task execution will continue in the ADL procedure which can examine the global variable CONFIRM_DELETE_YN to see if it is set to "Y". In this case the ADL can exit with no further action required. Otherwise the procedure should call SET_FAILURE() to force the DELETE to fail. (ADL procedure to confirm delete of this record) confirm_delete_yn := 'N'; fork confirm_delete' if confirm_delete_yn <> 'Y' then (abort the DELETE action) SET_FAILURE(); ---------------------------------------------------------------- Dear Wombat Wizard ---------------------------------------------------------------- Dear Wombat Wizard: Does DATATRIEVE think that 25 = 30? I have been working on a very complex report on our client list. The report is output to a file and then read into another domain to analyze summary statistics. Since the output of the Report Writer goes into another domain, the column layout is very critical. I used a print statement in the Report Writer which looks something like: print . . . space 0, client_name(-), space 0, . . . The field CLIENT_NAME is declared with a PIC X(25) clause. But when we changed the print statement to print . . . space 0, fn$upcase(client_name)(-), space 0, . . . our procedures stopped working with a bang and a crash! After an hour of chasing why the record was now five characters longer than before, we discovered that the upper case client name was 30 characters long, not 25 as before. What gives? Why does DATATRIEVE think a length of 30 is the same as a length of 25? Signed, Worried that DTR can't count. Dear Worried: Whew! For a second there, I thought you were going to ask why is Halloween the same as Christmas. It that case 31 = 25, or 31 OCT = 25 DEC But to answer your question, the string functions, in particular FN$STR_EXTRACT and FN$UPCASE, have a default edit-string of 30 characters. If you don't believe me, check the VAX DATATRIEVE Reference Manual under the function FN$STR_EXTRACT. So ... if you don't specify otherwise, the "little Wombat function server" on the inside of DATATRIEVE will assume that the output of FN$UPCASE is 30 characters long. To persuade the "little Wombat function server" to use some other length, try FORMAT ... USING as in print ... space 0, format fn$upcase(client_name) using x(25), space 0, ... And yes, DATATRIEVE counts very well; somethings it's just not clear how it is counting. Signed, The Wombat Wizard (HGR, BZL, TCW) ----------------------------------------------------------------- RALLY as a DATATRIEVE Function Bart Z. Lederman, System Resources Corp., Burlington, MA 01803 ----------------------------------------------------------------- RALLY is a 4GL product sold by Digital; you've probably seen some articles about it here in the Newsletter. Like DATATRIEVE, it has a call interface which allows it to be linked in and called from other programs. There are actually two ways to call it: one requires a number of different entry points to be called and checked; the other is a 'simplified' interface which accepts single RALLY commands such as "RALLY RUN rga_file". This interface can be easily accessed as a DATATRIEVE function. The definition which has to be added to DTRFND.MAR looks like: ; FN$RALLY - Access to RALLY applications ; B. Z. Lederman ; Input is a RALLY command line ; No output ; ; This function requires linking to the shared RALLY image. .LINK "SYS$SHARE:RALLY$SHARE.EXE"/SHAREABLE $DTR$FUN_DEF FN$RALLY, RALLY$RALLY, 1 $DTR$FUN_OUT_ARG TYPE = FUN$K_STATUS $DTR$FUN_NOVALUE $DTR$FUN_NOOPTIMIZE $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 1 $DTR$FUN_END_DEF You then rebuild DATATRIEVE as documented in the "Customization" manual. How to use it? Well, basically, you input the same RALLY commands to this function as you would enter in DCL. For example: DTR> FN$RALLY("RALLY RUN SYS$EXAMPLES:RALLY$TAPES") I have not tried any other commands like RALLY EDIT, but they should work. ---------------------------------------------------------------- Wombat Magic, Spring 1989 - Part 4 Session Co-Chairs: Dana Schwartz, DOD, Washington, DC Bert Roseberry, U. S. Coast Guard, Washington, DC Session Editor: Joe H. Gallagher, Ph. D., 4GL Solutions, Overland Park, KS ---------------------------------------------------------------- Editors' note: The following is Part 4 of a highly edited transcription of the Wombat Magic Session at the 1989 Spring DECUS Symposium in Atlanta, Georgia, which occurred on May 11, 1989. Part 3 appeared in the November 1989 newsletter. Material which was presented on transparencies has been merged into the oral presentation. An attempt has been made to convey both the technical content of the Magic Session as well as the humor, covert intellectual swaggering, and the spirited interchange of the presentations. Material which appears in the text within square brackets [] has been added by the editor in an attempt to improve the understandability of this very exciting Magic Session. The material presented here is not presented in the same order as it occurred in the session. John Putnam, Harris Bank, Chicago, IL This is "proposed" magic; I'm actually stumping for votes on the next PIR, as in wouldn't it be nice to use the grouping and re-definition features of a record definition on a declared variable? Now [currently], one has to use the string extract function to pull things apart. But if one could make a record definition like: DEFINE RECORD CDATE_REC USING 01 CDATE_REC. 03 CDATE PIC X(6). 03 CDATE_BREAKDOWN REDEFINES CDATE. 05 YY PIC XX. 05 MM PIC XX. 05 DD PIC XX. ; and just say DECLARE XDATE USING CDATE_REC. XDATE.CDATE = "890511" PRINT XDATE.MM|"/"|XDATE.DD|"/"|XDATE.YY would give 05/11/89 But even better use would be the case where you have a file that has a concatenated RMS key of an account number followed by a date in the form NNNNQQQQQQQQ where NNNN is a four byte account number and QQQQQQQQ is a quad word date. Then the record definition would look like: 01 CEKY_REC. 05 KEY. 07 ACCT PIC 9(4). 07 DATE USAGE IS DATE. 05 CKEY REDEFINES KEY PIC X(12). . . . Then one could use READY ACCT_DOM READY TRANS DECLARE X USING CKEY_REC. X.DATE = "TODAY" FOR A IN ACCT_DOM BEGIN X.ACCT = A.ACCT FOR TRANS WITH TKEY = X.CKEY . . . END and save the use of an external file! If DATATRIEVE had such a capability, then maybe · This sort of temporary could be viewed as a virtual domain that is open [always ready] and has a selected record. · The variable name could be viewed as a contest variable. · This may be a cheap extension to the language with lots of BANG for the bucks. There may be some other interesting things. One of the things that I do currently with FMS and DATATRIEVE is define a whole bunch of DECLARED variables and use the DISPLAY_FORM. An equivalent syntax might be DECLARE X USING X_REC FORM IS FM. MODIFY X This could be a way of propagating a record environment and storing it in the CDD and making it available to a number of different routines. And because of DATATRIEVE and its interpretive nature, that would propagate automatically. So that would save a lot of code maintenance as well. The last thing is because of the structure of a record definition, it would be possible to pass a large block of information to a user defined function. If X were a virtual record definition, then a call like FN$MYROOT(X) would be very powerful especially if MYROOT were a call to DECWindows! Lieutenant Richard Young, U. S. Air Force, Panama City, FL I've been trying to create DATATRIEVE procedures so that someone less experienced than myself can use them. In creating these procedures we use a lot of the usual *."prompt text" prompts. In my situation we have a database of missile types -- and there are a lot of missile types out there. And I want to be able to do a multi-prompt [that is, enter a variable number of values of a field to use in a record select expression]. So I went to the DTR/4GL SIG campground and asked Joe Gallagher how to do this. And here is how to search for a variable number of values of a field. Suppose we have a domain we have to search which has a field, MISSILE-TYPE which is PIC X(6). Then we DECLARE BUFFER PIC X(70). DECLARE COUNTER USAGE IS INTEGER. DECLARE TEMP PIC X(6). BUFFER = "" COUNTER = *."number of missile types to search for" REPEAT COUNTER BEGIN TEMP = *."missile type" BUFFER = BUFFER||TEMP|"?" END READY MISSILE-DATABASE FOR MISSILE-DATABASE WITH BUFFER CONT MISSILE-TYPE . . . The size of global variable BUFFER is the size of the field to search (in this case the field MISSILE-TYPE is 6 characters) plus 1, times the number of different value to search for (in this case 10). We specify the number of values we need to enter; then we enter the values. The values are placed in the buffer, BUFFER, with each value separated by character which never appears within the field MISSILE-TYPE. The character "?" never appears in field MISSILE-TYPE so we can use that character. The magic is that we reverse the order of the Boolean expression. Normally the Boolean expression would be WITH MISSILE-TYPE boolean-operator "value" but we use WITH BUFFER CONT MISSILE-TYPE The reason that we need a character like "?" in the buffer is the the values in the buffer have got to have a registration. Suppose we had missile types "123456", "456789", and "789012". If we wanted to search for missile types "123456" and "789012", and put these two values in the buffer without being separated by a "?", then the buffer would contain "123456789012". If we searched the buffer to see if the missile type "456789" were there, we would improperly find that it was. However, if we separate the values in the buffer by "?", then the buffer would contain BUFFER = "123456?789012?" and it would not contain "456789". Bert A. Roseberry, U. S. Coast Guard, Washington, DC Unfortunately this isn't going to be a funny one, but since no one has present magic on TEAMDATA, I figured that if I came up with anything I'd be a shoe in for the TEAMDATA doc set. For those of you who have never used TEAMDATA or looked at it, it's a really interesting product. One of the things I find annoying about the product though, is when you delete various things such as tables or sheets or whatever, it goes into a folder called WASTEBASKET. Then you have to open up the folder WASTEBASKET and get rid of it again. Most unsophisticated TEAMDATA users won't take that extra step. So as a system manager, you need a way go in a get rid of everything that's in peoples WASTEBASKET folder. The best way to do this is: $RUN SYS$SYSTEM:RDO RDO> INVOKE DATABASE FILENAME "TEAMDB" RDO> START_TRANSACTION READ_WRITE RDO> FOR A IN VDD$VIA$ROOTDIR WITH A.DIR$NAME = "WASTEBASKET" RDO> FOR B IN VDD$VIA$ROOTDIR WITH B.DIR$PARENT=A.DIR$ELEMENT_ID RDO> ERASE B END_FOR END_FOR RDO> COMMIT and you can set this up to run as a command procedure to run at night to empty all the TEAMDATA waste baskets. Mike Reopell, Williams College, Williamstown, MA At the college we have a lot of reasons to do reports and/or mailing labels that are specific to regional areas. Everything was based on zip codes. This is a real brief version of what our DATATRIEVE procedure looked like. . . . READY ADDRESS SHARED READ READY PERSON SHARED READ . . . FOR ALL ADDRESS WITH ZIPCODE BT "...","..." AND ZIPCODE BT "...","..." AND . . . BEGIN FOR FIRST 1 PERSON WITH ID_NUM = ADDRESS.ID_NUM BEGIN FOR ALL ADDRESS WITH ADDRESS.ID_NUM = PERSON.ID_NUM . . . However, with the Post Office in its infinite wisdom constantly changing zip codes and adding new regions, the RSE in the initial loop [WITH ZIPCODE BT ...] was getting out of hand. Plus it tied people specifically to zip codes. I'll try to clarify that a little later. Basically what we did was select all records by zip code and some other stuff, we than tie that to the PERSON file while has all the information about specific classes of alumni, and then we have to go back for all address again because alumns don't have one address. They could have a home, business, and several seasonal addresses. And we need to get their current zip code to store for a zip code sort. So for the new release of our data base, they came up with these things called GEO_CODEs. Take out ZIPCODE, put in GEO_CODE. Presto. READY ADDRESS SHARED READ READY PERSON SHARED READ . . . FOR ALL ADDRESS WITH WITH GEO_CODE = "XYZ" BEGIN FOR FIRST 1 PERSON WITH ID_NUM . . . BEGIN FOR ALL ADDRESS WITH ID_NUM . . . BEGIN . . . The nice part about GEO_CODEs and the reason that they really wanted to have them was they could go as assign an alumni to a specific regional area without changing the zip code. Plus I only had to go a look at one alternate keyed field. The problem was on a small test of 100 records, the ZIPCODE based procedure took 1 minute and 7 seconds and the GEOCODE based procedure took 1 minute and 48 seconds - only a small increase in CPU time. But on a larger test of 4,000 records, the ZIPCODE based procedure to 1 hour and 5 seconds while the GEOCODE base procedure was killed after 11 hours and 33 seconds having performed 2,342,843 direct I/Os. At this point, I had no idea what was going on. Basically, DATATRIEVE gets Alzheimer's disease; it has no idea where it is. Within the second FOR loop on ADDRESS, DATATRIEVE gets lost and sits in a state of I/O for ever. I thought I figured out a way around this; I hadn't really solved it. I called Digital's Hot Line; the DATATRIEVE people blame it on the DCL people and the DCL people blame it on the DATATRIEVE people. Neither one of them answers your question. What I did was break the problem down into its smallest parts. When you go into a domain twice when the initial loop uses a record selection expression on an alternate key with many duplicates, causes the problem. When I was using ZIPCODE with 50,000 records, I had about 46,000 unique zip codes. But with GEOCODE, those 50,000 records gave only about 70 unique regional codes; I had lots and lots of duplicates. That is the root cause of the problem. Well, I didn't cure this problem, I went around it with READY ADDRESS SHARED READ READY PERSON SHARED READ DEFINE FILE TMP_ADR_ID; READY TMP_ADR_ID WRITE . . . FOR ADDRESS WITH WITH GEO_CODE = "XYZ" ... REDUCED TO ADDRESS_ID STORE TMP_ADR_ID USING TMP_ID = ADDRESS_ID_NUM . . . FOR TMP_ADR_ID BEGIN FOR FIRST 1 PERSON . . . BEGIN FOR ADDRESS . . . BEGIN . . . . . . By storing the ADDRESS_ID_NUM in a temporary domain, we avoid the two FOR loops in ADDRESS. This situation actually results in less CPU time and fewer I/Os than the original ZIPCODE-based procedure. But I made the mistake, like Harry Miller, of talking to Joe Gallagher about this problem, and what Joe suggested was the use of an alias like READY PERSON SHARED READ READY ADDRESS SHARED READ READY ADDRESS AS ADDRESS_2 SHARED READ . . . FOR ALL ADDRESS WITH WITH GEO_CODE = "XYZ" BEGIN FOR FIRST 1 PERSON WITH ID_NUM . . . BEGIN FOR ALL ADDRESS_2 WITH ID_NUM . . . BEGIN . . . This hasn't been tested yet. I know mine works, but I suspect the alias also works. And Andy [Schneider] is shaking his head [in agreement]. Pat Scopelliti, Corning, Inc., Corning, NY Over the years we have had "Dueling Logical Names" and "Dueling Functions" and "Dueling Escapes." What we have tonight is "Dueling Centering." DECLARE B PIC X(66). DECLARE X PIC X(40). X = *."title to be centered" B = " " PRINT FN$STR_EXTRACT(B,1,(132-FN$STR_LOCATE(X||"~","~"))/2)|X Mary Ann Lightfoot, Aratex Services, Inc., Encino, CA I work in a shop full of guys and I'm always getting flack that DATATRIEVE can't do this, can't do that, and shouldn't do this. And most of the file we have are very large; we have one that has our field [service?] information in it and it's over 300,000 blocks long. And, of course, that is what the general manager want to see. They want to see the revenue. Part of the record of the huge file looks like: . . . 05 KEY. 07 CUST PIC 9(9) COMP 3. 07 LINE PIC 9(9) COMP 3. 07 ITEM PIC X(15). 05 MORE_FIELDS. . . . 05 PURCHASE_ORDER PIC X(10). 05 CUST_MANE COMPUTED BY (CUST VIA CUSTOMER_TABLE). 05 NEW_KEY_FIELD COMPUTED BY (CUST|PURCHASE_ORDER). . . . ; When I extract a portion of the huge file into a much smaller file which is keyed on NEW_KEY_FIELD with a record that looks like . . . 05 NEW_KEY_FIELD PIC X(19). 05 MORE_FIELDS. . . . there is a big performance win, because the small file is equivalent to the huge one with an RSE. Richard Copeland, Corning, Inc., Wilmington, NC [Editor's note: Last summer, Richard moved from Wilmington to the Corning facilities in Corning, NY.] This magic is called "If you feed a Wombat long enough, it gets very very large!" This is not particularly magical, but it is one of the more interesting things we have done with DATATRIEVE. But it may expand your horizons a little bit. When you have an application in DATATREIVE it become very popular. You keep adding record to it and keep adding to it and it go on for years and years. And it gets bigger and bigger and bigger. How do you rid of any of the records and still retain DATATREIVE access? That was our problem. We started building this file in 1981 and by 1988 the [detail] file was taking up half of an RA81 disk drive and getting bigger all the time and becoming a really unwieldy size. At first we tried to split the file into the data for the last six months and then all older data. But the archive data was still too big to easily deal with. The file organization is a master record which contains header information about large pieces of glass. The detailed domain contains 20 or so records about the small pieces of glass that are made out of the large ones. Most of the people in our organization are interested in the detail information, and they are not very interested in the header [master file] information. But we keep it anyway. But the header information is a lot smaller than the detail information. One of the pieces of information in the header is the creation date of the detail record; that's very important. We decided to keep on the last 4 years of detail information online. We surveyed the people who use this data and they said that they didn't really need instantaneous access to data older than four years as long as we can get to it in a day or so. We created a magnetic tape for each year that would be archived and we left the header record alone. We used the COPY command to transfer the file to individual year's tape. On rare occasions (maybe once every two weeks) when the user needs to access the archived data: 1. The user finds the header record and gets the creation date. 2. Exits from DATATRIEVE. 3. Executes a DCL command file that prompts for the year, mounts the proper tape, defines a logical HISTTAPE as TAPE:FILENAME.DAT 4. Starts DATATREIVE, READYs the domain that points to HISTTAPE. 5. Then uses a FOR to get the needed data. This works just like a disk-based domain except that it is sequential access file and no collections can be used. And it is quite fast! That's how we solved our very large file problem. ---------------------------------------------------------------- Author Index - Volume 10 Joe H. Gallagher, Ph. D., 4GL Solutions, Overland Park, KS ---------------------------------------------------------------- The annual Author Index of the Wombat Examiner and 4GL Dispatch has been constructed in the same manner as the Author Index for the first nine volumes which appeared October of 1988, Volume 10, Number 2, page DTR-12. Volume 10 of the Wombat Examiner and 4GL Dispatch is Volume 4 of the DECUS SIGs Newsletter and covers the period September of 1988 through August of 1989. An attempt has been made to use the author's full name when available. Babiarz, John N4p8, N6p4 Beer, Alan H. N1p20, N2p7 Carpenter, John N1p4, N4p1 Chimene, Jeff N1p13, N12p1 Copeland, Richard N2p3 Cordiviola, Steven N4p8, N10p5 Diba, Ali N7p13 Doyle, Ellen A. N5p6 Dubiner, Eric S. N11p5 Ferrara, Raymond N4p11 Fournier, Thomas R. N1p16 Fredrickson, Steven C. N8p2, N9p5 Gallagher, Joe H. N1p1, N1p3, N1p9, N1p11, N2p1, N2p5, N2p12, N3p3, N3p25, N4p1, N4p7, N4p9, N4p10, N4p11, N4p12, N4p13, N5p4, N5p9, N5p12, N6p1, N6p2, N7p1, N7p16, N8p1, N8p3, N9p1, N9p1, N11p1, N11p9 Ganel, Shaul N11p4 Garcia, Evelyn N4p13 Gross, Charles R. N8p2 Hall, Sue N2p5 Hatfield, David A. N8p1, N11p5 Henning, John L. N11p1, N12p7 Herzmark, Leonard E. N2p9 Hicks, Larry N12p3 Holst, Sabastian N4p10 Hulse, Lesley A. N5p1, N8p1, N11p5 Jasmann, Lawrence M. N2p5 Kah, Ann F. N1p15 Lasher, Lew N2p5 Lederman, Bart Z. N4p4, N7p5, N9p3, N10p13, N11p3, N11p6, N12p9 Lehman, Donna N10p4 Mathis, Jack N6p9 McDavid, Glenn T. N6p5 McKim, James N9p6 Miller, Harry J. N1p18, N10p10, N11p10 Naecker, Philip A. N7p13 Reines, Herbert G. N1p3, N6p1 Reynolds, Bernadette N10p10 Richards, Brian N4p11 Roduner, Larry D. N2p6, N7p2 Rogers, Tony N9p7 Roseberry, Bert A. N1p2, N1p20, N2p8, N3p1, N5p4, N6p2, N7p14, N7p17, N11p9 Schneider, Andrew W. N2p5 Schwartz, Dana J. N1p16, N5p1, N6p9, N11p9 Scopelliti, Pasquale F. N4p3, N6p5, N11p1 Simutis, John D. N6p1 Stern, Jr., Donald E. N4p9 Swan, David M. N6p7, N7p15 Tellis, Winston N8p3, N12p3 Unknown, N4p14 Wool, T. Chris N1p4, N5p1, N8p3, N8p5, N10p1, N11p10, N12p5 ---------------------------------------------------------------- Keyword Index - Volume 10 Joe H. Gallagher, Ph. D., 4GL Solutions, Overland Park, KS ---------------------------------------------------------------- The annual Keyword Index of the Wombat Examiner and 4GL Dispatch has been constructed in the same manner as the Keyword Index for the first nine volumes which appeared in November of 1988, Volume 10, Number 3, page DTR-25. Articles in Volume 10 (Volume 4 of the DECUS SIGs Newsletter) were manually assigned up to five key words or key phrases. These assignments were made by best guess and experience. Each article, editorial, letter to editor or chair, and each individual Wombat Magic presentation or problem solution was given a separate reference designation and set of keywords. If a particular product was identified, that product abbreviation became one of the five keywords. However, most of the articles deal with VAX-DATATRIEVE and this keyword was not always assigned if there were other more specific keywords that needed to be assigned. References dealing with DTR-11, TEAMDATA, RALLY, CDD, FMS, and the non-Digital 4GLs of ACCENT R, CORTEX, INGRES, ORACLE, POWERHOUSE, and SMARTSTAR are easily found. A ACCENT R N10p4 ACCENT R WG N8p3, N12p3 arrays, pseudo N1p16 AT BOTTOM OF PAGE N7p13 AT TOP OF N6p1 AT TOP OF PAGE N2p5 Atlanta support N11p9 author index N2p12 award, outstanding SIG N11p1 B ballot analysis, PIR N1p4 BASIC N12p1 bibiography N10p5 C calculator N6p4 CDD N5p1 CDD/Plus N4p3, N5p1 centering N11p10 comment searcher N1p20 COMPUTED BY N2p3 COMPUTED BY CHOICE OF N4p8, N6p1, N6p1, N6p5 contest N1p9, N2p1 contest data N5p12 contest question N7p1 context variable N4p11, N6p1 continuation flag N6p1 CORTEX WG N11p5 Cropper, Douglas N11p1 cross referencing N10p1 CROSS, avoiding N2p5 D data base restructure N10p4 data, cleaning up N6p5 date arithmetic N11p10 date data type N5p4, N10p10, N11p10 date formatting N4p13, N4p13 date reformatting N1p9, N1p20 DCL N10p13 DECGRAPH N1p2 DECLARE...COMPUTED BY...MAX N4p9, N4p10 DECREPORTER N1p4, N4p1, N11p1 DECUS membership test N7p14 DECUS, goals N8p1 disk usage N4p4 domain, scratch N4p13, N4p13 DTR N1p2, N1p3, N1p4, N1p9, N1p11, N1p13, N1p16, N1p18, N1p20, N2p3, N2p5, N2p5, N2p6, N2p7, N2p8, N2p9, N3p1, N4p1, N4p4, N5p6, N8p5, N11p1 DTR V4.2 N5p1 DTR$DATE_INPUT N1p20 DTR, callable N6p4 DTR-11 N1p4, N1p9, N1p15, N2p5, N4p1, N4p10, N4p13, N4p13, N5p1, N11p1 E EDIT ALL N2p5 EDITing in DTR N7p15 editor, SUMSLP N2p8 editors and chairs N1p1 errata N3p2, N11p3 errata, see N4p7 error message N3p1 error messages, capture N9p5 escape sequences N2p6 exit status N1p13, N7p13 EXIT, control of N6p2 F field test site N6p9 file access in function N7p17 file names, computed N8p3 file names, printing N9p3 FILLER, use of N1p15 FIMS N4p3 fiscal year N6p1 FMS N5p6 FMS, list in N7p2 fn$attach N12p1 fn$baby_ed N3p1 fn$char N11p9 fn$convert_reclaim N11p6 fn$create_log N8p3 fn$date N5p4, N11p10 fn$dcl N10p13 fn$define_log N7p13 fn$edit N11p6 fn$edit_blob N7p13 fn$exit N6p2 fn$fao N4p4 fn$fdl_create N11p6 fn$floor N10p10 fn$julian N4p8 fn$lov N7p17 fn$mod N1p16 fn$month N6p1 fn$nint N1p18, N10p10 fn$pos_extract N12p9 fn$random N1p11, N1p18 fn$soundex N7p5 fn$str_case_blind_compare N12p9 fn$str_element N12p9 fn$str_extract N1p16, N4p4, N5p9, N10p5, N10p10 fn$str_find_first_in_set N12p9 fn$str_find_first_not_set N12p9 fn$str_length N10p5 fn$str_loc N2p3, N5p9, N10p5, N11p10 fn$str_replace N1p11, N5p9 fn$trim_filespec N9p3 fn$upcase N5p4 fn$year N6p1 FOCUS N4p10, N5p12 FOCUS WG N5p1, N8p1, N11p5 FOR...FOR N4p11 FOR...REDUCED...SORTED BY N4p9 FORMAT fn$str_extract N4p4 FORTRAN N1p20, N2p9, N6p4 FUN$K_STATUS N3p1 function return status N3p1 functions N1p11 G games, craps N1p18 GET_FORM N7p2 global variable buffer N4p9, N4p10, N4p11 group field, principal N9p1 H help menu N2p5 hierarchies N5p6 history of Wombat Examiner N1p1 humor N1p16, N1p20, N4p14, N6p9, N7p14, N11p9, N11p9 I index N3p3, N3p25 index, KWIC N5p9 index, newsletter N5p9 INGRES WG N12p3 init file N10p4 installation N5p1 K key remapping, dynamic N9p7 keyword index N3p25 KWIC index N3p3 L Lederman, Bart Z. N11p1 line movement, partial N2p6 lines in report, vertical N2p6 lines, dial-in N10p13 list of values in DTR N7p17 LN03 N2p6 login analysis N10p13 M MACRO N7p5, N11p3 management, system N10p13 MATCH N7p2 messages, VMS style N1p13 missing records N2p5 N news N4p3 NOECHO N6p5 normalization N6p7 numeric format N1p3 O OCCURS clause N7p1 ORACLE WG N4p2, N11p4 P pages per volume N1p1 parsing N2p9 parsing, text N10p1 password N6p5 PIR N1p4, N5p1, N8p5, N9p1, N12p5, N12p7 PIR process N8p1 PLOT ENSIGN N2p8, N3p2 PLOT MULTI-BAR N4p8 PLOTS N2p8 pollution monitoring N2p9 PORT, declare N6p4 POWERHOUSE WG N4p2, N8p1, N11p5 prime number generator N7p16 PRINT NEW-PAGE N2p5 print, very complex N6p5 problem contest N9p1 problem solution N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p13, N4p13, N5p12 problem statement N4p7 procedure in RSE N2p5 procedure, input N2p7 PROCEDURES, dummy N7p15 protection, field level N6p7 Q quad data type N11p10 R RALLY N2p5, N4p1, N5p1, N9p5, N9p6, N9p7, N11p1 RALLY WG N4p2, N8p2 Rdb blob N7p13 records, "relative" N6p9 records, previous N6p9 REDEFINES N1p15, N2p9 relinking N1p2 report writer N2p3 report, multi-group N9p6 responses to PIRs, Digital's N12p7 RUNNING TOTAL N6p1 S screen formatting N1p16 screen management N10p4 screen paging N7p13 scrolling regions N11p9 Searching all fields N9p1 seminars N2p1 sessions, least popular N11p9 sharable images N1p2 single statement N4p11 SMARTSTAR WG N4p2, N8p2 SMG$ N7p17 solution performance N4p12 sorted extremum N1p9, N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12 sorting N6p1 Soundex N7p5, N11p3 Starkey, Jim N7p16 steering committee meetings N2p1 stock holding report N6p5 string vs numeric N1p3 suite activities N2p1 SUMSLP N3p2 T table translation N1p3 tables N2p7 tables, for protection N6p7 talk to developers N1p20 TEAMDATA N1p2, N4p1, N5p1, N8p5, N11p1 test data N4p7 text, management N1p15 time, average N10p10, N11p10 time, entry of N5p4 titles, centered N2p3 top 10 list N1p16, N1p20, N11p9, N11p9 TPU N7p13 U user complaints N1p16 USING T N6p5 V validation N2p7 VIA TABLE N1p13 Volume 10 N1p1 Volumes 1 to 9 N2p12 volunteer N9p1 volunteer recruitment N2p1 volunteers, new N4p3, N11p1 W Wombat Examiner & 4GL Dispatch N2p12 Wombat Examiner, index N3p3, N3p25 X, Y, Z X-Windows N4p3 zip codes N2p5 ---------------------------------------------------------------- Keyword In Context (KWIC) Title Index - Volume 10 Joe H. Gallagher, Ph. D., 4GL Solutions, Overland Park, KS ---------------------------------------------------------------- The annual Keyword in Context Title Index for Volume 10 of the Wombat Examiner and 4GL Dispatch was created in the same way as the KWIC index for Volumes 1 to 9 which appeared in the November 1988 issue, Volume 10, Number 3, page DTR-3. From the title of each article in Volume 10 (Volume 4 of the DECUS SIGs Newsletter), a standard keyword in context (KWIC) index was constructed. Many entries were removed. Removed entries included all non-essential punctuation, all articles (a, an, and the), many isolated digits, all conjunctions which were not used as DATATRIEVE reserved words, many verbs which were not used as DATATRIEVE reserved words, many adjectives, and many adverbs. Keyword Keyword in Context Rotated Title Reference 'TWAS 'Twas the Night before Implementation A Seasonal Poem - N4p14 1988 1988 DECUS Update Fall N4p3 1988 Fall DECUS Symposium, Anaheim, CA Results of Problem Contest at Wombat Magic N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 1988 Fall Symposium in Anaheim DTR/4GL Activities at the N2p1 1989 1989 DATATRIEVE Contest - Spring N7p1 4GL 4GL Dispatch, Volumes 1 to 9 Author Index of Wombat Examiner and N2p12 A ACCENT R ACCENT R TIPS & TECHNIQUES N10p4 ACCENT R Working Group News Atlanta DECUS N12p3 ACTIVITIES Activities at the 1988 Fall Symposium in Anaheim DTR/4GL N2p1 Activities in Atlanta DTR/4GL SIG Sponsored Working Group N8p1, N8p1, N8p2, N8p2, N8p3 ADDING Adding a Soundex Function to DATATRIEVE N7p5 Adding the Function LIB$TRIM_FILESPEC to DATATRIEVE N9p3 ANAHEIM Anaheim Contest at Wombat Magic in N1p9 Anaheim DTR/4GL Activities at the 1988 Fall Symposium in N2p1 Anaheim, CA Results of Problem Contest at Wombat Magic 1988 Fall DECUS Symposium, N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 ANALYSIS Analysis and Digital's Responses PIR Ballots N1p4 Analysis of PIR Ballots N12p5 APPLICATIONS Applications Cross Referencing DATATRIEVE N10p1 ATLANTA Atlanta DTR/4GL SIG Sponsored Working Group Activities in N8p1, N8p1, N8p2, N8p2, N8p3 Atlanta DECUS ACCENT R Working Group News N12p3 Atlanta Symposia DTR/4GL SIG News of the N11p1 Atlanta Symposium INGRES Working Group Report for N12p3 AUTHOR Author Index of Wombat Examiner and 4GL Dispatch, Volumes 1 to 9 N2p12 B BAD Bad Dial-In Lines with DATATRIEVE (and DCL) Identifying N10p13 BALLOTS Ballots Analysis of PIR N12p5 Ballots Analysis and Digital's Responses PIR N1p4 BEFORE before Implementation A Seasonal Poem - 'Twas the Night N4p14 BIBLIOGRAPHY Bibliography Using VAX DATATRIEVE Database for a Scientific N10p5 C CALCULATING Calculating Median Time with DATATRIEVE N10p10 CALL Call for Product Improvement Requests (PIRs) N5p1 CALLING Calling Utilities as DATATRIEVE Functions N11p6 CHOICE CHOICE OF Fields Sorting on COMPUTED BY N6p1 COMPUTED COMPUTED BY CHOICE OF Fields Sorting on N6p1 CONTEST Contest - Spring 1989 DATATRIEVE N7p1 Contest at Wombat Magic 1988 Fall DECUS Symposium, Anaheim, CA Results of Problem N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 Contest at Wombat Magic in Anaheim N1p9 CONTEXT Context (KWIC) Title Index - Volumes 1 to 9 Keyword in N3p3 CORTEX CORTEX Working Group Report N11p5 CROSS Cross Referencing DATATRIEVE Applications N10p1 D DATABASE Database for a Scientific Bibliography Using VAX DATATRIEVE N10p5 DATATRIEVE DATATRIEVE Adding a Soundex Function to N7p5 DATATRIEVE Adding the Function LIB$TRIM_FILESPEC to N9p3 DATATRIEVE Calculating Median Time with N10p10 DATATRIEVE Database for a Scientific Bibliography Using VAX N10p5 DATATRIEVE Parsing Text Using N2p9 DATATRIEVE (and DCL) Identifying Bad Dial-In Lines with N10p13 DATATRIEVE Applications Cross Referencing N10p1 DATATRIEVE Contest - Spring 1989 N7p1 DATATRIEVE Functions Calling Utilities as N11p6 DATATRIEVE; With a Note on Edit-Strings Measuring Disk Usage with N4p4 DCL DCL) Identifying Bad Dial-In Lines with DATATRIEVE (and N10p13 DECUS DECUS ACCENT R Working Group News Atlanta N12p3 DECUS Symposium, Anaheim, CA Results of Problem Contest at Wombat Magic 1988 Fall N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 DECUS Update Fall 1988 N4p3 DIAL-IN Dial-In Lines with DATATRIEVE (and DCL) Identifying Bad N10p13 DIGITAL'S Digital's Response to DTR/4GL SIG Product Improvement Requests N12p7 Digital's Responses PIR Ballots Analysis and N1p4 DISK Disk Usage with DATATRIEVE; With a Note on Edit-Strings Measuring N4p4 DISPATCH Dispatch, Volumes 1 to 9 Author Index of Wombat Examiner and 4GL N2p12 DTR/4GL DTR/4GL Activities at the 1988 Fall Symposium in Anaheim N2p1 DTR/4GL SIG News of the Atlanta Symposia N11p1 DTR/4GL SIG Product Improvement Requests Digital's Response to N12p7 DTR/4GL SIG Sponsored Working Group Activities in Atlanta N8p1, N8p1, N8p2, N8p2, N8p3 E EDIT-STRINGS Edit-Strings Measuring Disk Usage with DATATRIEVE; With a Note on N4p4 EDIT/SUMSLP EDIT/SUMSLP File Errata for ENSIGN N3p2 EDITOR Editor Letter to the N7p2, N11p3, N12p1 EDITOR'S Editor's Pen From the N1p1 EDITORIAL Editorial An N8p1, N9p1 ENSIGN ENSIGN EDIT/SUMSLP File Errata for N3p2 ERRATA Errata N5p12 Errata for ENSIGN EDIT/SUMSLP File N3p2 EXAMINER Examiner and 4GL Dispatch, Volumes 1 to 9 Author Index of Wombat N2p12 F FALL Fall 1988 DECUS Update N4p3 Fall DECUS Symposium, Anaheim, CA Results of Problem Contest at Wombat Magic 1988 N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 Fall Symposium in Anaheim DTR/4GL Activities at the 1988 N2p1 FIELDS Fields Sorting on COMPUTED BY CHOICE OF N6p1 FILE File Errata for ENSIGN EDIT/SUMSLP N3p2 FOCUS FOCUS Working Group Report N11p5 FROM From the Editor's Pen N1p1 FUNCTION Function LIB$TRIM_FILESPEC to DATATRIEVE Adding the N9p3 Function to DATATRIEVE Adding a Soundex N7p5 FUNCTIONS Functions Calling Utilities as DATATRIEVE N11p6 Functions for VAX-DATATRIEVE Some More String N12p9 G GROUP Group Activities in Atlanta DTR/4GL SIG Sponsored Working N8p1, N8p1, N8p2, N8p2, N8p3 Group News Atlanta DECUS ACCENT R Working N12p3 Group Report CORTEX Working N11p5 Group Report FOCUS Working N11p5 Group Report ORACLE Working N11p4 Group Report POWERHOUSE Working N11p5 Group Report Working N4p2, N5p1 Group Report for Atlanta Symposium INGRES Working N12p3 I IDENTIFYING Identifying Bad Dial-In Lines with DATATRIEVE (and DCL) N10p13 IMPLEMENTATION Implementation A Seasonal Poem - 'Twas the Night before N4p14 IMPROVEMENT Improvement Requests Digital's Response to DTR/4GL SIG Product N12p7 Improvement Requests Product N8p5 Improvement Requests (PIRs) Call for Product N5p1 INDEX Index - Volumes 1 to 9 Keyword N3p25 Index - Volumes 1 to 9 Keyword in Context (KWIC) Title N3p3 Index of Wombat Examiner and 4GL Dispatch, Volumes 1 to 9 Author N2p12 INGRES INGRES Working Group Report for Atlanta Symposium N12p3 K KEYWORD Keyword in Context (KWIC) Title Index - Volumes 1 to 9 N3p3 Keyword Index - Volumes 1 to 9 N3p25 (KWIC) (KWIC) Title Index - Volumes 1 to 9 Keyword in Context N3p3 L LETTER Letter to the Editor N7p2, N11p3, N12p1 LIB$TRIM_FILESPEC LIB$TRIM_FILESPEC to DATATRIEVE Adding the Function N9p3 LINES Lines with DATATRIEVE (and DCL) Identifying Bad Dial-In N10p13 M MAGIC Magic Wombat N1p11, N1p13, N1p15, N1p16, N1p16, N1p18, N1p20, N1p20, N2p3, N2p5, N2p5, N2p5, N2p5, N2p6, N2p7, N2p8, N5p6, N5p9, N6p2, N6p4, N6p5, N6p5, N6p7, N6p9, N6p9, N7p13, N7p13, N7p14, N7p15, N7p16, N7p17, N9p5, N9p6, N9p7, N11p9, N11p9, N11p9, N11p10,N11p10 Magic 1988 Fall DECUS Symposium, Anaheim, CA Results of Problem Contest at Wombat N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 Magic in Anaheim Contest at Wombat N1p9 MEASURING Measuring Disk Usage with DATATRIEVE; With a Note on Edit-Strings N4p4 MEDIAN Median Time with DATATRIEVE Calculating N10p10 MORE More String Functions for VAX-DATATRIEVE Some N12p9 N NEWS News Atlanta DECUS ACCENT R Working Group N12p3 News of the Atlanta Symposia DTR/4GL SIG N11p1 NIGHT Night before Implementation A Seasonal Poem - 'Twas the N4p14 NOTE Note on Edit-Strings Measuring Disk Usage with DATATRIEVE; With a N4p4 O ORACLE ORACLE Working Group Report N11p4 P PARSING Parsing Text Using DATATRIEVE N2p9 PEN Pen From the Editor's N1p1 PIR PIR Ballots Analysis of N12p5 PIR Ballots Analysis and Digital's Responses N1p4 (PIRS) (PIRs) Call for Product Improvement Requests N5p1 POEM Poem - 'Twas the Night before Implementation A Seasonal N4p14 POWERHOUSE POWERHOUSE Working Group Report N11p5 PROBLEM Problem Contest at Wombat Magic 1988 Fall DECUS Symposium, Anaheim, CA Results of N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 PRODUCT Product Improvement Requests N8p5 Product Improvement Requests Digital's Response to DTR/4GL SIG N12p7 Product Improvement Requests (PIRs) Call for N5p1 Product Status Report N4p1, N11p1 R REFERENCING Referencing DATATRIEVE Applications Cross N10p1 REPORT Report CORTEX Working Group N11p5 Report FOCUS Working Group N11p5 Report ORACLE Working Group N11p4 Report POWERHOUSE Working Group N11p5 Report Product Status N4p1, N11p1 Report Working Group N4p2, N5p1 Report for Atlanta Symposium INGRES Working Group N12p3 REQUESTS Requests Digital's Response to DTR/4GL SIG Product Improvement N12p7 Requests Product Improvement N8p5 Requests (PIRs) Call for Product Improvement N5p1 RESPONSE Response to DTR/4GL SIG Product Improvement Requests Digital's N12p7 RESPONSES Responses PIR Ballots Analysis and Digital's N1p4 RESULTS Results of Problem Contest at Wombat Magic 1988 Fall DECUS Symposium, Anaheim, CA N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 S SCIENTIFIC Scientific Bibliography Using VAX DATATRIEVE Database for a N10p5 SEASONAL Seasonal Poem - 'Twas the Night before Implementation A N4p14 SIG SIG News of the Atlanta Symposia DTR/4GL N11p1 SIG Product Improvement Requests Digital's Response to DTR/4GL N12p7 SIG Sponsored Working Group Activities in Atlanta DTR/4GL N8p1, N8p1, N8p2, N8p2, N8p3 SORTING Sorting on COMPUTED BY CHOICE OF Fields N6p1 SOUNDEX Soundex Function to DATATRIEVE Adding a N7p5 SPONSORED Sponsored Working Group Activities in Atlanta DTR/4GL SIG N8p1, N8p1, N8p2, N8p2, N8p3 SPRING Spring 1989 DATATRIEVE Contest - N7p1 STATUS Status Report Product N4p1, N11p1 STRING String Functions for VAX-DATATRIEVE Some More N12p9 SYMPOSIA Symposia DTR/4GL SIG News of the Atlanta N11p1 SYMPOSIUM Symposium INGRES Working Group Report for Atlanta N12p3 Symposium in Anaheim DTR/4GL Activities at the 1988 Fall N2p1 Symposium, Anaheim, CA Results of Problem Contest at Wombat Magic 1988 Fall DECUS N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 T TECHNIQUES TECHNIQUES ACCENT R TIPS & N10p4 TEXT Text Using DATATRIEVE Parsing N2p9 TIME Time with DATATRIEVE Calculating Median N10p10 TIPS TIPS & TECHNIQUES ACCENT R N10p4 TITLE Title Index - Volumes 1 to 9 Keyword in Context (KWIC) N3p3 U UPDATE Update Fall 1988 DECUS N4p3 USAGE Usage with DATATRIEVE; With a Note on Edit-Strings Measuring Disk N4p4 USING Using DATATRIEVE Parsing Text N2p9 Using VAX DATATRIEVE Database for a Scientific Bibliography N10p5 UTILITIES Utilities as DATATRIEVE Functions Calling N11p6 V VAX VAX DATATRIEVE Database for a Scientific Bibliography Using N10p5 VAX-DATATRIEVE VAX-DATATRIEVE Some More String Functions for N12p9 VOLUMES Volumes 1 to 9 Author Index of Wombat Examiner and 4GL Dispatch, N2p12 Volumes 1 to 9 Keyword in Context (KWIC) Title Index - N3p3 Volumes 1 to 9 Keyword Index - N3p25 W WIZARD Wizard Wombat N1p2, N1p3, N3p1, N5p1, N5p4, N6p1, N8p3, N9p1 WOMBAT Wombat Examiner and 4GL Dispatch, Volumes 1 to 9 Author Index of N2p12 Wombat Magic N1p11, N1p13, N1p15, N1p16, N1p16, N1p18, N1p20, N1p20, N2p3, N2p5, N2p5, N2p5, N2p5, N2p6, N2p7, N2p8, N5p6, N5p9, N6p2, N6p4, N6p5, N6p5, N6p7, N6p9, N6p9, N7p13, N7p13, N7p14, N7p15, N7p16, N7p17, N9p5, N9p6, N9p7, N11p9, N11p9, N11p9, N11p10, N11p10 Wombat Magic 1988 Fall DECUS Symposium, Anaheim, CA Results of Problem Contest at N4p7, N4p8, N4p8, N4p9, N4p9, N4p10, N4p10, N4p11, N4p11, N4p12, N4p13, N4p13 Wombat Magic in Anaheim Contest at N1p9 Wombat Wizard N1p2, N1p3, N3p1, N5p1, N5p4, N6p1, N8p3, N9p1 WORKING Working Group Activities in Atlanta DTR/4GL SIG Sponsored N8p1, N8p1, N8p2, N8p2, N8p3 Working Group News Atlanta DECUS ACCENT R N12p3 Working Group Report N4p2, N5p1 Working Group Report CORTEX N11p5 Working Group Report FOCUS N11p5 Working Group Report ORACLE N11p4 Working Group Report POWERHOUSE N11p5 Working Group Report for Atlanta Symposium INGRES N12p3