ADAPTING SCRIPTS FROM A SOURCE PLATFORM TO BE UTILIZED IN A TARGET PLATFORM

A computer-implemented method, system, and computer program product for adapting scripts from a source platform to be utilized in a target platform when porting. Traces of system calls from the commands in the source and target platforms are analyzed to identify building blocks. A tree structure for each command of the source and target platforms is constructed with one or more building blocks from the identified building blocks. Commands of the target platform with a functionality within a threshold degree of similarity to the commands of the source platform are identified by analyzing the building blocks of the commands' tree structures. Alternative commands for the commands of the source platform, such as those commands that are not supported by the target platform, may be generated using such identified commands. The script from the source platform may then be adapted to be utilized in the target platform using such alternative commands.

TECHNICAL FIELD

The present disclosure relates generally to porting, and more particularly to adapting scripts from a source platform to be utilized in a target platform when porting, such as porting open-source tools.

BACKGROUND

In software engineering, porting is the process of adapting software for the purpose of achieving some form of execution in a computing environment that is different from the one that a given program was originally designed for execution (e.g., different CPU, operating system, or third party library).

SUMMARY

In one embodiment of the present disclosure, a computer-implemented method for adapting scripts from a source platform to be utilized in a target platform when porting comprises analyzing system call traces of commands from the source and target platforms to identify building blocks. The method further comprises constructing a tree structure for each command of the source and target platforms with one or more building blocks of the identified building blocks. The method additionally comprises identifying commands of the target platform with a functionality within a threshold degree of similarity of commands of the source platform by analyzing building blocks of the tree structures of the commands of the source and target platforms. Furthermore, the method comprises generating one or more alternative commands for the source platform using the identified commands of the target platform with the functionality within the threshold degree of similarity of the commands of the source platform. Additionally, the method comprises adapting a script from the source platform to be utilized in the target platform using the generated one or more alternative commands.

Other forms of the embodiment of the computer-implemented method described above are in a system and in a computer program product.

The foregoing has outlined rather generally the features and technical advantages of one or more embodiments of the present disclosure in order that the detailed description of the present disclosure that follows may be better understood. Additional features and advantages of the present disclosure will be described hereinafter which may form the subject of the claims of the present disclosure.

DETAILED DESCRIPTION

As stated in the Background section, in software engineering, porting is the process of adapting software for the purpose of achieving some form of execution in a computing environment that is different from the one that a given program was originally designed for execution (e.g., different CPU, operating system, or third party library).

When porting software, such as open-source tools, across different operating systems (e.g., Linux®, iOS®, Unix®, etc.) and/or hardware platforms (e.g., x86, Arm®, etc.), many scripts from a source platform need to be modified in order to be executed successfully on a target platform. A script refers to a program or sequence of instructions that is interpreted or carried out by another program rather than by the computer processor. A platform refers to the hardware and software (operation system) on which software applications can be run. A source platform refers to the platform upon which the scripts were originally designed for execution. A target platform refers to the platform upon which the scripts are desired to be executed.

For example, the script for a BATS (Bash Automated Testing System) framework in a source platform, such as the Linux® platform, may not be supported by the target platform (e.g., z/OS®). For instance, the commands of the script for the BATS framework may be not supported by the target platform. If the target platform does not report errors or warnings regarding unsupported commands, then the user will have no knowledge of such unsupported commands. As a result, the user may spend enormous time in attempting to identify the reasons for the script not executing on the target platform as well as spend enormous time in modifying the script in order to be properly executed on the target platform.

Unfortunately, there is not currently a means for informing the user regarding unsupported commands. Neither is there a means for automatically modifying the scripts from the source platform in order to be correctly executed on the target platform.

The embodiments of the present disclosure provide a means for adapting scripts from a source platform (e.g., Linux®) to be utilized in a target platform (e.g., z/OS®) when porting, such as porting open-source tools, by analyzing system call traces of commands from the source and target platforms to identify building blocks. A “system call,” as used herein, is the programmatic way in which a computer program requests a service from the operating system on which it is executed. A “system call trace,” as used herein, refers to the specialized use of logging to record information about the system call. A “building block,” as used herein, refers to a portion of the script that contains functionality for performing task-based operations. For example, such task-based operations may include creating a service requirement, registering for an event, etc. Furthermore, building blocks typically contain one or more application programming interfaces (APIs). Such building blocks may be combined to perform the task-based operations of a command (e.g., reading a configuration file, copying files, moving and renaming files, creating empty files, etc.). A tree structure (hierarchical structure that is used to represent and organize the building blocks performing the task-based operations of the command) for each command of the source and target platforms is constructed with one or more building blocks of the identified building blocks. In one embodiment, the building blocks used to construct the command's tree structure are identified by analyzing the command's system call traces. Commands of the target platform with a functionality within a threshold degree of similarity as the commands of the source platform are identified by analyzing the building blocks of the tree structures of the commands of the source and target platforms. Alternative commands for the commands of the source platform, such as those commands that are not supported by the target platform, may then be generated using such identified commands. The script from the source platform may then be adapted to be utilized in the target platform using such generated alternative commands. For example, the script from the source platform may be adapted by replacing commands in the script that are not supported by the target platform with alternative commands that are supported by the target platform. For instance, a command from the script of the source platform that is mismatched (command used in the source platform with an appearance to a command used in the target platform but with a different functionality) or missing (command used in the source platform with the same functionality as a command from the target platform but with a different appearance) may be replaced with such a generated alternative command thereby enabling the script of the source platform to be adapted to be executed on the target platform. A further description of these and other features will be provided below.

In some embodiments of the present disclosure, the present disclosure comprises a computer-implemented method, system, and computer program product for adapting scripts from a source platform to be utilized in a target platform when porting. In one embodiment of the present disclosure, traces of system calls from the commands in the source and target platforms are analyzed to identify building blocks. A “system call,” as used herein, is the programmatic way in which a computer program requests a service from the operating system on which it is executed. A “system call trace,” as used herein, refers to the specialized use of logging to record information about the system call. A “building block,” as used herein, refers to a portion of the script that contains functionality for performing task-based operations. A tree structure for each command of the source and target platforms is constructed with one or more building blocks from the identified building blocks. In one embodiment, such tree structures are constructed by analyzing the commands' system call traces. Commands of the target platform with a functionality within a threshold degree of similarity, which may be user-designated, to the commands of the source platform are identified by analyzing the building blocks of the commands' tree structures. In one embodiment, such similarity between the commands of the source and target platforms are determined by vectorizing the building blocks of the commands, including the actions, parameters, inputs, functions, etc. of the building blocks. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the commands of the source and target platforms. Alternative commands for the commands of the source platform, such as those commands that are not supported by the target platform, may then be generated using such identified commands. The script from the source platform may then be adapted to be utilized in the target platform using such generated alternative commands. For example, the script from the source platform may be adapted by replacing commands in the script that are not supported by the target platform with alternative commands that are supported by the target platform. For instance, a command from the script of the source platform that is mismatched (command used in the source platform with an appearance to a command used in the target platform but with a different functionality) or missing (command used in the source platform with the same functionality as a command from the target platform but with a different appearance) may be replaced with such a generated alternative command thereby enabling the script of the source platform to be adapted to be executed on the target platform. In this manner, scripts from a source platform with commands that are not supported by the target platform may now be adapted in a manner that enables such scripts to be executed on the target platform.

In the following description, numerous specific details are set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without such specific details. In other instances, well-known circuits have been shown in block diagram form in order not to obscure the present disclosure in unnecessary detail. For the most part, details considering timing considerations and the like have been omitted inasmuch as such details are not necessary to obtain a complete understanding of the present disclosure and are within the skills of persons of ordinary skill in the relevant art.

Referring now to the Figures in detail,FIG.1illustrates an embodiment of the present disclosure of a communication system100for practicing the principles of the present disclosure. Communication system100includes a source platform101connected to a target platform102via a network103. A “platform,” as used herein, refers to the hardware and software (operation system) on which software applications can be run. A “source platform”101, as used herein, refers to the platform upon which the scripts were originally designed for execution. A “target platform”102, as used herein, refers to the platform upon which the scripts are desired to be executed. A “script,” as used herein, refers to a program or sequence of instructions that is interpreted or carried out by another program rather than by the computer processor.

Furthermore, in one embodiment, each platform, source platform101and target platform102, includes an operating system, such as source operating system (o/s)104and target operating system (o/s)105, respectively. Operating systems104,105correspond to a program that, after being initially loaded into platform101,102, respectively, manages all of the other application programs in platform101,102, respectively. Such application programs make use of the operating system104,105by making requests for services through defined application programming interfaces (APIs).

As discussed above, when porting software, such as open-source tools, scripts from source platform101may not be supported by target platform102. For instance, the commands of the script from source platform101may not be supported by target platform102. A command, as used herein, refers to an action assigned to a program (e.g., script) to perform a specific task. As a result, the script from source platform101may need to be adapted to be utilized in target platform102when porting, such as porting open-source tools. In one embodiment, porting mechanism106is configured to adapt scripts from source platform101to be utilized in target platform102as discussed below.

As shown inFIG.1, porting mechanism106is connected to network103. In one embodiment, porting mechanism106is configured to adapt scripts from source platform101to be utilized in target platform102by analyzing traces of system call traces from commands in source and target platforms101,102to identify building blocks. A “system call,” as used herein, is the programmatic way in which a computer program requests a service from the operating system on which it is executed. For example, commands from the script from source platform101may request a service from operating system104. In another example, commands from the script to be utilized in target platform102may request a service from operating system105.

A “system call trace,” as used herein, refers to the specialized use of logging to record information about the system call. A “building block,” as used herein, refers to a portion of the script that contains functionality for performing task-based operations. For example, such task-based operations may include creating a service requirement, registering for an event, etc. Furthermore, building blocks typically contain one or more application programming interfaces (APIs). Such building blocks may be combined to perform the task-based operations of a command (e.g., reading configuration files, copying files, moving and renaming files, creating empty files, etc.).

In one embodiment, porting mechanism106constructs a tree structure for each command of source and target platforms101,102with one or more of the building blocks of the identified building blocks. A tree structure, as used herein, refers to a hierarchical structure that is used to represent and organize the building blocks performing the task-based operations of the command. In one embodiment, the building blocks used to construct the command's tree structure are identified by analyzing the command's system call traces.

