|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - downloadIndex: ┃ E T ┃
Length: 151044 (0x24e04)
Types: TextFile
Names: »ENVIRONMENT_RELEASE12_5_0_LPT«
└─⟦d10a02448⟧ Bits:30000409 8mm tape, Rational 1000, ENVIRONMENT, D_12_7_3
└─ ⟦fc9b38f02⟧ »DATA«
└─⟦47afa1691⟧
└─⟦this⟧
└─⟦5f3412b64⟧ Bits:30000745 8mm tape, Rational 1000, ENVIRONMENT 12_6_5 TOOLS
└─ ⟦91c658230⟧ »DATA«
└─⟦75a4ca594⟧
└─⟦this⟧
Rational Environment Release Information
Release D_12_5_0
Copyright 1991 by Rational
Part Number: 508-003207-005
September 1991 (Software Release D_12_5_0)
\f
ENP-100i and CMC are trademarks of CMC Corporation.
EXOS 204 is a trademark of Excelan, Inc.
IBM is a registered trademark and RISC System/6000 is a trademark
of International Business Machines Corporation.
PostScript is a registered trademark of Adobe Systems
Incorporated.
Rational and R1000 are registered trademarks and Rational
Environment is a trademark of Rational.
Sun Workstation is a registered trademark of Sun Microsystems,
Inc.
UNIX is a registered trademark of AT&T.
Rational
3320 Scott Boulevard
Santa Clara, California 95054-3197
1. Overview
This D_12_5_0 release of the Rational Environment is primarily a
maintenance release that:
* Fixes a large number of problems from previous releases,
enabling existing commands to work correctly. Some of these
fixes introduce new features (see section 6); other fixes
involve changed features (see section 7). A major fix,
described in section 6.3.4, enables you to free significant
amounts of disk space on your system.
* Introduces various new Environment interfaces, including:
- Two new networking packages
(!Tools.Networking.Transport_Name.Service and
!Tools.Networking.Transport.Route); see sections 6.6 and
6.7
- A package for managing the storage of encrypted passwords
that provide access to remote systems
(!Commands.Remote_Passwords); see section 6.5
- A new subsystem (!Tools.Math_Support), which contains
implementations of two secondary standards for elementary
mathematical functions; see section 6.9
- Various new commands in !Commands.System_Maintenance and in
package !Commands.Access_List; see sections 6.3 and 6.1
September 1991 R\f
Release D_12_5_0
- New commands in !Commands.Abbreviations for printing; see
6.2
* Changes the way an R1000 is initialized at boot time to
simplify R1000 system management and layered-product
installation. See section 9.
* Provides a single release that can be installed on any R1000
configuration.
* Provides up-to-date, significantly expanded online help for 23
packages. See section 8.
2. Supported Configurations and Upgrades
D_12_5_0 supports the following configurations of the R1000:
* Series 100
* Series 200 (Models 10, 20, and 40)
* Series 300 System (300S)
* Series 300 Coprocessor (300C) for the IBM RISC System/6000
and Sun Workstation servers.
* Series 400 System (400S)
* Series 400 Coprocessor (400C) for the IBM RISC System/6000 and
Sun Workstation servers.
D_12_5_0 supports two kinds of tape drive:
* The 9-track tape drive, which is standard on the Series 100
and 200 and an optional upgrade to the Series 300S.
* The 8-millimeter cartridge tape drive, which is standard on
the Series 300S, 300C, 400S, and 400C, and an optional upgrade
to the Series 200.
D_12_5_0 also supports the optional expansion of memory from 32
megabytes to 64 megabytes to improve system performance. This
upgrade applies to all series except the Series 100.
The combinations of configurations and upgrades supported by
D_12_5_0 are shown in Table 1.
Table 1 Configurations and Upgrades Supported by D_12_5_0
R September 1991 1\f
Rational Environment Release Information
----------------------------------------
| | | | | |
| | 8-mm |9-Track|32-Mb | 64-Mb|
|Configura| Tape | Tape |Memory| Memory|
| tion | Drive | Drive | | |
----------------------------------------
| | | | | |
|Series |N/A |Standar|Standa| N/A |
|100 | |d | rd | |
----------------------------------------
| | | | | |
|Series |Upgrade|Standar|Standa| Upgrad|
|200 | |d | rd | |
----------------------------------------
| | | | | |
|Series |Standar|Upgrade|Standa| Upgrad|
|300S |d | | rd | |
----------------------------------------
| | | | | |
|Series |Standar|N/A |Standa| Upgrad|
|300C |d | | rd | |
----------------------------------------
| | | | | |
|Series |Standar|N/A |Standa| Upgrad|
|400S |d | | rd | |
----------------------------------------
| | | | | |
|Series |Standar|N/A |Standa| Upgrad|
|400C |d | | rd | |
----------------------------------------
3. Compatibility
D_12_5_0 is fully compatible with all production versions of
Rational layered software products:
Design Facility: 2167 6_0_7 or later
Design Facility: 2167A 6_2_5 or later
Documentation Tools 10_2_9 or later
Design Tools 10_2_9 or later
Rational Teamwork Interface 2_1_2 or later
Rational Publishing Interface 1_0_2 or later
CDF: Mc68020_Bare 5_1_2 or later
CDF: Mc68020_Os2000 6_1_3 or later
CDF: Mc68020_Hp_Unix 6_2_4 or later
Remote Compilation Facility 3_2_0 or later
RCF: Rs6000_Aix_Ibm 3_2_0 or later
Target Build Utility 10_0_3 or later
2 September 1991 R\f
Release D_12_5_0
RPC 1_0_2 or later
Software Analysis Workstation 6_0_0 or later
Mail 11_4_5 or later
Rational X Interface 10_5_2 or later
4. Upgrade Impact
The Environment can be upgraded from D_12_1_1 to D_12_5_0 without
forcing you to Archive.Save and Archive.Restore your
applications. You will not have to modify or recompile any of
your own tools, with the possible exception of:
* Tools written against the unit specifications listed in
"Impact of Specification Changes," below.
* Customizations of the unit bodies listed in "Impact of
Implementation Changes," below.
The new declarations listed in section 6 are all installed
upward-compatibly and therefore have no impact on user-written
tools.
Once upgraded to D_12_5_0, a system cannot be reverted to a
previous Environment release.
4.1. Impact of Specification Changes
The installation process for D_12_5_0 overwrites several
Environment unit specifications. Overwriting these specifications
causes the demotion of any customer-created tools written against
them. The installation process tries to recompile such tools
automatically; however, depending on the nature of the tools,
some may require modification before they can be recompiled.
Units that cannot be recompiled during installation are listed in
the installation log.
Following are the unit specifications that are overwritten when
D_12_5_0 is installed:
* !Commands.Abbreviations.Print'Spec (see section 7.12.2).
* !Implementation.Work_Order_Implementation'Spec (see section
7.20.5). Note that the changes to this unit affect only tools
that were created under D_12_1_1 or earlier releases; tools
created under D_12_2_4 are not affected.
Furthermore, the units !Machine.Initialize@ are either demoted or
moved to other locations to accommodate the new mechanisms for
initializing an R1000 (see section 9).
R September 1991 3\f
Rational Environment Release Information
4.2. Impact of Implementation Changes
The installation process for D_12_5_0 overwrites one unit body.
Because this body may contain user customizations, its contents
are saved in a text file in the same library as the overwritten
body. The name of the file is of the form Unit_Name_Vnn, where nn
is the unit's default version number. The customizations then can
be transferred to the new implementation.
Following is the unit whose body is overwritten when D_12_5_0 is
installed:
* !Commands.Abbreviations.Print'Body (see section 7.12.2).
5. Known Problems
5.1. Problem in Spelling Checker
The D_12_5_0 release of the Environment affects the spelling
checker. Specifically, one-character words that are not
explicitly added to a dictionary are now flagged as suspicious
spellings. To minimize the impact of this change, the
installation process adds the one-letter words "I," "A," and "a"
to the master dictionary.
For example, in the following text, the spelling checker
reports "e" and "g" as suspicious spellings:
Pick two prime numbers less than 20 (e.g., 11 and 17).
5.2. Problem for CDF Customization
The D_12_5_0 release of the Environment affects the installation
of customizations of the Mc68020_Bare CDF. Specifically, you will
not be able to install new or changed customizations without
first making a minor change to the following package body:
!Targets.Implementation.Motorola_68k_Target_Download.Exos5_0_1.
Units.-
Exos_Operations'Body
As delivered, this package cannot be promoted to the coded state
on a D_12_5_0 system because of changes made to the Environment's
compilation system that enable it to comply with validation.
Existing customizations are not affected by the problem unless
this package is demoted and an attempt is made to repromote it.
The change you need to make to the Exos_Operations'Body follows:
1. Locate the line that is indicated by >>> in the following
excerpt (this is line 126 in the unit):
4 September 1991 R\f
Release D_12_5_0
type Message_Buffer is
record
Msg_Header : Message_Header;
>>> Data : Machine_Defs.Byte_String (1 .. Natural (Max_Message_Length));
end record;
2. Replace the indicated line with the line below:
Data : Machine_Defs.Byte_String (1 .. Max_Message_Length);
Attempting to promote the package body without making this change
will cause two lines to be flagged with errors. You should leave
these lines unchanged; change only the line indicated in step 1
above.
6. New Environment Interfaces
D_12_5_0 provides a number of new interfaces, including:
* New procedures and functions; see sections 6.1, 6.2, 6.3, and
6.4
* New packages; see section 6.5, 6.6, and 6.7
* New networking features; see section 6.8
* New subsystems; see sections 6.9 and 6.10
6.1. New Procedures in Package Access_List
6.1.1. Procedure Remove
procedure Remove (Group : String := ">>SIMPLE NAME<<";
For_Object : Name := "<SELECTION>";
Response : String := "<PROFILE>");
Removes the specified group from the access list of each of the
specified objects.
6.1.2. Procedure Remove_Default
procedure Remove_Default (Group : String := ">>SIMPLE
NAME<<";
For_World : Name := "<SELECTION>";
Response : String := "<PROFILE>");
Removes the specified group from the default access list of each
of the specified worlds.
R September 1991 5\f
Rational Environment Release Information
6.2. New Procedures in !Commands.Abbreviations
The procedures in the following paragraphs allow easy reference
to networked printers. These procedures are sensitive to the new
printer-configuration mechanism described in section 9.5. If this
mechanism is not in use at your site, you should use the
Queue.Cancel, Queue.Display, and Queue.Print commands instead of
the commands described below.
6.2.1. Procedure Cancel_Print_Request
procedure Cancel_Print_Request (Printer : String :=
"<Default>";
Request_Id : Positive);
Removes the specified print request from the queue of the
specified printer.
The Printer parameter accepts any printer name that has been
defined in the printer-configuration files (see section 9.5). By
default, the parameter specifies the printer name that is
associated with the user who enters the command (this association
is established using a user-printer map).
You can obtain a print request's number from the display
generated by the Display_Queue procedure.
6.2.2. Procedure Display_Queue
procedure Display_Queue (Printer : String := "<Default>");
Displays the print requests currently queued on the specified
printer.
The display shows the identification number for each request. The
identification number can be specified as the Request_Id
parameter when using the Cancel_Print_Request command.
The Printer parameter accepts any printer name that has been
defined in the printer-configuration files (see section 9.5). By
default, the parameter specifies the printer name that is
associated with the user who enters the command (this association
is established using a user-printer map).
6.2.3. Procedure Print
procedure Print (Object_Or_Image : String := "<CURSOR>";
From_First_Page : Positive := 1;
To_Last_Page : Positive := 3000;
Display_As_Twoup : Boolean := True;
6 September 1991 R\f
Release D_12_5_0
Display_Border : Boolean := True;
Display_Filename : Boolean := True;
Display_Date : Boolean := True;
Ignore_Display_Parameters_For_Postscript :
Boolean := True;
Highlight_Reserved_Words_For_Ada :
Boolean := True;
Other_Options : String := "";
Number_Of_Copies : Positive := 1;
Printer : String := "<Default>";
Effort_Only : Boolean := False);
Prints one or more objects or images, including PostScript
files, plain text files, Ada units, mail messages, command logs,
and so on. By default, this command prints the object or image
indicated by the cursor.
The print request initiated by this command is directed to the
device specified by the Printer parameter. By default, the
command uses the device that is associated with the user who
entered the command. This association is set up by the system
manager in a user-printer map.
You can use the Print command's parameters to control various
characteristics of the print job. These parameters correspond to
one or more options that are defined by the Queue.Print command.
See the comments in the command specification for details about
the parameters.
6.3. New Procedures in System_Maintenance Subsystem
!Commands.System_Maintenance'Spec_View contains the new
procedures described in the following paragraphs.
6.3.1. Procedure Analyze_Disks_For_Backup
Locates and checks for corrupt data on disks. This procedure must
be used only by Rational personnel or under their direction. For
a detailed description, see the specification of this procedure.
The fully qualified name of this procedure is:
!Commands.System_Maintenance'Spec_View.Units.Analyze_Disks_For_
Backup
R September 1991 7\f
Rational Environment Release Information
6.3.2. Procedure Destroy_Library
procedure Destroy_Library (Existing : String := ">>OBJECT To Destroy<<";
Effort_Only : Boolean := True;
Response : String := "<PROFILE>");
Deletes a library regardless of its contents. This procedure is
useful for:
* Removing the home worlds of deleted users
* Removing any large libraries that may contain subsystems
No special capability is required to use this command. You must
have D access to a world in order to delete it.
Warning: The actions of this command are not reversible. To avoid
unintended deletions, you can execute this command first with
Effort_Only set to True and verify that the resulting list
contains only the objects you want to delete.
The fully qualified name of this procedure is:
!Commands.System_Maintenance'Spec_View.Units.Destroy_Library
6.3.3. Procedure Monitor_Performance
procedure Monitor_Performance
(Max_Samples : Natural := 500;
Sample_Interval : Duration := 60.0 * 12;
Output_File : String := ">>filename<<";
Append_To_File : Boolean := False;
Header : String := "Performance data");
Provides system performance statistics.
This procedure monitors system performance at a global level by
taking the specified number of samples, one sample per specified
interval, and writing the output to Output_File. If
Append_To_File is True, data is appended to the end of the file;
otherwise, the file is overwritten. The Header string is entered
in the file before the reported data.
The output file contains one entry per line, where each entry has
fields containing the information shown in Table 2.
Table 2 Fields in Entries of Output Files
8 September 1991 R\f
Release D_12_5_0
----------------------------------------------
| | |
|Field| Information |
----------------------------------------------
| | |
|Time |Time that the entry is written. |
----------------------------------------------
| | |
|Cpu |CPU % used during the sample interval. |
| |If the load is high, this number will be|
| |very inflated because it must be |
| |computed. Values greater than 100% are |
| |common under high loads, so this value |
| |must be considered approximate. |
----------------------------------------------
| | |
|DiskW|Number of disk waits in this sample. |
| |Roughly, the number of disk transfers, |
| |which is a function of the number of |
| |page faults. |
----------------------------------------------
| | |
|Users|Number of users logged on at the end of |
| |the interval. |
----------------------------------------------
| | |
|Jobs |Number of jobs running at the end of the|
| |interval. |
----------------------------------------------
| | |
|Jobs_|Number of jobs that terminated during |
|T |the interval. Indicates the level of |
| |command activity. |
----------------------------------------------
| | |
|Load1|CPU run load for last 15 min. |
|5 | |
----------------------------------------------
| | |
|Disk1|Disk load for last 15 min. |
|5 | |
----------------------------------------------
| | |
|Whld1|Withheld task load for last 15 min. |
|5 | |
----------------------------------------------
The fully qualified name of this procedure is:
!Commands.System_Maintenance'Spec_View.Units.Monitor_Performance
R September 1991 9\f
Rational Environment Release Information
6.3.4. Procedure Repair_Cg_Attrs
Reclaims disk space by removing lost objects that were produced
and not properly deleted by the code generator in previous
Environment releases (D_12_5_0 fixes this problem). You should
execute this command once after installation of D_12_5_0 is
complete.
The Repair_Cg_Attrs command marks the objects for removal. Their
disk space is reclaimed the next time normal disk collection
runs.
Note that:
* You can execute the Repair_Cg_Attrs command whether or not
users are logged in.
* You must belong to the Privileged group to execute this
command.
* The amount of time required by this command depends on the
number of objects to be traversed. In Rational's experience,
this command takes from 1 to 4 hours.
* The amount of disk space that is freed increases with the
length of time the system has been in use since initial
installation. More specifically, the amount of freed disk
space increases with the number of coding operations that have
been performed on unit specifications since installation.
The fully qualified name of this procedure is:
!Commands.System_Maintenance'Spec_View.Units.Repair_Cg_Attrs
6.4. New Functions in Package Work_Order_Implementation
Package !Implementation.Work_Order_Implementation contains two
new functions:
function Create_User_Name (The_Order : Work_Order_Handle) return
String;
function Close_User_Name (The_Order : Work_Order_Handle) return
String;
This package also contains a changed declaration; see section
7.20.5.
These changes and additions to Work_Order_Implementation were
previously available to users of Series 400S and 400C through the
D_12_2_4 release of the Environment.
10 September 1991 R\f
Release D_12_5_0
6.5. Package Remote_Passwords
Package !Commands.Remote_Passwords provides encrypted password
storage for efficient access to other systems from an R1000. In
previous Environment releases, this package was called
!Tools.Dtia_Rpc_Mechanisms'Spec_View.Units.Remote_Passwords and
was available only with selected optional products.
This package can be used to add, change, or delete entries in a
remote-passwords file, which is a text file that specifies the
usernames and passwords to be used when accessing remote hosts.
The commands in this package provide a convenient alternative to
locating the file in the library hierarchy and then editing it
directly. Furthermore, the commands in this package provide a way
to encrypt the passwords listed in the file.
6.6. Package Transport_Name.Service
Package !Tools.Networking.Transport_Name.Service exports
subprograms that programmers can use to translate a service name
and a machine name to a Transport_Defs.Network_Name and
Transport_Defs.Socket_Id.
This tool is intended for implementing software that forms
network client-server connections; it supports reconfiguration of
the Socket_Id that identifies the server without modifying client
or server software.
6.7. Package Transport.Route
Package !Tools.Networking.Transport.Route provides an abstract
interface to the routing table, which contains gateways and the
destinations that can be reached through them. This routing table
is used by Rational Networking for routing transport-level
datagrams.
Package Transport.Route provides a programmatic interface to the
routing table. In contrast, package
!Tools.Networking.Transport_Route provides a command interface to
it. In fact, package Transport_Route is a further layer of
abstraction on package Transport.Route.
6.8. IP Subnetting
Rational Networking supports IP subnetting as defined in RFC 950,
"Internet Standard Subnetting Procedure." IP subnetting is
supported only on the R1000 Series 400 (and not the Series 100,
200, or 300). Note that IP subnetting is different from IP
routing, which is supported in all releases of Rational
Networking in all series of R1000. For general information on
this technology, refer to RFC 950 or Internetworking with TCP/IP
R September 1991 11\f
Rational Environment Release Information
by Douglas Comer.
To configure a Series 400 for IP subnetting, you:
1. Create a text file called !Machine.Tcp_Ip_Subnet_Mask.
2. Enter into the file an IP address, in decimal-dotted notation,
in which every bit of the network number or subnet number of
this machine is 1, and all other bits (the host number of this
machine) are 0.
For example, the following commands can be used to configure a
Series 400 to operate in a class B network (in which the
network number is represented in the first 16 bits of the IP
address) with a subnet number represented in the 4 bits
immediately following the network number:
Log.Set_Output ("!Machine.Tcp_Ip_Subnet_Mask");
Io.Put_Line ("255.255.240.0"); -- 240 = 2#11110000#
Log.Reset_Output;
3. Execute !Tools.Networking.Tcp_Ip_Boot to make the
configuration take effect. This command is normally executed
when booting the Environment, but you can execute it at any
time in the Series 400.
Because Tcp_Ip_Boot abruptly disconnects any TCP/IP
connections and Telnet logins that presently exist, it is
recommended that you execute Tcp_Ip_Boot from an RS232 login
port or from the console command interpreter, with all Telnet
users logged out.
After Tcp_Ip_Boot has executed, the Series 400 will endeavor to
route IP datagrams to machines whose IP addresses differ from its
own in any of the bits of the Subnet_Mask.
IP subnetting fails in either of the following cases:
* Tcp_Ip_Boot could not read a mask from
!Machine.Tcp_Ip_Subnet_Mask.
* You attempt to install subnetting on an R1000 Series 100, 200,
or 300.
6.9. Math_Support Subsystem
A new subsystem, called !Tools.Math_Support, contains an
implementation of the two proposed secondary standards developed
by the ISO-IEC/JTC1/SC22/WG9 (Ada) Numerics Rapporteur Group.
These standards provide various elementary mathematical
functions, implemented for the R1000 target and for use with
Rational M68K Cross-Development Facilities.
12 September 1991 R\f
Release D_12_5_0
For more information about this subsystem, see the notes provided
in the subsystem itself.
6.10. Dfs Subsystem
A new subsystem, called !Machine.Dfs, contains procedures and a
package for managing Diagnostic File System (DFS) information.
The paragraph below describes a procedure of particular use to
system managers. See also section 7.14 for descriptions of DFS
changes.
6.10.1. Procedure Analyze_Crashdump
procedure Analyze_Crashdump
(Tape_Drive : Natural := 0;
Expunge : Boolean := True;
Output_File : String :=
"!Machine.Error_Logs.Crash_Summary";
Working_Directory : String :=
"!Machine.Temporary.Crash_Info";
Read_Tape : Boolean := True;
Ask_To_Read_Memory : Boolean := True;
Volume : Natural := 0);
Analyzes a crash-dump tape and produces a textual summary that
can be sent to Rational for analysis. This summary is especially
useful at secure sites, because it can be sent to Rational
instead of the crash-dump tape.
The fully qualified name of this command is:
!Machine.Dfs'Spec_View.Units.Analyze_Crashdump
7. Changes from D_12_1_1
This section describes the changes, enhancements, and
user-visible problem fixes that D_12_5_0 makes to existing
features of the Environment. The information in this section is
presented in roughly the same order in which it would be found in
the Rational Environment Reference Manual:
* General editing and screen operations (EI); see section 7.1
* Editing specific types of objects such as Ada units and
command windows (EST); see section 7.2
* Debugger information (DEB); see section 7.3
* Information on session and job management (SJM)-specifically,
session switches; see section 7.4
* Library-management information (LM), including changes to
access control (see section 7.5), library switches (7.8),
R September 1991 13\f
Rational Environment Release Information
links (7.6), compilation (7.7), and archive (7.9)
* String Tools (ST) and Programming Tools (PT); see section 7.10
* System-management information (SMU), including changes to
package Operator (see section 7.11), printing (7.12),
initializing an R1000 (7.13), the diagnostic file system (DFS)
(7.14), procedures in System_Availability (7.15), procedures
in System_Maintenance (7.16), the boot process (7.17), system
backup (7.18), and miscellaneous features (7.19)
* Information about subsystems and CMVC (PM); see section 7.20
Following these are sections about Environment changes that
pertain to networking; see section 7.21.
7.1. Editor Changes
When overwrite mode is on, Procedure Editor.Character.Delete now
replaces a character with a blank space instead of deleting it.
Editor.Character.Delete is typically bound to the [Delete] or
[Backspace] key.
A problem was fixed so that control characters copied from other
windows using RXI or RWI are properly inverted.
7.2. Changes to Package Common
The Common.Object.Delete procedure, when applied to a subsystem
or view, now generates a command window containing an appropriate
deletion command. This procedure is typically bound to the
[Object] - [D] key combination.
The Common.Definition command, when used in a debugger window,
now uses the value of <CURSOR> if there is no selection in that
window. Also, the In_Place parameter to Definition is no longer
ignored in a debugger window.
7.3. Changes to Debugging
7.3.1. Setting Breakpoints
The Debug.Break command is now able to set breakpoints properly
at nested accept statements.
The Debug.Break command now works correctly in all cases in
generic formal procedures.
The Debug.Break command in the R1000 debugger now allows two
breakpoints to be taken at the same location in a generic, such
that one Break command specifies the generic and the other
14 September 1991 R\f
Release D_12_5_0
specifies a specific instantiation.
The R1000 debugger now reports all actions pertaining to a given
location. In this respect, the R1000 debugger and CDF debuggers
now behave the same. In particular:
* If more than one break is set at the same location, then all
applicable breaks are now reported to the user when that
location is encountered.
* If you use Debug.Run to step your program to a location at
which a breakpoint is set (including a temporary breakpoint),
the R1000 debugger now reports both the step and the
breakpoint to the user.
7.3.2. Displaying Values
The Debug.Put command was changed so that if special-type image
functions return an object image containing Ascii.Lf's, all lines
in the image are indented the same amount by the debugger.
Consequently, image functions can be written without concern for
the depth of the subobjects they display within the largest
object displayed by the Put command.
The Debug.Put command was changed so that predefined special-type
image functions no longer raise exceptions when applied to
uninitialized data.
The Debug.Put command now works correctly with variables in
generic formal procedures in all cases.
7.3.3. Quitting While the Debugger Is Running
A workaround now exists for the following situation. In some
circumstances, if you quit your session while a job under control
of the debugger is running, your session won't terminate. This
will prevent you from logging back in on the same session and
will cause other users' sessions to hang (fail to terminate) when
Quit is executed. If this situation occurs, you now can kill the
debugger using Job.Kill from another session, which will allow
your original session and all other hung sessions to terminate.
This problem arises when you enter the Quit command while a job
that was started under the debugger is actively sending output to
a window. You can avoid the problem by stopping or killing such a
job before executing Quit.
7.3.4. Other Debugger Changes
Error messages have been improved for a number of debugger
commands.
R September 1991 15\f
Rational Environment Release Information
The Common.Definition command, when used in a debugger window,
now uses the value of <CURSOR> if there is no selection in that
window. Also, the In_Place parameter to Definition is no longer
ignored in a debugger window.
Problems were fixed in debugger name resolution so that:
* Instantiation names are now resolved properly in CDF products.
This problem affected release 6_2_4 CDF compilers, but not
previous CDF products.
* Debugger commands no longer fail for instantiations of generic
functions that are given operator names (for example, "+")
The Debug.Show (State_Type => Debug.Traces) command now displays
the state of machine instruction tracing.
The Debug.Show (State_Type => Debug.Histories) command now
displays the state of machine instruction history.
The Debug.Trace and Debug.History commands now perform machine
instruction tracing and history correctly.
Performance enhancements were made to the initialization of the
R1000_Debugger subsystem, causing the R1000 to boot faster.
7.4. Changes to Session Switches
There is one new session switch:
* Speller.Allow_Underscores
Controls whether underscore characters (_) cause word breaks.
When the switch is set to False (the default), underscores
embedded in a string are treated as word breaks by the
spelling checker. When the switch is set to True, underscores
are not treated as word breaks, so that a string containing
embedded underscores is treated as a single word.
7.5. Access-Control Changes
Problems were fixed so that access lists containing seven entries
are now processed correctly. That is, commands in package
Access_List no longer raise Constraint_Error when processing ACLs
with seven entries.
Changing the ACL of an object no longer changes the last update
timestamp on that object.
Access-list compaction now removes groups that were deleted from
access lists stored in Cmvc_Access_Control databases.
16 September 1991 R\f
Release D_12_5_0
7.6. Changes to Links Management
The Links.Edit, Links.Add, and Links.Delete commands now observe
ACL restrictions.
7.7. Compilation Changes
A code-generator problem was fixed so that promoting unit
specifications (and certain other units) to the coded state no
longer generates lost objects that consume disk space. That is,
the hidden objects that are generated during coding are now
automatically deleted when the operation is complete. You can
remove the lost objects that accumulated under previous
Environment releases, thereby freeing significant amounts of disk
space (see section 6.3.4).
The D_12_5_0 release of the Environment contains a number of
fixes for problems that formerly prevented units from being
installed, coded, or executed. These fixes are listed in sections
7.7.1, 7.7.2, and 7.7.3.
7.7.1. Installing Units
A problem was fixed where a library-unit generic instantiation
failed to install in a spec view if the generic contained other
instantiations in its private part.
A problem was fixed so that promote operations no longer
incorrectly demand:
* A body for a subprogram to which a pragma Interface was
applied
* A body for a package spec, all of whose subprograms had a
pragma Interface applied
A problem was fixed that prevented pragma Interface from being
applied to operators.
The R1000 compiler now:
* Handles literals that are greater than 64 bits
* Computes Standard.Character'Size correctly
Improved error messages are now displayed if you try to install a
unit for a non-R1000 target whose CDF compiler is not running.
You can no longer use incremental operations to add a
representation specification or a pragma Pack to a type that had
other types derived from it.
R September 1991 17\f
Rational Environment Release Information
7.7.2. Coding Units
The Compilation.Promote and Compilation.Make commands now code
Ada units in a different order. This new coding order causes the
coding of a unit body to follow the coding of its spec more
closely, thereby minimizing the number of units that are coded
between them. This change in coding order should improve the
effectiveness of inlining in CDF compilers.
When you promote a main unit body to the coded state, its spec is
now automatically coded as well. (This corrects a problem that
was introduced in the D_12_1_1 release.) Note that no other
compilation in the world is possible while the spec (and any
other required units) is being implicitly promoted to coded,
because the program library for the enclosing world is locked.
The R1000 code generator now handles qualified, non-infix calls
to Universal_Fixed-valued operators, such as P."/"(a,b).
The R1000 code generator now performs compile-time evaluation
correctly for the following:
* Literals greater than 64 bits
* The Storage_Size attribute
* Renames of built-in operators
The R1000 code generator now successfully ignores a pragma
Interface that is encountered while the
Semantics.Ignore_Interface_Pragmas switch is set to True.
Pragma Pack no longer causes a Write_To_Read_Only_Page exception
when applied to a record or to an array type that is introduced
in a private part and completed in a body.
A problem was fixed in which promoting main programs to the coded
state caused deadlocks in the dependency database.
A problem was fixed so that CDF debuggers no longer lose the
correspondence between code locations and Ada source locations
when debugging instantiations of macro-expanded library units.
A problem was fixed that caused certain main programs to fail to
code (and command windows to fail to promote) with the message
Unsatisfiable import requirement. This problem arose for main
programs and commands that withed units from code views in
secondary subsystems, where these code views referenced generics
defined outside subsystems. In D_12_5_0, such coding/promotion
now succeeds, generating a lengthy warning message that is
relevant only if coding fails for some other reason.
Non-R1000 code generators now refuse to promote a main program
whose closure contains a package for which a body is optional, if
a body for that package exists and is not in the coded state.
18 September 1991 R\f
Release D_12_5_0
7.7.3. Executing Units
The R1000 code generator now emits correct code so that
multidimensional array aggregates with string-literal
subaggregates no longer fail at execution time.
The R1000 code generator now correctly computes the Storage_Size
attribute of access types for which a Storage_Size representation
specification has been given.
A problem was fixed that caused very large (usually
machine-generated) programs to fail at run time with a variety of
errors. These programs are "very large" in that they contain more
than 1,024 references to units (if compiled with the
Retain_Delta1_Compatibility switch set to True) or to individual
declarations (if compiled with this switch set to False).
A problem was fixed that caused Type_Error to be raised by
renames of function-valued attributes (such as 'Pos or 'Val) when
used inside a function.
7.8. Library Switches
You must now enable privileges to use the Switches.Associate
command to change the associations of switch files within
subsystems.
7.9. Archive Changes
The Archive.Restore and Archive.List commands no longer crash the
R1000 when you use them to restore or read a multireel archive.
The Archive.Restore command no longer fails with a layout error.
The Archive.Restore command no longer causes the R1000 to run out
of action IDs, for example, when a large number of empty files
are restored.
The Archive.Save and Archive.Restore commands are now able to
save/restore work orders of any size.
The Archive.Restore command now processes switch-file
associations consistently with renaming introduced by the
For_Prefix and Use_Prefix parameters.
The Archive.Restore and Archive.Copy commands now produce
improved error messages.
When the Device parameter of the Archive.Save command specifies a
library name and that library does not exist, a world is created
outside a subsystem and a directory is created inside a
subsystem. Previously, directories were always created.
R September 1991 19\f
Rational Environment Release Information
Problems were fixed so that data containing newlines and
formfeeds is now saved and restored consistently. Previously,
such restored data caused CMVC to report inconsistencies in its
database.
7.9.1. Archiving Units with Large CDBs
Archive commands no longer fail when saving, restoring, or
copying Ada units whose compatibility database (CDB) signatures
are very large. It should now be possible to successfully save,
restore, or copy Ada units regardless of the size of their CDB
signatures.
Note, however, that an Ada unit that can be saved only on a
D_12_5_0 Environment must be restored onto a D_12_5_0 (or later)
Environment. Attempting to restore such a unit onto an earlier
Environment causes the following message to be displayed:
INTERNAL ERROR (declaration mapping): ARCHIVE_IS_BAD
restoring the !subsystem.view.Units.unit
7.9.2. Archive Options
The After option of the Archive.Save command now works correctly.
The Archive.Save, Archive.Restore, and Archive.List commands now
accept the following new option:
* Unload
A Boolean option. When True (the default), causes the tape to
be rewound and unloaded after the operation is complete.
When False, this option causes the tape to be rewound to the
beginning and to remain online and available for subsequent
requests. This is useful when you want to perform a list
operation followed by a restore operation, or if you want to
perform several restore operations in a row. Note that,
because the tape is rewound, successive save operations will
overwrite each other.
When the tape is left online, subsequent requests send a
tape-mount request to the operator's console, which must be
answered before the tape can be accessed.
The Archive.Save command now accepts the following new option:
* Starting_At = time
Delays the save operation until the specified time, which can
be a date, a time of day, or both, and can be written in any
of the styles defined by the !Tools.Time_Utilities.Date_Format
type and the !Tools.Time_Utilities.Time_Format type. The save
20 September 1991 R\f
Release D_12_5_0
operation starts only if the tape-mount request has been
answered.
7.10. Changes to String Tools and Programming Tools
The implementation of package !Tools.Unbounded_String has been
modified to improve its free-space management and performance
characteristics. This should noticeably improve the performance
of the Compose tool and RDF document generation.
The implementations of packages !Tools.Set_Generic and
!Tools.Map_Generic have been modified to improve their free-space
management and performance characteristics.
7.11. Changes to Package Operator
The Operator.Add_To_Group command now permits naming expressions
to be used in the User and Group parameters. In particular, you
can now use wildcards, set notation, and indirect files to
reference multiple user and group names. In both parameters, you
can use expressions that resolve to simple names; the expressions
are automatically evaluated in the proper context. For example:
Operator.Add_To_Group
("[Phil,Vicki,Anderson]","Project_7_@");
The Operator.Cancel_Shutdown command now sends a message
informing users that shutdown is canceled.
The Operator.Create_Group command now issues an error message
when no more groups can be created. In previous releases, the job
would "hang" and the system would go into wait service.
The Operator.Delete_Group command can no longer be used to delete
predefined groups (such as Operator and Privileged).
The Operator.Delete_User command can no longer be used to delete
predefined users (such as Operator).
The Operator.Delete_User command now generates a message in the
error log.
The Operator.Remove_From_Group command can no longer be used to
remove users from their own groups. For example, the following
command now fails:
Operator.Remove_From_Group ("Anderson","Anderson");
The Operator.Remove_From_Group command now permits naming
expressions to be used in the User and Group parameters. In
particular, you can now use wildcards, set notation, and indirect
files to reference multiple user and group names. In both
parameters, you can use expressions that resolve to simple names;
R September 1991 21\f
Rational Environment Release Information
the expressions are automatically evaluated in the proper
context. For example:
Operator.Remove_From_Group
("[Phil,Vicki,Anderson]","Project_7_@");
7.12. Changes Pertaining to Printing
The print spooler now properly honors pragma Page.
A new, file-driven mechanism exists for configuring printers.
This mechanism provides an alternative to using user-created
procedures that call package Queue. This mechanism also supports
the use of the !Commands.Abbreviations.Print command.
7.12.1. Change to Package Queue
The Queue.Add command now accepts the following new option, which
allows you to define a device that is a directory on a networked
workstation:
* Ftp
A Boolean option. When True, specifies that print requests be
sent via FTP to the directory and machine referenced by the
device. Each print request is sent as a separate file. Once
the files are on the other machine, you can use that machine's
print commands or tools to print the files.
When you specify the Ftp option, you must also specify the
Device parameter with the name of an R1000 file that contains,
on separate lines:
- The network name of the destination machine. The
destination machine can be any computer system, typically a
workstation.
- The full pathname of the destination directory. The
directory pathname must contain punctuation appropriate to
the destination machine, and must have trailing punctuation
that permits appending the name of the transferred
print-request file.
- A suffix to be appended to the filenames that are created
on the workstation. If no suffix is to be appended, leave a
blank line. The specified suffix can be used by print tools
as a way of identifying which files to print. This is
useful when several devices send files to the same
directory.
- The pathname of an Environment remote-passwords file. The
remote-passwords file must contain a username and password
suitable for accessing the destination machine.
22 September 1991 R\f
Release D_12_5_0
It is recommended that you place the device file and the
remote-passwords file in the !Machine.Queues.Ftp library.
7.12.2. Changes to !Commands.Abbreviations.Print
!Commands.Abbreviations.Print has a new parameter list and
implementation, so that it now:
* Is sensitive to the user-printer map and printer-configuration
file to determine what printer to go to. By default, the
command uses the device that is associated with the user who
enters the command.
* Provides parameters for specifying information normally
entered through options with Queue.Print.
* Is able to print PostScript files, plain text files, Ada
units, windows, and mailboxes.
Because the changes to this command are so significant, it is
described under "New Features" in this release note (see section
6.2).
7.13. Machine-Initialization Software
D_12_5_0 changes the software that is automatically executed by
the Environment during the boot process. The software is
reorganized to make it easier to:
* Install layered products
* Distinguish Rational-specific, site-specific, and
machine-specific customizations
* Configure a network of printers for large sites
See section 9 for a detailed explanation of these changes.
7.14. Changes to Diagnostic File System (DFS)
When an R1000 crashes, the DFS now creates a file in the DFS area
to preserve a synopsis of the machine state at the time of the
crash. The existence of this "tombstone" file allows you to
reboot the R1000 without losing all crash information. System
managers can access the crash-information file by:
* Using System_Report.Generate with Report_Type set to Outages
or to Everything
* Inspecting the system error log (the Environment boot process
now automatically copies a textual image of the last tombstone
file into the system error log)
R September 1991 23\f
Rational Environment Release Information
Crash messages have been streamlined so that irrelevant
information is suppressed.
The DFS recovery process now remembers the hardware memory
configuration. This greatly simplifies the Environment
installation process.
See also sections 6.10 and 7.15 for more information relating to
the DFS.
7.15. !Tools.System_Availability
The System_Report.Generate command now includes machine crash
information when Report_Type is set to Outages or to Everything.
The System_Report.Generate command now includes percentages of
disk space used when Report_Type is set to Daemons.
7.16. !Commands.System_Maintenance
The Set_Universe_Acls command is now more consistent with
Check_Universe_Acls.
7.17. Changes to the Boot Process
Performance enhancements were introduced to cause the R1000 boot
process to take 10 to 20 minutes less than it did in previous
releases.
The Environment boot process now automatically copies a textual
image of the last "tombstone" file into the system error log (a
tombstone file contains a synopsis of the machine state at the
time of the last crash).
7.18. Changes Pertaining to Backups
The R1000 now shuts down and reboots automatically after a tape
backup is restored. This makes disk collection work properly.
The Starting_At parameter is no longer ignored when you use
either of the following commands to take a secondary backup:
* !Commands.Abbreviations.Secondary_Backup
* !Commands.Abbreviations.Do_Backup
7.19. Miscellaneous System-Management Changes
The Shutdown and Snapshot commands have been removed from the
Kernel command interpreter on the operator's console.
24 September 1991 R\f
Release D_12_5_0
The Daemon.Quiesce command no longer raises an exception when the
Additional_Delay parameter is given the value Duration'Last.
7.20. CMVC Changes
7.20.1. Changes to Editing Activities
The activity editor now properly handles entries that refer to
nonexistent subsystems and views.
7.20.2. Changes to Package Cmvc
Various commands in package Cmvc now produce improved error
messages.
The Cmvc.Accept_Changes command now correctly accepts new
subunits into a view even when no stubs already exist in the
parent units.
The Cmvc.Build command no longer produces a Numeric_Error if the
configuration name does not contain an underscore character ( _
).
The Cmvc.Copy command now copies a source view correctly, even if
it contains units that contain insertion points.
The Cmvc.Copy command and its derivatives now preserve Delta1
compatibility when copying a view that contains a
Delta1-compatible loaded main program. (Such copy operations now
copy the underlying code database along with the
Delta1-compatible loaded main program.)
The Cmvc.Import command now reports all problems that result from
link-name conflicts. In previous releases, the command would
report only the first conflict it encountered. (A conflict arises
when units in different imported views have the same link name,
for example, because they have the same simple name.)
The Cmvc.Initial command no longer requires you to have D access
to the world in which a subsystem is created. Furthermore, the
remaining access requirements no longer have to come from a
single ACL entry, as was the case in previous releases.
The Cmvc.Join command no longer operates atomically when multiple
objects are specified. That is, individual failures no longer
cause the entire operation to be abandoned and its partial
effects undone. The command is now allowed to continue even if
one or more individual objects fail to join, and any objects that
are successfully joined remain that way.
The Cmvc.Make_Code_View command now causes links for code views
to be deleted. This reduces the likelihood of errors when code
R September 1991 25\f
Rational Environment Release Information
views are archived and restored.
The Cmvc.Make_Controlled command no longer operates atomically
when multiple objects are specified. That is, individual failures
no longer cause the entire operation to be abandoned and its
partial effects undone. The command is now allowed to continue
even if one or more individual objects cannot be made controlled;
any objects that have been made controlled remain that way. This
is particularly important when the Save_Source parameter is set
to True and some of the specified objects are binary (and
therefore incapable of being saved in the CMVC database).
The Cmvc.Make_Controlled command now echoes its parameters
correctly.
A problem was fixed so that the Cmvc.Make_Path,
Cmvc.Make_Subpath, and Cmvc.Copy commands can successfully cause
units to be promoted in the newly created views.
The Cmvc.Release command no longer fails if information is
missing from the View.State.Last_Release_Name file. The command
now uses default values to reconstruct the file, rather than
causing an error.
The Cmvc.Show_@ commands (such as Cmvc.Show_All_Uncontrolled) no
longer fail with errors when they encounter an open object. These
commands now persevere in this situation (provided that the
profile is set appropriately).
7.20.3. Changes to Package Cmvc_Maintenance
The Cmvc_Maintenance.Check_Consistency command now uses the
response characteristics specified in its Response profile.
The Cmvc.Show_Image_Of_Generation command now uses the response
characteristics specified in its Response profile.
7.20.4. Changes to Work Orders
Bugs were fixed so that using Archive.Save or Archive.Copy on
large (300 Kb to 400 Kb) work orders no longer raises
Storage_Error.
7.20.5. Spec Change in Package Work_Order_Implementation
A change has been made to package
!Implementation.Work_Order_Implementation'Spec. In particular,
the parameter list in the Work_Order_Operations.Traverse_Comments
generic procedure has been changed to fix a problem from
D_12_1_1.
26 September 1991 R\f
Release D_12_5_0
The generic procedure now has the following specification, which
provides a new parameter called User_Name:
generic
with procedure Visit (The_User : User_Id;
User_Name : String;
The_Comment : String;
The_Element : Element_Name;
The_Time : Calendar.Time);
procedure Traverse_Comments
(For_Work_Order : Work_Order_Handle; Success : out
Status);
You must recompile any tools created under the D_12_1_1
Environment release if those tools are compiled against
!Implementation.Work_Order_Implementation'Spec. Furthermore, you
may need to modify those tools to accommodate the new parameter
list.
Package Work_Order_Implementation also contains new declarations;
see section 6.4.
These changes and additions to Work_Order_Implementation were
previously available to users of Series 400S and 400C through the
D_12_2_4 release of the Environment.
7.21. Networking Changes
7.21.1. IP Routing
A default IP route is now supported for the Series 400 (which has
a CMC ENP-100i Ethernet controller). This change does not affect
the Series 100, 200, or 300 (which has an Excelan EXOS 204
Ethernet controller).
A default IP route must be defined in every Series 400 machine
(CMC ENP-100i) that uses IP routing (that is, communicates with
machines in other IP networks or subnets). Furthermore, the
default IP router must do at least one of the following when the
R1000 sends an IP datagram to it:
* Relay the datagram toward its target, or
* Send an ICMP Redirect message back to the R1000, directing it
to another IP router.
The default router must do one or both of these things for any IP
datagram targeted to any machine with which the R1000 must
communicate.
To define a default IP route, you:
R September 1991 27\f
Rational Environment Release Information
1. Add a line to !Machine.Transport_Routes that designates an IP
router, with no other text and no white space in that line.
The router can be designated by:
* Its IP address (in decimal-dotted notation), or
* A name that can be resolved to an IP address via
!Machine.Transport_Name_Map. You must use a name that is
defined in !Machine.Transport_Name_Map, because it is not
possible to communicate with the name server (the machine
designated in !Machine.Tcp_Ip_Name_Server) at the time the
name is resolved.
2. After editing (and closing) !Machine.Transport_Routes, execute
Tcp_Ip_Boot to load the default IP route into the CMC ENP-100i
Ethernet controller.
To change the default IP route:
1. Edit !Machine.Transport_Routes to designate the new default IP
router in a line with no white space and no other information
(see above).
2. Execute Transport_Route.Undefine to erase any default IP
routes that are presently defined. You can find them by
executing Transport_Route.Show.
3. After editing (and closing) !Machine.Transport_Routes, execute
Tcp_Ip_Boot to load the default IP route into the CMC ENP-100i
Ethernet controller.
You can define other, nondefault IP routes using other IP
routers, as described in package Transport_Route, but any
nondefault route that is not used for a period of 30 minutes is
likely to be deleted by the Series 400 (CMC ENP-100i), and
subsequent datagrams to which the route pertained will be
transmitted to the default IP router (until an ICMP Redirect
message is received).
If you must use a nondefault route in a Series 400, and the
default IP router cannot redirect you to it periodically, you can
define it in !Machine.Transport_Routes and then execute this
program to prevent its being deleted because of disuse:
Scheduler.Set_Job_Attribute
(System_Utilities.Get_Job,"Kind","Server");
loop
Transport_Route.Load;
delay 25 * 60.0;
end loop;
Transport_Route.Show will display a route that is deleted because
of disuse as though it were still in effect. The only way to
discover the contents of the Series 400 IP routing table is to
transmit test IP datagrams and observe (on the Ethernet) the IP
28 September 1991 R\f
Release D_12_5_0
routers to which they are relayed.
7.21.2. Miscellaneous Networking Changes
Package !Tools.Networking.Transport_Defs now contains additional
error codes.
Several problems were fixed, which occurred only with the CMC
ENP-100i Ethernet controller:
* It is now possible to receive a UDP datagram that contains
more than 1,472 bytes of user data.
In previous releases of the Environment, when a program was
executing the Transport.Receive command and waiting for UDP
datagrams, Transport.Receive would return Status =
CONNECTION_BROKEN and that connection would close upon
receiving a UDP datagram in multiple IP fragments.
* Transport.Receive now correctly returns Status NOT_OPEN if the
connection is not open. In previous releases, the Status
NOT_CONNECTED was returned.
In the Ftp.Get command, setting the Append_To_File parameter to
True no longer fails if the specified file already exists.
You can now use FTP to append data to an existing object on an
R1000, without incurring the following error:
*** Problem with local file - Problem opening local file.
*** Ftp transfer failed with status = FILE_ERROR.
++* <filename> was not retrieved.
8. Documentation
The D_12_5_0 release of the Environment includes new and updated
online help for the packages listed below. Many of these packages
have been significantly rewritten and the introductions of
important packages (such as Archive, Compilation, Profile,
Program, Remote_Passwords) now contain extensive introductory
material. Use the What.Does command to obtain online help.
The new and updated packages are listed by the volume in which
they appear in the Rational Environment Reference Manual:
* One package from the Debugging (DEB) book (Volume 3):
- Debug
* All packages from the Session and Job Management (SJM) book
(Volume 4):
- Job
R September 1991 29\f
Rational Environment Release Information
- Log
- Profile
- Program
- Remote_Passwords
- Search_List
- What
* All packages from the Library Management (LM) book (Volume 5):
- Access_List
- Access_List_Tools
- Archive
- Compilation
- File_Utilities
- Library
- Links
- Switches
- Xref
* Six packages from the System Management Utilities (SMU) book
(Volume 10):
- Message
- Operator
- Queue
- System_Backup
- Tape
- Terminal
9. Appendix A: !Machine.Initialization
D_12_5_0 changes the software that is automatically executed by
the Environment during the boot process. The software is
reorganized to make it easier to:
30 September 1991 R\f
Release D_12_5_0
* Install layered products
* Distinguish Rational-specific, site-specific, and
machine-specific customizations
* Configure a network of printers for large sites
The following subsections describe the new mechanisms for
initializing an R1000. See also the "Installation Procedure" for
specific steps to convert any existing initialization software to
the new mechanisms.
9.1. Overview
Each time an R1000 is booted, software is executed that
initializes layered products, sets various system parameters (for
example, disk-collection thresholds and snapshot intervals),
starts servers, enables terminals, and so on.
In previous Environment releases, the boot process automatically
executed !Machine.Initialize, which in turn executed a family of
procedures (with names of the form !Machine.Initialize_@).
In D_12_5_0, !Machine.Initialize is no longer used. Instead, all
system-initialization software resides in the world
!Machine.Initialization, which is structured as shown:
!Machine.Initialization : Library (World);
Local : Library (World);
Rational : Library (World);
Site : Library (World);
Start : Ada (Load_Proc);
The D_12_5_0 boot process automatically executes the Start
procedure, which in turn executes all the procedures that reside
in (or are referenced in) the Local, Rational, and Site worlds:
* The world Rational contains or references software that
initializes Rational products and provides standard settings
for many system parameters. Users should not modify the
objects in this world.
* The worlds Site and Local provide a place for system managers
to put objects that customize the initialization process. Such
objects can be used to override various standard system
parameter settings, to initialize customer-written
applications, and to specify terminal and printer
configurations:
- The world Site is intended for customer-written objects
that are common to two or more machines at a given site.
- The world Local is intended for customer-written objects
that apply only to the current R1000.
R September 1991 31\f
Rational Environment Release Information
The following subsections give more detail about these worlds.
9.1.1. World !Machine.Initialization.Rational
The Rational world contains objects supplied by Rational that
perform basic initialization services for the current R1000.
These objects include:
* Loaded main procedures that are executed by
!Machine.Initialization.Start whenever the system is booted.
* "_Start" files that reference procedures located elsewhere in
the Environment. These are text files whose names end with
_Start; the procedures they reference are executed by
!Machine.Initialization.Start.
On a typical system, this world contains objects such as the
following:
!Machine.Initialization.Rational : Library (World);
Clean_Machine_Temporary : C Load_Proc;
Cross_Compilers : C Load_Proc;
Design_Facilities : C Load_Proc;
Dtia : C Load_Proc;
Finish_Install : C Load_Proc;
Log_Previous_Outage_Start : Text;
Mail_Start : Text;
Network : C Load_Proc;
Parameters : C Load_Proc;
Printers : C Load_Proc;
Servers : C Load_Proc;
Teamwork_Interface : C Load_Proc;
Terminals : C Load_Proc;
The procedures that are supplied or referenced in this world:
* Perform cleanup and compaction
* Initialize the installed Rational products, such as CDFs, RDF,
Rational Networking, and so on
* Initialize servers, including the archive and FTP servers
* Set standard values for various system parameters, such as the
medium-term scheduler, snapshot intervals and warnings,
disk-collection thresholds, and so on
* Initialize terminals and printers according to user-specified
requirements (given in files in the Site and Local worlds)
For more specific information, you can browse the comments in
each object in this world.
32 September 1991 R\f
Release D_12_5_0
9.1.2. Worlds !Machine.Initialization.[Site,Local]
The Site and Local worlds are where system managers can create
objects to control sitewide or machine-specific initialization
and configuration. These objects may include:
* Ada procedures that supplement or override the basic
initialization services performed by objects in the Rational
world. All procedures in the Site and Local worlds are
executed by !Machine.Initialization.Start each time the system
is booted.
* "_Start" files that reference procedures located elsewhere in
the Environment. These are text files whose names end with
_Start; the procedures they reference are executed by
!Machine.Initialization.Start. Using a "_Start file" is
equivalent to calling Program.Run or Program.Run_Job to
execute the referenced procedure. (See section 9.3.2.)
* Configuration files that tell the Environment how to enable
and configure ports for login and ports for printing. These
are text files that are read by two of the procedures executed
by !Machine.Initialization.Start. A default file for enabling
login ports is created in the Local world during installation.
(See sections 9.4 and 9.5.)
* Text files that tell the Environment how to initialize layered
products such as the Cross-Development Facility or the
Rational Design Facility. (See the comments in the
specifications of the Cross_Compilers and Design_Facilities
procedures in !Machine.Initialization.Rational.)
At most sites, system managers will use the Site and/or Local
worlds as a place for procedures (or "_Start" files) that:
* Set password policy
* Set login limits
* Start server programs for site-specific networking, databases,
and applications (for example, a login monitor or network
security server)
At some sites, system managers may need to use these worlds for
procedures that:
* Provide nonstandard daemon settings, for example:
- The time at which daily and weekly clients run. (The
standard times are 3:00 a.m. for daily clients and 2:30
a.m. for weekly clients.)
- How often snapshots are taken. (The standard snapshot
interval is every 30 minutes.)
R September 1991 33\f
Rational Environment Release Information
- Whether (and when) to send a snapshot warning, snapshot
start messages, and snapshot finish messages. (The standard
is to send a warning 20 seconds before the next snapshot
and to notify users only when the snapshot has finished.)
- The interval for daemon warnings. (The standard is to send
a warning 2 minutes before the daily clients begin.)
- Whether to send disk-collection threshold warnings. (The
standard is to warn users when collection thresholds have
been passed.)
- What kinds of system log messages appear on the operator
console. (The standard is to route only warning, problem,
and fatal messages to the operator console.)
- Whether clients should perform access-list compaction. (The
standard is for all relevant clients to perform access-list
compaction.)
* Provide customized disk-collection thresholds (see also
section 9.3.4). Note, however, that values set by the
procedure in world Rational are calculated based on your disk
configuration and should be sufficient; see your Rational
technical representative if you want to use different
thresholds.
* Provide nonstandard medium-term scheduler settings. (You can
enter the Scheduler.Display command to see the standard
settings.) Note, however, that values set by the procedure in
world Rational should be sufficient; see your Rational
technical representative if you want to use different
settings.
9.2. Setting Up the Site and Local Worlds
If you have a new R1000, you can use the following guidelines to
set up your Site and Local worlds:
1. Decide whether you need to provide any system customizations
such as those listed in section 9.1.2. Create the appropriate
procedures and/or "_Start" files, using the hints given in
section 9.3.
2. Inspect the default Terminal_Configuration file that was
created in the Local world during installation. This file
enables ports 235 through 249 for login. Edit this file if you
want to enable a different set of ports and/or specify further
connection or communication information; see section 9.4.
3. Decide whether to implement a printer-configuration mechanism
to enable users to use the !Commands.Abbreviations.Print and
to facilitate the use of networked printers. Create the
appropriate files; see section 9.5.
34 September 1991 R\f
Release D_12_5_0
4. If you have layered products such as the CDF or RDF, inspect
the comments in the specifications of the Cross_Compilers and
Design_Facilities procedures in
!Machine.Initialization.Rational. Create any files required
for initializing these products (for example, a text file that
registers an RDF customization).
If you are upgrading from a previous release to D_12_5_0, the
Local world will already contain several objects that contain
customizations:
* A Terminal_Configuration file is automatically created in the
Local world that enables the same set of ports that were
enabled at the time of installation. This file also preserves
any nondefault communication characteristics that were in
effect for RS232 ports.
* The !Machine.Initialize_Site procedure is automatically moved
into the Local world, as described in the "Installation
Procedure."
After your R1000 has been upgraded, you can use the following
guidelines to set up your Site and Local worlds:
1. Inspect the Initialize_Site procedure that has been copied
into the Local world during installation. Edit this procedure
to preserve any system customizations that are still
appropriate. You may want to split this procedure into
separate procedures and move appropriate procedures into the
Site world. See the "Installation Procedure" for specific
recommendations for handling this procedure. See also section
9.3 for information about initialization procedures and
"_Start" files.
2. Inspect the default Terminal_Configuration file that was
created in the Local world during installation. Edit this file
if you want to enable a different set of ports and/or specify
further connection or communication information; see section
9.4.
3. Decide whether to implement a printer-configuration mechanism
to enable users to use the !Commands.Abbreviations.Print and
to facilitate the use of networked printers. Create the
appropriate files; see section 9.5.
4. If you have layered products such as the CDF or RDF, inspect
the comments in the specifications of the Cross_Compilers and
Design_Facilities procedures in
!Machine.Initialization.Rational. Create any files required
for initializing these products (for example, a text file that
registers an RDF customization).
R September 1991 35\f
Rational Environment Release Information
9.3. Hints for Implementing System Customizations
This section provides information about:
* Writing customized initialization procedures in the Site and
Local worlds; see section 9.3.1.
* Writing "_Start" files that reference procedures that reside
in other Environment libraries; see section 9.3.2.
* Controlling the order in which the customized initialization
procedures and the "_Start" files are processed by the Start
procedure; see section 9.3.3.
* Customizing disk-collection thresholds; see section 9.3.4.
9.3.1. Writing Customized Initialization Procedures
You can write procedures in the Site or Local worlds to implement
system customizations such as password policies, system daemon
settings, and so on. All procedures that appear in these worlds
are executed by the Start procedure each time the R1000 boots.
Customized initialization procedures can contain calls to
procedures in various standard Environment packages. Some useful
packages include:
* Package Daemon, which contains procedures that schedule
clients and warnings
* Package Operator, which contains procedures that set password
policy and login limits
* Package Scheduler, which contains procedures that control the
medium-term scheduler
* Package Program, which contains procedures that execute other
programs
Note that:
* You do not have to provide initialization procedures for
configuring login ports and printer ports; it is recommended
that you use configuration files instead (see sections 9.4 and
9.5).
* You do not have to write an initialization procedure "from
scratch" for customizing disk-collection thresholds; if you
must customize these thresholds, it is recommended that you
edit the sample initialization procedure provided in the Local
world (see section 9.3.4).
When writing customized initialization procedures:
36 September 1991 R\f
Release D_12_5_0
* You can create separate procedures or put all calls in a
single procedure. Separate procedures take longer to execute,
but make it easier to see what operations are being performed.
* You must not duplicate procedure names across the Rational,
Site, and Local worlds.
* You can specify the relative execution order of procedures
using annotations (see section 9.3.3).
9.3.2. Using "_Start" Files to Reference Initialization
Procedures
As an alternative to writing procedures directly in the Site and
Local worlds, you can create "_Start" files in one or both worlds
to reference customized initialization procedures that reside
elsewhere in the Environment. "_Start" files are processed by the
Start procedure each time the R1000 boots, and the procedures
they reference are executed.
When writing "_Start" files:
* You must choose filenames that end with _Start
* You must not duplicate filenames across the Rational, Site,
and Local worlds.
* You must use annotations to reference the procedure to be
executed, as illustrated below.
* You may use annotations to control the order in which the
Start procedure executes the referenced procedures (see
section 9.3.3).
Referencing a procedure in a world or directory. A "_Start" file
with the following contents illustrates the basic set of
annotations required to reference a procedure that resides in an
Environment world or directory:
--|Procedure_Name Initialize_Routine
--|Procedure_Context !Commands.Example
--|Parameters Notify => "manager",
--|Parameters Effort_Only => False
* The --|Procedure_Name annotation specifies the name of the
referenced procedure. If the procedure resides directly in a
library, you supply the procedure's simple name; if the
procedure resides in a package, you supply the name in the
form Package_Name.Procedure_Name.
* The --|Procedure_Context annotation specifies the Environment
world or directory that contains the referenced procedure.
R September 1991 37\f
Rational Environment Release Information
* Each of the --|Parameters annotations specifies the value to
be used for one of the procedure's parameters. Note that
string values must be enclosed in quotation marks, and commas
must be included to separate multiple parameters.
Referencing a procedure in a subsystem. A "_Start" file with the
following contents illustrates how to reference a procedure that
resides in an Environment subsystem. Note that you must replace
the --|Procedure_Context annotation with the --|Subsystem and
(optional) --|Activity annotations:
--|Procedure_Name Excelan_Boot_Server
--|Subsystem !Targets.Implementation.Motorola_68k_Download
--|Activity !Machine.Release.Current.Activity
--|No_Wait
* The --|Subsystem annotation specifies the name of the
subsystem that contains the procedure. (When this annotation
is specified, the --|Procedure_Context annotation is ignored.)
* The --|Activity annotation specifies the activity to be used
to obtain the view name and construct the full pathname of the
procedure. If you omit this annotation,
!Machine.Release.Current.Activity is used.
* Note that Excelan_Boot_Server is a parameterless procedure;
otherwise, one or more --|Parameters annotations would be
present.
* The --|No_Wait annotation permits concurrent execution (see
section 9.3.3). This annotation is present because this
procedure starts a server.
Specifying further information. "_Start" files may also contain
annotations that control the order in which the Start procedure
will execute the referenced procedures. See section 9.3.3.
Using a "_Start" file is equivalent to executing the referenced
procedure via Program.Run_Job or Program.Run. See the comments in
the specification of !Machine.Initialization.Start for additional
annotations that specify the equivalent of the Options parameter
in the Program.Run_Job procedure and the Context parameter in the
Program.Run and Program.Run_Job procedures.
9.3.3. Controlling the Order of Execution
You can specify the relative execution order of all
initialization procedures (including those referenced in "_Start"
files). To do this, you include annotations in the appropriate
procedure specifications or "_Start" files:
* To specify that procedure A cannot run until procedure B has
finished, you include the annotation --|Prerequisite B in the
specification of procedure A (or in the "_Start" file that
38 September 1991 R\f
Release D_12_5_0
references procedure A).
If procedure B is referenced in a "_Start" file, you specify
the filename as the annotation's argument: --|Prerequisite
B_Start.
Note that the argument of this annotation is a simple name and
that all three worlds (Rational, Local, and Site) are searched
for that simple name. Therefore, simple names must be unique
across these three worlds if you want to use this annotation.
* To specify that procedure A must finish before any other
procedure can start executing, you include the annotation
--|Wait in the specification of procedure A (or in the
"_Start" file that references procedure A).
Using this annotation is equivalent to executing procedure A
via Program.Run
* To specify that procedure A is to execute as a separate job
concurrent with other procedures, you include the annotation
--|No_Wait in the specification of procedure A (or in the
"_Start" file that references procedure A).
Using this annotation is equivalent to executing procedure A
via Program.Run_Job.
If none of the annotations listed above are present in a given
procedure or "_Start" file, the --|Wait annotation is assumed.
That is, procedures are executed sequentially unless told
otherwise.
If a circular dependency results from a combination of
annotations, it will be reported and ignored, so that each
procedure will run.
Note that you can execute the Start command with the Effort_Only
parameter set to True to test the execution order that results
from your annotations.
See the comments in the specification of the
!Machine.Initialization.Start procedure for a complete
description of annotation usage, along with examples.
9.3.4. Customizing Disk-Collection Thresholds
You can customize the disk-collection thresholds for the
particular needs of your site. To implement a change in your
disk-collection thresholds:
1. Create an empty Ada unit in the Local world.
2. Copy the contents of the following file into the empty Ada
unit:
R September 1991 39\f
Rational Environment Release Information
!Machine.Initialization.Local.Local_Gc_Thresholds_Sample.
3. In the Ada unit, edit the Thresholds1 and Thresholds2 arrays
to specify the desired thresholds.
4. Promote the Ada unit.
Note, however, that values set by the procedure in world Rational
are calculated based on your disk configuration and should be
sufficient; see your Rational technical representative if you
want to use different thresholds.
9.4. Enabling and Configuring Login Ports
D_12_5_0 provides a file-driven mechanism in
!Machine.Initialization for enabling and configuring ports for
login.
At the very least, you must ensure that this mechanism has enough
information to enable the desired login ports (see section
9.4.1). In addition, you may optionally use this mechanism to
specify:
* Connection and terminal-type characteristics for Telnet and
RS232 ports, such as logoff-on-disconnect,
disconnect-on-logoff, and so on
* Communication characteristics for RS232 ports, such as flow
control, parity, and so on
Such information is specified using the options described in
section 9.4.4.
9.4.1. Enabling Ports for Login
Ports for terminal devices must be enabled for login each time an
R1000 boots. Accordingly, the !Machine.Initialization.Start
procedure calls a procedure called Terminals in the Rational
world. This procedure in turn consults a file called
Terminal_Configuration in the Local world to determine which
ports to enable for login. This file-driven mechanism takes the
place of a procedure like !Machine.Initialize_Terminals, which
enables terminals via calls to the Operator.Enable_Terminal
procedure.
The Terminal_Configuration file is automatically created in the
Local world during installation:
* On a new machine, a Terminal_Configuration file is created
that enables ports 235 through 249 for login.
* On an R1000 that is being upgraded from a previous Environment
release, the Terminal_Configuration file contains entries for
40 September 1991 R\f
Release D_12_5_0
the same set of ports that were enabled at the time of
installation. (This file also preserves any nondefault
communication characteristics that were in effect for RS232
ports; see section 9.4.4.)
You can edit the Terminal_Configuration file at any time to
change which ports are enabled. The changes take effect the next
time you boot the R1000. Alternatively, you can execute the
Rational.Terminals procedure to make the changes take effect
without booting the R1000. Note that you must keep the
Terminal_Configuration file in the Local world, even if you want
to enable the same ports on all machines at a given site.
Following is a sample Terminal_Configuration file containing
basic enabling information:
16 => (Enable)
224 .. 249 => (Enable)
-- Ports 250 and 251 are for printers; disable them for login
250..251 => (Login_Disabled)
As shown, the Terminal_Configuration file consists of:
* Comments preceded with Ada comment notation (--)
* Entries of the general form: Port_Range => (Options), where:
- Port_Range can be a single port number or a range of port
numbers
- Options must be enclosed in parentheses
The options that pertain to enabling and disabling ports are
summarized in Table A-1.
------------------------------------------------------------
| | |
| Option | Description |
------------------------------------------------------------
| | |
|Enable |When specified for a given port, enables the |
| |port for login. Note that the port cannot |
| |subsequently be enabled for any other device, |
| |such as a printer. |
------------------------------------------------------------
| | |
|Login_ |When specified for a given port, prevents the |
|Disabled |port from being enabled for login-for example, |
| |by subsequent usage of the |
| |Operator.Enable_Terminal command. Note that the|
| |port can subsequently be enabled for other |
| |devices, such as printers. |
------------------------------------------------------------
R September 1991 41\f
Rational Environment Release Information
------------------------------------------------------------
| | |
| Option | Description |
------------------------------------------------------------
| | |
|Disable |When specified for a given port, disables the |
| |port for all devices. Note that the port can |
| |subsequently be enabled for any device, |
| |including login. Specifying this option is |
| |equivalent to having no entry for the port in |
| |the file. |
------------------------------------------------------------
Port 16 is always enabled for login, regardless of whether an
entry exists for it. An entry for port 16 is included in the
automatically created Terminal_Configuration file for
explicitness.
Do not assign the Enable option to any port that you plan to
enable for a printer or other device (such as a CDF). Instead,
you can assign the Login_Disabled option or the Disable option to
those ports, or you can simply omit entries for them from the
file. Assigning the Login_Disabled option is recommended if you
want to ensure that printer ports cannot be enabled for login
even if the print spooler is killed.
9.4.2. Customizing Port Characteristics
You can add information to the Terminal_Configuration file to
specify connection characteristics for RS232 ports and
communication characteristics for RS232 and Telnet ports. Such
information is specified via the options listed in section 9.4.4.
The simplest way to specify multiple options is to assign them
directly to a port or range of ports:
* Multiple options in a single entry must be enclosed by
parentheses.
* Multiple options must be separated by commas.
* The options can extend over several lines, although the entry
itself must start on a new line.
For example, the following entry assigns several connection
characteristics to ports 224..249 and then enables those ports:
224..249 => (Logoff_On_Disconnect,
Disconnect_On_Logoff,
Enable)
42 September 1991 R\f
Release D_12_5_0
You can organize recurrent sets of options and improve
readability in the Terminal_Configuration file by defining an
abbreviation for each set of options and then assigning each
abbreviation to a port or range of ports:
* Abbreviation entries are of the general form Abbreviation =
Options. Note that the equals sign (=) is used to define
abbreviations, and not the => symbol, which is used for port
assignment.
* Existing abbreviations can be nested in the definition of new
abbreviations.
For example, the following entries create the abbreviations
User_Ports and Telnet_Ports, assigning the Telnet_Ports
abbreviation to ports 224..249:
-- Port settings for user login ports
User_Ports = (Logoff_On_Disconnect, Disconnect_On_Logoff)
-- Port settings for telnet ports
Telnet_Ports = (Terminal_Type => Xrterm, User_Ports)
224..249 => (Telnet_Ports, Enable)
When adding entries to a Terminal_Configuration file, bear in
mind that:
* Nondefault communication characteristics for RS232 ports must
be set each time an R1000 boots. Consequently, if a port is to
have nondefault values for any of the options listed in Table
A-4, you must include these options in the entry for that
port. Omitting an option causes its default value to be set.
* Connection and terminal-type characteristics persist across
boots, retaining the last values that were set for them. Thus,
in principle, the options listed in Tables A-2 and A-3 need to
be set only once and then can be omitted from the
Terminal_Configuration file. However, you may choose to
include values for these options in the file to ensure that
booting the system resets them to the proper values in case
they had been changed.
* The options for each port are set in the order in which they
are assigned in the Terminal_Configuration file. Similarly,
the options in an abbreviation are set in the order in which
they are declared. If a single port number is included in the
ranges of more than one entry, that port takes the options of
the last entry in which it appears.
9.4.3. A Sample Terminal_Configuration File
The following sample file shows how a system manager can use
abbreviations to organize port information meaningfully. Note
R September 1991 43\f
Rational Environment Release Information
that a number of connection options have been explicitly set to
ensure that booting the system sets them to a known value. Note
also that specifying the Disable option for the printer ports is
not absolutely necessary; however, specifying this option ensures
that no previous entry in the file had inadvertently enabled
these ports.
-- Operator line 16 settings
Operator_Port = (~Logoff_On_Disconnect,
~Disconnect_On_Logoff,
~Login_Disabled)
-- User login port settings
User_Ports = (Logoff_On_Disconnect, Disconnect_On_Logoff,
~Login_Disabled,
~Log_Failed_Logins,
~Disconnect_On_Failed_Login,
~Disconnect_On_Disconnect)
-- Dial-in port connection settings
Dialin_Ports = (Terminal_Type => VT100,
Input_Rate => Baud_2400,
Output_Rate => Baud_2400,
Parity => None,
Bits_Per_Char => Char_8,
Stop_Bits => 1,
User_Ports)
-- Telnet port settings
Telnet_Ports = (Terminal_Type => Xrterm, User_Ports)
-- Printer port settings
Printer_Ports = (Login_Disabled)
-- Ports not in use
Unused = (Login_Disabled)
16 => (Operator_Port, Enable)
17..31 => (Dialin_Ports, Enable)
224..249 => (Telnet_Ports, Enable)
250..251 => (Disable, Printer_Ports)
252..255 => (Disable, Unused)
9.4.4. Terminal-Configuration Options
Tables A-2, A-3, and A-4 summarize the connection, terminal type,
and RS232 communication options you can specify in the
Terminal_Configuration file. These options invoke corresponding
procedures in package Terminal.
Table A-2 Boolean Options for Connection Characteristics
44 September 1991 R\f
Release D_12_5_0
------------------------------------------------------------
| | |
| Option | Description |
------------------------------------------------------------
| | |
|Disconnect_On_ |When specified for a given port, |
|Disconnect |causes the Environment to respond to |
| |an incoming disconnect signal |
| |received on that port by initiating |
| |an outgoing disconnect signal on that|
| |port. |
------------------------------------------------------------
| | |
|Disconnect_On_Failed_ |When specified for a given port, |
|Login |causes the Environment to initiate an|
| |outgoing disconnect signal on that |
| |port when a user repeatedly fails to |
| |log in on that port (for example, by |
| |repeatedly entering an incorrect |
| |password or unrecognized username). |
------------------------------------------------------------
| | |
|Disconnect_On_Logoff |When specified for a given port, |
| |causes the Environment to initiate an|
| |outgoing disconnect signal on that |
| |port when a user logs off a session |
| |running on that port. |
------------------------------------------------------------
| | |
|Log_Failed_Logins |When specified for a given port, |
| |causes the Environment to write an |
| |entry to the system error log when a |
| |user repeatedly fails to log in on |
| |that port (for example, by repeatedly|
| |entering an incorrect password or |
| |unrecognized username). |
------------------------------------------------------------
| | |
|Logoff_on_Disconnect |When specified for a given port, |
| |causes the Environment to respond to |
| |a disconnect received on that port by|
| |logging off that port's session. |
------------------------------------------------------------
Table A-3 Enumeration Option for Specifying Terminal Type
R September 1991 45\f
Rational Environment Release Information
-------------------------------------------------------------
| | |
| Option => Value | Description |
-------------------------------------------------------------
| | |
|Terminal_Type |Specifies the output driver type for a |
| |given port. Value can be any valid |
| |terminal type name, including (but not |
| |limited to): |
| |Cit500r Facit Rational Vt100 Xrterm |
-------------------------------------------------------------
Table A-4 Enumeration Options for RS232 Communication
-------------------------------------------------------------
| | | |
| |Default| |
| Option => Value | Value | Description |
-------------------------------------------------------------
| | | |
|Bits_Per_Char |Char_8 |Specifies the number of data |
| | |bits per character. Value can |
| | |be: Char_5 Char_6 Char_7 |
| | |Char_8 |
-------------------------------------------------------------
| | | |
|Flow_Control | None |Specifies software flow control |
| | |for data transmitted by the |
| | |R1000 on the specified port. |
| | |Value can be: |
| | |None Xon_Xoff Dtr Rts |
-------------------------------------------------------------
| | | |
|Input_Rate | Baud_ |Sets the incoming data rate for |
| | 9600 |a given port. Value can be: |
| | |Baud_50 Baud_75 Baud_110|
| | |Baud_134_5 Baud_150 Baud_200|
| | |Baud_300 Baud_600 |
| | |Baud_1200 |
| | |Baud_1800 Baud_2400 |
| | |Baud_9600 |
| | |Baud_19200 Disabled |
| | |Ext_Rec_Clk |
-------------------------------------------------------------
| | | |
|Output_Rate | Baud_ |Sets the outgoing data rate for |
| | 9600 |a given port. Values are the |
| | |same as for Input_Rate. |
-------------------------------------------------------------
46 September 1991 R\f
Release D_12_5_0
-------------------------------------------------------------
| | | |
| |Default| |
| Option => Value | Value | Description |
-------------------------------------------------------------
| | | |
|Parity | None |Sets the parity for transmitted |
| | |and received data on a given |
| | |port. Value can be: None Odd |
| | |Even |
-------------------------------------------------------------
| | | |
|Stop_Bits | 2 |Sets the number of stop bits for|
| | |a given port. Value is a natural|
| | |number in the range 1..2. |
-------------------------------------------------------------
| | | |
|Receive_Flow_Control| None |Specifies flow control of data |
| | |received by the R1000 on the |
| | |specified port. Value can be: |
| | |None Xon_Xoff Dtr Rts |
-------------------------------------------------------------
| | | |
|Receive_Xon_Xoff_ |(17,19)|Specifies flow-control bytes so |
|Bytes | |that the R1000 can regulate the |
| | |data it receives on the |
| | |specified port. Value is (n,m), |
| | |where n and m are natural |
| | |numbers in the range 0..255. |
-------------------------------------------------------------
| | | |
|Xon_Xoff_Bytes |(17,19)|Specifies the flow-control bytes|
| | |that the R1000 recognizes for |
| | |the specified port. Value is: |
| | |(n,m), where n and m are natural|
| | |numbers in the range 0..255. |
-------------------------------------------------------------
9.5. Configuring Printers
D_12_5_0 provides a file-driven mechanism in
!Machine.Initialization for configuring a group of networked
and/or local printers. This mechanism allows you to define a
printer name for each printer on the network and to specify how
each printer is to be accessed. Furthermore, you can also
associate a printer name with each user, so that when a given
user enters the Print command (that is,
!Commands.Abbreviations.Print), the print job will, by default,
be sent to the device that is defined by the associated printer
name.
R September 1991 47\f
Rational Environment Release Information
This new mechanism automatically adds the specified devices to
the appropriate R1000s, creates the necessary print classes on
the appropriate R1000s, and associates each class with the
specified device, thereby creating print queues. Thus, when you
use the new mechanism, you do not need to use procedures from
package Queue (such as Add, Create, Enable, and Register) to do
these things.
Existing sites can choose whether to use this new mechanism or to
continue using procedures from package Queue to configure
printers. However, because the new mechanism combines class and
machine information, it is recommended that large sites with
multiple networked printers use the new !Machine.Initialization
mechanism. Small sites with few printers connected directly to
R1000s may want to continue using package Queue.
9.5.1. Where to Specify Printer Information
Each time an R1000 boots, the !Machine.Initialization.Start
procedure calls a procedure called Printers in the Rational
world. This procedure initializes the print spooler on that R1000
based on the information in the following user-created files:
* !Machine.Initialization.Site.Printer_Configuration, which
defines a printer name for each of the devices available on
the network and specifies how each device is to be accessed. A
copy of this file must exist on all R1000s from which users
will enter the Print command and on all R1000s that will
handle print requests for the specified devices.
* !Machine.Initialization.Local.Printer_Configuration, which
defines additional printer names for additional devices
intended only for users of the current R1000.
* !Machine.Initialization.Local.User_Printer_Map, which
associates a default printer name with individual users on the
current R1000. When a user executes the Print command with the
default Printer parameter, the command looks up the user's
name and sends the print request to the corresponding printer.
At a minimum, the Print command requires that one
Printer_Configuration file exist in either the Site or Local
world. If no User_Printer_Map file exists (or if the file exists
but contains no entry for a particular user), the Print command
uses the first printer name defined in the
Site.Printer_Configuration file. If this file doesn't exist, the
first printer name defined in the Local.Printer_Configuration
file is used.
If you choose not to create any of these files, you will have to:
* Create an initialization procedure (in either the Site or
Local world) that uses package Queue to create print queues
each time the system boots.
48 September 1991 R\f
Release D_12_5_0
* Either:
- Use the Queue.Print command instead of the
!Commands.Abbreviations.Print command.
- Use the !Commands.Abbreviations.Print command, but
explicitly specify the class name for the Printer
parameter.
9.5.2. Adding Entries to a Printer_Configuration File
During installation, an empty Printer_Configuration file is
created in the Local world. After installation, you can:
* Add entries to this file to enable the use of the Print
command.
* Move this file (or create an additional file called
Printer_Configuration) in the Site world, if you need to
define sitewide printer information.
Each entry in a Printer_Configuration file defines a printer name
and specifies the characteristics of the device it represents.
Each entry must start on a new line, but the information can
extend over several lines and can include single and in-line
comments. For readability, the entries are often formatted like
command parameters.
Each entry has the general form:
Printer_Name => (Device_Type => Device_Info,
Other_Device_Characteristics,
Laser_Comm => Boolean,
Reverse_Output_Pages => Boolean,
On_Node => R1000_Name)
where:
* Printer_Name is the name by which you want to refer to a given
device in a Print command.
* Device_Type is one of the following four kinds of printer
devices:
- Direct, which specifies a printer connected to an R1000 via
direct line.
- Telnet, which specifies a printer connected to an R1000 via
Telnet.
- File, which specifies a file on an R1000 in which
print-spooler output is collected. Subsequent processing is
required to get this output printed.
R September 1991 49\f
Rational Environment Release Information
- Workstation, which specifies a directory on a remote
workstation to which print requests are sent. Such requests
are sent via FTP as individual files; from the remote
directory, they can be printed using the workstation's
print tools.
* Device_Info is further information about the device you
specified. The information depends on the type of device
specified (see the paragraphs below).
* Other_Device_Characteristics are additional entry elements,
separated by commas, that give further information about the
chosen device (see the paragraphs below).
* The Laser_Comm option, when True, specifies that printing will
be done on a laser printer. Omitting this option implies that
printing will be done on a line printer.
For Direct and Telnet devices, setting Laser_Comm to True
specifies that a laser printer is connected; for File and
Workstation devices, setting Laser_Comm to True specifies that
the collected print requests will eventually be printed on a
laser printer.
* The Reverse_Output_Pages option allows you to adjust the order
in which pages are spooled to accommodate the way your printer
stacks pages in its output tray. This option applies only if
the Laser_Comm option is set to True.
- Setting Reverse_Output_Pages to True causes the print
spooler to reverse the order of output pages, so that the
last logical page is printed first. Omitting this option is
equivalent to specifying True.
- Setting Reverse_Output_Pages to False causes the print
spooler to keep the pages of output in the order in which
they appear in the source file.
* The On_Node option specifies the network name of the R1000
that contains the print spooler for the device. Omitting this
option is equivalent to specifying the name of the current
R1000.
The following paragraphs describe printer-configuration file
entries for each of the four kinds of devices. (See also the
comments in the specification of
!Machine.Initialization.Rational.Printers.)
9.5.3. Specifying a Directly Connected Printer
To specify a printer connected to an R1000 via direct line, you
specify an entry of the following general form:
Printer_Name => (Direct => Protocol,
50 September 1991 R\f
Release D_12_5_0
Device => Terminal_n,
Laser_Comm => Boolean,
Reverse_Output_Pages => Boolean,
On_Node => R1000_Name)
where:
* Protocol specifies the printer flow control and can be either
Xon_Xoff or Dtr. See the printer manual for details.
* Terminal_n represents the RS232C port to which the printer is
connected (n is the port number). The specified port must not
be enabled for login in the Local.Terminal_Configuration file.
* The Laser_Comm option, when True, specifies that a laser
printer is connected and enables a two-way
printer-communication protocol. Omitting the option is
equivalent to specifying False, which means that a line
printer is connected.
* The Reverse_Output_Pages option allows you to adjust the order
in which pages are spooled to accommodate the way your printer
stacks pages in its output tray, as described in section
9.5.2. This option applies only if Laser_Comm is set to True.
* The On_Node option specifies the network name of the R1000 to
which the printer is directly connected. Omitting this option
is equivalent to specifying the name of the current R1000.
The following entry creates a printer name called Lp, which
represents a line printer that is directly connected to port 30
of an R1000 called Jazmo:
-- Lineprinter connected to jazmo
Lp => (Direct => Xon_Xoff,
Device => terminal_30,
On_Node => jazmo)
9.5.4. Specifying a Networked Printer
To specify a printer connected to an R1000 via Telnet, you
specify an entry of the following general form:
Printer_Name => (Telnet => Host_Name,
Device => Terminal_n,
Laser_Comm => Boolean,
Reverse_Output_Pages => Boolean,
On_Node => R1000_Name)
where:
* Host_Name is the network name of the printer.
R September 1991 51\f
Rational Environment Release Information
* Terminal_n represents the Telnet port to which the printer is
connected (n is the port number). The specified port must not
be enabled for login in the Local.Terminal_Configuration file.
* The Laser_Comm option, when True, specifies that a laser
printer is connected and enables a two-way
printer-communication protocol. Omitting the option is
equivalent to specifying False, which means that a line
printer is connected.
* The Reverse_Output_Pages option allows you to adjust the order
in which pages are spooled to accommodate the way your printer
stacks pages in its output tray, as described in section
9.5.2. This option applies only if Laser_Comm is set to True.
* The On_Node option specifies the network name of the R1000 to
which the printer is connected via Telnet. Omitting this
option is equivalent to specifying the name of the current
R1000.
The following entry creates a printer name called Dlaser, which
represents a laser printer that is connected via Telnet to port
226 of an R1000 called Roget. Because of the way this printer
stacks its output, print requests are spooled to this device with
their pages in ascending (rather than reversed) order:
-- Documentation's laser printer
Dlaser => (Telnet => doc_laser,
Device => terminal_226,
Laser_Comm,
Reverse_Output_Pages => false,
On_Node => roget)
9.5.5. Specifying an Environment File
To specify a file in which to collect print-spooler output, you
specify an entry of the following general form:
Printer_Name => (File => Environment_Pathname,
Laser_Comm => Boolean,
Reverse_Output_Pages => Boolean,
On_Node => R1000_Name)
where:
* Environment_Pathname specifies the file to which output is
written. The pathname must name a file that exists on the
R1000 named by On_Node. Note that the group Spooler must have
access to the specified file.
* The Laser_Comm option, when True, specifies that the collected
print requests will eventually be printed on a laser printer.
Omitting the option is equivalent to specifying False, which
means that a line printer will be used.
52 September 1991 R\f
Release D_12_5_0
* The Reverse_Output_Pages option allows you to adjust the order
in which pages are spooled to accommodate the way your printer
stacks pages in its output tray, as described in section
9.5.2. This option applies only if Laser_Comm is set to True.
* The On_Node option specifies the network name of the R1000 on
which the file is located. Omitting this option is equivalent
to specifying the name of the current R1000.
The following entry creates a printer name called Hold, which
represents a file on an R1000 called Logo. Low-priority print
requests are sent to this file, where they are held until someone
prints the file using the Print command (specifying a printer
name that represents a connected printer):
-- Place to hold large requests until printers are free in
the evening
Hold => (File => !Machine.Queues.Local.Held_Print_Requests,
On_Node => Logo)
9.5.6. Specifying a Workstation Directory
To specify a directory on a workstation to which print requests
are sent, you specify an entry of the following general form:
Printer_Name => (Workstation => Host_Name,
Path => Directory_Name,
Laser_Comm => Boolean,
Suffix => String,
Reverse_Output_Pages => Boolean,
On_Node => R1000_Name)
where:
* Host_Name is the network name of the workstation to which the
files will be transferred.
* Directory_Name is the pathname of the workstation directory
into which the files will be transferred. The directory
pathname must have syntax appropriate to the workstation and
must have trailing punctuation that permits the name of the
transferred print-request file to be appended.
* The Laser_Comm option, when True, specifies that the collected
print requests will eventually be printed on a laser printer.
Omitting the option is equivalent to specifying False, which
means that a line printer will be used.
* The Suffix option allows you to specify a string to be
appended to the filenames that are created on the workstation.
Omitting this option causes no suffix to be appended to the
filenames. The specified suffix can be used by print tools as
a way of identifying which files to print. This is useful when
several printer names send files to the same directory.
R September 1991 53\f
Rational Environment Release Information
* The Reverse_Output_Pages option allows you to adjust the order
in which pages are spooled to accommodate the way your printer
stacks pages in its output tray, as described in section
9.5.2. This option applies only if Laser_Comm is set to True.
* The On_Node option specifies the network name of the R1000
whose print spooler handles the print requests. Omitting this
option is equivalent to specifying the name of the current
R1000.
When print requests are sent as files to a workstation, any FTP
messages are directed to a log file that is created in
!Machine.Queues.Ftp. This log file is automatically cleared after
each 100 print requests. Messages pertaining to creating print
classes and enabling devices are directed to the system error
log.
The following two entries create printer names Dc_Laser and
Dc_Lineprinter, both of which direct print requests to a
directory on a UNIX workstation called Enterprise. These print
requests, which are routed through the print spooler on an R1000
called Capitol, are sent as files with different suffixes,
depending on the printer name (_Lsr and _Lpt, respectively):
-- Laser printer attached to workstation in Washington,
-- D.C., office;
-- spooled on R1000 called Capitol.
Dc_Laser => (Workstation => Enterprise,
Path => /usr/spool/ratqueue/,
Laser_Comm,
Suffix => _Lsr,
On_Node => Capitol)
-- Line printer attached to workstation in Washington, D.C.,
-- office;
-- spooled on R1000 called Capitol.
Dc_Lineprinter =>
(Workstation => Enterprise,
Path => /usr/spool/ratqueue/,
Suffix => _Lpt,
On_Node => Capitol)
Print tools on the workstation, such as the following sample, are
required to actually print the requests:
# This program spools print requests placed in /usr/spool/ratqueue to
# the appropriate printer based on the suffix of the spooled file.
# It checks the spool directory at five-minute intervals to see if any
# new files need printing. This runs as a C-shell script. To execute,
# type csh and the name of this file.
54 September 1991 R\f
Release D_12_5_0
:
set xFTPxDIRx=/usr/spool/ratqueue #spool directory
#
set xFTPxSUFFIXxLSRx=_Lsr # Laser printer suffix
set xFTPxSUFFIXxLPTx=_Lpt # Line printer suffix
#
set xPRINTxLISTxLSRx=/tmp/rat_print_lsr.$$ # Laser printer list file
set xPRINTxLISTxLPTx=/tmp/rat_print_lpt.$$ # Line printer list file
#
set xPRINTxCOMMANDx=/tmp/rat_command.$$ # temporary print command file
#
set xPRINTxDELAYx=120 # interval to wait before printing
set xRECHECKxTIMEx=180 # interval for checking print requests
#
cd $xFTPxDIRx
while (1 == 1)
#
# Creates a list of files to print for each printer.
#
ls $xFTPxDIRx | grep $xFTPxSUFFIXxLSRx > $xPRINTxLISTxLSRx
ls $xFTPxDIRx | grep $xFTPxSUFFIXxLPTx > $xPRINTxLISTxLPTx
#
# Adds the laser- and line-printer files to the print-command file
# (the device name of each type of printer should be provided after the -P).
#
cat $xPRINTxLISTxLSRx | sed -e 's^.^lpr -r -Plaser &^' > $xPRINTxCOMMANDx
cat $xPRINTxLISTxLPTx | sed -e 's^.^lpr -r -Pline &^' >> $xPRINTxCOMMANDx
#
# Waits the specified amount of time before printing the requests.
# (This delay allows time for the FTP operation to complete and should
# be adjusted based on the average length of files being printed.)
#
sleep $xPRINTxDELAYx
#
# Prints the files if there are any to print.
#
set LCNT=`cat $xPRINTxCOMMANDx | wc -l `
if ( $LCNT != 0 ) then
chmod +x $xPRINTxCOMMANDx
$xPRINTxCOMMANDx
endif
#
# Waits the specified amount of time.
#
R September 1991 55\f
Rational Environment Release Information
sleep $xRECHECKxTIMEx
#
# Removes the old temporary files.
#
rm $xPRINTxLISTxLSRx
rm $xPRINTxLISTxLPTx
rm $xPRINTxCOMMANDx
#
end
9.5.7. Associating Default Printers with Individual Users
To associate a default printer with each user, you must create a
file called User_Printer_Map in the Local world and add entries
of the following form:
Username Printer_Name
where:
* Username is either:
- The username for an R1000 user
- The string Others, which represents all users not
explicitly listed by name.
* Printer_Name is defined in a Printer_Configuration file.
Following is a sample User_Printer_Map file:
phil dc_laser
sue dlaser
others lp
See also the comments in the specification of
!Machine.Initialization.Rational.Printers.
56 September 1991 R\f
Release D_12_5_0
Contents
1. Overview 0
2. Supported Configurations and Upgrades 1
3. Compatibility 2
4. Upgrade Impact 3
4.1. Impact of Specification Changes 3
4.2. Impact of Implementation Changes 4
5. Known Problems 4
5.1. Problem in Spelling Checker 4
5.2. Problem for CDF Customization 4
6. New Environment Interfaces 5
6.1. New Procedures in Package Access_List 5
6.1.1. Procedure Remove 5
6.1.2. Procedure Remove_Default 5
6.2. New Procedures in !Commands.Abbreviations 6
6.2.1. Procedure Cancel_Print_Request 6
6.2.2. Procedure Display_Queue 6
6.2.3. Procedure Print 6
6.3. New Procedures in System_Maintenance Subsystem 7
6.3.1. Procedure Analyze_Disks_For_Backup 7
6.3.2. Procedure Destroy_Library 8
6.3.3. Procedure Monitor_Performance 8
6.3.4. Procedure Repair_Cg_Attrs 10
6.4. New Functions in Package Work_Order_Implementation 10
6.5. Package Remote_Passwords 11
6.6. Package Transport_Name.Service 11
6.7. Package Transport.Route 11
6.8. IP Subnetting 11
6.9. Math_Support Subsystem 12
6.10. Dfs Subsystem 13
6.10.1. Procedure Analyze_Crashdump 13
7. Changes from D_12_1_1 13
7.1. Editor Changes 14
7.2. Changes to Package Common 14
7.3. Changes to Debugging 14
7.3.1. Setting Breakpoints 14
7.3.2. Displaying Values 15
7.3.3. Quitting While the Debugger Is Running 15
7.3.4. Other Debugger Changes 15
7.4. Changes to Session Switches 16
7.5. Access-Control Changes 16
7.6. Changes to Links Management 17
7.7. Compilation Changes 17
7.7.1. Installing Units 17
7.7.2. Coding Units 18
7.7.3. Executing Units 19
7.8. Library Switches 19
7.9. Archive Changes 19
7.9.1. Archiving Units with Large CDBs 20
7.9.2. Archive Options 20
7.10. Changes to String Tools and Programming Tools 21
7.11. Changes to Package Operator 21
7.12. Changes Pertaining to Printing 22
R September 1991 iii\f
Rational Environment Release Information
7.12.1. Change to Package Queue 22
7.12.2. Changes to !Commands.Abbreviations.Print 23
7.13. Machine-Initialization Software 23
7.14. Changes to Diagnostic File System (DFS) 23
7.15. !Tools.System_Availability 24
7.16. !Commands.System_Maintenance 24
7.17. Changes to the Boot Process 24
7.18. Changes Pertaining to Backups 24
7.19. Miscellaneous System-Management Changes 24
7.20. CMVC Changes 25
7.20.1. Changes to Editing Activities 25
7.20.2. Changes to Package Cmvc 25
7.20.3. Changes to Package Cmvc_Maintenance 26
7.20.4. Changes to Work Orders 26
7.20.5. Spec Change in Package Work_Order_Implementation26
7.21. Networking Changes 27
7.21.1. IP Routing 27
7.21.2. Miscellaneous Networking Changes 29
8. Documentation 29
9. Appendix A: !Machine.Initialization 30
9.1. Overview 31
9.1.1. World !Machine.Initialization.Rational 32
9.1.2. Worlds !Machine.Initialization.[Site,Local] 33
9.2. Setting Up the Site and Local Worlds 34
9.3. Hints for Implementing System Customizations 36
9.3.1. Writing Customized Initialization Procedures 36
9.3.2. Using "_Start" Files to Reference Initialization
Procedures 37
9.3.3. Controlling the Order of Execution 38
9.3.4. Customizing Disk-Collection Thresholds 39
9.4. Enabling and Configuring Login Ports 40
9.4.1. Enabling Ports for Login 40
9.4.2. Customizing Port Characteristics 42
9.4.3. A Sample Terminal_Configuration File 43
9.4.4. Terminal-Configuration Options 44
9.5. Configuring Printers 47
9.5.1. Where to Specify Printer Information 48
9.5.2. Adding Entries to a Printer_Configuration File 49
9.5.3. Specifying a Directly Connected Printer 50
9.5.4. Specifying a Networked Printer 51
9.5.5. Specifying an Environment File 52
9.5.6. Specifying a Workstation Directory 53
9.5.7. Associating Default Printers with Individual
Users56
iv September 1991 R\f