APPENDIX E: PROGRAM LIBRARY ASSESSOR README FILE

INTRODUCTION:

The Library Assessor consists of this readme file ("yl_readm.txt") to guide the user, a set of command language files to execute a set of programs, and procedures to determine the functional capabilities of an Ada program library management system (including some time and space performance measurements), and a report form ("yl_tmplt.txt") for collection of test results, and recording of comments.

Library scenarios performing timing measurements are actually performed as part of the performance tests in the Systematic Compile Speed group, Compilation Unit Size subgroup. The tests in this subgroup are relevant to both the Library Assessor evaluation and to the performance tests for systematic compile speeds. While the interdependence is regrettable, it is preferable to compiling the relevant files twice because compilation requires more than 20 hours on some of the trial systems. If users want to complete the Library Assessor before running the performance tests, or don't need to run the full performance test suite at all, they must run the "sy_cu" and "sy_1000" command files from the performance tests and copy the relevant results (as directed by the command file output) into the Library Assessor Summary Report form. The ACES Library Assessor contains 22 scenarios (most have multiple parts) which the user will adapt to the library system being evaluated. The different scenarios are independent and can be run (or rerun) in any order.

These are:

Before running the Library Assessor tests, the user must have completed the ACES Pretest Step 5. This will have compiled the zg_glob packages into the program library. Running the zg_basln command file will be sufficient to enter into the program library all the "global" units required by the Library Assessor (actually, only Steps 1 and 3 of the zg_basln file need to be performed to compile the zg_glob packages; not necessary, but not harmful are the random number generator from Step 2, the Math package from Step 3, the zg_init programs from Step 4, and the zg_incld tool from Step 5).

The scenarios calling for timing measurements are actually performed in the performance test section, Systematic Compile Speed group. Results should be copied to the Library Assessor Report form from running these tests (as noted in the descriptions of the individual scenarios here and in the output from compiling the Systematic Compile Speed group test programs). Because the tests are designed to make library commands part of the performance tests, a user cannot complete the Library Assessor Report form before running some performance tests. However, this does provide for the easy comparison of library manipulation processing between systems by the Comparative Analysis (CA) tool.

These test time measurements may be extracted from the logs obtained when running the SY group lower-level command files "sy_cu.com" and "sy_1000.com" which are called from "sy.com". These time measurements can be extracted directly by editing the log files, or indirectly by examining the "compilation_condensed" file created by running the Condense tool and specified in the "za_cosys.txt" file. The disk size measurements (if the user has performed the necessary system-dependent adaptation required to extract disk space information on a system) will require users to read the log files. The Library Assessor tests which request timing (or timing and sizing) information are noted in the "yl_tmplt.txt" summary report form file, and identify the Systematic Compile Speed problem which collects the associated timing data. In filling out the form, users replace the words (e.g., "time*") in the problem name field with the associated measurements.

One feature which is used in several Library Assessor scenarios is disk size measurement. The purpose of library scenario yl_ib02-16 is to assess the capability of a system to provide disk size measurements. If the system does not provide this information, it should not be awarded a "YES" for disk size measurements even if a workaround can be devised in selected cases. However, in other cases the disk size is requested for purposes of collecting disk usage information for comparative purposes and any technique which gathers the desired size data would be acceptable.

Workarounds can be devised for some compilation systems which do not provide direct size data, depending on the information the ACES user can obtain about their library implementation.

1. If the compilation system uses operating system files for storing intermediate unit objects, there are several possibilities:

a. If there is a simple mapping from Ada unit names to system file names used to store the intermediate objects (or if the system will display the system file names on request) it may be possible to directly use the host operating system capabilities to list disk file sizes. The name mapping is likely to be awkward for units with long names (this is a particular concern for nested subunits where the fully qualified name would be rather long), or for Ada unit names containing an underscore (which may not be a valid character in a filename on some operating systems).

b. If the mapping from Ada unit names to system filenames is not easily determined, disk space used by a unit can be measured by one of the following approaches:

(1) Bracket the compiler invocation with a command to display the total size of all files in the directory which contains the Ada library and then subtract the difference. In DCL:

$ DIRECTORY/SIZE/GRAND_TOTAL ADALIB

$ ADA

.

.

.

$ DIRECTORY/SIZE/GRAND_TOTAL ADALIB

