Method and apparatus for production processing of TWS migration version

Abstract

The application provides a TWS migration version production processing method and device, relates to the technical field of data processing, and comprises the following steps: obtaining a migration version scheduling file of TWS, checking the migration version scheduling file according to a preset condition, and publishing the migration version scheduling file after the checking; analyzing the migration version scheduling file to obtain script parameter information; reading a migration version script template of TWS, generating a TWS migration version script according to the script parameter information and the migration version script template; obtaining a script effective time point, a script data list and a directory where a job entity is located according to the TWS migration version script, and auditing the TWS migration version script; loading resources of the TWS migration version according to the TWS migration version script after the auditing; and triggering an automatic cleaning mechanism to clean the resources of the TWS migration version when the resources of the TWS migration version are used up.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more particularly to a production processing method and apparatus for a TWS mobile version. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] Large commercial banks manage and maintain TWS (Tivoli Workload Scheduler) based on IBM mainframes in batches. To ensure business stability and diversity, monthly version releases and deployments are routinely scheduled. Additionally, due to business needs, earlier or later versions are released as needed. For TWS versions, releases and deployments are divided into core batch versions and migration batch versions. Core batch versions generate and execute daily plans based on runtime cycles and ETT (Event-triggered Tracking) loading methods, with version content reused according to settings. Migration batch versions are primarily for production deployment, and their content is used only once during production deployment.

[0004] In existing application scenarios, the core batch version deployment is typically scheduled for Sunday morning. The current solution uses a single TWS set shared by the core batch version and the migration batch version. Overseas, there are four TWS sets based on time zones. The migration batch TWS content is deployed on the evening of T-2, relying on the daily plan generation time on T-1 to load the migration batch version content into the T-1 daily plan. Before generating the daily plan in each environment on T, the TWS process is cleared, and the core batch TWS version is deployed, ensuring that the daily plan generated on T no longer includes the migration batch TWS version content. Simultaneously, after the version deployment is completed, each TWS set needs to check the T-1 day plan and manually remove any unexecuted content.

[0005] Using existing technology for TWS version deployment, overseas core batches generate batch plans daily on a scheduled basis. Since these plans share the same TWS as the core batches, the migration version can only run after the daily batch plan is generated. If an emergency patch is needed, it cannot be deployed immediately, impacting deployment efficiency. Furthermore, the migration batches are only used for production deployment, and any remaining content in the TWS can be accidentally triggered; therefore, timely cleanup of migration content is necessary. The cleanup process presents the following risks: because the migration and core share the same TWS, cleaning up the migration content requires cleaning up the core content before reloading it, which carries the risk of core batch ETT loading failure; the core and migration TWS processes are intertwined, and there is a risk of accidental operation during the cleanup and reloading of core content.

[0006] In summary, existing technologies suffer from drawbacks such as low efficiency and the risk of accidental triggering in batch migration, necessitating a technical solution that can overcome these shortcomings. Summary of the Invention

[0007] To address the problems existing in the prior art, this invention proposes a production processing method and apparatus for TWS migration versions. The method involves checking the migration TWS release, parsing the migration version scheduling file, generating a TWS migration version script, and deploying the TWS migration version resources after the script is approved. Effective cleanup is also performed after resource use, ensuring the safe and stable production and use of migration versions under the new scheme, improving the accuracy and efficiency of TWS migration version deployment, and reducing production risks.

[0008] In a first aspect of the present invention, a production processing method for a TWS migration version is proposed, comprising:

[0009] Obtain the migration version schedule file for TWS, check the migration version schedule file according to preset conditions, and publish the migration version schedule file after the check passes;

[0010] Parse the migration version scheduling file to obtain script parameter information;

[0011] Read the TWS migration version script template, and generate the TWS migration version script based on the script parameter information and the migration version script template;

[0012] Based on the TWS migration version script, obtain the script's effective time, script data list, and the directory where the work entities are located, and review the TWS migration version script;

[0013] After approval, the resources of the TWS migration version are loaded according to the TWS migration version script;

[0014] When the resources of the TWS migration version are used up, an automatic cleanup mechanism is triggered to clean up the resources of the TWS migration version.

[0015] In a second aspect of the present invention, a production processing apparatus for a TWS migration version is provided, comprising:

[0016] The inspection module is used to obtain the migration version schedule file of TWS, inspect the migration version schedule file according to preset conditions, and publish the migration version schedule file after the inspection is passed.

[0017] The parsing module is used to parse the migration version scheduling file to obtain script parameter information;

[0018] The generation module is used to read the TWS migration version script template and generate the TWS migration version script based on the script parameter information and the migration version script template.

[0019] The review module is used to review the TWS migration version script by obtaining the script's effective time, script data list, and the directory where the job entities are located.

[0020] The loading module is used to load the resources of the TWS migration version according to the TWS migration version script after the review is approved;

[0021] The cleanup module is used to trigger an automatic cleanup mechanism to clean up the resources of the TWS mobile version when the resources of the TWS mobile version are exhausted.

[0022] In a third aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a production processing method for a TWS mobile version.

[0023] In a fourth aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements a production processing method for a TWS mobile version.

[0024] In a fifth aspect of the present invention, a computer program product is provided, the computer program product including a computer program, which, when executed by a processor, implements a production processing method for a TWS mobile version.

[0025] The TWS migration version deployment processing method and apparatus proposed in this invention obtains the TWS migration version scheduling file, checks the migration version scheduling file according to preset conditions, and publishes the migration version scheduling file after passing the check; parses the migration version scheduling file to obtain script parameter information; reads the TWS migration version script template, and generates the TWS migration version script according to the script parameter information and the migration version script template; obtains the script effective time point, script data list, and the directory where the work entity is located according to the TWS migration version script, and reviews the TWS migration version script; after the review is passed, loads the TWS migration version resources according to the TWS migration version script; when the TWS migration version resources are used up, an automatic cleanup mechanism is triggered to clean up the TWS migration version resources. The overall solution can realize the entire process of TWS migration version release, generation, deployment, and cleanup, with flexible version deployment methods, reducing deployment risks, effectively improving resource utilization, and providing strong technical support for TWS management and maintenance. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the production processing method for a TWS mobile version according to an embodiment of the present invention.

[0028] Figure 2 This is a flowchart illustrating the process of checking the migration version schedule according to a specific embodiment of the present invention.

[0029] Figure 3 This is a flowchart illustrating the process of generating a migration version script according to a specific embodiment of the present invention.

[0030] Figure 4 This is a flowchart illustrating the process of reviewing the TWS migration version script according to a specific embodiment of the present invention.

[0031] Figure 5 This is a schematic diagram of the automated production process according to a specific embodiment of the present invention.

[0032] Figure 6 This is a schematic diagram of an automatic cleaning process according to an embodiment of the present invention.

[0033] Figure 7 This is a schematic diagram of the production processing device architecture for a TWS mobile version according to an embodiment of the present invention.

[0034] Figure 8 This is a schematic diagram of a computer device structure according to an embodiment of the present invention. Detailed Implementation

[0035] The principles and spirit of the invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement the invention, and are not intended to limit the scope of the invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0036] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0037] According to an embodiment of the present invention, a production processing method and apparatus for TWS mobile versions are proposed, relating to the field of data processing technology.

[0038] In the embodiments of the present invention, the following terms need to be explained:

[0039] 1. TWS: Tivoli Workload Scheduler is an enterprise workload management program used for unified planning, management, control, and automatic scheduling of batch jobs on the host machine. It also allows for manual intervention in batch planning. In this invention, it mainly refers to the Z / OS version, i.e., the host-side version.

[0040] 2. TWS Version: Large commercial banks regularly release batch scheduling versions to meet business needs or ensure stable production. These versions are divided into core batch versions and migration batch versions.

[0041] 3. SR: Special Resource (hereinafter referred to as SR). This is similar to a switch. For example, the end-of-day batch job start is triggered by an SR, and all subsequent batch jobs run in the set order. Typically, an SR represents a specific resource within the system. These resources are required by certain jobs during the batch job execution process. During a certain period, these resources are unavailable, preventing batch jobs from running and requiring a wait. Once the special resource becomes available, its status is set to available, and subsequent batch jobs that depend on this resource can begin running.

