PL/SQL Packages

Goods which are not shared are not goods. --Fernando de Rojas

This chapter shows you how to bundle related PL/SQL programming resources into a package.
The resources might include a collection of procedures or a pool of type definitions and variable
declarations. For example, a Human Resources package might contain hiring and firing
procedures. Once written, your general-purpose package is compiled, then stored in an Oracle
database, where its contents can be shared by many applications.

This chapter discusses the following topics:

What Is a PL/SQL Package?

Advantages of PL/SQL Packages
Understanding The Package Spec
Understanding The Package Body
Some Examples of Package Features
Private Versus Public Items in Packages
Overloading Packaged Subprograms
How Package STANDARD Defines the PL/SQL Environment
Overview of Product-Specific Packages

What Is a PL/SQL Package?

A package is a schema object that groups logically related PL/SQL types, items, and
subprograms. Packages usually have two parts, a specification and a body, although sometimes
the body is unnecessary. The specification (spec for short) is the interface to your applications; it
declares the types, variables, constants, exceptions, cursors, and subprograms available for use.
The body fully defines cursors and subprograms, and so implements the spec.

As Figure 9-1 shows, you can think of the spec as an operational interface and of the body as a
"black box." You can debug, enhance, or replace a package body without changing the interface
(package spec) to the package.

Figure 9-1 Package Interface

Text description of the illustration pls81013_package_interface.gif

To create packages, use the CREATE PACKAGE statement, which you can execute interactively
from SQL*Plus. Here is the syntax:

CREATE [OR REPLACE] PACKAGE package_name

[AUTHID {CURRENT_USER | DEFINER}]
{IS | AS}
[PRAGMA SERIALLY_REUSABLE;]
[collection_type_definition ...]
[record_type_definition ...]
[subtype_definition ...]
[collection_declaration ...]
[constant_declaration ...]
[exception_declaration ...]
[object_declaration ...]
[record_declaration ...]
[variable_declaration ...]
[cursor_spec ...]
[function_spec ...]
[procedure_spec ...]
[call_spec ...]
[PRAGMA RESTRICT_REFERENCES(assertions) ...]
END [package_name];

[CREATE [OR REPLACE] PACKAGE BODY package_name {IS | AS}

[PRAGMA SERIALLY_REUSABLE;]
[collection_type_definition ...]
[record_type_definition ...]
[subtype_definition ...]
[collection_declaration ...]
[constant_declaration ...]
[exception_declaration ...]
[object_declaration ...]
[record_declaration ...]
[variable_declaration ...]
[cursor_body ...]
[function_spec ...]
[procedure_spec ...]
[call_spec ...]
[BEGIN
sequence_of_statements]
END [package_name];]

The spec holds public declarations, which are visible to your application. You must declare
subprograms at the end of the spec after all other items (except pragmas that name a specific
function; such pragmas must follow the function spec).

The body holds implementation details and private declarations, which are hidden from your
application. Following the declarative part of the package body is the optional initialization part,
which typically holds statements that initialize package variables.

The AUTHID clause determines whether all the packaged subprograms execute with the privileges
of their definer (the default) or invoker, and whether their unqualified references to schema
objects are resolved in the schema of the definer or invoker. For more information, see "Invoker
Rights Versus Definer Rights".

A call spec lets you publish a Java method or external C function in the Oracle data dictionary.
The call spec publishes the routine by mapping its name, parameter types, and return type to their
SQL counterparts. To learn how to write Java call specs, see Oracle9i Java Stored Procedures
Developer's Guide. To learn how to write C call specs, see Oracle9i Application Developer's
Guide - Fundamentals.

Example of a PL/SQL Package

In the example below, you package a record type, a cursor, and two employment procedures.
Notice that the procedure hire_employee uses the database sequence empno_seq and the
function SYSDATE to insert a new employee number and hire date, respectively.

CREATE OR REPLACE PACKAGE emp_actions AS -- spec

TYPE EmpRecTyp IS RECORD (emp_id INT, salary REAL);
CURSOR desc_salary RETURN EmpRecTyp;
PROCEDURE hire_employee (
ename VARCHAR2,
job VARCHAR2,
mgr NUMBER,
sal NUMBER,
comm NUMBER,
deptno NUMBER);
PROCEDURE fire_employee (emp_id NUMBER);
END emp_actions;

