Should COBOL be lockedUP for good?...
in [Cobol]
|
From: Kellie Fitton on 17 May 2005 14:33 Hi Richard, Richard Wrote: > 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, and to reply back in haste, withOut reading between the lines of the posting. here is my first posting to you from this thread: > 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? Noticed the question marks(??????????????????????????????), I was simply asking YOU a question. 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. With Micro Focus COBOL compiler, file/record locking is very simple code, here is how to deal with a lock: 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. RICHARD WROTE: > I think that you are stepping out _well_ beyond your actual knowledge. SMP and > shared memory is what happens inside _one_ machine. You cannot 'share > memory' between a file server machine and a client machine. 1). SMP is a multi-threading programming technique that is used with server box machines that has a dual micro-processors. When multiples threads are launched in an application, the operating system would allow its scheduler to manage, control and run each thread on a separate CPU automatically. 2). It is very easy to use shared memory between a file server and a client machine in a netWork environment. There are four options to select from, when trying to share memory between machines. 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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_operations.asp Regards, Kellie.
From: Richard on 17 May 2005 15:35 > Micro Focus's COBOL compiler NetExpress does handles the COMMIT and > ROLLBACK, and works like a charm in any COBOL program. One of the problems with discussing any subject with you seems to be that your naive optimism has not yet been broken by experience. You make these rash claims and have obviously not even attempted to test these. The manual entry has: """For COBOL systems that support the WITH...ROLLBACK clause of the SELECT statement as other than documentary, ...""" You seem to have missed the keywords 'systems that support'. The _one_ system is MF FileShare which is an add on package that acts as a file system server. This FileShare is obviously not what you have been talking about (Note: it is not just the compiler option 'fileshare'). 'Any COBOL program' treats COMMIT and ROLLBACK on Cobol files as "documentary". Write a simple program and demonstrate to yourself how it doesn't 'work like a charm', you might actually learn something. > the "Restart" dilemma is a very simple problem if you use COBOL > thinking mentality ... ... pure mighty COBOL. Once again your naive optimism not yet dulled by actually having to implement such a process and deal with the _actual_ problems. You seem to expect that when a WRITE is done in the program there are actual bits being reliably put onto the disk surface such that it will be available if the power should fail. This leads you to think that such a simplistic mechanism as writing out the keys as they are processed will actually give a checkpoint for a restart. There _are_ ways to allow restarts to avoid duplicate processing and without having to do a restore and rerun, but a 'key stack file' is unlikely to be one of them. The problem is that you cannot guarantee that files will be synchronised correctly. It may be that at the point of failure the key stack has been put onto the disk but the main file hasn't or vice versa. The data blocks may be in the program buffer, the client's network cache, the server's network buffer, the server disk cache or the disk drive's buffer. The order that blocks are finally written to the disk is probably using elevator seeks. The other problem that you completely fail to notice yet again is that this is all done by the programmer writing code, as they would do in most other languages. It is independent of the language used. The other problem that I find is that I fail to see why you ask questions, you obviously already know everything you are ever likely to.
From: Pete Dashwood on 18 May 2005 02:16 Hi Kellie, I read the whole of this thread and all the replies. You are receiving some EXCELLENT advice, getting it for free from people who have spent years in the real world, and, it seems to me you may be too dismissive of the points being raised. As you know, I am supportive of your "independent thought" stance and I wouldn't want to see that stifled, but you do need to test some of your ideas before you can really make claims about them. You are allowing your emotional attachment to COBOL to blind you here. (It isn't wise to do that with ANY language; it is just computer programming, not life and death or a lifetime love affair...) Both Richard and Bill (and some others) have tried to explain their reservations to you and tried to point out some of the things you need to be aware of. But it certainly looks as though your mind is already closed. That is OK (as part of a learning curve; it is NEVER OK to close your mind, really... :-)), but then, you can forgive Richard for asking why you asked the question if you already have all the answers... You may think it is fine to use the COBOL file system, but it isn't. It isn't just about relative efficiency, it is about other software having access to the data. Many years ago, right here in this forum, when I suggested that the COBOL file system should be replaced by RDBs, wherever possible, there were howls of indignation and I was seen as an anti-COBOL idiot. (I'm actually neither...but people get emotional about computer programming.) Today, people see there are real benefits in letting an established system do the work for you... The fact is that one of the nails in COBOL's coffin has been the file system. People don't want to have write a program (or have one written for them), every time access to corporate data is required. It was OK 40 years ago when there was no other option; it ISN'T OK today. It is ironic that the only thing actually "wrong" with the file system is that it is closed. As a system for data management it is excellent. But so are modern databases, and they have the advantage of handling locks, rollback, checkpoints, and all of the facilities you realised you needed (I give you full credit for that...) embedded in them and fully debugged and operational. Richard in particular has explained at some length some of the considerations with multiprocessing and multitasking and it isn't ALL to be found on MSDN (although, I agree that is an excellent resource, and use it myself). Here's some general things to consider, and I wish you every success with your system... 1. Don't let the technology you know and understand drive your requirements. Sometimes you need to put aside your technical knowledge and try to understand what is needed in plain English from a user point of view. It is all too easy to think "requirement for random access. OK that means ISAM (or VSAM or BTRIEVE or whatever your environment supports).". The tail does not wag the dog. Get the WHOLE requirement then start looking at what technology is most applicable. Do the homework and don't just use COBOL as a "one size fits all" tool. That is one step away from "Everything I want to do, I can do in COBOL". When I hear people say that, it immediately tells me they are limited in their imagination and/or in what they want to do... The BEST tools for the job. Sometimes it is COBOL; sometimes it isn't... 2. Accept that there is a knowledge base here that is worth considering. That's why you come here, right? There is nothing wrong with questioning, but maybe run a few tests, rather than rely on what you think OUGHT to be the case. (I did this recently when you suggested some alternate forms of input and validation... I'm sure you remember. The exercise was enlightening to me and there were a number of useful spin-offs. Not to mention that a number of people provided useful considerations and input. If, after 40 years of programming, I am not above employing an empirical approach when appropriate, don't you think you could too? :-) The sad fact is that what you read in the manuals (and on MSDN) is not ALWAYS true... (I know...shock! horror!). When people with the experience base of Richard Plinston and Bill Klein are giving you a heads up, it is polite to at least listen...and wise to consider what they say (I certainly do...). (If you think you are not getting a fair hearing or being understood, then do some experiments and repost.) 3. I believe you have what it takes to be a really successful problem solver. BUT, you lack experience. Accept that. It isn't a fault. Be thankful there are people here who will share THEIR experience with you (and for FREE!), just as you will in years to come... Finally, I have deliberately refrained from answering your questions, even though I have some opinions about the solutions. This is a time when you really must evaluate the answers for yourself, and consider all the opinions you have had. Best, Pete. <snip>
From: Michael Russell on 18 May 2005 15:32 Kellie Fitton wrote: >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. > > > An excellent locking mechanism? How about an excellent unlocking mechanism, as well? I think I'd drive the locking more actively than waiting for system-supplied timeouts. Anyway, why go to all that trouble when an RDBMS will handle it all properly? If you handle the rdbms nicely, of course :-) Moreover, using an rdbms lends itself to future sharing & reporting needs. Can't see the benefit of isam + Cobol for a new application myself - except it's tried & trusted - but, if that's so, how come the fuzziness about timeouts? Regards Michael
From: Richard on 18 May 2005 16:15
> 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 ? |