Browse Prior Art Database

Strategy for Retaining Command Line Options for Client Server Processes

IP.com Disclosure Number: IPCOM000109028D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 3 page(s) / 133K

Publishing Venue

IBM

Related People

Curry, SM: AUTHOR [+3]

Abstract

Disclosed are three different ways of entering command line options when client and server processes are used in an operating system and a solution for insuring that each method preserves the option values, whether they are temporary or not, in this environment.

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

Strategy for Retaining Command Line Options for Client Server Processes

       Disclosed are three different ways of entering command
line options when client and server processes are used in an
operating system and a solution for insuring that each method
preserves the option values, whether they are temporary or not, in
this environment.

      Command line flag options are commonplace for command line
programs, such as the include and define flags for a C compiler's cc
command.  In AIX*, the C compiler can also take flag values from
global variables.  Processing these flags works well when dealing
with one program running under one process; the program starts,
executes using the given flags, and then terminates.  But in the case
of two processes, such as with client and server processes, where the
client may start, run while communicating with the server, and die,
but where the server may run in the background indefinitely, the
standard method of processing flags is not adequate.  The values of
the flag options must be stored somewhere that the client and server
can access and they must be able to pass between the client and the
server.

      The database command line interface is one such application
that uses client and server processes.  User entered commands are
initiated from the client, and if they require a database connection,
they are passed to the server.  The server process maintains the
connection to the database, processes SQL commands, and passes
information back to the client.  The following examples use the
database command line program (DBM) and the option of displaying the
SQL data area (SQLDA) after a command.

      Command line options may be entered a number of ways:
      * Temporary flag options with a command, such as:
           DBM -t SELECT * FROM ORG
      With the -t flag option, the DBM command displays the SQLDA
structure for this DBM SELECT statement only. The previous default
SQLDA flag value is restored afterwards.
      * User initiated as a complete command string, such as:
           DBM SQLDA ON

      This turns the SQLDA option on, making it the new default value
until it is turned off with the DBM SQLDA OFF command string.  When
on, the SQLDA structure will be displayed after every executed DBM
command that uses the SQLDA structure.
      * Default profile value, such as:
           DBMSQLDA=OFF
           Stored in the user's DBM profile file, this value is used
as the default value until "permanently" overridden by a user-
initiated command string or temporarily changed by a flag.

      If only one client and one server process ever existed, it
would be easy to store these flag options in a global variable used
by the system, but where multiple "sessions" may exist with each
session having a client and server process, system-wide global
variables cannot be used since they may be different for each
sess...