Home > Archive > Cobol > May 2005 > Should COBOL be lockedUP for good?...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Should COBOL be lockedUP for good?...
|
|
| Kellie Fitton 2005-05-18, 8:55 pm |
| Hello EveryOne,
I am developing a softWare application for a multiUser operation
in a netWork environment, the software should facilitate dataEntry
functions, and provide capabilities for an information system
as well. Also, the program has to handle concurrent Read-Write
intensive requests, withOut any bottlenecks or performance blips.
However, I realize that shared dataFiles are indispensable in such
an environment and with such an application, and consideration
must be put forward to correctly create and design sharedFiles,
vis-a-vis fileHandling mechanism.
So, I got the source code cut out with some moot questions that
I would like to share with you, hopefully you can shed some lights
on the layOut, limits and pitfalls, when developing multiTasking
and multiUser softWare programs.
1). Should shared dataFiles use records locking schemes?
2). Should shared dataFiles use data compression mechanism?
3). Should shared dataFiles (largeSize) be split into several
smaller files?
4). Should shared dataFiles be handled by an I/O dynamically
called module per file, that service all processes running
concurrently?
5). Should shared dataFiles be handled by an I/O independent
module per file, that runs separately and communicates with
the application thru shared memory, and service all processes
running concurrently?
Regards, Kellie.
| |
| Richard 2005-05-18, 8:55 pm |
| > I think I'd drive the locking more actively than waiting for
> system-supplied timeouts.
That seems to be primarily a Windows deficiency, or at least a
deficiency of Fat Client using shared files. MS-DOS based systems were
even worse as there seemed to be no timeout at all.
Unix had no record locking mechanism until Xenix was added so compiler
systems built their own locking (or used C-ISAM's).
I mainly used DRI multiuser systems for many years, starting with MP/M
II and MF CIS Cobol + FileShare the Level II and Cobol/2 on
Concurrent-DOS. These gave OS level record locks that were reliable and
released immediately if the process stopped or crashed.
Before I moved to Linux I tested to ensure that automatic unlocking
occurred reliably and quickly. Running a small number of systems on
Windows (granted it was long ago) had demonstrated that if a client
machine is switched off or rebooted, or the 'close' tag clicked, while
it held a lock invaribly resulted in eventually having to reboot the
whole network (well at least the file server).
I don't think that 'Timeouts' are sensible. There may be good reasons
why I would want to lock a record for some hours, there are certainly
good reasons why I want all locks released immediately if the client
dies.
> Anyway, why go to all that trouble when an RDBMS will handle it all
properly?
You raise a good point. What exactly does happen on Windows if I do a
'SELECT .. FOR UPDATE' and obtain a lock and then turn simply pull the
network cable from my client machine ?
Would it remain locked awaiting my next instruction ? Would it be
polling the client machine to see if I was still there ? or would it
..... timeout ?
| |
| Richard 2005-05-18, 8:55 pm |
| Kellie, you had asserted that:
Now we find that "a well designed cobol module with a good algorithm
functions, can do the job very well as needed".
In other words you can write your own which may, or may not, be
'excellent' depending on how good the programmer is. But it is not
_COBOL_ that does this, and it may not be 'any type of file'. How well
does COBOL deal with .xls ? or .doc ? so what does 'any type of file'
actually mean ?
[color=darkred]
> My compiler (NetExpress) provide a file-sharing and an exellent
locking mechanism as a
> built-In features.
You may start to call it 'excellent' after you have demonstrated how it
behaves when, say, the client machine is powered down after having
locked some records in the server.
You may also need to demonstrate that COMMITT and ROLLBACK work as may
be expected (ie are not treated as comments) before calling it any more
than merely adequate.
> However, regarding the "Restart" mode, perhaps you can give me some
more
> information, or highlight the question?
A 'Restart' is where a program has been updating a file and the program
crashes, or otherwise fails to complete, due to, say, power fail or
data error. The 'restart' would continue processing from the failure
point or from a checkpoint a short time beforehand, thus saving having
to do a restore and rerun everything up to that point.
With DBMS systems it is relatively easy to emulate restarts using
transactions and commit. File based systems make this more complex.
You may also want to contemplate what happens when the server goes down
(bluescreens or powers down). Certain disk blocks may. or may not, have
been actually written to the disk. They may have been in the client's
network cache, or the server's disk cache or the drive's buffer. As
there is no guarantee that disk blocks are written in any specific
order an index may have been written but the record not, or vice versa.
| |
| Kellie Fitton 2005-05-18, 8:55 pm |
| 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.
| |
| HeyBub 2005-05-18, 8:55 pm |
| Kellie Fitton wrote:
>
> 1). Should shared dataFiles use records locking schemes?
Sure.
>
> 2). Should shared dataFiles use data compression mechanism?
Ummm.... Maybe. In addition to the obvious advantages/di vantages,
compressed data is impossible to debug and cannot be "read" by an external,
generic program.
>
> 3). Should shared dataFiles (largeSize) be split into several
> smaller files?
Again, maybe. What's "large?" In the best case your trading (how much)
programming and error potential for (how much) execution efficiency? Three
months of additional programming and debugging effort vs saving thirty
seconds per day probably is not worth it.
>
> 4). Should shared dataFiles be handled by an I/O dynamically
> called module per file, that service all processes running
> concurrently?
Probably not.
>
> 5). Should shared dataFiles be handled by an I/O independent
> module per file, that runs separately and communicates with
> the application thru shared memory, and service all processes
> running concurrently?
I don't know.The issue has never come up.
>
>
> Regards, Kellie.
| |
| Richard 2005-05-19, 3:55 am |
| > 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.
| |
| Kellie Fitton 2005-05-19, 3:55 am |
| 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. ;---)
| |
| Richard 2005-05-20, 3:55 pm |
| > 1). Should shared dataFiles use records locking schemes?
Absolutely. Though different techniques can be used for different
applications and different business needs.
For example in an oin-line order entry system it needs to be decided
how the 'race' for stock should be handled. If there is only a small
number of products then you cannot afford to lock the stock records
over a data-entry interaction because there will be too many clashes.
If there may be stock shortages over many different products, however,
then the stock record can be locked while the available stock is held
awaiting quantity to be entered.
You should also consider using a locking hierarchy. For example it may
be that to work on debtor's transactions every program that does so
must first lock the debtors' master record. If all correctly follow
the rule then a requirement for multiple locks (kept locks) can be
avoided.
Also ensure that you do specific UNLOCKs when finished. Typically you
may read through a section of records, such as all order lines for an
order. It is necessary to read until the order number changes, there
is a risk that the program will leave a lock on the first record of the
next order.
> 2). Should shared dataFiles use data compression mechanism?
Compression probably will use less disk space (it need not) and this
means fewer disk transfers to access a set of data which may make
processing faster.
> 3). Should shared dataFiles (largeSize) be split into several
> smaller files?
Depends on the value of 'large'. If I thought that in a few years the
data file may get to be a Gigabyte then I may consider using some
sectioning of data.
> 4). Should shared dataFiles be handled by an I/O dynamically
> called module per file, that service all processes running
> concurrently?
That depends on the architecture of the system. Are you, for example,
going to get just one 'dynamically called module' or will you actually
get an iteration of the module for each run-unit (with or without
shared code) ?
Generally you won't get a _CALLed_ routine to 'service all processes'.
Perhaps you are asking if you should have a separate 'file server'
run-unit that interacts with the programs using IPC in some way, as in
Q5.
That will depend on how you need to balance your network traffic. For
example in a networked system with the programs running on client
machines if a search is to be done by examining each record then the
_whole_ file must be sent across the network one record at a time
(plus, probably, thousands of index blocks).
If a server program runs on the file server and this does searches then
only the 'found' records are sent to the client program.
However, if the architecture of the system is centralised where all the
programs run on an 'application server' accessed via terminal systems
(eg X or putty to a Linux application or RCA clients to a TSE server)
then all disk traffic is local within the box and only screen images go
accross the network.
> 5). Should shared dataFiles be handled by an I/O independent
> module per file, that runs separately and communicates with
> the application thru shared memory, and service all processes
> running concurrently?
'Shared memory' implies that all the run-units are in one machine. In a
client-server situation you need to use IPC that is _not_ shared
memory.
| |
| Kellie Fitton 2005-05-20, 3:55 pm |
| Hi Richard,
> Absolutely. Though different techniques can be used for different
> applications and different business needs.
I would like to use a manual lock with kept locks for muliple record
locking,
however, what would happen if some records are locked, and the
workStation
experience a powerOutage of some sort? I know the operating system will
release
the records automatically, but I donn't know after how long, though?
> Compression probably will use less disk space (it need not) and this
> means fewer disk transfers to access a set of data which may make
> processing faster.
doesn't compression de-compression of the file records causes some
performance
problems or read/write operation delay?
> That depends on the architecture of the system. Are you, for
example,
> going to get just one 'dynamically called module' or will you
actually
> get an iteration of the module for each run-unit (with or without
> shared code) ?
I am trying to choose between a dynamically called or an independent
I/O module.
Dynamically speaking though, it will be an iteration of the same module
for each
runUnit within the same application. I want to run the interFace
program on a client
machine, while the application runs on the file server, so the shared
dataFiles can
be used efficiently on the netWork. Also, am looking for a way to
reduce the
network traffic to exactly one roundTrip per I/O operation, if I can do
that with my
cobol code. Do you consider that approach wise?
> 'Shared memory' implies that all the run-units are in one machine. In
a
> client-server situation you need to use IPC that is _not_ shared
> memory.
All the runUnits are in one machine for each end-user --- provided
though, the main
application will run on the file server, where the main file searching
will take place
accordingly. Doesn't that approach reduces the roundTrip delay in the
network
connections and in the dataRate transfer as well??
Regards, Kellie.
| |
| Kellie Fitton 2005-05-20, 3:55 pm |
| Hi Bill,
the functionality of BackUp, Restore and Archive does NOT need to be a
built-in
function within the COBOL language --- a well designed cobol module
with a good
algorithm functions, can do the job very well as needed. My compiler
(NetExpress)
provide a file-sharing and an exellent locking mechanism as a built-In
features.
However, regarding the "Restart" mode, perhaps you can give me some
more
information, or highlight the question?
Regards, Kellie.
| |
| Kellie Fitton 2005-05-20, 3:55 pm |
| Hi Richard,
> How do you _know_ that the locks will be released automatically?
Based on what I have read at MSDN website, the OS will eventually
release the locks
after timeOut automatically, if these locks were not Unlocked by the
process that
initiated them on the client machine.
> What is your system ? Unix/Linux ? Windows ? Windows TSE ? How
> does the client talk to the server ? teminal to TSE ? X terminal?
> tty ? SMB ? IPC ?
My system is Windows 2000 professional/Upgrading to Xp Pro, and the
client machine
will talk to the file server using SMP programming and shared memory.
> If you have "interFace program on a client" how do you start
> the server application for it? How do a dozen sever applications
> startup for a dozen clients?
The interFace program on the workStation will collect the data entry
from the end-user,
and append the new records into the indexed files on the file server
machine, the
interFace program can communicate with the main application on the file
server by
using shared memory if needed.
The main application on the file server will start automatically when
the server is
bootedUp, and polls the client machines for input messages, and
communicates with
the client machines thru shared memory as well. The main application
will simply
perform the houseKeeping tasks such as, BackUps, Restores, Archives and
rebuilding indexed files when necessary on the server machine.
Regards, Kellie.
| |
| Richard 2005-05-20, 3:55 pm |
| > It does ? How so ? What _COBOL_ features actually do this ?
> it is very easy to BackUp or Restore any indexed or text files on a
> file server machine,
> simply by using a win32 API function, case in point:
So it isn't, as you claimed, a _COBOL_ feature, you are using a Windows
API.
First this is non-portable, it only works on Windows. It also seems to
be needed to be done on the server. For some systems you would need to
make two calls, one for the data file and one for the index.
> Also, to Archive any indexed file on the file server, the cobol
> programmer would code
> a module to process some transactions files, and generate an archive
> file as the
> byProduct of that process, and copy the newly created archive files
> into the assigned
> location on the server. Very simple and highly effective process.
Well, yes, you can write a program to do most things. The point being
that you _have_ to write a program - or write additional code into a
program. That can be done in _any_ language. You claimed that "_COBOL_
does an excellent job" when it turns out that it is a programmer that
must do an 'excellent job' and this could be in _any_ language - or
using any API.
But, of course, you haven't even started to address the actual real
problems associated with backup, restore and archiving.
For example: ensuring that the file(s) are not being used when you
attempt to copy them, ensuring that a consistent and complete set is
saved away, ensuring that it is not corrupt before you bother copying
it (and thus overwriting the previous backup).
| |
| William M. Klein 2005-05-20, 3:55 pm |
| Kellie,
I won't speak for Richard, but the reason that I questioned your original
statement was that these features are "built-in" to many (most?) RDB products.
This is the difference - they are NOT built-in to COBOL file systems (although
SOME vendors provide such facilities). As Richard indicates, a programmer
certainly CAN create such code - and in many (some? most?) cases, they will do
it "well". However, the tools provided with most "production quality" database
systems (RDB - or otherwise) are heavily tested and "production quality"
*before* the COBOL application programmer needs to rely on them.
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1116316421.600466.285680@g47g2000cwa.googlegroups.com...
>
>
> So it isn't, as you claimed, a _COBOL_ feature, you are using a Windows
> API.
>
> First this is non-portable, it only works on Windows. It also seems to
> be needed to be done on the server. For some systems you would need to
> make two calls, one for the data file and one for the index.
>
>
> Well, yes, you can write a program to do most things. The point being
> that you _have_ to write a program - or write additional code into a
> program. That can be done in _any_ language. You claimed that "_COBOL_
> does an excellent job" when it turns out that it is a programmer that
> must do an 'excellent job' and this could be in _any_ language - or
> using any API.
>
> But, of course, you haven't even started to address the actual real
> problems associated with backup, restore and archiving.
>
> For example: ensuring that the file(s) are not being used when you
> attempt to copy them, ensuring that a consistent and complete set is
> saved away, ensuring that it is not corrupt before you bother copying
> it (and thus overwriting the previous backup).
>
| |
| Howard Brazee 2005-05-20, 3:55 pm |
| I thought that the big advantage that modern (library based or OO) languages
have over CoBOL is that they are flexible and don't need to rely on the original
language specs. Just add or change a new library function or object, and the
new needs are met.
That means, new languages don't need hardly anything "built in". The whole
world is part of the language. As such, it isn't easy to know what a program
does - as programs have commands that are not part of the language, but are
instead are part of the available libraries. And it does mean that the
language is constantly changing - we don't have a reliable stable, fully tested
basis that we can count on working one way.
But such stability comes at a cost. Stability and flexibility are counter to
each other, and the optimal balance between these depends upon our business
needs.
| |
| William M. Klein 2005-05-20, 3:55 pm |
| Kellie,
I think you are mixing up one implementation (probably Micro Focus) with
"COBOL" when you say,
"COBOL does an excellent job of BackUp, Restore and archive any type of
files."
COBOL, itself, has NO "backup and restore" facility and its "restart"
capabilities are limited (at best). Specific vendors have been FORCED to create
"solutions" to this serious lack. (Just as Standard COBOL - up until the '02
Standard had *no* file-sharing or record-locking - and even in the '02 Standard,
this is "processor dependent" - aka "OPTIONAL").
If one is designing an application "from scratch" - I would certainly go with a
"standard" RDB (Relational Database) system over a COBOL-only solution
any-day-of-the-w . These solutions (besides built-in "recovery" systems) also
provide built-in (or relatively common) user-interface tools that may or may NOT
be available for COBOL files.
--
Bill Klein
wmklein <at> ix.netcom.com
"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1116279557.772145.199780@g49g2000cwa.googlegroups.com...
> Hello Robert,
>
> You can lead a horse to the water, however, if you can make him float,
> you got
> something pretty good. :---))
>
> you are raising an exellent point though --- however, I think that a
> skillful
> programmer with clairvoyant thinking, and a well thought program design
> approach,
> can produce or at least emulate a large database management system
> functionality. Not to mention also, COBOL does an exellent job of
> BackUp,
> Restore and archive any type of files.
>
> Personally, I think the only weakLink in my indexed file design, is the
> actual
> indexed files per se, indexed files tend to bog down when they get very
> large in
> size, however, COBOL systems can have a workAround that issue pretty
> easy
> as Richard pointedOut above.
>
> Regards, Kellie.
>
| |
| Kellie Fitton 2005-05-20, 3:55 pm |
| Hi Richard,
Richard Wrote:
> In other words you can write your own which may, or may not, be
'excellent' depending on how good the programmer is. But it is not
_COBOL_ that does this, and it may not be 'any type of file'. How well
does COBOL deal with .xls ? or .doc ? so what does 'any type of file'
actually mean?
any type of files actual means, files that COBOL language deals with in
a business
application (indexed, relative, text), however, your are asking about
the microSoft
office EXCEL and WORD, which is very simple to use in a COBOL program,
one
can use the OLE/AUTOMATION to handle files like .XLS and .DOC.
Micro Focus has many demos examples to show how to deal with excel and
word
files in a COBOL application (word97.zip demo).
> You may also need to demonstrate that COMMITT and ROLLBACK work as
> may be expected (ie are not treated as comments)
> before calling it any more than merely adequate.
Micro Focus's COBOL compiler NetExpress does handles the COMMIT and
ROLLBACK, and works like a charm in any COBOL program.
> A 'Restart' is where a program has been updating a file and the
program crashes,
> or otherwise fails to complete, due to, say, power fail or data
error. The 'restart'
> would continue processing from the failure point or from a checkpoint
a short
> time beforehand, thus saving having to do a restore and rerun
everything up to
> that point.
> With DBMS systems it is relatively easy to emulate restarts using
> transactions and commit. File based systems make this more complex.
the "Restart" dilemma is a very simple problem if you use COBOL
thinking
mentality --- this problem was solved more than 20 years ago with a
very simple
trick, the programmers used a nested loop called softWare pipelining
with an
input/output procedure sorting routine, they also used a control file
or a stack file
if you will, during processing the transaction updates, they captures
the main
key of the record, and saved it into the stack file as a marker, if the
program
crashes, that marker in the stack file, would enable the reStarting and
continues
of the transaction process again, from the failure point or from the
checkPoint if
you will. Clever, Simple, Smart, Elegant.... pure mighty COBOL.
Regards, Kellie.
| |
| Richard 2005-05-20, 3:55 pm |
| > I would like to use a manual lock with kept locks for muliple record
locking,
> however, what would happen if some records are locked, and the
workStation
> experience a powerOutage of some sort? I know the operating system
will
release
> the records automatically, but I donn't know after how long, though?
How do you _know_ that the locks will be released automatically ?
With MS-DOS based programs using SHARE an OS based record lock was
applied to a set of bytes at an offset. If the program crashed without
releasing the locks you had to reboot to reliably release the locks.
Certainly with systems that I use (non-Microsoft) the locks are
released if the process crashes, but all programs run in the one box
(server based). If a client machine crashes or just stops then the
server simply never gets another message. Specifically it does _NOT_
get a message 'I have just crashed, please tidy up'. The server
neither knows nor cares whether the client machine is switched off or
the user has gone for an extended lunch and wants the record left
locked.
The only way that a server will know if the client died is if it polls
the machine. It may also release locks after a timeout - show where
this is in the documentation before assuming that it will.
> doesn't compression de-compression of the file records causes some
performance
> problems or read/write operation delay?
There is some small CPU time spent compressing and decompressing, but
RLL encoding is fast and easy (RLL=Run Length Limited) and isn't a
'performance problem' even if you were still using 486 machines. The
gain is saving of network time, disk transfers, head moves.
> I am trying to choose between a dynamically called or an independent
I/O module.
> Dynamically speaking though, it will be an iteration of the same
module for each
> runUnit within the same application. I want to run the interFace
program on a client
> machine, while the application runs on the file server, so the shared
dataFiles can
> be used efficiently on the netWork. Also, am looking for a way to
reduce the
> network traffic to exactly one roundTrip per I/O operation, if I can
do that with my
> cobol code.
> Do you consider that approach wise?
I don't think that you have stated a single approach yet. You appear
to want to have the server run 'file system services' for you clients
but don't know whjether it should be one run-unit or on per client.
A single 'file system server' will have to maintain its own lock list
as Cobol locks are only detectable by _another_ process. You would also
probably want this to multi-thread. It would also have to maintain
timeouts or poll the client to detect system outages for lock
releasing.
But I suspect that you are very, very far from having a finished
product and are just at the sketch-the-boxes phase. By using CALLs to
access files you can start with having these routines statically
linked, move to having them dynamic and later build IPC replacement to
export the routines to the server. That way you can _learn_ about the
advantages or divantages of each approach.
> All the runUnits are in one machine for each end-user --- provided
though, the main
> application will run on the file server, where the main file
searching will take place
> accordingly. Doesn't that approach reduces the roundTrip delay in the
network
> connections and in the dataRate transfer as well??
What is your system ? Unix/Linux ? Windows ? Windows TSE ? How does the
client talk to the server ? teminal to TSE ? X terminal ? tty ? SMB ?
IPC ?
If you have "interFace program on a client" how do you start the server
application for it ? How do a dozen sever applications startup for a
dozen clients ?
Every different system has different ways of doing it, you seem to want
to define the end point without having any steps in between.
| |
| Kellie Fitton 2005-05-20, 3:55 pm |
| Hello Robert,
You can lead a horse to the water, however, if you can make him float,
you got
something pretty good. :---))
you are raising an exellent point though --- however, I think that a
skillful
programmer with clairvoyant thinking, and a well thought program design
approach,
can produce or at least emulate a large database management system
functionality. Not to mention also, COBOL does an exellent job of
BackUp,
Restore and archive any type of files.
Personally, I think the only weakLink in my indexed file design, is the
actual
indexed files per se, indexed files tend to bog down when they get very
large in
size, however, COBOL systems can have a workAround that issue pretty
easy
as Richard pointedOut above.
Regards, Kellie.
| |
| Robert Jones 2005-05-20, 3:55 pm |
| Hello Kelly
While I agree with Richard's good advice, I would suggest that you
consider using a relational database with SQL instead of using files
for such an application. The sharing and locking processes are
arguably more comprehensive and less prone to programmer error such as
forgetting to lock, share, unlock when required. They also tend to
come with a fairly good set of management, backup and recovery
features. They also tend to scale up well, especially when the data is
eventually accessed from a variety of programs written in a variety of
languages on a variety of platforms.
I am not saying that a file system is not appropriate in your
circumstances, but that you should at least consider the database
alternative and weigh the pros and cons. For example, you may not know
how to use a database, or you have to work with pre-existing files, or
a file system might be faster, etc..
regards, Robert
| |
| Kellie Fitton 2005-05-20, 8:55 pm |
| Hi Richard,
Kellie Wrote:
> Not to mention also, COBOL does an exellent job of BackUp,
> Restore and archive any type of files.
Richard Wrote:
> It does ? How so ? What _COBOL_ features actually do this ?
it is very easy to BackUp or Restore any indexed or text files on a
file server machine,
simply by using a win32 API function, case in point:
01 SHFILEOPSTRUCT.
03 FO-hwnd PIC X(4) COMP-5 VALUE 0.
03 FO-wFunc PIC X(4) COMP-5 VALUE 0.
03 FO-pFrom POINTER value null.
03 FO-pTo POINTER value null.
03 FO-fFlags PIC X(4) COMP-5 VALUE
0.
03 FO-fAnyOperationsAborted PIC X(4) COMP-5 VALUE 0.
03 FO-hNameMappings PIC X(4) COMP-5 VALUE 0.
03 FO-lpszProgressTitle POINTER value null.
CALL WINAPI "SHFileOperationA" USING
BY REFERENCE SHFILEOPSTRUCT
RETURNING BACKUP-STATUS-CODE
END-CALL.
Also, to Archive any indexed file on the file server, the cobol
programmer would code
a module to process some transactions files, and generate an archive
file as the
byProduct of that process, and copy the newly created archive files
into the assigned
location on the server. Very simple and highly effective process.
Regards, Kellie.
|
|
|
|
|