This technique will not work for recompilations, where the difference in size will only show the size difference between the original and the modified objects. Library systems may maintain structures to record inter-unit dependencies (so they can provide closure facilities and easily check for obsolescence). These dependencies may be stored in a separate, library-wide structure and not associated with each unit (see test yl_ib17). Techniques which measure directory size may include size for this structure and will not be directly comparable to measurements which only examine files "directly charged" to each unit. This is the technique used in the UNIX versions of library command files. There are comments marking the places to display "before" and "after" sizes in the VMS sample command files.

(2) Write a time stamp before invoking the compiler and immediately after the compiler completes, use a host operating system command to display the size of all units created after the time stamp. In DEC Command Language (DCL):

$ START_TIME=F$EXTRACT(12,11,F$TIME())

$ ADA

.

.

$ DIRECTORY/SIZE/SINCE='START_TIME ADALIB

2. If the compilation system uses a single operating system file for an Ada program library and manages partitions within this file for each of the Ada units in the library, it may be possible to use operating system capabilities to measure the size (disk space in use) of the program library file before and after compiling a new Ada unit into it.

If the library manager marks obsolete units as "unused", but does not reclaim space occupied by the unit, then this technique may be applicable to recompilation. Systems with user commands to "compress" a program library almost surely do not automatically reclaim disk space for obsolete units.

There may still be systems for which no variations of the above technique will permit measurement of disk sizes of Ada units (with anything less than unlimited access to the source code for the library manager and the investment of a large effort to write a program to process it and report size). On such systems, the ACES users should report for assessor scenarios which request disk size that the information is "Not Available" (the users should also note in comments the extent to which they tried to develop workarounds).

PREPARING TO TEST:

Have these groups of files available:

1. Global files (with a prefix of "zg_").

2. Library Assessor files (those with a "yl_" prefix). The Ada files associated with Library Assessor scenario N are named "yl_ibn*. For example, there are five "*.ada" files associated with Scenario 3: "yl_ib03a.ada", "yl_ib03b.ada", "yl_ib03c.ada", "yl_ib03d.ada", and "yl_ib03e.ada". On systems with particularly limited disk space, a user could load only those files needed for a particular scenario onto the host system.

Fill out the descriptive information in the report form ("yl_tmplt.txt"). This calls for information on the identity of the system being tested, the hardware and software configuration used, the name of the tester, the date, and any other information a user may wish to note.

Adapt the command files for each scenario:

Sample Library Assessor command language files are distributed for two compilation systems: VMS (files with a ".com" suffix) and UNIX (files with a ".unx" suffix).

When adapting the Library Assessor command files, take note if the compilation system under test does not compile files with a ".ada" suffix. The ".ada" files will need to be renamed or a copy will need to be made on such systems.

For each scenario, a high-level driver command file calls on a lower-level command file. Submitting the driver will call on each in turn.

Command files can generally be executed interactively or submitted as batch jobs. Two of the library scenarios are defined as interactive processes (yl_ib05 which tests for integrity after manual aborts, and yl_ib06 which tests for concurrent access) and should not be run in batch mode.

TESTING:

The general steps for testing each library scenario are the same:

1. Adapt "yl_ib*.com" file.

2. Run "yl_ib*.com" file.

3. Examine results. As each command file executes, it writes to standard output (on VMS by using a DCL "write" command, on UNIX by using an "echo") text identifying what capability is being tested and how to determine whether the capability is correctly implemented (the results sufficient to answer "YES" to the questions in the Library Assessor Report form).

4. Fill in answers on the report form ("yl_tmplt.txt"), based on directions in the output.

The Library Assessor Report form ("yl_tmplt.txt") should be filled out with the results from attempting each scenario. It could be modified with an editor, or printed and the hardcopy filled in. When the Library Assessor is complete, the filled-in form will form a summary report for future reference (note that the form has provisions for entering general comments).

5. Run the command files for each scenario.

DESCRIPTIONS OF LIBRARY ASSESSOR SCENARIOS:

1. yl_ib01 - Query program library contents.

yl_ib01 will test the capability of the library manager system to support queries of the units in a program library. It tests for support of names greater than 30 characters (because some systems might restrict the length of names of library units) and for the support of wild-card meta-characters in a query.

2. yl_ib02 - Query status of particular units.

yl_ib02 will test the capability of the library manager system to support queries for particular units in a program library.

