Browse Prior Art Database

Using Different Tasking Schemes To Satisfy Requests For Two File Systems

IP.com Disclosure Number: IPCOM000123160D
Original Publication Date: 1998-Jun-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 114K

Publishing Venue

IBM

Related People

Schank, GD: AUTHOR [+2]

Abstract

This disclosure is concerned with the simultaneous use of multitasking and OpenEdition *Byte File System* (BFS*) services in server-type applications that run in the IBM *VM/ESA* environment.

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

Using Different Tasking Schemes To Satisfy Requests For Two File
Systems

   This disclosure is concerned with the simultaneous use of
multitasking and OpenEdition *Byte File System* (BFS*) services in
server-type applications that run in the IBM *VM/ESA* environment.

   Multitasking application programs may exist which use their
own multitasking schemes instead of making use CMS* Application
Multitasking (CMS AM) services.  An application that uses
OpenEdition services automatically becomes a POSIX process that is
subject to the architectural requirements of CMS AM.  If the
application uses a local tasking scheme instead of CMS AM for its
multitasking, it can enter wait states that are not compatible with
CMS AM; this can cause the application to experience
file/object-sharing errors from the BFS token manager for shared BFS
objects.  Disclosed is a method for modifying such an application to
make it become CMS AM-compliant so that it can use OpenEdition
services, via the use of a CMS AM "shell" which makes it unnecessary
to rewrite the application's existing tasking scheme.

   For illustration, assume that an application is a server
that has its own multitasking scheme in which a dispatcher function
controls execution of a series of tasks that perform operations on
file system objects on behalf of clients.  In the server's tasking
scheme, a task is preempted when it wants to perform a time-consuming
operation such as an I/O operation, at which time that task is made
to wait while another task is dispatched.  This scheme would work for
CMS minidisk and SFS* (Shared File System*) files, because
asynchronous interfaces exist for I/O operations in those file
systems.  BFS operations, however cannot be multitasked in this way
because there is no asynchronous BFS interface; if BFS operations are
to be multitasked, they must be multitasked using CMS AM  services.
However, the use of CMS AM services for BFS operations would cause
conflicts with the server's tasking scheme, as described in the
preceding paragraph.

   Instead of rewriting the server's tasking scheme to make
exclusive use of CMS AM for all of its operations, which could be a
formidable job, there is a way to retain the server's orginal
multitasking scheme with the addition of CMS AM services for BFS
operations only, via implementation of a CMS AM "shell".  The CMS AM
can be constructed by creating a new CMS AM thread...