WO1990012362A1

WO1990012362A1 - Controller for a space management program

Info

Publication number: WO1990012362A1
Application number: PCT/US1990/001740
Authority: WO
Inventors: Wayne L. Allred
Original assignee: A.C. Nielsen Company
Priority date: 1989-04-10
Filing date: 1990-04-02
Publication date: 1990-10-18
Also published as: AU5403990A; PT93703A

Abstract

A controller (10, 12) is shown for a system that is operable in accordance with a main program (14) to perform a plurality of operations wherein the main program (14) requires a plurality of user input commands to perform each operation. When the controller is executed, a transaction file (26) is set up that includes a plurality of command lines entered on a keyboard (16) by a user wherein each command line defines one operation to be performed by the main program. The controller (10, 12) then translates each command line in the transaction file to generate command codes required by the main program (14) to perform the operations defined by the command lines in the transaction file (26). The controller (10, 12) stores the generated command codes in a command file (28). After the command file (28) is generated, the controller (10, 12) runs the main program (14) to perform the operations defined by the command lines in the transaction file (26) using the command file (28) wherein the controller issues a generated input command code for the main program (14) when the main program requires the input command during the running thereof.

Description

CONTROLLER FOR A SPACE MANAGEMENT PROGRAM TECHNICAL FIELD The present invention relates to a controller for a system operable in accordance with a main com- puter program to perform various operations each of which requires a number of user input commands and more particularly to such a controller that automatic¬ ally generates the user input commands for each opera¬ tion selected by a user and thereafter automatically runs the main program.

BACKGROUND OF THE INVENTION Many computer programs require a number of inputs prior to the running of the program. A large amount of time can be consumed by this inputting pro- cess since programs are often set up to first ask a user to enter one input and after the user enters that one input the program requests the user to enter a second input depending on the status of the first input and so on. Further, computer programs are often repetitively run for a number of different data files having some common data. In order to change data common to a number of data files, each file must be individually loaded into a working memory and changed. This repetitious process makes the change operation both time-consum ng and tedious.

One type of program that requires a number of user inputs to run is a space management type of program such as SPACEMAN ™ from Logistics Data Systems, Inc. This space management program generates a planogram which is a layout of objects such as gro¬ cery products on a structure such as a shelving fix¬ ture. The space management program enables a user to find the layout that will be optimal for his purposes and to view an image of the layout on a display to see how the products will look without requiring him to physically stock shelves. A user of this space management program can make slight changes to the layout and see from reports that are generated by the space management program, the effects of those changes on profits, movement, etc. For users having a number of stores carrying the same products, the inputting process to change, for example, the position of a product or the number of facings of a product in each planogram for each store can be extremely time-consum¬ ing and repetitive.

SUMMARY OF THE INVENTION

In accordance with the present invention, the disadvantages of the inputting process associated with prior computer programs such as a space management program have been overcome. The controller of the present invention automatically generates the user input commands required by a main program to perform each of a number of operations defined by a user input command line and thereafter automatically runs the main program utilizing the generated user input com¬ mands.

More particularly, the controller of the present invention includes means for setting up a transaction file that includes a plurality of command lines that are entered by a user on an input device such as a keyboard. Each command line defines an operation performed by the system in accordance with the main program wherein the main program requires a plurality of user input commands in order to perform each operation. Each of the command lines includes at least one keyword, wherein different combinations of keywords define different operations of the main program. Further, the same command line may define ⁵ different operations of the main program depending on variations in one or more command lines preceding it. After the transaction file of command lines is set up, the controller automatically generate codes repre¬ senting at least one control command and the user 0 input commands required by the main program to perform each operation defined by the command lines in the transaction file. The generated codes are stored in a command file. After the command file is complete, the controller, in response to a control command code 5 runs the main program to perform the operations defined by the command lines in the transaction file utilizing the input command codes stored in the command file wherein the controller issues an input command code from the command file whenever the main program re¬ 0 quires a user input command during the running thereof.

In addition to automatically generating control command codes and user input command codes, the controller of the present invention automatically performs an error check to check the validity of each ⁵ command line in the transaction file. If an invalid command line is found, then no command codes are gener¬ ated for the invalid command line or for any command lines subsequent thereto in the transaction file. Further, the controller automatically generates an

- ^ error report identifying the invalid command line and the nature of the error to aid the user in correcting the problem. The controller automatically generates an information report regardless of whether the trans¬ action file includes errors or not, the information

³⁵ report identifying the operations that took place during the controller execution as well as identifying the operations that took place during the execution of the main program.

Although the controller of the present inven¬ tion may be used to simplify the inputting process ⁵ for any computer program, the controller is particular¬ ly well suited for space management programs wherein the operations executed by the space management program relate to a planogram file that includes a layout of objects with respect to a structure and a listing of

10 information associated with each of those objects. In accordance with the present invention one command line, when translated by the controller, generates the user input codes or keystrokes required by the space management program to load a planogram file 5 from a hard memory such as a disk into a working memory of the computer system. Another command line, when translated by the controller, generates the codes necessary to perform a change operation in regard to an object in the planogram that is loaded into the

20 working memory. The change operation may vary the number of facings of the object, the sales of the object, the profit of the object, the movement of the object, the presence of the object in the layout and in the listing, the manufacturer of the object, the - description of the object, the color of the object, the price of the object, the case cost of the object or the market of the object. Another command line, when translated, generates the codes to automatically position an object in the planogram layout.

- ^Q Still another command line, when translated, generates the codes to call a particular subroutine during the running of the main program and to create a report with the results of the subroutine, the command line further generating any user.input command codes re-

- - quired by the subroutine. A pair of command lines, when translated, generate the code necessary to get a particular data base file from a disk and to retrieve data records from that data base file to update a loaded planogram. A further pair of command lines identify a start and an end load loop with a number of planogram files being identified in the start load ⁵ loop command line. When another command line defining an operation to be performed is interposed between the loop command lines , the translation of these command lines generates the codes to load each plano¬ gram file and to perform the operation defined by the 0 interposed command line(s) so that each of the piano- grams identified in the start load loop command line is automatically operated on in response to as few as three command lines entered by a user. Still a further command line, when translated, generates the codes 5 necessary to output data to an output device such as a printer or plotter and to control the actuation of the output device.

The controller of the present invention is extremely user-friendly and minimizes the time neces¬ 0 sary for inputting information required by a main program to run since the controller automatically generates codes representing the user input commands that are required by the main program. The controller further allows a large number of data files to be 5 ' maniupulated using the load loop which requires the user to enter as few as three command lines.

These and other objects, advantages and novel features of the present invention, as well as details of an illustrated embodiment thereof, will be - - more fully understood from the follow description and the drawing.

BRIEF DESCRIPTION OF THE DRAWING FIG. 1 is a block diagram of a system utiliz¬ ing the controller of the present invention; ³⁵ FIG. 2a is a front view plot of a planogram layout generated by the system of FIG. 1; FIG. 2b is a side view plot of the shelving fixture shown in FIG. 2a;

