Coping with Office Automation Products (such as All-In-1) using Datatrieve Part 2: All-In-1 User Environment B. Z. Lederman ITT World Communications New York, NY 10004-2464 This article is the second in a series showing some of the uses for Datatrieve in managing and/or coping with such products as All-In-1. This particular article shows how to manipulate the user environment files, which are used by All-In-1 to determine who is allowed to use it, where they are, and what sort of options are available to that user. For the remainder of this article, AI1 is an abbreviation for All-In-1, WPS for any version of WPS or WPS-Plus, and DTR for Datatrieve. The previous article of this series showed how to access the document database, something managers and users would do. This article shows how to access files such as OA$DATA:PROFILE.DAT, the master profile file for All-In-1, something that most managers are going to want to reserve to themselves only. REDEFINE RECORD AI1_PROFILE_REC USING 01 AI1_PROFILE_REC. 10 USER PIC X(30). 10 USER_INFO. 20 VMSNAM PIC X(12). 20 FULNAM PIC X(32). 20 TITLE PIC X(30). 20 DEPART PIC X(24). 20 STATUS PIC X(68) EDIT_STRING T(24). 20 PASWRD PIC X(31). 20 PHONE PIC X(20). 10 RESERVED PIC X(15). 10 PRIV. 20 DCL PIC X. 20 SUP PIC X. 20 ERR PIC X. 20 CMD PIC X. 20 SRC PIC X. 20 CPHD PIC X. 20 LOG PIC X. 20 MULTI_NODE PIC X. 20 RSVD_FOR_TCS PIC X. 10 ADDRESS. 20 ADDR1 PIC X(30). 20 ADDR2 PIC X(30). 20 ADDR3 PIC X(30). 20 ADDR4 PIC X(30). 20 ZIPCOD PIC X(15). 10 NOTIFY. 20 NOTICE PIC X. 20 BATCH_NOT PIC X. 20 PRINT_NOT PIC X. 20 MAIL_READ_REC PIC X. 20 TICKLER PIC X. 20 ACTITEM PIC X. 10 DIRECTORY PIC X(68) EDIT_STRING T(32). 10 FORMLIB PIC X(68) EDIT_STRING T(24). 10 INIT_FORM PIC X(30). 10 EDITOR PIC X(10). 10 PRINTER PIC X(15). 10 NODE PIC X(13). 10 PRINT_PORT PIC X. 10 TERM_MODE PIC X. 10 MAIL. 20 MAIL_FORWARD PIC X(66) EDIT_STRING T(24). 20 MAIL_REPLY PIC X(31). 20 MAIL_MENU PIC X(10). 20 MAIDES PIC X(10). 10 CALENDAR. 20 CALTIMEING PIC X(5). 20 SETUSR PIC X. 20 YESDAYS PIC X. 20 STARTD PIC X. 20 ENDD PIC X. 20 STARTH PIC X(7). 20 ENDH PIC X(7). 20 MEALS PIC X(7). 20 MEALE PIC X(7). 20 CALDAY PIC X. 10 UFLAG. 20 UFLAG1 PIC X. 20 UFLAG2 PIC X. 20 UFLAG3 PIC X. 20 UFLAG4 PIC X. 20 UFLAG5 PIC X. 20 UFLAG6 PIC X. 20 UFLAG7 PIC X. 20 UFLAG8 PIC X. 20 UFLAG9 PIC X. 20 UFLAG10 PIC X. 20 CLASS PIC X(10). 10 LANGUAGE PIC X(20). 10 END PIC X(138) EDIT_STRING T(24). ; If you compare this definition with the screens AI1 gives you for user profile addition, modification, etc., you will find the fields match (more or less). Since AI1 gives you access to these fields, why would you use Datatrieve? The answer is that AI1 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 say '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 DTR than in AI1 as presently supplied. You can also use DTR to produce nice formatted reports of all users or groups of users, and you can select which information fields are printed in that report. Because AI1 manipulates several files for user profiles, it is NOT a good idea to add or delete user profiles using DTR, though it could be done in emergencies. 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 the record definition. DELETE AI1_NETWORK_REC; REDEFINE RECORD AI1_NETWORK_REC USING ! ! Read the ALL-IN-1 network data file. ! ! B. Z. Lederman ! 01 AI1_NETWORK_REC. 10 USER_NAME PIC X(30). 10 NODE PIC X(6). 10 DATE1. 20 FILLER PIC X(16). 20 LAST_UPDATE COMPUTED BY CHOICE OF (IY1 EQ " ") THEN FN$DATE("18-NOV-1858") ELSE FN$DATE(ID1 | "-" | IM1 VIA MONTH_TABLE | "-" | IY1 | " " | IH1 | ":" | II1 | ":" | IS1 | "." | IF1) END_CHOICE. 20 UPDATE_TIME COMPUTED BY FN$TIME(DATE1.LAST_UPDATE) EDIT_STRING X(11). 10 DI1 REDEFINES DATE1. 20 IY1 PIC XXXX. 20 IM1 PIC XX. 20 ID1 PIC XX. 20 IH1 PIC XX. 20 II1 PIC XX. 20 IS1 PIC XX. 20 IF1 PIC XX. 10 FULL_NAME PIC X(32). 10 TITLE PIC X(30). 10 DEPARTMENT PIC X(24). 10 TELEPHONE PIC X(20). 10 ADDRESS. 20 ADDR1 PIC X(30). 20 ADDR2 PIC X(30). 20 ADDR3 PIC X(30). 20 ADDR4 PIC X(30). 20 ZIPCOD PIC X(10). 10 NETWORK_ADDRESS PIC X(63) EDIT_STRING T(32). 10 TIMESTAMP PIC X(22). 10 M_NODE PIC X. 10 DELETED PIC X. ; 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? In this instance, Datatrieve is a useful tool for cleaning up when AI1 doesn't do a complete job of managing it's own data, and there will be more examples of this later in this series of articles. 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.