[0042] 4. ETT: Event-triggered tracking. This type of process does not have a runcycle (running rules) in TWS and is commonly used for features that submit data at irregular intervals. It adds an Activity Generated from the current Plan (AD) to run, and can also set its predecessor / follower relationships within the original Plan. ETT is generally triggered using SR (Signal Response), so ADs triggered by ETT all have SR.

[0043] 5. AD: Application Descriptions, also known as job groups, are collections of jobs with the same attributes. In a large batch workflow, many jobs may perform similar functions, completing only one business task, and their execution cycles are the same. Therefore, it is unnecessary to define the execution cycle for each job. An AD can be defined to put jobs that perform similar functions and have the same execution cycle into this AD. Only one execution rule needs to be defined for this AD, so all jobs belonging to this AD will have the same execution rule. An AD can contain a maximum of 256 jobs, which cannot exceed the total number of jobs.

[0044] In TWS, the smallest unit of execution rules is AD, not job. If each job must have different execution rules, then each job must belong to one AD.

[0045] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0046] Figure 1 This is a schematic flowchart of a production processing method for a TWS mobile version according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0047] S101, Obtain the migration version scheduling file of TWS, check the migration version scheduling file according to preset conditions, and publish the migration version scheduling file after the check passes;

[0048] S102, parse the migration version scheduling file to obtain script parameter information;

[0049] S103, Read the TWS migration version script template, and generate the TWS migration version script according to the script parameter information and the migration version script template;

[0050] S104. Based on the TWS migration version script, obtain the script effective time point, script data list and the directory where the work entity is located, and review the TWS migration version script;

[0051] S105, After the review is approved, load the resources of the TWS migration version according to the TWS migration version script;

[0052] S106, when the resources of the TWS mobile version are used up, an automatic cleanup mechanism is triggered to clean up the resources of the TWS mobile version.

[0053] The TWS migration version production processing method proposed in this invention checks the migration TWS release, parses the migration version scheduling file, generates a TWS migration version script, puts the TWS migration version resources into production after the script is approved, and effectively cleans up the resources after use. This ensures the safe and stable production and use of the migration version under the new scheme, improves the accuracy and efficiency of TWS migration version production, and reduces production risks.

[0054] To provide a clearer explanation of the above-mentioned production processing method for the TWS migration version, each step will be explained in detail below.

[0055] In step S101, the migration version scheduling file for TWS is obtained, and the migration version scheduling file is checked according to preset conditions. After the check passes, the migration version scheduling file is published. The specific process is as follows:

[0056] Read the contents of the migration version scheduling file to obtain the job group name, job name, and partition identifier;

[0057] If, after inspection, it is determined that there are no duplicate work group names, no duplicate work names, and that the distribution identifier matches the currently selected partition, the migration version scheduling file is published.

[0058] In practical applications, considering that TWS migration versions are only used once during production deployment, this invention merges four overseas TWS migration versions into a single TWS environment to conserve production resources. Based on this scenario, it is necessary to ensure that the names of different entity jobs are different in each overseas environment and that there are no pre- or post-job dependencies between different overseas environments. Therefore, preset conditions (i.e., mandatory specifications) are established in the migration version scheduling, requiring all release content to meet the following conditions:

[0059] Overseas migration is divided into 4 partitions, each with a unique batch number, and the batch numbers within each partition are independent and do not overlap. The migration version schedule provides the option to select the overseas partition. For migration AD (job catalog) and jobs that are not divided into batches, TWS scheduling only allows one partition to be selected.

[0060] For non-batch migration operations, the last character of the fixed operation name is the zone identifier. For example, O, E, A, and X represent Asia Pacific, Europe and Africa, Americas, and major banks, respectively.

[0061] In one specific embodiment, based on the above-mentioned preset conditions, the present invention performs a standardization check on the migration version schedule. The main process includes: reading the migration version schedule file, checking the file format and permissions, reading the file content and parsing the schedule content line by line, obtaining the partition parameter value after determining that the AD name and job name are not duplicated, and checking whether the last partition identifier of the job name is consistent with the selected partition.

[0062] refer to Figure 2 This is a flowchart illustrating the process of checking the migration version schedule according to a specific embodiment of the present invention. Figure 2 As shown, the specific process is as follows:

[0063] S201, retrieve the TWS scheduler file name and address.