FIG. 3 is a flow chart illustrating the controller of the present invention;

FIG. 4 is a flow chart illustrating the controller's translation of a LOAD keyword;

FIG. 5 is a flow chart illustrating the controller's translation of a SAVE keyword;

FIG. 6 is a flow chart illustrating the controller's translation of a CHANGE keyword;

FIG. 7 is a flow chart illustrating the controller's translation of a POSITION keyword;

FIG. 8 is a flow chart illustrating the controller's translation of an EVALUATE keyword;

FIG. 9 is a flow chart illustrating the controller's translation of an OPTIMIZE keyword;

FIG. 10 is an illustration of the control¬ ler's translation of a GDCONFIGURE keyword and related GD-keywords;^*

FIG. 11 is a flow chart illustrating the controller's translation of a DRAW keyword;

FIG. 12 is a flow chart illustrating the controller's translation of a REPORT keyword;

FIG. 13 is a flow chart illustrating the controller's translation of the VIDEO OUTPUT keywords;

FIG. 14 is a flow chart illustrating the controller's translation of the FILES and ENDFILES keywords; and

FIG. 15 is a flow chart illustrating the translation of a DIRECTORY keyword.

DESCRIPTION OF THE PREFERRED EMBODIMENT

As shown in FIG. 1, a central processing unit (CPU) 10 operating in accordance with the control¬ ler of the present invention automatically runs a main program 14 and generates the user input command codes necessary therefore without user intervention after the inputting of a series of valid command lines. As used herein, a command line is a one sentence type of command entered via a keyboard 16 on a single line that includes one or more keywords wherein the key¬ words, alone or in combination, define an operation performed by the main program that requires multiple user inputs. A user input is information entered via the keyboard 16 on one line and is formed of one or more keystrokes. In effect, a command line is a par¬ ticular type of user input. The controller 12 and main program 14 are stored in a hard memory or disk 18 along with the data files 20 used by the controller 12 and main program 14 and along with the operating system 22. A random access memory 24 is employed to temporarily store various files as well as to provide an area in which data is manipulated.

Once the controller 12 is called, the CPU 10, in accordance therewith, is responsive to the entry of a file name and command lines via the keyboard 16 to set up a transaction file 26 in the RAM 24 where¬ in the transaction file 26 is a listing of each command line entered. Once the transaction file 26 is set up, the controller 12 as discussed in detail below translates each command line in the transaction file to generate control command codes and input command codes that are required by the main program 14 to perform the operations defined by the command lines in the transaction file 26. The generated command codes are stored in a command file 28. In response to a control command code, the controller 12 runs the main program 14 to perform the operations defined by the command lines in the transaction file utilizing the user command codes stored in the command file 28, the controller 12 issuing a particular command code as required by the main program 14 during the running thereof. The controller 12 further creates a report file 30 which includes both an error report and an information report. Prior to the translation of each command line, the controller 12 checks the validity of the command line. If a command line is found to be invalid, an error report is generated identifying the invalid command line and the nature of the error. Thereafter, the controller 12 does not translate any subsequent command lines contained in the transaction file 26 but checks the remaining command lines for validity and updates the error report contained in the report file 30. If no errors are found in the command lines of the transaction file 26, the control¬ ler 12 still generates an information report in the report file 30 wherein the information report identi¬ fies the operations that were carried out during the execution of the controller 12. The controller 12 also creates a transaction map file 32. The transac¬ tion map file 32 maps errors that occur during the running of the main program 14 back to the transaction file 26.

The controller 12 as shown in detail in FIG. 3, operates as follows. The controller 12 may be called at block 33 by entering a command line via the keyboard 16 that comprises the name of the control¬ ler program followed by the names of the transaction file, the command file and the report file to which the CPU 10 responds at block 34 by setting up the transaction file. Alternatively, the controller may be called by simply entering the controller's program name to which the controller 12 responds by requesting that the user enter a file name for the transaction file 26. Upon entering a transaction file name, the CPU 10 in accordance with the controller 12 automatic¬ ally generates names for the command file 28 and the report file 30 wherein these respective names are formed of the transaction file name and different file name extensions. Thereafter, the CPU 10 sets up the transaction file 26 at block 34 by storing each command line entered via the keyboard 16 under the name of the entered transaction file 26. A further method of starting the execution of the controller requires the user to enter a command line that includes the controller's program name followed by a command that instructs the CPU 10 to execute the controller 12 at a particular later time.

After setting up the transaction file at block 34, the CPU 10 at block 36 defines a reference point to be used by the controller during the transla¬ tion of each command line. At a block 38, the CPU 10 sets Y equal to 1 and at a block 40 determines whether command line Y is valid or not. If the command line Y is valid, the CPU 10 at block 42 translates the command line Y to generate the control command and user command codes necessary for the main program to perform the operation defined by the command line Y and stores the generated codes in the command file 28. Thereafter, at a block 44, the CPU updates the report file 30 with information regarding the command line Y and at block 46 increments the variable Y by 1. The CPU, at block 48 determines whether the end of the transaction file has been reached and if not returns to block 40 to determine whether the next command line is valid or not. After each of the com¬ mand lines of the transaction file 26 are generated so that the command file 28 is complete, the CPU 10, at block 50 runs the main program 14 using the gener¬ ated command codes in the file 28.

If the CPU 10 determines at block 40 that the command line Y is not valid, the CPU 10 goes to block 52 and stores an error code for line Y in the report file 30 wherein the error code identifies the nature of the error in command line Y. At block 52, the CPU also increments an error counter to enable the report file 30 to provide the total number of errors found. Thereafter, at block 54 the CPU incre¬ ments the variable Y by 1 and at block 56 determines whether the end of the transaction file 26 has been reached. If the CPU determines that the end of the transaction file 26 has not been reached, the CPU 10 proceeds to block 58 to determine whether the next command line is valid or not. If the next command line is invalid, the CPU returns to block 52 to update the error report 30; whereas, if the next command line is valid, the CPU returns to block 54 to increment Y. When the CPU determines at block 56 that the end of the transaction file 26 has been reached, the CPU 10 at a block 60 controls a display 62 to display the error report. As can be seen, the controller 12 will not generate the complete command file 28 if even one error in the transaction file is found, the branch 64 to block 52 inhibiting the generation of the command file 28.

The following discussion of the translation operation 42 of the controller 12 and the validity of command lines will be specific for a controller for a space management type of main program 14. The space management program 14 manipulates planogram files that are stored in the data file section 20 of the disk portion 18 of the system's memory. Each planogram file includes a planogram layout of a number of ob¬ jects, such as grocery products 64-84, with respect to a structure such as a shelving fixture 90 shown in FIGS. 2a and 2b. Each planogram file also includes a chart that is a listing of information associated with each product that may be placed in the planogram layout as discussed in detail below.