CREATE OR REPLACE PACKAGE BODY emp_actions AS -- body

CURSOR desc_salary RETURN EmpRecTyp IS
SELECT empno, sal FROM emp ORDER BY sal DESC;
PROCEDURE hire_employee (
ename VARCHAR2,
job VARCHAR2,
mgr NUMBER,
sal NUMBER,
comm NUMBER,
deptno NUMBER) IS
BEGIN
INSERT INTO emp VALUES (empno_seq.NEXTVAL, ename, job,
mgr, SYSDATE, sal, comm, deptno);
END hire_employee;

PROCEDURE fire_employee (emp_id NUMBER) IS

BEGIN
DELETE FROM emp WHERE empno = emp_id;
END fire_employee;
END emp_actions;
Only the declarations in the package spec are visible and accessible to applications.
Implementation details in the package body are hidden and inaccessible. So, you can change the
body (implementation) without having to recompile calling programs.

Advantages of PL/SQL Packages

Packages offer several advantages: modularity, easier application design, information hiding,
added functionality, and better performance.

Modularity

Packages let you encapsulate logically related types, items, and subprograms in a named PL/SQL
module. Each package is easy to understand, and the interfaces between packages are simple,
clear, and well defined. This aids application development.

Easier Application Design

When designing an application, all you need initially is the interface information in the package
specs. You can code and compile a spec without its body. Then, stored subprograms that
reference the package can be compiled as well. You need not define the package bodies fully
until you are ready to complete the application.

Information Hiding

With packages, you can specify which types, items, and subprograms are public (visible and
accessible) or private (hidden and inaccessible). For example, if a package contains four
subprograms, three might be public and one private. The package hides the implementation of
the private subprogram so that only the package (not your application) is affected if the
implementation changes. This simplifies maintenance and enhancement. Also, by hiding
implementation details from users, you protect the integrity of the package.

Added Functionality

Packaged public variables and cursors persist for the duration of a session. So, they can be shared
by all subprograms that execute in the environment. Also, they allow you to maintain data across
transactions without having to store it in the database.

Better Performance

When you call a packaged subprogram for the first time, the whole package is loaded into
memory. So, later calls to related subprograms in the package require no disk I/O. Also,
packages stop cascading dependencies and thereby avoid unnecessary recompiling. For example,
if you change the implementation of a packaged function, Oracle need not recompile the calling
subprograms because they do not depend on the package body.
Understanding The Package Spec
The package spec contains public declarations. The scope of these declarations is local to your
database schema and global to the package. So, the declared items are accessible from your
application and from anywhere in the package. Figure 9-2 illustrates the scoping.

Figure 9-2 Package Scope

Text description of the illustration pls81014_package_scope.gif

The spec lists the package resources available to applications. All the information your
application needs to use the resources is in the spec. For example, the following declaration
shows that the function named fac takes one argument of type INTEGER and returns a value of
type INTEGER:

FUNCTION fac (n INTEGER) RETURN INTEGER; -- returns n!

That is all the information you need to call the function. You need not consider its underlying
implementation (whether it is iterative or recursive for example).

Only subprograms and cursors have an underlying implementation. So, if a spec declares only
types, constants, variables, exceptions, and call specs, the package body is unnecessary. Consider
the following bodiless package:

CREATE PACKAGE trans_data AS -- bodiless package

TYPE TimeRec IS RECORD (
minutes SMALLINT,
hours SMALLINT);
TYPE TransRec IS RECORD (
category VARCHAR2,
account INT,
amount REAL,
time_of TimeRec);
minimum_balance CONSTANT REAL := 10.00;
number_processed INT;
insufficient_funds EXCEPTION;
END trans_data;
The package trans_data needs no body because types, constants, variables, and exceptions do
not have an underlying implementation. Such packages let you define global variables--usable by
subprograms and database triggers--that persist throughout a session.

Referencing Package Contents

To reference the types, items, subprograms, and call specs declared within a package spec, use
dot notation, as follows:

package_name.type_name
package_name.item_name
package_name.subprogram_name
package_name.call_spec_name

You can reference package contents from database triggers, stored subprograms, 3GL
application programs, and various Oracle tools. For example, you might call the packaged
procedure hire_employee from SQL*Plus, as follows:

