Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Ibm Os/2 Extended Edition Memory Management Enhancements

IP.com Disclosure Number: IPCOM000099873D
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 4 page(s) / 168K

Publishing Venue

IBM

Related People

Arnold, HH: AUTHOR [+3]

Abstract

This article describes the method that the OS/2* EE Database Manager uses to manage OS/2 shared data areas in Release 1.1. It is an enhancement over the method used in Release 1.0.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 36% of the total text.

Ibm Os/2 Extended Edition Memory Management Enhancements

       This article describes the method that the OS/2* EE
Database Manager uses to manage OS/2 shared data areas in Release
1.1.  It is an enhancement over the method used in Release 1.0.

      In Release 1.0 of the OS/2 Extended Edition Database Manager, a
pool of shared segments was allocated at linkedit time and was
associated with the kernel dynamic link package.  The reason shared
segments were allocated at compile/link time is that during
development of OS/2, OS/2 development would not guarantee that shared
segments allocated dynamically would have the same selector for each
sharing process. This would have meant that addresses of and within
shared segments would be unique to a process (each process would have
its own version).  Since the database architecture required that
shared segments be used to save pointers to shared segment address,
clearly dynamic allocation would not work.  OS/2 development finally
guaranteed that dynamic allocation would work and that each sharing
process would address a given shared segment by the same selector.

      This packaging made the Database Manger fix the size of the
shared memory model (50 shared segment max allotted to the kernel) at
ship time which resulted in:
A)   Limiting the number and size of databases running concurrently.
B)   Waste of OS/2 selectors never being used by majority of
applications.
C)   Applications could access all of the data areas.  They could
potentially accidentally destroy the contents of these data areas.

      With the advent of larger faster machines, the max value of 50
shared segments will not be large enough.  New max value for shared
segments is 1500.  With Presentation Manager absorbing 68% of the
OS/2 selectors available, Database Manager could not and should not
hog an additional 1500 selectors.

      Allocate shared segments as required.  Kernel shared segments
are allocated at STARTDBM; other shared segments are allocated as
required. This gives the following advantages:
*    The max number of shared segments to be allocated is fixed at
STARTDBM time and can be changed via modifying the Database Manager
Configuration File.  This means that small systems can allocate
smaller number of segments, thus using less resources (i.e.,
segments, selectors, storage and DASD space).  A larger system can
allocate more segments.
*     This solution makes the sqlo.dll smaller thus reducing required
DASD and ship diskette space.
*     Additional storage protection is provided for the shared
segment pool against processes which use Database Manager dynamic
link functions, but which have not issued Start Using Database; i.e.,
application program cannot access shared segments unless connected to
the database.
      The 1.1 Memory Management implemented the following objectives:
A)   The KRCB will be the only linkedited shared segment.
B)   Support the number...