pset2020_4: # 84218 (BDUX81547): TCS 800-239506 Global variable g.company does not work Date: Mon, 08 Feb 2021 08:44:48 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ TCS 800-239506 Whens ession tdsls4601m200 is started with tdslsdll4071 in debug you can notice that in function initialize.global.object.variables(..) the variable g.company is not filled with get.compnr(). Can you explain why this is occuring. When I rename the variable into g.company.1 it works OK. Therefore I assume somewhere else g.company is used as well. How can this be prevented? Compiler / VSC? _Workaround_ The correct symbol is set and accessed in the BaanVM, however this cannot be verified with the debugger _Test Procedure_ RegTests 3GL debugger: see TCS remark _Affected Executables_ bshell6.2 _Motive source_ TCS:800-239506 ------------------------------------------------------------------------ pset2020_4: # 84191 (BDUX81436): add bshell governor bms messsage when resources are exceeded Date: Mon, 01 Feb 2021 15:58:27 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ When printing large reports the file system in the Cloud can bring down a node. Therefore a limit is imposed on the max number of bytes allowed to be written by a report or other session. When this limit is reached, the report is terminated and an internal message is send to the Resource monitor _Test Procedure_ RegTests _Affected Executables_ bshell6.2 _Motive source_ JIRA:LND2-35411 ------------------------------------------------------------------------ pset2020_4: # 84182 (BDUX81520): D752469: Unicode conversion: Slow conversion of BLOB table Date: Fri, 29 Jan 2021 17:37:04 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ The Unicode conversion of a table containing a BLOB column is extremely slow. The time to convert a table containing a BLOB column grows quadratically as the number of rows increases. _Test Procedure_ Convert a table containing a BLOB column. Duplicate the number of rows, and observe that the time to convert the table also approximately duplicates. _Affected Executables_ msql_srv _Motive source_ InforXtreme:752469 ------------------------------------------------------------------------ pset2020_4: # 84158 (BDNT81493): Windows build: adding dependency of msql7 on bsql and jbdb to prevent combodriver version error Date: Wed, 27 Jan 2021 18:07:56 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ In many cases, a partial Windows build resulted in tests failing due to the version of the combodriver differing from those of jbdb. Moreover, during the testing of this project, I discovered that bsql would also sometimes complain about an incorrect version. By adding a dependency to these two projects in msql7_dll, the error message should at least be less common. _Test Procedure_ Built on pset8. ------------------------------------------------------------------------ pset2020_4: # 84131 (BDUX81452): Incident 15188468/Critical Production Service Unusable Date: Fri, 22 Jan 2021 15:14:17 +0100 Created on: pset2020_3 Type: bugfix _Problem Description (Customer terms)_ bshell crashes with Log for Locking in combination with the bdemanager and child transactions _Affected Executables_ bshell6.2 _Motive source_ InforXtreme:752909 ------------------------------------------------------------------------ pset2020_4: # 84114 (BDUX81422): Error during remote execute: hardware capability unsupported VIS3 Date: Tue, 19 Jan 2021 16:54:05 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ Customer is having Fujitsu SPARC M12 / M10 Platforms (ORACLE SOLARIS 11.4 as OS) which support VIS4 Instruction set and not VIS3 instruction set. Received below reply from Oracle: Unfortunately, migration-class1 is not compatible with Fujitsu SPARC M12 platforms or Fujitsu M10 platforms. As a result of that VIS3 Instruction Set cannot work in M10 or M12. After discusion with Oracle agreed to go back to generic instruction set. _Workaround_ NA _Test Procedure_ execute elfdump -H bshell6.2 to see if the instruction set VIS3 is mentioned. Should not be. _Affected Executables_ all _Motive source_ InforXtreme:739142 ------------------------------------------------------------------------ pset2020_4: # 84097 (BDNT81404): splashscreen for startfirst Date: Tue, 12 Jan 2021 13:41:28 +0100 Created on: pset2020_3 Type: enhancement _Problem Description (Customer terms)_ new version and copyright ------------------------------------------------------------------------ pset2020_4: # 84047 (BDUX81339): Log for locking: fix S3 when using non-bshell applications Date: Mon, 28 Dec 2020 11:49:13 +0100 Created on: pset2020_3 Type: bugfix _Problem Description (Customer terms)_ Previously, there was a fix to change the unique pointer used to ensure that the destructor of TracerS3 was called (and that the resulting log for locking file was uploaded to S3, as well as deleted thereafter) to a call in stop(). However, it was overlooked that stop is only called when using the bshell, which means that the functionality will be broken for all other applications that use log for locking. This will potentially lead to the filling up of local storage. Hence the merge to pset2020_3 as well as the latest branch. _Test Procedure_ Built and tested on dev6 and pset8. ------------------------------------------------------------------------ pset2020_4: # 84040 (BDNT81325): Regtest: get rid of error message in Windows Date: Tue, 22 Dec 2020 16:43:11 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ 1. The Build3rdparty, when run on the pset6, would do a 'rm -rf /*', due to a variable not being set. The script has been changed to die if the value in question is not set. 2. On Windows, Perl gave an error message due to the implicit cast of the return value of readdir() to an int, which would result in the while-loop terminating if a file or dirname with "0" were encountered. _Test Procedure_ Tested on pset7. ------------------------------------------------------------------------ pset2020_4: # 84033 (BDUX81309): permission for session check in wrong company due to compnr 0 fix Date: Mon, 21 Dec 2020 17:10:13 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ For a normal user a AMS Role is defined where permissions are given to start sessions of the DA package in companies 1782, 1783 and 1784. When using Portingset 9.3i from the date 3 november 2020 the normal user does not have any problems starting session daxch0501m000 (Exchagne Schemes). However, on december 15 Portingset 9.3j has been installed and in the following Bflow test run a specific Bflow test fails. It fails with the message that the user does not have permissions to start session daxch0501m000. AMS Roles and the user definition are all defined and created in the Bflow test and this in not changed. The problem can also be reproduced without Bflow (see reproduction scenario) The problem can be 'fixed' by adding a new rule in the AMS Role defining the permission for package DA, specifically for Company 0000. In that case the normal user is able to start the session as he should. This is discussed with Dick Zwartbol and Avi Cohen Stuart and some tracing files have been send. Where did the defect occur? (Session code, etcetera) The problem occurs on the Bflow environment of the Nlbaltldev1, while logged in as normal user junior. How can the defect be reproduced? (Description of the test actions, step by step, starting from the main session) 1. Loging to the Bflow environment on system Nlbaltldev1 as normal user junior (password is mail to Avi) URL: https://nlbavwebui01.infor.com:8443/lnui-master/servlet/standalone?startupArgument=nlbavltldev1-bflow 2. Ensure that the desired Portingset is used (9.3j DT.PROTO.64-bit) 3. Ensure the correct AMS Role is used. It should be AMS Role JUNIOR_3B. 4. Start session daxch0501m000. See that the message No Permission pops up, How must the defect be solved? The user should be able to start the session in company 1782 as defined in AMS Role JUNIOR_3B. _Workaround_ Move the session permission check after the start in company 0 check. add tracing for ttadv999 compnr 0 check _Test Procedure_ bflow regtests _Affected Executables_ bshell6.2 _Motive source_ TCS:800-239211 ------------------------------------------------------------------------ pset2020_4: # 84016 (BDUX81245): LND2-32003: netchange keep track of deleted records (phase 1 for demo) Date: Thu, 17 Dec 2020 15:12:51 +0100 Created on: pset2020_4 Type: enhancement _Problem Description (Customer terms)_ soft delete functionality for netchange and SPS _Test Procedure_ regtest _Affected Executables_ all _Motive source_ JIRA:LND2-32003 ------------------------------------------------------------------------ pset2020_4: # 83929 (BDUX81165): DF748303: msql map ODBC failover error codes to knowd bdb_errno codes Date: Thu, 03 Dec 2020 14:26:47 +0100 Created on: pset2020_3 Type: bugfix _Problem Description (Customer terms)_ msql: uncatched odbc errors during failover _Test Procedure_ none _Affected Executables_ msql_srv _Motive source_ InforXtreme:748303 ------------------------------------------------------------------------ pset2020_4: # 83891 (BDNT81102): An error occurred while determining what data to stage (file lib/publish_tables_ce01026 is corrupt). Date: Thu, 26 Nov 2020 13:10:28 +0100 Created on: pset2020_2 Type: bugfix _Problem Description (Customer terms)_ Errors in log 'An error occurred while determining what data to stage (file 'lib/publish_tables_ce01026' is corrupt)' _Workaround_ N/A _Test Procedure_ Tested on the reproduction environment provided by support, see defect for more information. _Affected Executables_ Bshell _Motive source_ InforXtreme:743416 ------------------------------------------------------------------------ pset2020_4: # 83873 (BDNT81094): check deliver.lst for AWS Date: Mon, 23 Nov 2020 12:52:42 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ Missing aws dlls cause crash in bshell _Affected Executables_ all exe and dll which uses AWS ------------------------------------------------------------------------ pset2020_4: # 83852 (BDUX81045): Sessions start in company 0 Date: Thu, 19 Nov 2020 15:35:01 +0100 Created on: pset2020_3 Type: bugfix _Problem Description (Customer terms)_ Suddenly sessions where started in Company 0 _Workaround_ Session Compile would add the additional new compnr start field in a ttadv999 record. _Test Procedure_ regtest _Affected Executables_ bshell6.2 ------------------------------------------------------------------------ pset2020_4: # 83804 (BDUX81001): crash in get_debug_in_debug_mode_ext due to stack overflow Date: Wed, 11 Nov 2020 16:25:15 +0100 Created on: pset2020_4 Type: bugfix _Problem Description (Customer terms)_ Crash with debug objects in combination with long filenames and long local variables _Test Procedure_ RegTest _Affected Executables_ bshell6.2 ------------------------------------------------------------------------ pset2020_4: # 83770 (BDUX80938): Start in Company 0 property Sessions - Portingset part Date: Tue, 03 Nov 2020 17:47:57 +0100 Created on: pset2020_3 Type: enhancement _Problem Description (Customer terms)_ User AMS Companies: Exclude tools sessions that switch to company 0000. _Affected Executables_ bshell6.2 _Motive source_ JIRA:LND2-33320