JPH037986B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION BACKGROUND OF THE INVENTION The present invention relates to online documentation facilities for computer systems. online·
The documentation facility provides various system information to the user in response to documentation or "help" commands. For example, if the user enters HELP TERM
When a documentation command such as ``BILLING IDENTIFIER'' is issued, the system provides documentation to the user located at the terminal of what the term ``billing identifier'' means in the system. . Or if the user uses HELP COMMAND
When you issue the =CALL documentation command, the system provides documentation on how to use the "call" command. Another example is HELP ERROR=E
For example, there is a documentation command NOT FOUND, for which the system provides documentation for errors with the mnemonic E NOT FOUND.

SUMMARY OF THE INVENTION In the past this type of documentation was completely defined within the system. (In other words, it can be said that it has been defined by the system designer.) However, according to the present invention, a user of a computer system that provides online documentation has the ability to is given the ability to define a unique documentation. This is accomplished by making changes to the "system documentation" (original documentation provided by the system) for that particular documentation command.
(The term "user" here is intended to encompass not only a single individual, but also a collection of individuals who access the system under a particular billing number.) Of course, system documentation It is necessary to keep it in its original state so that other users can obtain both the original documentation and the documentation that has been modified by the other user. In the preferred embodiment, this includes one or more system documentation files and one or more system documentation files for each user desiring to use user-specific documentation features. This is accomplished by providing more user documentation files. In detail,
System files contain system documentation, and user files contain documentation text provided by users and how these texts can be used to modify the system documentation. It consists of instructions that show you what you can do. In other words, the user file contains information indicating the differences between user-specific documentation and system documentation associated with one or more documentation commands. When a particular documentation command is issued by a user, the system accesses the system documentation file and, if necessary, the user documentation file, and creates the appropriate documentation file specific to the user. Provide shiyeon.

Example description Table shows documentation commands
1 shows system documentation sent back to the computer system of FIG. 1 in response to a HELPCMMAND=CALL.

Table **CALL** *USAGE* PACKAGE-SPHP call (nsa=)/nsa/ (mode=/mode/) *EXPLANATION* The “call command” executes the program with the specified name.

*ARGUMENTS* NSA: A program installed on a given NSA is executed.

MODE: The terminal mode is changed to the value specified before running the program. Modes can be common, parent-parent, or class-specific.

In accordance with the present invention, users of the system are given the ability to define user-specific documentation for documentation commands by specifying changes to the system documentation. System documentation here refers to documentation normally provided by a system in response to a targeted documentation command.
For example, the table shows how the system documentation shown in the table has been modified by the user to provide documentation for a user-specific "call command."

Table **CALL** ＊USAGE＊ call<Network Standard Address> (mode=
<common or class-specific>) *EXPLANATION* Programs are named by a 10-digit network standard address (NSA). The call command executes the named program.

*ARGUMENTS* NSA The program installed on the specified NSA is executed.

MODE: The terminal mode is changed to the value specified before running the program. A mode can be common, transparent or class-specific. Transparent mode is currently not supported and should not be used.

＊EXAMPLE＊ call0451271234 mode=class−specific The “USAGE” section has been replaced,
Note that one sentence has been added to the beginning of the "EXPLANATION" section, one sentence has been added to the end of the "ARGUMENT" section, and a new "EXAMPLE" section has been added.

FIG. 1 shows a system in which the invention is used. The system provides integrated data processing/communications services to multiple customers and includes multiple nodes located within the service provider's premises.
Contains 0. At the core of each node is one or more digital computers as described below. A plurality of data terminals 10a and host computers (or hosts) 106 are connected to node 10 via appropriate data lines. Most terminals and hosts are customer owned and located within their respective buildings. However, some terminals and computers belong to service providers and are used for system management, for example. Nodes 10 communicate with each other via a packet-switched transport network 15. The nodes are connected to the network via respective links 11, which transmit 56 kB/S of data using a protocol according to CCITT standard X.25. Some of the nodes may be used to perform specific functions, such as billing, service provisioning, maintenance, etc.

Communications provide customers with numerous services. These include time-sharing execution of application programs provided by customers and service providers stored within the node; storage of customer data in a database maintained within the node;
Support for software “building blocks” that can be called by client programs to provide editing, command interpretation, etc. services; processes running on one node can interact with processes running on other nodes. distributed processing capabilities achieved by communicating; and store-and-send message services.

