Reader Feedback Regarding The Shadow Of Database Hype
December 2, 2013 Timothy Prickett Morgan
I must disagree with the quote that it was not until V7R1 that the AS/400 had “in-memory database.” We have been using the SETOBJACC command for many, many years to lock commonly used table files and work files into memory to improve performance.
The trick is to create a separate subsystem/memory pool that has no job queues to route actual jobs into the same memory paging space. It takes a surprisingly small amount of memory to achieve dramatic I/O savings on these files. For the work files, be sure to create them with deleted records, and set them to Reuse Deleted Records = “Y”; this prevents the data space from overflowing the initial allocation and being paged out to disk.
The following text is from the IBM Help on the SETOBJACC command:
Set Object Access – Help
The Set Object Access (SETOBJACC) command temporarily changes the speed of access to an object by bringing the object into a main storage pool or purging it from all main storage pools. An object can be kept main storage resident by selecting a pool for the object that has available space and does not have jobs associated with it.
Repeated use of the command can cause a set of objects to be resident in a main storage pool.
FYI . . . The article at this link references V2R2, with performance data from a D70 box. V2R2 was released 2/18/1992. A D70 box was rated at 384 MB max memory with 146 GB DASD, and 32.3 CPW (32, not 32,000). It cost about $400,000 for the base hardware/OS at the time. (See the IT Jungle article A Radical Idea For IBM i Software Pricing for support of this pricing reference.)
If I remember correctly, our latest P05 class 720 with four cores, 64 GB RAM, and approximately 1 TB of flash disk cost about $120,000 with all cores active for OS/400, memory, and the flash disk included in the amount. (I don’t think the base D70 price included the full memory/DASD configuration). It is rated at 23,800 CPW and can handle about 52,000 IOPS due to the flash disk. It supports 1,600 users in only 4U of rack space.
Twenty years has made a bit of a difference, hasn’t it?
But an application written then still runs on the current systems.
Regarding the contention about in-memory database capabilities arriving with IBM i 7.1, that was when individual objects could be kept in memory, which is a more direct comparison with what other in memory database options are offering at this time. The article, I believe, makes note of earlier in-memory-like capabilities available in IBM i and OS/400. I would not argue that using memory to enhance database performance has been a capability for many years. In fact, it riles me to hear SAP and Oracle talk about their recent in memory “discoveries.” Their marketing people would like to rewrite history and that sets off my BS meter.