SQL> CALL emp_actions.hire_employee('TATE', 'CLERK', ...);

In the example below, you call the same procedure from an anonymous PL/SQL block
embedded in a Pro*C program. The actual parameters emp_name and job_title are host
variables (that is, variables declared in a host environment).

EXEC SQL EXECUTE

BEGIN
emp_actions.hire_employee(:emp_name, :job_title, ...);

Restrictions

You cannot reference remote packaged variables directly or indirectly. For example, you cannot
call the following procedure remotely because it references a packaged variable in a parameter
initialization clause:

CREATE PACKAGE random AS

seed NUMBER;
PROCEDURE initialize (starter IN NUMBER := seed, ...);

Also, inside a package, you cannot reference host variables.

Understanding The Package Body

The package body implements the package spec. That is, the package body contains the
implementation of every cursor and subprogram declared in the package spec. Keep in mind that
subprograms defined in a package body are accessible outside the package only if their specs
also appear in the package spec.

To match subprogram specs and bodies, PL/SQL does a token-by-token comparison of their
headers. So, except for white space, the headers must match word for word. Otherwise, PL/SQL
raises an exception, as the following example shows:

CREATE PACKAGE emp_actions AS

...
PROCEDURE calc_bonus (date_hired emp.hiredate%TYPE, ...);
END emp_actions;

CREATE PACKAGE BODY emp_actions AS

...
PROCEDURE calc_bonus (date_hired DATE, ...) IS
-- parameter declaration raises an exception because 'DATE'
-- does not match 'emp.hiredate%TYPE' word for word
BEGIN ... END;
END emp_actions;

The package body can also contain private declarations, which define types and items necessary
for the internal workings of the package. The scope of these declarations is local to the package
body. Therefore, the declared types and items are inaccessible except from within the package
body. Unlike a package spec, the declarative part of a package body can contain subprogram
bodies.

Following the declarative part of a package body is the optional initialization part, which
typically holds statements that initialize some of the variables previously declared in the
package.

The initialization part of a package plays a minor role because, unlike subprograms, a package
cannot be called or passed parameters. As a result, the initialization part of a package is run only
once, the first time you reference the package.

Remember, if a package spec declares only types, constants, variables, exceptions, and call
specs, the package body is unnecessary. However, the body can still be used to initialize items
declared in the package spec.

Some Examples of Package Features

Consider the package below named emp_actions. The package spec declares the following
types, items, and subprograms:

 Types EmpRecTyp and DeptRecTyp

 Cursor desc_salary
 Exception invalid_salary
 Functions hire_employee and nth_highest_salary
  Procedures fire_employee and raise_salary

After writing the package, you can develop applications that reference its types, call its
subprograms, use its cursor, and raise its exception. When you create the package, it is stored in
an Oracle database for general use.

CREATE PACKAGE emp_actions AS

/* Declare externally visible types, cursor, exception. */
TYPE EmpRecTyp IS RECORD (emp_id INT, salary REAL);
TYPE DeptRecTyp IS RECORD (dept_id INT, location VARCHAR2);
CURSOR desc_salary RETURN EmpRecTyp;
invalid_salary EXCEPTION;

/* Declare externally callable subprograms. */

FUNCTION hire_employee (
ename VARCHAR2,
job VARCHAR2,
mgr REAL,
sal REAL,
comm REAL,
deptno REAL) RETURN INT;
PROCEDURE fire_employee (emp_id INT);
PROCEDURE raise_salary (emp_id INT, grade INT, amount REAL);
FUNCTION nth_highest_salary (n INT) RETURN EmpRecTyp;
END emp_actions;

CREATE PACKAGE BODY emp_actions AS

number_hired INT; -- visible only in this package

/* Fully define cursor specified in package. */

CURSOR desc_salary RETURN EmpRecTyp IS
SELECT empno, sal FROM emp ORDER BY sal DESC;

/* Fully define subprograms specified in package. */

FUNCTION hire_employee (
ename VARCHAR2,
job VARCHAR2,
mgr REAL,
sal REAL,
comm REAL,
deptno REAL) RETURN INT IS
new_empno INT;
BEGIN
SELECT empno_seq.NEXTVAL INTO new_empno FROM dual;
INSERT INTO emp VALUES (new_empno, ename, job,
mgr, SYSDATE, sal, comm, deptno);
number_hired := number_hired + 1;
RETURN new_empno;
END hire_employee;

