The PowerBuilder code rule "Always use AES encryption algorithm in a secure mode" requires that developers use the Advanced Encryption Standard (AES) algorithm for all encryption operations. AES is a symmetric encryption algorithm that is considered to be one of the strongest and most reliable encryption algorithms available. When using AES encryption, it is important to always use a secure mode, such as Cipher Block Chaining (CBC) or Galois/Counter Mode (GCM). This ensures that the encrypted data is secure and not susceptible to attacks.

The rule states that "Calling the Java class in PowerBuilder is no longer supported in PowerBuilder 2022", this means that developers can no longer use these objects in their PowerBuilder 2022 applications, and any existing applications that were built with these objects will need to be updated to use other methods. o The EJBConnection, EJBTransaction, and JavaVM objects are no longer supported. Also The CreateJavaVM function is no longer supported. This change reflects the changing landscape of application development and the need for developers to use more modern methods and technologies.

The "CASE expressions should end with ELSE clauses" rule states that all CASE expressions used in PowerBuilder code should be concluded with an ELSE clause, regardless of whether the ELSE clause contains any code or not. This is done to ensure that all possible cases are accounted for in the CASE expression, and that the code is robust and reliable. Without an ELSE clause, a CASE expression may not be able to handle unexpected inputs or values, which can cause the code to fail or produce unexpected results.

This rule states that when using cryptographic hash functions, SHA-1 or Message-Digest Algorithms should not be used. Cryptographic hash functions are used to provide a secure way of verifying the integrity of data. SHA-1 and Message-Digest Algorithms are known to be vulnerable to attack, so it is important to use stronger algorithms to ensure the data is secure.

This PowerBuilder code rule states that database queries should be constructed in such a way that they are not vulnerable to injection attacks. An injection attack is a type of malicious attack in which malicious code is inserted into a query in order to gain access to or manipulate data. To prevent such attacks, code should be written to ensure that user input is sanitized and that queries are constructed properly so that malicious code is not able to be injected into them.

The PowerBuilder code rule "DDE functions and events are Obsoleted" states that the use of Dynamic Data Exchange (DDE) functions and events should be avoided as they are no longer supported in new versions of PowerBuilder. Developers should use alternative methods for data exchange, such as OLE Automation or web services.

This rule states that the Data Encryption Standard (DES) or Triple DES (3DES) should not be used in PowerBuilder code. DES and 3DES are outdated encryption algorithms, and are considered to be weak and insecure. It is recommended to use more modern and secure algorithms such as AES or RSA for encryption.

This rule states that when using encryption algorithms, they must be used in conjunction with the appropriate secure mode and padding scheme in order to ensure the security of the data being encrypted.

The rule "Encryption keys should be long enough" states that encryption keys used to protect sensitive data should be of a sufficient length to provide an adequate level of security. The longer the key, the more secure the data will be. Generally, the longer the key, the more difficult it is for an attacker to guess or crack the key. It is important to use strong encryption keys that are at least 128 bits long to ensure that the data is sufficiently protected.

The PowerBuilder code rule "Encryption keys should not be hardcoded" states that any encryption keys used in PowerBuilder code should not be stored as plain text in the code. Instead, the encryption keys should be stored in a secure location outside of the code and referenced from there. This ensures that the encryption keys are kept secure and not exposed to potential attackers who may be able to access the code. It also makes it easier to manage the keys in the event that they need to be changed or updated.

The "Forward Prototype Should Not Contain Duplicate Function Declarations" rule states that PowerBuilder code should not contain multiple declarations of the same function within a single forward prototype. This rule is intended to ensure that the code is organized and readable, and that the same function is not declared multiple times in the same forward prototype. If the same function is declared multiple times in the same forward prototype, it can lead to confusion and errors in the code. This rule also helps to ensure that the code is easy to maintain and debug.

The PowerBuilder code rule that states "Functions should end with RETURN statements" means that all functions should include a RETURN statement as the last line of code. This statement is used to indicate the end of the function and to return a value to the calling program. By using RETURN statements, code can be written in a more organized and efficient manner, as well as making it easier for other developers to understand and debug the code.

The "GOTO should not be used to jump backwards" PowerBuilder code rule states that the GOTO statement should not be used to jump backwards to a previous line of code. This is because it can create confusion and make debugging difficult. Instead, the code should be restructured to use loops, functions, and other control statements to make the code easier to read and understand.

This rule states that IF...ELSEIF constructs should always end with an ELSE clause. This means that any IF...ELSEIF construct should have an ELSE clause at the end, which will be executed if none of the other conditions in the IF...ELSEIF construct are met. This ensures that all possible conditions are accounted for and that no unintended behavior occurs.