The first three questions (yl_ib02-1, yl_ib02-2, and yl_ib02-3) are performed in the performance tests, Systematic Compile Speed group, and Compilation Unit Size subgroup. This placement permits the Comparative Analysis tool to include timing measurements for some library manipulation commands in the inter-system comparative reports.

3. yl_ib03 - Does the library system support versions and/or variations?

yl_ib03 will test the capability of the library manager system to support versions and/or variations. The example is setup to test for the support for sublibraries.

4. yl_ib04 - Space reclamation.

yl_ib04 will test the extent to which the library manager is able to reuse space from obsolete and deleted units.

5. yl_ib05 - Is the library intact after manual aborts?

yl_ib05 will test the integrity/robustness of a program library system by starting a compilation and aborting it before it completes. This is an interactive test; the user will start the compiler and abort it before it completes. The sample program provided is large enough that it is unlikely that it will complete before the user can abort it. Users are cautioned that even if three successive manual abortions of compilation do not result in failure, they should not conclude that the library system is immune to corruption. Failure may be "statistical" in nature, and if more trials were attempted corruption might eventually be observed. It is also possible that the probability of corruption varies with the specific features being tested. Some variables that may cause the system to be more vulnerable to corruption after manual aborts are:

a. Particular functions of the sample programs being compiled.

b. Library manipulations (other than compilation), such as deleting units.

If users know from prior experience with the system (or from a review of system documentation) that compilations cannot be aborted without risking corruption of the library system, they may chose not to run this test scenario. This is advisable, if the recovery from a corrupted library is particularly expensive.

Some systems may avoid the problem of library corruption after a manual abort by not supporting the capability to abort the compiler (masking any operating system abort command until the compiler completes). For such systems, the user may either mark this scenario as "Not Applicable", or try to force abnormal compiler termination by powering off the machine, or dismounting the disk drive containing the program library while the compiler is running.

6. yl_ib06 - Concurrent library access.

yl_ib06 will test the program library for concurrent access. This is basically an interactive test--the user should have two "sessions" active (e.g., windows, batch jobs, terminal sessions). The example command file is written using a VMS SPAWN command to indicate interactive use. However, this is not the recommended way to test for concurrent library access because it does not verify that operations are really concurrent. A library manager which provides for exclusive access to the program library and enforces concurrent requesters to wait until the current user is completed will completely support the syntax of current use, but will not satisfy the intent. To satisfy this scenario, it is necessary to verify that users are not forced to wait for "long periods" until all concurrent users are finished making all their library manipulations before satisfying their requests.

7. yl_ib07 - Provides names of missing units.

yl_ib07 will test whether the program library manager will report the names of missing units. This will typically be a linker function, but different Ada compilation systems may assign the capability to different parts of the compilation system. It might be deferred to the loader.

8. yl_ib08 - Recompilation facility.

yl_ib06 will test the program library ability to support a "bring-up-to-date" capability, and the effectiveness of this command in minimizing recompilation.

9. yl_ib09 - List a valid compilation order.

yl_ib09 will test whether the program library manager has a capability to display the units of a program in a valid compilation order. A example source program with several dependencies is compiled into a library as a test case.

10. yl_ib10 - Moving intermediate objects.

yl_ib10 will test whether the program library manager has a capability to move intermediate forms between libraries without recompiling the source text. It assumes that the system supports a sublibrary concept as in yl_ib03. (If not, the question concerns transporting intermediate objects between installations; this is a nice capability to have, but it is too extreme to require an ACES user to have two different installations to perform a Library Assessor test.)

11. yl_ib11 - Deleting objects.

yl_ib11 will test aspects of a program library manager deletion facility. It tests the following subpoints and measures their execution time:

a. Is a reasonable message produced when an attempt is made to delete a nonexistent unit?

b. Delete a nonexistent unit when there are many units in a library.

c. Delete a subunit--is parent unit flagged?

d. Delete a parent--are subunits deleted?

e. Delete a package with no dependent units.

f. Are both specification and body removed in one command?

g. Is it possible to delete using wild card characters?

h. Delete from a library with 1000 units.

i. Delete from a library with 100 units.

These points are addressed in the performance tests, Systematic Compile Speed group, and Compilation Unit Size subgroup. Copy timing and size measurements from that group into the library report form as directed.

12. yl_ib12 - Library creation.

yl_ib12 will test whether the library system provides a "create library" command and measures its execution time, if provided.