PROCEDURE fire_employee (emp_id INT) IS

BEGIN
DELETE FROM emp WHERE empno = emp_id;
END fire_employee;
 /* Define local function, available only inside package. */
FUNCTION sal_ok (rank INT, salary REAL) RETURN BOOLEAN IS
min_sal REAL;
max_sal REAL;
BEGIN
SELECT losal, hisal INTO min_sal, max_sal FROM salgrade
WHERE grade = rank;
RETURN (salary >= min_sal) AND (salary <= max_sal);
END sal_ok;

PROCEDURE raise_salary (emp_id INT, grade INT, amount REAL) IS

salary REAL;
BEGIN
SELECT sal INTO salary FROM emp WHERE empno = emp_id;
IF sal_ok(grade, salary + amount) THEN
UPDATE emp SET sal = sal + amount WHERE empno = emp_id;
ELSE
RAISE invalid_salary;
END IF;
END raise_salary;

FUNCTION nth_highest_salary (n INT) RETURN EmpRecTyp IS

emp_rec EmpRecTyp;
BEGIN
OPEN desc_salary;
FOR i IN 1..n LOOP
FETCH desc_salary INTO emp_rec;
END LOOP;
CLOSE desc_salary;
RETURN emp_rec;
END nth_highest_salary;

BEGIN -- initialization part starts here

INSERT INTO emp_audit VALUES (SYSDATE, USER, 'EMP_ACTIONS');
number_hired := 0;
END emp_actions;

Remember, the initialization part of a package is run just once, the first time you reference the
package. So, in the last example, only one row is inserted into the database table emp_audit.
Likewise, the variable number_hired is initialized only once.

Every time the procedure hire_employee is called, the variable number_hired is updated.
However, the count kept by number_hired is session specific. That is, the count reflects the
number of new employees processed by one user, not the number processed by all users.

In the next example, you package some typical bank transactions. Assume that debit and credit
transactions are entered after business hours through automatic teller machines, then applied to
accounts the next morning.

CREATE PACKAGE bank_transactions AS

/* Declare externally visible constant. */
 minimum_balance CONSTANT REAL := 100.00;
/* Declare externally callable procedures. */
PROCEDURE apply_transactions;
PROCEDURE enter_transaction (
acct INT,
kind CHAR,
amount REAL);
END bank_transactions;

CREATE PACKAGE BODY bank_transactions AS

/* Declare global variable to hold transaction status. */
new_status VARCHAR2(70) := 'Unknown';

/* Use forward declarations because apply_transactions

calls credit_account and debit_account, which are not
yet declared when the calls are made. */
PROCEDURE credit_account (acct INT, credit REAL);
PROCEDURE debit_account (acct INT, debit REAL);

/* Fully define procedures specified in package. */

PROCEDURE apply_transactions IS
/* Apply pending transactions in transactions table
to accounts table. Use cursor to fetch rows. */
CURSOR trans_cursor IS
SELECT acct_id, kind, amount FROM transactions
WHERE status = 'Pending'
ORDER BY time_tag
FOR UPDATE OF status; -- to lock rows
BEGIN
FOR trans IN trans_cursor LOOP
IF trans.kind = 'D' THEN
debit_account(trans.acct_id, trans.amount);
ELSIF trans.kind = 'C' THEN
credit_account(trans.acct_id, trans.amount);
ELSE
new_status := 'Rejected';
END IF;
UPDATE transactions SET status = new_status
WHERE CURRENT OF trans_cursor;
END LOOP;
END apply_transactions;

PROCEDURE enter_transaction (
/* Add a transaction to transactions table. */
acct INT,
kind CHAR,
amount REAL) IS
BEGIN
INSERT INTO transactions
VALUES (acct, kind, amount, 'Pending', SYSDATE);
END enter_transaction;

/* Define local procedures, available only in package. */

PROCEDURE do_journal_entry (
/* Record transaction in journal. */
acct INT,
kind CHAR,
 new_bal REAL) IS
BEGIN
INSERT INTO journal
VALUES (acct, kind, new_bal, sysdate);
IF kind = 'D' THEN
new_status := 'Debit applied';
ELSE
new_status := 'Credit applied';
END IF;
END do_journal_entry;