In one embodiment, porting mechanism106is configured to refine the command's tree structure by categorizing the build blocks as being “trivial” or “critical” based on the relatedness to the key or main function of the command. The category of “trivial,” as used herein, refers to building blocks with little value or importance in accomplishing the key or main function of the command and do not need to be utilized when identifying commands of target platform102with a functionality within a threshold degree of similarity as commands of source platform101. The category of “crucial,” as used herein, refers to building blocks of great importance in accomplishing the key or main function of the command and need to be utilized when identifying commands of target platform102with a functionality within a threshold degree of similarity as commands of source platform101. In one embodiment, such building blocks are categorized as being “trivial” or “critical” based on weights assigned to the building blocks. For example, a weight of 1 or less assigned to a building block indicates categorizing such a building block as being trivial; whereas, assigning a weight of greater than 1 (e.g., 3) indicates categorizing such a building block as being critical. In one embodiment, the value of the weight assigned to such building blocks is based on the degree of relatedness to the key or main function of the command.

In one embodiment, the tree structures of commands, including such refined tree structures that include the categorized and/or weighted building blocks, are stored in databases. For example, the tree structures of commands pertaining to the scripts from source platform101are stored in database107connected to source platform101. In another example, the tree structures of commands pertaining to the scripts to be utilized in target platform102are stored in database108connected to target platform102.

In one embodiment, porting mechanism106is configured to identify commands of target platform102with a functionality within a threshold degree of similarity to commands of source platform101by analyzing the building blocks of commands' tree structures for those commands categorized as critical and/or with a weight that exceeds a threshold value, which may be user-designated. In one embodiment, such an analysis may simply be based on the building blocks classified as critical. In another embodiment, such an analysis may simply be based on the building blocks with a weight that exceeds a user-designated threshold value.

In one embodiment, porting mechanism106labels each command of source platform101and/or target platform102with the designation of “same,” “mismatch,” or “missing” based on comparing the building blocks for each command of target platform102with the building blocks of commands of source platform101. The designation of “same,” as used herein, refers to a command of source platform101or target platform102that has an appearance and a functionality within a threshold degree of similarity of a command of target platform101or source platform101, respectively. The designation of “mismatch,” as used herein, refers to a command of source platform101or target platform102that has an appearance within a threshold degree of similarity of a command of target platform102or source platform101, respectively, but does not have a functionality within a threshold degree of similarity of the command of target platform102or source platform101, respectively. The designation of “missing,” as used herein, refers to a command of source platform101or target platform102that has a functionality within a threshold degree of similarity of a command of target platform102or source platform101, respectively, but does not have an appearance within a threshold degree of similarity of the command of target platform102or source platform101, respectively. The designations of “mismatch” and “missing” are indications of commands, such as the commands of source platform101, that are not supported by target platform102.

In one embodiment, porting mechanism106generates, if possible, alternative commands for the commands of source platform102labeled as mismatch and/or missing. For example, the command of “mktemp” (the mktemp command declares an explicit file or directory that is meant to be temporary) of source platform101(e.g., Linux®) is classified as “missing” since such a command does not have a command with a functionality within a threshold degree of similarity of a command of target platform102(e.g., z/OS®). However, the command of “mktemp” does have an alternative command that was generated by porting mechanism106, such as the combination of the “mkdir” and “head/dev/urandom” commands of target platform102. As a result, the script from source platform101may be adapted to be utilized in target platform102by replacing the “mktemp” command in the script for source platform101with the combined commands of “mkdir” and “head/dev/urandom” of target platform102.

In another example, the command of “stat -c” (the stat -c command gives information about the file and filesystem) of source platform101(e.g., Linux®) is classified as “mismatch” since such a command does not have a command with an appearance within a threshold degree of similarity of a command of target platform102(e.g., z/OS®). However, the command of “stat-c” does have an alternative command that was generated by porting mechanism106, such as the “ls -l” command (command used to list files and directories) of target platform102, since the “ls -l” command returns the same information as the information returned by “stat -c.” As a result, the script from source platform101may be adapted to be utilized in target platform102by replacing the “stat -c” command in the script for source platform101with the command of “ls -l” of target platform102.

Hence, in one embodiment, porting mechanism106is configured to adapt scripts from source platform101to be utilized in target platform102by using such generated alternative commands.

A more detailed description of these and other features will be provided further below. Furthermore, a description of the software components of porting mechanism106used for adapting scripts from a source platform to be utilized in a target platform when porting is provided below in connection withFIG.2. A description of the hardware configuration of porting mechanism106is provided further below in connection withFIG.10.

As discussed above, porting mechanism106is connected to network103.

Network103may be, for example, a local area network, a wide area network, a wireless wide area network, a circuit-switched telephone network, a Global System for Mobile Communications (GSM) network, a Wireless Application Protocol (WAP) network, a WiFi network, an IEEE 802.11 standards network, various combinations thereof, etc. Other networks, whose descriptions are omitted here for brevity, may also be used in conjunction with system100ofFIG.1without departing from the scope of the present disclosure.

System100is not to be limited in scope to any one particular network architecture. System100may include any number of source platforms101, target platforms102, networks103, porting mechanisms106, and databases107,108.

A discussion regarding the software components used by porting mechanism106to adapt scripts from a source platform to be utilized in a target platform when porting is provided below in connection withFIG.2.

FIG.2is a diagram of the software components used by porting mechanism106(FIG.1) to adapt scripts from a source platform (e.g., source platform101) to be utilized in a target platform (e.g., target platform102) when porting in accordance with an embodiment of the present disclosure.

As shown inFIG.2, porting mechanism106includes an analyzing engine201configured to analyze traces of system calls from commands in source and target platforms101,102to identify building blocks.

As discussed above, a “system call,” as used herein, is the programmatic way in which a computer program requests a service from the operating system on which it is executed. For example, commands from the script from source platform101may request a service from operating system104. In another example, commands from the script to be utilized in target platform102may request a service from operating system105.

A “system call trace,” as used herein, refers to the specialized use of logging to record information about the system call. A “building block,” as used herein, refers to a portion of the script that contains functionality for performing task-based operations. For example, such task-based operations may include creating a service requirement, registering for an event, etc. Furthermore, building blocks typically contain one or more application programming interfaces (APIs). Such building blocks may be combined to perform the task-based operations of a command (e.g., reading configuration files, copying files, moving and renaming files, creating empty files, etc.).

In one embodiment, analyzing engine201traces system calls via the use of tracing tools, which can include, but are not limited to, strace, dtruss, Jaeger, Zipkin, Dynatrace®, etc.

In one embodiment, analyzing engine201analyzes such traces to identify building blocks based on identifying functions (e.g., openat( ), mmap( ), statx( ), write( ), etc.), where the lines of code of the function correspond to the building block as illustrated inFIG.3. In one embodiment, analyzing engine201identifies the functions in the system call traces based on identifying terms listed in a data structure (e.g., table) corresponding to functions to be identified in the system call traces. For example, such a data structure may include the terms of “openat( ),” “mmap( ),” “statx( ),” “write( ),” etc. corresponding to functions to be identified in the system call traces. In one embodiment, such a data structure resides within the storage device of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

Referring now toFIG.3,FIG.3illustrates identifying building blocks based on analyzing the system call traces of commands from source and target platforms101,102in accordance with an embodiment of the present disclosure.

As shown inFIG.3, analyzing engine201identifies the functions (e.g., openat( ), mmap( ), statx( ), write( ), etc.) used in the system call traces of commands from source platform101(e.g., Linux® platform). For instance, analyzing engine201identified the function openat( ) (opens the file named by the path) corresponding to building block ID (“Block ID”): A1(see element302A), where the lines of code for such an identified function correspond to the building block, such as building block301A. In one embodiment, analyzing engine201generates an identifier (“Block ID”) for each building block identified. In one embodiment, the type of building block (“Block Type”) for each identified building block is identified by analyzing engine201based on the identified function and the input or parameter of the identified function listed within the parenthesis of the function. For example, the building block type for building block301A corresponds to having the common dependence libraries inform (see element303A). In one embodiment, analyzing engine201determines such information based on identifying the function in the data structure (e.g., table) containing a listing of functions that are associated with various building block types. Furthermore, such a data structure may include an identification of the building block type based on the input or parameters within the parenthesis of the function. As a result, analyzing engine201is able to identify the building block type based on identifying the input or parameters within the parenthesis of the identified function. In one embodiment, such a data structure resides within the storage device of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

Other examples include analyzing engine201identifying the function openat( ) corresponding to building block ID (“Block ID”): B1(see element302B), where the lines of code for such an identified function correspond to the building block, such as building block301B. Furthermore, analyzing engine201identifies the building block type for building block301B as corresponding to a common dependence library (see element303B).

In another example, analyzing engine201identifies the function mmap( ) (creates a new mapping in the virtual address space) corresponding to building block ID (“Block ID”): C1(see element302C), where the lines of code for such an identified function correspond to the building block, such as building block301C. Furthermore, analyzing engine201identifies the building block type for building block301C as corresponding to requesting a resource to enforce security controls (see element303C).

In a further example, analyzing engine201identifies the function statx( ) (identifies the target file) corresponding to building block ID (“Block ID”): D1(see element302D), where the lines of code for such an identified function correspond to the building block, such as building block301D. Furthermore, analyzing engine201identifies the building block type for building block301D as corresponding to getting information about the file (see element303D).

In another example, analyzing engine201identifies the function write( ) (creates a communication line) corresponding to building block ID (“Block ID”): E1(see element302E), where the lines of code for such an identified function correspond to the building block, such as building block301E. Furthermore, analyzing engine201identifies the building block type for building block301E as corresponding to writing to the standard output (see element303E).

Furthermore, porting mechanism106includes a constructing engine202configured to construct a tree structure for each command of source and target platforms101,102with one or more building blocks from the building blocks identified by analyzing engine201.

In one embodiment, constructing engine202constructs such tree structures by analyzing the commands' system call traces.

For example, in one embodiment, constructing engine202analyzes the particular command's system call trace to identify the building blocks out of the building blocks identified by analyzing engine201based on identifying functions (e.g., openat( ), mmap( ), statx( ), write( ), etc.), where the lines of code of the function correspond to the building blocks. In one embodiment, analyzing engine201identifies the functions in the system call traces based on identifying terms listed in a data structure (e.g., table) corresponding to functions to be identified in the system call traces. For example, such a data structure may include the terms of “openat( ),” “mmap( ),” “statx( ),” “write( ),” etc. corresponding to functions to be identified in the system call traces. In one embodiment, such a data structure resides within the storage device of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

In one embodiment, tree structures are constructed based on such analysis of the particular command's system call trace based on determining the dependencies among the building blocks. Such dependencies, as used herein, refer to relationships between the building blocks, such as the functions of the building blocks, where one building block relies on the other to work properly. In one embodiment, such dependencies are obtained using various dependency analysis tools, which can include, but are not limited to, MathWorks® (e.g., matlab.codetools.requiredFilesandProducts function), DepAn, slizaa, Softagram®, etc.

