Part 14 - Mar 15 2002

[admin]

#411 Continuing on
Expand Messages

Lynn H. Maxson
Mar 29, 2002
I realise that a significant number of subscribers to this mailing
list had rather code than communicate. Should we all adopt this
preference it would leave significant time lapses between
responses, leading to an indication of inactivity or disinterest.
That perception does little to attract more people resources to an
effort which many think will cover 3, 5, 7 or more years.

Whether you prefer vertical layering on an existing host or common
(horizontal) layering on a uK you have to code at least one OS
CPAPI (vertical layering) or two (horizontal layering). In either
case you must explore and understand two different CPAPI sets. To
assist others you need to document the results of the exploration
and the understanding gained.

Moreover you need to allay any fears, any trepidation, any
hesitation when it comes to programming an OS kernel. You must
describe it in a manner in which anyone possessive of programming
skills and understanding the documented logic can undertake the
coding of any part.

You need also not only to say "what" functions to implement, but
also "why". For example, the many argue to do away with the SIQ
(Single Input Queue) of OS/2. To do away with it means replacing
it with something else. The most common proposed replacement lies
in using multiple SIQs. For some reason, not necessarily logical,
there appears a belief in the security of numbers, the more the
better.

The problem lies in veering away from queue theory in that you can
have a SISQ (Single Input Single Queue), MISQ (Multiple Input
Single Queue), SIMQ (Single Input Multiple Queues), and a MIMQ
(Multiple Input Multiple Queues). Now OS/2 uses a SISQ. You have
only two variables: the number of inputs, the number of queues.
Once the number of either exceeds one (SISQ) the processing logic
relative to selection and scheduling gets more complicated.

The point is not to argue against such considerations but to
present an exhaustive description of each option, leaving it up to
the reader then to make his or her own choice. In this instance I
would personally stick with OS/2's existing SISQ. Why? The
problem lies with ill-behaving applications, not with the queue.

Like anything else in quality control you change the cause, not
the effect. The OS/2 SISQ is not the cause. The application is.
The cure lies in recognizing when the application misbehaves, when
no queue input processing occurs within an "acceptable" time
limit. That's the ill-behavior. That's what needs correcting,
first by terminating and removing it from from the list of active
processes. Basically this mechanism exists already in OS/2.

Thus the term SIQ commonly used in OS/2 is a misnomer for the SISQ
of queue theory. Thus the applicable queue theory itself should
be part of the documentation in order for everything the
prospective programmer needs to make a decision. He or she should
clearly understand the different ramifications of SISQ, MISQ,
SIMQ, and MIMQ. Those are the choices. There's not an infinite
number.

Thus there are a host of design decisions, each with its own set
of algorithms. You have them for any allocation scheme, e.g.
internal or external storage. You have multiple file systems
basically unknown to an application and of concern only below the
CPAPI. You have memory management. You have a scheme for
relating internal storage segments or pages to external, all of
which invisible to an application.

Best of all you have the ability to stand on the shoulders of all
who have gone before you whose perfections and blemishes are a
matter of record. You basically have no new ground to cover, only
to make sure you have enough ground cover to make a decision on
what cover you want for what ground. Then only to insure that the
covers, the mapping chosen, fits seamlessly at the edges (the
interfaces).

An operating system poses challenges, but far less so than say an
application to solve the traveling salesman problem. There are
many such applications more complex and complicated than any
operating system. I say this to encourage more people to
participate in the design and coding necessary to support the
CPAPI, the actual OS personality.

While we may not make our journey shorter we can certainly make it
less so for those who come after us.

[admin]

#412 A slight correction
Expand Messages

Lynn H. Maxson
Mar 29, 2002
Before anyone takes me to task for my liberties with queueing
theory lets just say that a "server" has an "input" queue. The
only options are SISS (Single Input Single Server), MISS (Multiple
Input Single Server), SIMS (Single Input Multiple Servers), and
MIMS (Multiple Input Multiple Servers). The inputs which is where
the queueing takes place allow three options: FIFO (First In First
Out), LIFO (Last In First Out), and Ordered (in other than FIFO
and LIFO).