PROCEDURE credit_account (acct INT, credit REAL) IS

/* Credit account unless account number is bad. */
old_balance REAL;
new_balance REAL;
BEGIN
SELECT balance INTO old_balance FROM accounts
WHERE acct_id = acct
FOR UPDATE OF balance; -- to lock the row
new_balance := old_balance + credit;
UPDATE accounts SET balance = new_balance
WHERE acct_id = acct;
do_journal_entry(acct, 'C', new_balance);
EXCEPTION
WHEN NO_DATA_FOUND THEN
new_status := 'Bad account number';
WHEN OTHERS THEN
new_status := SUBSTR(SQLERRM,1,70);
END credit_account;

PROCEDURE debit_account (acct INT, debit REAL) IS

/* Debit account unless account number is bad or
account has insufficient funds. */
old_balance REAL;
new_balance REAL;
insufficient_funds EXCEPTION;
BEGIN
SELECT balance INTO old_balance FROM accounts
WHERE acct_id = acct
FOR UPDATE OF balance; -- to lock the row
new_balance := old_balance - debit;
IF new_balance >= minimum_balance THEN
UPDATE accounts SET balance = new_balance
WHERE acct_id = acct;
do_journal_entry(acct, 'D', new_balance);
ELSE
RAISE insufficient_funds;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND THEN
new_status := 'Bad account number';
WHEN insufficient_funds THEN
new_status := 'Insufficient funds';
WHEN OTHERS THEN
new_status := SUBSTR(SQLERRM,1,70);
END debit_account;
END bank_transactions;
In this package, the initialization part is not used.

Private Versus Public Items in Packages

Look again at the package emp_actions. The package body declares a variable named
number_hired, which is initialized to zero. Unlike items declared in the spec of emp_actions,
items declared in the body are restricted to use within the package. Therefore, PL/SQL code
outside the package cannot reference the variable number_hired. Such items are called private.

However, items declared in the spec of emp_actions, such as the exception invalid_salary,
are visible outside the package. Therefore, any PL/SQL code can reference the exception
invalid_salary. Such items are called public.

When you must maintain items throughout a session or across transactions, place them in the
declarative part of the package body. For example, the value of number_hired is kept between
calls to hire_employee within the same session. The value is lost when the session ends.

If you must also make the items public, place them in the package spec. For example, the
constant minimum_balance declared in the spec of the package bank_transactions is available
for general use.

Overloading Packaged Subprograms

PL/SQL allows two or more packaged subprograms to have the same name. This option is useful
when you want a subprogram to accept similar sets of parameters that have different datatypes.
For example, the following package defines two procedures named journalize:

CREATE PACKAGE journal_entries AS

...
PROCEDURE journalize (amount REAL, trans_date VARCHAR2);
PROCEDURE journalize (amount REAL, trans_date INT);
END journal_entries;

CREATE PACKAGE BODY journal_entries AS

...
PROCEDURE journalize (amount REAL, trans_date VARCHAR2) IS
BEGIN
INSERT INTO journal
VALUES (amount, TO_DATE(trans_date, 'DD-MON-YYYY'));
END journalize;

PROCEDURE journalize (amount REAL, trans_date INT) IS

BEGIN
INSERT INTO journal
VALUES (amount, TO_DATE(trans_date, 'J'));
END journalize;
END journal_entries;
The first procedure accepts trans_date as a character string, while the second procedure accepts
it as a number (the Julian day). Each procedure handles the data appropriately. For the rules that
apply to overloaded subprograms, see "Overloading Subprogram Names".

How Package STANDARD Defines the PL/SQL

Environment
A package named STANDARD defines the PL/SQL environment. The package spec globally
declares types, exceptions, and subprograms, which are available automatically to PL/SQL
programs. For example, package STANDARD declares function ABS, which returns the absolute
value of its argument, as follows:

FUNCTION ABS (n NUMBER) RETURN NUMBER;

The contents of package STANDARD are directly visible to applications. You do not need to
qualify references to its contents by prefixing the package name. For example, you might call
ABS from a database trigger, stored subprogram, Oracle tool, or 3GL application, as follows:

abs_diff := ABS(x - y);

If you redeclare ABS in a PL/SQL program, your local declaration overrides the global
declaration. However, you can still call the built-in function by qualifying the reference to ABS,
as follows:

