New UniBasic command supports performance-enhancing field level replication
UniBasic: New/Enhanced Commands
With UniData 8.2.1 we introduced a new command and extended existing commands to support the introduction of field level replication (which I will cover in-depth in a subsequent blog).
We introduced a new statement called FIELDWRITE, which you can use to update specific fields in an existing record, without the overhead of recreating the entire record under the covers. We also extended the READV and WRITEV commands to read/write multiple fields in a single update, adding additional performance to these commands when updating multiple fields within a record. Writes performed by FIELDWRITE and WRITEV are automatically considered field level updates within UniData Replication.
We’ve enhanced the REMOVE statement with the introduction of @REMOVE.ATTRIBUTE. Setting the @REMOVE.ATTRIBUTE defines which mark character the REMOVE statement will stop at and setting @REMOVE.ATTRIBUTE to “” (the default) results in REMOVE behaving as it did prior to 8.2.1.
Run Time Performance Enhancement
We enhanced UniBasic to support faster dynamic array extraction at the attribute level within a loop. An internal pointer is now maintained at run time to keep track of the last attribute position extracted in the array. Based on worst-case customer issues, run time was reduced from 2 minutes 20 seconds to a sub-second response. This enhancement will provide significant performance improvement to any application doing dynamic array extraction.
Transaction Commit Logging and Replication
We’ve made the following changes around Transactions and Replication. The addition of new @variables:
- @SYS.TIMESTAMP provides the system start up timestamp.
- @TRANSACTION.ID provides the transaction ID. With RFS enabled it provides the transaction ID of the tm process.
We’ve extended the intrinsic system functions with SYSTEM(517), which returns the total wait time applied to the current session as a result of replication pacing.
We’ve added the new UniBasic function getTransactionUpdates to provide a dynamic array of information of active updates within a Transaction Boundary.
The UniBasic Commands Reference manual is a useful source for the syntax/examples and rules of these commands.
To reduce unnecessary or excessive logging, we’ve added the AuditLog function to allow for an application-driven audit.
Run Time Reporting of Errors for Included Code
We’ve made enhancements to now report the name and line number of included code if an error is encountered at runtime. The ‘–D’ option of the BASIC command will now produce an include file trace stack that is used at runtime to report the error.
Debugging for included code
We’ve expanded the V option of the debugger along with the ‘-D’ option of BASIC to allow the interactive debugger to step through and display included code.
- SYSTEM(9013) returns the hostname of the system
- Prior to UniData 8.2.1 EXECUTE … CAPTURING statement always produced Y_ and Z_ temporary files in the _PH_ even if there was no output
- On some file systems, this became an OS bottleneck if the EXECUTE command was used repeatedly in quick succession
- Starting at UniData 8.2.1 the Y_ and Z_ files are not always produced; these files are now created only if the CAPTURING or RETURNING clause returns more than 1,024 bytes or an OS-level command is called
- Query parameters can now be passed in the URL for the following methods GET, POST, PUT and DELETE for HTTP requests
Starting with the UniData 8.2.1 release, we changed the core libraries for UniData on UNIX/Linux from being statically linked to being dynamically linked. With this change the executables makeudt and makeudapi are no longer required. If you run makeudt, a short how-to display noting this change will be displayed.
The libu2callc.so/sl library file now includes the custom code and the udt and udapi_slave executables are not modified. The cfuncdef_user file is also no longer used and only cfuncdef is referenced. If the cfuncdef file has been changed, an upgrade will preserve the pre-existing file and not replace it.
That’s it for now. See you in early January with a blog on UniData and Replication.