In order to run the space management program 14, a planogram file must first be loaded from the data file's section 20 of the memory 18 into a working area 100 of the RAM 24 by a LOAD command line shown in FIG. 4 or a FILES command line shown in FIGS. 14 and 15 and discussed in detail below. If a transaction file 26 is set up without one of these load command lines preceding an operating command line such as illustrated in FIGS. 6-13, the operating command line will be determined by the CPU 10 to be invalid at block 40 and the command file 28 for the transaction file 26 will not be generated.

A valid LOAD command line includes the key¬ word LOAD followed by the name of the planogram file to be operated on. As will be seen with reference to FIG. 4, the LOAD command line is an example of a com¬ mand line that defines different operations to be performed depending on the command lines that precede it, if any. When translating a LOAD command line, the CPU 10 in accordance with the controller 12, at a block 102 determines whether a planogram file is already loaded and if so, proceeds to block 104 to determine whether a save flag has been set or not. As shown in FIG. 5, the CPU 10 sets a save flag at a block 106 in response to a SAVE command line. If the CPU determines at block 104 that the save flag has been set, the CPU 10 at block 108 goes to the reference point defined at block 36 in FIG. 3, and generates the keystrokes, i.e., command codes, necessary to open a file to save the planogram that is already loaded. These keystrokes are saved in the command file 28. Thereafter, at a block 110, the CPU 10 creates a name for the planogram file to be saved and at block 112 generates the keystrokes to complete the SAVE operation with the planogram file saved in a file under the name created at block 110. The key¬ strokes generated at block 112 are then saved in the command file 28. If at block 104, the CPU 10 deter¬ mines that the save flag has not been set, the CPU 10 at block 114 goes to the reference point and generates the "no save" keystrokes which are saved in the command file 28. After the CPU generates the save or no save keystrokes at respective blocks 112 and 114, the CPU proceeds to block 116. At block 116, the CPU 10 deter- mines whether the new planogram file specified in the LOAD command line exists or not. If the specified planogram file does not exist, the CPU goes to block 52 (FIG. 3) to generate an error report. However, if the specified planogram file does exist, the CPU 10 proceeds to block 118. The CPU 10 at block 118 goes to the reference point and generates the keystrokes to load the specified planogram file from the data files section 20 of the disk memory 18 into the working area 100 of the RAM 24.

One example of an operating command line that may follow a load command line is a CHANGE command line, the translation operation of which is depicted in FIG. 6. When translating a CHANGE command line, the CPU 10 determines at block 122 whether the command line is valid or not. A valid CHANGE command line includes the CHANGE keyword followed by a product ID, pid, followed by at least one more keyword representing a variable to be changed followed by rl which is a number or value or followed by str which is a string of characters to which the specified variable will be changed. For example, the following is a list of valid CHANGE command lines:

CHANGE pid FACINGS TO rl

CHANGE pid SALES TO rl

CHANGE pid PROFIT TO rl

CHANGE pid MOVEMENT TO rl

CHANGE pid MARKET TO rl

CHANGE pid REMOVE SHELF CHANGE pid REMOVE CHART

CHANGE pid MANUFACTURER TO str

CHANGE pid CATEGORY TO str

CHANGE pid DESCA TO str

CHANGE pid DESCB TO Str

CHANGE pid DESCC TO str

CHANGE pid DESCD TO Str

CHANGE pid COLOR TO il CHANGE pid PRICE TO rl

CHANGE pid CASECOST TO rl

If the CPU 10 at block 122 determines that the CHANGE command line is not valid, the CPU 10 goes to block 52 (FIG. 3) to generate the error report. If the CHANGE command line is determined to be valid at block 122, the CPU 10 determines at a block 124 whether the second keyword in the command line is FACINGS and if so proceeds to block 126 to generate the keystrokes to cause the space management program 14 to change the number of FACINGS of the product, pid, to the number, rl, and stores these keystrokes in the command file 28. Thereafter, the CPU 10 returns to the reference point. The number of facings of a product refers to the number of visible products on the shelf in the planogram layout. For example, with reference to FIG. 2a, there are three facings of the product 64, one facing of the product 65, four facings of the product 66, etc. If the CPU 10 determines that the second keyword in the CHANGE command line is SALES at a block 130, the CPU at a block 132 generates the keystrokes to change in the chart portion of the loaded planogram file the number of sales of the pro¬ duct, pid, to the number, rl, and stores these key- strokes in the command file 28. Thereafter, the CPU 10 goes to block 128. If the CPU determines at block 134 that the second keyword in the CHANGE command line is PROFIT, the CPU 10 proceeds to block 136 to generate the keystrokes necessary to change in the chart portion of the loaded planogram file the PROFIT of the product, pid, to the number, rl, and stores these keystrokes in the command file 28, thereafter returning to block 128. If the CPU 10 determines at block 138 that the second keyword in the CHANGE command line is the keyword MOVEMENT, the CPU 10 proceeds to block 140 to generate the keystrokes to CHANGE in the chart of the loaded planogram file, the information representing the movement of the product, pid, to the number, rl, and store these keystrokes in the command file 28, thereafter returning to block 128. If the CPU 10 determines at block 142 that the second keyword ⁵ in the CHANGE command line is the keyword MARKET, the CPU 10 at block 144 generates the keystrokes to change in the chart of the loaded planogram file the informa¬ tion regarding the market of product, pid, to the value, rl, and stores these keystrokes in the command ¹⁰ file 28, returning to block 128 thereafter. If the CPU 10 determines at block 146 that the second and third keywords in the command line are the keywords REMOVE SHELF, the CPU 10 a block 148 generates the keystrokes to remove the product, pid, from it's shelf l ~ in the planogram layout portion of the planogram file and stores these keystrokes in the command file 28, thereafter returning to block 128. If the CPU 10 determines at a block 150 that the second and third keywords in the CHANGE command line are REMOVE CHART,

20 the CPU 10 at block 152 generates the keystrokes to remove the product, pid, from both the chart and the planogram layout and stores these keystrokes in the command file 28, thereafter returning to block 128.

If the CPU 10 determines at block 154 that the second

² - keyword in the CHANGE command line is the keyword

MANUFACTURER, the CPU 10 at block 156 generates the keystrokes to change in the chart of the loaded plano¬ gram file the information identifying the manufacturer of the product, pid, to the string of characters,