FIG. 2 is a block diagram of one node 10. This node has two node processors 20
and one database processor 26. Each of these processors is assumed to be a DEC VAX11/780 computer operating under the VMS operating system supplied by DEC. The node further includes a spare VAX11/780 processor 28 that can serve as either a database processor or a node processor. Other nodes 10 (first
Figure 1) can have less than two or more node processors depending on the expected processing demands. Communication between processors is carried out via bus 25. This bus 25 is a PCL (Parallel Communications Link) bus provided by DEC.

A mass storage unit (eg, a disk) 21 is associated with each node processor, and a mass storage unit 27 is associated with the data base processor 2.
It is related to 6. Mass storage unit 27 has a dual port configuration with spare processor 28, so that spare processor 28 can also be accessed. Associated with each of the four processors is a general purpose input/output (I/O) (eg, CRT) terminal device 29.

In addition, each node processor has one node
At least one front end processor 22 is associated which provides an interface between the processor and the associated terminal 10a and host 10b on the other hand. Front end processor 22 is provided by IBM in the illustrated embodiment.
It is an IBM Series/1 computer running under the RPS operating system. Each front end processor communicates with its respective node processor using the X.25 protocol.
The DEC-supplied firmware that controls the DEC-supplied microprocessor 23 is a level 2 (“link”) level of the protocol.
Performs the role of DTE. Other microprocessors 24 associated with each node processor are linked 11
It performs a similar function regarding X.25 communication via .

The function of node processor 20 is to execute programs for customers and service providers. Thus, the mass storage unit 21 associated with each processor is used primarily to support the processing currently underway at that processor. All data, programs and other files belonging to the customer and the service provider, respectively, are contained within the mass storage device 27.
Memorized in the base. The function of mass storage device 27 is to manage the data base and provide node processors with access to the data base.

The structure of a typical application program package provided by a service provider called a Message Application Package (MAP) is shown in FIG. This program package provides users with text editing,
It provides services such as message generation and sending functions and various database-based services.

The MAP consists of a main program 31 that is linked with a number of utilities that are called as subroutines from the main program.
These utilities include an editor 32 that provides text editing functionality; a set/get station parameter utility 33 that allows the user to retrieve and set various parameters associated with the user's terminal; accept the line, identify the command verb (e.g. “call” or “help”),
a command parser 34 which acts to convert the verb into internal form and organize the variables into a form suitable for the utility to which the command is being transferred; provides the user with a menu of various selections and, depending on the user's selection, further menus; and an online documentation facility 36 embodying the principles of the invention.

A standard that provides a mechanism for performing functions such as enabling and disabling programs and stations provided to the user as program packages supplied by other service providers (but not shown) A Customer Control Package (SCCP); and a Standard Parameter Handling Package (SPHP) which provides functionality similar to the Get/Set Station Parameter Utility 33 are included. Each of these program packages is linked with a set of utilities including on-line documentation functionality 36.

Storage areas within the database are of two types: system storage areas and user storage areas. As shown in Figure 4, the system storage area 4
0 includes a number of system documentation files 400. Five files are clearly shown in the diagram. These are command documentation files 401, 402 and 403, vocabulary file 404 and error documentation file 405. Files 401, 402 and 403 are MAP,
Consists of records containing specific commands and associated system documentation recognized by SCCP and SPHP, respectively. The term file 404 consists of records containing definitions of specific terms used in the system. Error file 405 is detected by the system and the program
Consists of records containing information about specific error or alarm conditions that are returned to the user during the execution of a package.

Different storage areas are created in the database for each user, and FIG. 4 shows the user storage areas associated with one particular user. In accordance with the present invention, user storage area 45 includes a user documentation file 450 whose records include user-supplied documentation text and one or more documentation files. Contains instructions on how to use these texts to modify system documentation for commands. In other words, a user documentation file contains one or more documentation commands and associated information indicating how user-specific documentation differs from system documentation. Contains. These files in the user storage area are created using editor 32, for example.

This example assumes that the user provides documentation information for a) commands used in the MAP and b) errors. This requires two user files: the MAP command
A documentation file 451 and an error documentation file 452 are formed in the user storage area. In the figure, the names of these files are the same as the corresponding system documentation files, ie, files 401 and 405. Thus, once the documentation facility 36 obtains the name of the appropriate system documentation file to open, as described below, the facility 36 also obtains the name of the appropriate user documentation file to open. - You will also own the name of the file (if it exists).

