.PAGE SIZE 60, 80 .RIGHT MARGIN 80 .LAYOUT 1, 2 .NO FLAGS ACCEPT .NO FLAGS OVERSTRIKE .FLAGS BOLD .TITLE OA001: Management Tools for ALL-IN-1 .SUBTITLE B.#Z.#Lederman WU#World Communications, New York .CENTER ^*OA001: ^&Management Tools for ALL-IN-1\&\* .BLANK 2.CENTER Monday May 16, 1988 .BLANK.CENTER 1:00 p.m. - 2:00 p.m. West 241 .BLANK 2.CENTER ^*B.#Z.#Lederman\* .BLANK.CENTER WU World Communications .CENTER New York, NY 10004-2464 .BLANK .NOTE ^*Abstract\* This session is intended to illustrate some of the tools which may be used for managing and/or coping with ALL-IN-1, including the use of the procedures supplied with ALL-IN-1 environment, the use of some VMS utilities, and the use of DATATRIEVE. .BLANK PLEASE NOTE: to conserve paper, listings of most of the record definitions and procedures are not included here. All of the DATATRIEVE definitions used in this session, and many others, may be obtained through the DECUS Library on the DTR/4GL SIG Library Tape collection (V-SP-59), or the VMS or OA#SIG Tape Collections. .END NOTE .BLANK 2.CENTER ^*Why manage ALL-IN-1?\* .PARAGRAPH Most of the time, ALL-IN-1 runs fairly well by itself. But like most large complex software systems, it is not totally self-reliant. .LIST 2, "·" .LE; As ALL-IN-1 is used (and more specifically, as documents are added and deleted, meetings are scheduled and canceled, mail is sent, or users are added or removed) various files used by ALL-IN-1 to store it's operational data are modified. For good performance, these files should be compressed or reorganized occasionally. .LE; ALL-IN-1 can be modified by changing or adding forms and/or scripts: for good performance this too requires data file reorganization. .LE; When there are a lot of users of ALL-IN-1, keeping track of them manually or by memory is not feasible (and can cause serious problems if there is only one "manager" and that person is out sick the day a problem arises). .LE; There are also the inevitable disk and file problems which may occur occasionally and which must be repaired. .LE; Users may have to be moved from one system to another, or from one disk to another, and their data files must also be moved and/or merged into existing directories. .LE; There are also, unfortunately, situations where ALL-IN-1 does not keep it's own data files in order, and these should sometimes be corrected. .LE; There are times when it is desirable to determine what ALL-IN-1 is being used for (is Time Management being used? Are different electronic mail menus being used?). .END LIST.BLANK All of this is made easier by using the proper tools. .BLANK 2.CENTER ^*Periodic maintenance using ALL-IN-1 tools.\* .PARAGRAPH ALL-IN-1 come supplied with procedures which can be run for "normal" system maintenance, and to fix "ordinary" file problems. Adding and deleting documents requires the various file cabinets (DOCDB.DAT files) be reorganized periodically if the best performance is to be obtained, which is what these procedures do. .BLANK This should be performed on a regular basis: more often for active systems (many documents and mail messages created or modified), less often for less active systems. The profile should be reorganized if many users have been added / modified / deleted. The Janitor deletes files out of the WASTEBASKET folder if users are not doing this themselves. .BLANK This session will not go into this in much depth as it is covered in the ALL-IN-1 ^&System Manager's Guide\&, particularly section 5. .BLANK .NO JUSTIFY.NO FILL.TEST PAGE 18 ALL-IN-1 System Manager System Manager Mon 14-Mar-1988 System Manager Functions .BLANK .BLANK SEL Select Master: PROFILE .BLANK C Create E Edit D Delete P Print R Read I Index TR Transfer Users SD Shut-down the running ALL-IN-1 system SCH Schedule Janitor ^*{This entry,}\* FM File Maintenance ^*{and this entry.}\* IVP Installation Verification Procedures (more...) .BLANK .BLANK.TEST PAGE 18 ALL-IN-1 System Manager System Manager Mon 14-Mar-1988 System Manager Functions .BLANK .BLANK SEL Select Master: PROFILE .BLANK C Create E Edit .BLANK .BLANK File Maintenance Options .BLANK FV File Cabinet Verification ^*{this entry through...\* FVR File Cabinet Verification and Repair FC File Cabinet Reorganization ^*this entry,}\* FL Form Library Reorganization PR User Profile Reorganization ^*{and this entry.}\* AF Analyze an RMS File .BLANK.JUSTIFY.FILL .BLANK 2.CENTER ^*Consolidating users.\* .PARAGRAPH There is a non-obvious use for the File Cabinet Verification and Repair procedure. I had two systems with users on both of them (and entries in the PROFILE for all users on system "B" were also already on system "A"). When I had to move all users from system "B" to "A", I simply moved all of their documents (the "ZR¨¨¨¨¨¨¨.WPL" files in the [user.OA.DOC%] directories) from system "B" to system "A", and then ran the procedure. It detected that there were now files in users' directories which were not entered in the document databases, and proceeded to enter them. I must admit that I didn't fully expect this method to work; but it did, and it saved a lot of manual re-entering of documents into the file cabinet. .! ALSO MENTION TU MENU SELECTION .BLANK 2.CENTER ^*Performance improvements after modifying ALL-IN-1\* .PARAGRAPH If forms and/or scripts are modified (for example, replacing the "digital" logo on form MAIN with your own logo, or adding scrips for different printers), various libraries should be reorganized. .BLANK See section 6.10 of the ^&System Manager's Guide\&. .BLANK Also see section 5.6.3 for reordering the forms libraries (OAFORM and MEMRES): the FM menu shown previously has an item (FL) for doing this. .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 18 ALL-IN-1 System Manager System Manager Mon 14-Mar-1988 System Manager Functions .BLANK .BLANK SEL Select Master: PROFILE .BLANK C Create E Edit .BLANK .BLANK .BLANK Additional Manager Options .BLANK CS Communications Setup SDL System Distribution Lists MM Messaging Management ST Statistics NU Schedule Network Update NI Initialize Network Profile NP Schedule Network Purge CTX Compile Text Library (TXL) ^*{this}\* .BLANK There is also a procedure which can be invoked outside of ALL-IN-1: .BLANK.TEST PAGE 4 Directory SYS$SYSDEVICE:[ALLIN1.LIB] .BLANK REORDER.COM;2 4 17-APR-1986 18:34 .BLANK Note that you may have to define some logical names to point to the correct directory and/or files for this procedure to work. .JUSTIFY.FILL .BLANK 2.CENTER ^*Using DATATRIEVE to manage multiple data entries.\* .PARAGRAPH Although ALL-IN-1 comes with it's own utilities and commands for the examination and maintenance of it's data files, there are times when using DATATRIEVE allows faster, easier, or more versatile access or management of this information. For example, it is possible to access the user profile file. .PARAGRAPH ALL-IN-1 management is oriented to processing one user at a time. If you want to find out, for example, which users have DCL access enabled, you have to go through several menus and screens to get an index of users, write down their names, then examine them all one at a time to find the ones with DCL. With DATATRIEVE, you can ready the PROFILE domain and enter ^*'PRINT#PROFILE#WITH#DCL#=#"Y"'\* to find all such users. Similarly, operations on large numbers of users such as turning DCL access or logging on or off for everyone, or finding the users whose accounts point to certain disks and/or re-assigning them to other disks, are easier in DATATRIEVE than in ALL-IN-1 as presently supplied. You can also use DATATRIEVE to produce nice formatted reports of all users or groups of users, and you can select which information fields are printed in that report. .BLANK.NO JUSTIFY.NO FILL DTR> for profile print user, directory .BLANK.TEST PAGE 9 USER DIRECTORY .BLANK IVP SYS$SYSDEVICE:[ALLIN1.IVPUSER] JONES USER$DEVICE:[JONES.OA] LEDERMAN USER$DEVICE:[LEDERMAN.WPSPLUS] MANAGER SYS$SYSDEVICE:[ALLIN1.MGR] POSTMASTER SYS$SYSDEVICE:[ALLIN1.POSTMASTE] SMITH USER$DEVICE:[SMITH.WPSPLUS] .BLANK.JUSTIFY.FILL .PARAGRAPH Because ALL-IN-1 manipulates several files for user profiles, it is NOT a good idea to add or delete user profiles using DATATRIEVE, though it could be done in emergencies. .PARAGRAPH It would also be possible to use DATATRIEVE to report or reformat the information in this file. For example, produce a mailing list or address labels from the list of users in the PROFILE file (it could even be written as a WPS list processing list). .BLANK 2.CENTER ^*Multiple entry processing and emergency repair\* .CENTER ^*(the document database).\* .PARAGRAPH It is also possible to access the document database (DOCDB.DAT) file using DATATRIEVE. There is at least one important field in the document database is not usually obtainable within ALL-IN-1, and that is the VMS file which contains the document. Sometimes the DOCDB.DAT file becomes corrupted, and then it is necessary to try to coordinate the VMS files with the documents: using DATATRIEVE allows you to obtain a listing of all documents ALL-IN-1 (or WPS-Plus) knows about and compare it with a directory listing to find missing documents or files. If there are VMS files not recorded in the document database you could add an entry with DATATRIEVE, though I would recommend you first try the File Cabinet Verification and Repair procedure supplied with ALL-IN-1 or try using WPS (or EDT, as is appropriate) to create a document and then do a Gold-G (GET) to incorporate that file into a new document. Similarly: if the verification procedure doesn't delete an entry for which there is no file it can be fixed with DATATRIEVE. .BLANK 2.CENTER ^*Coordinating ALL-IN-1 with VMS.\* .PARAGRAPH Some users have reported that they implement expiration dates on their disks to flag old files for archiving. Since this will include the files corresponding to WPS documents, it is necessary to process the DOCDB.DAT file to find out which document goes with which file (this is item 287063 in the current OA#SIG SIR list.) DATATRIEVE is one way to obtain the necessary information. .BLANK 2.TEST PAGE 11.CENTER ^*Faster and more versatile reports.\* .BLANK.NO JUSTIFY.NO FILL .NO FLAGS BOLD.TEST PAGE 11 REDEFINE PROCEDURE DOCDB_REPORT ! ! Fast report of all documents with their VMS file name. B. Z. Lederman ! REPORT DOCDB ON *."file specification" SET COLUMNS_PAGE = 132 SET LINES_PAGE = 42 PRINT DOCNUM, FOLDER, TITLE USING T(48), FILENAME USING T(24) END_REPORT END_PROCEDURE .FLAGS BOLD .BLANK.TEST PAGE 13 16-Mar-1988 Page 1 .BLANK DOCNUM FOLDER TITLE FILENAME .BLANK 156 CREATED this is a test message []ZRUWBELSS.WPL 161 DXT symposium scheduling [.DOC1]ZRVLAQKWM.WPL 126 EXAMINER install_process [.DOC6]ZRQJAQVXO.WPL 103 LETTERS Atlanta [.DOC3]ZRJIARTPZ.WPL 160 OUTBOX Meeting notice OA$SHARE4:ZRVFARBWY.WPL 125 PICTURES Size Comm B [.DOC5]ZRPXBEPKV.WPL 90 WPS SPR Response to SPR 11-AT00023 [.DOC0]ZRHYBBOAO.WPL .BLANK Another example of a DATATRIEVE report format: .BLANK CREATED this is a test message 26-Jan-1988 14:52:00.37 DATABASE Normalization 1 12-Nov-1987 09:58:51.95 DICTIONARIES PERSONAL 26-Jun-1986 14:16:04.34 EXAMINER install_process 1-Oct-1987 08:13:22.53 OUTBOX Meeting notice 4-Feb-1988 08:19:51.25 PICTURES EIA null modem/Ethernet 15-Sep-1987 11:46:00.41 .BLANK.JUSTIFY.FILL These reports happens to be sorted by folder because the folder name forms part of the primary key, but with DATATRIEVE it is possible to easily change the report for the format and sort order you want: for example, all documents written on, before, or after a certain date; documents with particular authors or keywords or words in a title (ALL-IN-1 lets you search on individual fields, but DATATRIEVE lets you search on combinations of fields), documents on particular disks or in particular directories, etc. I have even put a DATATRIEVE procedure like this one into a form and included it as an ALL-IN-1 application so that users can simply type one command and have a complete index of their documents sent to their default printer. (Information such as this is similar to requests 288001, 288007, and 288015 in the OA#SIG SIR list. Also note that it is possible to select messages in the CREATED folder which are older than a given date, which is part of SIR 288015.) .BLANK 2.TEST PAGE 5.CENTER ^*Access to other user's accounts.\* .PARAGRAPH This method also allows you to see other user's document databases, such as the POSTMASTER's database (which may include system wide information such as mail messages) without logging into VMS POSTMASTER account, or you may not even have to have a VMS account for the POSTMASTER. This could be important, since the release notes for ALL-IN-1 V2.1 warn against logging into the POSTMASTER account as it can lock out the message router and cause mail messages not to be delivered. .! .BLANK 2.CENTER .! The network profile. .! .PARAGRAPH .! Another, somewhat less well known, file is OA$DATA:NETWORK.DAT, .! which contains information on all users who have network or .! multi-node access (and, I suspect, all users). If you use a VAX .! Cluster, then you essentially have a multi-node system, and there .! will be a NETWORK.DAT file with something in it. Most managers .! probably don't do anything with this file, but there is at least one .! time it should be looked at, which may be deduced from looking at .! some sample data. .! .BLANK.NO JUSTIFY.NO FILL .! USER_NAME : LEDERMAN .! NODE : SYS31 .! LAST_UPDATE : 9-Jan-1987 .! UPDATE_TIME : 15:10:15.81 .! FULL_NAM : Bart Z. Lederman .! TITLE : Project Engineer .! DEPARTMENT : Advanced Systems Dev .! TELEPHONE : 212-607-2657 .! ADDR1 : 2572 E. 22nd Street .! ADDR2 : Sheepshead Bay, NY .! ADDR3 : .! ADDR4 : .! ZIPCOD : 11235-2504 .! NETWORK_ADDRESS : LEDERMAN AT A1 AT SYS31 .! TIMESTAMP : .! M_NODE : Y .! DELETED : N .! .JUSTIFY.FILL .! .BLANK 2.CENTER .! Cleaning up after ALL-IN-1. .! .PARAGRAPH .! Most of the fields are self explanatory, and many match the fields you .! will find in the PROFILE, but notice the field "DELETED". I recently .! had to re-organize my system, and deleted a lot of old user profiles .! using the normal ALL-IN-1 menus and procedures. I found, however, that .! there were still a lot (all?) of the old users still in the .! NETWORK.DAT file. Most, but not all, were marked as deleted, but .! still: why take up space storing profiles on people who aren't here .! anymore? (There may be cases where you want to know that a user used .! to be on a system, but in my case when a user is off the system I want .! them to be completely off of the system.)# In this instance, .! DATATRIEVE is a useful tool for cleaning up when ALL-IN-1 doesn't do a .! complete job of managing it's own data, and there will be more .! examples of this later. .! .PARAGRAPH .! The NETWORK_ADDRESS field does not look like a regular node name: .! the reason is because it's really a Message Router Gateway type .! address, used when routing mail to other networks or mail agents. .BLANK 2.TEST PAGE 5.CENTER ^*Clean up after ALL-IN-1.\* .PARAGRAPH Using DATATRIEVE, I can access the calendar access data file to produce a nice overall report of all users. .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 21 User Access Read Schedule Granting Given Your for Access To Calendar You .BLANK ERSKINE STEVE Y Y ERSKINE ELLIOTT Y Y LEROY REGGIE Y Y LEROY HOWIE Y N LEROY RALPH Y N LEROY SOLON Y N LEROY JOSHI Y N LEROY STEVE Y Y RKELLY VICKIC Y N STEVE ERSKINE Y N VICKIC BEATE Y N VICKIC ERSKINE Y Y VICKIC IRENE Y N VICKIC STEVE Y N VICKIC ELLIOTT Y N VICKIC RKELLY Y N .JUSTIFY.FILL.BLANK What is not immediately obvious in this report is an important reason why a manager would want DATATRIEVE access to this file: none of the persons listed have access to this system. ALL-IN-1 does not clean up after itself properly, especially when deleting users. All of the persons you see listed above were deleted from ALL-IN-1 using the normal System Manager's functions, but ALL-IN-1 didn't delete their entries from the Calendar Access files, or the MEETING or ATTENDEE or other time management files. (A method of purging deleted users is item 387013 of the OA#SIG SIR list.) Using DATATRIEVE, it is easy to locate and delete all records which have the name of a person who is no longer an ALL-IN-1 user in either the GRANTUSER or ACCUSER fields and thus clean up the file. .PARAGRAPH Something to be aware of is that any user with write access to this file can add or modify records. This is handy if the system manager wants to add new users to have access to many existing users, or if the manager wants to obtain access to other users' calendars, but it's not so good if users give themselves more access then they should have to other users' calendars. The "System Manager's Guide" has a chapter with the recommended file protections which should be set to prevent unauthorized access to system information. .PARAGRAPH The lists of old meeting and attendees also does not get cleared out when a user is deleted from the system. I have also found when using Time Management that it is difficult to obtain an overall list of all meetings in the past or future, or to purge out old meetings. With DATATRIEVE, I have found it easy to remove all meetings for dates in the past, all attendees who no longer work for the company, etc. .BLANK 2.TEST PAGE 5.CENTER ^*Pending mail count.\* .PARAGRAPH Another data file is OA$DATA:PENDING.DAT, which contains the pending mail count. Although there is an (undocumented?) program supplied with ALL-IN-1 which can be run to give you your unread mail count without going into ALL-IN-1, it has some restrictions: and the manager can't use it to see other user's unread mail counts. (You should find MAILCOUNT.OBJ in your [ALLIN1.SOURCES] directory, or the directory corresponding to logical name OA$BUILD, or in the A1022.C save set, and you can LINK it to get the utility.)# DATATRIEVE can be used to fix both of those situations. .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 9 PENDING KEY C A B D Pending .BLANK FETCHER QUEUE 0 4 0 0 MAIL BROWN 0 4 0 34 MAIL DEMO 0 0 0 0 MAIL IVP 0 0 0 0 MAIL JONES 0 152 148 2 MAIL MANAGER 0 0 0 0 .BLANK.JUSTIFY.FILL It's easy to set up a procedure for individuals to use to get their own pending mail counts, or for the manager to see who isn't reading their mail. You can also delete users who are no longer on the system (ALL-IN-1 doesn't do this), but it won't necessarily remove the user's links to the mail message. Hopefully, either the "Purge Mail" option shown below (it's on the MM form), or one of the system verification and repair procedures referenced at the beginning of this paper, will do that. Note, however, that it won't give you a list of users with pending mail: DATATRIEVE will. .BLANK .NO JUSTIFY.NO FILL.TEST PAGE 16 ALL-IN-1 System Manager System Manager Sat 16-Apr-1988 Electronic Messaging System Management .BLANK HS Hold remote Sender HF Hold remote Fetcher AS Abort remote Sender AF Abort remote Fetcher SS Start remote Sender SF Start remote Fetcher RS Run remote Sender RF Run remote Fetcher DS Display status DQ Display sender Queue .BLANK SM Show Message of another user SL Switch Logs CM Cancel Message of another user SPQ Show Print Queues CMP Change Message router Password SBQ Show Batch Queues CTZ Change Time Zone and Time Offset PU Purge User's Incoming Mail from Pending file ^*{This entry}\* .JUSTIFY.FILL .BLANK 3.TEST PAGE 5.CENTER ^*ALL-IN-1 usage and tuning: the logging file.\* .PARAGRAPH ALL-IN-1 has the ability to generate a logging file (see section 9.3.2 of the ^&System Manager's Guide\&) but there are no good utilities or facilities supplied to do anything with the information generated. .PARAGRAPH The manual mentions that only users with the PRVLOG entry in their user profile will be logged (this is the LOG user privilege field, the second entry in the second row of flags, between CPHD and MNODE): you will probably want to turn on logging for all users, or for particular departments (and may want to turn off logging for the MANAGER and POSTMASTER accounts). I find DATATRIEVE handy when modifying groups of users. I also have logging turned on for everyone anyway, because that way I get all logging whenever I activate it as shown below: and when logging isn't active having PRVLOG set to "Y" has no affect. .PARAGRAPH The manual also mentions briefly that the commands should be submitted as a batch file if you don't want to tie up a terminal when logging is enabled. The following will work, and should be submitted under a privileged account (the ALL-IN-1 manager's account would be good): .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 5 $ ALLIN1/NOINIT OA$LOG_TO_FILE oa$lib:ai1.log ^*{use a file name you like here.}\* EXIT $EXIT .BLANK.JUSTIFY.FILL To stop logging you have to abort this batch job (or delete the entry from the batch queue). .PARAGRAPH DATATRIEVE is a good tool for reading and analyzing this information. A small portion of the raw data looks like this: (It won't fit in 80 columns, so I've removed some fields which happened to all be the same in this very short sample) .NO FLAGS SPACE .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 11 SYS ELAP TIME TIME INPUT FUNCTION TEXT .BLANK 13:18:50.97 0 Function: SET_MENU DEFAULT 13:18:51.20 13 Function: FORM MAIN 13:18:51.30 23 Function: OA$FORM_MENU 13:18:52.06 64 Function: FORM WP 13:18:52.38 88 Function: OA$FORM_MENU 13:18:52.39 89 Function: GET #CURDOC="$WPDOC" 13:18:52.41 90 Function: . .IF $WPDOC:6:30 NES "" THEN CAB CURRENT $WPDOC ELSE CAB CLEAR 13:18:52.43 91 Function: CAB CURRENT $WPDOC 13:18:53.41 125 %OA-W-CAB_ NOT_OPENED, Erro r in opening the file cabinet file "CAB$SDAF" 13:18:53.71 145 -RMS-F-CRM P, CRMPSC system service failed to map global buffers 13:18:56.58 180 {CTRL/Z} 13:18:59.01 263 ex{CR} 13:18:59.02 264 Function: OA$FLD_DONE 13:18:59.04 266 Function: EXIT 13:18:59.38 271 Ending ALL -IN-1 13:27:44.02 0 Function: SET_MENU DEFAULT 13:27:44.13 11 Function: FORM MAIN 13:27:44.24 21 Function: OA$FORM_MENU 13:27:45.04 65 Function: GET #CURDOC="$WPDOC" 13:27:45.06 67 Function: FORM FC1/MORE=WP 13:27:45.40 90 Function: OA$FORM_MENU /MORE=WP 13:27:45.41 91 Function: . .IF @#CURDOC:6:30 NES "" OR @#CURDOC:6:30 NE 0 THEN CAB CURRENT @#CURDOC ELSE CAB CLEAR 13:27:45.52 95 Function: CAB CURRENT @#CURDOC 13:28:35.18 155 i{CR} 13:28:35.19 156 Function: OA$FLD_DONE 13:28:35.21 158 Function: GET #INDEX="Document" 13:28:35.22 158 Function: FORM WPINDX/STYLE=CHOICE 13:28:35.47 175 Function: GET #INPROMPT='0' 13:28:35.48 176 Function: GET #goldA_exit = 3 .BLANK.JUSTIFY.FILL .FLAGS SPACE To make this information more useful, DATATRIEVE can be used to process the information to extract just FORM and DO script usage, and match it up to the library where the form or script is stored. The information, after processing, looks like this (again with the constant fields deleted here to save space): .BLANK.NO JUSTIFY.NO FILL MSG SYS ELAP ID TIME TIME FUNCTION NAME LIBRARY .BLANK 18842411 20:54:34.26 35 FORM MAIN MEMRES 18842411 20:54:45.65 90 FORM EMC OAFORM 18842411 20:55:06.23 242 FORM EMHEAD OAFORM 18842411 20:55:37.03 337 FORM AUTO MEMRES 18842411 20:55:39.28 361 FORM AUTO MEMRES 18842411 20:55:41.11 383 FORM AUTO MEMRES 18842411 20:55:41.31 400 FORM OA$EDIT MEMRES 18842411 20:56:59.28 717 FORM WP OAFORM 18842411 20:57:07.93 760 FORM WPINDX OAFORM 18842411 20:57:37.96 851 FORM EMC OAFORM 18842411 20:57:38.53 890 FORM OA$LIST MEMRES 18842411 20:58:03.61 1078 FORM WPINDX OAFORM 18842411 20:58:33.91 1164 FORM MAIN MEMRES .JUSTIFY.FILL .BLANK 2.TEST PAGE 5.CENTER ^*Why is this done in DATATRIEVE?\* .PARAGRAPH The reason for using DATATRIEVE is that if you used a "third generation" language such as COBOL or FORTRAN, you would have to write just as much processing code, plus a lot more code for the file and record processing work, to accomplish the same result as the DATATRIEVE procedure shown here; and it would take much longer to write and test it. Once the data has been processed, DATATRIEVE makes it easy to query the data to obtain information, and it will also produce graphs from the data. .PARAGRAPH In addition, ALL-IN-1 is used in "office" sites where "traditional" programming languages (such as FORTRAN, BASIC, COBOL, C, etc.) are not available; or, as mentioned previously, there may not be any "programmers" on the staff. 50% of ALL-IN-1 licenses ship with DATATRIEVE, so many sites have it. (This may not include sites which purchased the two products separately.) .BLANK 2.TEST PAGE 5.CENTER ^*What can be learned?\* .PARAGRAPH There is a considerable amount of information one can obtain from this data. For example: how many users access ALL-IN-1, when they use it, the sequence of commands entered, and what features are being used. I concentrated on what FORMS and DO scripts were being used, with the intention of optimizing performance by putting the most used scripts in the TXL, (and the most used forms in MEMRES, but see the caveat below), and moving the lesser used forms and scripts elsewhere. With DATATRIEVE, it's quite easy to get summary information. .BLANK.NO JUSTIFY.NO FILL.TEST PAGE 8 FUNCTION LIBRARY COUNT NAME .BLANK FORM MEMRES 3 AUTO FORM OAFORM 1 DISPREMINDER FORM OAFORM 4 EMC FORM OAFORM 1 EMHEAD FORM MEMRES 4 MAIN FORM MEMRES 1 OA$EDIT FORM MEMRES 2 OA$LIST FORM OAFORM 1 WP FORM OAFORM 2 WPINDX .JUSTIFY.FILL.BLANK .PARAGRAPH Although the above extract from a very short logging session doesn't happen to show any, DO script usage accounts for a significant portion of the work done by ALL-IN-1, and putting the most used scripts into the TXL can improve performance: moving unused scripts out conserves memory (and moving them out of the default directory saves directory look-up time). The above process can be used to identify the most and least used scripts. .PARAGRAPH As was previously mentioned, DATATRIEVE does graphics. Two examples from other (very short) logging files are appended: a pie chart showing how often each forms library and DO script account was accessed; and a bar chart showing the forms/scripts in order of usage. .PARAGRAPH This logging information is also the best (perhaps only) method of finding out what your users are actually doing in ALL-IN-1, where the most effort is being expended, and where efforts to improve performance or ease of use will yield the greatest results, and even how you might tune your system or adjust quotas to match the work being done. By noting the forms and scripts used, you can tell if people are doing most of their work with word processing, time management, electronic mail, etc. (It may be noted that item 387013 of the current OA#SIG SIR ballot requests a method for the System Manager to analyze user activity: it may have implied active monitoring such as the VMS#MONITOR or SPM commands, but this at least provides a method of analyzing usage.) .BLANK 2.CENTER ^*Some other reasons for using DATATRIEVE.\* .PARAGRAPH At a previous presentation of similar material, an employee of DEC raised some objections to the use of DATATRIEVE in manipulating ALL-IN-1's internal files. He stated that it could interfere with ALL-IN-1 or corrupt files, and that facilities existed to write ALL-IN-1 scripts to do what I was doing with DATATRIEVE. I do not accept this, for several reasons. .LIST 2, "·" .LE; All of ALL-IN-1's files are identified to VMS as normal RMS files. It should be possible to read (and write) these files using normal VMS RMS services without causing any problems. If ALL-IN-1 is bypassing RMS, it should be immediately corrected so it works properly within the normal operating system environment. .LE; I have noted in several places throughout this presentation that, whenever possible, the normal ALL-IN-1 procedures should be used to write data to these files. DATATRIEVE is being used primarily to read data: it is used to delete records only when ALL-IN-1 fails to do so itself. Modifying entries such as the DCL flag should not upset ALL-IN-1. .LE; My job is system management, ^&NOT\& writing ALL-IN-1 scripts. I find such scripts difficult to understand, difficult to write, difficult to work with and difficult to update. Furthermore, writing a script to remove a user from calendar access won't give me a formatted report of calendar access: a new script would be needed. With DATATRIEVE, once I have a record definition I can do whatever I want: it takes much less time to set up than even one ALL-IN-1 script, I don't have to re-write my procedures each time I need to do something new with the file, I can interactively view the results and change my commands, etc. As a system manager my time is valuable, and I need to use the most efficient tool to get the job done. .LE; Finally: I have avoided saying this explicitly in the past, but it should be obvious that there are many things ALL-IN-1 is failing to do. I should not have to go in and manually delete all of these left over records whenever a user is deleted (pending mail, calendar access, meetings, network profile, etc.): ALL-IN-1 should do it itself. .END LIST