In one embodiment, based on such dependencies, a tree structure of such dependencies (parent-child relationships) is constructed by constructing engine202. A tree structure, as used herein, refers to a hierarchical structure that is used to represent and organize the building blocks performing the task-based operations of the command. In such a hierarchical structure, the nodes in a tree structure represent the building blocks identified from analyzing the particular command's system call trace. Each node in the tree structure has zero or more child nodes, which are located beneath it in the tree structure. A node that has a child is called the child's parent node. All nodes have exactly one parent, except the topmost root node, which has none. An illustration of such a tree structure is shown inFIG.4.

FIG.4illustrates a tree structure400representing the dependencies among the identified building blocks by analyzing the command's system call trace in accordance with an embodiment of the present disclosure.

As shown inFIG.4, tree structure400is constructed for a command401(e.g., command1) based on the dependencies among the building blocks402, such as building blocks A1, B1, B2, B3, C1, D1, E1and so forth as shown inFIG.4.

As further illustrated inFIG.4, tree structure400is constructed based on building blocks402whose corresponding block identifiers (“Block ID”) and building block types (“Block Type”) are shown in table403. As illustrated in table403, building blocks (e.g., B1, B2, and B3) with the building block type of having a common dependence library are the child nodes to the building block (e.g., A1) with the building block type corresponding to having the common dependence libraries inform. Such dependencies are illustrated in tree structure400by having building blocks B1, B2, and B3be the child nodes to building block A1.

Returning toFIG.2, in conjunction withFIGS.1and3-4, in one embodiment, constructing engine202is configured to construct a tree structure for each command of source and target platforms101,102with one or more building blocks from the building blocks identified by analyzing engine201based on the determined dependencies among the building blocks using various software tools, which can include, but are not limited to, Graphviz®, Mermaid, Nomnoml, etc.

Porting mechanism106additionally includes a refinement engine203configured to refine the command's tree structure (e.g., tree structure400) by categorizing the building blocks of tree structure400as being trivial or critical based on the relatedness to the key or main function of the command. The category of “trivial,” as used herein, refers to building blocks with little value or importance in accomplishing the key or main function of the command and do not need to be utilized when identifying commands of target platform102with a functionality within a threshold degree of similarity as the commands of source platform101. The category of “crucial,” as used herein, refers to building blocks of great importance in accomplishing the key or main function of the command and need to be utilized when identifying commands of target platform102with a functionality within a threshold degree of similarity as the commands of source platform101. In one embodiment, such building blocks are categorized as being “trivial” or “critical” based on weights assigned to the building blocks. For example, a weight of 1 or less assigned to a building block indicates categorizing such a building block as being trivial; whereas, assigning a weight of greater than 1 (e.g., 3) indicates categorizing such a building block as being critical. In one embodiment, the value of the weight assigned to such building blocks is based on the degree of relatedness to the key or main function of the command.

In one embodiment, refinement engine203categorizes the building blocks of tree structure400based on determining the relatedness to the key or main function of the command. In one embodiment, the key or main function of the command is determined based on identifying the key or main function (e.g., provide information about the file and filesystem) of the command (e.g., stat -c) listed in a data structure (e.g., table). For example, such a data structure may include the key or main function of “providing information about the file and filesystem” corresponding to the stat -c command. Furthermore, in such a data structure, the key or main function may be associated with other functions that are of great importance for implementing such a key or main function, such as write( ), statx( ), etc. Upon identifying such functions from the data structure, refinement engine203attempts to identify such functions associated with the building blocks of tree structure400. Upon identifying such functions in the building blocks of tree structure400, such building blocks are classified as being “critical,” whereas, the other building blocks are classified as being “trivial” as shown inFIG.5. In one embodiment, such a data structure resides within the storage device of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

FIG.5illustrates categorizing the building blocks of tree structure400for a command (e.g., command401) of source platform101or target platform102as being trivial or critical based on the relatedness to the key or main function of the command in accordance with an embodiment of the present disclosure.

Referring toFIG.5, building blocks501have been identified as being trivial since such functions associated with such building blocks of tree structure400are of little value or importance in accomplishing the key or main function of the command.FIG.5further illustrates that building blocks502have been identified as critical since such building blocks are of great importance in accomplishing the key or main function of the command. In one embodiment, the functions (e.g., statx( ), write( )) of such building blocks502may have been identified in a data structure as being of great importance for implementing the key or main function of command401. As a result, such building blocks502are identified as being critical.

Furthermore, building blocks402of command401as shown inFIG.4may, in addition or alternatively to being classified as being “trivial” or “critical” as discussed above, be assigned a weight based on the relatedness to the key or main function of command401. In one embodiment, the key or main function of the command is determined based on identifying the key or main function (e.g., provide information about the file and filesystem) of the command (e.g., stat -c) listed in a data structure (e.g., table). For example, such a data structure may include the key or main function of “providing information about the file and filesystem” corresponding to the stat -c command. Furthermore, in such a data structure, the key or main function may be associated with various functions that are of varying degrees of importance for implementing the key or main function. Such varying degrees of importance may be identified via an assigned weight to such a function, where the lower the value of the weight, the less important is the function for implementing the key or main function of command401and vice-versa. In one embodiment, such a data structure resides within the storage device of porting mechanism106. In one embodiment, such a data structure is populated by an expert. An example of assigning each command's building blocks an appropriate weight, such as using the data structure discussed above, is illustrated inFIG.6.

FIG.6illustrates assigning the building blocks of a command's tree structure with a weight based on the relatedness to the key or main function of the command in accordance with an embodiment of the present disclosure.

Referring toFIG.6,FIG.6illustrates assigning weights to the building blocks of command601(e.g., stat -c ‘% s’ /var/log/messages) from source platform101. For instance, the openat( ) function may be of little importance to implementing the key or main function of command601(e.g., stat -c); whereas, the statx( ) function may be of great importance to implementing the key or main function of command601(stat -c). As a result, a higher weight (e.g., 3) may be assigned to building block602A associated with the function of statx( ) and a lower weight (e.g., 0.5) may be assigned to the building blocks602B-602C associated with the function of openat( ).

FIG.6further illustrates assigning weights to the building blocks of command603(e.g., ls -l /var/log/messages) from target platform102. For instance, the openat( ) function may be of little importance to implementing the key or main function of command603(e.g., ls -l); whereas, the statx( ) function may be of great importance to implementing the key or main function of command603(e.g., ls -l). As a result, a higher weight (e.g., 3) may be assigned to building block602D associated with the function of statx( ) and a lower weight (e.g., 0.5) may be assigned to the building blocks602E-602G associated with the function of openat( ).

Referring toFIG.2, in conjunction withFIGS.1and3-6, porting mechanism106additionally includes a comparison module204configured to identify commands of target platform102with a functionality within a threshold degree of similarity, which may be user-designated, to the commands of source platform101by analyzing the building blocks of the commands' tree structures400for those commands categorized as critical and/or with a weight that exceeds a threshold value.

In one embodiment, such similarity between the commands of source platform101and target platform102may be determined by vectorizing the building blocks of the commands, including the actions, parameters, inputs, functions, etc. of the building blocks, such as via Word2vec, Doc2Vec, GloVe, etc. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the commands of source platform101and target platform102. Such a similarity measure is compared to a threshold value, which may be user-designated, to determine if the commands are within a threshold degree of similarity to one another. If the similarity measure exceeds such a threshold value, then the commands are deemed to be within a threshold degree of similarity. Otherwise, the commands are not deemed to be within the threshold degree of similarity.

“Cosine similarity,” as used herein, refers to a measure of similarity between two non-zero vectors defined in an inner product space. Cosine similarity is the cosine of the angle between the vectors. That is, it is the dot product of the vectors divided by the product of their lengths. If the measurement exceeds a threshold value, which may be user-designated, then the commands are deemed to be within a threshold degree of similarity. Otherwise, the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the Euclidean distance is calculated as the square root of the sum of the squared differences between the two feature vectors. If the distance exceeds a threshold value, which may be user-designated, then the commands are deemed to be within a threshold degree of similarity. Otherwise, the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the similarity measure is a score between the values of 0 and 1 for vectors that have only positive values. In one embodiment, any negative scores can be made positive by taking its absolute value.

Comparison module204utilizes various software tools for generating the similarity score, which can include, but are not limited to, TensorFlow®, MathWorks®, plus sklearn, scikit-learn®, etc.

An illustration of comparison module204identifying a command(s) of source platform101or target platform102with a functionality within a threshold degree of similarity to a command(s) of target platform102or source platform101, respectively, by analyzing the building blocks of the commands' tree structures400for those command categorized as critical and/or with a weight that exceeds a threshold value is provided inFIG.7.

FIG.7illustrates identifying a command(s) (e.g., mktemp) of source platform101(e.g., Linux® platform) or target platform102with a functionality within a threshold degree of similarity to a command(s) of target platform102(e.g., z/OS®) or source platform101, respectively, in accordance with an embodiment of the present disclosure.

As shown inFIG.7, the mktemp command701of source platform101has a functionality within a threshold degree of similarity to the combination of the head/dev/urandom command702and mkdir command703of target platform102(e.g., z/OS®). As illustrated inFIG.7, the mktemp command701includes building blocks602C,602H, and602I, which together have a functionality within the threshold degree of similarity to the combination of the head/dev/urandom command702and mkdir command703of target platform102(e.g., z/OS®). As further illustrated inFIG.7, the head/dev/urandom command702includes building blocks602E, and602J and the mkdir command703includes building blocks602E, and602K.

Another example of identifying a command(s) of source platform101or target platform102with a functionality within a threshold degree of similarity to a command(s) of target platform102or source platform101, respectively, is provided inFIG.8.

FIG.8illustrates a further example of comparison module204identifying a command(s) (e.g., stat -c ‘% s’ /var/log/messages) of source platform101(e.g., Linux® platform) or target platform102with a functionality within a threshold degree of similarity to a command(s) (e.g., ls -l /var/log/messages) of target platform102(e.g., z/OS®) or source platform, respectively, in accordance with an embodiment of the present disclosure.

As shown inFIG.8, the stat -c command601of source platform101has a functionality within a threshold degree of similarity to the ls -l command603of target platform102(e.g., z/OS®). As illustrated inFIG.8, the stat -c command601(e.g., stat -c ‘% s’ /var/log/messages) includes building blocks602A,602B, and602C, which together have a functionality within the threshold degree of similarity to the ls -l command603(e.g., ls -l /var/log/messages), which includes building blocks602D,602E,602F, and602G. For example, the information returned by the ls -l command603of target platform102corresponds to the information returned by the stat-c command601of source platform101.

