WO1999017192A1

WO1999017192A1 - Method for configuring data processing equipment

Info

Publication number: WO1999017192A1
Application number: PCT/DE1998/002447
Authority: WO
Inventors: Ralph Rinschen
Original assignee: Siemens Nixdorf Informationssysteme Ag
Priority date: 1997-09-30
Filing date: 1998-08-20
Publication date: 1999-04-08
Also published as: AU9531298A; EP1027646A1; CN1272927A; DE19743324A1; JP2001518659A

Abstract

The invention relates to a method for operating a data processing facility with a parameter adjuster, which adjusts the parameter settings of system components in that a definition file identifies the parameters and a configuration file determines the parameters using the identification contained in the definition file.

Description

Configuration procedure for data processing systems

Techn-i sπhfis G hi et

The invention relates to a configuration method for data processing systems.

S in technology

Many facilities and machines, in particular cash dispensers, service and information stations, booking machines, contain a data processing system for control. In many cases, depending on the available computer technology and performance, it is derived from an otherwise usable universal system such as a personal computer or workgroup server and uses its operating system. Screens with today's graphic options are available as the user interface, which are therefore operated by programs that are created with the tools for creating programs for, for example, personal computers. In addition, a number of programs are active which operate the special periphery of the machine and have to be adapted to it. All of these programs require parameter or configuration data for their operation, which are stored in the data processing system. Even if these increasingly adopt a common standard in terms of format, it must nevertheless be ensured that the parameters necessary for operation are set correctly.

This setting of parameters was previously carried out manually by a customer service representative during installation or updated on-site if required. At a Malfunction was also checked for possible errors, controlled by the experience and knowledge of the person. For the installation of a program it has therefore been known for a long time to have this carried out by another program which copies the program files to the target system and sets up the parameter files.

Such a method is described, for example, in the technical reference for the Microsoft Windows NT Workstation 4.0, Microsoft Press Germany 1996, ISBN 3-86063-240-X in Chapter 2, in which the sections "Installation of Applications" and "Uniqueness Database Files (UDFs) "describes that and how additional applications can be installed and configured differently for each individual system. However, knowledge of the parameter names of the individual applications is necessary. There is no support for changes after the start of operations; these can be carried out either with the configuration program of the respective component or with general tools, here the registry editor or a text editor for the .INI files.

The Free Software Foundation provides under the name "GNU CFENGINE" a system developed by Mark Burgess for the administration of data processing systems, which is based on operating systems according to the POSIX standard. Version 1.4.1 of this software can be reached via ftp://ftp.germany.eu.net/ /pub/packages/gnu/cfengine-1.4.1. tar. gz and via any other mirror of "Free Software Foundation Inc.", 59 Temple Place - Suite 330, Boston, MA 02111, USA. "CFENGINE" is a system for managing a network of data processing systems. A special script language is used to describe the target configuration of a data processing system. The associated Software is controlled by this script language in such a way that the target configuration described there is set. The section "editfiles" is of particular importance. With "editfiles" a number of files can be brought to a target level. The commands provided in CFENGINE make it possible to automatically inspect a configuration or parameter file and bring it to a desired target state. This is achieved by a number of commands, eg "AppendlfNoSuchLine", which inserts a line if it is not available. An experienced system administrator is required, as can be seen from the last paragraph of the above section, which states: "It is suggested that you use these editing functions with caution.".

In this case, parameters of different applications or their programs and parameter files are assigned based on the knowledge of the system administrator, who must be informed and trained to know the respective names and references of the parameters to one another. If modified software is installed, the control file for CFENGINE must be updated accordingly.

Another method is described in the installation manual "SuSE Linux 4.3" by B. Bauer and others, Fürth 1996, ISBN 3-930419-31-9. Section 11.5 from page 11-5 shows that a central configuration file / etc / rc. config is used. In terms of programming, a number of environment variables are set there, which are entered in other parameter files, for example / etc / resolv, by calling / sbin / SuSEconfig. conf. Even if a changed and standardized naming of the parameters as well as a multiple use of the parameters can be achieved, the adaptation to the respective component can be achieved by adaptation of the respective script in the ../init.d is necessary. However, this is usually specified by the system software supplier, which is why changes in it lead to maintenance problems.

In contrast, it is desirable in the case of customer installations of data processing systems with a number of interlinked programs which present themselves to the customer as a single application, to give the customer care representative an easy possibility to adapt or correct parameters without having to have detailed knowledge of the parameter files and having to know different variants of parameter files.

Presentation of the invention