[0064] S202: Has the migration version scheduling file been obtained? If not, report that the file does not exist; if obtained, proceed to S203.

[0065] S203, Read file.

[0066] S204, check file permissions and format; if file permissions are insufficient or the format is incorrect, the check fails and the process ends; if the file has the necessary permissions and the format is correct, execute S204.

[0067] S205 parses the file content to obtain parameter values ​​such as AD, job name, and partition.

[0068] S206, determine whether AD contains an expansion character; if not, execute S207; if it does, execute S208.

[0069] S207, check if AD has a duplicate name; if so, indicate that AD has a duplicate name and end the current process; if not, execute S208.

[0070] S208, determine if the job name contains an expansion character; if yes, execute S209; otherwise, execute S210.

[0071] S209, check if there are duplicate job names; if so, prompt that there are duplicate job names and end the current process; if not, execute S210.

[0072] S210, parse and obtain the last character of the job name.

[0073] S211, determine if the last character of the job name matches the environment; if not, prompt that the last character of the job name does not match the environment and end the current process; if they match, execute S212.

[0074] S212, The migration version scheduling file has passed the check. The migration version scheduling file has been published, and the current process is now complete.

[0075] In S102, the migration version scheduling file is parsed to obtain script parameter information.

[0076] The script parameter information includes at least: job group name, job group attributes, job name, constraint relationship and partition identifier.

[0077] In S103, the TWS migration version script template is read, and the TWS migration version script is generated based on the script parameter information and the migration version script template. The specific process is as follows:

[0078] Import the job group name, job group attributes, job name, constraint relationship and partition identifier into the TWS migration version script template to generate a job entity; wherein, if the job group name and job name contain batch extension symbols, the job group name and job name are automatically extended according to the partition identifier;

[0079] Deploy the job entities according to the partitions in the corresponding directories of each partition.

[0080] In one specific embodiment, after setting the TWS running cycle and necessary TWS parameters, the TWS script template is read; according to the approved migration version scheduling file, each line is parsed to obtain information such as AD name, AD attributes (running cycle or control conditions such as ETT, SR, etc.), job name, constraint relationship (timing, predecessor and predecessor constraints, etc.), and partition. If the AD name or job name contains the batch extension symbol $, it is automatically extended according to the partition batch number to finally form the TWS script.

[0081] Meanwhile, when obtaining or expanding the job name, the corresponding job template is read synchronously, the job entity is automatically generated, and it is deployed in different directories according to different partitions.

[0082] refer to Figure 3 This is a schematic diagram illustrating the process of generating a transition version script according to a specific embodiment of the present invention. Figure 3 As shown, the specific process is as follows:

[0083] S301, enter the effective time and TWS environment parameters.

[0084] S302, reads and parses to obtain the TWS version script template.

[0085] S303 reads the TWS scheduling file and reads the records.

[0086] S304, parse the record and obtain parameter information.

[0087] S305, determine whether AD contains an extension character; if it does, execute S306; if it does not, execute S307.

[0088] S306: Obtain the partition number of the partition based on the partition and automatically extend the AD name.

[0089] S307, determine if the job name contains an extension character; if it does, proceed to S308; if it does not, proceed to S309.

[0090] S308: Obtain the partition number of the partition based on the partition and automatically extend the job name.

[0091] S309, Read the job template; if reading fails, prompt that the job template is abnormal; if reading is successful, execute S310.

[0092] S310, Generate job entity.

[0093] S311, import the job group name, job group attributes, job name, constraint relationship and partition identifier into the TWS migration version script template to generate the TWS migration version script.

[0094] In S104, based on the TWS migration version script, the script's effective time, script data list, and the directory where the job entities are located are obtained. The TWS migration version script is then reviewed. The specific process is as follows:

[0095] Compare the script activation time of the TWS migration version script with the preset activation time;

[0096] Compare the script data list with the test center script list; wherein the script data list includes at least: job group list, job list, control list and total number of script lines;

[0097] Check the job names in the job entity directory;

[0098] The TWS migration version script is approved when the script's effective time coincides with the preset effective time, the script data list matches the list of scripts in the test center, and there are no duplicate job names in the job entity directory.