The SIQ (Single Input Queue), the input side itself is FIFO based.
In theory it can be of indefinite, if not infinite, length. In
practice it is limited by the amount of real and virtual memory
available. The problem with respect to overall performance of
OS/2 lies at the rate at which the "server" processes the queue,
i.e. takes the next entry from it. The "best" overall performance
occurs when the server processes the input on average as fast as
it arrives, i.e. no more than one entry in the input queue.

If it is not possible to process the entries at their arrival
rate, then some lesser rate need exist. The original OS/2 problem
arose when that rate went to zero, i.e. the server stopped
processing the input due to an ill-behaved process. The result
was to pick a "by guess and by golly" interval, say 100
milliseconds, as an acceptable processing rate. If the
application does not take the next input entry in that interval,
then to consider it as a candidate for termination, allowing the
scheduling of the next process in line.

By consideration here means that an independent "observer" process
exists not constrained, not dependent upon the SIQ. The user
through that observer process can opt to terminate or not the
ill-behaved process. This observer process currently exists as an
add-on utility like System Commander initiated by something like
the C-A-D key sequence.

Nothing dictates that the observer process cannot be a separate OS
personality whose function it is to oversee, schedule, and control
the other OS personalities. If it too using an SIQ (which it
should), the only requirement is to make sure that it cannot
become ill-behaved in turn. This observer process is quite
similar in function to the CP (Control Program) of IBM's VM
operating system.

[admin]

#413 For the group...
Expand Messages

hitureas
Mar 29, 2002
Here is a place you can find lots of good deals on credit cards. I
have the worst credit and I was approved!

Click on link Below!

http://apply4creditcard.com

[admin]

#414 Point of contention
Expand Messages

Lynn H. Maxson
Mar 29, 2002
From the moment I heard about the SIQ problem of OS/2 I knew it
wasn't "the" problem. There are no other kind of queues: all
queues are single input queues. It couldn't be a problem because
it was never an option: no other choice is possible.

You could have multiple (single) input queues, but that wouldn't
solve anything as it is a "server" not a "queue" failure. Having
multiple input queues into a single "failing" server differs not
one whit from a single input queue into a single server (SQSS).

You could go to a single queue single server (SQSS) to a single
queue multiple server (SQMS), but in a single processor system in
which only one process at a time can be executing, i.e. not a
multi-processor or -processing system, the same ill-behaved
process would have to be scheduled at each server. That really
makes no sense, not even in a multi-threading process.

So those who would go to correct the so-called SIQ problem of OS/2
in fact have no where to go. Again it is not a queue (or
queueing) problem. It is a server (or queue processor) problem.
The name SIQ does not relate to nor is any part of the problem.

The solution lies in regulating the server processing, insuring
that it is processing queue entries in a "timely" manner. The
solution provided in OS/2 lies in choosing an reasonable interval
of inactivity (no queue processing occurs) from which a choice to
terminate the process exists. This says basically that an
application as a server process must insure queue processing
within this interval.

Nominally this affects only process-bound applications not
invoking system functions, e.g. locked in an internal loop.

If anyone wants to propose anything other than the SQSS (Single
Queue Single Server) used by OS/2, either MQSS, SQMS, or MQMS,
then they will have to describe how "events" are assigned to
queues (if multiple) or how processes are assigned to servers or
how servers are assigned to queues.

The point here is to document these options, provide the
scheduling algorithms, and not mislead people by using a reference
to a "SIQ problem" which does not exist or at the very least
misleading.

[admin]

#415 More on queueing
Expand Messages

Lynn H. Maxson
Mar 30, 2002
No sense in leaving queueing theory too early. There's equally no
sense in not having formal queue objects. Queues are simply too
common in programming. Let's ease the task of creating and
processing of queues.

As a queue is a set of 0, 1, or more entries we can declare a
queue as LIFO, FIFO, or ORDERED with a range of possible entry
types, generic or specific. For example, "DCL STACK QUEUE LIFO
ENTRY (FIXED BIN (31));" states that a variable named STACK is a
LIFO queue each entry of which must be a 32-bit signed integer, a
generic entry.

Now we have several overlapping choices for programming queue
processing. We can use GET and PUT, PUSH and POP (PULL), or READ,
WRITE, and UPDATE (REWRITE). As in object-oriented methodology
the object, in this instance a queue, has some say over what
methods may be used to access it. We could therefore redeclare
STACK as 'dcl stack queue lifo entry (fixed bin(31)) methods
(push, pop);'. We have now given a full object description
containing data and methods.