The PowerBuilder code rule "IP addresses should not be Hardcoded" states that IP addresses should not be stored directly in the code, but should instead be stored in a configuration file. This allows the IP address to be changed without having to modify the code. This helps to ensure that the code is easier to maintain and allows for easier updates in the future.

This rule states that developers should never use the CoSetProxyBlanket or CoInitializeSecurity APIs in PowerBuilder code. These APIs are used to set the authentication level for a COM object, which can be a security risk when used incorrectly. As such, they should be avoided when writing PowerBuilder code.

This rule states that when writing string literals in PowerBuilder code, newline and control characters should not be used. This is because these characters can cause unexpected behavior in the program, and can also be difficult to debug. It is best to stick to standard characters such as letters, numbers, and punctuation when writing string literals.

The "OS commands should not allow injection attacks" rule states that when executing OS commands from PowerBuilder code, the commands should be validated to ensure that they cannot be used to inject malicious code into the system. This can be done by using parameterized queries, whitelisting accepted commands, or other methods of input validation. Additionally, the code should be written to ensure that any user-supplied data is properly escaped and sanitized to prevent malicious code from being injected into the system.

This PowerBuilder code rule states that regular expressions should not be used in a way that could result in a Denial of Service (DoS) attack. A DoS attack is an attack that attempts to make a system or network resource unavailable to its intended users. Regular expressions can be used to match patterns in strings, but they can also be used to create malicious input that can overwhelm a system with requests. To prevent DoS attacks, regular expressions should be used with caution and be thoroughly tested before being deployed in a production environment.

This rule states that the SOAP and INET objects should not be used when writing PowerBuilder code. These objects are not supported by PowerBuilder and can cause instability and unexpected behavior. Instead, developers should use other supported objects such as the Web Service Proxy or the HTTP Client object. Using these objects will ensure that the code is stable and reliable.

The PowerBuilder code rule "Syntax Errors" checks the syntax of PowerBuilder code for errors. This includes checking for missing semicolons, invalid keywords, and other syntax-related problems. The rule will report any syntax errors it finds, along with a description of the error and its location in the code. This helps developers quickly identify and fix any syntax-related issues in their PowerBuilder code.

The PowerBuilder code rule "The JDBC database interface is removed from the Database painter" means that the JDBC database interface is no longer available in the Database painter. This means that the Database painter will no longer be able to connect to databases using the JDBC interface. Instead, users will need to use other database interfaces to connect to databases.

The OData database interface has been removed from the Database painter in PowerBuilder code. This means that developers will no longer be able to access this interface from the Database painter, and instead must use other methods to access OData databases. This removal is likely intended to encourage developers to use more modern methods of accessing databases, such as through web services or through other more modern interfaces.

The PowerBuilder code rule states that the OLE web browser should no longer be used, as it is not secure. This is because the OLE web browser is an outdated technology that is no longer supported or updated, and thus is vulnerable to security breaches. It is recommended that developers use more secure alternatives such as HTML or JavaScript.

The XSLFOP! PDF method has been removed from PowerScript in order to improve performance and reduce the complexity of the code. This method was used to generate PDF documents from PowerScript, but it was found to be inefficient and difficult to maintain. By removing this method, code will be simpler and more efficient, making it easier to maintain and debug. Additionally, the removal of this method will also improve the overall performance of PowerScript, as it will no longer need to process the unnecessary code.

Upgrade your .NET assembly to .NET 6.0 assembly and use the LoadWithDotNet function instead of LoadWithDotNetFramework and LoadWithDotNetCore functions, you must first ensure that your assembly is compatible with .NET 6.0. Once you have verified compatibility, you can use the LoadWithDotNet function to load the assembly into the PowerBuilder application. The LoadWithDotNet function is designed to work with .NET 6.0 assemblies, and it is a more efficient and reliable way to load assemblies compared to the LoadWithDotNetFramework and LoadWithDotNetCore functions.

This rule states that user IDs and passwords should not be hardcoded into any PowerBuilder code. This means that any references to user IDs and passwords should not be included in the code itself, but instead should be stored in a separate, secure location. This ensures that user credentials are kept confidential and secure, and that they can be easily updated when necessary.

This PowerBuilder code rule states that user input should not be allowed to inject or traverse paths, as this could allow attackers to gain access to unauthorized areas of the system. Path injection and path transversal attacks involve maliciously manipulating the system's file paths to gain access to areas of the system that the user is not authorized to access. To prevent this, user input should be validated and filtered to ensure that only legitimate paths are allowed. Additionally, it is important to ensure that the system is configured to prevent users from accessing areas of the system that they do not have permission to access.