[0099] In one specific embodiment, this step mainly involves automatically checking and reviewing the generated TWS migration version scripts and job entities before production deployment. This avoids production incidents caused by inconsistencies in the effective time parameters in the scripts, duplicate job names, or duplicate job entities, which could lead to abnormal TWS migration version installation or activation, or by job miscalls during execution.

[0100] The main processes in this step include: reading and parsing the produced TWS migration version script, obtaining the effective time point parameters and comparing them to confirm that the effective time points are consistent; obtaining the AD list, job list, SR list, and ETT list through script parsing, while counting the total number of lines in the script, comparing the obtained results with the list and statistical results of the test center script to ensure consistency with the content handed over to the test center; parsing and obtaining the directory where the job entity is located, and checking to confirm that there are no jobs with duplicate names in the directory.

[0101] For details, please refer to Figure 4 This is a flowchart illustrating the process of reviewing the TWS migration version script according to a specific embodiment of the present invention. Figure 4 As shown, the specific process is as follows:

[0102] S401, reads the TWS migration version script.

[0103] S402, parse and obtain the effective time.

[0104] S403, determine whether the effective time is consistent with the preset effective time; if yes, execute S404; if no, indicate that the effective time is inconsistent and end this process.

[0105] For example, the default effective time is 9:00 for domestic and major banking environments; 12:00 for Europe and Africa; and 6:00 for Asia Pacific.

[0106] S404, parse and obtain the AD list and job list.

[0107] S405, determine whether the parsed data is consistent with the handover list; if yes, proceed to S406; if no, indicate that the resource list is inconsistent and output the verification result, and end this process.

[0108] S406, Statistics on resource quantity and script length.

[0109] S407: Determine if the statistical data matches the number of resources being handed over; if yes, proceed to S408; if no, indicate that the number of resources is inconsistent and end the current process.

[0110] S408, parse the job directory and obtain the job name information for each directory.

[0111] S409 checks if the filename is unique; if so, the approval is granted; otherwise, a message indicating that the filename is not unique is displayed and a list of abnormal filenames is output, ending the current process.

[0112] In step S105, after approval, the resources of the TWS migration version are loaded according to the TWS migration version script. The specific process is as follows:

[0113] When the set time period is reached, stop TWS and back up the TWS in the current queue;

[0114] After the backup is complete, clear the TWS in the current queue and load the TWS migration version script one by one;

[0115] During the script loading process, the number of TWS resources is checked in real time. If the number of resources matches the preset number of resources, the current resources are backed up and the resources of the TWS migration version are loaded into the current queue.

[0116] Start TWS and monitor its running status.

[0117] In one specific embodiment, this step can realize automated production deployment, inspection functions, and automatic cleanup functions after the TWS migration version is completed.

[0118] This step uses the TWS process to automate the deployment of the migration version. The main processes include: during the change period, by turning on the SR switch, the ETT loading automated deployment process is triggered; after turning on the first job control SR switch, the prepared version installation job is automatically called and executed automatically according to the dependencies, including original resource backup, TWS resource clearing, automatic loading of the migration version, counting and verifying the number of resources, new resource backup, and automatic generation of the new version to be effective.

[0119] For details, please refer to Figure 5 This is a schematic diagram of an automated production process according to a specific embodiment of the present invention. Figure 5 As shown, the specific process is as follows:

[0120] S501, turn on SR.

[0121] S502, turn off the TWS switch.

[0122] S503, back up the original TWS process.

[0123] S504, clear TWS process.

[0124] S505 automatically loads the TWS migration process one by one.

[0125] S506, check and obtain the real-time resource count of TWS.

[0126] S507: Compare the resource counts to see if they match. If yes, proceed to S508. If no, the resource counts do not match, end the current process.

[0127] Specifically, after a script in a certain environment is installed, it is necessary to verify whether the number of resources matches the preset number. According to the test handover, each environment's script resource count will have a preset value, such as AD count, SR count, etc., which is recorded in the script configuration file. In actual application scenarios, after an environment is installed, the final number of each resource after loading is obtained and compared with the preset value. If they match completely, it means that the resource count meets expectations, and the next step can be continued; otherwise, a message indicating that the resource count is inconsistent is displayed.

[0128] S508, back up new resources.

[0129] S509 automatically generates a new plan transition version.