³^ str, and stores these keystrokes in the command file 28, thereafter returning to block 128. If the CPU 10 determines at block 158 that the second keyword in the CHANGE command line is CATEGORY, the CPU 10 at block 160 generates the keystrokes to change in the ⁵ chart of the loaded planogram file the category infor¬ mation of the product, pid, to the string of charac¬ ters, str, and stores these keystrokes in the command file 28, thereafter returning to block 128. If the CPU 10 at block 162 determines that the second keyword in the command line begins with DESC, the CPU 10 pro¬ ceeds to block 163 to determine whether the next letter is A and if so, the CPU 10 at block 164 generates the keystrokes to change the first description of the product, pid, in the chart of the loaded planogram to the string of characters, str, and stores these key¬ strokes in the command file 28. If the letter B fol¬ lows DESC as determined by the CPU 10 at block 165, the CPU 10 at block 166 generates the keystrokes to change the second description of the product, pid, in the chart of the loaded planogram file to the character string, str, and stores these keystrokes in the command file 28. If the CPU determines at block 167 that the letter C follows DESC, the CPU 10 at block 168 gener¬ ates the keystrokes to change the third description of the product, pid, in the chart of the loaded plano¬ gram to the string of characters, str, and stores these keystrokes in the command file 28. If the CPU 10 determines at blocks 163, 165 and 167 that neither A, B or C follows DESC, the CPU 10 at block 170 gener¬ ates the keystrokes to change the fourth description of the product, pid, in the chart of the loaded plano¬ gram to the string of characters, str and stores these keystrokes in the command file 28. If the CPU 10 determines at block 172 that the second key word in the CHANGE command line is the keyword COLOR, the CPU 10 generates the keystrokes to change in the planogram chart and layout the color of the product, pid, to the color il and stores these keystrokes in the command file 28. The variable il represents an integer ranging from 1 to 7 wherein each integer represents a different one of the following colors: blue, green, cyan, red, purple, yellow and black. If, the CPU 10 determines at block 176 that PRICE is the second keyword in the CHANGE command line, at block 178, the CPU generates the keystrokes to change in the chart of the loaded planogram file the price of the product, pid, to the number, rl, and stores these keystrokes in the command file 28. If the CPU determines at block 176 that ⁵ PRICE was not the second keyword in the command line, the CPU 10 proceeds to block 180 to generate the key¬ strokes to change in the chart of the loaded planogram file the information representing the case cost of the product, pid, to the number, rl, and stores these 0 keystrokes in the command file 28, thereafter returning to block 128.

The keyword POSITION is translated by the CPU 10 in accordance with the controller 12 as depicted in FIG. 7. At block 182 the CPU 10 determines whether 5 the POSITION command line is valid or not and if the command line is invalid, the CPU goes to block 52 to generate an error report. The following are valid POSITION command lines:

POSITION pidl il i2 i3 0 POSITION pidl il i2 i3 SHELF sid POSITION pidl il i2 i3 BEFORE pid2 POSITION pidl il i2 i3 AFTER pid2 The keyword POSITION is used to position a product, pid, with orientation, il, having i2 number of facings - and a capping style of i3 on a shelf, sid, after the product that a cursor, depicted on the display 62, is pointing at or before or after a product, pid2. The capping style of the product determines whether the products are stacked on top of each other as depicted ⁰ for the products 84 in FIG. 2a or whether the products are stacked side-by-side as depicted for the products 83. To use the keyword POSITION, the product pid must exist in the chart portion of the planogram file that is loaded into the working area 100 of the RAM ⁵ 24. If the product pid is not in the chart, the

POSITION command line is determined to be invalid at block 182. If the POSITION command line is determined to be valid, the CPU 10 determines at block 184 whether the second keyword in the POSITION command line is SHELF. If the second keyword is SHELF the CPU 10 proceeds to block 186 to generate the keystrokes to ⁵ position i2 facings of the product pid with orientation il and capping style i3 on the shelf sid after the product on which the cursor of the display 62 is set. The CPU 10 at block 186 further stores these keystrokes in the command file 28. If the CPU 10 determines at ⁰ block 188 that the second keyword in the POSITION command line is the keyword BEFORE, the CPU 10 proceeds to block 190 to generate the keystrokes to position i2 facings of product pidl with orientation il and capping style i3 on the shelf before the product pid2.

1 5 The CPU 10 then stores these keystrokes in the command file 28. If the CPU 10 determines that the second keyword in the POSITION command line is the keyword AFTER at block 192, the CPU 10 proceeds to block 194 to generate the keystrokes to position i2 facings of

20 the product pidl with orientation il and capping style i3 on the shelf after the product pid2 and stores these keystrokes in the command file 28. If, the CPU 10 determines that POSITION is the only keyword in the POSITION command line, the CPU 10 proceeds from

- ^•■ block 192 to block 196 to generate the keystrokes necessary to position i2 facings of the product pidl with orientation il and capping style i3 at the default position specified in the space management program 14.

³^ The CPU 10 in accordance with the controller

12 translates the keyword EVALUATE in accordance with the flow chart depicted in FIG. 8. At block 200, the CPU 10 determines whether the EVALUATE command line is a valid command line. The following represents

- - the four possible valid command lines for EVALUATE: EVALUATE TO FILES fn EVALUATE TO FILES fn MESSAGE mesg EVALUATE TO PRINT Ipt? EVALUATE TO PRINT Ipt? MESSAGE mesg If the CPU 10 determines at block 200 that the EVALUATE command line is not valid, the CPU goes to block 52 5 (FIG. 3) to generate an error report. If the EVALUATE command line is determined to be valid at block 200, the CPU 10 at block 202 generates the keystrokes to call a financial^' analysis subroutine of the main pro¬ gram 14 to perform a financial analysis of the plano-

10 gram file loaded into the working area 100 of the RAM -24 and generates any user input codes required by the subroutine. At block 202, the CPU 10 also generates the keystrokes to create a report containing the re¬ sults of the financial analysis. The CPU then stores

- ~ the generated keystrokes in the command file 28. At block 204, the CPU 10 determines whether the keyword MESSAGE is contained in the command line and if so, the CPU 10 proceeds to block 206 to generate the key¬ strokes necessary to add the message, mesg, to the

²⁰ report created at block 202 after the header of the report and stores these keystrokes in the command file 28. At a block 208, the CPU 10 determines whether the keyword FILES is used in the command line and if so, proceeds to block 210 to generate the keystrokes

25 to send the report created to the file fn and stores these keystrokes in the command file 28. If the key¬ word FILES is not in the command line as determined by the CPU at block 208, the CPU 10 at block 212 gener¬ ates the keystrokes to send the report that is created

30 to a printer Ipt 214 wherein Ipt designates one of three possible printers that may be coupled to the CPU 10. The CPU 10 stores the keystrokes generated at block 212 in the command file 28.

FIG. 9 illustrates the translation operation

35 of a keyword OPTIMIZE. At block 216, the CPU 10 deter¬ mines whether the OPTIMIZE command line is valid or not and if not proceeds to block 52 (FIG. 3) to gener- ate an error report. A valid OPTIMIZE command line includes the keyword OPTIMIZE used alone or followed by variables a-f wherein "a" represents a particular type of financial mode, "b" represents an objective - basis or a cubic space basis, "c" represents whether one product may be split over two or more shelves, "d" determines what may be done with empty space on the shelves, "e" determines whether products are to be placed alphabetically within a particular zone, 0 and "f" determines whether an audit trail report is to be generated or not. If the OPTIMIZE command line is valid, the CPU 10 proceeds to block 218 to generate the keystrokes to call an optimization subroutine to reposition products on the shelves of the planogram ⁵ layout optimally according to the variables a, b, c, d, e and f if specified and to generate any user input command codes required by the subroutine. The CPU 10 further stores the generated keystrokes at block 218 in the command file 28. Thereafter, the CPU 10 deter-

