DECUS U. S. Chapter SIGs Newsletter, Volume 5, Number 2 October 1989 Wombat Examiner, Volume 11, Number 2 ---------------------------------------------------------------- Election Notice ---------------------------------------------------------------- The policies and procedures of the DATATRIEVE/Fourth Generation Language Special Interest Group requires that the SIG Chair must be (re)elected every two years. The current chair, was elected at the Fall 1987 Symposium and took office at the Spring 1988 Symposium. An election, therefore, will be held at the Fall 1989 Symposium in Anaheim; the next two-year term will begin at the Spring 1990 Symposium in New Orleans. Don Stern has declared his candidacy for re-election as SIG Chair. Other nominations may be make via DCS or at the open meeting of the SIG's Steering Committee on Sunday, November 5, 1989, at 6:00 PM in the DTR/4GL SIG Suite at the Marriott Hotel in Anaheim. Nominations will also be accepted at that time for the position of Vice-Chair of the SIG. The elections will be conducted at the meeting of the SIG Steering Committee on Friday, November 10, 1989, at 4:00 PM, also in the Suite. ----------------------------------------------------------------- From the Chairman Donald E. Stern, Jr., SIG Chair, Warner Lamber Co., Milford, CT ----------------------------------------------------------------- The symposium at Anaheim is rapidly approaching. The SIG Steering Committee is working very hard to make the symposium an enriching experience for all DECUS members and particularly those members with an interest in DATATRIEVE and other 4th Generation Languages. As usual the SIG will be hosting a suite at the Marriott Hotel in which we will have Digital hardware and software. Come to the suite to find an answer to a problem, volunteer to get involved in DECUS leadership, or just to escape the rigors of symposia. Additionally, the SIG will be sponsoring a variety of activities in a campground area. Some of these activities include meetings of the 4GL Working Groups. Members interested in Accent-R, Corvision (Application Factory), Focus, Ingres, Oracle, Powerhouse, RALLY, or Smartstar are encouraged to come to the working group meetings and get involved. Users of other 4GLs are invited to come seek out users with a common interest. I'm looking forward to this symposium in order renew acquaintances and to make new friends. I'm always looking for new volunteers as well. If you would like to get more involved, stop by and see me. ----------------------------------------------------------------- Volunteers Needed at Symposia Harry J. Miller, Volunteer Coordinator, Ontario, CA ----------------------------------------------------------------- Enhance your enjoyment of the Anaheim Symposium by participating in volunteer SIG Activities. Session chairs and suite hosts/hostesses are need to assist with SIG activities. Volunteers receive an appreciation gift of a much sought after Wombat Polo shirt. To participate, attend a drop-in meeting of volunteers between 5:00 and 6:00PM on Sunday, November 5, in the DTR/4GL SIG Suite in the Marriott Hotel (check in the lobby for the room number) or see Harry Miller, Volunteer Coordinator, at the Sunday evening Welcoming Reception (9:00 to 10:00PM). You may also contact Harry Miller by phone at 714-988-6481 extension 7798 at the Ontario California Police Department during the week before the Symposia if you would like to reserve a particular session chair. Session chairs have the best seat in the room - right up front! They introduce the speaker, control the question and answer session at the end of the talk, evaluate the presentation, enforce the DECUS commercialism policy, and assist the speaker with the lights and audio- visuals. Suite hosts/hostesses welcome attendees, help direct attendees to Digital engineers and experiences users to get their questions answered, and make sure the hardware doesn't spout legs. In addition to the Wombat Polo shirt, the SIG will also send a "thank you" letter to the volunteer's boss if the volunteer requests it. ----------------------------------------------------------------- RALLY Working Group, Fall '89 Symposium Primer Steven C. Fredrickson, Chairman, RALLY Working Group, Seattle, WA ----------------------------------------------------------------- Well, that time is upon us again. The DECUS Fall Symposium, this year being held in Anaheim, is shaping up to be another robust one for the DTR/4GL SIG. As chairman of the RALLY Working Group, I'd like to invite all of those users and abusers of RALLY, as well as those who are interested in learning about the product, to attend the various events scheduled for the week. At the time of publication, the preliminary schedule was fairly well- rounded. The schedule is outlined below. I'd like to offer some highlights. TUESDAY - November 7 2:00 - 3:00 pm DT074 RALLY Technical Overview (DEC Presentation) 3:00 - 4:00 pm DT073 RALLY Tutorial Forms/Reports (DEC Presentation) 4:00 - 5:00 pm DT075 Optim. Perf. w/RALLY & Rdb/VMS (DEC Presentation) THURSDAY - November 9 12:00 - 1:00 pm DT061 RALLY - A Case Study (User Presentation) 1:00 - 2:00 pm DT078 RALLY with 3GLs (DEC Presentation) 2:00 - 3:00 pm DT048 RALLY User Panel (Users Presentation) 3:00 - 4:00 pm DT047 RALLY Working Group (Redondo Room) 4:00 - 6:00 pm DT049 RALLY/TEAMDATA Clinic (Problem Solving Time!) 8:00 - 10:00 pm DT005 Wombat Magic Tuesday, November 7th, the sessions are being presented by Digital. The first session is geared for those just looking at the product. The following two sessions provide some helpful hints and insight into application development. Thursday, November 9th, there is a full afternoon of sessions. The first RALLY session, at noon, is given by a speaker from the Department of Transportation. Their application is a rather interesting one, and the presentation should offer some useful insights. Following at 1:00 pm is a session given by Digital on RALLY and 3GLs. If you're looking into integrating RALLY with 3GLs or vice-versa, this session is a must. The Panel Discussion at 2:00 pm brings together various RALLY users who will share with the world their actual (and often candid) viewpoints on the product. Come and hear the perspective from the 'man on the streets'. From 3:00 - 4:00 pm is the Working Group meeting in the Redondo Room. This is the opportunity to meet other users of RALLY along with Digital personnel and discuss in an open forum your ideas and concerns. I highly recommend this meeting for current RALLY users. An added bonus this year is that the RALLY/Teamdata Clinic is scheduled right after the Working Group Meeting, from 4:00 - 6:00 pm in the DTR/4GL SIG Suite. The Clinic is your chance to go one-on-one with either a Digital developer or experienced RALLY user and get some answers to those tough-to-solve problems. Last, but not least, is Wombat Magic. Got a neat RALLY trick? This Session is just for you. Other users like yourself get together to share some 'magic' and good times. There may even be a prize for the best RALLY Magic! All in all, Anaheim looks like another fun and exhaustive time! We hope to see you there, so until then ... RALLY Ho!! ----------------------------------------------------------------- Notice to all VAX/FOCUS users, and potential users Les Hulse, FOCUS Working Group Chair, Boston, MA ----------------------------------------------------------------- A session sponsored by all of the 4GL working groups entitled "User Panel Comparison of 4GLs" will be presented on Monday, November 6, from 11:30AM to 1:00PM. This session will present user experiences in implementing different 4GLs in different environments and will serve as a springboard for other 4GL-oriented sessions throughout the symposium. For all users interested in FOCUS on the VAX, there will be eight sessions and a working group meeting at the fall 1989 DECUS Symposium (November 6-10). Six of the sessions will be sponsored by the DATATRIEVE/4GL SIG and one each by Business Applications and Office Automation SIGs. A working group meeting is scheduled for 9-10PM on Monday evening in the Redondo Room. A key discussion topic will be how the working group will approach the 4GL problem presented in the September 1989 DECUS SIG Newsletter. This meeting is open to all symposium attendees with an interest in FOCUS (who are still awake at the end of the first day of sessions). A "FOCUS Wish List" will again be available in the DATATRIEVE/4GL campground for user submissions. IBI will respond to the requests in the "Wish List" session on Thursday evening from 8-9PM. We hope to have enough time to also take questions from the floor. ---------------------------------------------------------------- Pre-Symposium Report of the Cortex Working Group Eric S. Dubiner, Cortex Working Group Chair, Wilmington, DE ----------------------------------------------------------------- The Cortex Working Group will once again be meeting as a Birds-of-a-Feather session in Anaheim. Check the Update.Daily BOF schedule for time and place. Since Atlanta, I have been working with Cortex, and their user group CORUS, to create a direction for the working group. I have been told that we will have at least one person from Cortex Product Engineering present at the working group meeting to answer questions and respond to comments. We have an opportunity to present to Cortex our concern as to the the direction of the product ... so come prepared for a productive working meeting. If you have any questions or would like to be included on the future mailings of the Working Group, please do not hesitate to contact me at the address given in the list of SIG officers in the back of the newsletter. ----------------------------------------------------------------- Accent R Tips and Techniques Donna E. Lehman, ACCENT R Instructor, NIS ----------------------------------------------------------------- @SCN_READ_KEYSTROKE When using @SCN_READ_KEYSTROKE in a PM or CM, it will be executed the number of times which you indicate a value to be compared to its result: LEAVE IF @SCN_READ_KEYSTROKE EQ 278, 13 will require two RETURNs to leave this line. It will read the first key and if it isn't PF3, will wait again for the next read to see if it's 13 (a RETURN). If this is causing delays and the necessity for repeated keystrokes, rewrite the code as follows: @SCN_READ_KEYSTROKE TO @INTEGER LEAVE IF @INTEGER EQ 258, 13 Now the keystroke will be read once and the value checked immediately. SCREEN PUT_CHARS If you indicate @SCN_ERASE in a SCREEN PUT_CHARS command, all characters on that line will be erased before the new text is displayed. Specify @SCN_NOERASE if you want to keep the original text in addition to the new characters. @FILL_ACTION SETS @SCN_TERM_CODE If you set "END" to @FILL_ACTION, be aware that SMF will put the value of @SCN_END_CODE into @SCN_TERM_CODE before exiting the FILL FORM. If you use PF3 to terminate (258 TO @SCN_CANCEL_CODE), and your PERFORM ALWAYS AFTER routine sets "END" to @FILL_ACTION, @SCN_TERM_CODE is not going to be 258 (PF3) after the FILL has ended, but will be 26 (CTL-Z), or whatever the value you have set to @SCN_END_CODE. DATA INDEX ON MULTIPLE FIELDS If you usually sort and search on more than one field, define them as a combined domain in the data index: DOMAIN ST_CITY ON STATE,CITY To select, a semicolon is an "AND" condition... FIND DOMAIN ST_CITY WHEN STATE;CITY EQ 'OHIO';'PARIS' and is faster than FIND IF STATE EQ 'OHIO' AND CITY EQ 'PARIS' CODE SEGMENTS RELATE statements can now be specified in Code Segments (after version 10.09) to be included in PMs. Any code may be written in Code Segments and included where it would be typed into a CM, DI, PM, SD, SF or ID, not just PMs. @AUX AND @EOF @AUX is usually used to determine if a record was retrieved from a data set (e.g., LEAVE IF @AUX NE 'YES'). It's not the entire or only solution to the last or bad record situation, however. In addition, consider @EOF EQ 'YES' to indicate end of file and check the value of @AUX to determine what really caused the @AUX NE 'YES'. Be sure to label @EOF - there's one for each open data set. START:10 GET FROM X1 NEXT RECORD HUSH LEAVE:10 IF @AUX NE 'YES' PERFORM DISPLAY_FIELDS REPEAT:10 EXIT ROUTINE IF @EOF:X1 EQ 'YES' PERFORM FAILED_OPEN IF @AUX EQ 'OPEN' or check for @AUX's other values (CLOSE, DUP, EMPTY, LOCK, MISSI, etc.). The "last record" read might not be the last record. Quiz What is the result of the following? *USE DS DEC *SELECT WITH NISINC ON VAX SHOW ACCENT(R) _ _ _ _ The DBL is as follows... SD NISINC: SD DEC: 0001 VAX,C,2 0001 VAX,C,2 0002 R,I,2 0002 ACCENT,C,6,OCCURS 4 DS NISINC: DS DEC: X1 2 X1 A B C D X2 1 X2 E F G H X3 4 X3 P Q R S X4 1 X4 T U V W ----------------------------------------------------------------- Dear Wombat Wizard ----------------------------------------------------------------- Dear Wombat Wizard: We deal with data which can have a large dynamic range so we use USAGE IS REAL data type. Sometimes when we store data into a record we can not retrieve that record with an EQUALS RSE (record selection expression). The problem most often occurs with the values 0.3 and 0.6, but I suspect that other values will exhibit the anomaly as well. Why can't we retrieve the data this way and how can be work around this problem? Signed, Have a REAL Problem Dear REAL Problem: This is a REALly interesting problem; it is one related to the representation of the data; and similar problems occur in almost every computing language. However, this particular one is rather unique to VAX-DATATRIEVE. So that everyone can follow the details, I'll construct a test domain upon which we can show this particular problem. Consider: DEFINE DOMAIN TEST USING TEST-RECORD ON TEST.DAT; DEFINE RECORD TEST-RECORD USING 01 TEST-REC. 03 REAL-FIELD USAGE IS REAL. ; Then use the following procedure to put some test data into the domain. DEFINE PROCEDURE LOADIT DEFINE FILE FOR TEST; READY TEST WRITE DECLARE X PIC 9V99. X = 0.0 REPEAT 100 BEGIN X = X + 0.01 STORE TEST USING REAL-FIELD = X END END-PROCEDURE Then, see which records we can retrieve with the procedure DEFINE PROCEDURE TESTIT DECLARE COUNTER USAGE IS INTEGER. DECLARE X PIC 9V99 EDIT-STRING IS 9.99 . READY TEST SHARED READ X = 0 REPEAT 100 BEGIN X = X + 0.01 COUNTER = 0 FOR TEST WITH REAL-FIELD = X COUNTER = COUNTER + 1 IF (COUNTER EQ 0) THEN PRINT X END END-PROCEDURE When we execute TESTIT, we get DTR> :TESTIT X 0.15 0.23 0.27 0.30 0.43 0.46 0.49 0.53 0.54 0.59 0.60 0.67 0.73 0.86 0.92 0.98 0.99 Thus, we find seventeen numbers which we stored which we can not retrieve with the same value we used in the STORE! If we change the data type on the field REAL-FIELD to USAGE IS DOUBLE, USAGE IS G-FLOATING, USAGE IS H-FLOATING, or PIC 9V99 we can retrieve all of the records. However, if we try the procedure TESTIT in one of the version of DATATRIEVE-11 we can retrieve none of the records!! The root of the problem is how data is stored and compared in one or more of the many possible pairs of data types. Floating point data types such as USAGE IS REAL are represented and stored as a signed fraction (a number between -1 and +1) which is called the mantissa times a power of two which is called the exponent. [More precisely, a REAL datum is four contiguous bytes starting on an arbitrary byte boundary. Bits are labeled from the right, 0 through 31. The form of a REAL datum is sign magnitude, with bit 15 the sign bit, bits 14:7 an excess 128 binary exponent, and bits 6:0 and 31:16 a normalized 24-bit fraction with the redundant most significant fraction bit not represented.] Thus, the representation of any number which is not the sum of powers of twos is an approximate one when stored in a finite number of bits. We have exactly the same problem in representing one third in finite number of decimal digits as in 1/3 = 0.33333... When DATATRIEVE encounters a record selection expression like WITH REAL-FIELD = STRING-VALUE DATATRIEVE tries to convert the value on the left side of the equals sign and the value of the right side of the equals sign to a common data type with equivalent precision. This works if the right side is a STRING data type and the left side is DOUBLE, G-FLOATING, H-FLOATING, or STRING, but sometimes fails if the left side is REAL. However, if the Boolean comparison involves ANY KIND OF A CALCULATION such as WITH REAL-FIELD = CALCULATE-VALUE both sides are converted to H-FLOATING data type (the type with the most precision and greatest dynamic range). [It will be left for the reader to show that if the procedure TESTIT is modified by FOR TEST WITH REAL-FIELD = 1.0 * X the Boolean fails on a different and larger set of cases!] If you this this behavior is strange, consider the affect of trailing zeros (implied precision) in the right side string value with DTR> find test with real-field = 0.3 [0 records found] DTR> find test with real-field = 0.30 [0 records found] . ! keep trying with more and more trailing zeros . . DTR> find test with real-field = 0.3000000000000000 [0 records found] DTR> find test with real-field = 0.30000000000000000 [1 record found] DTR> find test with real-field = 0.300000000000000000 [1 record found] DTR> find test with real-field = 0.3000000000000000000 [0 records found] DTR> find test with real-field = 0.30000000000000000000 Data conversion overflow. [0 records found] Clearly, at least clearly to the Wizard, this is a problem in the precision of the data in the EQUALS RSE. This problem also should be looked at a bit more carefully by the VAX-DATATRIEVE developers see if something more can be done to make this behave a bit more predictably. There is one fairly obvious way (at least, it is obvious to the Wizard) to force DATATRIEVE to use the same precision on both sides of the record selection expression. This can be accomplished with the FORMAT USING construct. An example of this would be WITH FORMAT REAL-FIELD USING 9.99 = STRING-VALUE This would cause DATATRIEVE to do the comparison as strings. However, this would not work for the full dynamic range of data that could be stored in the real field. If the value on the right side of the RSE is prompted for, one could format both sides like WITH FORMAT REAL-FIELD USING 99.99 = FORMAT *."value" USING 99.99 Another way would be to use a global variable which has exactly the same data type as the field used in the RSE. Consider DECLARE TEMP-REAL USAGE IS REAL. TEMP-REAL = *."value" READY TEST FIND TEST WITH REAL-FIELD = TEMP-REAL In this case, the FIND will always retrieve the desired records since the data conversions AT THE STORE and AT THE RETRIEVE are exactly the same. One of the best features of the DATATRIEVE is the automatic data conversion that it does behind the scenes - out of sight of the user. This is especially true for conversion of strings to and from numbers and the conversion of date data type. However, there are situations when the user, weather a novice wombat breeder or a wizard, must keep in mind what is really going on at the level of bits and bytes to produce the desired results. However, if you want to avoid this problem and can afford the space (4 extra bytes), you might want to use USAGE IS DOUBLE rather that USAGE IS REAL. Signed, The Wombat Wizard (WDP&SH&JG) Part 3 of Spring '89 Wombat Magic will appear next month. ----------------------------------------------------------------- Special RALLY PIR John L. Henning, Digital Counterpart, Nashua, NH T. Chris Wool, PIR Coordinator, du Pont, Newark, DE ----------------------------------------------------------------- Digital seeks feedback from users of RALLY. What improvements would you like to see in future versions? In particular, we encourage you to use the DTR/4GL SIG Product Improvement Request (PIR) process. RALLY Engineering has some specific PIRs for which we request feedback. If you are a RALLY user, please read the attached lists of suggestions, and give us your feedback by voting in the PIR process. In addition, you can discuss the fine points of the suggestions by: - Entering a REPLY to one of the Notes on DECUServe dealing with RALLY - Attending Fall DECUS and discussing them with the Digital representatives in the DTR/4GL Suite. DECUServe provides an electronic conferencing system for DECUS members; subscription information is available by calling 508-480-3418 or writting DECUS - DECUServe Processing 219 Boston Post Road, BP02 Marlboro, MA 01752-4605 Discussion of RALLY primarily occurs within the DATATRIEVE conference, since RALLY is one of the products covered by the DTR/4GL SIG. Please see Notes 57-62 within the DATATRIEVE conference. * * * INSTRUCTIONS * * * A "point allocation" scheme will be used to determine your likes and dislikes for a particular product improvement request. You have a total of 50 points with which to vote. You may allocate either positively (in favor of a PIR) or negatively (against a PIR). The number of points you allocate to a particular PIR indicates how strongly you feel about it. In order to assure a wide range of choices, however, you may not allocate more that 10 points (positive or negative) to any one PIR and the absolute value of the total may not exceed 50 points. Use the ballot which is in the Questionnaire Section in the back of the newsletter. You may copy the ballot if you prefer rather than removing a page from your newsletter. You may submit your ballot electronically on DECUServe (deadline December 4); you may deliver your ballot in person to the DTR/4GL SIG Suite or to one of the RALLY Working Group offices at the Anaheim Symposium (deadline November 10); or you may mail your ballot to Chris Wool at the address indicated on the PIR ballot (deadline for receipt of mailed ballots is December 15). NOTE: The only commitment RALLY Engineering has is to respond in writing to the top ten PIRs in the overall ranking, for publication in the Wombat Examiner and 4GL Dispatch. The submission of PIRs by RALLY Engineering in no way implies or states a commitment by RALLY Engineering to implement the proposed PIR. End-user features: RALLY developers create applications which are run by end-users. The PIRs below would provide additional features for application end users: F89-1 Abstract: Provide 'Undelete record' command Discussion: RALLY applications allows users to delete a record with a single keystroke. If autocommit is in effect, the user might delete the wrong record without the ability to recover. This option would allow users to restore the deleted record. Nominations for what keystroke should be bound to "undelete record" will be accepted on DECUServe, at DATATRIEVE note #58]. F89-2 Abstract: Require confirmation before delete Discussion: The RALLY Guide to Application Development explains how to attach a "confirm before delete" option to a form. This PIR suggests that the application definer be able to select this feature simply by checking a box on the form definition. [For discussion at note 58: should the confirmation message be customizable by the application definer?] F89-3 Abstract: Remember previous query criteria Discussion: Sometimes the user wants to follow up a query with a slightly different query. This option would cause the application to restore the previous query criteria when re-entering query mode, so the user could then edit to make changes. [Again, DECUServe can be used to discuss fine points, such as whether this behavior should become the default.] F89-4 Abstract: Allow 'next/previous record' to cross group boundaries Discussion: RALLY form/reports consist of "groups". Navigation commands (such as arrow keys) generally move only within the current group, which means that the the user should understand the form/report group structure. An alternative navigation model would hide the group structure from the end user by allowing next/previous record commands to cross group boundaries. F89-5 Abstract: Display current mode Discussion: RALLY Form/Reports can be used in various modes (browse, insert, update, query ...). This PIR suggests that RALLY prominently display the current mode, to help the users understand their current state. [Note: Screen space would be required; suggestions about where to place the mode display are welcome on DECUServe at DATATRIEVE note 58.] F89-6 Abstract: Step-by-step queries Discussioni: This feature would provide the application user with very specific step-by-step instructions when performing a query, automatically giving hints at each step of entering the mode, moving to a field, typing in a valid query expression, and executing the query. Report features: F89-7 Abstract: Adjust size of form/report to current environment Discussion: Sometimes people wish to define a single form/report for use on different sized devices (for example, a 24-line VT330 screen, a 48-line DECterm window, and a 60-line piece of paper). RALLY lets you do this, but each form/report has a single "page length" which is used in all situations. This can result in paper reports with lots of white space, or reports that you can only see part of on the screen (until you scroll them). This proposal would add an option to adjust form/reports to the size of the calling RALLY task. F89-8 Abstract: Character string formatting Discussion: RALLY currently provides the ability to format numbers and date strings on output, but not character strings. This option would provide output formatting of character strings. F89-9 Abstract: Set terminal width from RALLY Discussion: RALLY tasks can be of arbitrary width, and are formatted to fit the environment in which they are run. For example, a 132 column report can be run on an 80-column terminal, and the user can scroll through it. If that same report (and task) were run on a 132-column terminal (or DECterm window), the user need not scroll at all. At this time, RALLY makes no attempt to re-size the device it is using. The proposed feature would provide some method for changing the device size from RALLY. [DECUServe discussion of details is welcome, such as whether resize should be automatic on invocation of a new task, or done explicitly by an ADL function. Please enter your opinions at DATATRIEVE note 59] F89-10 Abstract: Don't start parent record on a separate page from children Discussion: This option would provide better widow/orphan control by not starting a parent record unless at least some of its children will also fit on the same page. Menu features: F89-11 Abstract: Extend Menu Builder to include All-in-1 style menus Discussion: RALLY menus can look like All-in-1 style menus today, but only after the developer edits them. The default style is similar to VAX TEAMDATA. This option would provide another default style, similar to ALL-in-1. F89-12 Abstract: Display menu choices according to authorized access Discussion: RALLY allows the application definer to associate passwords with menu choices. This PIR suggests that both selection and display of menu choices should be controlled through a protection scheme based upon authorized user access. Form features: F89-13 Abstract: Enhance autocommit features in parent-child situations Discussion: "Autocommit" causes changes to be applied to the database as soon as the user leaves the current record. This definition implies that when the user moves the cursor from a parent record to a child record, the parent is committed. The proposed enhancement would defer committing until the user moves to a higher group, or moves to another record in the parent group. No commits would occur when the user moves back and forth between a parent record and its children. F89-14 Abstract: Highlight current field Discussioni: This feature would allow highlighting of the current field. [Should a highlighted current field remain highlighted when the user moves the cursor over to the List Of Values? Opinions welcome on DECUServe, at DATATRIEVE note 61.] F89-15 Abstract: Provide more action sites Discussion: RALLY provides a wide variety of "action sites", where the application developer can add additional processing or affect flow of control. This feature would further expand the set of available sites, for example, before/after visiting record, before/after performing query, after user presses INSERT key. [To discuss what specific action sites are needed, please reply to DATATRIEVE note 61 on DECUServe.] F89-16 Abstract: Ability for ADL to move the cursor to a given field Discussion: ADL procedures are able to move the cursor from one field to the next (or previous field). This feature would allow a procedure to move the cursor directly to a specific named field. F89-17 Abstract: Ability to set keypad to numeric or "application" mode Discussion: Data entry applications sometimes require the keypad to be in numeric mode. This PIR would add an option in ADL and/or a command available on to the end user that changes the mode of the keypad. F89-18 Abstract: Multiple legends for a field Discussion: RALLY currently allows the definer to specify text that pops up whenever the user visits a given field. This is a popular feature. A proposed enhancement would provide the ability to specify more than a single legend for a given field, depending on the circumstances. [For discussion: how should the legend be selected? According to the mode currently in effect? By an ADL procedure? Other?] F89-19 Abstract: Option to make fields required in query mode Discussion: Some applications want to require that, if the user does a query, the user must query on a certain field, for example, to reduce the number of records retrieved. Note: a new action site "before executing query" would allow definers to get the effect of this feature, although by writing ADL procedures. F89-20 Abstract: Option to suppress LOV validation in query mode Discussion: Some applications have stricter restrictions on data entry than on query. This option would skip List of Values Validation in query mode. F89-21 Abstract: Trap broadcast messages Discussion: This feature would trap incoming broadcast messages and present them in an orderly fashion. F89-22 Abstract: Ability to vary the text of the working message Discussioni: Whenever RALLY applications perform a long operation, RALLY automatically displays a "Working" message. This option would allow application definers to define what text should be displayed, rather than just "working", and thereby give a more informative message. Definition time enhancements: F89-23 Abstract: DCL object Discussion: RALLY applications can execute DCL commands by an External Link to call LIB$SPAWN. This option would allow the definer to directly specify a DCL command that is to be performed (for example at an action site) thus providing the convenience of not needing to define the external link. F89-24 Abstract: Ability to turn off Integrity Checking Discussion: RALLY applications are checked for correctness on a fairly frequent basis, for example as edits are completed to a form/report. Frequent integrity checking has the advantage of giving the application definer feedback about problems in a timely fashion, but for large applications integrity checking consumes significant time. This proposal would allow the definer to effectively say "I'm an expert - don't bother checking what I do until I tell you to." Of course, the user of this feature would have to accept the fact that when he finally does verify his application, there may be a great many errors to report. F89-25 Abstract: LSE for editing ADL Discussion: This feature would make it possible to use LSE and LSE templates when editing ADL procedures. F89-26 Abstract: Run-time variables from DML Discussion: A powerful feature of RALLY V2 is the ability to specify expressions that are evaluated at run-time and which restrict selection of records for a data source definition (DSD) when it is opened by a form/report. This proposal would extend the feature to also be available for DSDs opened through ADL's Data Manipulation Language. F89-27 Abstract: Option for the definer to turn on/off legends Discussion: RALLY "legends" provide incremental help messages to the user, and are a well-received feature for providing a friendly application environment. However, expert users may prefer to save the time required for screen painting legends. This option would provide a way for the definer to turn off display of all legends. F89-28 Abstract: Extend RALLY UPDATE to handle renaming of database fields Discussion: The RALLY UPDATE utility will automatically make certain changes to all Data Source Definitions based upon changes in the underlying database - for example, if the field is changed from text to numeric or the size is changed. But if a field is renamed in the database (e.g. EMP_NAME is deleted and EMPLOYEE_NAME is created), the definer must edit each DSD to reflect the change. This proposal would extend RALLY UPDATE to handle the case of field renaming. F89-29 Abstract: Extend use of CDD/Plus Discussion: RALLY makes significant use of CDD/Plus today; but there is room for extension, for example by extending impact analysis to additional RALLY objects or using additional attributes that are defined in the dictionary. [Discussion topic for DECUServe: what specific extensions are most important? See DATATRIEVE note 62.] F89-30 Abstract: Provide LOV "Starts With" for definition time Discussion: A new feature of RALLY V2.1 when using Rdb databases allows the end-user to type in the first few characters of a field, press Gold-Select, and see a list of choices that start with the entered characters. This PIR suggests providing similar capability within the RALLY Definition Environment.