Prev: JCL Builder or script HELP
Next: Need sanity check on return from EZASOKET call
From: Kellie Fitton on 18 May 2005 17:59
Hi Pete,

My sainted mother said:

"The secret of walking on water is not watching your feet.".

Personally, I don't have any negative feeling regarding the use of
dataBase's file
system. I never said in this thread that we should destroy, vanquish,
annihilate
or even ostracize every dataBase management system.

Nonetheless, you are raising a superb point regarding COBOL's file
system
(indexed, relative, sequential), as opposed to the dataBase's file
system (tables),
which I think is a matter of debate, simply because, just because
someOne thinks
that COBOL's file system is not suitable or practical in a multiUser
softWare
application, is no reason to become doctrinaire.

Access to corporate data or informations is an essential part of
information system
technologies, and I am very aware of that fact. As a matter of fact, I
have developed
a COBOL module that I called SnapShot, which functions as an automatic
dataLink to all the files in the multiUser application -- if a user
request a copy of
a file (table to you), the module will ensure that all files that
correlates to the
requested file, will also be generated and copied in plain Text
formats, flat files are
very universal and can be used to alleviate concerns for data access.

Records Locking schemes can be considered a mineField by many skillfull
professional programmers, and some of them will not attempt to use
locks, unless
they are dealing with multiple file servers in a complex netWork
configuration.
however, if I decide to use locking schemes in my softWare programs, my
personal
choice will be to use a record version number, along with a
Date-And-Time stamp,
shared memory and the win32 APIs CreateFileMapping(),
OpenFileMapping(),
MapViewOfFile().

The rollBack command in a dataBase management system simply will undo,
any
changes made to the database by the current transaction on the current
connection, nothing too fancy about this function at all --- I will
create a recover
cobol module that can assists the end-user, to Undo the changes or any
faux pas
they made to a record, in the current session or even later on after
they have
closed the file. I really think the rollBack function should be dynamic
as well as
permanent if it needs to be.

COBOL was declared dead about 40 years ago, put in a coffin, publicly
viewed in
a church and then cremated, when the programming language PL/1 (NPL)
was
introduced in the U.S.A. One can ask, where is PL/1 today?

I am maybe young, crazy, inexperienced and certainly non-conformist ---
however,
my philosophy in life is very simple: Never Follow.

Regards, Kellie.

From: Richard on 18 May 2005 19:54
>> How would you set the timeout ? How long is 'eventually' ? and is it
within the
>> needs of the business ? If 'eventually' is half an hour do all the
users go to a tea
>> break if this is on a control record that is frequently used ?

> Its very obvious that you don't read my Replies Carefully, nor
understand what I am
> trying to say to you, you simply jump into a conclusion to create
your own context,

That particular set of questions were those that _you_ would need to
ask yourself before relying on a locking mechanism that timed out. The
context is _your_ systems and _your_ needs. Once _you_ determine the
answer to those questions then you can start making sensible choices
about whether to use locking or not.

> and to reply back in haste, withOut reading between the lines of the
posting.
> here is my first posting to you from this thread:

> Noticed the question marks(??????????????????????????????),

And did you notice mine ? You often seem to turn any discussion into a
conflict.

> I was simply asking YOU a question.

Yes, and seem to be expecting an answer without supplying any
information that it can be based on. You need to supply your own
answers and you need information and experience to then make a
judgement about what mechanisms are suitable or how to deal with what
is unsuitable.

> I never said this is my solution to a record lock.
> I never said this is my program coding to deal with a lock.
> I never said this is my handling routine of a record lock.

No. You asked whether you should and I was giving some feedback on what
additional data you needed in order to be able to make a decision for
yourself. You don't seem to want to deal with such issues.

> With Micro Focus COBOL compiler, file/record locking is very simple
> code, here is how to deal with a lock:

I have been using MF Cobol locking for a couple of decades or more.

> in a manual mode:
> 1). read with a lock
> 2). re-write the record
> 3). use COMMIT or UNLOCK to release the lock.
> 4). the automatic mode can release the lock automatically,
> after re-write, delete, or close file. Voila, done.

COMMIT only works on systems that support it. With MF this effectively
means the add-on FileShare product. If you don't have this then COMMIT
is documentary.