²⁰ mines at block 220 whether the keyword FILES is used in the OPTIMIZE command line and if so proceeds to block 222 to determine whether a file fn is specified or not. If a file, fn is specified in the OPTIMIZE command line, the CPU 10 generates the keystrokes

~ ~ necessary to send the report that is generated in response to the keystrokes issued at block 218 to a file fn. If the keyword FILES is used in the command line, with the word "planogram", the CPU proceeds to block 225 to generate the keystrokes necessary to

30 send the report to a file having the same name as the loaded planogram file plus the extension "XXA". If the keyword FILES is not specified in the command line but the keyword PRINT is specified in the command line as determined by the CPU 10 at block 226, the

35 CPU 10 proceeds to block 228 to generate the keystrokes necessary to send the report to the printer lp 214. In order to change a planogram file stored in the working area 100 of the RAM 24 according to data stored in a particular data base file in the data files section 20 of the disk memory 18, two com- mand lines are required the first of which when trans¬ lated generates the keystrokes to get a particular file and the second of which when translated generates keystrokes to cause the loaded planogram file to be manipulated according to data in the retrieved data base file. The first command line is "GDCONFIGURE fl f2 f3" wherein fl represents the data base file name, f2 represents the index of the data base file and f3 represents the UPC index file of the data base file. In response to the keyword GDCONFIGURE, the CPU 10 at block 230 determines whether the GDCONFIGURE command line is valid or not. If the command line is not valid, the CPU 10 goes to block 52 to generate an error report. If the CPU 10 determines that the GDCONFIGURE command line is valid, the CPU 10 at block 232 generates the keystrokes to get the data base file fl with index file f2 and index file f3 and stores these keystrokes in the command file 28. At block 234 the CPU 10 determines whether the keyword GDSELECT follows the command line GDCONFIGURE and if so, at block 236 the CPU 10 determines whether the GDSELECT command line is valid or not. A valid GDSELECT command line is as follows, "GDSELECT fl ol dl f2 o2 d2 f3 o3 d3 f o4 d4" wherein f(n) represents the field identi¬ fication that the data is to be selected from; o(n) represents the operator to be used; and d(n) represents the data to be selected in field f(n) wherein four different groups may be specified. If the GDSELECT command line is valid, the CPU 10 proceeds to block 238 and sets y equal to the number of fields and n equal to 1. Thereafter, at block 240, the CPU 10 generates the keystrokes necessary to select records with field f (n) , operator o(n) and data d(n) to read the records from the data base into the chart portion of the loaded planogram file, these keystrokes being stored in the command file 28. Thereafter, at block 242, the CPU 10 increments the variable n and at block 5 244 determines whether n is greater than y, the number of fields specified in the GDSELECT command line. If n is less than or equal to y, the CPU returns to block 240 and if n is greater than y, the CPU proceeds to a block 246. At block 246, the CPU 10 determines whether 0 ^a GDUPDATE command line follows the GDCONFIGURE command line and if so proceeds to block 248. At block 248, the CPU 10 generates the keystrokes to update the information in the loaded planogram file for each product that matches a product in the data base file ₅ identified in GDCONFIGURE with the information stored in the data base file for the matched products. These keystrokes are then stored at block 248. Thereafter, at block 250 the CPU 10 determines whether the keyword GDSAVE follows the command line GDCONFIGURE. If so, 0 the CPU 10 at block 252 generates the keystrokes to save all of the products in the currently loaded plano¬ gram file in the data base file set up by the GDCON¬ FIGURE command line. At block 252 the block CPU 10 also stores these generated keystrokes. Thereafter, 5 the CPU 10 determines whether a GDDELETE command line follows the GDCONFIGURE command line. If so, the CPU 10 determines whether the GDDELETE command line is valid or not, a valid GDDELETE command line specifying a product, pid, after the GDDELETE keyword. If the 0 command line is determined to be valid at block 256, the CPU 10 at block 258 generates the keystrokes to delete the product, pid, from the data base file speci¬ fied in the command line GDCONFIGURE and to further delete the product, pid, from the loaded planogram m - file. These keystrokes are stored in the command file 28 at block 258. It is noted that the flow chart of FIG. 10 may be modified so that other command lines may be interspersed between the GDCONFIGURE command line and the other GD command line.

As shown in FIG. 11, the CPU 10 in accordance with the controller 12 translates the keyword DRAW as follows. At block 260, the CPU 10 determines whether the DRAW command line is valid or not. The keyword DRAW may be used alone to form a valid command line or the keyword DRAW may be followed by "2 2 1". If the CPU 10 determines that the DRAW command line is valid, at. block 260 the CPU 10 proceeds to block 262 to determine whether the "DRAW 2 2 1" command line is specified. If it is, at block 264 the CPU 10 generates the keystrokes to cause the layout of the planogram file that is loaded in the working area 100 of the RAM 24 to be plotted by a plotter 265 with the type of paper identified by the first variable "2" specified in the command line, the speed of the plotter identi¬ fied by the second variable "2" and the number of copies identified by the variable "1". At block 264 the CPU 10 stores the generated keystrokes in the command file 28. If at block 262, the CPU 10 deter¬ mines that the keyword DRAW is used alone, the CPU 10 proceeds to block 266 to generate the keystrokes neces¬ sary to cause the planogram to be plotted by the plot- ter 265 with the default settings specified in the space management program 14.

The CPU 10 translates a REPORT command line as depicted in FIG. 12. At block 268, the CPU 10 determines whether the REPORT command line is valid or not, valid REPORT command lines being as follows: REPORT rid TO FILES fn REPORT rid TO FILES fn MESSAGE mesg REPORT rid TO FILES planogram REPORT rid TO FILES planogram MESSAGE mesg REPORT rid TO PRINT Ipt?

REPORT rid TO PRINT Ipt? MESSAGE mesg Further, in order to use a REPORT command line, a printer 214 must be coupled to the CPU and memory or the command line will be interpreted as invalid. If the REPORT command line is valid, the CPU 10 proceeds to block 270 to determine whether the keyword MESSAGE is used in the REPORT command line and if so at block 272 the CPU 10 generates the keystrokes to add the MESSAGE, mesg, to the REPORT, rid, below the header thereof, the CPU 10 storing these keystrokes in the command file 28. Thereafter, at block 274, the CPU 10 determines whether the keyword FILES is used in the REPORT command line and if so, determines at block 278 whether a file name fn has been specified after the keyword FILES. If a file name fn has been speci¬ fied, the CPU proceeds from block 278 to block 282 to generate the keystrokes to write the report rl to the file fn storing these keystrokes in the command file 28. If at block 278, the CPU 10 determines that a file name fn has not been specified but that the word "planogram" is used in the command line, at block 280 the CPU generates the keystrokes to write the report rl to a file having the name of the loaded planogram plus the extension "XXR". If at block 274, the CPU 10 determines that the keyword PRINT is used in the command line, the CPU 10 at block 276 generates the keystrokes necessary to send the report, rid, to the printer, Ipt, the CPU 10 storing these keystrokes in the command file 28.