abs_diff := STANDARD.ABS(x - y);

Most built-in functions are overloaded. For example, package STANDARD contains the following
declarations:

FUNCTION TO_CHAR (right DATE) RETURN VARCHAR2;

FUNCTION TO_CHAR (left NUMBER) RETURN VARCHAR2;
FUNCTION TO_CHAR (left DATE, right VARCHAR2) RETURN VARCHAR2;
FUNCTION TO_CHAR (left NUMBER, right VARCHAR2) RETURN VARCHAR2;

PL/SQL resolves a call to TO_CHAR by matching the number and datatypes of the formal and
actual parameters.

Overview of Product-Specific Packages

Oracle and various Oracle tools are supplied with product-specific packages that help you build
PL/SQL-based applications. For example, Oracle is supplied with many utility packages, a few
of which are highlighted below. For more information, see Oracle9i Supplied PL/SQL Packages
and Types Reference.

About the DBMS_ALERT Package

Package DBMS_ALERT lets you use database triggers to alert an application when specific database
values change. The alerts are transaction based and asynchronous (that is, they operate
independently of any timing mechanism). For example, a company might use this package to
update the value of its investment portfolio as new stock and bond quotes arrive.

About the DBMS_OUTPUT Package

Package DBMS_OUTPUT enables you to display output from PL/SQL blocks and subprograms,
which makes it easier to test and debug them. The procedure put_line outputs information to a
buffer in the SGA. You display the information by calling the procedure get_line or by setting
SERVEROUTPUT ON in SQL*Plus. For example, suppose you create the following stored
procedure:

CREATE PROCEDURE calc_payroll (payroll OUT NUMBER) AS

CURSOR c1 IS SELECT sal, comm FROM emp;
BEGIN
payroll := 0;
FOR c1rec IN c1 LOOP
c1rec.comm := NVL(c1rec.comm, 0);
payroll := payroll + c1rec.sal + c1rec.comm;
END LOOP;
/* Display debug info. */
dbms_output.put_line('Value of payroll: ' || TO_CHAR(payroll));
END;

When you issue the following commands, SQL*Plus displays the value assigned by the
procedure to parameter payroll:

SQL> SET SERVEROUTPUT ON

SQL> VARIABLE num NUMBER
SQL> CALL calc_payroll(:num);
Value of payroll: 31225

About the DBMS_PIPE Package

Package DBMS_PIPE allows different sessions to communicate over named pipes. (A pipe is an
area of memory used by one process to pass information to another.) You can use the procedures
pack_message and send_message to pack a message into a pipe, then send it to another session
in the same instance.

At the other end of the pipe, you can use the procedures receive_message and
unpack_message to receive and unpack (read) the message. Named pipes are useful in many
ways. For example, you can write routines in C that allow external programs to collect
information, then send it through pipes to procedures stored in an Oracle database.

About the UTL_FILE Package

Package UTL_FILE allows your PL/SQL programs to read and write operating system (OS) text
files. It provides a restricted version of standard OS stream file I/O, including open, put, get, and
close operations.

When you want to read or write a text file, you call the function fopen, which returns a file
handle for use in subsequent procedure calls. For example, the procedure put_line writes a text
string and line terminator to an open file, and the procedure get_line reads a line of text from
an open file into an output buffer.

About the UTL_HTTP Package

Package UTL_HTTP allows your PL/SQL programs to make hypertext transfer protocol (HTTP)
callouts. It can retrieve data from the Internet or call Oracle Web Server cartridges. The package
has two entry points, each of which accepts a URL (uniform resource locator) string, contacts the
specified site, and returns the requested data, which is usually in hypertext markup language
(HTML) format.

Guidelines for Writing Packages

When writing packages, keep them as general as possible so they can be reused in future
applications. Avoid writing packages that duplicate some feature already provided by Oracle.

Package specs reflect the design of your application. So, define them before the package bodies.
Place in a spec only the types, items, and subprograms that must be visible to users of the
package. That way, other developers cannot misuse the package by basing their code on
irrelevant implementation details.

To reduce the need for recompiling when code is changed, place as few items as possible in a
package spec. Changes to a package body do not require Oracle to recompile dependent
procedures. However, changes to a package spec require Oracle to recompile every stored
subprogram that references the package.