Each program package contains its own data structure called an "environment." The environment for each package includes the file name for the system documentation file associated with that particular program package. In detail, the environment 310 associated with MAP (shown in Figure 3) includes, for example, Error.doc, Term.doc and
MAP.doc (these are files 405 and 40 respectively)
4, and 401 file names), vocabulary, and command file names. For example, the documentation facility 36
When a need arises to retrieve command documentation associated with a MAP, the facility 36 examines the environment 310 to determine the name of the system documentation file to be accessed. The environments associated with SCCP and SPHP contain the same error and vocabulary file names as the MAP environment, provided the same set of error mnemonics and the same terminology are used throughout the system.
However, the commands used in each program package vary. Therefore, SCCP and SPHP environments have their respective command documentation file names, namely SCCP.doc and SPHP.doc (these are the names of files 402 and 403).
Contains.

Each record in the system and user documentation files is searched by a "key" whose value is a command, term, or error mnemonic. Thus, for example, a record in a system or user file containing documentation for a particular command is retrieved by specifying that command as an index key in a database read operation.

system documentation record,
That is, the format for one record in the system documentation file 400 is shown in FIG. . The record begins with a field delimiter (in this case the character ##), followed by an optional main record flag and trailing delimiter, at least a first section heading, and section text. In this case, each is separated by a delimiter.

When the value of the main record flag is the letter "C", it indicates "continuation" and the documentation associated with the index key in question is too long to fit into one record. This indicates that one or more additional records follow. (Such additional records include keys formed by appending numbers to the keys indexed by the first record, e.g. call1, call
The index is specified by 2nd grade. ) Alternatively, the main record flag may be the letter "M" for "menu". This flag indicates that the record in question contains the name of a menu rather than an actual documentation, and when this record is added to a documentation facility 36, that facility 36
5 and designates the menu as the menu to be displayed to the user. Records of this type can be created, for example, by the system as “list file” or “list file”.
Used when providing documentation for a set of command verbs such as "commands", "list directives", etc., and expecting the user to enter an incomplete documentation command, HELP LIST. In this case: , the command documentation file contains "M" as its main record flag, and contains the key "list" containing the name of the menu that asks the user what type of "list" command documentation they would like to know. Contains the record indexed by ”.

The section headings in the system documentation record shown in Figure 5 are the headings "USAGE" in the table,
This is an example of characters such as “EXPLANATION”. Section text is a character example consisting of the text that follows each section heading.

(Other types of records used in system documentation files that do not follow the format shown in Figure 5 consist only of index keys without initial delimiters. When a record is encountered, it responds by immediately accessing the record indexed by that key. This mechanism allows the system to automatically correct certain expected user errors. For example, a record consisting of the entry "run program" can be indexed by the key "run", which is not a legal command. Therefore, a user who wants documentation for the "run program" command may Shion Command HELP
If COMMAND=RUN is inadvertently generated, the documentation facility first searches for the record indexed by the key "run". If the record is found to contain the entry "run program", it will search for the record with the index "run program", thereby automatically correcting the user's error. ) User Documentation Record, i.e., User Documentation File 45
The format of one of the zero records is shown in FIG. This includes an initial delimiter, an optional one or two main record flags, at least the first section heading and each subsequent section heading, an optional section flag, and a section heading.
Consists of text (all separated by delimiters).

The main record flag field may again be the letter "C" meaning "continue". The field may contain "R" or "N". “R” stands for “replacement”;
"N" represents "new". The values of these flags all have the same machine, etc., and indicate that this entire user documentation record should be used in place of the corresponding entire system documentation record. It is Luxion.

The section heading and section text in the user documentation record are similar to the section heading and section text in the system documentation record and will not be discussed further.

The section flag has four values “A”, “P”,
It can take either "R" or "N". “A” and “B” represent “after” and “before” and the section heading in the user record is the section text of the section that has the corresponding heading in the corresponding system documentation record. “R” and “N” are instructions to be added after or before respectively.
represent "replacement" and "new", respectively, as described above. Each of these indicates that the section text in question should replace the section text of the section with the corresponding heading in the corresponding system documentation record. If the section flag does not exist, the section is treated as if the section flag value is "A". and user documentation.
If the section heading of the record is not the same as the section heading of any system documentation record, then the value of the section flag is invalid, as seen below.

Before proceeding to the flowcharts of FIGS. 7-9, it is deemed appropriate to discuss the format of documentation commands in more detail. As pointed out earlier, the user can use HELP
COMMAND=CALL、HELP TERM=
BILLING IDENTIFIER and HELP ERROR
You can issue a command such as =E NOT FDUND, in which the system will respond to the command in question; terminology or error (if modified by the user). ) Provide all documentation. Optionally, when requesting command documentation, the user can
=" for example HELP CALL SECTION
=USAGE SECTION=EXAMPLE. Yet another option is to retrieve documentation from a command documentation file associated with a program package other than the one the user is currently using, if the user knows the file name. I can do it. For example, if a MAP user uses HELP CALL FILE=SCCP.doc
Issuing the command SECTION=ARGUMENTS allows the user to use the “call” command used in SCCP.
You can get documentation about command variables.

7-9 are flowcharts of the online documentation facility 36, which is referred to as a subroutine as described above, but will be referred to as a "routine" hereinafter.

FIG. 7 shows the record search section of this routine in detail. The routine begins at step 701, which examines variables added by command parser 34 to determine what documentation is requested. In step 703, the user enters an inappropriate documentation command, such as HELP.
If it is determined that an ERROR has been issued, the documentation facility calls the menu facility 35 in step 704. The menu facility uses the responses from the user to determine which documentation the user desires. Once the user's desired documentation is determined, the menu facility forms a documentation request on the user's behalf and adds the information back to the documentation facility.

For convenience of explanation, the user is running MAP,
Assume that you have issued a documentation command requesting documentation for a "call" command. As shown at 706, it is determined whether the last documentation requested by this user was for the same command for which documentation is currently being requested, ie, "call". Ru. (This documentation is still available in the output record list 1050, as discussed below.) If the same, control is passed directly to the marking/printing portion of the routine (Figure 9). passed on.

If not, the documentation facility determines the name of the appropriate system and hence the user command documentation file (MAP.doc in this example) in step 709. The routine then examines a table holding the names of open documentation files, as shown at 711, to determine whether the file named MAP.doc is already open. 714 if not open
As shown in Figure 2, a file named MAP.doc is opened in both the system and user storage areas.

Here, since the system file always exists, it can be assumed that the system file with the currently targeted name is open.
However, the user file for the type of documentation requested may not exist. It is therefore determined at 717 whether an open user file named MAP.doc actually exists. If not, the routine proceeds directly to step 732 where a record containing documentation for the command in question is retrieved.

On the other hand, if a user file named MAP.doc is opened, a user record containing documentation for the command "call" is retrieved from it in step 721. Step 7
If it is determined at 24 that there is no such record (ie, the user did not provide any documentation for the "call" command), the routine again proceeds to step 732. However, if a user record exists, its main record flag field (6th
A check is made to see if the value shown in the figure is "R" or "N". If “R” or “N”, “call”
The user documentation for the command replaces the system documentation, thereby causing step 732 to be skipped in this case. This is because a system record containing documentation for the "call" command is not required. On the other hand, if the user record is a replacement record, the system
The record must be retrieved and step 732 is performed as before.

Control is then passed to the records processing section of the documentation facility, as shown at 734. 8th
This portion of the illustrated routine begins at step 801, where the previously retrieved system documentation records (if any) are examined and resolved. This operation requires the 10th
The so-called system record list 1 shown in the figure
010 entries.
The system record list is an array of predefined data structures (system blocks 1020) each containing storage locations that hold the following information about a respective section of the system record. The section stored in location 1021
the heading, a pointer to the location of the section text stored in location 1022, and the number of characters in the text stored in location 1023.

Referring again to FIG. 8, the routine proceeds to step 803 where the previously retrieved user
The documentation records (if any) are similarly examined and parsed into user records β list 1030 as shown in FIG. The user record list consists of user blocks 1040. Each user block has a section heading, a text pointer, and a number of characters (these are located at location 1041,
1042 and 1043), the section flag values (A, B, R
or N).

The system and user record list is the so-called output record list, briefly described below.
used to generate list 1050. This list consists of an array 1060 of output blocks, each of which has storage locations for the following information: The information is a section heading, a pointer to the first text,
The number of characters for the first text, the pointer for the second text, the number of characters for the second text and the print flag, which are 10
61 to 1066, respectively.

To be more specific, this routine is executed at 808 in FIG.
The output record list 1050 is filled by executing the loop as shown in FIG. Each time through the loop, the routine processes successive system blocks 1
020, and in step 811 the user
Determine if there is a matching section heading in block 1040. If not, the routine proceeds to step 814 where the section heading is copied from location 1021 in the system block to location 1061 in the next available block in output blocks 1060. Additionally, the text pointer and character count are located at system block locations 1022 and 10.
23 into the output block locations 1062 and 1063 as a first text pointer and a first number of characters, respectively. The second text pointer in the output block stored at location 1064 is cleared to an empty string. The routine then loops to process the next system block.

On the other hand, the systems currently under consideration
If a section heading exists in one of the user blocks 1040 that matches the section heading in the block, the routine copies the heading into the next available output block location 1061 in step 816, and then Step 819 sets the text pointer (and corresponding number of characters) in the output block according to the value of the section flag stored in the user block's location 1045. If the value of the section flag is “A” (meaning “after”), the output block locations 1062 and 1064
The first and second text pointers stored in are given the values of the text pointers stored in system and user block locations 1022 and 1042. The same thing is done with regard to the number of characters. If the section flag is "B" (meaning "before"), the output block text pointer and number of characters are assigned the same value but in reverse order. If the section flag is “R” (meaning “replace”) or “N” (meaning “new”), the system documentation for a particular section is completely replaced by user documentation. replaced by In this case, the first text pointer and number of characters in the output block will be given the value of the user block text pointer and number of characters, and the second output block text pointer will be an empty string. Step 8
As shown at 21, the user block in question is marked as currently in use by setting its section heading to an empty string.

In this way all system blocks 1
Once 020 is processed, the loop is exited and the routine proceeds to step 824. The routine now scans user record list 1030 for unmarked user blocks, ie, blocks whose section heading is not an empty string. Information from such user blocks is copied into the output block in the same manner as information in system blocks that do not have a matching user block is copied into the output block as described above in connection with step 814. Copied into output block. It should be understood from the foregoing that the value of the section flag is irrelevant in this case.

As shown at 826, the routine then proceeds to its section marking/printing portion (which is shown in FIG. 9). If it is determined in step 901 that the documentation command is to display only a section, the print flag in the appropriate output block is set as shown in step 903. Otherwise, print flags in all output blocks are set as shown in step 904.

The documentation is now ready to be printed or displayed to the user. First, the record key used for the record search is printed in step 908 in uppercase letters with a double * mark. (eg, tables and **CALL** of tables) Each block of output list 1050 is then processed in a loop starting at 911. Within the loop, each output block is first checked in step 913 to see if it is marked for printing. If not marked, move on to the next block. However, if the block is marked for printing, the routine executes steps 915, 916, and 919, where the section heading is printed in uppercase and the specified second text in the output block is printed. 2 text (if present) is printed.

Once all output blocks have been processed, the routine returns to the point of call.

Although shown and described with respect to specific embodiments of the invention, these are merely illustrative of the principles of the invention.
It will be apparent to those skilled in the art that numerous arrangements may be devised without departing from the spirit and scope of the invention.

[Brief explanation of drawings]

FIG. 1 is a block diagram of a data processing/communication system in which the present invention is used, FIG. 2 is a block diagram of a multi-computer node within the system of FIG. 1, and FIG. 3 is a block diagram of a multi-computer node in the system of FIG. Figure 4 shows a program package running within the node of Figure 2, which includes line documentation functionality;
The figure shows part of the system and the user database storage area within the node in Figure 2. Figure 5 shows the format of the system documentation records held in the system storage area. FIG. 6 is a diagram showing the format of the user documentation record held in the user storage area; FIG.
9 shows a flowchart of the online documentation function, and FIG. 10 shows the system users and output record list generated for the online documentation function during the execution period. FIG.

[Table] Second means for providing the station to the other user of the system

Claims (1)

[Scope of Claims] 1. A method performed by an online documentation program executing in a computer system, the method comprising: In a method adapted to display online documentation, a user-specific online documentation associated with a particular online documentation command is received from each of a plurality of users of the system. the user-specific online documentation previously received from the user for each of the plurality of users when the user issues a particular online documentation command; A method of online documentation, characterized in that it consists of steps for displaying. 2. The method as claimed in claim 1, further comprising: providing a method for associating a specific documentation command to each other user of the system when the other user issues a specific documentation command; 1. A method of online documentation, the method comprising the step of displaying system documentation that has been previously defined. 3. In the method set forth in claim 2, the computer system provides information indicating how user-specific documentation is displayed to each of a plurality of users, and the user uses the system documentation for that purpose. an online system comprising means for storing information different from the documentation, the first display step including the step of generating user-specific documentation in response to the system documentation and the information;・Documentation method. 4. The method of claim 3, wherein the information includes one or more documentation texts and each user documentation text being used by the system to generate user-specific documentation. An online program featuring instructions on how to combine the documentation.
Documentation method.