AETL-IM (25-1a)
MEMORANDUM FOR CINCUSAREUR AND 7A, AEAIM-AR-AA (Maj Fleming),
APO NY 09175
SUBJECT: USAREUR Generic Capability Request (CAPR) for Battalion and Brigade Staffs
1. Reference. USAREUR Memorandum, AEAIM-AR-AA, SAB, dated 27 Jun 90.
2. Recommended changes to your proposed generic CAPR follow:
add to paragraph 7b.
(4) Records Management
Justification: The files created and stored on these computers are subject to Army Recordkeeping requirements under MARKS. This applies even more strongly if these computers are to be networked. See Enclosure 1 for recommended recordkeeping directory structures for standalone and networked systems.
(5) Audio/Visual
Justification: Since these computers have graphic monitors and the recommended software contains complex graphic creation and presentation capability, then the video aspects of the system must be recognized, and controlled. This applies especially when the multitude of graphic file formats, video boards, video drivers, monitor types, monitor frequency ranges and color capabilities, and presentation systems (LCD and Projector) are considered. If these are not standardized and controlled, then the likelihood of incompatibility or non-interoperability increases dramatically. The same applies to the layout and visualization standards for the information presented within theses graphic images. No guidance has been distributed on the standards for preparing a chart, image, or drawing. A recommended starting point for this is to use the Army Standard Statistical Representation guidance issued by the Comptroller of the Army. Consideration must be given to readability, color usage, chart-type appropriateness to the data, headings, graphic file naming, graphic labels and identifiers, etc.
change paragraph 7e to read:
(1) Compatabililiy and Interoperability. Must conform to the International Standards Organization (ISO) Open System Interconnection (OSI) architecture. All...version 3.3+ and Posix based on UNIX V/386 Release 3.2,.... The workstations must be capable of operating as a terminal through terminal emulation on various host based, timeshare multiuser computer systems to include as Xwindow terminal of Xwindow based Unix hosts or servers, and simultaneously capable of operating as client workstations or servers on local area networks based on the GOSIP standards using the OSI protocol stack with Transport Protocol Class 4 (TP4), DDN X.25 Packet Level Protocol for wide area network connections, and IEEE 802.3 for local area network connections. Combinations of Bridges, Routers, Brouters, Trouters, Gateways, Software Bridges, Terminal Servers, and other interconnection devices/software may be used for interconnection between these workstations and networks and to other LAN using the TCP/IP protocol stack or over wide area networks using CCITT X.25 media, when necessary. SNA compatibility and interoperability will be provided to selected workstations or servers, as determined.... Other connections to local unique, prototype, or Army standard standard systems will be provided on a case by case basis by the IMO.... Any multiuser database management system (DBMS) installed on a local area network must have full ANSI SQL compatability.
Note: Leave out the portion of the final sentence about 4GL. There is no international, ANSI, Army, or Federal standard for 4GL application development and prototyping languages. The Army has indicated that we are to use Information Engineering Methodology and Computer Aided System Engineering (CASE) tools. CASE tools do not normally contain 4GL development languages, although a few do provide 4GL's as prototyping tools. Until the Army or some other organizing body identifies what the standard 4GL will be, we should leave this tool alone.
Change 7l. to read:
Required resources:
The suite of hardware and software available through the Desktop III contract, number F01620-90-D-0001, Small Multiuser Computer (SMC) contract, number ?????, X.25 connections through the SMS contracts for internetworking and Wide Area Networking, number ????, and GOSIP compatible Local Area Networks through ULANA II when approved.
Change Workstation A configuration to CLIN 0001AB and Workstation B configuration to CLIN 0002AB.
The math coprocessor provided with these CLIN are critical for effective system performance, since the applications provided are all graphically oriented. Graphical applications such as Microsoft Windows, Microsoft Office, and Unix System V/386 Release 3.2 all require extensive floating point math to draw the graphical screens. Unless this floating point math is provided by a processor on the video board (which is not the case - we believe), it must be accomplished by the system CPU. Reasonable screen response would then require the math coprocessor. Buying each math coprocessor retroactively will cost hundreds of dollars more in money and installation manhours.
Change Workstations A and B software so that the user can select to operate under MS-DOS, POSIX, or both. Recommended Software would then be broken out into three suites, shown as follows:
MS-DOS Configuration.
MS-DOS 4.01 Operating System
Microsoft Office V1.0 (Single User)
Central Point PCTools V5.5
POSIX Configuration (POSIX Compliant Unix).
UNIX V/386 R3.2 Operating System
ENABLE OA (Single User)
POSIX and MS-DOS (MS-DOS applications running in VP/IX MS-DOS emulation window under UNIX)
UNIX V/386 R3.2 Operating System
ENABLE OA (Single User) (Optional)
MS-DOS 4.01 Operating System
Microsoft Office V1.0 (Single User)
Change Enhancement Package, Paragraph 2 to read:
b. Hardware:
CLIN 0022AA - OSI/GOSIP LAN Interface Card
CLIN 0022AB - OSI/GOSIP LAN Interface Transceiver
CLIN 0022AF-AJ - OSI/GOSIP LAN Interface Cable
c. Software:
CLIN 0022AC - MS-DOS OSI/GOSIP Networking Software (for MS-DOS based workstations)
or
CLIN 0022AE - POSIX OSI/GOSIP Networking Software (for UNIX/POSIX based workstations)
d. Documentation:
CLIN 0032FV - MS-DOS OSI/GOSIP Networking SW Documentation Package
or
CLIN 0032FW - UNIX/POSIX OSI/GOSIP Networking SW Documentaion Package
Change Enhancement Package, Paragraph 3 to read:
a. Used with Workstation B to create a Local Area Network Server.
Justification: If this Workstation B is to be used as a host computer, it would need to include a multiport asynchrounous serial communications board to allow multiple serial connections for terminals or PC's emulating terminals.
b. Hardware:
add 320 MB tape backup to first part of paragraph.
add WORM drive to LAN Server for Records Management usage (See Enclosure 1)
add CD-ROM reader to LAN Server for Printing and Publications usage. (Reference mass distribution of publications and forms on CD-ROM from DA) (Ensure compatibility of formats first) (Also decide at USAREUR level whether only the MILCOM CDOIMs will have these Army Standard CDs or whether each organization will have them. It is largely a matter of communications connectivity, capacity, and cost versus broader distribution of the CDs and readers)
add 3270 emulation with serial communications to form a communications gateway into ASIMS over DDN for the network server or for a single workstation configured as communcation server on the LAN.
Justification: Most Battalions and Brigades (as well as their higher Division/Corps and EAC staffs) would have regular and routine needs to access supporting STAMIS running on ASIMS computers. In this way the ASIMS mainframes become database and application servers over a DDN based USAREUR Wide Area Network, accessible by all USAREUR subordinate Wide Area Networks and LANS. This would then allow the orgnizations served by ASIMS to gain file access to its STAMIS data and reports for downloading or interactive (virtual terminal) access.
add information on use of LAN media such as COAX, Fiber Optic, or Shielded Twisted Pair LAN backbones, as well as 802.3 network bus topology. Include information on use of cascading Fan-Out boxes (Multiport tranceivers) for use in situations where a backbone cable is not feasible, such as in a temporary or mobile environment.
c. Software:
Change all Network Server software to UNIX/POSIX based software. MS-DOS based network servers cause the LAN to lack the C2 level security inherent in the UNIX V/386 Rel 3.2 based server. Note: it is not clear that the CLINs provided in this contract for networking software provide for anything other that client capability. Network server software in not clearly addressed in any of the CLIN descriptions that have been reviewed. The Desktop III contract, paragraph c11.20 (page 235) says that the contractor does not provide network operating system software.
Change all software and documentation CLINS to correspond to appropriate POSIX OSI/GOSIP Networking Software and Documentation. (i.e., from 0015 series CLINs to 0022 series CLINS for hardware.)
ENCLOSURE 1
GEOGRAPHIC ARCHITECTURE
THE MAP OF THE INFORMATION INFRASTRUCTURE
1. COMMAND GLOBAL DIRECTORY - FRAMEWORK FOR DISTRIBUTED DATA AND DISTRIBUTED APPLICATIONS.
References. AR 340-9, Office Symbols
AR 25-CAA, Compilation of Army Addresses
Federal Information Processing Standard for X.500
Global Internetwork Directory
2. Diagram of Unix LAN File Server or Host Directory Structure.
ROOT
*
+)))))))))))))0))))))))2)))))))0))))))))))))))))),
* * * *
*System *Personal *Position *Recordkeeping
*Operation *Mail *Mail *Files
Files
a. The directory tree for System Operation Files contains all Operating System, Network Operating System, Commercial Software, Security Files, and Approved Application (executable) files.
This file structure would require infrequent maintenance or modification by the systems administrator.
b. The directory tree for Personal-Mail contains electronic mail and file transfers addressed to specific authorized network users by name. A Personal Mail directory is optional with the organization. Personal mail traffic can overload the network and consume large amounts of storage if protocols for its use are not published and enforced. With this personal mail capability, significant manhours can be saved by the organization because the people will not have to leave their office to communicate brief informal messages, nor will they have to play telephone-tag to contact the addressee.
The path to the home directory is the unit office symbol, and the home directory consists of a suffix indicating the activity, such as S1, and the initials of the user. For example:
/aetlgkgc/s1-js is the personal home directory path for CPT Joe Schmoe, the Battalion S1.
Files for personal use will contain no official documents or data, except during the transition between position incumbents. This directory is needed for personal messages and to allow a smooth transition from one position incumbent to the next, without depriving either the former or the new incumbent with network access. After a user with a personal mailbox (home directory) departs the unit, the files will be reviewed by the new position incumbent and transferred as needed to the position-mail home directory for that position. Then the departed person's personal mailbox home directory and all remaining files will be erased.
This file structure would require frequent maintenance and modification due to the arrival and departure of personnel.
c. The directory tree for Position-Mail contains electronic mail and file transfers addressed to specific authorized network users by position. It contains the home directories of users by office symbol, office title, and a numberical position code within an office.
The path to the home directory is the unit office symbol. For example, the first four digits of the path would be "aetl" (the official office symbol for a USAREUR EAC subordinate command. Fifth and sixth digits would correspond to a brigade or CS/CSS organization, and seventh and eighth digits would correspond to a line battalion. This directory name would also be the DDN Sub-host name and LAN server name. The directories based on office symbol are necessary in case multiple organizations are served by the same server. Note that for a Corps organization, a office symbol code for a division or a COSCOM would be inserted between the SUBMACOM and brigade office symbols.
Subdirectories would correspond to the title of a headquarters staff element, a brigade staff element, battalion staff elements or batteries.
The home directory of a user would consist of an office title indicating the activity, such as S1, S2, CDR, etc., and a number assigned by the local system administrator.
A battalion S1 would have the following users, S1-1 (S1 Officer), S1-2 (Asst. S1), S1-3 (S1 NCOIC), etc. For example:
AETL is the official office symbol of 32d AADCOM
/aetl would be the public directory address on the Headquarters, 32 AADCOM file server. It is the path to the command directory for training schedules, command bulletins, public information, etc., accessible to all command authorized users.
/aetlXX would be the public directory address on a brigade or CS/CSS organization file server, with XX representing the office symbol suffix for that organization. It is the path to the brigade directory for training schedules, brigade bulletins, public information, etc., accessible to all brigade authorized users.
/aetlXXYY would be the public directory address on a battalion file server, with YY representing the office symbol suffix for that battalion. It is the path to the battalion directory for training schedules, battalion bulletins, public information, etc., accessible to all battalion authorized users.
/aetlXXYY/s1 is the path to the S1 staff directory on the battalion server, for S1 common information, staff bulletins, suspense lists, schedules, duty assignments, budgets, G1 distribution, etc., accessible to all s1 authorized users.
/aetlXXYY/s1/-1 is the path to the S1 Officer home directory for Email, draft documents, work files, and temporary data bases
/aetlXXYY/s1/-2 is the path the the Asst. S1 Officer home directory. Is there is no Asst. S1 Officer, do not use.
/aetlXXYY/s3/-3 is the path to the S3 NCOIC home directory.
/aetlXXYY/a/-1 is the home directory to the commander of A Battery.
/aetlXXYY/t/-2 is the home directory to the XO of Headquarters and Headquarters Battery. If there is no XO, do not use.
/aetlXXYY/x/-1 is the home directory of the Battalion Commander.
As the home directory of the position, all position Email, work files, drafts, scanned incoming correspondence, and temporary data bases will be stored in that directory, or in subordinate directories established by the user to organize files by MARKS, with subdirectories by project. Users could access files in higher level directories to use office or organization common work files and temporary data bases.
This file structure would require infrequent maintenance and modification to correspond to changes in unit or activity maximum strength based on changes in MTOE/TDA structure.
The users of this position directory must maintain the files contained within it according to MARKS. They must transfer relevant incoming correspondence files to the appropriate Recordkeeping directory, along with all files and data bases that contribute to a formal record communication or transaction.
Note: A position alias could be established in the network base on the authorization document. For example: AR FROM ARMY, E6 FROM TAADS CODE FOR 32D AADCOM, AVA99 FROM UIC WAVA99 FOR AUGMENTATION TO MTOE, 134C FROM TDA PARAGRAPH, 1 FROM TDA LINE IN PARAGRAPH, -1 FROM POSITION WITHIN LINE. THE - SYMBOL SEPARATED THE POSITION NUMBER FROM THE LINE NUMBER
d. The directory tree for Recordkeeping Files contains all official incoming and outgoing correspondence and all computer files which contribute to that correspondence, all record traffic, and all data bases that provide reference and management information for the command. There would be two groups of subdirectories under the Recorkkeeping Files directory.
(1) The first group of subdirectories under the Recordkeeping File directory would correspond to the Regulatory Series that affect that organization. The directory tree would correspond to the Modern Army Recordkeeping System (MARKS) file numbers assigned to the whole organization supported by the file server.
Individual staff element proponents would be assigned control of specific MARKS directories to determine who can gain access (read/write) to those files contained within the directory.
For example:
/ is the system root directory.
/MARKS is the base directory for all recordkeeping files
/MARKS/25 is the directory for the Information Mission Area Regulatory Series.
/MARKS/25/-1 is the directory for the Information Resources Management Program.
/MARKS/25/-1/a (e.g., a - zz) is the disposition subdirectory corresponding to the disposition code "a" for the MARKS AR 25-1 category. Additional subdirectories under this MARKS disposition directory would be established for each record item or correspondence that consists of more than one file. When a particular record requires a signature to be official, an unalterable electronically scanned image of the final signed page will be stored in the appropriate MARKS disposition directory on the computer along with its supporting files, and the actual signed document will be maintained in the appropriate MARKS manual file. Read permission will be established by the data administrator in coordination with the functional proponent for that MARKS number and the system administrator.
Each branch of directories will correspond to MARKS numbers approved by the organization Records Coordinator and Command Records Manager and contain offical record traffic and correspondence, as well as their contributing files. Once a item has been written to this series of directories, it must never be allowed to change, because it represents an official Army record, and Federal laws apply to its retention and management. For this reason the storage media for these active and inactive files should be of very high erasable capacity to handle all of the neccessary records. Erasable optical storage is recommended for this storage system. During the proponent's annual file maintenance, records that must be retired should be written to a permanent media approved by the National Archives (perhaps Write Once-Read Many (Worm) storage devices), and records that can be destroyed can then be erased from the erasable active and inactive storage.
(2) The second group of subdirectories will be labeled as REF subdirectories indicating reference files. They will contain: reference and functional management data bases, tables, and data dictionaries; reference and management publications, procedures, standards, and controls, and information about the organization processes, functions and tasks corresponding to that Regulatory Series; and documents requiring coordination across the organization, with appropriate annotation and revision controls. Access permissions will be established by the data administrator in coordination with the functional proponent for that MARKS number and the system administrator.
/MARKS/25/-1/REF/db is the directory for data bases and data tables containing reference and management information about the Information Mission. No subdirectories will be used under this directory. The management, integration, and control of these various tables must be controlled by a data dictionary for that particular Regulatory Series. These various functional data dictionaries will be integrated and controlled by a higher level data repository residing immediately below root (/db).
/MARKS/25/-1/REF/guid is the subdirectory for all published policy, regulation, procedures, standards, controls, and forms for this regulation, as well as a functional outline of all the functions, tasks, procedures, reports, and data element associated with this regulation.
/MARKS/25/-1/REF/coord is the subdirectory for all coordination actions across an organization. Standardized group access will be used, as established by the data administrator, unless the functional proponent for this coordination action indicates the need for a special coordination group.
3. Workstation Directories. Workstation directories will correspond to the System Operation File and Recordkeeping File directories on the LAN, as appropriate to the workstation software and functional responsibilities of the workstation users.
4. Network Storage Device and File Naming Conventions. The following table provides proposed naming conventions for all storage devices and files across LAN and WAN.
CONVENTIONS COMMON TO ALL PC'S, WORKSTATIONS, SERVERS, AND HOSTS.
SERVER/HOST ID =
BRANCH OF SERVICE CODE + TAADS COMMAND CODE + TYPE-CONFIGURATION NUMBER + CONFIGURATION SYTEM-NUMBER + DRIVE LETTER (STORED AS VOLUME NAME ON HARD DISKS)
EXAMPLE: AR+AETLGKGC = ARAETLGKGC
This code would be a unique identifier for a file server throughout DoD.
USER ID = BRANCH OF SERVICE CODE + LAN HOME DIRECTORY PATH FOR POSITION MAIL
EXAMPLE: AR+AETLGKGCS1-1 = ARAETLGKGCS1-1
This code would be a unique identifier for a position encumbent throughout DoD.
SYSTEM CONFIGURATION ID =
TYPE CONFIGURATION CODE + CONFIGURATION SYSTEM NUMBER
EXAMPLE: DT1 + .26
A TYPE-CONFIGURATION CODE WOULD CORRESPOND TO A BASIC CONFIGURATION IDENTIFIED IN AN APPROVED CAPR OR MATERIEL FIELDING PLAN. (e.g DT = Desktop and DT1 = Desktop Standard Configuration 1. Each configuration would be a specifically configured computer sytem, including its standard hardware and software components.) IT WOULD BE IDENTIFIED AS A MAJOR COMPONENT OF THE ORGANIZATION'S GEOGRAPHIC/TECHNICAL ARCHITECTURE. THE TYPE-CONFIGURATION NUMBER WOULD MATCH THE SPECIFIC DEVICE WITH THE HARDWARE AND SOFTWARE IDENTIFICATION DATA (INCLUDING SERIAL NUMBERS) MAINTAINED IN A MAINTENANCE/ ACCREDITATION/ ACCOUNTABILITY DATA BASE. THIS DATABASE SHOULD HAVE ALL CPU, COMMUNICATION EQUIPMENT, AND RELATED COMPONENTS (PERIPHERAL, SOFTWARE) IDENTIFIED BY SERIAL NUMBER, VERSION NUMBER, AND TYPE CONFIGURATION CODE, ETC. THIS WOULD INCLUDE ALL INFORMATION MISSION ARE ASSETS, NOT JUST TIER III ITEMS. SEPARATE FIELDS IN THE DATABASE WOULD IDENTIFY WHETHER THAT ITEM AND ITS RELATED COMPONENTS IS OWNED OR LEASED, AND TO BE MAINTAINED AS A TIER III ITEM.
THE CONFIGURATION SYSTEM NUMBER WOULD CORRESPOND TO THE QUANTITIES OF A PARTICULAR TYPE-CONFIGURATION, AUTHORIZED BY A CAPR OR MATERIEL FIELDING PLAN, THAT HAVE BEEN ISSUED.
STORAGE DEVICE ID =
SYSTEM CONFIGURATION CODE + DRIVE DESIGNATION
EXAMPLE: DT1.26 + .D = DT1.26.D
FILE ID = STORAGE DEVICE ID + DIRECTORY PATH TO FILE + FILENAME + FILE EXTENSION
EXAMPLE: DT1.26.D\MARKS\25\-1\a\SAMPLE.PCX
NOTE THAT THE SERVER/HOST ID COMBINED WITH THE FILE ID PROVIDES A UNIQUE IDENTIFIER FOR THIS FILE WITHIN DoD.
EXAMPLE = ARAETLGKGC-DT1.26.D\MARKS\25\-1\a\SAMPLE.PCX
5. WORKSTATION ACCESS SECURITY.
ALL STANDALONE PC AND NETWORK WORKSTATIONS WOULD HAVE SOFTWARE THAT PROVIDES SYSTEM TIMEOUT AND KEYBOARD LOCKOUT.
SYSTEM TIMEOUT WOULD LOCK-UP THE SYSTEM FROM FURTHER INPUT FROM KEYBOARD OR OTHER INPUT DEVICE AND BLANK THE SCREEN IF NO INPUT OR OUTPUT WAS PROCESSED ON THE SYSTEM IN A SELECTABLE TIME FRAME SUCH AS 5 MINUTES. THIS PROTECTS PC'S THAT ARE LEFT UNATTENDED FOR EXTENDED PERIODS. THE SYSTEM MAY BE REACTIVATED ONLY BY INPUT OF PRE-ESTABLISHED AD-HOC PASSWORD, REGISTERED USER-ID AND PASSWORD, OR BY A REBOOT.
KEYBOARD LOCKOUT WITH SIMULTANEOUS SCREENBLANK WOULD ALLOW A REGISTERED USER TO LOCK UP HIS KEYBOARD AND ALL OTHER INPUT AND OUTPUT DEVICES FROM FURTHER ACTIVITY. THE SYSTEM MAY BE REACTIVATED ONLY BY INPUT OF PRE-ESTABLISHED AD-HOC PASSWORD, REGISTERED USER-ID AND PASSWORD, OR BY A REBOOT. THIS PROTECTS PC'S THAT ARE LEFT OPERATIONAL OVER EXTENDED PERIODS AWAITING RECEIPT OF DATA COMMUNICATIONS FROM AN EXTERNAL PROCESSOR. IN THIS WAY A SYSTEM MAY BE UPDATED OR QUERIED FROM A REMOTE PROCESSOR AFTER DUTY HOURS WITH THE SAME LEVEL OF ACCESS CONTROL AS A PHYSICAL LOGIN. REMOTE PROCESSORS WOULD ALSO EXECUTE THIS LOCKOUT COMMAND AT THE END OF A DATA COMMUNICATION SESSION. ONCE DATA COMMUNICATION WITH/BY A REMOTE CPU OVER ANY PORT IS ATTEMPTED, NO KEYBOARD ACTIVITY WOULD BE ALLOWED EXCEPT A PROPER LOGIN FROM A REGISTERED USER.
ALL PASSWORDS (AD-HOC OR REGULAR) MUST MEET MINIMUM SECURITY STANDARDS (LENGTH, COMPLEXITY, ETC.) BEFORE ACCEPTANCE BY THE SYSTEM. ALL PASSWORDS MUST BE TIMED TO REQUIRE UPDATES ON A SELECTED TIMEFRAME.
THE ADPSSO WOULD GIVE A DEVICE ID NUMBER TO ALL STORAGE DEVICES OTHER THAT FLOPPY DRIVES.
ALL FLOPPY DRIVES SHOULD BE DISABLED AS A BOOT DRIVE FOR ALL PERSONNEL EXCEPT THE ADPSSO, SYSTEMS OPERATIONS PERSONNEL (I.E., SYSTEM ADMINISTRATOR/TASO/NSO), OR UNIT IM MAINTENANCE PERSONNEL.
THE ADPSSO WOULD MAINTAIN A SECURE ENCRYPTED (SHADOW) TABLE ON EACH PC BOOT DISK LISTING THE REGISTERED USERS FOR THAT SYSTEM. SYSTEMS OPERATIONS PERSONNEL OR UNIT IM MAINTENANCE PERSONNEL WOULD BE REGISTERED AS USERS ON ALL SYSTEMS FOR THEIR ORGANIZATION. EACH REGISTERED USER MUST HAVE HIS NAME ASSIGNED TO USER STATUS FOR THE DEVICE'S BOOT DISK. IN THIS WAY THE ADPSSO WOULD CONTROL UTILIZATION OF BOTH WARM AND COLD BOOT-UP OF PC'S.
EACH PC SHOULD ALSO HAVE SOFTWARE TO MAINTAIN A SECURE AUDIT TRAIL OF ALL ATTEMPTED LOG-INS, ALL LOG-INS, ALL DOS COMMANDS AND SYSTEM CALLS (E.G., COPY, ERASE, OPEN-FILE, APPEND, RENAME, FORMAT, ETC.), ALL PROGRAMS AND BATCH FILES EXECUTED, AND ALL COMMUNICATION PORT ACTIVATION AND USE (INCLUDING MOUSE/DIGITIZER USE).
IN ADDITION, A PROGRAM SHOULD BE ON EACH PC AND MULTIUSER SYSTEM (E.G., LAN OR UNIX) THAT ALLOWS A REGISTERED USER ON A SYSTEM TO TRANSFER THE LOG-IN TO A NON-REGISTERED USER SUCH AS A MAINTENANCE PERSON OR VISITOR. IN THE EVENT THE MAINTENANCE PERSON OR VISITOR DOES NOT HAVE A VALID USER ID, A TEMPORARY ONE MAY BE OBTAINED FROM THE ADPSSO OR SYSTEM ADMINISTRATOR. THE SYSTEM WOULD THEN MAINTAIN THE AUDIT TRAIL OF THE NON-REGISTERED USER'S ACTIVITY APPENDED TO THE USER ID OF THE REGISTERED USER WHO GAVE HIM ACCESS. WHEN THE NON-REGISTRED USER FINISHED HIS WORK HE WOULD LOG OUT, WHICH WOULD TRANSFER THE LOG-IN BACK UP TO THE REGISTRED USER WHO GAVE HIS ACCESS. IN THE EVENT THE SYSTEM TIMED-OUT OR AN ILLEGAL OPERATION (AS SPECIFIED BY THE ADPSSO OR SYSTEM ADINISTRATOR/TASO/NSO) WAS ATTEMPTED, THE SYSTEM WOULD LOCK-UP AND COULD ONLY BE REBOOTED BY THE ADPSSO.
6. LAN/WAN/HOST ACCESS.
EACH ADPSSO MUST MAINTAIN A NETWORK TABLE OF AUTHORIZED USERS MATCHED WITH DEVICES IN HIS LOCATION. THIS SHOULD CONSIST OF A CONSOLIDATION OF ALL PC ACCESS TABLES HE MAINTAINS.
ACCESS REQUIREMENTS FOR INDIVIDUALS, GROUPS, AND THE PUBLIC ARE DETERMINED BY THE DATA ADMINISTRATOR IN COORDINATION WITH STAFF ELEMENT SUPERVISORS AS FUNCTIONAL PROPONENTS. THE DATA ADMINISTRATOR WOULD DETERMINE INDIVIDUAL AND GROUP ACCESS PERMISSIONS BY A REVIEW OF THE ORGANIZATION, ITS MISSION, AND ITS FUNCTIONS, AND HOW RESPONSIBILITY FOR THOSE FUNCTIONS IS ASSIGNED TO INDIVIDUAL POSITIONS OR STAFF ELEMENTS. THE DATA ADMINISTRATOR WOULD PROVIDE THE ACCESS REQUIREMENT TABLE TO THE SYSTEM OPERATIONS PERSONNEL.
THE SOFTWARE TOOLS, SUCH AS GENERAL PURPOSE COMMERCIAL APPLICATIONS (SPREADSHEET, WORD PROCESSOR, GRAPHICS COMPOSITION, DATA BASE PROGRAMMING LANGUAGE, DATA QUERY SYSTEM, CALENDAR, SCHEDULER, PROJECT MANAGMENT, ETC.), WILL BE ACCESSIBLE TO ALL USERS ASSIGNED TO GROUPS WITH EXECUTE PERMISSIONS. IN THIS WAY, ALL USERS COULD UTILIZE THESE TOOLS TO CREATE WORK PRODUCTS FOR THE ORGANIZATION.
ACCESS TO APPLICATIONS, DEVELOPED LOCALLY OR TOP-FED, WOULD BE CONTROLLED BY THE FUNCTIONAL PROPONENT. THIS SAME CONTROL WOULD BE USED TO DETERMINE ACCESS AND PERMISSIONS TO MODULES WITHIN THE APPLICATION, TRANSACTIONS/REPORTS ROUTINES WITHIN THE MODULES, RECORDS CALLED BY THE TRANACTION/REPORT ROUTINES, AND DATA FIELDS WITHIN CALLED RECORDS.
OTHER THAT THE OBVIOUS TASKS OF KEEPING ACCESS TABLES UP TO DATE BECAUSE OF LOG-IN ERRORS AND NEW USERS, AND DOING FILE MAINTENANCE, THE PRINCIPAL WORKLOAD IN MAINTAINING THIS SYSTEM WOULD BE IN KEEPING THE USER ID AND ORGANIZATION DIRECTORY TREE IN SYNC WITH THE ORGANIZATIONS CURRENT EDITION OF THE MTOE AND TDA. IN THE EVENT A POSITION IS ELIMINATED BY A FORCE STRUCTURE CHANGE, THEN THE FILES AND DIRECTORIES SUPPORTING THAT POSITION AND ITS FUNCTIONS SHOULD BE MOVED TO THE HOME DIRECTORIES OF THE POSITIONS THAT INHERITED THE FUNCTIONS. IN THE EVENT NO POSITION INHERITS THE FUNCTIONS, THEN THE DIRECTORY AND FILES SHOULD BE MOVED TO THE HOME DIRECTORY OF THE ORGANIZATION RECORDS MANAGER FOR APPROPRIATE DISPOSITION.