ContributionsThis newsletter is a volunteer activity. There are no compensations given to any author or editor. Articles and letters for publication are encouraged from anyone. They may include helpful hints, inquiries to other users, reports on DECUS and SIG business, summaries of SPRs submitted to Digital, or any information of interest to users of either DATATRIEVE or 4th Generation Languages. However, this newsletter is not a forum for job and/or head hunting, nor is commercialism appropriate. Machine readable input is highly desirable and machine-to-machine transfer of material is preferred, but most anything legible will be considered for publication. Please send contributions, or for further information please contact either: Editor, DATATRIEVE Newsletter Joe H. Gallagher, Ph.D. c/o DECUS U.S. Chapter 4GL Solutions Company 219 Boston Post Road, BP02 10308 Metcalf, Suite 109 Marlboro, MA 01752 Overland Park, KS 66212 Editorials and letters to the editor within the Wombat Examiner and 4GL Dispatch are solely the opinion of the author and do not necessarily reflect the views of the Digital Equipment Computer Users Society, Digital Equipment Corporation, or the author's employer. All editorials are marked as #An Editorial"; letters to the editor always begin #Dear Editor". Table of ContentsDECUS U. S. Chapter SIGs Newsletter, Volume 4, Number 12 August 1989 Wombat Examiner, Volume 10, Number 12 Letter to the Editor DTR-1 Atlanta DECUS Accent R Working Group News DTR-3 INGRES Working Group Report for Atlanta Symposium DTR-3 Analysis of PIR Ballots DTR-5 Digital's Response to DTR/4GL SIG Product Improvement Requests DTR-7 Some More String Functions for VAX-DATATRIEVE DTR-9 About the authors... Bart Z. Lederman works for System Resources Corporation in Cambridge, MA; he holds a Masters of Electrical Engineering in Solid State Electronics and Communications from Rennselaer Polytechnic Institute. Bart is the Library Committee and PDP-11 Working Group representative of the DTR/4GL SIG; a regular speaker at Symposia; the artist for the Wombat Examiner and 4GL Dispatch and special projects coordinator for the SIG; a member of the DTR/4GL Executive Steering Committee; a 1984 recipient of the DATATRIEVE Greybeards Award; and the author of over 50 articles in the DECUS Newsletters. Letter to the Editor Dear Editor: Here is a little function to pass along to all nascent Wizards: attach to a parent process from DATATRIEVE. The code of the function is in BASIC, but those of you with FORTRAN should have no problem converting. MACRO-32 should not present too much of a problem either, since the routine is mostly system service calls. The DTR function definition follows it. FUNCTION Long BAS_Attach (String Prcnam) %Title 'BAS_ATTACH' %SBTTL 'Attach to a parent process' %Ident '1.0 22-FEB-1989 Jeff Chimene' Option Type = Explicit & , Size = Integer Long & , Size = Real Double & , INACTIVE = SETUP %Include 'STARLET' %From %Library 'SYS$LIBRARY:BASIC$STARLET' %Include 'LIB$ROUTINES' %From %Library 'SYS$LIBRARY:BASIC$STARLET' %Include '$JPIDEF' %From %Library 'SYS$LIBRARY:BASIC$STARLET' Record Item_List_3 Word buffer_length Word Item_code Long buff_address Long return_length_address Long mbz Long buff End Record Item_list_3 Declare Item_List_3 Itmlst & , Long Return_code & , Word Retlen itmlst::buff_length = 8 itmlst::buffer_address = loc(itmlst::buff) itmlst::return_length_address = loc(retlen) itmlst::mbs = 0 If prcnam = #" then itmlst::item_code = JPI$_MASTER_PID Return_code = SYS$GETJPIW(,,,itmlst,,,) Else itmlst::item_code = JPI$_PID Return_code = SYS$GETJPIW(,,prcnam,itmlst,,,) End If ! parent process name specified If (Return_code and 1%) then Return_code = Lib$Attach(itmlst::buff) End If END FUNCTION Return_code ! End of FUNCTION BAS_Attach The MACRO linkage to be included in DTRFND.MAR is: ; FN$ATTACH - Attach to a parent process ; ; No Output ; Input is a string descriptor containing a process name or null for master ; $DTR$FUN_DEF FN$ATTACH, BAS_ATTACH, 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_EDN_DEF The ATTACH function is useful if you want to use DATATRIEVE as a kept process. This allows you to pop between your main DCL session and a DATATRIEVE session. For example, your DCL session may be menu driven, with DTR one of its choices. If DTR is started as a sub-process, you can re-attach to the menu without losing context. $ ! First, let's start DATATRIEVE as a sub-process: $ SPAWN/PROC=DTR DTR Process DTR spawned Terminal now attached to process DTR VAX DATATRIEVE V4.2 DEC Query and Report System Type HELP for help DTR> show dictionary The default directory is _CDD$TOP.DTR$USERS.CHIMENE DTR> ! Return control to our PARENT process DTR> ! The null string says #return to parent" DTR> ! Anything else is assumed to be a process name DTR> FN$ATTACH('') Control returned to process Jeff Chimene [Attached to DCL in directory DISK$SMTPMS:[CHIMENE]] $ show proc/sub 9-JUN-1989 16:16:40:02 LTA3128 User: CHIMENE Processes in this tree: Jeff Chimene (*) DTR $ ! Now, return control to the DATATRIEVE session: $ ATTACH DTR DTR> show dictionary The default directory is _CDD$TOP.DTR$USERS.CHIMENE DTR> exit The following DCL command file can be used to determine if a new DATATRIEVE session should be started or an existing one resumed: $ dtr_Name := dtr $! $ 10$: $ Proc = F$Getjpi(F$Pid(Pid),"PRCNAM") $ If (Proc .EQS. dtr_Name) $then $ Write Sys$Output #[Attaching to kept dtr session]" $ Define/Nolog Sys$Input Sys$Command $ Attach #''dtr_Name'" $ Goto Leave $Else $ If (Pid .NE. 0) then Goto 10$ $EndIf $! $ Write Sys$Output #[Starting a new kept dtr session]" $ Define/NoLog Sys$Input Sys$Command $ spawn/nolog/proc="''dtr_Name'" dtr $! $ Leave: $ Write Sys$Output #[Attached to DCL in directory ''F$Env("Default")']" $ exit I've been using these routines for some time and found them to be quite useful. May your context always be current, Jeff Chimene Carondelet Health Services Tucson, Arizona [Editor's note: In the 1988 Spring PIR List (Volume 3, Number 7, March 1988), PIR number S88-27 requests that Digital add a function to allow attaching to a process or sub-process. Jeff has fulfilled that request very nicely!] Atlanta DECUS Accent R Working Group News Winston Tellis, Accent R Working Group Chair, Fairfield, CT We had a very productive symposium and our working group meeting laid the foundation for our Anaheim meeting. We came up with several excellent suggestions for proposed papers for Anaheim and they have in fact been submitted to our SIG. When we hear about their acceptance, we will inform you through this newsletter. The schedule will probably work for most companies to send their representatives for the day we are assigned for all the Accent R sessions. The new feature at Anaheim will be that instead of the 'Working Group' meeting, we have requested a 'town meeting' with vendor and users making up the panel answering questions from users. It should be a great opportunity to get your problems resolved! We informed the users present about DECUSERVE and encouraged them to sign up so that we may form a conference of our own and thereby have an ongoing dialogue with our peers. This is an excellent bulletin board application and we could certainly help each other a lot. In the next newsletter, I hope to give you more info about DECUSERVE and the papers that will be offered at Anaheim. INGRES Working Group Report for Atlanta Symposium Larry Hicks, INGRES Working Group Chair, Cary, NC The formation meeting of the INGRES Working Group was held at the Atlanta Symposium as a Birds-of-a-Feather session. The initial meeting drew twenty-three attendees. We discussed my role in setting up the formation meeting and my willingness to serve as the initial chair. (I have nine years of active DECUS involvement and can help the Working Group get established quickly.) I voiced my major concern about chairing the group -- I am a Marketing Director for one of Relational Technology's preferred consulting partners and VAR. The group elected me as the chair. Relational Technology, henceforth called RTI, named Dave Kellogg as the Working Group Counterpart and Cynthia Pinkston as his alternate. A call was made for volunteers for a Working Group steering committee. The steering committee would help formulate plans and run the Working Group. Several people expressed an interest in helping, but most felt they would need to talk to their management. The Working Group established the following goals: # Encourage INGRES sessions at future symposia. # Establish an interface with the INGRES Users' Association. I am currently the chair of the IUA's DECUS Working Group; that link has been established. # Develop a Wish List and communicate it to RTI. # Coordinate the submission of IUA INGRES public domain programs and tools into the DECUS library. # Develop a flow of information into the newsletters and onto the DECUServe system. We determined to review these goals in Anaheim and update or revise them as necessary. For Anaheim, there are at least four INGRES sessions submitted. These include: a Working Group meeting; a RTI performance session (submitted under Data Management SIG); a Users' Panel (like the one in Atlanta); and a Wish List session. We intend to hold additional sessions as Birds-of-a-Feather sessions in the campground, or wherever is necessary, and for any hot topics that can not be accommodated in the sessions above. We are trying to attract some of the IUA sessions to next year's symposia. It will take until Anaheim to coordinate most of that activity. We started a Wish List at Atlanta. Unfortunately, I was unable to get into the campground on Friday afternoon until after the campgrounds were locked up. At the moment, I have not been able to locate what happened to the list (the volunteer and interest sign up sheets were there also). I WOULD APPRECIATE IT, IF ANYONE WHO EITHER ENTERED AN ITEM OR READ THE LIST WOULD SEND ME ALL THE ITEMS THAT THEY REMEMBER FROM THE LIST. (My address is listed below.) Our plan with the Wish List is to have the Working Group members submit items and vote on the priorities at least once a year and possibly twice a year. At each symposium, we would present the current items and their rankings. Voting would probably occur away from symposia to allow the maximum participation by Working Group members, probably by mail ballet. We have a volunteer to coordinate the program collection and submission. He is Sim Wright. At the IUA, there was some discussion of having the informal INGRES public domain software placed in a real software library. I think we can make the DECUS Library be this place. Sim and I will be investigating this more between now and the Anaheim Symposium. I have developed an initial list of volunteer needs for the INGRES Working Group, so that we can meet our established goals and ensure that activity continues when any of the steering committee are overwhelmed at work. INGRES Working Group Steering Committee Chair Larry Hicks Vice Chair open Tape/Program Librarian Sim Wright Session Coordinator open Wish List Coordinator open Campground/BOF Coordinator open Newsletter/DECUServe Coordinator open Counterpart (from RTI) Dave Kellogg Alternate Counterpart Cynthia Pinkston IUA interface Larry Hicks Alternate IUA interface open Other Volunteer Needs: INGRES User Panel members for Anaheim and New Orleans Session speakers for New Orleans and Las Vegas Newsletter article writers With the exception of panel members and speakers, the only other volunteers who would need to attend DECUS regularly (at least once a year) are the Vice Chair, Campground/BOF coordinator, and Alternate IUA interface. If you are interested in volunteering, please call me at (919) 460-9896 between 9 and 5 Eastern time, or FAX me at (919) 460-8607, or write me at Turn-Key Solutions, Inc. 875 Walnut Street, Suite 275-17 Cary, NC 27511 I will discuss the effort and time commitments of each of the positions or try to help you get your session or article prepared and submitted. If you have suggestions for sessions, additional activities or other Working Group issues, I welcome them. A follow up report from the Working Group should be prepared in September. Until then, may your databases be uncorrupted. Analysis of PIR Ballots T. Chris Wool, PIR Coordinator, du Pont, Newark, DE Product improvement requests (PIRs) are the process by which users give feed-back to Digital regarding improvements in products. At the 1988 Fall Symposium in Anaheim and by mail, users submitted requests for improvement. In the April 1989 issue of the Newsletter (Volume 4, Number 8), all PIRs and a ballot were published. The statistical analysis of all ballots for all 20 product improvement requests for VAX-DATATRIEVE follows. The PIRs are order by decreasing total points. Also listed are the percent of ballots with positive points, the percent of ballots with negative points, the average points, and the standard deviation of points. See the article in the April 1989 newsletter for a description of how points could be balloted for or against a particular PIR. Pct of Pct of PIR Total Ballots Ballots Avg Pts Std Dev No. PIR Description Pts Pos Pts Neg Pts Given of Pts 7 Allow wildcards in dictionary 258 75.6 0.0 7.6 2.4 referencing commands 5 Implement compiled procedures 228 62.2 2.2 7.9 3.7 10 Provide a center function 196 73.3 0.0 5.9 2.8 in the Report Writer 6 Add a case insensitive EQUAL 177 57.8 0.0 6.8 2.8 boolean operator 2 Add an ELSE clause to the FROM 132 44.4 2.2 6.3 3.8 value expression 3 Implement a more generalized 123 40.0 0.0 6.8 2.6 scheme for establishing the textual SET variables in the Report Writer 4 Implement a screen management 111 31.1 2.2 7.4 4.4 system internal to DATATRIEVE which uses calls to VAXFORMS and replaces FMS and TDMS 20 Enhance time handling 110 37.8 0.0 6.5 2.5 capabilities for date fields 15 Add a screen painter to help 104 33.3 2.2 6.5 3.8 users set up Report Writer layouts PIR Analysis (con't)... Pct of Pct of PIR Total Ballots Ballots Avg Pts Std Dev No. PIR Description Pts Pos Pts Neg Pts Given of Pts 14 Make graphics device 103 40.0 0.0 5.7 3.3 independent and #Board Room" quality 1 Add memory resident tables 102 37.8 2.2 5.7 3.7 8 Warn the user if a non-indexed 89 40.0 2.2 4.7 4.6 CROSS is being performed 19 Support segmented keys 81 24.4 2.2 6.8 4.3 in RMS files 16 Separate Report Writer PRINT 62 24.4 2.2 5.2 4.2 elements with a single space 18 Allow field level 62 33.3 2.2 3.9 2.7 access protection 17 Align SUM columns properly 56 31.1 0.0 4.0 2.3 12 Support the CDDL 47 17.8 0.0 5.9 2.7 variant structure 13 Allow variables in PLOT TITLE 44 17.8 0.0 5.5 2.9 9 Support the full DATATRIEVE 36 17.8 2.2 4.0 3.2 syntax in Guide Mode 11 Add SET [NO] LEGEND to plots 10 6.7 0.0 3.3 1.5 Ballots were statistically analyzed for preference by CPU type (VAX, PDP-11, DECsystems) and by application type (Business EDP/MIS, Software Development, Education, Engineering/Scientific, Office Automation, Service Bureau). The complete analysis has been presented to the Digital development groups. However, the small number in each subcategory and the relative uniformity of ordering does not warrant the publication of the complete analysis by category of user. Only a comparison of how each of the largest subgroups ranked the VAX-DATATRIEVE PIRs follows: All VAX VAX EDP Dev OA Eng PDP Edu Users Users DTR Type Type Type Type Users Type Users Responses 45 44 43 28 19 18 12 8 7 Ranking 1 7 7 7 5 5 5 7 6 7 2 5 5 5 7 6 7 5 5 3 3 10 10 10 6 7 10 6 7 19 4 6 6 6 10 10 6 14 10 6 5 2 2 2 3 15 4 10 14 10 6 3 3 3 2 4 15 3 20 4 7 4 4 4 4 2 20 1 1 5 8 20 20 20 15 20 14 20 3 17 9 15 15 15 14 3 2 9 17 8 10 14 14 14 1 1 8 2 2 16 11 1 1 1 19 14 1 18 4 14 VAX-DATATRIEVE PIRs (con't)... All VAX VAX EDP Dev OA Eng PDP Edu Users Users DTR Type Type Type Type Users Type Users Responses 45 44 43 28 19 18 12 8 7 Ranking 12 8 19 19 20 17 3 4 9 20 13 19 8 8 8 8 19 12 19 12 14 16 16 16 17 18 18 15 16 15 15 18 17 17 13 16 17 13 18 18 16 17 18 18 9 19 13 17 8 9 17 12 13 13 12 13 16 11 12 13 18 13 12 12 18 12 12 8 15 11 19 9 9 9 16 11 9 16 11 2 20 11 11 11 11 9 11 19 13 1 All Users - All Users VAX Users - VAX Users VAX DTR Users - VAX-DATATRIEVE Users EDP Type - Business EDP/IMS Application Type Dev Type - Software Development Application Type OA Type - Office Automation Application Type Eng Type - Scientific/Engineering Application Type PDP Users - PDP-11 Users Edu Type - Education Application Type Digital's Response to DTR/4GL SIG Product Improvement Requests John L. Henning, Digital Counterpart, Nashua, NH Digital values the feedback we receive from customers through the Product Improvement Request system. We use the feedback to help us plan future versions, and we encourage customers to submit and vote on the PIRs. Specific responses follow from VAX DATATRIEVE, DATATRIEVE-11, and VAX TEAMDATA. Responses from VAX DATATRIEVEFor the short term, most of our attention is focused on completing the next major release of VAX DATATRIEVE, which will contain support for DECwindows and CDD/Plus (as has been discussed at previous symposia). But, please keep those requests coming in. They are important to us, and will remain in our project planning files. Attached are VAX DATATRIEVE Development Team's responses to the top 10 overall PIR vote getters, in order by number of votes. S89-7 Allow wildcards in dictionary-referencing commands. This is a very viable request, and one which would supplement the functionality of VAX DATATRIEVE. Since the item was so popular with the PIR process, we will put it near the top of our list for inclusion in a future release. Note: wildcarding features in VAX DATATRIEVE would likely be built upon the underlying capabilities of CDD/Plus dictionaries, where they are available. S89-5 Implement compiled procedures. This request has been mentioned before, and Digital has responded that it would be very difficult to implement. The current VAX DATATRIEVE architecture will not support this concept, and we feel that a change to allow compilation would significantly reduce the functionality and flexibility of the product. S89-10 Provide a centering function in the Report Writer. The idea is one which can benefit almost all users. The inclusion of a function such as report centering is one we are very interested in. S89-6 Add a case-insensitive EQUAL boolean operator. Similar to the CONTAINING operator, this new EQUAL operator would be very valuable to the DTR user. We are very interested in its possible implementation, but are concerned with its behavior with internationalization issues such as data comparison consistency. We will carefully look at this request in the near future. S89-2 Add an ELSE clause to the FROM value expression. Again, a very valuable addition to the existing VAX DATATRIEVE product, and one which could be syntactically compatible with existing DTR expressions. We will actively look at this feature for a future release. S89-3 Implement a more generalized scheme for establishing the textual SET variables in the REPORT WRITER. Because of the current VAX DATATRIEVE architecture, particularly around the report writer, but also including other PRINT commands, this is difficult to implement. We will examine this area when making any future report writer changes, but at this time it is unlikely to occur. S89-4 Implement a screen management system internal to DTR which uses calls to DECforms and replaces TDMS and FMS. We are very interested in the support of the DECforms product. It is a high priority for the future of VAX DATATRIEVE. Note, however, that any new interface must live in conjunction to the existing FMS and TDMS interfaces, since these two existing products are still supported and have large customer bases, including DTR users. Our DECforms implementation would attempt to provide a separate interface. S89-20 Enhance time handling capabilities for USAGE DATE fields. This is a highly-requested feature for VAX DATATRIEVE, particularly the ability to manipulate time within items like the PLOT statement. We will actively look at this request for future enhancements to the DTR architecture, particularly around the PLOT area. S89-15 Add a screen painter to help users set up Report Writer layouts. Thank you for your suggestion. We do not have any immediate plans in this area at this time. S89-14 Make graphics device-independent and #Board Room" quality. With the popularity of workstations, the area of Graphics has once again come to the forefront with VAX DATATRIEVE users. We are very interested in taking advantage of new graphical areas, particularly in the workstation area. DATATRIEVE would likely take advantage of quality graphics capabilities already available in other products, through appropriate open interfaces. Responses from DATATRIEVE-11The DATATRIEVE-11 Development Group responded to the top 4 vote-getters from the users who have PDP-11s. The responses are below in order of number of votes. S89-6 Add a case insensitive EQUAL boolean operator. Provided that VAX DATATRIEVE implemented something along these lines, DTR-11 could do likewise for compatibility's sake. The implementation would be straightforward and could be accomplished without impacting pool too greatly, however it should be noted that this capability is there now with the creative use of some existing features. S89-5 Implement compiled procedures. DTR-11 is unable to do anything in this particular area. Due to the nature of the product's implementation this feature would not be feasible. S89-7 Allow wildcards in dictionary referencing commands. DTR-11 is unlikely to implement this request. It is non-trivial and there is additionally an issue with the style of wildcarding being inconsistent within the PDP-11 product set. S89-10 Provide a center function in the Report Writer. We could certainly consider something such as this if VAX DATATRIEVE were to do something similar. Again, it would be relatively straightforward and without much impact on pool. Responses from VAX TEAMDATAVAX TEAMDATA Development Team responded to both of the PIRs which were submitted for the product. S89-21 Allow TEAMDATA access to RMS files via any CDD record. We find this an extremely interesting suggestion. We will strongly consider implementing this enhancement in a future release. S89-22 Allow user define procedures to be used globally. This enhancement would be very tricky to implement. However, we will consider implementing this request in a future release. Some More String Functions for VAX-DATATRIEVE Bart Z. Lederman, System Resources Corporation, Cambridge, MA In preparing the latest version of the DATATRIEVE/Fourth Generation Languages SIG Library Tape which will be distributed as part of the Spring 1989 tape collections, I decided to put together all of the functions which are available so far into one file. I #folded in" a number of functions which had been submitted previously by Don Stern, and decided to add a few more of my own. I have added five of the Run Time Library String functions. FN$STR_ELEMENTThe STR$ELEMENT function extracts parts of a character string which are separated by a fixed delimiter character. Consider the following examples: DTR> declare tstring pic x(20). DTR> tstring = #aa,bb,cc,dd,ee,ff,gg" DTR> print fn$str_element(0, #,", tstring) String aa DTR> print fn$str_element(1, #,", tstring) String bb DTR> print fn$str_element(5, #,", tstring) String ff DTR> print fn$str_element(8, #,", tstring) String %STR-W-NOELEM, no element found The first two lines simply fill a sample string with a number of characters, all of which are separated by a single fixed character (in this case, a comma #,"). The STR_ELEMENT function pulls out one of the #pieces" which is separated by the supplied string delimiter. The first element is number 0, the next is number 1, etc. Note what happens if you specify an element which is past the end of the input string. Since DTR V4.2 requires the status to be passed back from a function, when there is an error it is passed back to DTR, and then back to you. FN$POS_EXTRACTDATATRIEVE has an FN$STR_EXTRACT function, which calls STR$LEN_EXTR. This allows you to extract a substring specifying the starting position and length. STR$POS_EXTRACT works the same way, except you specify a starting position and an ending position rather than a length. The following examples are applied to the same sample TSTRING defined before. DTR> print fn$str_pos_extract(tstring,6,8) POS EXTRACT ,cc DTR> print fn$str_pos_extract(tstring,6,10) POS EXTRACT ,cc,d DTR> print fn$str_pos_extract(tstring,3,10) POS EXTRACT ,bb,cc,d FN$STR_CASE_BLIND_COMPAREDATATRIEVE does a number of string comparisons. When you have data where the case of the characters might vary but you want to match regardless of case, you have to do a number of manipulations. You can convert both strings to upper case with FN$UPCASE, or you can use the CONTAINING comparison, but these don't always meet the needs of every application. Building in the Run Time Library function lets you perform case blind comparisons, and check for strings which are longer or shorter than others at the same time. DTR> print fn$str_case_blind_compare(#abc","ABC") String Comparison 0 DTR> print fn$str_case_blind_compare(#abc","AbC") String Comparison 0 DTR> print fn$str_case_blind_compare(#abc","ABCd") String Comparison -1 DTR> print fn$str_case_blind_compare(#abcD","ABC") String Comparison 1 DTR> print fn$str_case_blind_compare(#","ABC") String Comparison -1 FN$STR_FIND_FIRST_IN_SETThe function STR$FIND_FIRST_IN_SET is an interesting one. You give it a set of characters to match, and it will search a string to find the first instance where any of the given characters occur. DTR> print fn$str_find_first_in_set(#abcdefg","bcd") FIND FIRST IN SET 2 DTR> print fn$str_find_first_in_set(#abcdefg","abcd") FIND FIRST IN SET 1 DTR> print fn$str_find_first_in_set(#abcdefg","cd") FIND FIRST IN SET 3 Another example of how this can be used is to parse #words" out of a line. I will define a sample string and a string containing word #separators", and then parse them out. In this example I'm entering the position to subtract by hand so it will print out and you can see what's happening; in a procedure you would put the position into a variable. DTR> declare tstring pic x(80). DTR> tstring = #The quick,brown-fox;jumped+over" DTR> declare separate pic x(5). DTR> separate = " ,-;+" DTR> print fn$str_find_first_in_set(tstring,separate) FIND FIRST IN SET 4 DTR> tstring=fn$str_pos_extract(tstring,5,80) DTR> print tstring TSTRING quick,brown-fox;jumped+over DTR> print fn$str_find_first_in_set(tstring,separate) FIND FIRST IN SET 6 DTR> tstring=fn$str_pos_extract(tstring,7,80) DTR> print tstring TSTRING brown-fox;jumped+over DTR> print fn$str_find_first_in_set(tstring,separate) FIND FIRST IN SET 6 DTR> tstring=fn$str_pos_extract(tstring,7,80) DTR> print tstring TSTRING fox;jumped+over and so on until you have parsed out what you want. FN$STR_FIND_FIRST_NOT_SETThere is a corresponding Run Time Library routine STR$FIND_FIRST_NOT_IN_SET, which works the same as the above function except that it finds the first character which is not in the specified subset. Note that the name had to be truncated to keep it from going over a 31 character symbol length limitation in the VAX programming language. DTR> print fn$str_find_first_not_set(#abcdefg","cd") FIND FIRST NOT SET 1 DTR> print fn$str_find_first_not_set(#abcdefg","acd") FIND FIRST NOT SET 2 DTR> print fn$str_find_first_not_set(#abcdefg","abd") FIND FIRST NOT SET 3 The following are the definitions inserted into DTRFND.MAR to add the above functions. ; FN$STR_CASE_BLIND_COMPARE - Compare Strings Without Regard to Case ; B. Z. Lederman ; ; Output is a value in R0: -1 if first string is less than second ; 0 if strings are equal (with blank fill) ; +1 if first string is greater than second ; ; Input is two strings to compare $DTR$FUN_DEF FN$STR_CASE_BLIND_COMPARE, STR$CASE_BLIND_COMPARE, 2 $DTR$FUN_OUT_ARG TYPE = FUN$K_VALUE, DTYPE = DSC$K_DTYPE_L $DTR$FUN_HEADER HDR = <"String"/"Comparison"> $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 1 $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 2 $DTR$FUN_END_DEF ; FN$STR_ELEMENT - Extract Delimited Element Substring. B. Z. Lederman ; ; output is a the selected substring. ; input is the element number (starting with zero for the 1st element) ; the delimiter string which separates elements ; and the source string $DTR$FUN_DEF FN$STR_ELEMENT, STR$ELEMENT, 4 $DTR$FUN_OUT_ARG TYPE = FUN$K_STATUS $DTR$FUN_HEADER HDR = <"String"> $DTR$FUN_IN_ARG TYPE = FUN$K_TEXT , OUT_PUT = TRUE $DTR$FUN_IN_ARG TYPE = FUN$K_REF, DTYPE = DSC$K_DTYPE_L, ORDER = 1 $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 2 $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 3 $DTR$FUN_END_DEF ; FN$STR_FIND_FIRST_IN_SET - Find First Character in Set of Characters ; B. Z. Lederman ; ; output is the position of the substring (a number) ; input is a source string descriptor, ; and a set of characters, any one of which may be matched. $DTR$IFUN_DEF FN$STR_FIND_FIRST_IN_SET, STR$FIND_FIRST_IN_SET, 2 $DTR$FUN_HEADER HDR = <"In"/"Set"> $DTR$FUN_OUT_ARG TYPE = FUN$K_VALUE, DTYPE = DSC$K_DTYPE_L $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 1 $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 2 $DTR$FUN_END_DEF ; FN$STR_FIND_FIRST_NOT_SET - Find First Character That Does Not ; Occur in Set. ; B. Z. Lederman ; ; output is the position of the substring (a number) ; input is a source string descriptor, ; and a set of characters, none of which may be matched. $DTR$IFUN_DEF FN$STR_FIND_FIRST_NOT_SET, STR$FIND_FIRST_NOT_IN_SET, 2 $DTR$FUN_HEADER HDR = <"Not"/"In"/"Set"> $DTR$FUN_OUT_ARG TYPE = FUN$K_VALUE, DTYPE = DSC$K_DTYPE_L $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 1 $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 2 $DTR$FUN_END_DEF ; FN$STR_POS_EXTRACT - String extract B. Z. Lederman ; ; output is a string ; input is an output string descriptor, ; an input string descriptor ; a starting position in the string ; the ending position in the string $DTR$FUN_DEF FN$STR_POS_EXTRACT, STR$POS_EXTR, 4 $DTR$FUN_OUT_ARG TYPE = FUN$K_STATUS $DTR$FUN_HEADER HDR = <"String"> $DTR$FUN_IN_ARG TYPE = FUN$K_TEXT, OUT_PUT = TRUE $DTR$FUN_IN_ARG TYPE = FUN$K_DESC, DTYPE = DSC$K_DTYPE_T, ORDER = 1 $DTR$FUN_IN_ARG TYPE = FUN$K_REF, DTYPE = DSC$K_DTYPE_L, ORDER = 2 $DTR$FUN_IN_ARG TYPE = FUN$K_REF, DTYPE = DSC$K_DTYPE_L, ORDER = 3 $DTR$FUN_END_DEF These five new functions are connected to DATATRIEVE by compiling and re-linking from a privileged account with: $SET DEFAULT DTR$LIBRARY $MACRO DTRFND $@DTRBLD Due to the large amount of material in this issuePart 2 of the Spring 1989 Wombat Magicis postponed to the September issue.