What is the rule structure in Aion 11.0 versus Aion 10.2?

Products

• Aion Business Rules Expert

Issue/Introduction

In the past, migrating from a major Aion release to another has meant recoding the Aion rules. However the differences in the code structure between Aion 10.2 to 11.0 are minimal, and no rewriting will be necessary in general.

Environment

Release: AIOCBV05900-10.2-Aion-Business Rules-Advanced Builder Option
Component:

Resolution

Aion 11.0 code differs little, in general, from Aion 10.2. This will make migration to Aion 11.0 from 10.2 fairly easy.

As per section 6.3 of the Aion 11.0 Readme, and section 8.0 of the Aion Installation Guide, there are no major changes that necessarily need to be made.

6.3 Aion BRE Mainframe Specific Information

Aion BRE r11 for the mainframe offers the same basic functionality as Aion BRE r10.2, r11 for Microsoft Windows, except for those features that are unique to the Microsoft Windows platforms (for example, support for the Aion IDE, support for COM, and the Dynamic Rule Manager).

Aion 10.2 applications that have been developed for the mainframe should be converted to Aion BRE r11 in the Microsoft Windows environment before being compiled under Aion BRE r11 for the mainframe.

Most Aion r10.2 mainframe applications can be successfully compiled by Aion BRE r11 without modification. However, if any difficulties are encountered, it is recommended that the application be restored using the primary development environment, Aion BRE r11 for Microsoft Windows, where the problem can be investigated using a more intuitive graphical facility IDE capabilities.

Migration Considerations

This section describes various migration considerations. You should also refer to the ?Best Practices Guide? and the ?Readme? document.

1. In r10.2 the suffix of module names was ?10?, such as RESYS10, and OAES10. In r11.0 the suffix of module names is ?B0?. You must search your existing application files (APPs) with a text editor for explicit references to modules with a ?10? suffix, and replace these with ?B0? suffixes.
   
   
2. All your applications have to be rebuilt for r11.0. Applications that were built with a prior version of Aion BRE cannot be executed in the r11.0 environment. Similarly, applications that are built by Aion BRE r11.0 cannot be executed in a pre-r11.0 environment.
   
   
3. If you are executing Aion BRE applications in a MAES environment, you can mix pre-11.0 and r11.0 applications and modules in the STEPLIB and MAESHPO DD allocations. This must be done carefully, and needs to be thoroughly tested, prior to production use. Aion BRE r10.x client programs running in the CICS and IMS environments will execute applications via program OAES10. The request for OAES10 is explicit within VTAM messages sent to MAES. Aion BRE r11.0 client programs will send explicit requests for OAESB0. Both of these variations will execute correctly when both sets of libraries are in the STEPLIB and MAESHPO allocations.
   
   
4. DB2 applications with short integer column attribute values must be changed from- integer(2) to integer.
   
   
5. Client applications that use xb_Open to prepare binary objects to pass to Aion methods as parameters need to make an additional call to a xb_SetDataBufferSize function to establish the size of the binary buffer. Previously the Aion BRE internal functions that processed the binary data and advanced it without verifying that the end of the buffer was not exceeded. When the data was referenced beyond the end of the buffer it caused a crash. The internal functions were updated to ensure that data is only referenced within the extent of the buffer. The additional xb_SetDataBufferSize call is necessary, because the size of the buffer is not provided on the xb_Open call. The following shows how the xb_SetDataBufferSize call was added to the SOBATCB COBOL example program:
   

   CALL 'xb_Open' USINGBY VALUE XB-OPEN-READBY VALUE ADDRESS OF COBOL-WS-OBJECTRETURNING BINARYOUT-OUT OF RECEIVEONE-METHODCALL 'xb_SetDataBufferSize' USINGBY VALUE BINARYOUT-OUT OF RECEIVEONE-METHODBY VALUE LENGTH OF COBOL-WS-OBJECT Migration Considerations Chapter 8: Migration Information 181

6. The internal logic of MAES Suspend/Resume and Acquire/Release processing is updated. These revisions do not adversely affect customer application processing. You should retest IMS and CICS applications that use this style of processing to ensure Suspend/Resume and Acquire/Release capabilities are operating correctly.
   
   
7. In r11.0 there is a new format for messages exchanged with TCP/IP (and SSL) clients. The pre-r11.0 message format is also supported. The new message format uses 4-byte lengths for parameter values, and the length of the overall message is a 4-byte value. The pre-r11.0 message format was restricted by an overall 2-byte message length value. The new TCPIP/SSL message format can also be used by Java clients.
   
   
8. By default DB2 static SQL applications perform multi-row fetches. These applications will operate correctly in DB2 v8.1 NFM and DB2 v9 environments. Problems will occur in DB2 v8.1 non-NFM environments. These problems can be corrected by rebuilding the application with the following directive in the BABUILD step.

   DB2-STATIC-MULTIROW-FETCH=NO