HOME
Executive Committee
Institutional Members
International Directory
Congresses
National Collections
Research Sites
Partner Organisations
WHAT'S NEW
FORUM
|
TANDEM
EDP System
specification for selection of hardware and software
Documentation et Art de
l'Acteur
Records and Images of the Art of the Performer
18ème Congrès
International, Stockholm 3-7 septembre 1990 / 18th
International Congress, Stockholm 3-7 September 1990
Editor: Barbro Stribolt
(Drottningholms Teatermuseum). Stockholm : 1992, p.
140-144
Current status
1. Overview and
context
The new EDP planning
concerns all areas within the TANDEM total concept.
To be more exact, the following areas are covered:
- Works Title File,
TEWE,
- Works Catalogue,
TEKA,
- Seek Title File,
TESU,
- Production File,
TEDI,
- Subject File, TEDO.
Additionally, the entire
library system is affected by these plans, as in the
future the library will be linked to the EDP system.
2. Procedures,
processes and aids at present available.
- The organisational
structure of TANDEM files is based on a category
system. This structure of document acquisition in content
categories that have been extensively standardised and
can apply to many files should be adhered to in
principle. Data acquisition takes place directly at the
terminal or the PC. An additional aid to proceedings is
provided by a Seek Title Card File and an Author Card
File, which can in the medium term be transferred to
files thus dispensing with the need for card files.
Existing hardware and
software:
- IBM 3090 Mainframe,
15 MIPS, 64 MByte core memory. Connection via:
- 1 DAG 9600 UE-03
modem
- 1 IBM 3274 61 C
control unit
- 8 IBM 3180
terminals
- 1 IBM 3192 G
terminal (for technical data, see RZ Manual, p.7
onwards)
Software: STAIRS/VS,
ISPF 2.2.0
- Current TANDEM EDP
Organisational Status:
- Data input:
Input occurs in accordance with certain formal
(specified in the "control" works) and
content related criteria, based on a defined
system of categories, which contains the
information relevant to the file in a structured
form.
- Data processing:
Processing of data acquired using the SPF Editor
occurs by means of autonomous programs. These are
specifically written on the basis of the
declarations made in the "control"
works and technologically implemented in the
Documentation, System and User manuals. The
programming language for this software is PL1.
The programs are executed when a job is sent to
the Mainframe in the Ministry of Agriculture via
one of the IBM terminals. These jobs are
formulated in JCL (Job Control Language).
3. Evaluation of the
current situation
- TANDEM's
organisational structure should be adhered to in
principle. This includes distribution of information to
the files as well as their internal structure.
- In contrast, the
current situation in the areas of data acquisition and
data processing, involving both hard and software, seems
unreasonable. In particular concerning:
- cost explosion with
regard to the HOST.
- unreasonable
response times of the HOST.
- slowness of
individual programs.
- dependence on
hardware/software interchange with the HOST.
Involving the necessity of program adaptations.
- blocking of
external on-line communication by the HOST.
- unsatisfactory
character set:
- concerning
the monitor display.
- concerning
the printout
Involving the
necessity of keeping two parallel data memories.
- only limited access
if required by several people at the same time.
- retrieval system
limitations.
- software:
As SPF involves a pure text editor, where the
main area of application is software programming,
many standard features of both a word processor
and a database are not available. Only simple
commands such as copying lines and blocks of
text, replacing and deleting, and a basic search
facility are available. Even interchanging data
between different files proves to be relatively
complicated. Linking functions and commands, and
the more complex generation of clauses (e.g. for
reporting and logging functions) require the use
of a complicated procedure: output and
intermediate inventories must be created, several
programs must be activated and their correct
operation monitored.
There are additional problems with data input:
- Lack
of a default mask: each input line has to
be freshly created and published by the
documentor.
This means not only an excessive amount
of work, but also a permanent and
critical source of errors.
- Lack of
help on input, such as constants.
- Lack of
validity checks and logging functions.
- Lack of
word processing features such as
automatic line wrap, easy publishing,
automatic horizontal scrolling of text,
clear layout, etc.
- Lack of
interactive functions, such as HELP or
error description.
- Lack of a
reorganisation function.
Setting objectives
- The operational
structure should also be expanded beyond the existing
conditions into the following planned areas of
organisation:
- Literature file for
secondary literature connected with the
International Theater Bibliography.
- Involving TANDEM in
matters concerning library organisation.
- Inclusion of
external files (German Library) and other formats
(MAB, MARC, ASCII, dBase).
- Personal file.
- Critic file.
- File of performance
dates.
- The following
peculiarities should be taken into account when
considering the aims as a whole:
- decentralised input
- German language and
international input
- networking access,
both nationally and internationally, in the
TANDEM world
- differing data
groups with:
- direct
access via fields/categories
- access
via thesaurus/descriptor
- library management
- museum organisation
in relation to subject management
- property management
and financial administration.
Demands on the
proposed application software
1. General technical
demands
- Basically the proposed
application software must satisfy all requirements with
regard to efficiency, ease of operation and security.
Data input should be possible without costly training,
checking and monitoring functions as well as any form of
inventory management should be automated and taken over
by the system. Interactively, the system should offer
extensive support to the user during input, i.e. guiding
the user with menus or masks. Standard research
operations should be possible without great expenditure.
Highly complex research operations are only possible with
variable and flexible techniques or reporting, indexing
and integration.
- As far as the library aspect is concerned, already
existing system specifications for library software must
be taken into account.
- The following
requirements - listed in function of areas - apply
generally, independently of the structure of individual
TANDEM files:
1. 1. Input
- It must be possible
to import data fields or data records from other
files automatically, in accordance with certain
selection criteria.
- It is essential
that a validity check runs continuously during
input with regard to form and syntax as laid down
in the "control" texts.
- A continuous
automatic validity check when inputting the title
of the work and its master number.
- Generation of
subcategories (of equal or lesser importance)
must be possible without having to alter the
overall structure of the file. If subcategories
are generated in categories unrelated in content,
the appropriate subcategories must be
automatically generated in the corresponding main
categories.
- There must be an
automatic setting up of cross-references between
categories and subcategories which are related to
each other in content (e.g. publisher and place
of publication).
- An, as it were,
"invisible" category should exist in
the background of each document which contains
the system date. This should be used as a
criterium for sorting or selecting.
- Implementing
printer control characters.
- Fast and simple
transfer of contents (copying) from a category
that has already been input, into other
categories.
- Duplicating
function of entire data records for publishing
- Generation of
constants; contents of fields which often reoccur
must be established as constants to be published
and therefore appear automatically in the mask at
each new input of document.
- Creation of a field
list: categories/fields must:
- be
either open or closed, as required, for
input or output (this obviously does not
apply to compulsory categories).
This can produce either
- only open
categories/fields in the mask/printout
- all
categories/fields, but only the open ones
are available for input, i.e. the cursor
skips the closed categories in the mask.
- Categories/fields
without entries are automatically deleted from
the data record/document, but will reappear again
for the next entry.
- Automatic line wrap
at selected points.
- Default index: At
the start of the input procedure, one or more
categories will be specified as the index. Any
new documents after this will automatically be
put into the correct location in the database.
1.2. Output
- Printing of tables:
open fields must be printed side by side (at either the
monitor or the printer), so that each document takes up
one line.
1.2.1. Sorting,
Selecting, Reporting
- It must be possible
to export data fields or data records to other
files automatically, in accordance with certain
selection criteria.
- Control characters
such as the non-sort character, square and
pointed brackets and special characters must be
taken into account when sorting.
- Sorting/selection
to occur after entry of a Sort/Select criterium
identified by a predetermined control character
(e.g. ":") at any point in the
field/category. The control character should
apply exclusively to the appropriate category.
- Truncation: left,
centre, right.
- Ignoring when
sorting anything in the field/category that is
not content-related (e.g. "BEAR:",
"KOLL:", "OS:",
"DL:").
- Filtering function:
only those data records that correspond to a
preset filtering scheme (also generated by
Boolean operation) are included (e.g. all
documents entered after a certain date. and/or
whose categories correspond to a certain
pattern).
- Sorting by date,
optional date inversion, variable date format.
- Observance of
continuation line/line break when sorting.
- Simple print
facility for report programming.
1.2.2. Printout
- The system must
adhere to the special requirements on setting up
a register of published works (also see Chapter
3) regarding print format. It is worth
considering here whether a special program or
special routine should be used for creating a
register from TANDEM files.
- Converting the
contents of multiple vertical columns into
continuous text.
- Optional transfer
of control and special characters to text.
- Automatic numbering
and pagination.
- Creation of header
and footer lines.
- What is being
printed also visible on the monitor for checking.
- Various forms of
printing:
- cards,
labels
- layout
design
- variable
text layout
- Full text output
possible, with abbreviated version option.
1.3. Automatic
conversion
- Previously, it has
been necessary to use substitution to represent
characters that could not be reproduced (e.g.
"&e22" for "é"). Of
course, the new system is able to produce
diacritics (both on screen and printout), and can
also automatically convert any substitutions in
existing records into diacritics. For reasons of
compatibility of data exchange or data transfer,
this function must also work in reverse
(conversion of diacritics into substitutions).
- Inversion must also
occur automatically (e.g. with names of people)
and must also be equally easily reversed.
- Incoming and
outgoing data using a different line format or
line length from that used by the system must be
easily transformed (if necessary using a utility
program).
- It must be possible
to use prearranged control characters (e.g.
"&") with their usual meaning.
- Automatic
conversion of abbreviations into full text.
- Document number to
be retained and automatically generated as a
field.
1.4. Interfaces
- Optional hardware
interfaces: CD-ROM, BTX, Telefax, Videodisk.
- Compatibility with
the software in use (e.g. OPAC, or possibly LARS)
is highly desirable.
- Compatibility with
standalone and multiuser systems, i.e. external
users should certainly be able to assume control
of their own data processing. This points to the
long term option of a multilevel expansion of
capacity. This means that present system
requirements must include the possibility of
being upgraded to cater for an at present unknown
number of users.
- Database/word
processor link.
- Interface to
customer management (address file and delivery
file), inventory management, accounting and
reminders, correspondence.
1.5. File integration
- All TANDEM files
must be linked together relationally by index
fields, which can be defined as desired.
- It must be possible
to include utility files (e.g. thesaurus).
- It should always be
possible to access TESU while working in other
files.
Other Requirements
- Character sets must
contain special characters, going beyond the
German alphabet (e.g. diacritics of all European
languages in Roman script), including the special
characters used for transliteration and
transcription from languages not written in Roman
characters, in the transliteral or transcribed
form (also including Hebrew and Turkish). It is
not necessary to include character sets for
alphabets with non-Roman characters.
18th Congress
SIBMAS Home Page
URL:
http://www.theatrelibrary.org/sibmas/congresses/sibmas90/sto_33.html
Information about
this site: Claire Hudson, Secretary General
Last modified:
November 21, 2000
|