This says that somewhere else a description (specification) for
push and pop exists. We don't have to engage in either the class
systems of OO or depend upon inheritance as both the data and the
rules exist within the declaration. We could further specify the
range of values that the entries could have, e.g. 'dcl stack queue
lifo entry (fixed bin(31)) methods (push, pop) range
(0...16384);'.

Herein you have the beauty of logic programming based on the
declaration of rules. The responsibility for the enforcement of
the rules lies on the software not on programmers. Such rules in
something like an operating system run into the thousands. Having
the software enforce the rules means, one, that it can notify a
programmer when his code violates the rules (a form of
instantaneous peer review), or, two, write the necessary enforcing
code, e.g. checking the value range prior to assignment, thus
saving programming effort as well as a possible memory failure
(incomplete and thus incorrect coding).

Eventually queues themselves decompose into lists, objects with 0,
1, or more entries. Entries in a list are either contiguous or
they are not: the entries form a linked list. The linkage is
either single (next entry only or null) or double (previous and
next entry either of which (or both) may be null).

List themselves get somewhat more complicated in that they may
have associations with other lists as "child" or "parent". A list
may have 0, 1, or more child lists with either single (child
first) or double (child first, child last) links. These
complications lead to increasing interconnections. The more
interconnections the more complex.

Thus the more lists involved the more complicated the processing.
The more associations (interconnections) involved the more
complex. Thus you may have a complicated situation due to the
number involved but not complex due to the lack of interconnection
among the number. Complicated is related to absolute number of
entries;complex, to their interconnnections.

As fundamental as queues are they are not as fundamental as lists.
Along with the requirement to support 0, 1, or more entries,
wherein queues and lists function identically, a queue's entries
are always logically contiguous. Whether a queue's entries are
physically contiguous or not depends upon the underlying list
structure: either linked or not.

Procedural languages which do not have queues as native data types
force the programmer to define it in an alternative manner, force
the programmer to process it in a defined manner, and force the
programmer to enforce the rules governing its behavior. Now
that's a lot of programming. If at some time you make a decision
to change the underlying physical order, e.g. from contiguous to
non-contiguous (linked list entries), all associated logic must be
changed as well.

The alternative lies in having a queue as a native data type and
having it as well as the rules governing its behavior (type (LIFO,
FIFO, ORDERED), methods, range, etc.) as part of its declaration.
This leaves it up to the software to enforce the rules. The only
(manual) programming change which needs to take place regardless
of the number of use instances elsewhere lies in the single
declaration statement. After that point it becomes the
responsibility of the software to reflect the necessary changes in
processing.

Others may find C plus some assembler sufficient for writing an
operating system. We have just covered a few of the reasons why
such an effort requires the ongoing participation of hundreds and
thousands of others. If you don't have that number which is both
complicated and complex (requiring ever more time dedicated to
inter-communication, an inter-connection otherwise known as a
meeting<g>), then you might be more interested in working
"smarter" instead of "harder".

[admin]

#416 We need help with webpage !
Expand Messages

JMA
Mar 31, 2002
Hi all !

The webpage (www.osfree.org) needs your help !

While I can produce the texts for the site i urgently
need help to add the texts and do graphics.

Anyone who feels he/she has time and knowledge
please contact me !




Sincerely

JMA
Development and Consulting

John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================

[admin]

#417 A little SL/I
Expand Messages

Lynn H. Maxson
Apr 5, 2002
Frank Griffin makes a valid point about the need for examples. I
don't wish to frighten non-programmers, but I would like to break
the barriers to a deeper understanding of logic programming
(programming in logic) and the advantages it offers over
procedural (logic in programming). To do that I want to return to
the earlier beetles, spiders, and legs problem expressed in
textbook manner in a normalized form as 6B + 8S - L = 0.

There are three variables (B, S, and L). In procedural languages
we have the assignment or replacement statement normally
represented by the equal (=) operator where the variable on the
left-hand side is replaced by the evaluation of the expression on
the right-hand side. This means that procedural languages only
support solving expressions with one unknown, i.e. either B or S
or L. Thus the following choices are available:
B = ((8*S)-L)/6; /* for number of beetles */
S = ((6*B)-L)/8; /* for number of spiders */
L = (8*S) + (6*B); /* for number of legs */