These questions are answered in the performance tests, Systematic Compile Speed group, Compilation Unit Size subgroup, and program sy_cum45. Copy timing measurements from that group into the library report form as directed.

13. yl_ib13 - Library consistency/integrity verification.

yl_ib13 will test for the presence of a capability to verify that a program library is internally consistent.

14. yl_ib14 - Library support for large programs.

Program yl_ib14 will test the capability of a library system to support large programs. One set of programs is provided to measure the time to compile 100 units at a time into a library which is initially empty of user-defined units, producing programs with 100, 200, 300, 400, 500, 600, 700, 800, 900, and 1000 units. This set of programs provides data to observe whether compilation times degrade as the number of units in a library increases. Because of the dependence of later units on earlier ones, if a failure occurs in one of the programs, all of the later programs in the set should be skipped.

There is also a set of tests for a program with 100 (and with 200) subprograms; the time to compile a file containing the subunit specifications is measured separately, as is the time to compile a file containing the bodies, as is the time to compile a file containing a corresponding program which defines the subprograms locally within a package.

These test programs may exceed the capacity limits of a system. Because of the time which may be required to compile and link this set of programs (over 24 hours on some of the systems used during ACES testing), these programs are processed in their own command file ("sy_1000.com"). The command file includes logic checking the elapsed time against a user-modifiable time limit, and will not start another compilation or link if the elapsed time exceeds the specified limit. It will also avoid starting another compile or link if an error was detected in an earlier step; the later files are dependent on units in earlier files, and will not complete successfully if there were earlier errors, but might still consume significant amounts of time in failing.

These questions are answered in the performance tests, Systematic Compile Speed group, Compilation Unit Size subgroup, and programs sy_cum12 through sy_cum27. Copy timing and sizing measurements from that group into the library report form as directed.

15. yl_ib15 - Size of a NULL unit.

yl_ib15 will measure the disk size for storage of the intermediate object forms for a NULL procedure.

16. yl_ib16 - Generics.

yl_ib16 will measure the time to compile and the disk space required to store the intermediate forms of:

a. yl_ib16-1 - A small generic definition.

b. yl_ib16-2 - Instantiation of this small generic unit.

c. yl_ib16-3 - Compilation of a comparable small non-generic unit.

d. yl_ib16-4 - A large generic definition.

e. yl_ib16-5 - Instantiation of this large generic unit.

f. yl_ib16-6 - Compilation of a comparable large non-generic unit.

These questions are answered in the performance tests, Systematic Compile Speed group, Compilation Unit Size subgroup, and programs sy_cum28 through sy_cum33. Copy timing and sizing measurements from that group into the library report form as directed.

17. yl_ib17 - Hidden space.

yl_ib17 will search for the presence and reclamation of "hidden space" in a library system.

Hidden space is used by some implementations to record inter-unit dependencies. This scenario tests for reclamation of this type of hidden space. It uses a multi-step process:

Step 1 - Create a temporary library.

Step 2 - Record the program library size as reported from manager commands and from operating system facilities.

Step 3 - Compile and recompile multiple units with many inter-dependencies.

Step 4 - Measure size of program library and enter amount by which this measurement exceeds step 2 into template as "FULL".

Step 5 - Delete all the user-defined units in the library.

Step 6 - Measure size of program library and enter amount by which this measurement exceeds step 2 into template as "DELETED".

Step 7 - Delete the temporary program library.

The concern is that "hidden" space (perhaps used by the library manager to record inter-unit dependencies) is not reclaimed and reused after the units in the library are deleted. If the size measured at Step 6 is the same as Step 2, we can safely assume that space is reused. Note that the sample program used to test for hidden space contains enough units (and inter-unit dependencies) that they should show sizes, if space is not reclaimed. If smaller sample programs were used, it might be that no difference would be measured (although hidden space is not reclaimed) because of quantization effects (small numbers might not add enough data to the hidden structures to overflow the initial space reserved for structure).

On systems which use and do not reclaim such hidden space, space could be reclaimed and the speed of library references generally improved by (deleting and) recreating a program library. This technique may be useful when the speed of compilation and library searches seem to decrease as units are added and deleted over time. It may be possible to restore the system to its original speed by rebuilding the library.

This test may exceed the capacity of a library system.

18. yl_ib18 - Obsolete executables.

yl_ib18 will test whether an executable file is marked obsolete when one of the Ada units from which it is composed is removed from the program library.

19. yl_ib19 - Source in library.