[0130] S510, turn on the TWS switch.

[0131] S511, check if the TWS status is normal; if yes, the status is normal; if no, the TWS status is abnormal, end this process.

[0132] In S106, when the resources of the TWS mobile version are used up, an automatic cleanup mechanism is triggered to clean up the resources of the TWS mobile version. The specific process is as follows:

[0133] When the resources of the TWS migration version are used up, stop TWS, query the unfinished jobs in the TWS daily plan, and change the status of the unfinished jobs to completed.

[0134] Clean up the resources of the TWS migration version in the job queue and export the list of successful cleanup.

[0135] Start TWS and monitor its running status.

[0136] In one specific embodiment, after the version has been put into production and used, the SR switch is turned on to trigger the automatic cleanup mechanism, which includes steps such as turning off the TWS switch, obtaining jobs and ADs in non-complete state and automatically setting them to complete state, deleting the TWS migration version content in the base library, and turning on the TWS switch.

[0137] For details, please refer to Figure 6 This is a schematic diagram of an automatic cleaning process according to an embodiment of the present invention. Figure 6 As shown, the specific process is as follows:

[0138] S601, open SR.

[0139] S602, turn off the TWS switch.

[0140] S603 allows for real-time querying and retrieval of unfinished tasks in the daily TWS plan.

[0141] S604, check if there are any incomplete ADs; if yes, proceed to S605; if no, proceed to S606.

[0142] S605, Automation sets AD to complete.

[0143] S606 automatically cleans up the TWS migration version content in the base library.

[0144] S607 allows for real-time querying and retrieval of the resource list in the base database.

[0145] S608, check if the cleanup is complete; if yes, execute S609; if no, the cleanup failed and a list of unsuccessful cleanup attempts is output.

[0146] S609, turn on the TWS switch and check the TWS status.

[0147] S610: Determine if the status is normal; if yes, end the current process; if no, issue a TWS status abnormality prompt.

[0148] The TWS migration version production processing of this invention separates the migration and version integration production content of the four overseas regions from the core TWS and integrates them into a TWS environment. Furthermore, it adopts new overseas migration TWS release rules, new overseas migration TWS version checking and cleaning tools, and adjusts MV tool parameters and TWS system configuration to ensure the safe and stable production and use of migration versions under the new solution.

[0149] Compared with the prior art, the present invention has at least the following advantages:

[0150] 1. Flexible Version Deployment. After the overseas migration of TWS was separated, the generation of migration batch plans is no longer constrained by the generation time of the core batch plan, enabling batch plans to take effect immediately. For migration versions, batch plans can be flexibly generated and implemented for production based on application needs. This not only significantly shortens the overall time from installation to production for planned versions, but also enables rapid deployment of emergency patches as soon as they are available, improving the efficiency of version production.

[0151] 2. Reduce production risks. The separation of overseas-migrated TWS and core TWS allows for independent production deployment of the overseas-migrated TWS and core versions, preventing modifications and cleanups of the overseas version from affecting the core batch production and improving the security of version deployment.

[0152] 3. Effective utilization of resources. The utilization rate of production-dedicated TWS is low, while the TWS migration version reuses existing TWS, effectively improving the utilization rate of production TWS.

[0153] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0154] After introducing the method of exemplary embodiments of the present invention, the following references are made. Figure 7 The production processing apparatus for a TWS mobile version according to an exemplary embodiment of the present invention will be described.

[0155] The implementation of the TWS mobile version production processing device can refer to the implementation of the above method, and the repeated parts will not be described again. The term "module" or "unit" used below can be a combination of software and / or hardware to implement a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0156] Based on the same inventive concept, this invention also proposes a production processing device for a TWS migration version, such as... Figure 7 As shown, the device includes:

[0157] The inspection module 710 is used to obtain the migration version schedule file of TWS, inspect the migration version schedule file according to preset conditions, and publish the migration version schedule file after the inspection is passed.

[0158] Parsing module 720 is used to parse the migration version scheduling file to obtain script parameter information;

[0159] The generation module 730 is used to read the TWS migration version script template and generate the TWS migration version script according to the script parameter information and the migration version script template.

[0160] The review module 740 is used to review the TWS migration version script by obtaining the script's effective time, script data list, and the directory where the job entities are located.

