HP 3000 Manuals HP 3000 Manuals
Ground Rules
In addition to the menu and screen structure discussed at the beginning
of this chapter, there are other ground rules on which the Administrator
Utility's operation is based. A good understanding of these ground rules
will help you use the utility efficiently.
Order for Additions and Deletions
For the most part, the order in which you add and delete configured items
is important.
Here is the order in which additions must occur:
* You must define a remote HP 3000 system before you can define
databases or files that reside on it.
* You must define a database before you can define IMAGE tables
derived from datasets in the database. Similarly, you must define
a file before you can define file tables derived from files.
* You must define configured tables before defining a view table
derived from them.
* You must define an access group before defining users belonging to
the access group.
* You must define configured tables and access groups before
defining table security and item security involving those tables
and access groups.
Here is the order in which deletions must occur:
* You must delete databases and files before you can delete the
remote HP 3000 system they reside on.
* You must delete a view table before deleting the configured tables
from which it is derived.
There are four cases where deletions, because they might otherwise be
tedious and time-consuming, are done for you:
* If you delete a database, you are first told that there are
configured tables (IMAGE and view) derived in whole or in part,
from that database. If you then confirm your request to delete,
the Administrator Utility deletes the definitions of all of those
configured tables as well as deleting the definition of the
specified database. (The same is true for deleting a file.)
* If you delete a configured table, the Administrator Utility
deletes all table security and item security associated with that
table.
* If you delete an access group, you are first told that there are
users defined for that access group. If you then confirm your
request to delete, the Administrator Utility deletes the
definitions of all of those users as well as deleting the
definition of the specified access group.
* If you delete a user, the Administrator Utility also deletes the
definitions of all saved tables associated with that user, as well
as the T-files in PPCSAVE.HPOFFICE that contain the data for those
saved tables.
Impact on Active Users
Where deletions have an effect on currently active users, that
information is noted in Chapters 3 through 10 in the "To Delete..."
discussions.
Redirecting Printed Output
All reports and printouts, whether from the various Show and List screens
or from the Report Main screen, are directed to the file ADMLIST.
(Another file, ADMSYLST, is used for reports generated from the
Synchronization Summary screen.)
The default print device that Access Server associates with this file is
LP. There are two ways to redirect output to a different printer:
* Set up a file equation before running the Administrator Utility.
For example, if you have a laser printer configured with the
device class name PP, then the following file equation redirects
your reports and printout to the laser printer:
:FILE ADMLIST;DEV=PP;ENV=LP2.HPENV.SYS
_________________________________________________________________
NOTE If the environment you specify does not allow 132-character
lines, your output will be truncated.
_________________________________________________________________
* Redefine and then use the UDC ADMIN to run the Administrator
Utility.
The UDC command file that comes with the product contains the
command:
ADMIN
COMMENT FILE ADMLIST;DEV=LP
RUN ADMIN.PPC.SYS
*******************
Substitute your file equation for the COMMENT line just before the
RUN command. Thereafter, use the UDC command ADMIN to run the
Administrator Utility and your printouts will be automatically
directed to the specified printer.
You can also redirect output to a disc file, using either of the above
methods of directing that output. First, build the disc file, like this:
:BUILD ADFILE;REC=-132,10,F,ASCII;DISC=10000;CCTL
Then, set up your file equation this way:
:FILE ADMLIST=ADFILE,OLD;DEV=DISC
Reserved Words as Table and Item Names
The following are all reserved words in Access Server.
AND LEFTJOIN
CASE LIKE
DEFAULT LJ
DIV MATCH
ELSE MOD
END NOT
F OR
FALSE T
IS TRUE
JOIN
When you use the SQL statement in the Host Batch Facility or in PC batch,
four additional reserved words exist: SELECT, FROM, WHERE, and HAVING.
The reserved word restriction in Access Server has been removed. You can
use both table names and item names that are also reserved words. For
example, DIV, JOIN, CASE, and so on.
When a table or item name that is also a reserved word is used within a
view table definition, you must prefix the name with an exclamation point
(!). This allows Access Server to differentiate true reserved words from
these names. For example,
Item Clause: DIVISION=!DIV, SIMILAR=!MATCH, LIKE-IT=!LIKE
A table name or an item name can include any of these reserved words in a
longer string of characters without the prefixed exclamation point. For
example, MATCHBOX and DIVISION are acceptable names, even though MATCH
and DIV occur in them.
When to Use the Translator Utility
If you use Dictionary/3000 and you want your Access Server users to be
able to access data already defined in a Dictionary/3000 data dictionary,
Access Server provides a Translator Utility. This utility translates
Dictionary/3000 information into Information Access data dictionary
format and adds the appropriate entries to the Information Access data
dictionary.
Part III of this manual covers the Translator Utility in detail. We
mention it here to indicate when you would use it.
The Translator Utility is helpful primarily in initially defining your
data, but you can also use it whenever you add new information to
Dictionary/3000 that you would also like to add to the Information Access
data dictionary.
In defining your data, use the Translator Utility after configuring
remote HP 3000 systems, but before configuring databases. You use the
Translator Utility to specify host or remote databases you want to
translate. The Translator Utility adds to the Information Access data
dictionary the definitions of the databases you specify. It then adds,
as IMAGE tables, all the detail datasets and manual master datasets
defined for those databases.
You should be able to use the Translator Utility to automate most of the
translation effort, then use the Administrator Utility to check the
result and make any necessary adjustments before continuing the process
of defining your data. (For a discussion of Translator Utility
limitations, see Chapter 11, "How to Use the Translator Utility.")
Data Access Across Groups or Accounts
If, on the host system, any of the data sources you want to configure are
going to be accessed across group and/or account boundaries, you need to
ensure that they are "released" for read access.
NOTE The same holds true for remote data sources residing in an account
other than the one specified in the logon defined for the remote
system. You can, however, maintain remote data source security by
first configuring the same Node several times with different Remote
System names and different logons, then configuring your remote
data source using the Remote System name that logs on to the
account it resides in. (For details, see "Adding..." under
"Defining Remote HP 3000 Systems" in Chapter 3.)
This release can be done in either of two ways:
To Release Databases:.
* You or the System Manager can use the :ALTGROUP and :ALTACCT
commands to allow all MPE users access to data in the group where
each such data source resides.
MPE file security is thereby relaxed for all data in this group,
but IMAGE security on your database remains intact.
* You can use the RELEASE command in DBUTIL.PUB.SYS. To use this
option, you need to be the creator of the data source and you need
to be logged on to the group and account where the data source
resides. For example, to release database DB1, you would
:RUN DBUTIL.PUB.SYS
>>RELEASE DB1
In this case, MPE file security is relaxed only for the database
files, but remains intact for other files in the group and
account. IMAGE security on your database files remains intact.
Another alternative, if you find these options unacceptable, is to let
your PC users know what groups and accounts their data sources reside in
and to insist that they change their host logon accordingly. This
alternative, of course, will not work if users need to access view tables
that combine data from data sources in different accounts. In that case,
they'll need to retrieve the data from each account separately, then join
the saved tables.
To Release Files:.
You can use the :RELEASE command to temporarily suspend security
provisions for a file at all levels (file, group, and account), allowing
any user in the system unlimited access to the file. Suspension remains
in effect until a :SECURE command is entered for this file to restore its
previous security provisions. The suspension remains valid after job
termination or system failure followed by a coldload or a reload.
(However, it can be negated if the system is reloaded from a SYSDUMP tape
created before the :RELEASE command was entered.)
Note that this command can be used only for permanent files on disc whose
labels identify you as the creator of the file. In addition, the
:RELEASE command will not work if the group's home volume set is not
mounted. When the normal (default) MPE security provisions are in
effect, the file must be in your logon account and must belong to your
logon or home group.
The :RELEASE command will not cause a volume set to be mounted. If the
file's home volume is not mounted when this command is issued, the file
will not be found and thus cannot be released.
The :RELEASE command does not affect the file's lockword, if any.