Referring toFIG.2, in conjunction withFIGS.1and3-8, porting mechanism106additionally includes a labeling engine205configured to label each command of source platform101and/or target platform102with the designation of “same,” “mismatch,” or “missing” based on comparing the building blocks for each command of target platform102with the building blocks of commands of source platform101. The designation of “same,” as used herein, refers to a command of source platform101or target platform102that has an appearance and a functionality within a threshold degree of similarity of a command of target platform101or source platform101, respectively. The designation of “mismatch,” as used herein, refers to a command of source platform101or target platform102that has an appearance within a threshold degree of similarity of a command of target platform102or source platform101, respectively, but does not have a functionality within a threshold degree of similarity of the command of target platform102or source platform101, respectively. The designation of “missing,” as used herein, refers to a command of source platform101or target platform102that has a functionality within a threshold degree of similarity of a command of target platform102or source platform101, respectively, but does not have an appearance within a threshold degree of similarity of the command of target platform102or source platform101, respectively. The designations of “mismatch” and “missing” are indications of commands, such as the commands of source platform101, that are not supported by target platform102.

In one embodiment, comparison engine204determines whether the appearance of the command of source platform101and/or target platform102is within a threshold degree of similarity to the appearance of the command of target platform102and/or source platform101, respectively, based on vectorizing the commands of source and target platforms101,102. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the appearance of the commands of source platform101and target platform102. Such a similarity measure is compared to a threshold value, which may be user-designated, to determine if the appearance of the commands are within a threshold degree of similarity to one another. If the similarity measure exceeds such a threshold value, then the appearance of the commands are deemed to be within a threshold degree of similarity. Otherwise, the appearance of the commands are not deemed to be within the threshold degree of similarity.

“Cosine similarity,” as used herein, refers to a measure of similarity between two non-zero vectors defined in an inner product space. Cosine similarity is the cosine of the angle between the vectors. That is, it is the dot product of the vectors divided by the product of their lengths. If the measurement exceeds a threshold value, which may be user-designated, then the appearance of the commands are deemed to be within a threshold degree of similarity. Otherwise, the appearance of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the Euclidean distance is calculated as the square root of the sum of the squared differences between the two feature vectors. If the distance exceeds a threshold value, which may be user-designated, then the appearance of the commands are deemed to be within a threshold degree of similarity. Otherwise, the appearance of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the similarity measure is a score between the values of 0 and 1 for vectors that have only positive values. In one embodiment, any negative scores can be made positive by taking its absolute value.

Comparison engine204utilizes various software tools for generating the similarity score, which can include, but are not limited to, TensorFlow®, Math Works®, plus sklearn, scikit-learn®, etc.

In one embodiment, comparison engine204determines whether the functionality of the command of source platform101and/or target platform102is within a threshold degree of similarity to the functionality of the command of target platform102and/or source platform101, respectively, based on vectorizing the commands of source and target platforms101,102by vectorizing the building blocks of the commands, including the actions, parameters, inputs, functions, etc. of the building blocks, such as via Word2vec, Doc2Vec, GloVe, etc. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the functionality of the commands of source platform101and target platform102. Such a similarity measure is compared to a threshold value, which may be user-designated, to determine if the functionality of the commands are within a threshold degree of similarity to one another. If the similarity measure exceeds such a threshold value, then the functionality of the commands are deemed to be within a threshold degree of similarity. Otherwise, the functionality of the commands are not deemed to be within the threshold degree of similarity.

“Cosine similarity,” as used herein, refers to a measure of similarity between two non-zero vectors defined in an inner product space. Cosine similarity is the cosine of the angle between the vectors. That is, it is the dot product of the vectors divided by the product of their lengths. If the measurement exceeds a threshold value, which may be user-designated, then the functionality of the commands are deemed to be within a threshold degree of similarity. Otherwise, the functionality of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the Euclidean distance is calculated as the square root of the sum of the squared differences between the two feature vectors. If the distance exceeds a threshold value, which may be user-designated, then the functionality of the commands are deemed to be within a threshold degree of similarity. Otherwise, the functionality of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the similarity measure is a score between the values of 0 and 1 for vectors that have only positive values. In one embodiment, any negative scores can be made positive by taking its absolute value.

Comparison module204utilizes various software tools for generating the similarity score, which can include, but are not limited to, TensorFlow®, MathWorks®, plus sklearn, scikit-learn®, etc.

Based on the findings of comparison module204as to whether the commands of source platform101and/or target platform102have an appearance and functionality within the threshold degree of similarity of the commands of target platform102and/or source platform101, respectively, labeling engine205labels such commands of source platform101appropriately (e.g., “same,” “mismatch,” or “missing”) as illustrated inFIG.9.

FIG.9illustrates labeling each command of source platform101and/or target platform102(e.g., z/OS® platform) with the designation of “same,” “mismatch,” or “missing” based on comparing the building blocks for source and target platforms101,102in accordance with an embodiment of the present disclosure.

As shown inFIG.9, the commands of source platform101/target platform102are labeled as “same”901, “mismatch”902and “missing”903. As illustrated inFIG.9, the commands of cd904, mkdir703, ls -l603, cp905, and head/dev/urandom702of target platform102are labeled as “same”901since such commands have an appearance and functionality within the threshold degree of similarity of the commands of source platform101.

As further illustrated inFIG.9, the commands of mount-f906and stat -c601of source platform101(e.g., Linux® platform) are labeled as mismatch902since such commands have an appearance within a threshold degree of similarity of a command of target platform102but does not have a functionality within a threshold degree of similarity of the command of target platform102.FIG.9further illustrates an alternative command for performing the command of stat -c601of source platform101, which corresponds to the ls -l command603of target platform102as shown via arrow907.

Furthermore, as illustrated inFIG.9, the commands of mktemp701and date +% s908of source platform101(e.g., Linux® platform) are labeled as missing903as such commands have a functionality within a threshold degree of similarity of a command of target platform102but do not have an appearance within a threshold degree of similarity of the command of target platform102.FIG.9further illustrates an alternative command for performing the command of mktemp701of source platform101, which corresponds to the combination of the mkdir703and head/dev/urandom702commands of target platform102as shown via arrow909.

Returning toFIG.2, in conjunction withFIGS.1and3-9, porting mechanism106additionally includes a generator engine206configured to generate, if possible, alternative commands for the commands of source platform101labeled as mismatch and/or missing. In one embodiment, generator engine206generates such alternative commands based on the commands of target platform102identified by comparison module204as having a functionality within a threshold degree of similarity, which may be user-designated, to the commands of source platform101. For example, comparison module204may have identified the command of ls -l603from target platform102as having the same functionality (or within a threshold degree of similarity) as the command of stat -c601as identified by arrow907inFIG.9. In another example, comparison module204may have identified the commands of mkdir703and head/dev/urandom702from target platform102as having the same functionality (or within a threshold degree of similarity) as the command of mktemp701as identified by arrow909inFIG.9. As a result of identifying such alternative commands by comparison module204, generator engine206generates, if possible, alternative commands for the commands of source platform101labeled as mismatch and/or missing.

For example, referring toFIG.9, the command of stat -c601of source platform101is identified as being classified as mismatch902. Since comparison module204identified an alternative command (e.g., ls -l603) of target platform102for the command of stat -c601of source platform101, as illustrated by arrow907ofFIG.9, such an alternative command is generated by generator engine206. In another example, the command of mktemp701of source platform101is identified as being classified as missing903as shown inFIG.9. Since comparison module204identified an alternative command (e.g., combination of the commands of mkdir703and head/dev/urandom702) of target platform102for the command of mktemp701of source platform101, as illustrated by arrow909, such an alternative command is generated by generator engine206.

Generator engine206is further configured to adapt the script from source platform101to be utilized in target platform102by using such generated alternative commands. For example, as discussed above, the command of mktemp701of source platform101(e.g., Linux®) is classified as “missing” since such a command does not have a command with a functionality within a threshold degree of similarity of a command of target platform102(e.g., z/OS®). However, the command of mktemp701does have an alternative command that was generated by generator engine206, such as the combination of the mkdir703and head/dev/urandom702commands of target platform102. As a result, generator engine206adapts the script from source platform101to be utilized in target platform102by replacing the command of mktemp701in the script for source platform101with the combined commands of mkdir703and head/dev/urandom702of target platform102.

In another example, the command of stat -c601of source platform101(e.g., Linux®) is classified as “mismatch” since such a command does not have a command with an appearance within a threshold degree of similarity of a command of target platform102(e.g., z/OS®). However, the command of stat -c601does have an alternative command that was generated by generator engine206, such as the command of ls -l603of target platform102which returns the same information as the information returned by the stat -c command601. As a result, generator engine206adapts the script from source platform101to be utilized in target platform102by replacing the stat -c command601in the script for source platform101with the command of ls -l603of target platform102.

In this manner, scripts from a source platform (e.g., Linux®) which contain commands unsupported by a target platform (e.g., z/OS®) are adapted to be utilized in the target platform (e.g., z/OS®) when porting, such as porting open-source tools.

A further discussion regarding adapting scripts from source platform101to be utilized in target platform102by replacing commands that are unsupported by the target platform with alternative commands that are supported by the target platform is provided below.

Referring again toFIG.2, in conjunction withFIGS.1and3-9, porting mechanism106includes a parser207configured to parse an incoming script from source platform101line by line.

“Parsing,” as used herein, refers to analyzing and breaking down a sequence of input symbols or tokens into its component parts to determine its structure and meaning. Examples of parser207performing such parsing can include, but are not limited to, ANTLR®, Bison, Lemon, Lex, Parboiled, Ragel, XPL, etc.

Upon parsing the incoming script, comparison module204identifies a command in the parsed script, such as for the recent line of the incoming script that was parsed.

In one embodiment, comparison module204is configured to identify a command in the parsed script based on matching the name of a command (e.g., stat -c) in the parsed script with a listing of commands in a data structure (e.g., table) for various platforms, including both source and target platforms101,102. In one embodiment, such a data structure resides within the storage device of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

Upon identifying a command in the parsed script, generator engine206of porting mechanism106determines whether the identified command is labeled the “same”901.

For example, as discussed above, labeling engine205labels various commands with the designations of “same,” “mismatch,” or “missing.” In one embodiment, generator engine206accesses a data structure (e.g., table) with information as shown inFIG.9that was populated by labeling engine205. In one embodiment, such a data structure resides within the storage device of porting mechanism106. Upon locating the command identified in such a data structure, generator engine206determines if such a command is labeled under the category of “same”901.

