Re: Should COBOL be lockedUP for good?...

> 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 disadvantages 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.

.

Relevant Pages

  • Re: Speed with Fujitsu Cobol
    ... One of the problems of using indexed files on a system like this is ... that the client is not just 'reading a record', ... index and transferring multiple blocks of data across the network so ... Check the level of record locks ...
    (comp.lang.cobol)
  • How to implement synchronous rpc between 2 processes on the same machine.
    ... i.e it internally maintains a pool of threads i.e the server(process ... So here is my design the i want you to kindly kindly review and give ... The client i.e p1 invokes the function, ... The server thread gets the signal, locks mutex M1 executes the called ...
    (comp.programming.threads)
  • How to implement synchronous rpc between processes on the same machine
    ... i.e it internally maintains a pool of threads i.e the server(process ... So here is my design the i want you to kindly kindly review and give ... The client i.e p1 invokes the function, ... The server thread gets the signal, locks mutex M1 executes the called ...
    (comp.unix.programmer)
  • Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read()
    ... >> On the NFS server I'm exporting an XFS filesystem to the client ... The client mounts using ... the server locks up. ...
    (Linux-Kernel)
  • Re: Locks, Scope & Performance
    ... A query that brings the server to its knees is often a sign ... Would the process you are suggesting look like a proc that calls a sub> proc ... > and creates w/recompile an inner sProc? ... >> page locks or no locks instead. ...
    (microsoft.public.sqlserver.programming)