yl_ib19 will test whether the program library provides the capability to extract the source text of a program unit from the library.

20. yl_ib20 - Order of elaboration.

yl_ib20 will test whether the program library provides the capability to list package bodies in the order they will be elaborated when a main program is started.

21. yl_ib21 - Impact of potential modification.

yl_ib21 will test whether the program library provides the capability to assess the impact of a potential modification of unit, that is, to list the units which would be affected if a named unit were to be modified. Seven cases are tested.

22. yl_ib22 - Estimate of closure time.

yl_ib22 will test whether the program library provides the capability to estimate the time it would take to recompile all the obsolete units of a program. This is tested by compiling a file with several units, then compiling two modified units which make other units in the program obsolete, and then requesting a recompilation time estimate, and finally performing a recompilation and comparing the measured time with the estimate.

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

Evaluator's Name:____________________________________Date:____________

Compiler:____________________________________________Version:_________

Operating

System:______________________________________________Version:_________

Host

Hardware:____________________________________________Model:___________

Disk

Devices:_____________________________________________Memory:__________

Units for disk size measurement ( bytes in a block): _________________

Disk units to which following files are assigned:

Operating System: ___________________________________________

Ada Compilation System: ___________________________________________

Program library: ___________________________________________

ACES source files: ___________________________________________

Comments Are disks remote (accessed through network): ________

Size of disk cache (if present): ________

Extent of disk fragmentation (if known): ________

Other

Information:__________________________________________________________

______________________________________________________________________

Items with time measurements are collected in the Systematic Compile Speed Group of the performance tests and presented in the Comparative Analysis report.

For column entries with "name (t)" or "name (ts)" or "name (s)", the "name" should be replaced with the time and/or disk space measurements as they are determined. The presence of a time or space measurement implies a YES response (the system supported the capability and the results are presented). Time and space measurements can be extracted from the appropriate log files from "SY_CU.COM" or "SY_1000.COM".

Time is in seconds. Space is in disk blocks.

======================================================================

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

SCENARIO YES/NO or

TIME, SPACE

YL_IB01 Query program library contents

yl_ib01-1 Are names greater than 30 characters

supported? : ___

yl_ib01-2 Are wild card queries supported? : ___

YL_IB02 Query status of particular units

yl_ib02-1 Unit not present in new library : SY_CUM36 (t)

yl_ib02-2 Unit not present in library with 100 units : SY_CUM35 (t)

yl_ib02-3 Unit not present in library 1_000 unit : SY_CUM34 (t)

yl_ib02-4 Does library list unit's full name? : ___

yl_ib02-5 Does library list creation date? : ___

yl_ib02-6 Does library list unit status

(current or obsolete)? : ___

yl_ib02-7 Does library list compiler options used to

enter unit into it (such as /DEBUG or

/OPTIMIZE)? : ___

yl_ib02-8 Does library list version number of the

compiler? : ___

yl_ib02-9 Can the library list units dependent on

named unit? : ___

yl_ib02-10 Can library list closure of dependent units,

that is, all the units which would be made

obsolete if a named unit were recompiled? : ___

yl_ib02-11 Can library list units which named unit

depends on? : ___

yl_ib02-12 Can library list the closure of dependent

units, that is, all the units whose

recompilation would force the recompilation

of the named unit? : ___

yl_ib02-13 Can the library list the parents of a

named subunit? : ___

yl_ib02-14 Can the library list the subunits of a

named parent unit? : ___

yl_ib02-15 Does the library list the type of a unit,

that is, package specification / package

body / generic package specification /

generic package body / subprogram

specification / subprogram body /

subunit? : ___

yl_ib02-16 Does the library list the disk space used

by a unit? : ___

yl_ib02-17 If yl_ib02-16 is true, does the space for

a parent include the space for the

subunits? : ___

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

YL_IB03 Does the library system support versions and/or

variations? : ___

YL_IB04 Space reclamation

yl_ib04-1 Is space reclaimed after repeated

successful recompilations? : ___

yl_ib04-2 Is space reclaimed after repeated

unsuccessful recompilations? : ___

yl_ib04-3 Is space reclaimed after successful

compilations followed by explicit

deletions? : ___

YL_IB05 Is the library intact after manual aborts? : ___

# of aborts?

YL_IB06 Concurrent library access

yl_ib06-1 Is the host OS multiprocessing? : ___

yl_ib06-2 Does the library support simultaneous