Your summary is, of course, overly simplistic. You are merely
describing the syntax as 'very simple code'. Your code also needs to
deal with the actual complications which include detecting and dealing
with locks held by other users, detecting deadlocks, and especially
designing a system which avoids deadlocks.

> 1). SMP is a multi-threading programming technique ...

Regardless of whether your summary of SMP is acurate or not, you seem
to be trying to avoid noticing that it has nothing to do with
communicating with a client machine (as you had claimed).

> a). Here is my favorite IPC option:
> Create an indexed file on the file server as a stack file.
> Let the client machine write some data into the stack file.
> Let the file server read the data from the stack file.
> Clever, Simple, Smart, Elegant.... pure might COBOL.
> Now, here is the other three options for shared memory (IPC):
> b). MailSlots
> c). Named Pipes
> d). Sockets

_None_ of which are "shared memory".

'a)' is not even an 'IPC' mechanism. 'a)' is also in direct conflict
to what you were wanting to do which was to have a file handler in the
server. Now you propose read/writing directly to a file to communicate
with a server program that will do the file read/write for you.

_None_ are related to Cobol at all and can as easily be done (if not
more so) in almost any language.

>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/...

Which does not have the word 'memory' at all, nor do its sub-pages.
These are all _NOT_ "shared memory". The term refers to a mechanism
where two or more processes or threads inside one machine use pointers
to one block of memory (RAM) to communicate.

> nor understand what I am trying to say to you,

I don't think that many understand that. You asked some questions and
have subsequently merely argued that all the people answering were
wrong and have used well defined terms in misleading and completely
incompetent ways, rejecting suggestions that you actually try things
out.

From: Richard on 18 May 2005 20:10
> My sainted mother said:

> "The secret of walking on water is not watching your feet.".

It avoids noticing that it is not working and thus having to admit
failure, if only to yourself.

> I never said in this thread that we should destroy, vanquish,
annihilate
> or even ostracize every dataBase management system.

Strawman. No one said that you had. You had been quite dismissive
though.

> just because someOne thinks that COBOL's file system is not suitable
or practical
> in a multiUser softWare application, is no reason to become
doctrinaire.

Strawman, no one had said that.

> I have developed a COBOL module that I called SnapShot, which
functions as an
> automatic dataLink to all the files in the multiUser application --

Presumably, based on your earlier claims, hand coded to recognise all
the links for a particular set of files.

> flat files are very universal and can be used to alleviate concerns
for data access.

Flat files are often meaningless. They need descriptions of what the
data items mean and some mechanism for sifting out the required
information. Usually this means loading them into something that can
manipulate the data, such as a database.

> Records Locking schemes can be considered a mineField by many
skillfull
> professional programmers, and some of them will not attempt to use
locks, ...

Complete nonsense, provide references.

> if I decide to use locking schemes in my softWare programs, my
personal
> choice will be to use a record version number, along with a
Date-And-Time stamp,
> shared memory and the win32 APIs CreateFileMapping(),
> OpenFileMapping(), MapViewOfFile().

Great. Now why did you bother asking questions here ?

> I will create a recover cobol module that can assists the end-user,
to Undo the
> changes or any faux pas they made to a record, in the current session
or even later
> on after they have closed the file

You've never actually written a multiuser system have you, I can tell.

Still, as long as you already have all the answers I am sure that will
have the success that you deserve.

From: Kellie Fitton on 18 May 2005 22:34
Hi Michael Russell,

> An excellent locking mechanism? How about an excellent
> unlocking mechanism, as well?

If I understand your question correctly, locking and unclocking with
Micro Focus's
COBOL compiler (Net Express), is pretty much descriptive code -- read
with lock,
unClock file-name {record}.

> Anyway, why go to all that trouble when an RDBMS will handle
> it all properly?

Well, just like you said in your reply: the benefit of Isam + COBOL is
tried & trusted.
great, this is music to my ears.

> but, if that's so, how come the fuzziness about timeouts?

according to the manual of Micro Focus, locking and unLocking in a
netWork
environment, is operating system dependent, and requires the support of
the low-level
interrupt h"21" and function h"5C" jointly, even the maximum number of
locks that
the application can acquire, is determined by the OS per se. I am
guessing you might
need to downLoad some service packs, fix patches or some upDates for
your OS.

Regards, Kellie. ;---)

First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: JCL Builder or script HELP
Next: Need sanity check on return from EZASOKET call