The keywords VIDEO OUTPUT are used to gener¬ ate a live file for a planogram that is loaded in the working area 100 wherein the live file is used to generate a computer generated photograph of the plano- gram layout. When translating a VIDEO OUTPUT command line, as shown in FIG. 13, the CPU 10 first determines whether the VIDEO OUTPUT command line is valid or not at block 284. The following are valid VIDEO OUTPUT command lines:

VIDEO OUTPUT

VIDEO OUTPUT REPLACE

VIDEO OUTPUT fn VIDEO OUTPUT REPLACE fn If the VIDEO OUTPUT command line is valid, at block 286 the CPU 10 determines whether the keyword REPLACE is used in the command line or not. If the keyword REPLACE is used in the command line, at block 288 the CPU 10 determines whether there is an old live file for the loaded planogram. If so, the CPU 10 at block 290 generates the keystrokes to replace the old live file with a new live file and stores these keystrokes in the command file 28. If at block 288 the CPU 10 determines that no old live file exists, the CPU 10 proceeds to block 298 to issue the keystrokes to create a live file and stores these keystrokes in the command file 28. If at block 286, the CPU 10 determines that the keyword REPLACE is not used in the command line, the CPU 10 proceeds to block 296 to determine whether an old live file for the loaded planogram file exists. If such an old live file does exist and the REPLACE keyword is not used, a new live file will not be created so that the CPU 10 returns from this routine at block 297. If, however, the CPU 10 determines at block 296 that an old live file does not exist, at block 298 the CPU 10 issues the keystrokes to create a live file for the loaded planogram, storing these keystrokes in the command file 28. From blocks 290 or 298, the CPU 10 proceeds to block 292 to determine whether a file name fn has been specified in the VIDEO OUTPUT command line and if so, at block 294 generates the keystrokes to name the live file, fn, and stores these keystrokes in the command file 28.

A FILES/ENDFILES command line loop used alone or in combination with a DIRECTORY command line allows a number of planograms to be automatically altered or manipulated in accordance with one or more operating command lines that are interposed between the FILES command line and the ENDFILES command line. More particularly in a FILES command line, the keyword FILES is followed by two or more planogram file names or wild cards that describe the files to be operated on. A wild card may be such as "HOUSE*.PLN" which represents all those planogra s having file names that begin with "HOUSE" and end with the extension "PLN". After the FILES command line, one or more operating command lines, such as described with refer¬ ence to FIGS. 6-13, are specified, the loop ending with an ENDFILES command line. If FILES is not fol- lowed by an ENDFILES command line, the FILES command line will be interpreted as invalid.

The CPU 10 translates a FILES command line as follows with reference to FIG. 14. At block 300, the CPU 10 determines whether the FILES command line is valid or not. For example, the CPU 10 determines whether the planogram files specified after the keyword files exist or not and whether there is an ENDFILES command line in the transaction file 26 subsequent to the FILES command line. If the FILES command line is valid, the CPU 10 at block 302 defines the variable X as being equal to the number of planogram files and Z as being equal to the number of command lines between the FILES command line and the ENDFILES command line. At block 302 the CPU 10 also sets the variables Y equal to 1 and N equal to 1. Thereafter, at block 304, the CPU 10 generates the keystrokes to load the planogram file Y and stores these keystrokes in the command file 28. At block 306 the CPU 10 translates the command line N and stores the generated keystrokes in the command file 28. At block 308, the CPU 10 increments the variable N by 1 and at block 310 deter¬ mines whether N is greater than Z. If N is less than or equal to Z, the CPU 10 returns to block 306 to translate the next command line. If N is greater than Z, the CPU 10 at block 312 increments the variable Y by 1 and at block 314 determines whether Y is greater than X. If Y is less than or equal to X, the CPU 10 returns to block 304 and if Y is greater than X, the files loop is ended.

The keyword DIRECTORY as translated by the CPU 10 in accordance with the flow chart shown in FIG. 15 can only be used with a FILES command line following it. No other command lines can be interposed between the DIRECTORY command line and the FILES com¬ mand line. One valid DIRECTORY command line is "DIRECTORY AREA001/REGION 001/STORE*.*" which instructs the CPU 10 to look in DIRECTORY AREA 001 which looks in DIRECTORY REGION 001 using all directories that begin with STORE. A second valid DIRECTORY command line is "DIRECTORY AREA011/REGION004/STORE1?0.*" which instructs the CPU 10 to look in DIRECTORY AREA 011 which looks in DIRECTORY REGION 004 using all di¬ rectories that begin with "STORΞ 1?0" wherein the "?" is a DOS files naming convention.

As shown in FIG. 15, at block 316 the CPU 10 determines whether the DIRECTORY command line is valid or not. That is, the CPU 10 at block 316 deter¬ mines whether the DIRECTORY command line itself is valid and whether a valid FILES command line loop directly follows the DIRECTORY command line. If the DIRECTORY command line is determined to be valid at block 316, the CPU 10 at block 318 defines X as being equal to the number of files specified in the FILES command line; Z as being equal to the number of command lines between the FILES command line and the ENDFILES command line; and defines D as being equal to the number of directories specified in the DIRECTORY com¬ mand line. At block 318, the CPU 10 also sets the variables Y equal to 1, N equal to 1 and P equal to 1. At block 320, the CPU 10 determines whether the planogram file Y is in directory P and if so, proceeds to block 322 to generate the keystrokes necessary to load the planogram file Y in directory P, storing these keystrokes in the command file 28. Thereafter, at block 324 the CPU 10 translates the command line _N and stores the keystrokes generated during the trans¬ lation in the command file 28. At block 326, the CPU 10 increments the variable N by 1 and at block 328 ⁵ determines whether N is greater than Z. If N is less than or equal to Z, the CPU 10 returns to block 324 and if N is greater than Z, the CPU 10 proceeds to block 330 to increment Y by 1. From block 330, the CPU 10 proceeds to block 332 to determine whether the

10 variable Y is greater than X. If Y is less than or equal to X, the CPU 10 proceeds to block 320 to deter¬ mine whether the planogram file Y is in the directory P. If Y is determined to be greater than X at block 332, the CPU 10 at block 334 increments P by 1 and at

- - block 336 determines whether P is greater than D. If the CPU 10 at block 336 determines that P is less than or equal to D, the CPU 10 sets Y equal to 1 at block 338 and returns to block 320. If, however, the CPU 10 determines that P is greater than D, the CPU

20 ιo exits at block 340.

Many modifications and variations of the present invention are possible in light of the above teachings. Thus, it is to be understood that, within the scope of the appended claims, the invention may

25 be practiced otherwise than as described hereinabove. What is claimed and desired to be secured by Letters Patent is:

30

35

Claims

Claims:

1. A controller for a system operable in accordance with a main program to perform a plurality of operations, a plurality of user input commands being required by said main program for said system to perform each of said operations, said system includ¬ ing input means for entering said user inputs, compris¬ ing: means for setting up a file including a plurality of command lines entered on said input means, each command line defining one of said operations; means responsive to said file of command lines for automatically generating codes representing at least one control command and said input commands required by said main program to perform each operation defined by said command lines in said file; and

- means responsive to a control command code for running said main program to perform said opera¬ tions defined by said command lines in said file, said running means issuing a generated input command code for said main program when said main program requires said input command during the running thereof.

2. A controller for a system operable in accordance with a main program as recited in claim 1 wherein each of said command lines includes at least one keyword, different combinations of keywords defin¬ ing different operations of said main program and said code generating means generating different combi¬ nations of codes for different combinations of key¬ words.

3. A controller for a system operable in accordance with a main program as recited in claim 1 wherein said code generating means generates a differ¬ ent combination of user input codes for a first command line in response to variations in at least one command line preceding said first command line.

4. A controller for a system operable in acordance with a main program as recited in claim 1 including means responsive to the setting up of said file for checking the validity of each of said command lines.

5. A controller for a system operable in accordance with a main program as recited in claim 4 including means responsive to a finding of an invalid command line by said validity checking means for in¬ hibiting said code generating means from generating codes for said invalid command line.

6. A controller for a system operable in accordance with a main program as recited in claim 5 wherein said inhibiting means inhibits said code gener¬ ating means from generating codes for all command lines in said file subsequent to said invalid command line.

7. A controller for a system operable in accordance with a main program as recited in claim 4 including means responsive to a finding of an invalid command line by said validity checking means for gener¬ ating an error report.

8. A controller for a system operable in accordance with a main program as recited in claim 1 including means responsive to the running of said main program for generating a report including infor¬ mation relating to the operations carried out during the running of said main program.

9. A controller for a system operable in accordance with a main program as recited in claim 1 wherein said system includes a working memory means for storing data to be manipulated and means for stor- ing a data file and said plurality of command lines includes a load command line identifying one of said stored data files and at least one other command line, said code generating means in response to said load command line generating the command codes required by said main program to load said identified data file from said storing means to said working memory means and in re _*sponse to said other command line generating the command codes required by said main progam to perform on said loaded data file the operation defined by said other command line.

10. A controller for a system operable in accordance with a main progam as recited in claim 1 wherein said system includes a working memory for storing data to be manipulated and means for storing a plurality of data files and said plurality of command lines includes a start load loop command line identi¬ fied a plurality of said stored data files, an end of load loop command line and at least one other command line interposed between said start load loop command line and said end of load loop command line, said code generating means being responsive to said start load loop command line to generate the command codes required by said main program to load an identified data file and to perform the operation defined by said at least one other command line for each identi¬ fied data file.

11. A controller for a system operable in accordance with a main program as recited in claim 1 wherein said main program is a space management program and said plurality of operations relate to a planogram including a layout of objects with respect to a struc¬ ture and a listing of information associated with each of said objects, the system including means for storing said planogram.

12. A controller for a system operable in accordance with a space management program as recited in claim 11 wherein said system includes a working memory and one of said operations includes a loading operation that loads a planogram into said working memory from said storage means, said code generating means being responsive to a first command line to generate codes to perform said loading operation.

13. A controller for a system operable in accordance with a space management program as recited in claim 12 wherein one of said operations includes a change operation that changes at least one variable associated with an object in said planogram loaded into said working memory, said code generating means being responsive to a second command line to generate codes to perform said change operation.

14. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the number of facings of said object.

15. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the number of sales of said object.

16. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the profit of said object.

17. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the movement of said object.

18. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the presence of said object in said layout.

19. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the presence of said object in said layout and said listing.

20. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the manu¬ facturer of said object.

21. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes a descrip¬ tion of said object.

22. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the color of said object.

23. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the price of said object.

24. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the case cost of said object.

25. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said variable includes the market associated with said object.

26. A controller for a system operable in accordance with a space management program as recited in claim 13 wherein said second command line includes a first keyword defining said change operation, a second keyword defining said variable and an object identification.

27. A controller for a system operable in accordance with a space management program as recited in claim 12 wherein one of said operations includes a position operation that positions an object in said planogram loaded into said working memory, said code generating means being responsive to a second command line to generate codes to perform said position opera¬ tion.

28. A controller for a system operable in accordance with a space management program as recited in claim 12 wherein one of said operations includes a financial analysis of said planogram loaded into said working memory, said code generating means being re¬ sponsive to a second command line to generate codes to perform said financial analysis and to create a report with the results of said financial analysis.

29. A controller for a system operable in accordance with a space management program as recited in claim 12 wherein one of said operations includes the calling of a subroutine of said main space manage¬ ment program, said code generating means being respon¬ sive to a second command line to generate codes to call said subroutine and to create a report with the results of said subroutine and to generate codes repre- senting any user input commands required by said sub¬ routine.

30. A controller for a system operable in accordance with a space management program as recited in claim 12 wherein said storage means stores a data base file and one of said operations includes the loading of a data base file in said working memory and another of said operations includes the retrieval of information from said data base file, said code generating means being responsive to a second command line to generate codes to perform said data base file loading operation and to a third command line to gener¬ ate codes to retrieve information from said data base file and to update said loaded planogram with said retrieved information.

31. A controller for a system operable in accordance with a space management program as recited in claim 12 wherein said system includes an output means for providing a hard record of at least a portion of said planogram and one of said operations includes an output operation that outputs data to said output means and controls the actuation thereof, said code generating means being responsive to a second command line to generate codes to perform said output opera¬ tion.

32. A controller for a system operable in accordance with a space management program as recited in claim 11 wherein said storage means stores a plur¬ ality of planograms said code generating means being responsive to a first command line identifying a plur¬ ality of planograms and a start of a loop, at least one second command line defining an operation to be performed and a third command line identifying a loop end for generating codes for each planogram identified to load the planogram identified in said first command and to perform said operation for said loaded planogram defined by said at least one second command.

33. A controller for a system operable in accordance with a main program to perform a plurality of operations, a plurality of user input commands being required by said main program for said system to perform each of said operations, said system includ¬ ing input means for entering said user inputs, compris¬ ing: means for setting up a file including a plurality of command lines entered on said input means, each of said command lines including one or more key¬ words that define one of said operations; means for generating codes representing the user input commands required by said main program to perform said operation defined by the keywords of each of said command lines; means for storing said generated codes; and means for running said main program with said stored codes.

34. A controller for a system operable in accordance with a main program as recited in claim 33 wherein said main program is a space management program and said plurality of operations relate to a planogram including a layout of objects with respect to a struc¬ ture and a listing of information associated with each of said objects, the system including means for storing said planogram.

35. A controller for a system operable in accordance with a space management program as recited in claim 34 wherein said system includes a working memory and one of said operations includes a loading operation that loads a planogram into said working - - memory from said storage means, said code generating means being responsive to a first command line to generate codes to perform said loading operation.