retrieval? : ___

yl_ib06-3 Does the library support simultaneous

retrieval with one updating process? : ___

yl_ib06-4 Does the library support simultaneous

updating? : ___

YL_IB07 Does the library system identify missing units

by name on a link step? : ___

YL_IB08 Recompilation facility

yl_ib08-1 Is there a "bring-up-to-date" command? : ___

yl_ib08-2 If yl_ib08-1 is true, is an initial correct

compilation not required? : ___

yl_ib08-3 Can the manager list the names of the

units which must be recompiled to

make a program up-to-date, without

compiling them? : ___

yl_ib08-4 Does "bring-up-to-date" avoid compiling

units when no updates to source files

have been made? : ___

yl_ib08-5 Does "bring-up-to-date" avoid compiling

units when the main program source

is replaced by an identical file? : ___

yl_ib08-6 Does "bring-up-to-date" avoid compiling

a package body after making insignificant

changes to the package specification? : ___

yl_ib08-7 Does "bring-up-to-date" avoid compiling

dependent units after adding unique

declarations to a package specification? : ___

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

yl_ib08-8 Does "bring-up-to-date" avoid compiling

subunits after making changes to a parent

unit which do not affect any subunits? : ___

yl_ib08-9 Does "bring-up-to-date" avoid compiling

subunits after making changes to a

parent unit which do not affect all

subunits? : ___

yl_ib08-10 Does "bring-up-to-date" properly compile a

unit after adding a new dependency on

that unit to the program? : ___

yl_ib08-11 Does "bring-up-to-date" avoid compiling a

changed unit after removing all WITH

clauses mentioning the unit from the

program? : ___

YL_IB09 Is there a capability to list the units of a

program in a valid compilation order? : ___

YL_IB10 Can the library system move intermediate objects?: ___

YL_IB11 Deleting units

yl_ib11-1 Try to delete a nonexistent unit from

library with 1000 units. Is a reasonable

message produced? : ___

yl_ib11-2 Try to delete a nonexistent unit when

there are 1_000 units in the library : SY_CUM37 (t)

yl_ib11-3 When a subunit is deleted, is the parent

unit flagged? : SY_CUM39 (t)

yl_ib11-4 When a parent unit is deleted, are the

subunits deleted (or flagged?) : SY_CUM40 (t)

yl_ib11-5 Delete a package with no dependent units : SY_CUM41 (t)

yl_ib11-6 Can library delete both specification and

body of a package in one command? : SY_CUM42 (t)

yl_ib11-7 Does the library support deleting using wild

card metacharacters? : SY_CUM43 (t)

yl_ib11-8 Delete from a library with 1000 units : SY_CUM38 (t)

yl_ib11-9 Delete from a library with 100 units : SY_CUM44 (t)

YL_IB12 Library creation : SY_CUM45 (t)

YL_IB13 Library consistency / integrity verification : ___

YL_IB14 Library support for large programs

Tests yl_ib14-1 .. yl_ib14-10 may exceed library system

capacity. Note when failures occur.

yl_ib14-1 Compile and link program with 100 units : SY_CUM12 (ts)

yl_ib14-2 Compile and link 100 more units - total 200: SY_CUM13 (ts)

yl_ib14-3 Compile and link 100 more - total 300 : SY_CUM14 (ts)

yl_ib14-4 Compile and link 100 more - total 400 : SY_CUM15 (ts)

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

yl_ib14-5 Compile and link 100 more - total 500 : SY_CUM16 (ts)

yl_ib14-6 Compile and link 100 more - total 600 : SY_CUM17 (ts)

yl_ib14-7 Compile and link 100 more - total 700 : SY_CUM18 (ts)

yl_ib14-8 Compile and link 100 more - total 800 : SY_CUM19 (ts)

yl_ib14-9 Compile and link 100 more - total 900 : SY_CUM20 (ts)

yl_ib14-10 Compile and link 100 more - total 1000 : SY_CUM21 (ts)

yl_ib14-11 Compile unit with 100 SEPARATE

specifications : SY_CUM22 (ts)

yl_ib14-12 Compile unit with 100 SEPARATE bodies : SY_CUM23 (ts)

yl_ib14-13 Compile unit with 100 local subprograms : SY_CUM24 (ts)

yl_ib14-14 Compile unit with 200 SEPARATE

specifications : SY_CUM25 (ts)