[0161] The loading module 750 is used to load the resources of the TWS migration version according to the TWS migration version script after the review is approved;

[0162] The cleaning module 760 is used to trigger an automatic cleaning mechanism to clean up the resources of the TWS mobile version when the resources of the TWS mobile version are exhausted.

[0163] In one embodiment, the inspection module 710 is specifically used for:

[0164] Read the contents of the migration version scheduling file to obtain the job group name, job name, and partition identifier;

[0165] If, after inspection, it is determined that there are no duplicate work group names, no duplicate work names, and that the distribution identifier matches the currently selected partition, the migration version scheduling file is published.

[0166] In one embodiment, the script parameter information obtained by the parsing module 720 includes at least: job group name, job group attribute, job name, constraint relationship and partition identifier.

[0167] In one embodiment, the generation module 730 is specifically used for:

[0168] Import the job group name, job group attributes, job name, constraint relationship and partition identifier into the TWS migration version script template to generate a job entity; wherein, if the job group name and job name contain batch extension symbols, the job group name and job name are automatically extended according to the partition identifier;

[0169] Deploy the job entities according to the partitions in the corresponding directories of each partition.

[0170] In one embodiment, the audit module 740 is specifically used for:

[0171] Compare the script activation time of the TWS migration version script with the preset activation time;

[0172] Compare the script data list with the test center script list; wherein the script data list includes at least: job group list, job list, control list and total number of script lines;

[0173] Check the job names in the job entity directory;

[0174] The TWS migration version script is approved when the script's effective time coincides with the preset effective time, the script data list matches the list of scripts in the test center, and there are no duplicate job names in the job entity directory.

[0175] In one embodiment, the loading module 750 is specifically used for:

[0176] When the set time period is reached, stop TWS and back up the TWS in the current queue;

[0177] After the backup is complete, clear the TWS in the current queue and load the TWS migration version script one by one;

[0178] During the script loading process, the number of TWS resources is checked in real time. If the number of resources matches the preset number of resources, the current resources are backed up and the resources of the TWS migration version are loaded into the current queue.

[0179] Start TWS and monitor its running status.

[0180] In one embodiment, the cleaning module 760 is specifically used for:

[0181] When the resources of the TWS migration version are used up, stop TWS, query the unfinished jobs in the TWS daily plan, and change the status of the unfinished jobs to completed.

[0182] Clean up the resources of the TWS migration version in the job queue and export the list of successful cleanup.

[0183] Start TWS and monitor its running status.

[0184] It should be noted that although several modules of the TWS mobile version production processing device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided and embodied by multiple modules.

[0185] Based on the aforementioned inventive concept, such as Figure 8As shown, the present invention also proposes a computer device 800, including a memory 810, a processor 820, and a computer program 830 stored in the memory 810 and executable on the processor 820. When the processor 820 executes the computer program 830, it implements the aforementioned TWS mobile version production processing method.

[0186] Based on the aforementioned inventive concept, the present invention proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned production processing method for the TWS mobile version.

[0187] Based on the aforementioned inventive concept, this invention proposes a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements a production processing method for a TWS mobile version.

[0188] The TWS migration version deployment processing method and apparatus proposed in this invention obtains the TWS migration version scheduling file, checks the migration version scheduling file according to preset conditions, and publishes the migration version scheduling file after passing the check; parses the migration version scheduling file to obtain script parameter information; reads the TWS migration version script template, and generates the TWS migration version script according to the script parameter information and the migration version script template; obtains the script effective time point, script data list, and the directory where the work entity is located according to the TWS migration version script, and reviews the TWS migration version script; after the review is passed, loads the TWS migration version resources according to the TWS migration version script; when the TWS migration version resources are used up, an automatic cleanup mechanism is triggered to clean up the TWS migration version resources. The overall solution can realize the entire process of TWS migration version release, generation, deployment, and cleanup, with flexible version deployment methods, reducing deployment risks, effectively improving resource utilization, and providing strong technical support for TWS management and maintenance.

