Abstract:
Embodiments relate to policy-based, multi-scheme data reduction for a computer memory. An aspect includes receiving a plurality of policy rules by a policy engine of the computer memory, wherein a first policy rule specifies applying a first data reduction scheme to data in the computer memory based on the data matching first characteristics, wherein a second policy rule specifies applying a second data reduction scheme to data in the computer memory based on the data matching second characteristics, wherein the first data reduction scheme is different from the second data reduction scheme. Another aspect includes determining, by the policy engine, that first data in the computer memory matches the first characteristics, and that second data in the computer memory matches the second characteristics. Yet another aspect includes applying the first data reduction scheme to the first data, and applying the second data reduction scheme to the second data.

Description:
BACKGROUND 
       [0001]    The present invention relates generally to computer memory, and more specifically, to policy-based, multi-scheme data reduction for a computer memory. 
         [0002]    In order to store data efficiently in computer memory, data reduction techniques, such as compression and deduplication, are implemented in computer storage systems. Many different compression schemes and deduplication techniques are available. Data reduction may be applied within a storage device such that all data that is stored in the storage device is reduced using the same data reduction technique. However, it may be difficult to determine a particular data reduction technique to apply in a large file system or database that stores many different kinds of data, on different storage media or devices, for different purposes, applications, and users. Further, as data ages, its access pattern may change; thus the preferred data reduction technique for data may also change over time. 
       SUMMARY 
       [0003]    Embodiments include a method, system, and computer program product for policy-based, multi-scheme data reduction for a computer memory. An aspect includes receiving a plurality of policy rules by a policy engine of the computer memory, wherein a first policy rule of the plurality of policy rules specifies applying a first data reduction scheme to data in the computer memory based on the data matching first characteristics, wherein a second policy rule of the plurality of policy rules specifies applying a second data reduction scheme to data in the computer memory based on the data matching second characteristics, wherein the first data reduction scheme is different from the second data reduction scheme. Another aspect includes determining, by the policy engine, that first data in the computer memory matches the first characteristics, and that second data in the computer memory matches the second characteristics. Yet another aspect includes applying the first data reduction scheme to the first data, and applying the second data reduction scheme to the second data. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0004]    The subject matter which is regarded as embodiments is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The forgoing and other features, and advantages of the embodiments are apparent from the following detailed description taken in conjunction with the accompanying drawings in which: 
           [0005]      FIG. 1  depicts a computer system for policy-based, multi-scheme data reduction for a computer memory in accordance with an embodiment. 
           [0006]      FIG. 2A  depicts a metadata block including block location records for policy-based, multi-scheme data reduction for a computer memory in accordance with an embodiment. 
           [0007]      FIG. 2B  depicts a block group header for policy-based, multi-scheme data reduction for a computer memory in accordance with an embodiment. 
           [0008]      FIG. 3  depicts a process flow for application of policy-based, multi-scheme data reduction in accordance with an embodiment. 
           [0009]      FIG. 4  depicts a process flow for performing a read of reduced data in conjunction with policy-based, multi-scheme data reduction in accordance with an embodiment. 
           [0010]      FIG. 5  depicts a process flow for performing a write to reduced data in conjunction with policy-based, multi-scheme data reduction in accordance with an embodiment. 
           [0011]      FIG. 6  depicts an example of a computer that may be used in conjunction with policy-based, multi-scheme data reduction for a computer memory. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    Embodiments of policy-based, multi-scheme data reduction for a computer memory are provided, with exemplary embodiments being discussed below in detail. Because the data types and access patterns may vary within a single file system or storage device, it is possible that no single data reduction technique may be optimally applied to all of the data. Therefore, a variety of data reduction techniques, or schemes, may be applied within the file system. Different data reduction schemes may be applied at the file level, or to different parts of a single file. The data reduction may be applied based on policy rules that are set by, for example, an administrator. Files in the computer memory are divided up into fragments that are stored in block groups of storage blocks, and different data reduction schemes may be applied at the fragment level. Reduced data may be read and written based on a block group header and storage block location records that specify the data reduction scheme that is applied to a storage block that is being read or written. 
         [0013]    A file is stored in one or more storage blocks in the memory, and the storage blocks within each file are grouped into block groups. While a file may contain storage blocks in multiple block groups, each block group only belongs to a single file. A best-suited data reduction scheme may be selected for each file, or part of a file, in the computer memory, thereby increasing space savings. The data reduction scheme may be selected based on policy rules that specify a best data reduction scheme for particular data types or access patterns. A file size threshold may be set in some embodiments so that files that are smaller than the size threshold are not reduced. The policy rules may also specify when the data reduction is applied based on the load on the file system; for example, compression and deduplication may be performed during off-hours when the file system is at a relatively low load. 
         [0014]    In some embodiments, each storage block in a block group is divided into fixed-size fragments, and a space-reducing technique (e.g., compression or deduplication) is applied to each of the fragments. In some embodiments, a block group is divided into variable-size fragments that may span across the storage blocks, and space-reduction techniques that depend on variable-size fragments (such as variable-size chunking for deduplication) are applied. Various fields and flags in the file metadata and the block group header may indicate the data reduction scheme used for particular data. A variety of reduction techniques may be applied in various embodiments, including but not limited to compression via zip, lz4, snappy, run-length encoding, or arbitrary user defined compression via a dynamically linked library. Data may also be deduplicated using an external catalog. 
         [0015]      FIG. 1  depicts a computer system  100  for policy-based, multi-scheme data reduction for a computer memory in accordance with an embodiment. Computer system  100  comprises a file system including a processor  101  and a memory  106 . Processor  101  stores data in memory  106  in storage blocks such as storage blocks  103 A-N and storage blocks  104 A-N, which are divided up into block groups  105 A-B. A single file that is stored in memory  106  may span multiple storage blocks within a single block group, or multiple block groups. Policy engine  102  stores policy rules for application of data reduction techniques in memory  106 . The policy rules in policy engine  102  may be set by, for example, an administrator. The policy engine  102  may determine, based on, for example, data type, file type, and/or access patterns, a type of data reduction to apply to any storage block in memory  106 , such as storage blocks  103 A-N or  104 A-N. The policy engine may scan the memory  106  periodically in some embodiments in order to determine whether data reduction needs to be applied. In some embodiments, an access, such as reading or writing of data in one or more storage blocks may trigger determining by the policy engine  102  whether to apply a particular data reduction technique to the one or more storage blocks. The policy engine  102  may also specify when to apply data reduction; for example, data reduction may be performed during a period off-peak load period for the computer system  100  (for example, overnight), or after a specified amount of time has elapsed since a particular block group has been accessed. In some embodiments, the storage blocks  103 A-N and  104 A-N may each be 32 kilobytes (KB); however, storage blocks may be any appropriate size in various embodiments. In some embodiments, a fixed number of respective storage blocks (for example, 10) may form each block group. Computer system  100  is shown for illustrative purposes only, a memory such as memory  106  may comprise any appropriate number of storage blocks, and the storage blocks may be divided up into any appropriate number of block groups, each containing any appropriate number of storage blocks. 
         [0016]    In some embodiments, a policy engine such as policy engine  102  may be implemented in a system comprising a general parallel file system (GPFS) scheme, such as is described with respect to U.S. Pat. No. 8,548,965 (Devarakonda et al., Oct. 1, 2013), which is hereby incorporated by reference in its entirety. The GPFS system provides a structured query language (SQL)-like language that is used to match the attributes of files in the system. For example, ‘WHERE FILE_NAME LIKE’%.jpeg′ determines all files with the “.jpeg” extension in the memory  106 . The language of the GPFS system may be extended associate particular data reduction techniques with, for example, file extensions. The ACTION clause on the rules may be extended to include scheduling information to specify that the space reduction is performed in the future; for example, during a period of relatively low load in computer system  100 . Some examples policy rules that may be implemented in various embodiments include functions to compute the best data reduction methods based on the data values stored in files and database tables, based on sampling of data in files or database tables, and/or based on storage media and device characteristics. Further policy rules may compare an amount of space that a possibly already compressed file currently occupies versus a predicted amount the file would occupy if the file is re-reduced with different data reduction methods. Such policy rules may be implemented in policy engine  102  in any appropriate manner. Operation of the policy engine is discussed in further detail below with respect to method  300  of  FIG. 3 . 
         [0017]    In order to read a file, the file system must be able to locate the storage blocks that comprise that file. For this purpose, the file system maintains metadata blocks that record the location of each data block of each file.  FIG. 2A  illustrates an embodiment of a metadata block  200  for a file, which includes a plurality of block location records  201 A-N that each points to a respective individual storage block (such as storage blocks  103 A-N or  104 A-N) that make up the file associated with metadata block  200 . Each of storage block location records  201 A-N includes a respective space reduction flag  202 A-N, and a disk number  203 A-N and sector number  204 A-N, which gives the physical location in the memory of the storage block corresponding to the block location record. The space reduction flags  202 A-N in each of the block location records  201 A-N indicate whether the storage block corresponding to the block location record is unreduced (raw) or reduced (i.e., compressed or deduplicated). The space reduction flags  202 A-N may indicate a type of reduction that is applied to the respective storage block associated with the block location record  201 A-N in which the space reduction flag  202 A-N is located. 
         [0018]      FIG. 2B  depicts a block group  210  and a block group header  211  for policy-based, multi-scheme compression for a computer memory in accordance with an embodiment. Block group  210  may comprise either of block groups  105 A-B shown in  FIG. 1 , and is made up of a plurality of storage blocks  213 A-N, which may comprise storage blocks  103 A-N or  104 A-N that were shown in  FIG. 1 . Block group  210  includes a block group header  211 , which describes the entire block group  210 . The block group header  211  is located in the first storage block  213 A of the block group  210 . To enable relatively fast random access to reduced data, fixed size, hierarchical fragmenting of the data may be maintained. The block group header  211  includes a format version field  212 A, fragment descriptor table size field  212 B, and an index to the fragment descriptor table  212 C. The fragment descriptor table  212 D comprises a plurality of fragment descriptors that give information about the fragments that are stored in the storage blocks in the block group  210 . The fragment descriptors in the fragment descriptor table  212 D may include original fragment length, fragment type, a flag that indicates whether a fragment is in use, compression information such as fragment length with data reduction applied and starting offset, deduplication information such as signature and location information, and an index to the next fragment descriptor in the fragment descriptor table  212 D. Each fragment descriptor covers a range of the original data, and defines how the original data were reduced and where the reduced data are stored. Each fragment descriptor may be the same size and correspond to a single storage block in the block group  210  in some embodiments, or in other embodiments, the fragments that are stored in the storage blocks may be variable in size. The block group header  211  may also include, for each storage block in the block group  210 , the fragment offset within the block group  210 , the compressed size and a flag indicating whether the fragment is compressed or raw. Also, the block group header  211  contains the number of storage blocks in the block group  210  and the size of the compressed group (including invalidated fragments and active fragments). Reduced data may be stored in the same storage block in which the data was located before it was reduced, in a different storage block within the same block group of the file, or may be stored elsewhere, such as a catalog or dictionary for duplicate data. All data within a fragment is reduced using the same method, but fragments may vary in size. A fragment may be relatively large, covering multiple storage blocks, or a fragment may be relatively small, covering less than a single storage block. A fragment comprises the smallest independent unit of compression in the memory.  FIG. 2B  is shown for illustrative purposes only; in various embodiments, the header information may be stored in any appropriate manner within a block group. 
         [0019]      FIG. 3  depicts a method  300  for application of data reduction in conjunction with policy-based, multi-scheme data reduction in accordance with an embodiment. Method  300  may be implemented in policy engine  102 . First, in block  301 , a set of policy rules are defined in the policy engine  102 . The rules may be set by, for example, an administrator. Any appropriate characteristics of data in the file system may be matched by the policy rules. The rules may be defined to match static attributes of each file in memory  106 , such as file name, owner, or access time, may match static attributes of the underlying storage media. The rules may also match the contents of a file in some embodiments. Dynamic attributes may also be matched by the rules, such as recent access to the data, current load on the file system, or current time of day. Each policy rule specifies a data reduction technique. A rule that matches a file or part of a file defines the particular reduction technique that is applied to the data, or subset of the data, in that file. Reduction techniques that may be applied include but are not limited to a variety of compression algorithms, such as zip or lz4 for lossless compression; mpeg for lossy compression; and a variety of data deduplication algorithms that may be based on blocks, chunks, or streams in various embodiments. A rule may also specify a sampling heuristic to be used to determine if reduction should be attempted. A rule may also specify when the reduction should be applied. For example, reduction may be applied immediately in-line when the data is first written to a storage block. In other embodiments, data reduction may be applied after a threshold time period has elapsed since the file was last closed and no additional accesses to the file have occurred. The reduction may be scheduled for off-peak load hours in the file system, or any time the current load drops below some threshold, or may be scheduled as part of nightly backup. In further embodiments, the reduction technique applied to data may change as the data ages and is moved to slower physical storage or off-line. 
         [0020]    Next, in block  302 , the policy engine  102  determines the storage blocks to be reduced, the type of data reduction to use, and when to apply the data reduction, based on the policy rules that were defined in block  301 . The policy engine may scan the memory  106  for files or data that match the rules at predefined intervals in some embodiments. In some embodiments, access to a file, such as a write or read, may trigger a determination by the policy engine  102  of whether the file matches a policy rule in the policy engine  102 . Reduction may be applied to an entire file or to any portion of a file that matches a rule in policy engine  102 . Lastly, in block  303 , the file or portion of a file that was determined to match a rule in block  302  is reduced according to the matched rule. For example, the type of data reduction and the time of application of the data reduction are applied to the matching data according to the rule. In conjunction with application of data reduction, any block group headers and storage block location records (as shown in  FIG. 2A-B ) associated with the reduced data are updated to reflect the data reduction. Blocks  302  and  303  may be repeated as needed by the policy engine  102  during operation of the computer system  100  in order to apply data reduction to the data in memory  106   
         [0021]      FIG. 4  depicts a method  400  for performing a read of reduced data in conjunction with policy-based, multi-scheme data reduction in accordance with an embodiment. First, in block  401 , an offset and length for a read command are received. Next, in block  402 , the block group of the read is determined based on the metadata block  200  for the file that is being read. The file system may first obtain a byte-range lock over the requested region in order to insure consistency of the data before determining the block group. It is also determined, based on the space reduction flag(s) (such as space reduction flags  202 A-N) in the block location records that point to the storage blocks of the read whether the read is reading reduced data. If it is determined that the read is not reading reduced data, the read proceeds as normal and the unreduced data is read directly. However, if it is determined that the read is reading reduced data, the file system extends its byte range lock to cover the entire block group containing the requested data, and flow proceeds to block  403 . In block  403 , the particular reduced storage blocks involved in the read are determined. A read may spans multiple storage blocks or portions of storage blocks; all storage blocks that are to be fully or partially read by the read are determined in block  403 . This determination is made based on the block group header. Then, in block  404 , the determined storage blocks are unreduced, e.g., uncompressed in memory. Lastly, in block  405 , the read is performed from the unreduced data. 
         [0022]    If many fragments of storage blocks need to be uncompressed in block  404  of method  400 , it is faster to uncompress them together, rather than one at a time; however, in order to uncompress the fragments together, the fragments need to be physically adjacent in the memory. Fragments are logically adjacent just after initially compression of a file, but after writes to the compressed file (discussed below with respect to  FIG. 5 ), the order of the fragments in memory may change, and logically adjacent fragments may not be physically adjacent. Inspecting the fragment location data in fragment descriptor table  212 D of the block group header  211  may therefore be performed in block  403 , so that the contiguous sequences of compressed fragments may be determined and used for uncompressing the contiguous fragments together. 
         [0023]      FIG. 5  depicts a method  500  for performing a write to reduced data in conjunction with policy-based, multi-scheme data reduction in accordance with an embodiment. First, in block  501 , an offset, length, and write data for a write are received. Then, in block  501 , the block group for the write is determined based on the metadata block  200  for the file that is being written, and it is determined whether the write is to reduced data based on the space reduction flag(s) (such as space reduction flags  202 A-N) in the block location records that point to the storage blocks of the write. If the write is to unreduced data, the write is performed directly on the unreduced data. If the write is to reduced data, flow proceeds to block  503 . In block  503 , the first and last fragments in the block group that are involved in the write are determined using the fragment descriptor table  212 D in the block group header  211 . Next, in block  504 , if the write does not align to the fragment boundaries, the first and last fragments are unreduced, and the write data is inserted in between the unreduced first and last fragments, resulting in unreduced write storage block data for the write. If the write does align to the storage block boundaries, the first and/or last fragments may not need to be unreduced but are rather overwritten entirely. The contents of any intermediate fragments (which may comprise entire storage blocks) do not need to be unreduced, because the data in the intermediate fragments is being completely overwritten with the write data. Then, in block  505 , the unreduced storage block data is reduced and appended in new storage blocks to the end of the block group. The block group header is updated to indicate the new location of the written data after the write, and the block location records in the metadata block  200  for the written file are also updated as needed. 
         [0024]    Lastly, in block  506 , the original fragments that were determined in block  503  (first, last, and any intermediate fragments) are invalidated. These invalidated fragments may be garbage collected by the file system when, for example, their cumulative size starts significantly lowering (i.e., based on a threshold) the compression ratio for the block group. No uncompression is needed to perform garbage collection. The first storage block in the block group that contains at least one invalidated fragment is read and copied to the output buffer for the block group; any initial blocks that are not invalidated do not need to be read in block  506 . The fragments of the block group are then shifted over the invalidated fragments, so that the fragments of the block group are physically adjacent. In some embodiments of garbage collection, the valid storage fragments may be rearranged so that the compressed fragments are in the same order as the raw fragments (i.e., in logical order). In other embodiments, the valid fragments are copied one after the other to the shifted location in whatever order they happen to be. 
         [0025]    As described above with respect to  FIG. 5 , in some embodiments, when a reduced file is modified (i.e., partially written over), the storage blocks that were written over are invalidated but left in place, and their block group header entries are modified to point to the new storage blocks that are appended at the end of the block group. Therefore, after writing to a reduced file, the order of reduced fragments in the block group does not always follow the order of raw data in the file. In order to write to storage blocks that have fragments that do not follow the order of raw data in the file, preprocessing of the data in the block group header may be performed in block  503  to determine the locations of the fragments involved in the write. The preprocessing may comprise storing the identifiers of the fragments involved in the write in a temporary array based on the data in the block group header, and sorting the temporary array based on the logical order of the data in the storage blocks in the file. It is then determined based on the block group header and the temporary array which blocks are both physically and logically adjacent to one another. Blocks that are determined to be both physically and logically adjacent to one another are unreduced as a group, while blocks that are out of order are unreduced separately. 
         [0026]      FIG. 6  illustrates an example of a computer  600  which may be utilized in conjunction with exemplary embodiments of policy-based, multi-scheme compression for a computer memory. Various operations discussed above may utilize the capabilities of the computer  600 . One or more of the capabilities of the computer  600  may be incorporated in any element, module, application, and/or component discussed herein. For example, processor  101  may comprise processor  610 , and memory  106  may comprise memory  620 . 
         [0027]    The computer  600  includes, but is not limited to, PCs, workstations, laptops, PDAs, palm devices, servers, storages, and the like. Generally, in terms of hardware architecture, the computer  600  may include one or more processors  610 , memory  620 , and one or more I/O devices  670  that are communicatively coupled via a local interface (not shown). The local interface can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components. 
         [0028]    The processor  610  is a hardware device for executing software that can be stored in the memory  620 . The processor  610  can be virtually any custom made or commercially available processor, a central processing unit (CPU), a digital signal processor (DSP), or an auxiliary processor among several processors associated with the computer  600 , and the processor  610  may be a semiconductor based microprocessor (in the form of a microchip) or a macroprocessor. 
         [0029]    The memory  620  can include any one or combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and nonvolatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory  620  may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory  620  can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor  610 . 
         [0030]    The software in the memory  620  may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The software in the memory  620  includes a suitable operating system (O/S)  650 , compiler  640 , source code  630 , and one or more applications  660  in accordance with exemplary embodiments. As illustrated, the application  660  comprises numerous functional components for implementing the features and operations of the exemplary embodiments. The application  660  of the computer  600  may represent various applications, computational units, logic, functional units, processes, operations, virtual entities, and/or modules in accordance with exemplary embodiments, but the application  660  is not meant to be a limitation. 
         [0031]    The operating system  650  controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. It is contemplated by the inventors that the application  660  for implementing exemplary embodiments may be applicable on all commercially available operating systems. 
         [0032]    Application  660  may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler (such as the compiler  640 ), assembler, interpreter, or the like, which may or may not be included within the memory  620 , so as to operate properly in connection with the O/S  650 . Furthermore, the application  660  can be written as an object oriented programming language, which has classes of data and methods, or a procedure programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, C#, Pascal, BASIC, API calls, HTML, XHTML, XML, ASP scripts, FORTRAN, COBOL, Perl, Java, ADA, .NET, and the like. 
         [0033]    The I/O devices  670  may include input devices such as, for example but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. Furthermore, the I/O devices  670  may also include output devices, for example but not limited to a printer, display, etc. Finally, the I/O devices  670  may further include devices that communicate both inputs and outputs, for instance but not limited to, a NIC or modulator/demodulator (for accessing remote devices, other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc. The I/O devices  670  also include components for communicating over various networks, such as the Internet or intranet. 
         [0034]    If the computer  600  is a PC, workstation, intelligent device or the like, the software in the memory  620  may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of essential software routines that initialize and test hardware at startup, start the O/S  650 , and support the transfer of data among the hardware devices. The BIOS is stored in some type of read-only-memory, such as ROM, PROM, EPROM, EEPROM or the like, so that the BIOS can be executed when the computer  600  is activated. 
         [0035]    When the computer  600  is in operation, the processor  610  is configured to execute software stored within the memory  620 , to communicate data to and from the memory  620 , and to generally control operations of the computer  600  pursuant to the software. The application  660  and the O/S  650  are read, in whole or in part, by the processor  610 , perhaps buffered within the processor  610 , and then executed. 
         [0036]    When the application  660  is implemented in software it should be noted that the application  660  can be stored on virtually any computer readable storage medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable storage medium may be an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. 
         [0037]    The application  660  can be embodied in any computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable storage medium” can be any means that can store the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable storage medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or a device. 
         [0038]    More specific examples (a nonexhaustive list) of the computer-readable storage medium may include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic or optical), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc memory (CDROM, CD R/W) (optical). Note that the computer-readable storage medium could even be paper or another suitable medium, upon which the program is printed or punched, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory. 
         [0039]    In exemplary embodiments, where the application  660  is implemented in hardware, the application  660  can be implemented with any one or a combination of the following technologies, which are well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc. 
         [0040]    Technical effects and benefits include . . . &lt;add the technical benefits as described above&gt; 
         [0041]    The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention. 
         [0042]    The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A nonexhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire. 
         [0043]    Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device. 
         [0044]    Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user&#39;s computer, partly on the user&#39;s computer, as a stand-alone software package, partly on the user&#39;s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user&#39;s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention 
         [0045]    Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), 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 readable program instructions. 
         [0046]    These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, 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, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks. 
         [0047]    The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks. 
         [0048]    The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. 
         [0049]    The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.