Method and apparatus for developing scripts that access mainframe resources that can be executed on various computer systems having different interface languages without modification5390314Abstract A system for converting software commands generated in a UNIX-based first programming language environment to software commands that operate in a second programming language environment. A first computer system generates input data signals in a first program language. A plurality of vendor second computer systems each have a second high-level program language different from each other and different from the first program language. A translation device is interposed between the first computer system and the plurality of second computer systems for storing a plurality of translation command rules for performing each high-level language program designated by an input data signal. The translation device receives a data command signal in the first program language containing a vendor identification data portion and a command data portion in the programming language of the UNIX-based first system and provides a corresponding output command signal in the language of any selected one of the vendor second computer systems. Claims I claim: Description FIELD OF THE INVENTION
______________________________________
typedef struct.sub.-- SCIP.sub.--
/* Dispatch table*/
functions { /* Emulator name
*/
char *name; *cmnd /* Pointer to
SCIP.sub.-- cmnd.sub.-- str
command table*/
}SCIP.sub.-- fn.sub.-- str;
______________________________________
The dispatch table 36 contains global commands (and the like), SSI commands, HCON commands, Sabre commands and user definable commands as follows:
______________________________________
SCIP.sub.-- fn.sub.-- str SCIP.sub.-- fn [ ] =
{
{ "global",
cmnd.sub.-- global
}, /*Global commands
*/
{ "ssi", cmnd.sub.-- ssi
}, /*SSI HLLAPI
emulation */
{ "hcon", cmnd.sub.-- hcon
}, /*SSI HLLAPI
emulation */
{ "sabre",
cmnd.sub.-- sabre
}, /*Sabre AAPI
emulation */
{ "user", cmnd.sub.-- user
}, /*User definable
commands */
{ 0x00, 0x00 },
};
______________________________________
The command dispatch table structure for tables 38, 42 and 46 is as follows:
______________________________________
typedef struct.sub.-- SCIP.sub.-- cmnd{
/* Command table
*/
char *name; /* Command name
*/
int (*func) ( ); /* Pointer to
command function
*/
}SCIP.sub.-- cmnd.sub.-- str;
______________________________________
Each of the n command tables 38, 42 and 46 consists of an array of translation command structures containing pointers to string constants for each command name and a pointer to the appropriate function in the interface library 50. Each array is NULL terminated to provided an easily identifiable end of array marker. The command global array contains the following commands that are common to the SCIP translation device:
______________________________________
SCIP.sub.-- cmnd.sub.-- str cmnd.sub.-- global [ ] =
{ OPEN, mmOpen }, /*Initialize
conversation
*/
{ CLOSE, mmClose }, /*Terminate conversation
*/
{ HELP, mmHelp }, /*Display help info.
*/
{ ERRNO, mmErrNo }, /*Display error code
info. */
{ 0x00, 0x00 },
};
______________________________________
The command SSI array contains the commands that are specific to the SSI emulator as follows:
______________________________________
SCIP.sub.-- cmnd.sub.-- str cmnd.sub.-- ssi [ ] =
{ SEARCH, mmSearch.sub.-- ssi
}, /*Search presen-
tation space
*/
{ SEND, mmSend.sub.-- ssi
}, /*Send string to
host */
{ CLEARKB, mmCirKb.sub.-- ssi
}, /*Clear keyboard
lock cond.
*/
. . .
{ 0x00, 0x00 },
};
______________________________________
The command HCON array contains the commands that are specific to the IBM HCON emulator as follows:
______________________________________
SCIP.sub.-- cmnd.sub.-- str cmnd.sub.-- hcon [ ] =
{ SEARCH, mmSearch.sub.-- hcon
}, /*Search pres-
entation space
*/
{ SEND, mmSend.sub.-- hcon
}, /*Send string to
host */
{ CLEARKB, mmCirKb.sub.-- hcon
}, /*Clear key-
board lock
cond. */
. . .
{ 0x00, 0x00 },
};
______________________________________
The command Sabre array contains the commands that are specific to the American Airlines Sabre emulator as follows:
______________________________________
SCIP.sub.-- cmnd.sub.-- str cmnd.sub.-- sabre [ ] =
{ SEARCH, mmSearch.sub.-- sabre
}, /*Search pres-
entation space
*/
{ SEND, mmSend.sub.-- sabre
}, /*Send string to
host */
{ CLEARKB, mmCirKb.sub.-- sabre
}, /*Clear key-
board lock
cond. */
. . .
{ 0x00, 0x00 },
};
______________________________________
The command user array is a place holder for user definable commands which will contain the "userstub" routine as follows:
______________________________________
SCIP.sub.-- cmnd.sub.-- str.sub.-- cmnd.sub.-- user [ ] =
{ "userstub",
mmUsrStub },
{ 0x00, 0x00 }
};
______________________________________
String literals used for command names are stored as #defined constants so that they can be declared once as follows:
______________________________________
/***********************************
* Definitions for command string text *
***********************************/
#define OPEN "open"
#define CLOSE "close"
#define HELP "help"
#define SEARCH "search"
#define SEND "send"
#define CLEARKB "clearkb"
. . .
______________________________________
The SCIP translation device help facility is implemented using a structure which contains pointers to arrays of SCIP help structures for SCIP translation device specific commands and user definable commands as follows:
______________________________________
struct
SCIP.sub.-- help.sub.-- str *global;
SCIP.sub.-- help.sub.-- str *user;
}mm.sub.-- help
= {help.sub.-- global, help.sub.-- user};
______________________________________
The SCIP translation device help structure is defined as follows:
______________________________________
typedef struct.sub.-- SCIP.sub.-- help {
char *name; */ Command name
*/
char *text; */ Help text */
}SCIP.sub.-- help.sub.-- str;
______________________________________
The help global array contains help information for the translation device specific commands as follows:
______________________________________
SCIP.sub.-- help.sub.-- str help.sub.-- global [ ] =
{OPEN, OPEN.sub.-- H
},
{CLOSE, CLOSE.sub.-- H
},
{SEARCH, SEARCH.sub.-- H
},
{SEND, SEND.sub.-- H
},
{CLEARKB, CLEARKB.sub.-- H },
. . .
{0x00, 0x00};
};
______________________________________
The help user array contains help information for user definable commands as follows:
______________________________________
SCIP.sub.-- help.sub.-- str.sub.-- help.sub.-- user [ ] =
{"UserStub", "This is a sample of the
help text for user
API's." },
{0x00, 0x00 }
};
______________________________________
String literals used for help text are defined as #defined constants so
that they can be declared once as follows:
The SSI emulator is able to communicate with the SCIP translation device via the parameters that are passed on the "open" command. The format of this command is as follows:
______________________________________
scip open scip.sub.-- session.sub.-- letter ssi "SSI MS3279
variable" "SSI LS3279 variable"
ssi.sub.-- short.sub.-- session.sub.-- name
______________________________________
A shell script that uses an "open" must always include a "scip close" to clean up shared memory. The format of the closed command is as follows:
______________________________________
scip close
______________________________________
The translator device uses shared memory to save certain
variables across Shell calls. In order for shared memory to be obtained,
the Shell must set up the following memory variable:
This variable is used to create a shared memory key file. This value is designated as "/tmp/scip.$$" in the SHELL. The signals on lines 52, 54 and 56 from the n level 2 command dispatch tables 38, 42 and 46 respectively, are all coupled to the interface libraries 50. The interface library memory coupled to each of the command dispatch units 38, 42 and 46 store data in the first program language representing the plurality of high-level language command functions for each of the second vendor computer systems. In effect, the n level 2 command dispatch tables 38, 42 and 46 tell the interface library 50 what the command is and then the command searches the library 50 to see what is needed to complete the command. Thus, for each command received from the level 2 dispatch tables, a set of rules is stored in the interface library 50 that translates the command to the appropriate vendors' version of the command rules. The vendors' version is stored in the vendors' library 58. Thus the output of interface library on line 60 selects the appropriate vendors' version of the command portion of the input signal and that version is output on line 62 to the second computer system to operate the program command. Thus the vendor library memory 58 that is coupled to the interface library 50 through line 60 stores command function rules for each command in the second language to enable each of the second plurality of vendor computer systems to perform the command. The complete system for converting software commands generated in the UNIX based first programming language to software commands that operate in a second programming language environment is illustrated in FIG. 3. The SCIP translation device 32 is shown coupled to a terminal 64 which may utilize one of the standard Shell interfaces 10 illustrated in FIG. 1. A video data terminal 66 receives information from terminal 64 on line 68 and may include for instance a video display screen for viewing commands entered by terminal 64 in the translation device 32. Terminal 64 may include a keyboard for entering code data and instructions. The output of terminal 64 in a first programming language provides an input signal on line 70 to the first level dispatch table 36 in the translation device 32. The table 36 first checks to see if the input signal contains an "open" command signal meaning that this is going to be a new communication with a particular second high-level language computer device. That signal is stored in register 72 in the dispatch table 36. The signal is illustrated in FIG. 5 and includes a first portion 73 which is a vendor identification code and may include as many bits as desired. For simplicity, only 2 bits are shown in FIG. 5 as the vendor identification data code 73. The bits in the second portion 75 represent the command that is to be performed. A signal would normally be generated on line 74 to a shared memory 76 to determine if the identified vendor is currently running a program. In such case, a comparator 78 in the class dispatch table 36 compares the information in shared memory 76 with the vendor identification code 73 stored in register 72. Since there is an "open" command, the class dispatch table 36 knows this is a new program for a particular vendor computer system and table 36 stores the vendor identification in shared memory 36 via line 74. A gate device 80 in the first level dispatch unit 36 is coupled to the register 72, the comparator 78 and the shared memory 76 through lines 74 to transfer the vendor identification to the shared memory if the comparator 78 determines that the identified vendor is not currently running the program. This enables multiple programs to be run concurrently through a multiplexed arrangement of the incoming input signals. Thus if an identification code for SSI, HCON and AAPI are all stored in the shared memory, when a new command signal is generated by a terminal 64 designating SSI as the high-level language, if the command is an "open" signal, the first level dispatch unit 36 knows that this is starting a new communication in the SSI language. All subsequent commands will be routed to the SSI command dispatch unit in the second level such as unit 38 until a "close" command or another "open" command is received. If another open command is received the dispatch table 36 knows that this is a new communication for a new high-level language. It determines that language from the vendor identification code 73 in the command signal and consequently routes all commands to the command dispatch unit 38, 42 or 46 in the second level and all subsequent commands will be directed to that same command dispatch table for communication with the second high-level language controller until a "close" or another "open" command is received. Thus the shared memory allows multiple programs to be operating concurrently with multiplexed input signals. When the interface library 50 receives the appropriate command from one of the command dispatch units 38, 42 or 46, it searches the shared memory 76 through line 82 to determine the status of the last command completed by the selected second computer system. It then knows which set of rules to transfer for the next command through line 60 to the vendors library 58 where again selected command function rules enable the selected one of the second plurality of vendor computer systems to perform the command. The output command function rules on line 62 are coupled to a modem 84a to the appropriate vendor mainframe 86 on line 88. As shown in phantom lines, there may be an n.sup.th modem 84b coupled to an n.sup.th vendor mainframe 92. The result of the last command from the vendor libraries 58 on line 62 is also coupled through a register 94 and stored in shared memory 76 on line 96 so that the shared memory 76 keeps track of the operations being performed by the vendor mainframe. The results are also stored in the vendor's own memory 98. The vendor's memory 98 can communicate with the shared memory 76 via lines 100. The register 94 is gated with a signal 102 from the vendor libraries 58 to store the result of the performance of the function in shared memory 76. A like register 104 is gated by signals 105 to store the results of another mainframe operation in the n.sup.th vendor memory 106. FIG. 6 is a schematic representation of the shared memory 76 illustrating the separate memory areas 108, 110 and 112, for example only, for storing HCON information, API information and SSI information respectively. FIG. 4 is a flow chart of the process of the present invention by which a first computer using one of a plurality of standard Shell interface programming languages may communicate with one of a second plurality of second computers utilizing a particular HLLAPI language by means of the present invention. The program starts at 114 where a signal is generated to decision block 116 where it has to be determined if the command signal is an "open" command signal. If "yes", an area in shared memory is created and the class or vendor data information contained in the input signal is coupled through line 118 to shared memory 120 for storage in the created area. Thus the system knows that this is going to begin a series of new program commands. If the output of the decision device 116 is "no", a signal on line 122 is coupled to block 124 which selects the existing class or vendor data already stored in an area in the shared memory. In this case, the system knows that this is one of a continuation of commands of an ongoing program. The first level dispatch table, at step 124 simply accesses the shared memory 120 according to the data it received and retrieves the current status of the ongoing program. If it is a new program (an "open" command), the data just stored in shared memory 120 through line 118 is coupled to the class dispatch unit on line 126. Now knowing the class of HLLAPI language with which the system is going to communicate, the appropriate function rules are retrieved from the interface libraries at step 130. These rules are used at step 132 to translate the code to the appropriate rules stored in the vendor's library 134. The appropriate rules for translation are then dispatched, as indicated by line 138, to the vendor's modem and memory at step 140 for performing the designated command. Signals are coupled to vendor's modem 148 as indicated by line 140 and to the vendor's mainframe 152 as indicated by line 150. At step 156, the results are coupled to the shared memory for storage as indicated by line 158. The results are also stored in the vendor's memory at step 146. When the operation is completed as indicated by line 160, a return code is created at step 162 which indicates that the operation has been completed. The SSI command rules are well known and as indicated earlier are stored as one set of rules in the interface library 50 in FIG. 3. The HLLAPI commands and the SABRE commands are not as well known and are set forth as follows: HLLAPI Commands OPEN SYNTAX:
______________________________________
scip open scip.sub.-- session.sub.-- letter ssi "SSI MS3279
variable" "SSI LS3279 variable"
ssi.sub.-- short.sub.-- session.sub.-- name
sciopen scip.sub.-- session.sub.-- letter ssi "SSI MS3279
variable" "SSI LS3279 variable"
ssi.sub.-- short.sub.-- session.sub.-- name
______________________________________
DESCRIPTION: The OPEN command activates a host session, allowing further communications with that session. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi/sabre error CLOSE SYNTAX
______________________________________
scip close session type
sciclose session type
______________________________________
DESCRIPTION: The CLOSE command terminates a host session. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi/sabre error SEARCH SYNTAX
______________________________________
scip search string [loc] [timeout]
scisearch string [loc] [timeout]
______________________________________
DESCRIPTION: SEARCH searches the presentation space for a specific character string. The search will begin at the location specified by the loc parameter. If the loc parameter is not specified the search will begin in row one column one. The string location will be return in STDOUT. The timeout parameter will cause the SEARCH command to return after the specified time (in seconds) if the string was not found, otherwise the SEARCH will be performed once. RETURN CODES: 0: successful completion 1: invalid number of arguments Non Zero: string was not found or there was a hllapi error. SEND SYNTAX:
______________________________________
scip send string.sub.-- of.sub.-- keys [string.sub.-- of.sub.-- keys
e encriptedey] [ ] [
value]
scisend string.sub.-- of.sub.-- keys [string.sub.-- of.sub.-- keys
[string
e encripted value]
______________________________________
DESCRIPTION: Sends keystrokes to the hosts. The arguments to SEND will be concatenated together then sent to the host. The `-k` option may be used to specify special purpose keys (i.e.: TAB, ENTER, etc.). The `-e` option may be used to provide an encrypted value, such a password which will be decoded at runtime prior to concatenating it into the string to be sent to host. (See SENDKEY for more info.) RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. SETSESSION SYNTAX: ##STR1## DESCRIPTION: Changes the 3270 host session with which SCIP is attached. RETURN CODES: 0: successful completion Non Zero: shared memory error. GETSTRING SYNTAX: ##STR2## DESCRIPTION: Copies a data string from the presentation space to STDOUT, for the specified length, starting at the specified position. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. SENDFILE SYNTAX: ##STR3## DESCRIPTION: Uploads a file from the workstation to the host. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. GETFILE SYNTAX: ##STR4## DESCRIPTION: Downloads a file from the host to the workstation. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. QRYCURPOS SYNTAX: ##STR5## DESCRIPTION: Obtains the current linear cursor position and returns the information via STDOUT. RETURN CODES: 0: successful completion Non Zero: hllapi error. CLEARKB SYNTAX: ##STR6## DESCRIPTION Clears the keyboard for the host. RETURN CODES: 0: successful completion Non Zero: hllapi error. CHECKCOMM SYNTAX: ##STR7## DESCRIPTION: Checks for a communication error listed in the OIA. RETURN CODES: 0: successful completion 9: communication error on host Non Zero: communication error or hllapi SENDKEY SYNTAX: ##STR8## DESCRIPTION: Sends a special key the host. The following keys are supported:
______________________________________
RETURN ENTER TAB BACKTAB HOME
UP DOWN LEFT RIGHT CLEAR
RESET ERASEEO ERASEINP ATTN SYSREC
F
______________________________________
RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. SETROWCOL SYNTAX: ##STR9## DESCRIPTION: Sets the cursor at row & column. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. SETLPOS SYNTAX ##STR10## DESCRIPTION: Sets cursor at the specific linear position, i.e., position 82 is row 1 column 2. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. PUTSTRING SYNTAX: ##STR11## DESCRIPTION: Copies of local string to the presentation space at the specified position. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: hllapi error. ORYOIA SYNTAX ##STR12## DESCRIPTION: Obtains the operator information line and passes it back via STDOUT. RETURN CODES: 0: successful completion -1: communication error on host Non Zero: hllapi error. ORYROW SYNTAX: ##STR13## DESCRIPTION: Obtains the row size of the presentation space and returns the information via STDOUT. RETURN CODES: 0: successful completion Non Zero: hllapi error. ORYROL SYNTAX ##STR14## DESCRIPTION: Obtains the column size of the presentation space and returns the information via STDOUT. RETURN CODES: 0: successful completion Non Zero: hllapi error. Sabre Commands OPEN SYNTAX ##STR15## DESCRIPTION: The OPEN command activates a host session, allowing further communications with that session. The `sabre --configuration--file`contains Sabre parameters required to establish the connection to Sabre. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: sabre error CLOSE SYNTAX: ##STR16## DESCRIPTION: The CLOSE command terminates a host session. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: sabre error SEARCH SYNTAX: ##STR17## DESCRIPTION: SEARCH searches the Sabre read buffer for a specific character string. The search will begin at the location specified by the loc parameter. If the loc parameter is not specified the search will begin in row one column one. The string location will be returned in STDOUT. The timeout parameter will cause the SEARCH command to return after the specified time (in seconds) if the string was not found, otherwise the SEARCH will be performed once. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: sabre was not found or there was a sabre error. SEND SYNTAX: ##STR18## DESCRIPTION: Sends keystrokes to the host. The arguments to SEND will be concantenated together then sent to the host. The `-k` option may be used to specify special purpose keys (i.e.: TAB, ENTER, etc). The `-e` option may be used to provide an encrypted value, such a password which will be decoded at runtime prior to concatenating it into the string to be sent to the host. The `-f` option may be used to specify a target file to which the output of the command will be written. If the `-a` option is used, and a target filename is provided, then the file will be opened in append mde. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: sabre error. SENDFILE SYNTAX: ##STR19## DESCRIPTION: Uploads a file from the workstation to the host. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: sabre error. GETFILE SYNTAX: ##STR20## DESCRIPTION: Sends keystrokes to the host. The arguments to SEND will be concatenated together then sent to the host. The `-k` option may be used to specify special purpose keys (i.e.: TAB, ENTER, etc). The `-e` option may be used to provide an encrypted value, such as a password which will be decoded at runtime prior to concatenating it into the string to be sent to the host. The `-f` option may be used to specify a target file to which the output of the command will be written. If the `-a` option is used, and a target filename is provided, then the file will be opened in append mde. RETURN CODES: 0: successful completion -1: invalid number of arguments Non Zero: sabre error. CHECKCOMM SYNTAX: ##STR21## DESCRIPTION: Checks for communication error listed in the OIA. RETURN CODES: 0: successful completion 9: communication error on host Non Zero: communication error or sabre error. CHGSYS SYNTAX: ##STR22## DESCRIPTION: The CHGSYS command issues a sabre `change:change:system` command to connect the user to another system. RETURN CODES: 0: successful completion Non Zero: command failed CHGAREA SYNTAX: ##STR23## DESCRIPTION: The CHGAREA command issues a sabre `change:change:area` command to connect the user to another Sabre area. RETURN CODES: 0: successful completion Non Zero: command failed SETSESSION SYNTAX: ##STR24## DESCRIPTION: Changes the Sabre host session with which SCIP is attached. RETURN CODES: 0: successful completion Non Zero: shared memory error. Thus there as has been disclosed a novel system for converting software commands generated in a UNIX-based first programming language environment to software commands that operate in a second programing language environment. A first computer system generates program input signals in the first program language for a communication with a plurality of second vendor computer systems each having a second high-level language program different from each other and from the first program language. A translation device is interposed between the first computer system and the plurality of second computer systems for storing a plurality of translation command rules for performing each high-level language program. The translation device receives a data input signal in the first program language that contains a vendor identification data portion and a program command data portion in the programming language of the UNIX-based first system and provides a corresponding output program command in the language of any one of the set of vendor computer systems. Thus the translator device translates a command to an appropriate vendor version of the command. The novel system allows multiple communication channels to be operated simultaneously in a multiplexed arrangement. Thus a particular input command locates the parameters for that command stored in an interface library in a particular high-level language and matches those parameters with the high-level language commands stored in the vendor's library. Thus the stored ruler or parameter in the interface libraries match the stored ruler or parameters of the vendor's libraries. The shared memory and the two-level dispatch system are the important elements that enable the translation device to function. Shared memory stores the information that the translation device requires to be able to translate the input signal command. Thus, it lets the system know, first, where the incoming data is to be dispatched and second, what was the last function performed for a given purpose because it stores ongoing program information for each computer system for which translation is occurring. The first level dispatch table couples the incoming data signals to the proper channel for the high-level language computer system selected and the second level dispatch table selects the proper conversion rules in the interface library for matching with the stored parameter in the vendor's library and allowing the conversion to take place. While the invention has been described in connection with a preferred embodiment, it is not intended to limit the scope of the invention to the particular form set forth, but, on the contrary, it is intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||