Conversion of data & associated logic from ISAM to RDB
in [Cobol]
|
Prev: How would you do this?
Next: COBOL dynamic allocation (putenv) of output-file won't release extra space when closed
From: Anonymous on 13 Apr 2007 10:17 In article <131uoo31usaadf7(a)corp.supernews.com>, Rick Smith <ricksmith(a)mfi.net> wrote: > ><docdwarf(a)panix.com> wrote in message news:evleq8$o9j$1(a)reader2.panix.com... >> In article <131sb8b2f0atpc7(a)corp.supernews.com>, >> Rick Smith <ricksmith(a)mfi.net> wrote: [snip] >> >< http://www.microfocusworld.com/track_page.php?id=5 > >> >"A partner will present a session that shows how a relational >> >database can be used with a COBOL application using >> >standard COBOL I/O statements, WITHOUT any changes >> >to the code!" >> > >> >Perhaps the best is no conversion, at all! Just upgrade to the >> >latest technology. >> >> Mr Smith, come now... an organisation where the analyst recommends >> timestamping records... errrr, rows in a database and the manager has to >> turn to the UseNet for help will not, in my experience, embrace a solution >> which requires Spending Money to upgrade technology or sending someone of >> sufficient technical competence to benefit from the experience - as >> opposed to, say, a Corner-Office Idiot - to the Royal Pacific Resort in >> Orlando, FL, USA for three days. > >Apart from your alleged experience, this latest >technology would reasonably permit one to identify >"rows in a database" as records since there would >be no difference with respect to a COBOL program, >where the concept "records in a file" is common. Mr Smith, I am not sure what you are calling 'a COBOL program' here. According to the last version of the COBOL Language Reference I consulted (<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/FRAMESET/IGY3LR10/CCONTENTS?DT=20020920180651> or thereabouts) there are Reserved Words for file and record access; where are you finding the ones which allow 'a COBOL program' to address a database? ('Reasonable' might be in the mind of the beholder, of course; a fuel injector might be the same with respect to an automobile as a carburetor... errr, carburettor... oh, such things make me tyred... anyhow, the two devices might be the same in that they both assist in supplying the engine with air/fuel mixtures; it may be that 'a rose, by any other name', has a different place in poetry than it could in a technically-oriented workplace.) DD
From: Howard Brazee on 13 Apr 2007 10:20 On Fri, 13 Apr 2007 22:58:13 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >Really? By what strange definition of "competence" does a person standing >in a field, decide that his current location is at co-ordinates that are >several hundred miles off-shore in the Atlantic Ocean? Standing in a field is one thing. Outstanding in a field is something else.
From: Alistair on 13 Apr 2007 12:00 On 13 Apr, 11:58, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > "Alistair" <alist...(a)ld50macca.demon.co.uk> wrote in message > > news:1176405267.687547.144160(a)q75g2000hsh.googlegroups.com... > > > > > > > On 10 Apr, 00:39, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> > > wrote: > >> <docdw...(a)panix.com> wrote in messagenews: > >> > You might have checked other things as well... there's an Olde Joke you > >> > might have stumbled across, say, at > >> >http://www.dotnetspider.com/fun/Computer-Joke-838.aspx. > > >> Not sure what the point is here... we have a patently incompetent > >> programmer, and a patently stupid Project Manager, neither of whom have > >> any > >> responsibility for their actions. > > >> As they are both idiots, whatever their interaction is, it is of little > >> consequence. For this joke to work, it would be necessary to identify > >> with > >> one or other of the parties. This requires us to assume the same mantle > >> of > >> idiocy that they both display. > > >> Ah, now I see why SOME might find it amusing... :-) > > >> Pete > > > I have to take issue with your description of the Programmer as being > > incompetent; he clearly answered the question posed in the most > > accurate fashion possible, volunteering more information than is > > strictly necessary. > > Really? By what strange definition of "competence" does a person standing > in a field, decide that his current location is at co-ordinates that are > several hundred miles off-shore in the Atlantic Ocean? > > If this is your idea of the "most accurate fashion possible" I can > understand how getting a job may be ..... difficult. > > > I wonder if there is a certain note of > > defensiveness in your response? > > I wonder if there is a certain note of attempting to stir things in yours? > > > I do, however, agree that the project manager is clearly incompetent > > (at ballooning, at boy-scout preparation, at map-reading, at eliciting > > information?). > > Yes, on that we can agree. > > Pete According to my map reading skills he would have been standing on the Sohm Plain, probably at a depth of around 1000 feet. I give you that his GPS (if he had one) was somewhat out of true but then there is no field at that location so the joke needs to be updated. So that still leaves the PM at 300% more incompetent than the Programmer. And YES, I was stirring it a bit, but I have noticed a certain tendency on your part to blame programmers before managers for project ills and skills shortages.
From: Rick Smith on 13 Apr 2007 13:03 <docdwarf(a)panix.com> wrote in message news:evo3dn$o4d$1(a)reader2.panix.com... > In article <131uoo31usaadf7(a)corp.supernews.com>, > Rick Smith <ricksmith(a)mfi.net> wrote: > > > ><docdwarf(a)panix.com> wrote in message news:evleq8$o9j$1(a)reader2.panix.com... > >> In article <131sb8b2f0atpc7(a)corp.supernews.com>, > >> Rick Smith <ricksmith(a)mfi.net> wrote: > > [snip] > > >> >< http://www.microfocusworld.com/track_page.php?id=5 > > >> >"A partner will present a session that shows how a relational > >> >database can be used with a COBOL application using > >> >standard COBOL I/O statements, WITHOUT any changes > >> >to the code!" > >> > > >> >Perhaps the best is no conversion, at all! Just upgrade to the > >> >latest technology. > >> > >> Mr Smith, come now... an organisation where the analyst recommends > >> timestamping records... errrr, rows in a database and the manager has to > >> turn to the UseNet for help will not, in my experience, embrace a solution > >> which requires Spending Money to upgrade technology or sending someone of > >> sufficient technical competence to benefit from the experience - as > >> opposed to, say, a Corner-Office Idiot - to the Royal Pacific Resort in > >> Orlando, FL, USA for three days. > > > >Apart from your alleged experience, this latest > >technology would reasonably permit one to identify > >"rows in a database" as records since there would > >be no difference with respect to a COBOL program, > >where the concept "records in a file" is common. > > Mr Smith, I am not sure what you are calling 'a COBOL program' here. > According to the last version of the COBOL Language Reference I consulted > (<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/FRAMESET/IGY3LR10/CCO NTENTS?DT=20020920180651> > or thereabouts) there are Reserved Words for file and record access; where > are you finding the ones which allow 'a COBOL program' to address a > database? The claim was with respect to "using standard COBOL I/O statements". There was no claim respecting 'physical files' nor 'physical records' as defined by standard COBOL. Page 146, FDIS ISO/IEC 1989:2002, 9.1.1 Physical and logical files, "... In this document, references to records mean to logical records, unless the term 'physical record' is specifically used. Similarly, references to files mean to the logical characteristics of a file, unless 'physical file' is used." Page 4, FDIS ISO/IEC 1989:2002, 3.1.8 Nonstandard extensions, "Nonstandard extensions are language elements or functionality in an implementation that consist of any of the following: .... 3) language elements defined in this International Standard for which different functionality is implemented, where that language element is required for conformance to this International Standard, provided that standard-conforming behavior is also implemented and that an implementor-defined mechanism exists for selection of the nonstandard behavior." Thus, "an implementor-defined mechanism" for selectively replacing the standard COBOL "file connector" with, say, a "database connector" would permit "using standard COBOL I/O statements" to access a database and without contradicting standard COBOL.
From: Anonymous on 13 Apr 2007 13:16
In article <131ve6adqohilc0(a)corp.supernews.com>, Rick Smith <ricksmith(a)mfi.net> wrote: > ><docdwarf(a)panix.com> wrote in message news:evo3dn$o4d$1(a)reader2.panix.com... >> In article <131uoo31usaadf7(a)corp.supernews.com>, >> Rick Smith <ricksmith(a)mfi.net> wrote: >> > >> ><docdwarf(a)panix.com> wrote in message >news:evleq8$o9j$1(a)reader2.panix.com... >> >> In article <131sb8b2f0atpc7(a)corp.supernews.com>, >> >> Rick Smith <ricksmith(a)mfi.net> wrote: >> >> [snip] >> >> >> >< http://www.microfocusworld.com/track_page.php?id=5 > >> >> >"A partner will present a session that shows how a relational >> >> >database can be used with a COBOL application using >> >> >standard COBOL I/O statements, WITHOUT any changes >> >> >to the code!" >> >> > >> >> >Perhaps the best is no conversion, at all! Just upgrade to the >> >> >latest technology. >> >> >> >> Mr Smith, come now... an organisation where the analyst recommends >> >> timestamping records... errrr, rows in a database and the manager has to >> >> turn to the UseNet for help will not, in my experience, embrace a solution >> >> which requires Spending Money to upgrade technology or sending someone of >> >> sufficient technical competence to benefit from the experience - as >> >> opposed to, say, a Corner-Office Idiot - to the Royal Pacific Resort in >> >> Orlando, FL, USA for three days. >> > >> >Apart from your alleged experience, this latest >> >technology would reasonably permit one to identify >> >"rows in a database" as records since there would >> >be no difference with respect to a COBOL program, >> >where the concept "records in a file" is common. >> >> Mr Smith, I am not sure what you are calling 'a COBOL program' here. >> According to the last version of the COBOL Language Reference I consulted >> >(<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/FRAMESET/IGY3LR10/CCO >NTENTS?DT=20020920180651> >> or thereabouts) there are Reserved Words for file and record access; where >> are you finding the ones which allow 'a COBOL program' to address a >> database? > >The claim was with respect to "using standard COBOL >I/O statements". There was no claim respecting 'physical >files' nor 'physical records' as defined by standard COBOL. This might be, Mr Smith, a reason for my having mentioned neither 'physical files' nor 'physical records'. What implementors may wish to do with access-methods are their own concerns. DD |