If the identified command is labeled with the designation of “same,” then generator engine206writes the line of script from the parsed incoming script with the identified command in the output script for target platform102.

If, however, the identified command is not identified as being labeled with the designation of “same,” then such an identified command is identified as being either “mismatch” or “missing.” As a result, if the identified command is not identified as being labeled with the designation of “same,” then generator engine206of porting mechanism106determines whether there are any alternative commands for the commands of source platform101that are labeled as “mismatch” or “missing.”

As discussed above, labeling engine205labels various commands with the designations of “same,” “mismatch,” or “missing.” In one embodiment, generator engine206accesses a data structure (e.g., table) with information as shown inFIG.9that was populated by labeling engine205. Upon locating the command identified in such a data structure, generator engine206determines if such a command is labeled under the category of “mismatch”902or “missing”903. Upon identifying the command labeled as “mismatch”902or “missing”903, generator engine206determines if such a command has an alternative command that was identified by comparison module204, where such information (e.g., information such as shown by arrows907,909inFIG.9) was stored in a data structure (e.g., table) populated by labeling engine205. As a result, generator engine206performs a look-up of such a data structure to identify any alternative command for the command identified.

If there is not an alternative command for the identified command, then generator engine206inserts a warning message in the output script for target platform102that the command is labeled as mismatch or missing but with no generated alternative commend.

If, however, there is an alternative command, then generator engine206replaces the command from the line of script in the parsed incoming script with the generated alternative command and writes the line of script from the parsed incoming script with the replaced command in the output script for target platform102. For example, the command of stat -c601in the incoming script of source platform101is replaced with the alternative command of ls -l603as shown inFIG.9, where the line of script from the parsed incoming script with such a replacement is then written to the output script for target platform102.

In one embodiment, generator engine206utilizes various software tools for writing lines of code in the output script, inserting warning messages in the output script, replacing commands in the incoming script with alternative commands to be written to the output script, etc., which can include, but are not limited to, UltraEdit®, Xcode®, CodeLite, Emacs®, Vim®, etc.

Furthermore, in one embodiment, upon parsing each of the lines in the incoming script from source platform101and performing such tasks as discussed above, the output script is ready to be issued to target platform102to be executed on target platform102.

A further description of these and other features is provided below in connection with the discussion of the method for adapting scripts from a source platform to be utilized in a target platform during porting.

Prior to the discussion of the method for adapting scripts from a source platform to be utilized in a target platform during porting, a description of the hardware configuration of porting mechanism106(FIG.1) is provided below in connection withFIG.10.

Referring now toFIG.10, in conjunction withFIG.1,FIG.10illustrates an embodiment of the present disclosure of the hardware configuration of porting mechanism106which is representative of a hardware environment for practicing the present disclosure.

Computing environment1000contains an example of an environment for the execution of at least some of the computer code1001involved in performing the inventive methods, such as adapting scripts from a source platform to be utilized in a target platform during porting. In addition to block1001, computing environment1000includes, for example, porting mechanism106, network103, such as a wide area network (WAN), end user device (EUD)1002, remote server1003, public cloud1004, and private cloud1005. In this embodiment, porting mechanism106includes processor set1006(including processing circuitry1007and cache1008), communication fabric1009, volatile memory1010, persistent storage1011(including operating system1012and block1001, as identified above), peripheral device set1013(including user interface (UI) device set1014, storage1015, and Internet of Things (IoT) sensor set1016), and network module1017. Remote server1003includes remote database1018. Public cloud1004includes gateway1019, cloud orchestration module1020, host physical machine set1021, virtual machine set1022, and container set1023.

Processor set1006includes one, or more, computer processors of any type now known or to be developed in the future. Processing circuitry1007may be distributed over multiple packages, for example, multiple, coordinated integrated circuit chips. Processing circuitry1007may implement multiple processor threads and/or multiple processor cores. Cache1008is memory that is located in the processor chip package(s) and is typically used for data or code that should be available for rapid access by the threads or cores running on processor set1006. Cache memories are typically organized into multiple levels depending upon relative proximity to the processing circuitry. Alternatively, some, or all, of the cache for the processor set may be located “off chip.” In some computing environments, processor set306may be designed for working with qubits and performing quantum computing.

Computer readable program instructions are typically loaded onto porting mechanism106to cause a series of operational steps to be performed by processor set1006of porting mechanism106and thereby effect a computer-implemented method, such that the instructions thus executed will instantiate the methods specified in flowcharts and/or narrative descriptions of computer-implemented methods included in this document (collectively referred to as “the inventive methods”). These computer readable program instructions are stored in various types of computer readable storage media, such as cache1008and the other storage media discussed below. The program instructions, and associated data, are accessed by processor set1006to control and direct performance of the inventive methods. In computing environment1000, at least some of the instructions for performing the inventive methods may be stored in block1001in persistent storage1011.

Volatile memory1010is any type of volatile memory now known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, the volatile memory is characterized by random access, but this is not required unless affirmatively indicated. In porting mechanism106, the volatile memory1010is located in a single package and is internal to porting mechanism106, but, alternatively or additionally, the volatile memory may be distributed over multiple packages and/or located externally with respect to porting mechanism106.

Network module1017is the collection of computer software, hardware, and firmware that allows porting mechanism106to communicate with other computers through WAN103. Network module1017may include hardware, such as modems or Wi-Fi signal transceivers, software for packetizing and/or de-packetizing data for communication network transmission, and/or web browser software for communicating data over the internet. In some embodiments, network control functions and network forwarding functions of network module1017are performed on the same physical hardware device. In other embodiments (for example, embodiments that utilize software-defined networking (SDN)), the control functions and the forwarding functions of network module1017are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer readable program instructions for performing the inventive methods can typically be downloaded to porting mechanism106from an external computer or external storage device through a network adapter card or network interface included in network module1017.

End user device (EUD)1002is any computer system that is used and controlled by an end user (for example, a customer of an enterprise that operates porting mechanism106), and may take any of the forms discussed above in connection with porting mechanism106. EUD1002typically receives helpful and useful data from the operations of porting mechanism106. For example, in a hypothetical case where porting mechanism106is designed to provide a recommendation to an end user, this recommendation would typically be communicated from network module1017of porting mechanism106through WAN103to EUD1002. In this way, EUD1002can display, or otherwise present, the recommendation to an end user. In some embodiments, EUD1002may be a client device, such as thin client, heavy client, mainframe computer, desktop computer and so on.

Remote server1003is any computer system that serves at least some data and/or functionality to porting mechanism106. Remote server1003may be controlled and used by the same entity that operates porting mechanism106. Remote server1003represents the machine(s) that collect and store helpful and useful data for use by other computers, such as porting mechanism106. For example, in a hypothetical case where porting mechanism106is designed and programmed to provide a recommendation based on historical data, then this historical data may be provided to porting mechanism106from remote database1018of remote server1003.

Public cloud1004is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and/or other computer capabilities, especially data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages sharing of resources to achieve coherence and economies of scale. The direct and active management of the computing resources of public cloud1004is performed by the computer hardware and/or software of cloud orchestration module1020. The computing resources provided by public cloud1004are typically implemented by virtual computing environments that run on various computers making up the computers of host physical machine set1021, which is the universe of physical computers in and/or available to public cloud1004. The virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set1022and/or containers from container set1023. It is understood that these VCEs may be stored as images and may be transferred among and between the various physical machine hosts, either as images or after instantiation of the VCE. Cloud orchestration module1020manages the transfer and storage of images, deploys new instantiations of VCEs and manages active instantiations of VCE deployments. Gateway1019is the collection of computer software, hardware, and firmware that allows public cloud1004to communicate through WAN103.

Private cloud1005is similar to public cloud1004, except that the computing resources are only available for use by a single enterprise. While private cloud1005is depicted as being in communication with WAN103in other embodiments a private cloud may be disconnected from the internet entirely and only accessible through a local/private network. A hybrid cloud is a composition of multiple clouds of different types (for example, private, community or public cloud types), often respectively implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technology that enables orchestration, management, and/or data/application portability between the multiple constituent clouds. In this embodiment, public cloud1004and private cloud1005are both part of a larger hybrid cloud.

Block1001further includes the software components discussed herein in connection withFIGS.2-9to adapt scripts from a source platform to be utilized in a target platform during porting. In one embodiment, such components may be implemented in hardware. The functions discussed above performed by such components are not generic computer functions. As a result, porting mechanism106is a particular machine that is the result of implementing specific, non-generic computer functions.

In one embodiment, the functionality of such software components of porting mechanism106, including the functionality for adapting scripts from a source platform to be utilized in a target platform during porting, may be embodied in an application specific integrated circuit.

As stated above, when porting software, such as open-source tools, across different operating systems (e.g., Linux®, iOS®, Unix®, etc.) and/or hardware platforms (e.g., x86, Arm®, etc.), many scripts from a source platform need to be modified in order to be executed successfully on a target platform. A script refers to a program or sequence of instructions that is interpreted or carried out by another program rather than by the computer processor. A platform refers to the hardware and software (operation system) on which software applications can be run. A source platform refers to the platform upon which the scripts were originally designed for execution. A target platform refers to the platform upon which the scripts are desired to be executed. For example, the script for a BATS (Bash Automated Testing System) framework in a source platform, such as the Linux® platform, may not be supported by the target platform (e.g., z/OS®). For instance, the commands of the script for the BATS framework may be not supported by the target platform. If the target platform does not report errors or warnings regarding unsupported commands, then the user will have no knowledge of such unsupported commands. As a result, the user may spend enormous time in attempting to identify the reasons for the script not executing on the target platform as well as spend enormous time in modifying the script in order to be properly executed on the target platform. Unfortunately, there is not currently a means for informing the user regarding unsupported commands. Neither is there a means for automatically modifying the scripts from the source platform in order to be correctly executed on the target platform.

The embodiments of the present disclosure provide a means for adapting scripts from a source platform (e.g., Linux®) to be utilized in a target platform (e.g., z/OS®) when porting, such as porting open-source tools, as discussed below in connection withFIGS.11-12.FIG.11is a flowchart of a method for adapting scripts from a source platform (e.g., Linux®) to be utilized in a target platform (e.g., z/OS®) when porting.FIG.12is a flowchart of a method for adapting scripts from a source platform to be utilized in a target platform by replacing commands in the script for the source platform that are unsupported by the target platform with alternative commands that are supported by the target platform.

