Should COBOL be lockedUP for good?...
in [Cobol]
|
From: Richard on 16 May 2005 19:38 Kellie, you had asserted that: >> COBOL does an exellent job of BackUp, >> Restore and archive any type of files. 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 ? > 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.
From: HeyBub on 16 May 2005 20:13 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/disadvantages, 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.
From: Kellie Fitton on 16 May 2005 22:50 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.
From: Richard on 17 May 2005 00:26 > 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. 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 ? > and the client machine will talk to the file server using > SMP programming and shared memory. 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.
From: Kellie Fitton on 17 May 2005 03:23
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. |