Version 13 Release and Installation Notices

Category: Java compliance
Oracle has announced a date of January 2019 for the Commercial User End of Public Updates for Java 8; any further updates will be available only to Customers and accessible through My Oracle Support and via corporate auto update where applicable. These changes will affect LANSA customers using LANSA Integrator and LANSA Composer so to assist LANSA customers concerned about the impact on their applications, we have updated our Java Compliance statement. Refer to Impacts on LANSA of Oracle enforcing Java compliance

Category: Mapforce Licensing

With the recent release of the Altova Mapforce 2018 product line, there has been a change to the licensing model used by Altova. For more information, refer to Impacts on LANSA Composer of Altova Mapforce switch from concurrent licensing to Server licensing

Category: Mapforce 2018

Mapforce 2018 has been released by Altova.
LANSA has been actively testing Mapforce 2018 with Composer V6.1. This testing has completed without issue.
The status of Mapforce 2018 has been updated to Tested OK by LANSA.
You can check the versions of Mapforce tested with LANSA Composer (and the version of LANSA Composer) here
This section also has the following general reminder:
Attention: You should not download and apply any Mapforce Release or Service Pack until it is given an official support status by LANSA. Contact your LANSA Support representative for any Mapforce version support queries.

Category: Windows Updates

Any LANSA Client queries with output to Excel will generate the following error after applying Windows update KB4041676

This error will occur irrespective of LANSA Client versions or Windows operating systems (after applying the update).

The error above is listed in the KB4041676 notes, under the section ‘Known issues in this update’ with a status of ‘Microsoft is working on a resolution and will provide an update in an upcoming release.’

Uninstalling the windows update allows the queries to complete successfully with output to Excel. A short-term workaround, if customers don’t want to, or are not in a position to, uninstall the update, is to output to XML and load that XML file into Excel.

Category: Upgrade

In LANSA V12 SP1, a new COMPOSER_RUN BIF was introduced to facilitate one LANSA system interacting with a separate LANSA Composer system. Upgrading the LANSA V12 SP1 system calling the BIF to either V13 or up to V14 can cause functions using the COMPOSER_RUN BIF command to fail with the following error
DCM9999 This BIF is only supported on Microsoft Windows.
To overcome this error, you must recompile the failing function in the upgraded LANSA system.

Category: Longrange
21 January 2017: Apple have extended their iOS HTTPS/ATS implementation deadline from January 2017 deadline to a new undetermined date. This means that for the moment you don’t need anything. Refer to
https://developer.apple.com/news/?id=12212016b
Despite this extension of the deadline, Apple have made it clear that this implementation will occur. LANSA recommends including a move to HTTPS and ATS into your longer term plans.

Original Post: Apple has announced that starting from January 2017, all apps (including LongRange) on the App Store are to use HTTPS (TLS) connection only. Refer to this Longrange forum notice for details
https://longrange.lansa.com.au/viewtopic.php?f=13&t=511

Category: Host Monitor/Checkin and Compile
A checkin and compile problem has been encountered with the following criteria in place
- An RDML physical file which has a key, in an RDMLX partition
- Where the master repository is on an IBM i with Operating System 7.3
- The checkin and compile via the host Monitor will fail with an MCH5601 error in the joblog on a MOVOBJ command
This has been confirmed as an OS 7.3 issue and an IBM PTF is available to resolve the issue. The PTF is SI62854.
This problem is not exclusive to any particular version of LANSA and can occur on all supported versions of LANSA with the master repository on IBM OS 7.3.

• In a V13 partition, open a file definition that has access routes. Click the Access Routes tab. For any access route defined, expand the Key, and you will see the keys.
• Check the file into the IBM i master. Enter the LANSA system on the IBM i master, take option 21=Access Routes and take option 2 to see the access routes definitions. In some situations, you may find the key has disappeared.
  Note: if there are multiple access routes on a file, the key(s) for each access route will be missing.
• Checking out again, you will get an error when pressing Save/Compile due to the missing key.

1. Check out the file and its fields that have the SUNI attribute.
2. Create an impact list that contains the fields and all objects that use them. Save it to Excel.
3. Delete the fields from the repository.
4. Reload the file. It should now only have Nchar/Nvarchar fields, hopefully with the same identifier as previously. Rebuild the OAM.
5. Use the impact list to rebuild and test affected objects.
   * IBM i Char/Varchar fields with CCSID 1208 will always be loaded as Nchar/Nvarchar.

1. Security control - the VCS security controls what you can change in the VCS. What you change in your local repository effects nobody else. Only when you need to check it in to your VCS does there need to be a security check. (Removing this meant we did not have to deal with securing the security records in the text format VCS files).
2. Tasks are ignored. The control of whether you can edit a LANSA object is with the VCS, not LANSA. (Basic VCS just provide control of what you can edit, when and how you edited it. Some add in Task Management and integration into bug tracking and project management. Each LANSA customer needs to choose the VCS that best suits their work practices)
   VCS uses YAML to serialize a LANSA Object into a textual representation. Its been chosen because it’s a documented file standard and is easy to use with difference tools, which may be fundamental to the use of a VCS. Its is also easy to edit by hand.
3. Once the partition is enabled for long names support, all new files will have the PF created with SQL on the IBM i (as they automatically get the enable long names flag enabled). This can be switched off for individual files if needed.
4. Quick Export is not available for Web Components.
5. Web Components will not be able to be saved to a VCS using the IDE. They can still be in the Repository, but you must manage them yourselves.
6. The versioning information in the WAM is for use whilst editing the WAM. This is recognised in the fact that the number of versions kept is specific to each IDE instance. This feature will still be available when there is a VCS Master. But, when the file is serialised this information will not be kept. It will not be checked into the VCS Master. The saving of the object serialises it into the YML file. Whilst the YML file will not contain the WAM versions, neither will it remove them from the LANSA Repository. When a GetLatestVersion is performed, only then will the YML file replace the WAM versions with the single current instance.
   This is consistent with the rest of the LANSA objects. The VCS does source code control, not the LANSA editor. Similarly, the VCS performs security checks, not LANSA.

1. From OS/400 Main Menu screen enter the following command: go licpgm
2. Under Licensed Programs pick option 11 for Install licensed programs
3. Enter F11 twice then page down to find Product Option 39, which should have the description "International Components for Unicode"
4. IBM i PTFs are required for version 13 as part of NCHAR support:
   V5R4: SI44579, SI44580, SI44581, SI44582, SI44609
   V6R1: SI44391, SI44399, SI44400, SI44401, SI44402
   V7R1: SI44403, SI44404, SI44405, SI44406, SI44432

1. All LANSA shipped JavaScript and CSS files have been converted to UTF-8 as well.
2. Before external resources were introduced in 12 SP1, you could add extra JavaScript and CSS files using the css_files and javascript_files properties in layout weblets. The <link> and <script> elements created for these properties didn't have a charset attribute, therefore they were assumed to be in the same character set as the main document. To preserve backwards compatibility, they now have a charset attribute that defaults to "shift_jis" for language JPN and to "iso-8859-1" for all other languages. If you need to nominate a different character set, use the css_files_charset and javascript_files_charset properties in std_style_v2 and std_script weblets (You need to add these parameters to your site layout). A better approach is to register your extra CSS and JavaScript files as external resources and include them as such.
3. Text entered in the WAM Editor (UTF-8) no longer goes through any character set conversion (The intermediate character set conversions limited the use of certain characters that couldn't be converted to EBCDIC on IBM I ).

1. You have created your own versions of the grid weblet, because they use a list TSML node to store the metadata for a list
2. You have created your own Technology Service