As stated above,FIG.11is a flowchart of a method1100for adapting scripts from a source platform (e.g., Linux®) to be utilized in a target platform (e.g., z/OS®) when porting in accordance with an embodiment of the present disclosure.

Referring toFIG.11, in conjunction withFIGS.1-10, in step1101, analyzing engine201of porting mechanism106analyzes traces of system calls from commands in source and target platforms101,102to identify building blocks.

As discussed above, a “system call,” as used herein, is the programmatic way in which a computer program requests a service from the operating system on which it is executed. For example, commands from the script from source platform101may request a service from operating system104. In another example, commands from the script to be utilized in target platform102may request a service from operating system105.

A “system call trace,” as used herein, refers to the specialized use of logging to record information about the system call. A “building block,” as used herein, refers to a portion of the script that contains functionality for performing task-based operations. For example, such task-based operations may include creating a service requirement, registering for an event, etc. Furthermore, building blocks typically contain one or more application programming interfaces (APIs). Such building blocks may be combined to perform the task-based operations of a command (e.g., reading configuration files, copying files, moving and renaming files, creating empty files, etc.).

Furthermore, as discussed above, in one embodiment, analyzing engine201traces system calls via the use of tracing tools, which can include, but are not limited to, strace, dtruss, Jaeger, Zipkin, Dynatrace®, etc.

In one embodiment, analyzing engine201analyzes such traces to identify building blocks based on identifying functions (e.g., openat( ), mmap( ), statx( ), write( ), etc.), where the lines of code of the function correspond to the building block as illustrated inFIG.3. In one embodiment, analyzing engine201identifies the functions in the system call traces based on identifying terms listed in a data structure (e.g., table) corresponding to functions to be identified in the system call traces. For example, such a data structure may include the terms of “openat( ),” “mmap( ),” “statx( ),” “write( ),” etc. corresponding to functions to be identified in the system call traces. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

Referring now toFIG.3, analyzing engine201identifies the functions (e.g., openat( ), mmap( ), statx( ), write( ), etc.) used in the system call traces of commands from source platform101(e.g., Linux® platform). For instance, analyzing engine201identified the function openat( ) (opens the file named by the path) corresponding to building block ID (“Block ID”): A1(see element302A), where the lines of code for such an identified function correspond to the building block, such as building block301A. In one embodiment, analyzing engine201generates an identifier (“Block ID”) for each building block identified. In one embodiment, the type of building block (“Block Type”) for each identified building block is identified by analyzing engine201based on the identified function and the input or parameter of the identified function listed within the parenthesis of the function. For example, the building block type for building block301A corresponds to having the common dependence libraries inform (see element303A). In one embodiment, analyzing engine201determines such information based on identifying the function in the data structure (e.g., table) containing a listing of functions that are associated with various building block types. Furthermore, such a data structure may include an identification of the building block type based on the input or parameters within the parenthesis of the function. As a result, analyzing engine201is able to identify the building block type based on identifying the input or parameters within the parenthesis of the identified function. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

Other examples include analyzing engine201identifying the function openat( ) corresponding to building block ID (“Block ID”): B1(see element302B), where the lines of code for such an identified function correspond to the building block, such as building block301B. Furthermore, analyzing engine201identifies the building block type for building block301B as corresponding to a common dependence library (see element303B).

In another example, analyzing engine201identifies the function mmap( ) (creates a new mapping in the virtual address space) corresponding to building block ID (“Block ID”): C1(see element302C), where the lines of code for such an identified function correspond to the building block, such as building block301C. Furthermore, analyzing engine201identifies the building block type for building block301C as corresponding to requesting a resource to enforce security controls (see element303C).

In a further example, analyzing engine201identifies the function statx( ) (identifies the target file) corresponding to building block ID (“Block ID”): D1(see element302D), where the lines of code for such an identified function correspond to the building block, such as building block301D. Furthermore, analyzing engine201identifies the building block type for building block301D as corresponding to getting information about the file (see element303D).

In another example, analyzing engine201identifies the function write( ) (creates a communication line) corresponding to building block ID (“Block ID”): E1(see element302E), where the lines of code for such an identified function correspond to the building block, such as building block301E. Furthermore, analyzing engine201identifies the building block type for building block301E as corresponding to writing to the standard output (see element303E).

In step1102, constructing engine202of porting mechanism106constructs a tree structure for each command of source and target platforms101,102with one or more building blocks from the building blocks identified by analyzing engine201.

As stated above, in one embodiment, constructing engine202constructs such tree structures by analyzing the commands' system call traces.

For example, in one embodiment, constructing engine202analyzes the particular command's system call trace to identify the building blocks out of the building blocks identified by analyzing engine201based on identifying functions (e.g., openat( ), mmap( ), statx( ), write( ), etc.), where the lines of code of the function correspond to the building blocks. In one embodiment, analyzing engine201identifies the functions in the system call traces based on identifying terms listed in a data structure (e.g., table) corresponding to functions to be identified in the system call traces. For example, such a data structure may include the terms of “openat( ),” “mmap( ),” “statx( ),” “write( ),” etc. corresponding to functions to be identified in the system call traces. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

In one embodiment, tree structures are constructed based on such analysis of the particular command's system call trace based on determining the dependencies among the building blocks. Such dependencies, as used herein, refer to relationships between the building blocks, such as the functions of the building blocks, where one building block relies on the other to work properly. In one embodiment, such dependencies are obtained using various dependency analysis tools, which can include, but are not limited to, Math Works® (e.g., matlab.codetools.requiredFilesandProducts function), DepAn, slizaa, Softagram®, etc.

In one embodiment, based on such dependencies, a tree structure of such dependencies (parent-child relationships) is constructed by constructing engine202. A tree structure, as used herein, refers to a hierarchical structure that is used to represent and organize the building blocks performing the task-based operations of the command. In such a hierarchical structure, the nodes in a tree structure represent the building blocks identified from analyzing the particular command's system call trace. Each node in the tree structure has zero or more child nodes, which are located beneath it in the tree structure. A node that has a child is called the child's parent node. All nodes have exactly one parent, except the topmost root node, which has none. An illustration of such a tree structure is shown inFIG.4.

As shown inFIG.4, tree structure400is constructed for a command401(e.g., command1) based on the dependencies among the building blocks402, such as building blocks A1, B1, B2, B3, C1, D1, E1and so forth as shown inFIG.4.

As illustrated inFIG.4, tree structure400is constructed based on building blocks402whose corresponding block identifiers (“Block ID”) and building block types (“Block Type”) are shown in table403. As illustrated in table403, building blocks (e.g., B1, B2, and B3) with the building block type of having a common dependence library are the child nodes to the building block (e.g., A1) with the building block type corresponding to having the common dependence libraries inform. Such dependencies are illustrated in tree structure400by having building blocks B1, B2, and B3be the child nodes to building block A1.

In one embodiment, constructing engine202is configured to construct a tree structure for each command of source and target platforms101,102with one or more building blocks from the building blocks identified by analyzing engine201based on the determined dependencies among the building blocks using various software tools, which can include, but are not limited to, Graphviz®, Mermaid, Nomnoml, etc.

In step1103, refinement engine203of porting mechanism106refines the command's tree structure (e.g., tree structure400) by categorizing the building blocks of tree structure400as being trivial or critical based on the relatedness to the key or main function of the command. The category of “trivial,” as used herein, refers to building blocks with little value or importance in accomplishing the key or main function of the command and do not need to be utilized when identifying commands of target platform102with a functionality within a threshold degree of similarity as the commands of source platform101. The category of “crucial,” as used herein, refers to building blocks of great importance in accomplishing the key or main function of the command and need to be utilized when identifying commands of target platform102with a functionality within a threshold degree of similarity as the commands of source platform101. In one embodiment, such building blocks are categorized as being “trivial” or “critical” based on weights assigned to the building blocks. For example, a weight of 1 or less assigned to a building block indicates categorizing such a building block as being trivial; whereas, assigning a weight of greater than 1 (e.g., 3) indicates categorizing such a building block as being critical. In one embodiment, the value of the weight assigned to such building blocks is based on the degree of relatedness to the key or main function of the command.

As discussed above, in one embodiment, refinement engine203categorizes the building blocks of tree structure400based on determining the relatedness to the key or main function of the command. In one embodiment, the key or main function of the command is determined based on identifying the key or main function (e.g., provide information about the file and filesystem) of the command (e.g., stat -c) listed in a data structure (e.g., table). For example, such a data structure may include the key or main function of “providing information about the file and filesystem” corresponding to the stat -c command. Furthermore, in such a data structure, the key or main function may be associated with other functions that are of great importance for implementing such a key or main function, such as write( ), statx( ), etc. Upon identifying such functions from the data structure, refinement engine203attempts to identify such functions associated with the building blocks of tree structure400. Upon identifying such functions in the building blocks of tree structure400, such building blocks are classified as being “critical,” whereas, the other building blocks are classified as being “trivial” as shown inFIG.5. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

An example of such classification is shown inFIG.5. Referring toFIG.5, building blocks501have been identified as being trivial since such functions associated with such building blocks of tree structure400are of little value or importance in accomplishing the key or main function of the command.FIG.5further illustrates that building blocks502have been identified as critical since such building blocks are of great importance in accomplishing the key or main function of the command. In one embodiment, the functions (e.g., statx( ), write( )) of such building blocks502may have been identified in a data structure as being of great importance for implementing the key or main function of command401. As a result, such building blocks502are identified as being critical.

In step1104, refinement engine203of porting mechanism106assigns the building blocks of the command's tree structure400with a weight based on the relatedness to the key or main function of the command.

As discussed above, building blocks402of command401as shown inFIG.4may, in addition or alternatively to being classified as being “trivial” or “critical” as discussed above, be assigned a weight based on the relatedness to the key or main function of command401. In one embodiment, the key or main function of the command is determined based on identifying the key or main function (e.g., provide information about the file and filesystem) of the command (e.g., stat -c) listed in a data structure (e.g., table). For example, such a data structure may include the key or main function of “providing information about the file and filesystem” corresponding to the stat -c command. Furthermore, in such a data structure, the key or main function may be associated with various functions that are of varying degrees of importance for implementing the key or main function. Such varying degrees of importance may be identified via an assigned weight to such a function, where the lower the value of the weight, the less important is the function for implementing the key or main function of command401and vice-versa. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106. In one embodiment, such a data structure is populated by an expert. An example of assigning each command's building blocks an appropriate weight, such as using the data structure discussed above, is illustrated inFIG.6.