The invention is based on the observation that parameters of the respective applications or system components are often referred to differently, although they must be the same when the system is in operation. The invention therefore uses a definition file in which the parameters of the system components are identified and localized and are given a name in such a way that parameters which have the same content, even if they are designated differently by the system components and are stored in different places, are given a uniform designation. This name can then be chosen in the terminology and in relation to the field of application. Using these designations related to the application field, the user then defines his specific parameters for the overall system and saves them in a single configuration file. Regardless of the start of the system, i.e. also during operation, the process updates the parameters of the system components using the definition and configuration files. This procedure also makes it easy to carry out a test run at which the parameter updater logs what changes should be made, but without already making these changes.

It is therefore a method for operating a data processing system with a parameter comparator, which sets sets of parameters of system components in that a definition file designates the parameters and a configuration file determines the parameters by means of the designation from the definition file.

Brief description of the drawings

Show it

1 shows the arrangement of the components involved in the method,

Fig. 2 shows the links between the data fields.

Description of an execution note spl l s

1 schematically shows a parameter comparator 10 which processes a definition file 12 and a configuration file 14. One or more parameter files (16) are created from the data stored there.

A parameter file is a file in which a number of values are stored by means of an associative method, ie addressed by key. These values are used by a program using the parameter file to define runtime parameters. Such a parameter file 16 is shown schematically in FIG. 2 as a table, in which a key A is listed in the first column and the associated values E are contained in the second column. There are a number of different types after which these parameters are saved. In POSIX operating systems, these are the files also known as .re files, whose file names begin with a period. In the graphical user interface Windows 3.x from Microsoft, files with the extension '.INI' are used. These contain section identifiers in square brackets and, apart from comment or blank lines, a parameter for each line, the line starting with a key value, followed by an equal sign and the set value. Logically, there is a tree structure in which the file name represents the root, the section designates a subsequent node, the keys represent the lowest nodes and the values represent the leaves. Correspondingly, parameters in the Windows NT operating system are also stored in a central database, the tree structure being represented by a dot as a separator via the syntax of a key.

The structuring of the parameters as a tree is very helpful for the human reader, but of little importance for the technical content of the invention. Therefore, the representation in FIG. 2 assumes a linearized tree in which, for example, the absolute name of the parameter is present in the key. The type of storage, whether as a binary file or in a readable form, whether linearized or with measures that accelerate access, can be chosen freely by the person skilled in the art applying the invention in accordance with the respective boundary conditions and other requirements. Whether all parameters are stored in a single database or the top sheets represent file names is of secondary importance for the invention. The key A thus symbolically stands for the name of the parameter, its format and the location as well as the type of storage. The tables involved are shown in simplified form in FIG. 2. A parameter file 16 contains a number of parameters, represented as lines, with a key A and a value E. Furthermore, there is a definition file 12 which logically has three columns, namely a key A, a designation B and a standard value C. The keys are the same as used in the parameter file 16 and are therefore designated with A in both. There is also a configuration file 14, which conceptually has two columns A and D. The first column A again contains a key from the same entirety as the columns A of the parameter file 16 and the definition file 12. Associated with this is a target value D of the respective parameter designated by the key.

The method implemented by the parameter comparator 10 is based on the definition file. This is processed line by line and the triple is read from name A, description B and standard value C. Using the name A, the key A is searched for in the parameter file 16, indicated by the arrow 22, and the value E is read. If there is no entry with the key A, the standard value C is set as the value E and otherwise the value E is continued. The designation B is also searched for in the configuration file 14, symbolized in FIG. 2 by the connection 21. If the designation B is not found, the value C is used instead of the value D in the further steps. In terms of programming, it can make sense to keep copies of the files in memory and then to add the key B not found with the value D equal to the value C. However, it should be noted that the parameter comparator does not change the definition file or the configuration file; only the parameter file 16 is changed different. found, the value D is compared with the value E.

The value D takes precedence over the stored value E; i.e. the value D is entered in the parameter file 16 if it deviates from the value E.

The behavior of the parameter comparator 10 can also be described as follows: Set the value E under the key A in the parameter file 16 if the identifier B is also found in the configuration file 14. Otherwise, set the value C under the key A in the parameter file.

The detour via the identifier B ensures that the keys in the configuration file 14 can be selected freely and independently of the keys in the parameter file 16. This is because the latter are determined by the manufacturers of the products that use the parameter file 16. The definition file 12 is created by a specialist who compiles the products and has precise knowledge of the required parameters A. The configuration file can then be maintained by a user who now finds the changed identifiers adapted to his terminology and does not have to take into account the component for which the value D is intended.

Furthermore, it is thus possible to assign the same value D, determined by the identifier B, to different parameters, determined by the key A. This is achieved by the designation B appearing several times in the second column of the definition file. This means that if several components require the same parameter but have different names, they can only be listed once in the configuration file.

