DECUS U. S. Chapter SIGs Newsletter, Volume 5, Number 3 November 1989 Wombat Examiner, Volume 11, Number 3 ---------------------------------------------------------------- From the Editor's Pen ---------------------------------------------------------------- As you are heading out for Anaheim to the 1989 Fall DECUS Symposium, there are some reminders about activities at the symposia and some late-breaking news: o Digital made announcements in September at the time of European DECUS and early in October in the US of new versions of DATATRIEVE (and a lot of other products including some very interesting new ones). You will note the announcements which follow in this issue of the newsletter. You will also want to attend appropriate presentations in Anaheim for detailed information. o In last months issue of the newsletter a Special Rally PIR Ballot appeared. Interest in Rally is increasing very rapidly. Now is the time to give feedback to Digital about future directions of Rally. The deadline for receiving your returned Rally PIR ballots in December 15, 1989. o Bernadette Reynolds, our Symposium representative, reports that Working Groups meeting in Room 7 & 8 in the Convention Center have been moved across the street to the Palisades Room in the Hilton Hotel. For the DTR/4GL SIG, this will affect the Oracle Working Group meeting scheduled for Tuesday, 12:00 to 1:00PM which will now meet in the Palisades Room of the Hilton. Other Working Groups should not be affected, but you should check the Update.Daily schedule for any other last-minute changes. o Those who wish to volunteer to be a Session Chair for a DTR/4GL SIG sponsored session are invited to attend a drop-in meeting at 5:00PM in the DTR/4GL SIG Suite in the Marriott Hotel on Sunday, November 5. See the article by Harry Miller in last month's newsletter for the details. See you in Anaheim. Joe H. Gallagher, Editor ----------------------------------------------------------------- Announcing VAX DATATRIEVE V5.0 John L. Henning, DTR/4GL SIG Digital Counterpart, Nashua, NH ----------------------------------------------------------------- Digital Equipment Corporation is pleased to announce VAX DATATRIEVE V5.0. This article reviews the two major feature areas of the product (support for DECwindows and VAX CDD/Plus), and acknowledges contribution by DECUS to this release. The Wombat Does Windows VAX DATATRIEVE V5.0 takes advantage of several capabilities which are available on DECwindows workstations. The product provides: - Multiple windows. Windows are available for primary command input and results, HELP, Guide Mode, SHOW command output, and graphics output. - Scroll bars. You can move horizontally and vertically through output using the mouse and scroll bars. - Pull-down menus. Certain commonly-used options can now be selected directly from pull-down menus. - Screen resize. You can use the mouse to expand or contract the primary display area, up to 51 lines by 124 columns. - Dictionary navigation. You can use the mouse to navigate through dictionaries, expanding and contracting directories to find and select contents of interest. It should be noted that although you can select common options from menus, the DATATRIEVE language (commands and statements) is still available, and is in fact required for most data manipulation commands. Support for CDO-Format Dictionaries VAX DATATRIEVE V5.0 allows use of both older "DMU" (Dictionary Management Utility) dictionaries and the newer "CDO" (Common Dictionary Operator) dictionaries. DMU dictionary operations are identified by pathnames (for example, CDD$TOP.DTR$USERS.OLIVOTTO) and CDO dictionaries are identified by the VMS directory specification which provides the dictionary's anchor (for example, DISK3:[NINO]). DTR V5's dictionary support includes: - Read/write capability for storing and accessing DATATRIEVE record and domain definitions in CDO format dictionaries - Access to CDO field-level definitions for inclusion in DATATRIEVE record definitions stored in CDO format dictionaries - Access to CDO commands to perform pieces-tracking on domains and records - Use of search list logicals that let you treat multiple physical dictionaries as a single dictionary - Ability to ready a CDD$DATABASE object that points to an appropriate CDD$RMS_DATABASE object directly For this release of DATATRIEVE, we have chosen to provide full CDO support for the objects which are most commonly used by both DATATRIEVE and other applications, such as RECORDS, DOMAINS, and PORTS. DATATRIEVE's private dictionary objects (such as PROCEDURES and TABLES) continue to be stored in DMU-format dictionaries only at this time. Contribution by DECUS to DATATRIEVE V5.0 Digital thanks the DTR/4GL SIG for their contributions to Version 5.0. The SIG and its leadership have provided numerous requests for improvements to DATATRIEVE; have often served as Field Test sites for the product; have participated in early Human Factors testing; and had very direct input to recent decisions regarding the tuning of the product interface. We appreciate the SIG's contributions and look forward to continued partnership. VAX DATATRIEVE V5.0 will be on the demo floor at Anaheim Fall 89 DECUS Symposium, and two sessions (on Monday afternoon, November 6th) will be devoted to in-depth coverage of Version 5.0 features. ----------------------------------------------------------------- Announcing DATATRIEVE-11 Version 3.3 Joe Mulvey, Digital Equipment Corporation, Nashua, NH ----------------------------------------------------------------- DATATRIEVE-11 is an interactive query, report-writing and data maintenance system designed to give non-computer professionals easy access to system databases. It has many on-line prompting and help features to simplify the tasks of defining, managing and retrieving data. DATATRIEVE-11 is especially useful for users such as business analysts and middle management, who make frequent and constantly changing requests for data from large, corporate databases. It can also be used to build and maintain small, personal databases. DATATRIEVE-11 V3.3 is supported on the RSX-11M, RSX-11M-PLUS, RSTS/E, Micro/RSX and VAX-11 RSX operating systems; and under VAX-11 RSX on the VAX/VMS operating system. All DATATRIEVE-11 based products provide common functionality using one set of sources across all supported operating systems. V3.3 FEATURES Some of the key enhancements made for DATATRIEVE-11 V3.3 are listed below. For more complete product information please refer to the appropriate Software Product Description: SPD 12.48 (DATATRIEVE-11); SPD 18.15 (Micro/RSX DATATRIEVE-11); or SPD 25.14 (PDP-11 DATATRIEVE/VAX). * DATATRIEVE-11 provides lexical functions consisting of the following four groups: Functions using numeric data Functions using alphanumeric data Functions using dates Functions relating to processes * DATATRIEVE-11 can now determine at installation time whether or not floating point hardware is present. If floating point hardware is present, inline floating point code can be excluded from the task image if desired. This feature, if used, provides the user with significant additional pool space. * A new EDIT interface to EDT, which replaces QED, has been added for easier editing. * Time capability has been added to the DATE datatype for better resolution of time. Previously the resolution of time for DATATRIEVE-11 was a day. * A new AUTOINSTAL based feature has been added to allow for easier installation. This feature will be available on: RSX-11M, RSX-11M-PLUS and RSTS/E. * A system default for the initialization file (QUERY.INI) has been added. * DATATRIEVE-11 can now build and use Supervisor Mode RMS on those processors where both the hardware and software support this feature. This feature will provide the user with significant additional pool space. * Documentation has been completely updated and repackaged. A new set of documentation will accompany this release which will provide a more comprehensive and easy to use documentation set. * This release provides full layered product support for the License Management Facility (LMF) (PDP-11 DATATRIEVE/VAX only). Support Plans A full range of Software Product Services is available. Please contact your SPS Business Account Specialist for a complete description of support plans and additional information for Self-maintenance, BASIC, DECsupport, Right-to-Copy Update, Installation, Media Update, and Documentation Update services. ----------------------------------------------------------------- Dear Wombat Wizard ----------------------------------------------------------------- Dear Wombat Wizard: Like most users, we use a combination of languages and tools to solve our computing problems. These include DCL, third generation languages, a word processor, graphics and statistical packages, and, of course, a lot of DATATRIEVE. Our users are technical and profession people who are NOT computer experts. We try to make applications which are easy to use and which require an absolute minimum of keystrokes. All of the languages and tools we use except DATATRIEVE allow the entry of only a carriage return to indicate a default or null entry. Our users find it a real pain to have to enter a SPACE and a RETURN at a DATATRIEVE prompts when everything else allows the entry of just a RETURN. Why does DATATRIEVE required the entry of at least one character and how can we work around this irritating DATATRIEVE restriction? Signed, Annoyed by an extract character Dear Annoyed: This is a really good question. So that all readers understand the significance of the question, consider the following apparently very simple situation: DTR> DECLARE FOO PIC X. DTR> FOO = *."value of Foo" Enter value of Foo: Enter value of Foo: Enter value of Foo: Enter value of Foo: DTR> DATATRIEVE (both VAX and PDP-11) will not accept the entry of nothing, and will keep prompting until the user enters a SPACE or some other non-null character ahead of the carriage return. The Wizard consulted some DATATRIEVE developers and they stated that the reason why DATATRIEVE requires non-null input is that it differentiates between the null string and the blank (all spaces) string. While in most cases DATATRIEVE could make some reasonable assumptions about what to do with null input, there are some esoteric situations where a null string does not provide DATATRIEVE with enough data type information to do a reasonable conversion. However, the Wizard believes that the "restriction" for non-null input arises because of some conditions in the PDP-11 input/output routines; DATATRIEVE was originally written for RSX. In the current versions of DATATRIEVE-11, it is still not possible to use a null string. And this restriction in DTR-11 has been perpetuated in VAX-DATATRIEVE for upward compatibility. I guess the "bad" news is that's the way DATATRIEVE works and is likely to work from now on; the "good" news is that there are two work-arounds, which depending upon your mood, are relatively easy to do. I will describe the first and give full details for the second. If you use a 3GL front end to callable DATATRIEVE, you can control all terminal input - both commands and statements as well as data. An example of this is command line recall using SMG$ calls as described in an article by Dana Schwarts, Volume 2, Number 2, page DTR-3. Your 3GL code could be modified to allow a null input and convert it to a blank. The second work-around would be the use of a function such as FN$DTR_INPUT to accomplish the input. I have written the function in FORTRAN because FORTRAN is the most widely licensed 3GL on Digital computers (and because that is the 3GL that the Wizard has), but in this case, VAX-BASIC would be a more appropriate language because BASIC allocates string variables in a way which is more compatible with DATATRIEVE. Anyway, the function is: INTEGER FUNCTION DTR_INPUT(PROMPT_MIDDLE, RETURNED_STRING) ! An integer function which partially mimics DATATRIEVE input, ! but which allows the input of just a . CHARACTER*(*) PROMPT_MIDDLE ! the prompt between "Enter " & ": " CHARACTER*(*) RETURNED_STRING ! the returned input string CHARACTER*140 PROMPT ! allow for a big prompt string INTEGER STATUS ! the status returned from sys calls INTEGER*2 INPUT_CHAN ! the channel for I/O INTEGER CODE ! QIOW parameter INTEGER INPUT_BUFF_SIZE ! input buffer size INTEGER PROMPT_SIZE ! the size of the prompt string INTEGER INPUT_SIZE ! actual length of input string PARAMETER (INPUT_BUFF_SIZE=255) ! this is too big, but ... CHARACTER*255 INPUT INCLUDE '($IODEF)' ! get definitions for FORTRAN STRUCTURE /IOSTAT_BLOCK/ ! I/O block structure INTEGER*2 IOSTAT, TERM_OFFSET, TERMINATOR, TERM_SIZE END STRUCTURE RECORD /IOSTAT_BLOCK/ IOSB ! actual I/O block INTEGER*4 SYS$ASSIGN ! system call to assign a channel INTEGER*4 SYS$QIOW ! system call to read with wait INTEGER*4 SYS$DASSGN ! system call to deassign a channel ! ! assign a channel to do I/O ! STATUS = SYS$ASSIGN('SYS$INPUT', INPUT_CHAN,,) IF (.NOT. STATUS) CALL LIB$SIGNAL (%VAL(STATUS)) ! ! set code for read with prompt ! CODE = IO$_READPROMPT ! ! determine the length of the prompt string passed in ! STATUS = STR$TRIM(PROMPT_MIDDLE, PROMPT_MIDDLE, PROMPT_SIZE) ! ! if string is too long, truncate it to 132 characters ! IF (PROMPT_SIZE .GT. 132) THEN PROMPT_SIZE = 132 ! truncate to 132 if too big END IF ! ! prepend 'Enter ' and append ': ' to be compatible with DTR ! PROMPT = 'Enter '//PROMPT_MIDDLE(1:PROMPT_SIZE)//': ' ! ! increase size of prompt string by 8 characters (size of 'Enter'&': ' ! PROMPT_SIZE = PROMPT_SIZE + 8 ! ! do read with prompt ! STATUS = SYS$QIOW(, 2 %VAL(INPUT_CHAN), 2 %VAL (CODE), 2 IOSB, 2 ,, 2 %REF(INPUT), 2 %VAL(INPUT_BUFF_SIZE), 2 ,, 2 %REF(PROMPT), 2 %VAL(PROMPT_SIZE)) ! ! deassign the I/O channel ! STATUS = SYS$DASSGN(%VAL(INPUT_CHAN)) ! ! return string; if too long it will be truncated to size of ! returned_string ! RETURNED_STRING = INPUT(1:IOSB.TERM_OFFSET) ! ! tell DTR of a successful completion of this function ! DTR_INPUT = 1 RETURN END Now to connect this function to DATATRIEVE, you need to add the following MACRO code to DTRFND.MAR: ; FN$DTR_INPUT - ; input is a string ; output is a string $DTR$FUN_DEF FN$DTR_INPUT, DTR_INPUT, 2 $DTR$FUN_OUT_ARG TYPE = FUN$K_STATUS $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 1 $DTR$FUN_IN_ARG TYPE = FUN$K_TEXT, OUT_PUT = TRUE , ALL_LEN = 255 $DTR$FUN_NOOPTIMIZE $DTR$FUN_END_DEF Then compile the code, add it to the library, and relink DATATRIEVE something like: $SET DEFAULT DTR$LIBRARY $MACRO DTRFND $FORTRAN DTR_INPUT $LIBRARY/REPLACE DTRFUN DTRFND, DTR_INPUT $@DTRBLD The function FN$DTR_INPUT can be used any place where one would use the "*" to input data to DATATRIEVE. For example: declare choice_value pic 9. choice_value = fn$dtr_input("menu selection [default is 1]") if (choice_value eq 0) then choice_value = 1 Enter menu selection [default is 1] : So a null input can be used. But the biggest advantage of using FN$DTR_INPUT is that the prompt can be computed. Currently one cannot have a computed prompt in DATATRIEVE. Consider: DTR> ready yachts modify DTR> for yachts modify using begin CON> price = fn$dtr_input("new price. Old price is "| - CON> format price using $$$,$$9.99) CON> end Enter new price. Old price is $36,951.00 : 40000 Enter new price. Old price is $17,900.00 : 20000 Enter new price. Old price is $27,500.00 : 30000 . . . DTR> This clearly has superior capabilities over the usual prompting in DATATRIEVE. But if we get something, we usually have to give something up. We loose the re-enter try when the input does not satisfy the validation clause on the field. Note that: declare price usage is real edit-string is $$$,$$9.99 valid if price between 10000 and 20000 . price = fn$dtr_input("new price") Enter new price : 30000 Validation error for field PRICE. print price PRICE $30,000.00 does not give a satisfactory result when the input is outside the valid range. But there is a way to work-around this as well. Consider declare price usage is real edit-string is $$$,$$9.99 . price = fn$dtr_input("new price") while price not between 10000 and 20000 begin print "Entered value not valid. Please reenter." price = fn$dtr_input("new price") end Enter new price : 30000 Entered value not valid. Please reenter. Enter new price : 9000 Entered value not valid. Please reenter. Enter new price : 15000 So a function like FN$DTR_INPUT can be very useful in certain situations, but it can not, and should not, be used to do away with the usual DATATRIEVE prompted input. Such a function for input does bring up some other interesting possibilities. With very little effort it would be possible to change DTR_INPUT by adding a second argument to do a read with a time-out. One could also change DTR_INPUT by adding a second entry point or a second argument which could be used for prompting with "Re-enter" rather than "Enter." It would even be possible to change the function to something like DTR_INPUT_VALIDATED in which the data type, and the upper and lower limit of valid input were passed, and the 3GL function would do the input validation. I hope you can put this function to good use so your users won't have to type any extra characters. Signed, The Wombat Wizard (WEP&JG) ---------------------------------------------------------------- Wombat Magic, Spring 1989 - Part 3 Session Co-Chairs: Dana Schwartz, DOD, Washington, DC Bert Roseberry, U. S. Coast Guard, Washington, DC Session Editor: Kyle R. West, Rally Editor, Teepak, Inc., Columbia, SC ---------------------------------------------------------------- Editors' note: The following is Part 3 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 2 appeared in the September 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. Lew Lasher, Digital Equipment Corporation, Nashua, NH This is Rally magic called "Rally Editing Made Simple." This came to us because a customer requested it a couple of weeks ago. Fortunately, just in time for DECUS. +------------------------------------------------------------------------+ | Problem: How to allow screen editing by the Rally illiterate user | +------------------------------------------------------------------------+ The customer ask us how they could make Rally easier to use, imagine that, for some of their users who are not enlightened in [the Rally definition system]. The customer developed applications that worked fine, but wanted the users of the applications to be able to do some minor editing. They wanted to allow the end users just to change the appearance of the screen and not the functionality. And they said, 'Well, we don't want to give them the whole Rally definition system, because they'll break everything'. Break everything in their shop too. [Laughter] 'We just wanted to permit them to use the screen editor'. And so we [DEC] came up with this solution here using Rally macros. +------------------------------------------------------------------------+ | Solution: | | | | A. Define macros to get the user to and from the screen editor. | | | | 1. application form/report edit | | 2. 2 | | 3. top | | | | B. Define a key definition file with a severely limited set of | | commands. | | | | 1. Exclude: DO | | Menu Commands | | Finish Action | | Coordinates | | Insert Line | | | | 2. Include: Macro 1,2,3 | | Quit Application | | | | C. Rally edit 'p1'/key=few_keys/macro=rally_made_simple | +------------------------------------------------------------------------+ And basically you give people macros to go just where you want them to go in the Rally definition system. So it is just like the shuttle buses here in Atlanta, you give people a way to get to the screen editor and a way to get back. So, I think it only takes 3 macros, as I have figured it out here. One is that I'm assuming that they get into Rally from DCL, that at the TOP level of the definition system, this [macro number 1] should get them, not to the screen editor, this gets them to the point where they have to name what form/report they want to edit. Then it well ask which form/report that they want to edit and then they can type that in [or select the F/R from the LOV]. After they have typed in the form/report they want to edit then do macro number 2, which flags that form/report. After putting the number 2 there I realized that this is bad style, I should have used the key word, but I guess the work is done, and I can't remember what the key word is -- screen or edit [screen is correct]. So I had a 50/50 chance, I chickened out and just used the number 2. That gets them to the screen editor. Then give them a way to get out. And this [macro number 3] will do it here, just FINISH ACTION to get out of the editor and that brings them back to the menu where they edited the form/report. And TOP will bring them back to where they started. This is multi-part, this is part A, giving them macros to go where they should go. In the next step [part B], we will prevent them from going anywhere else. And the way you prevent them from going anywhere else is using the key definition facility in Rally. Because you can't go anywhere without keys. And so you define a key definition file and you can do this by starting with your favorite set of keys, EDT or WPS whichever, you edit everything out of it to remove nearly every command. You get rid of the DO key and you want to get rid of all of the menu commands. You know you may not realize, but when you run a Rally menu, like you move the cursor up to a choice or down to a choice those are actually name commands, that you can read all about in the Rally Command Reference Manual if you have nothing better to do with your time. And there is also, even pressing on a menu, like typing something in and then pressing , that is a command that you can define another key for or chuck from the key definition file. So if you get rid of that then people can still type on the menu but they won't be able to execute anything on the menu except the things you've defined to them, which is macros. And let's see, I'm not sure about this, but I think you'll want to get rid of FINISH ACTION. I am not sure about that but what the hick, lets get rid of it too. I think QUIT ACTION is safe, but FINISH ACTION looks dangerous. And that thing in the form/report editor to bring up the coordinates screen, that is the GOLD A, you'll want to get rid of that because somebody could define an integrity error, we didn't want that to happen. And I think there is a command called INSERT LINE and that is when you press carriage return in the screen editor. Never press carriage return in the screen editor unless you're a Rally sophistic. And you do want to include a few keys for the users to be able to use, one is to include keys for the 3 macros you so carefully defined. And you have to give people a way out. I am not sure you might be able to get away with giving them QUIT ACTION -- oh I know why you don't want to include FINISH ACTION or QUIT ACTION, I knew there was a reason for this, it all comes back to me. If you include FINISH ACTION or QUIT ACTION then when they're in the screen editor they can exit from it, and get back some level of main use and may press one of your macros, that will work from some bizarre place in some wrong menu, and God knows what it will do. So take out FINISH ACTION and take out QUIT ACTION, but you got to give them some way to go out. You can give them QUIT APPLICATION and that will take them all the way out in case they do define an integrity error, that always gets you all the way out, works just as will as CONTROL Y. A little slow but more elegant. And I think that's it for keys. Oh by the way, I guess I should mention that when you're defining the macros you should use the real set of keys, because otherwise your typing would return and won't do anything. That's why that is step A and this is step B, it's sequential. And after you have done that, then you just give people some kind of captive command procedure, that lets them edit their desired file with these keys and with those macros. And there you are Rally for the illiterate. B. Paul Bushueff, DOT Transportation System Center, Cambridge, MA [Paul's magic is titled "Handling a Long LOV in Rally."] We had a problem about 3 or 4 months ago when we had to show to a user a long LOV list. That long LOV consisted of a sequence number and a description of that number. The problem is the way that Rally works, you can only start at the beginning and page to the end. +-----------------------------------------------------------------------+ | RALLY | | o Long LOV | |-----------------------------------------------------------------------| | Number Description | | ------ ----------- | | 20 Galley | | 201 Galley Store | | 202 Galley Sink | | 21 Bridge | | . . | | . . | | . . | +-----------------------------------------------------------------------+ Here we have a LOV of about 800 to 1000 elements. For some people who know the approximate number or know that it started with a series of 20 or 30 or something like that or they know that it had to do with a certain description group, we really wanted to be able to search them [the elements of the LOV] numerical or alphabetical and be about to start at a given point in the list. +-----------------------------------------------------------------------+ | o Need to enter proper number. | | | | - Some know the approximate number | | - Some know the description | +-----------------------------------------------------------------------+ The solution that we came up with was that the user would be allowed to enter on the form either a numeric starting point or put an asterisk and any number of characters. +-----------------------------------------------------------------------+ | Solution | |-----------------------------------------------------------------------| | o Enter Starting Value | | | | 20 | | or | | *GA | +-----------------------------------------------------------------------+ | o Disable Rally LOV validation | | o Use local function key | | | | ADL | | ----- | | - put number in a global variable | | use parameterized RSE (>=) | | call conditional LOV | | | | - if *ab | | put letters in global variable | | use alternate RSE | +-----------------------------------------------------------------------+ Then we made sure that the LOV validation is disabled in Rally, using a local function key, the ADL code at the local function site. If a number is entered it would store the number in a global variable, use the parameter RSE and use the >= search criteria. Then call the conditional LOV and what it would return would be a LOV starting with the numeric field that we had entered. The alternative is that if you put in an asterisk, it would recognize the asterisk as character and it would work exactly the same way, it would put the alphabetic characters following it in the global variable. Use an alternative RSE and it would return an alphabetic list. John L. Henning, Digital Equipment Corporation, Nashua, NH [John's magic is titled "Goof Proof Rdb for RALLY."] This one may not be all that magical but it is a really problem that arises. +------------------------------------------------------------------------+ | Assumption: RALLY/COBOL/DTR application updates a database with | | local validation - e.g. change salary for employee with | | employee.dept = current user's dept. | +------------------------------------------------------------------------+ Assume that you have an application that is written in Rally or COBOL or DATATRIEVE. Something where you get some fairly careful structure put in place. So that it will do exactly what you want it to do. Doing some validation which might be done at the time of the application, based on something that is determined there, at that time. For example, you might have an application which changes a salary for an employee, that you want to check that the employee department is equal to the department of the current user or you might check that the person is actually authorized to make changes to that department. +------------------------------------------------------------------------+ | Problem: What if user comes in with Teamdata, DATATRIEVE or RDO and | | does [his] own updates ?? | +------------------------------------------------------------------------+ The problem arises with what if somebody instead of running the application that you so carefully built, comes in with Teamdata, DATATRIEVE or RDO. I am motivated to write this, simply in response to Bert's claim that [his] would be the only Teamdata magic. This is actually a general problem more general than Teamdata but he might be coming in through Teamdata after you have so carefully setup the [Rally] application to limit what he can do. +------------------------------------------------------------------------+ | Solution: | | - Captive account "UPDATER" | | - RDO ACL UPDATER "read+write+delete..." | | - In application login [login.com] define user | | SYS$REMOTE_NODE SYS$REMOTE_USER and check it in the | | application | | - RDO ACL * "read" | +------------------------------------------------------------------------+ The solution is fairly sample. You create a captive account you might call it "UPDATER". Then in RDO you give it the ACL that only "UPDATER" has "read+write+delete...". In the login.com file for the captive account, it turns out that you can define a logical name which picks up the remote user and remote node. You check against that in the application. Then finally there is one last piece, what do you do with all Teamdata or DATATRIEVE users that you do want to allow to do reporting against this. You give them an ACL for read only. That's it. part 4 of Spring 1989 Wombat Magic and the Author, Title, and Keywork Index to Volume 4 will appear next month