Referring toFIG.6,FIG.6illustrates assigning weights to the building blocks of command601(e.g., stat -c ‘% s’ /var/log/messages) from source platform101. For instance, the openat( ) function may be of little importance to implementing the key or main function of command601(e.g., stat -c); whereas, the statx( ) function may be of great importance to implementing the key or main function of command601(stat -c). As a result, a higher weight (e.g., 3) may be assigned to building block602A associated with the function of statx( ) and a lower weight (e.g., 0.5) may be assigned to the building blocks602B-602C associated with the function of openat( ).

FIG.6further illustrates assigning weights to the building blocks of command603(e.g., ls -l /var/log/messages) from target platform102. For instance, the openat( ) function may be of little importance to implementing the key or main function of command603(e.g., ls -l); whereas, the statx( ) function may be of great importance to implementing the key or main function of command603(e.g., ls -l). As a result, a higher weight (e.g., 3) may be assigned to building block602D associated with the function of statx( ) and a lower weight (e.g., 0.5) may be assigned to the building blocks602E-602G associated with the function of openat( ).

In step1105, comparison module204of porting mechanism106identifies the commands of target platform102with a functionality within a threshold degree of similarity, which may be user-designated, to the commands of source platform101by analyzing the building blocks of the commands' tree structures400for those commands categorized as critical and/or with a weight that exceeds a threshold value.

As stated above, in one embodiment, such similarity between the commands of source platform101and target platform102may be determined by vectorizing the building blocks of the commands, including the actions, parameters, inputs, functions, etc. of the building blocks, such as via Word2vec, Doc2Vec, GloVe, etc. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the commands of source platform101and target platform102. Such a similarity measure is compared to a threshold value, which may be user-designated, to determine if the commands are within a threshold degree of similarity to one another. If the similarity measure exceeds such a threshold value, then the commands are deemed to be within a threshold degree of similarity. Otherwise, the commands are not deemed to be within the threshold degree of similarity.

“Cosine similarity,” as used herein, refers to a measure of similarity between two non-zero vectors defined in an inner product space. Cosine similarity is the cosine of the angle between the vectors. That is, it is the dot product of the vectors divided by the product of their lengths. If the measurement exceeds a threshold value, which may be user-designated, then the commands are deemed to be within a threshold degree of similarity. Otherwise, the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the Euclidean distance is calculated as the square root of the sum of the squared differences between the two feature vectors. If the distance exceeds a threshold value, which may be user-designated, then the commands are deemed to be within a threshold degree of similarity. Otherwise, the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the similarity measure is a score between the values of 0 and 1 for vectors that have only positive values. In one embodiment, any negative scores can be made positive by taking its absolute value.

Comparison module204utilizes various software tools for generating the similarity score, which can include, but are not limited to, TensorFlow®, MathWorks®, plus sklearn, scikit-learn®, etc.

An illustration of comparison module204identifying a command(s) of source platform101with a functionality within a threshold degree of similarity to a command(s) of target platform102by analyzing the building blocks of the commands' tree structures400for those command categorized as critical and/or with a weight that exceeds a threshold value is provided inFIG.7.

As shown inFIG.7, the mktemp command701of source platform101has a functionality within a threshold degree of similarity to the combination of the head/dev/urandom command702and mkdir command703of target platform102(e.g., z/OS®). As illustrated inFIG.7, the mktemp command701includes building blocks602C,602H, and602I, which together have a functionality within the threshold degree of similarity to the combination of the head/dev/urandom command702and mkdir command703of target platform102(e.g., z/OS®). As further illustrated inFIG.7, the head/dev/urandom command702includes building blocks602E, and602J and the mkdir command703includes building blocks602E, and602K.

Another example of identifying a command(s) of source platform101with a functionality within a threshold degree of similarity to a command(s) of target platform102is provided inFIG.8.

As shown inFIG.8, the stat -c command601of source platform101has a functionality within a threshold degree of similarity to the ls -l command603of target platform102(e.g., z/OS®). As illustrated inFIG.8, the stat -c command601(e.g., stat -c ‘% s’ /var/log/messages) includes building blocks602A,602B, and602C, which together have a functionality within the threshold degree of similarity to the ls -l command603(e.g., ls -l/var/log/messages), which includes building blocks602D,602E,602F, and602G. For example, the information returned by the ls -l command603of target platform102corresponds to the information returned by the stat -c command601of source platform101.

In step1106, labeling engine205of porting mechanism106labels each command of source platform101and/or target platform102with the designation of “same,” “mismatch,” or “missing” based on comparing the building blocks for each command of target platform102with the building blocks of commands of source platform101.

As discussed above, the designation of “same,” as used herein, refers to a command of source platform101or target platform102that has an appearance and a functionality within a threshold degree of similarity of a command of target platform101or source platform101, respectively. The designation of “mismatch,” as used herein, refers to a command of source platform101or target platform102that has an appearance within a threshold degree of similarity of a command of target platform102or source platform101, respectively, but does not have a functionality within a threshold degree of similarity of the command of target platform102or source platform101, respectively. The designation of “missing,” as used herein, refers to a command of source platform101or target platform102that has a functionality within a threshold degree of similarity of a command of target platform102or source platform101, respectively, but does not have an appearance within a threshold degree of similarity of the command of target platform102or source platform101, respectively. The designations of “mismatch” and “missing” are indications of commands, such as the commands of source platform101, that are not supported by target platform102.

In one embodiment, comparison engine204determines whether the appearance of the command of source platform101and/or target platform102is within a threshold degree of similarity to the appearance of the command of target platform102and/or source platform101, respectively, based on vectorizing the commands of source and target platforms101,102. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the appearance of the commands of source platform101and target platform102. Such a similarity measure is compared to a threshold value, which may be user-designated, to determine if the appearance of the commands are within a threshold degree of similarity to one another. If the similarity measure exceeds such a threshold value, then the appearance of the commands are deemed to be within a threshold degree of similarity. Otherwise, the appearance of the commands are not deemed to be within the threshold degree of similarity.

“Cosine similarity,” as used herein, refers to a measure of similarity between two non-zero vectors defined in an inner product space. Cosine similarity is the cosine of the angle between the vectors. That is, it is the dot product of the vectors divided by the product of their lengths. If the measurement exceeds a threshold value, which may be user-designated, then the appearance of the commands are deemed to be within a threshold degree of similarity. Otherwise, the appearance of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the Euclidean distance is calculated as the square root of the sum of the squared differences between the two feature vectors. If the distance exceeds a threshold value, which may be user-designated, then the appearance of the commands are deemed to be within a threshold degree of similarity. Otherwise, the appearance of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the similarity measure is a score between the values of 0 and 1 for vectors that have only positive values. In one embodiment, any negative scores can be made positive by taking its absolute value.

Comparison engine204utilizes various software tools for generating the similarity score, which can include, but are not limited to, TensorFlow®, MathWorks®, plus sklearn, scikit-learn®, etc.

In one embodiment, comparison engine204determines whether the functionality of the command of source platform101and/or target platform102is within a threshold degree of similarity to the functionality of the command of target platform102and/or source platform101, respectively, based on vectorizing the commands of source and target platforms101,102by vectorizing the building blocks of the commands, including the actions, parameters, inputs, functions, etc. of the building blocks, such as via Word2vec, Doc2Vec, GloVe, etc. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the functionality of the commands of source platform101and target platform102. Such a similarity measure is compared to a threshold value, which may be user-designated, to determine if the functionality of the commands are within a threshold degree of similarity to one another. If the similarity measure exceeds such a threshold value, then the functionality of the commands are deemed to be within a threshold degree of similarity. Otherwise, the functionality of the commands are not deemed to be within the threshold degree of similarity.

“Cosine similarity,” as used herein, refers to a measure of similarity between two non-zero vectors defined in an inner product space. Cosine similarity is the cosine of the angle between the vectors. That is, it is the dot product of the vectors divided by the product of their lengths. If the measurement exceeds a threshold value, which may be user-designated, then the functionality of the commands are deemed to be within a threshold degree of similarity. Otherwise, the functionality of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the Euclidean distance is calculated as the square root of the sum of the squared differences between the two feature vectors. If the distance exceeds a threshold value, which may be user-designated, then the functionality of the commands are deemed to be within a threshold degree of similarity. Otherwise, the functionality of the commands are not deemed to be within the threshold degree of similarity.

In one embodiment, the similarity measure is a score between the values of 0 and 1 for vectors that have only positive values. In one embodiment, any negative scores can be made positive by taking its absolute value.

Comparison module204utilizes various software tools for generating the similarity score, which can include, but are not limited to, TensorFlow®, MathWorks®, plus sklearn, scikit-learn®, etc.

Based on the findings of comparison module204as to whether the commands of source platform101and/or target platform102have an appearance and functionality within the threshold degree of similarity of the commands of target platform102and/or source platform101, respectively, labeling engine205labels such commands of source platform101appropriately (e.g., “same,” “mismatch,” or “missing”) as illustrated inFIG.9.

As shown inFIG.9, the commands of source platform101/target platform102are labeled as “same”901, “mismatch”902and “missing”903. As illustrated inFIG.9, the commands of cd904, mkdir703, ls -l603, cp905, and head/dev/urandom702of target platform102are labeled as “same”901since such commands have an appearance and functionality within the threshold degree of similarity of the commands of source platform101.

As further illustrated inFIG.9, the commands of mount-f906and stat -c601of source platform101(e.g., Linux® platform) are labeled as mismatch902since such commands have an appearance within a threshold degree of similarity of a command of target platform102but do not have a functionality within a threshold degree of similarity of the command of target platform102.FIG.9further illustrates an alternative command for performing the command of stat -c601of source platform101, which corresponds to the ls -l command603of target platform102as shown via arrow907.

Furthermore, as illustrated inFIG.9, the commands of mktemp701and date +% s908of source platform101(e.g., Linux® platform) are labeled as missing903as such commands have a functionality within a threshold degree of similarity of a command of target platform102but do not have an appearance within a threshold degree of similarity of the command of target platform102.FIG.9further illustrates an alternative command for performing the command of mktemp701of source platform101, which corresponds to the combination of the mkdir703and head/dev/urandom702commands of target platform102as shown via arrow909.

In step1107, generator engine206of porting mechanism106generates, if possible, alternative commands for the commands of source platform101labeled as mismatch and/or missing.

As stated above, in one embodiment, generator engine206generates such alternative commands based on the commands of target platform102identified by comparison module204as having a functionality within a threshold degree of similarity, which may be user-designated, to the commands of source platform101. For example, comparison module204may have identified the command of ls -l603from target platform102as having the same functionality (or within a threshold degree of similarity) as the command of stat -c601as identified by arrow907inFIG.9. In another example, comparison module204may have identified the commands of mkdir703and head/dev/urandom702from target platform102as having the same functionality (or within a threshold degree of similarity) as the command of mktemp701as identified by arrow909inFIG.9. As a result of identifying such alternative commands by comparison module204, generator engine206generates, if possible, alternative commands for the commands of source platform101labeled as mismatch and/or missing, which is an indication of a command unsupported by target platform102.