yl_ib14-15 Compile unit with 200 SEPARATE bodies : SY_CUM26 (ts)

yl_ib14-16 Compile unit with 200 local subprograms : SY_CUM27 (ts)

YL_IB15 Size of NULL program : ___ (s)

YL_IB16 Measure the compile time and disk space size of

the following generic units:

yl_ib16-1 A small generic definition : SY_CUM28 (ts)

yl_ib16-2 Instantiation of this small generic unit : SY_CUM29 (ts)

yl_ib16-3 Compilation of a comparable small

non-generic unit : SY_CUM30 (ts)

yl_ib16-4 A large generic definition : SY_CUM31 (ts)

yl_ib16-5 Instantiation of this large generic unit : SY_CUM32 (ts)

yl_ib16-6 Compilation of a comparable large

non-generic unit : SY_CUM33 (ts)

YL_IB17 Does the library system reclaim hidden space? : FULL (s)

DELETED (s)

(delta from SY_CU.COM start and finish) SY_CU (s)

YL_IB18 Is an executable NOT marked as obsolete when a

unit it is compiled from is modified? : ___

YL_IB19 Does (can) the program library contain unit

source text? : ___

YL_IB20 Does the library system provide a capability to

present an order of elaboration? : ___

YL_IB21 Does the library system provide the capability to

assess the impact of a potential modification of

a unit? This is a "What If" mode which would list

the units which would be affected if a specified

unit is changed.

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

yl_ib21-1 Simple non-null dependency.

Main program which WITHs one package with

body where the body has a subunit. List

dependencies on package spec. Should include

main program, package body and subunit. : ___

yl_ib21-2 Simple null dependency.

Main program which WITHs one package with

body where the body has a subunit. List

dependencies on subunit. Should be null. : ___

yl_ib21-3 Possible dependency derived from INLINE.

Main program which WITHs one package with

body where package exports a subprogram

specified as INLINE. List dependencies on

package body. Should include main program. : ___

yl_ib21-4 Simple chain of dependencies.

Main program which WITHs one package (A)

which WITHs another package (B), which WITHs

another (C). List dependencies on (C) spec.

Should include all units. : ___

yl_ib21-5 Simple subunit dependencies.

Main program which defines subunit (A) which

defines subunit (B) which defines subunit

(C). List dependencies on (B). Should

list (C). : ___

yl_ib21-6 Subunit dependency with INLINE.

Main program which defines subunit (A) with

(specified as INLINE) which defines subunit

(B) (specified as INLINE) which defines

subunit (C) (specified as INLINE). List

dependencies on (B). Should list (C), might

list (A) and Main if INLINEs are honored : ___

yl_ib21-7 Dependency on generic

Main program which WITHs generic subprogram

(A). List dependencies on body of (A). Might

list none or list (C), depending on the

implementation of generics. : ___

YL_IB22 Can the library system provide an estimate of the

time which would be required to rebuild a program

after modifying source units? : ___

---------------------------------------------------------------------

ADA COMPILER EVALUATION SYSTEM Version 2.0

ADA PROGRAM LIBRARY ASSESSOR REPORT

General comments:

________________________________________________________________

________________________________________________________________

________________________________________________________________

Impressions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

Points to consider:

A. If the times for YL_IB14-1 .. YL_IB14-10 follow a sharply

increasing trend, then library search speed degrades as

the number of units in the library increase. This could

be awkward for programs with large numbers of units.

B. Several library managers maintain "description" files which

might fragment as units are added and deleted. The time

to perform operations may vary greatly depending on the

history of usage - the longer the library is used the slower

it becomes. This affects the extent to which it is valid

to extrapolate from one set of measured compilation times to

predict times of "similar" compilations on a library which

even has the same contents. It may be that operations on

a program library could be greatly accelerated by rebuilding

the library. This file may also retain "hidden space" (see

YL_IB17 and results from performance test command file SY_CU).

C. In general, all the compilation and library manipulation

operations are sensitive to traditional system tuning.

Execution of the same release of the compilation system and

operating systems on identical hardware can produce very

different results depending on the system installation and

user account parameters. Extrapolation to other configurations

is risky. Items affecting performance include: disk and

channel balancing; disk caching; disk buffering; disk

fragmentation; account quotas; the sizes of various system

structures and parameters (such as whether to perform read-

after-write checking on disk I/O by default or not); the

amount of memory available to the compiler/library manager;etc.