36. A controller for a system operable in accordance with a space management program as recited in claim 35 wherein one of said operations includes a change operation that changes at least one variable associated with an object in said planogram loaded into said working memory, said code generating means being responsive to a second command line to generate codes to perform said change operation.

37. A controller for a system operable in accordance with a space management program as recited in claim 36 wherein said second command line includes a first keyword defining said change operation, a second keyword defining said variable and an object identification.

38. A controller for a system operable in accordance with a space management program as recited in claim 35 wherein one of said operations includes a position operation that positions an object in said planogram loaded into said working memory, said code generating means being responsive to a second command line to generate codes to perform said position opera¬ tion.

39. A controller for a system operable in accordance with a space management program as recited in claim 35 wherein one of said operations includes a financial analysis of said planogram loaded into said working memory, said code generating means being re¬ sponsive to a second command line to generate codes to perform said financial analysis and to create a report with the results of said financial -analysis.

40. A controller for a system operable in accordance with a space management program as recited in claim 35 wherein one of said operations includes the calling of an optimization subroutine of said main space management program, said code generating means being responsive to a second command line to generate codes to call said subroutine and to create a report with the results of said subroutine and to generate codes representing the user input command required by said subroutine.

41. A controller for a system operable in accordance with a space management program as recited in claim 35 wherein said storage means stores a data base file and one of said operations includes the loading of a data base file in said working memory and another of said operations includes the retrieval of information from said data base file, said code generating means being responsive to a second command line to generate codes to perform said data base file loading operation and to a third command line to gener¬ ate codes to retrieve information from said data base file and to update said planogram with said retrieved information.

42. A controller for a system operable in accordance with a space management program as recited in claim 35 wherein said system includes an output means for providing a hard record of at least a portion of said planogram and one of said operations includes an output operation that outputs data to said output means and controls the actuation thereof, said code generating means being responsive to a second command line to generate codes to perform said output opera¬ tion.

43. A controller for a system operable in accordance with a space management program as recited in claim 34 wherein said storage means stores a plur¬ ality of planograms said code generating means being responsive to a first command line identifying a plur¬ ality of planograms and a start of a loop, at least one second command line defining an operation to be performed and a third command line identifying a loop end for generating codes for each planogram identified to load the planogram identified in said first command and to perform said operation for said loaded planogram defined by said at least one second command.

44. A controller for a system operable in acordance- with a main program as recited in claim 33 including means responsive to the setting up of said file for checking the validity of each of said command lines.

-45. A controller for a system operable in accordance with a main program as recited in claim 44 including means responsive to a finding of an invalid command line by said validity checking means for in¬ hibiting said code generating means from generating codes for said invalid command line.

46. A controller for a system operable in accordance with a main program as recited in claim 45 wherein said inhibiting means inhibits said code gener¬ ating means from generating codes for all command lines in said file subsequent to said invalid command line.

47. A controller for a system operable in accordance with a main program as recited in claim 44 including means responsive to a finding of an invalid command line by said validity checking means for gener¬ ating an error report.

48. A controller for a system operable in accordance with a main program as recited in claim 33 including means responsive to the running of said main program for generating a report including informa¬ tion relating to the operations carried out during the running of said main program.

49. A controller for a system operable in accordance with a main program as recited in claim 33 wherein said system includes a working memory means for storing data to be manipulated and means for stor¬ ing a data file and said plurality of command lines includes a load command line identifying one of said stored data files and at least one other command line, said code generating means in response to said load command line generating the command codes required by said main program to load said identified data file from said storing means to said working memory means and in response to said other command line generating the command codes required by said main progam to perform on said loaded data file the operation defined by said other command line.

50. A controller for a system operable in accordance with a main progam as recited in claim 33 wherein said system includes a working memory for storing data to be manipulated and means for storing a plurality of data files and said plurality of command lines includes a start load loop command line identi¬ fied a plurality of said stored data files, an end of load loop command line and at least one other command line interposed between said start load loop command line and said end of load loop command line, said code generating means being responsive to said start load loop command line to generate the command codes required by said main program to load an identified data file and to perform the operation defined by said at least one other command line for each identi¬ fied data file.

51. A controller for a system operable in accordance with a main program to perform a plurality of operations, a plurality of user input commands being required by said main program for said system to perform each of said operations, said system includ¬ ing input means for entering said user inputs, compris¬ ing: means for setting up a file including a plurality of command lines entered on said input means, each command line defining one of said operations; and means responsive to each of said command lines for generating codes representing the user input commands required by said main program to perform said operation defined by said command line, said generating means generating a different combination of user input command codes for a first command line in response to variations in at least one command line preceding said first command line.

52. A controller for a system operable in accordance with a main program to perform a plurality of operations, a plurality of user input commands being required by said main program for said system to perform each of said operations, said system includ¬ ing input means for entering said user inputs, compris¬ ing: means for setting up a file including a plurality of command lines entered on said input means, each command line including one or more keywords defin¬ ing one of said operations; and raeans responsive to each of said command lines for automatically generating codes representing the user input commands required by said main program to perform said operation defined by said command line, said generating means generating a different combination of user input command codes for a first command line having one keyword and a second command line having said one keyword in combination with a second keyword.

53. A method of controlling the execution of a main program by a system to perform a plurality of operations, a plurality of user input commands being required by said main program to perform each of said operations, said system including input means for entering user inputs, comprising: setting up a file including a plurality of command lines entered on said input means, each command line defining one of said operations; generating codes representing said user input commands required by said main program to perform each operation defined by said command lines in said file; and running said main program to perform said operations defined by said command lines in said file using said generated codes.

54. A method of controlling the execution of a main program by a system as recited in claim 53 wherein each of said command lines includes at leat one keyword, different combinations of codes being generated for different combinations of keywords.

55. A method of controlling the execution of a main program by a system as recited in claim 53 wherein different combinations of user input codes are generated for a first command line in response to variations in at least one command line preceding said first command line.

56. A method of controlling the execution of a main program by a system as recited in claim 53 further including the step of checking the validity of a command line before generating the codes there¬ for.

57. A method of controlling the execution of a main program by a system as recited in claim 53 further including the step of generating a report including information relating to operations carried out during the running of said main program.

58. A method of controlling the execution of a main program by a system as recited in claim 53 wherein said system includes a working memory means for storing data to be manipulated and means for stor¬ ing a data file and said plurality of command lines includes a load command line identifying one of said stored data files and at least one other command line, and wherein said generating step generates in response to said load command line the command codes required by said main program to load said identified data file from said storing means to said working memory means and in response to said other command line gener¬ ates the command codes required by said main progam to perform on said loaded data file the operation de¬ fined by said other command line.

59. A method of controlling the execution of a main program by a system as recited in claim 46 wherein said system includes a working memory for storing data to be manipulated and means for storing a plurality of data files and said plurality of command lines includes a start load loop command line identi- fied a plurality of said stored data files, an end of load loop command line and at least one other command line interposed between said start load loop command line and said end of load loop command line, said generating step generating the command codes required by said main program to load an identified data file and to perform the operation defined by said at least one other command line for each identified data file.