For example, referring toFIG.9, the command of stat -c601of source platform101is identified as being classified as mismatch902. Since comparison module204identified an alternative command (e.g., ls -l603) of target platform102for the command of stat -c601of source platform101, as illustrated by arrow907ofFIG.9, such an alternative command is generated by generator engine206. In another example, the command of mktemp701of source platform101is identified as being classified as missing903as shown inFIG.9. Since comparison module204identified an alternative command (e.g., combination of the commands of mkdir703and head/dev/urandom702) of target platform102for the command of mktemp701of source platform101, as illustrated by arrow909, such an alternative command is generated by generator engine206.

In step1108, generator engine206of porting mechanism106adapts the script from source platform101to be utilized in target platform102by using such generated alternative commands. For example, as discussed above, the command of mktemp701of source platform101(e.g., Linux®) is classified as “missing” since such a command does not have a command with a functionality within a threshold degree of similarity of a command of target platform102(e.g., z/OS®). However, the command of mktemp701does have an alternative command that was generated by generator engine206, such as the combination of the mkdir703and head/dev/urandom702commands of target platform102. As a result, generator engine206adapts the script from source platform101to be utilized in target platform102by replacing the command of mktemp701in the script for source platform101with the combined commands of mkdir703and head/dev/urandom702of target platform102.

In another example, the command of stat -c601of source platform101(e.g., Linux®) is classified as “mismatch” since such a command does not have a command with an appearance within a threshold degree of similarity of a command of target platform102(e.g., z/OS®). However, the command of stat -c601does have an alternative command that was generated by generator engine206, such as the command of ls -l603of target platform102which returns the same information as the information returned by the stat -c command601. As a result, generator engine206adapts the script from source platform101to be utilized in target platform102by replacing the stat -c command601in the script for source platform101with the command of ls -l603of target platform102.

In this manner, scripts from a source platform (e.g., Linux®) which contain commands unsupported by a target platform (e.g., z/OS®) are adapted to be utilized in the target platform (e.g., z/OS®) when porting, such as porting open-source tools.

A further discussion regarding adapting scripts from source platform101to be utilized in target platform102by replacing commands that are unsupported by the target platform with alternative commands that are supported by the target platform is provided below in connection withFIG.12.

FIG.12is a flowchart of a method1200for adapting scripts from a source platform (e.g., source platform101ofFIG.1) to be utilized in a target platform (e.g., target platform102ofFIG.1) by replacing commands in the script for the source platform that are unsupported by the target platform with alternative commands that are supported by the target platform in accordance with an embodiment of the present disclosure.

Referring toFIG.12, in conjunction withFIGS.1-11, in step1201, parser207of porting mechanism106parses the incoming script for source platform101line by line.

“Parsing,” as used herein, refers to analyzing and breaking down a sequence of input symbols or tokens into its component parts to determine its structure and meaning. Examples of parser207performing such parsing can include, but are not limited to, ANTLR®, Bison, Lemon, Lex, Parboiled, Ragel, XPL, etc.

In step1202, comparison module204of porting mechanism106identifies a command in the parsed script, such as for the recent line of the incoming script that was parsed.

In one embodiment, comparison module204is configured to identify a command in the parsed script based on matching the name of a command (e.g., stat -c) in the parsed script with a listing of commands in a data structure (e.g., table) for various platforms, including both source and target platforms101,102. In one embodiment, such a data structure resides within the storage device (e.g.,1011,1015) of porting mechanism106. In one embodiment, such a data structure is populated by an expert.

Upon identifying a command in the parsed script, in step1203, generator engine206of porting mechanism106determines whether the identified command is labeled the “same”901.

For example, as discussed above, labeling engine205labels various commands with the designations of “same,” “mismatch,” or “missing.” In one embodiment, generator engine206accesses a data structure (e.g., table) with information as shown inFIG.9that was populated by labeling engine205. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106. Upon locating the command identified in step1202in such a data structure, generator engine206determines if such a command is labeled under the category of “same”901.

If the identified command is labeled with the designation of “same,” then, in step1204, generator engine206of porting mechanism106writes the line of script from the parsed incoming script with the identified command in the output script for target platform102.

If, however, the identified command is not identified as being labeled with the designation of “same,” then such an identified command is identified as being either “mismatch” or “missing.” As a result, if the identified command is not identified as being labeled with the designation of “same,” then, in step1205, generator engine206of porting mechanism106determines whether there are any alternative commands for the commands of source platform101that are labeled as “mismatch” or “missing.”

As discussed above, labeling engine205labels various commands with the designations of “same,” “mismatch,” or “missing.” In one embodiment, generator engine206accesses a data structure (e.g., table) with information as shown inFIG.9that was populated by labeling engine205. Upon locating the command identified in step1202in such a data structure, generator engine206determines if such a command is labeled under the category of “mismatch”902or “missing”903. Upon identifying the command labeled as “mismatch”902or “missing”903, generator engine206determines if such a command has an alternative command that was identified by comparison module204, where such information (e.g., information such as shown by arrows907,909inFIG.9) was stored in a data structure (e.g., table) populated by labeling engine205. As a result, generator engine206performs a look-up of such a data structure to identify any alternative command for the command identified in step1202. In one embodiment, such a data structure resides within the storage device (e.g., storage device1011,1015) of porting mechanism106.

If there is not an alternative command for the command identified in step1202, then, in step1206, generator engine206of porting mechanism106inserts a warning message in the output script for target platform102that the command is labeled as mismatch or missing but with no generated alternative commend.

If, however, there is an alternative command, then, in step1207, generator engine206of porting mechanism106replaces the command from the line of script in the parsed incoming script with the generated alternative command (generated in step1107ofFIG.11) and writes the line of script from the incoming script with the replaced command in the output script for target platform102. For example, the command of stat -c601in the incoming script of source platform101is replaced with the alternative command of ls -l603as shown inFIG.9, where the line of script from the parsed incoming script with such a replacement is then written to the output script for target platform102.

As discussed above, generator engine206utilizes various software tools for writing lines of code in the output script, inserting warning messages in the output script, replacing commands in the incoming script with alternative commands to be written to the output script, etc., which can include, but are not limited to, UltraEdit®, Xcode®, CodeLite, Emacs®, Vim®, etc.

Upon writing the line of script with the identified command in the output script for target platform102or upon inserting the warning message in the output script for target platform102or upon replacing the command in the incoming script with the generated alternative command and writing the line of script from the incoming script with the replaced command in the output script, in step1208, parser207of porting mechanism106determines if there are more lines in the incoming script to be parsed.

If there are no more lines in the incoming script to be parsed, then, in step1209, generator engine206of porting mechanism106issues the output script to target platform106to be executed on target platform106.

If, however, there are more lines in the incoming script to be parsed, then parser207of porting mechanism106parses the next line in the incoming script for source platform101in step1201.

In this manner, scripts from a source platform with commands that are not supported by the target platform may now be adapted in a manner that enables such scripts to be executed on the target platform.

Furthermore, the principles of the present disclosure improve the technology or technical field involving porting.

As discussed above, when porting software, such as open-source tools, across different operating systems (e.g., Linux®, iOS®, Unix®, etc.) and/or hardware platforms (e.g., x86, Arm®, etc.), many scripts from a source platform need to be modified in order to be executed successfully on a target platform. A script refers to a program or sequence of instructions that is interpreted or carried out by another program rather than by the computer processor. A platform refers to the hardware and software (operation system) on which software applications can be run. A source platform refers to the platform upon which the scripts were originally designed for execution. A target platform refers to the platform upon which the scripts are desired to be executed. For example, the script for a BATS (Bash Automated Testing System) framework in a source platform, such as the Linux® platform, may not be supported by the target platform (e.g., z/OS®). For instance, the commands of the script for the BATS framework may be not supported by the target platform. If the target platform does not report errors or warnings regarding unsupported commands, then the user will have no knowledge of such unsupported commands. As a result, the user may spend enormous time in attempting to identify the reasons for the script not executing on the target platform as well as spend enormous time in modifying the script in order to be properly executed on the target platform. Unfortunately, there is not currently a means for informing the user regarding unsupported commands. Neither is there a means for automatically modifying the scripts from the source platform in order to be correctly executed on the target platform.

Embodiments of the present disclosure improve such technology by analyzing traces of system calls from the commands in the source and target platforms to identify building blocks. A “system call,” as used herein, is the programmatic way in which a computer program requests a service from the operating system on which it is executed. A “system call trace,” as used herein, refers to the specialized use of logging to record information about the system call. A “building block,” as used herein, refers to a portion of the script that contains functionality for performing task-based operations. A tree structure for each command of the source and target platforms is constructed with one or more building blocks from the identified building blocks. In one embodiment, such tree structures are constructed by analyzing the commands' system call traces. Commands of the target platform with a functionality within a threshold degree of similarity, which may be user-designated, to the commands of the source platform are identified by analyzing the building blocks of the commands' tree structures. In one embodiment, such similarity between the commands of the source and target platforms are determined by vectorizing the building blocks of the commands, including the actions, parameters, inputs, functions, etc. of the building blocks. After being converted into real-valued vectors, a similarity measure, such as cosine similarity or the Euclidean distance, may be used to determine the similarity between the commands of the source and target platforms. Alternative commands for the commands of the source platform, such as those commands that are not supported by the target platform, may then be generated using such identified commands. The script from the source platform may then be adapted to be utilized in the target platform using such generated alternative commands. For example, the script from the source platform may be adapted by replacing commands in the script that are not supported by the target platform with alternative commands that are supported by the target platform. For instance, a command from the script of the source platform that is mismatched (command used in the source platform with an appearance to a command used in the target platform but with a different functionality) or missing (command used in the source platform with the same functionality as a command from the target platform but with a different appearance) may be replaced with such a generated alternative command thereby enabling the script of the source platform to be adapted to be executed on the target platform. In this manner, scripts from a source platform with commands that are not supported by the target platform may now be adapted in a manner that enables such scripts to be executed on the target platform. Furthermore, in this manner, there is an improvement in the technical field involving porting.

The technical solution provided by the present disclosure cannot be performed in the human mind or by a human using a pen and paper. That is, the technical solution provided by the present disclosure could not be accomplished in the human mind or by a human using a pen and paper in any reasonable amount of time and with any reasonable expectation of accuracy without the use of a computer.