Should COBOL be lockedUP for good?...
in [Cobol]
|
From: Richard on 17 May 2005 03:53 > 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).
From: William M. Klein on 17 May 2005 12:28 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(a)Azonic.co.nz> wrote in message news:1116316421.600466.285680(a)g47g2000cwa.googlegroups.com... >> 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). >
From: Howard Brazee on 17 May 2005 12:50 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.
From: Kellie Fitton on 17 May 2005 13:01 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.
From: William M. Klein on 17 May 2005 13:33
Kellie, As far as "restarts" goes, the COBOL Language actually HAS syntax for this. Unfortunately (for you) Micro Focus has the following statement, (Check out the I-O Control Paragraph in your LRM) "The RERUN clause is documentary only." OTOH, they were marked as "OBSOLETE" in the '85 Standard and have been removed from the '02 Standard, so I can understand "new" COBOL systems (and programmers) not being familiar with them. For many other compilers and platforms, they are an "easy" and (yet again) "built-in" way to do what you are talking about (being done via other programming devices) -- Bill Klein wmklein <at> ix.netcom.com "Kellie Fitton" <KELLIEFITTON(a)YAHOO.COM> wrote in message news:1116349290.998449.30870(a)g44g2000cwa.googlegroups.com... > 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. > |