The waiting is over we now know what is in latest Technology Refreshes for IBM i 7.2 and 7.1. 7.2's TR3 and 7.1's TR11 appear to contain the same enhancements to the development environment. I am not going to list them all here, just the ones that captured my eye.
For RPG-ers the biggest change is finally releasing RPG from the last constraint of the fixed format. Prior to TR3/TR11 I could only code between the 8th and 80th columns. Now my RPG code can start in the first position and finish at the end of the line. The only prerequisite is that **FREE is entered starting in the first column before my RPG code can start in the first position.
Record and object lock information can now be accessed using SQL: QSYS2.RECORD_LOCK_INFO and QSYS2.OBJECT_LOCK_INFO.
Output queue entries information, similar to WRKOUTQ, is now available as a table function, QSYS2.OUTPUTQUEUE_ENTRIES( ), and as a View, QSYS2.OUTPUTQUEUE_ENTRIES. I can see myself using these a lot to replace the way I have retrieved Output queue entries information in the past.
The following IBM-ers have blog posts describing what is in the new Technology Refreshes:
- Steve Will, Chief IBM i architect: IBM i 7.2 TR3 – PurePower, BRMS Tiers, RPG
- Dawn May, Senior Technical Staff Member: IBM i 7.2 TR3 and 7.1 TR11 Highlights
- Barbara Morris, Lead developer RPG compiler development: Coming soon: Fully free-form RPG
These are the IBM developerWorks pages for the Technology Refreshes:
The formal release web page can be found here, where it states that the planned availability for the Technology Refreshes is November 20, 2015.
You can see a video of IBM's Tim Rowe's announcement webcast to COMMON Europe here.
"QSYS2.OUTPUTQUEUE_ENTIRES( )"
ReplyDelete"QSYS2.OUTPUTQUEUE_ENTIRES"
*ENTRIES
Big "Oops" there. Spelling corrections have been made.
DeleteThanks
The addition of a Run SQL Statements equivalent to Navigator was welcome news and long overdue.
ReplyDeleteI'm looking forward to learning the details of the "websockets" implementation within the Apache based HTTP server. It looked like node.js was the best option for websockets. It appears that we will now have a "native" option, too.
ReplyDelete