[0189] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0190] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0191] This invention is described with reference to flowchart illustrations and / or block diagrams of methods and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0192] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0193] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0194] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for production processing of a TWS mobile version, characterized in that, include: Obtain the migration version schedule file for TWS, check the migration version schedule file according to preset conditions, and publish the migration version schedule file after the check passes; The migration version scheduling file is parsed to obtain script parameter information; wherein, the script parameter information includes at least the job group name, job group attributes, job name, constraint relationship and partition identifier; Read the TWS migration version script template, and generate the TWS migration version script based on the script parameter information and the migration version script template; Based on the TWS migration version script, obtain the script's effective time, script data list, and the directory where the work entities are located, and review the TWS migration version script; After approval, the resources of the TWS migration version are loaded according to the TWS migration version script; When the resources of the TWS mobile version are used up, an automatic cleanup mechanism is triggered to clean up the resources of the TWS mobile version; The step of reading the TWS migration version script template and generating a TWS migration version script based on the script parameter information and the migration version script template includes: Import the job group name, job group attributes, job name, constraint relationship and partition identifier into the TWS migration version script template to generate a job entity; wherein, if the job group name and job name contain batch extension symbols, the job group name and job name are automatically extended according to the partition identifier; Deploy the job entities according to the partitions in the corresponding directories of each partition.

2. The method according to claim 1, characterized in that, Obtain the TWS migration version schedule file, check the migration version schedule file according to preset conditions, and release the migration version schedule file after the check passes, including: Read the contents of the migration version scheduling file to obtain the job group name, job name, and partition identifier; If, after inspection, it is determined that there are no duplicate work group names, no duplicate work names, and that the distribution identifier matches the currently selected partition, the migration version scheduling file is published.

3. The method according to claim 1, characterized in that, Based on the TWS migration version script, obtain the script's effective time, script data list, and the directory where the job entities are located. Review the TWS migration version script, including: Compare the script activation time of the TWS migration version script with the preset activation time; Compare the script data list with the test center script list; wherein the script data list includes at least: job group list, job list, control list and total number of script lines; Check the job names in the job entity directory; The TWS migration version script is approved when the script's effective time coincides with the preset effective time, the script data list matches the list of scripts in the test center, and there are no duplicate job names in the job entity directory.

4. The method according to claim 1, characterized in that, After approval, the resources of the TWS migration version are loaded according to the TWS migration version script, including: When the set time period is reached, stop TWS and back up the TWS in the current queue; After the backup is complete, clear the TWS in the current queue and load the TWS migration version script one by one; During the script loading process, the number of TWS resources is checked in real time. If the number of resources matches the preset number of resources, the current resources are backed up and the resources of the TWS migration version are loaded into the current queue. Start TWS and monitor its running status.

5. The method according to claim 1, characterized in that, When the resources of the TWS migration version are exhausted, an automatic cleanup mechanism is triggered to clean up the resources of the TWS migration version, including: When the resources of the TWS migration version are used up, stop TWS, query the unfinished jobs in the TWS daily plan, and change the status of the unfinished jobs to completed. Clean up the resources of the TWS migration version in the job queue and export the list of successful cleanup. Start TWS and monitor its running status.

6. A production processing device for a TWS (True Wireless Stereo) portability version, characterized in that, include: The inspection module is used to obtain the migration version schedule file of TWS, inspect the migration version schedule file according to preset conditions, and publish the migration version schedule file after the inspection is passed. The parsing module is used to parse the migration version scheduling file to obtain script parameter information; wherein, the script parameter information includes at least the job group name, job group attributes, job name, constraint relationship and partition identifier; The generation module is used to read the TWS migration version script template and generate the TWS migration version script based on the script parameter information and the migration version script template. The review module is used to review the TWS migration version script by obtaining the script's effective time, script data list, and the directory where the job entities are located. The loading module is used to load the resources of the TWS migration version according to the TWS migration version script after the review is approved; The cleanup module is used to trigger an automatic cleanup mechanism to clean up the resources of the TWS mobile version when the resources of the TWS mobile version are exhausted. Specifically, the generation module is used for: Import the job group name, job group attributes, job name, constraint relationship and partition identifier into the TWS migration version script template to generate a job entity; wherein, if the job group name and job name contain batch extension symbols, the job group name and job name are automatically extended according to the partition identifier; Deploy the job entities according to the partitions in the corresponding directories of each partition.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 5.

Images