Not shown in FIG. 2, the definition file can also contain information about the permitted parameter values E from the configuration file. Here are the usual ben, as they are used in plausibility checks, for example, value ranges for numerical values and the like. If a target value D is not below the permitted values, the standard value C is entered in its place. The same applies if the entered value E is not permitted. This can happen if the user has changed the parameter value E by other means. A message can be sent to an administrator using the means available in the respective operating system, for example mail or 'syslog'. The log file described below can also accommodate this message.

Every change to a parameter file 16 is noted in the log file 20. The previous value is also entered here. It is not only possible to understand the changes. If an inadmissible value is found in the configuration file, which can be changed by the user, then in the case of a log file the previous value is taken from the log file, which probably delivers better results than the standard value C from the definition file 12.

Since it is quite complex to reconstruct the last generated status from the log file, a status file 19 is provided in a development of the invention. All changed or checked values of all affected parameter files 16 are stored in these. Not all parameters are saved, as is the case with the registry in Windows NT, but only those that are handled by the parameter comparator. This also allows a backup on systems like 'Windows for Workgroups ¹ , where a backup of the parameter files is not provided. It also contains the last set or checked value so that changes can be made by the user with Edi- gates can be easily undone directly in the parameter files.

In another development, a control file 18 is provided. In this the mapping of the key A from the definition file 12 to the parameter file 16 is determined. Depending on the operating system, all parameters are stored in a single ('registry') database or in several text files ('. Ini'). The control file 18 uses a further indirect step in that the key A in the definition file 12 is broken down into two parts, the first of which deals with the control file 18 and the second is the key in the respective parameter file 16. For example, the key A in the definition file 12 is 'X25.CALL'; its value, a number, is irrelevant here. The key 'X25' is used to search in the control file 18 and as a result, depending on the respective system, it is found that either a file 'C: \ windows \ x25.ini' in Windows text format or a '.ini' in the OS / 2 binary format, or a section 'HKEY / LOCAL_SYSTEM / SOFTWARE / NETWORK / PACKET / X25' should be used in a registry 'registry'. The definition file 12 can thus be created and maintained independently of the respective system. Since the configuration file 14 still refers to the keys in the definition file 12, only the control file has to be exchanged when the operating system is changed.

In a variant of the invention, the values are tested in the following order: value from the configuration file; original value; Default value from the definition file; Average or median for an ordered amount or first value for an unordered amount of the allowed values.

Claims

claims

1. A method for operating a data processing system with a number of system components which are generally connected to one another and use a respective set of parameters (16) which are stored in the data processing system in a readable and writable manner by one or more means intended for this purpose, with the features

a parameter comparator (10) updates sets of parameters (16) of system components as follows:

* a definition file (12) contains triples from:

Reference (A) to a parameter of a system component,

- Name (B) of the parameter regardless of the system component,

- standard value (C) of the parameter;

* a configuration file (14) contains pairs

- Name (B) of a parameter as in the definition file, - Setpoint (D) of the parameter;

* where the parameter adjuster (10)

- localizes a parameter of a system component by means of the first component (A) of a trip ice of the definition file (12) and reads it with the means determined for this purpose,

- The parameter in the presence of a pair in the configuration file (14), the designation (A) of which corresponds to the designation (A) in the definition file (12), to the target value (D) from the configuration file (14), otherwise on sets the standard value (C) from the definition file (12),

- and writes the parameter by the means intended for this if the value is not equal to the read value.

2. The method according to any one of the preceding claims, wherein the reference to a parameter of a system component indicates the name of the parameter, its format and the location and the type of storage.

3. The method according to any one of the preceding claims, wherein in addition to the standard value, a set of permitted values of the parameter are specified in the definition file and, if a value is not within the permitted value range, a permitted value is used and optionally a message to an administrator is generated.

4. The method according to claim 3, wherein the permitted values are tested in the following sequence: value from the configuration file; original value; Standard value from the definition file; Average or median for an ordered amount or first value for an unordered amount of the allowed values.

5. The method according to any one of the preceding claims, wherein each change of a parameter is stored in a history file (20) and, in the case of an impermissible parameter in the configuration file, the previous value is determined from the history file and then used.

6. The method according to any one of the preceding claims, wherein the respective status of the changed or checked parameters is stored in a status file 19 and these values are used instead of a reconstruction using the history file (20).

7. The method according to any one of the preceding claims, wherein a control file is provided with which the reference (A) of the definition file (21) is supplemented or implemented in such a way that the location, type and, if appropriate, renaming of the keys in parameter files ( 16) is determined.