Browse Prior Art Database

Two Techniques for Versioning Callable Services

IP.com Disclosure Number: IPCOM000103876D
Original Publication Date: 1993-Feb-01
Included in the Prior Art Database: 2005-Mar-18
Document File: 6 page(s) / 159K

Publishing Venue

IBM

Related People

Cierech, T: AUTHOR [+4]

Abstract

Disclosed is a method for defining new versions of callable services using long internal names that allows strong type checking to be used to check the parameter list at compile time. It also allows meaningful names to be used to name different versions of the same callable service.

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

Two Techniques for Versioning Callable Services

      Disclosed is a method for defining new versions of callable
services using long internal names that allows strong type checking
to be used to check the parameter list at compile time.  It also
allows meaningful names to be used to name different versions of the
same callable service.

      A new calling interface and conditional parameter lists for
high level languages are also disclosed that allow strong type
checking for parameter lists and one name for all versions of the
same callable service.

Method 1: Using Long Names To Version Callable Services

      This method of defining new versions of callable services
allows strong type checking to be used to check parameter list at
compile time.  It also allows meaningful names to be used to name
different versions of the same callable service.

      When the number of parameters for a callable service is
changed, a common method to ensure compatibility is to have a version
parameter in the parameter list.

      For example, suppose that in release 1 there is a callable
service, READFILE, with the following interface:

      READFILE (VERSION, FILENAME, LETTER)
which reads a character from a file identified with FILENAME into the
variable LETTER.  In the second release, because of user requirement,
a return code is added to the interface.  Thus the callable service
interface will look like:

      READFILE (VERSION, FILENAME, LETTER, RETURN CODE)

      By assigning different value for the version parameter before
calling the service, the service can determine what and how many
parameters should be expected by checking the version parameter.
However, this checking is done at run time.  Therefore, high level
languages programs cannot use the strong typing feature provided by
the languages to check their parameters at compile time.

      The following technique was developed using the long internal
name feature of the high level languages to version callable
services:

      In the following PL/I example, release n (n=1) of the callable
service READFILE is specified by the following declarations:

      NOTE:  Similar examples can be constructed in FORTRAN, C, and
COBOL.

DECLARE
     READFILE VERSION 01 ENTRY EXTERNAL AS ("READFILE");
DECLARE
     READFILE VERSION 01 parameter list for release 1);

DECLARE
     READFILE VERSION 02 ENTRY EXTERNAL AS ("READFIL2");
DECLARE
     READFILE VERSION 02 (parameter list for release 2);
     ...
DECLARE
     READFILE VERSION On ENTRY EXTERNAL AS ("READFILn");
DECLARE
     READFILE VERSION On (parameter list for release n);

      There will be a separate entry point for each READFILk (k =
1,....,n).

      With this technique, each version of the callable service will
be treated as a different call by the compiler, and each version has
its own parameter list.  With this approach, the strong typing
feature of most...