Suppose, however, that you are only given the number of legs (one
known) and have to solve for the number of beetles and spiders
(two unknowns). You have no means of expressing this in in a
single assignment statement in procedural languages. Instead you
must solve for each unknown variable (B and S) separately, which
we will now illustrate.

We have to determine the limits of possible values. For N legs we
can have no more than floor(L/6) beetles and floor(L/8) spiders.
Here the floor builtin function guarantees an integer result as we
assume every spider and beetle comes with a complete complement of
legs. Thus for a leg count L of 46 we know that we can not have
more than 7 beetles (floor(46/6)) and 5 spiders (floor(46/8).
This establishes the upper limit on possible values. As it is
possible that an evaluation can contain only spiders or only
beetles this means that each has a lower limit of zero.

To express all this in procedural terms we need to calculate two
variables establishing the upper limits for both B and S:

L = 46; /* number of legs */
Y = floor(L/6); /* upper limit for beetles */
Z = floor(L/8); /* upper limit for spiders */

We now must iterate through all the possibilities until we get one
answer. In procedural languages this is done with a "do"
statement which in our case basically looks like this using
indentation to show nesting of "do" loops:
do B = 0 to Y;
do S = 0 to Z;
end;
end;

Now we need to insert the test to see if a particular combination
of B and S equals L. Not by chance this occurs in an "if"
statement which we will insert in the nested do loop.

L = 46; /* number of legs */
Y = floor(N/6); /* upper limit for beetles */
Z = floor(N/8); /* upper limit for spiders */
do B = 0 to Y;
do S = 0 to Z;
if (L = ((6*B) + (8*S)))
then
put list (B, S) skip;
end;
end;

Now this will display (put list(B, S) skip;) any concurrent values
of B and S on a new line. In this instance two such "doublets"
will occur, (B = 5 and S = 2) and (B = 1 and S = 5). So we will
have two lines of output. The same thing logically which occurs
when you execute an SQL query.

Now in logic programming we would simply ask for a list of the set
of unknowns, which in this instance of two unknowns we would
designate as (B,S) and request in an assignment statement as
'(B,S) = ((6*B) + (8*S)) - L;' Now if we have declared B, S, and
L as 'dcl (B,S,L) fixed bin (15) range(0...100) we could actually
write '(B,S,L) = ((6*B) + (8*S)) - L;' and receive as a result the
set of all triplets (B,S,L) satisfying the expression.

Now we could have done this in a procedural language an outer loop
for L and nesting within it our two previous loops for B and S.

L = 100; /* upper limit on legs */
Y = L/6; /* upper limit on beetles */
Z = L/8; /* upper limit on spiders */
do L = 1 to 100;
do B = 0 to Y;
do S = 0 to Z;
if L = (6*B) + (8*S)
then
put list (L, B, S) skip;
end;
end;
end;

Here we have chosen to display our results as we do in SQL. Note
that we could leave the right-hand side of our expression alone as
'((6*B) + (8*S)) - L' and in the left-hand side as for solutions
in terms of one unknown (singlet), two unknowns (doublet), and
three unknowns (triplet)
(L) = ((6*B) + (8*S)) - L;
(B) = ((6*B) + (8*S)) - L;
(S) = ((6*B) + (8*S)) - L;
(L,B) = ((6*B) + (8*S)) - L;
(L,S) = ((6*B) + (8*S)) - L;
(B,S) = ((6*B) + (8*S)) - L;
(L,B,S) = ((6*B) + (8*S)) - L:

And, if fact, we could have written this as
0 = ((6*B) + (8*S)) - L;, leaving it up the expression evaluator
to determine from the variables themselves whether to solve for
zero (true or false only), one, two, or three unknowns. It might
even be a lot nicer if you could write this as '0 = 6B + 8S - L;',
making it easier for the casual reader to understand the
expression not knowing that the * by common convention in
programming languages represents the multiplication operator.

Now the reason for putting parenthesis around the variables in the
left-hand side is to show that it is a list result. One of the
possible list results is the empty or null list, which in logic
programming terms (thus in SQL) means that the assertion on the
right-hand side is false, i.e. no true instances exist. Otherwise
the result is one or more true instances.

Procedural languages support element and aggregate variables.
They support two forms of aggregate variables, homogeneous
(vectors, arrays, etc.) and heterogeneous (structures) as well as
combinations of the two. Missing in this is another aggregate,
the list. This was first introduced as a data type in LISP. LISP
is a procedural language in which lists are a native data type,
something which in general is not true for other procedural
languages.

The most obvious example of this absence occurs when a procedural
language program, say C or PL/I, has to process an SQL query. An
SQL query produces a list of 0, 1, or more true instances.
Procedural languages (other than LISP) have no means of operating
on lists. That means you cannot have a list as an operand, e.g.
in an expression like 'a = b + c;', a, b, and c cannot be lists.
In C, C++, and JAVA they must be element variables only, while in
PL/I and APL they can also be any form of an aggregate (just not a
list).

Now logic programming relies on a two-stage proof engine. The
first stage is a completeness proof in which it creates the
necessary procedural logic. It can either do this, i.e. complete,
(true) or not (false). If true, it goes on to the second stage,
one of exhaustive true/false testing. If it cannot find a true
instance, it returns 'false' (an empty list), otherwise a list of
all true instances (1 or more). Thus the result of an assertion
which is either true or false is a list of 0, 1, or more entries.

So our '(B,S) = ((6*B) + (8*S)) - L;' has no simple (single
expression) equivalent in a procedural language, which is further
limited by the fact that it can accept a null value for a
variable, but not a "no" value, a null variable. Clearly, as LISP
has indicated for over 40 years now, such is a possibility.

So SL/I adds an assertion as a processing statement to PL/I. To
do so it must add a list as a native data type. In addition it
must allow a list to appear as an operand in an expression. Thus
SL/I operators (+, -, *, /, etc.) will accept lists as operands.
As Prolog only allows assertions I have chosen to fold its
functionality into SL/I. Thus in SL/I I can write the assignment
statements, the iterative do loops, etc. necessary for the
conversion of assertions into procedural logic and from there into
the instructional logic of a given machine (code generation).

In PL/I you cannot do assertions (other than the restricted forms
implied by the assignment statment) and in Prolog you cannot do
assignments (always true, one and only one expression value). You
need both, the assertion to reduce the amount of writing
necessary, and the assignment as that basically is the
instructional architecture of all von Neumann machines. If you
have both present, then you do not need to write one in whole or
in part in the language of another, e.g. Prolog using C, LISP or
assembly language.

In short you have a complete language, complete in data types
(operands), complete in operators, and complete in expression
capability (assertion and assignment). Otherwise it looks like
PL/I.<g>

[admin]

#418 [osfree] CVS is up !
Expand Messages

JMA
Apr 5, 2002
Hi all !

The CVS repository for osfree is up at last.

The address is osfree@...:d:/project

Do a
SET CVSROOT=:pserver:osfree@...:d:/project
to get there.

The password is: readonly

There is not much there yet but now its possible for developers
to put their stuff somewhere.

To do a readonly checkout do the following:

SET CVSROOT=:pserver:osfree@...:d:/project
cvs login
cvs checkout osfree/src

If you as a developer would like to participate and thus need a
read/write password please contact me.


PS: Webpage is soon to be updated.




Sincerely

JMA
Development and Consulting

John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================

[admin]

#419 support for pm (/P) mode
Expand Messages

Bartosz Tomasik (Bart/2)
Apr 7, 2002
Hello
shall we support /p mode (for command line tools- to be run as a backend for PM
based tools)?
-------------------------------------------------
Bart/2 irc:Ihsahn Bart2@... UIN:50890586
Asu'a Programmers Group http://www.asua.org.pl
TeamOS/2 Polska http://www.teamos2.org.pl

[admin]

#420 Re: [osFree] support for pm (/P) mode
Expand Messages

JMA
Apr 7, 2002
On Sun, 07 Apr 2002 17:42:46 +0200 (CDT), Bartosz Tomasik (Bart/2) wrote:

>Hello
> shall we support /p mode (for command line tools- to be run as a backend for PM
>based tools)?
>

Since we have the source to the PM tools

Yes !



Sincerely

JMA
Development and Consulting

John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================