Re: Definition of FACTORY

From: James J. Gavan (jjgavan_at_shaw.ca)
Date: 05/27/04 

Date: Thu, 27 May 2004 04:48:29 GMT

H. S. Lahman wrote:

Thanks again for responding. But I picked up on Karl's name while
looking for a response from you. I knew of him by name - so as he and I
don't have to talk in pidgin-English, and seeing as he jumped in, I'll
ask him the question.

> Right. COBOL provided nice syntactic file access support initially.
> However, when the storage paradigms started changing that became a
> problem. So COBOL went the add-in route and let the compiler vendor
> fill in the gaps. Dealing with that became a mess because the I/O
> code and declarations were ubiquitous in the code.
>
> FWIW, I usually advise encapsulating the actual file I/O in a single
> subsystem or layer. That isolates the ugly stuff behind a "firewall"
> from the rest of the application. Everything outside the I/O
> subsystem uses very vanilla data structures and talks to an
> interface. The subsystem lives to convert data back and forth from
> the simple formats and whatever buffers one needs to talk to the DB de
> jour.
>
Even within the field of IT (still think of it as EDP, even ADP :-) ),
we have to be careful about getting screwed up on terminology. Your
comments above, I think we are on the same wavelength. A generic
template class for the different filetypes which is passed the record
size and external filename. I don't want to throw you for a loop with
COBOL code, but see if the following helps. We have a CustomerFile so
from Business Logic (Public Domain - I know that's the correct name, but
I hate it) we :-
      
invoke ISAMFile "new" returning os-CustomerFile (the object)
then pass the record-length and external filename to the instance
to get a record :-

- move 'xyz" to Customer-Key
- invoke os-CustomerFile "readRecord" using Customer-Key returning
Customer-Info
- CustomerInfo holds a result-code and the remainder is the defined
CustomerRecord, defined in Business Logic
- Just in case your memory is grey, file-status is the COBOL file
equivalent of SQLCODE

If I hit true errors rather than "record not found", the ISAM and other
file classes invoke class FileErrors to get the text and then display a
messagebox. It works great - unfortunately, having spent some time
figuring it out and fine tuning. not too useful now because I've moved
across to DBMS..

> This nicely isolates the application from the I/O details so that
> maintenance is better focused. It also isolates the changes when one
> inevitably changes one's mind about the repository paradigm again.
> The downside is the cost of the data conversions, especially if the
> application really doesn't do much with the data.
>
> I could argue with the Access part, but I wouldn't think of arguing
> with the SQL part. B-)
>
I understand what you are getting at with MS Access but this was on the
recommendation of the four-decade user of (R)DBMS - he's used them all
including DB2. He himself uses Access and my application has separate
packages of data for oil/gas plants, on average some 300 columns and
up to a max of 600 columns, for each location. So power wise it is not
a big deal. Coupled with that the MS package also gives me Excel, so
reasonably easily, and I already have several good examples to refer to,
using OLE, I could do some fairly straightforward graphing in Excel -
if required.

> That's fine, but you still have to do the pasting of the SQL. Since
> you are able to use Access I assume there are no major multi-user or
> resource contention issues, so you probably don't have to worry about
> funny stuff around the SQL queries.
>
No basically a one-user system. Corrosion Inspection technicians - two
of them, one sat in a van with his ultrasonic screen next to the
computer showing the screen for current item "piece" being inspected. He
and the other technician are connected by cable, Tech # 2 points the
probe at a particular spot, invariably a bend in a pipe, ultrasonic
reading goes back to the guy in the van, he interprets and then keys
result, three decimals of an inch, into computer.

> I haven't used the Access ODBC interface, but I imagine there is still
> some special handshaking stuff that around opening/closing and
> transactions that will be specific to Access. So I would still be
> inclined to encapsulate all the SQL/ODBC stuff in a subsystem.
>
Well as I wrote previously, somewhat parallel to the COBOL file approach
- rightly or wrongly, my SQL syntax is in a separate class per table.
Believe me the SQL Generator I referred to is an absolute dream for
somebody getting into DBs and SQL for the first time. I need to
differentiate between 'common' tables applicable to all plants, and
tables per specific plant.
So as I go into each table class which stores a CONSTANT, (cast in
stone value), I know either this class is 'General' or "Plant" - first
step in each method invoke Class SQLConnect to see which is the current
Access.mdb being used and DISCONNECT/CONNECT as appropriate. Micro Focus
have provided an example of doing that.

>
> Alas, I'm not sure what the syntax actually means. In principle I
> think I agree. One way or another it is probably a good idea to put
> the SQL strings in a table somewhere so that the query can be
> constructed generically.
>
> However, this sounds more like SQL is access is syntactically
> supported via methods for different SQL statements. (As opposed to a
> generic "SQLCommand" method that was passed a query string.)
>
Don't know if will help but here's an example of something that gets
copied/pasted, I make minor changes to the generated code to set flags
for success or failure etc. :-

       *>--------------------------------------------------------------
       Method-id. "readRecord".
       *>--------------------------------------------------------------
       Linkage section.
       01 lnk-key.
          05 IN-DesID pic 9(02).
          05 IN-DesCode pic x(04).
       01 lnk-record.
        copy "\copylib\sqlResult.cpy" replacing ==(tag)== by ==05 lnk==.
        copy "desrecrd.cpy" replacing ==(tag1)== by ==05 lnk-data==,
                                      ==(tag)== by ==lnk==.

       Procedure Division using lnk-key
                          returning lnk-record.

        set ResultOK to true
        invoke os-SqlConnection "setCurrentConnection"
               using ws-dbID returning lnk-SqlResult

        if TableError
           EXIT METHOD
        End-if

        initialize lnk-record
        move IN-DesID to Descriptions-DesID
        move IN-DesCode to Descriptions-DesCode

            EXEC SQL
             SELECT DISTINCT
                    `A`.`DesID`
                   ,`A`.`DesCode`
                   ,`A`.`DesName`
                   ,`A`.`DesOther1`
                   ,`A`.`DesOther2`
             INTO
                  :Descriptions-DesID:Descriptions-DesID-NULL
                 ,:Descriptions-DesCode:Descriptions-DesCode-NULL
                 ,:Descriptions-DesName:Descriptions-DesName-NULL
                 ,:Descriptions-DesOther1:Descriptions-DesOther1-NULL
                 ,:Descriptions-DesOther2:Descriptions-DesOther2-NULL
               FROM `Descriptions` A
              WHERE ( `A`.`DesID` = :Descriptions-DesID )
               AND ( `A`.`DesCode` = :Descriptions-DesCode )
            END-EXEC

        Evaluate true
            when SQLSTATE = "00000"
                 move Descriptions-Record to lnk-data
            when SQLSTATE = "02000" *> No more rows
                 set RecNotFound to true
            when other
                 move lnk-key to ws-ErrorID
                 invoke self "setErrorMessage"
                 set TableError to true
        End-Evaluate

       End Method "readRecord".
       *>--------------------------------------------------------------

I don't want to crow, but I think COBOL has the best CASE syntax in the
game - that EVALUATE above can be coded :-

Evaluate true also true also false also true also false....................
and many permutations on the above, plus they can be nested :-

Evaluate true
     when Conditions1Thru10
          Evaluate CustomerPrefix
                when "A"...
                when "B"...
          End-evaluate
      when Conditions11thru20 etc..
.
. My use of 'IFs' is limited to a one or two conditional test

The old dinosaur you knew has come a long way, and apart from a handful
of VERBS used with OO we can still use all the COBOL syntax..

>
> Sorry, I still can't comment because I don't really understand the
> context here at a very basic level. I've pretty much forgotten all
> the COBOL I once knew and I never knew anything about OO COBOL. For
> example, here I don't know whether FACTORY and OBJECT are syntactic
> elements or classes you define.
>
Hopefully Karl's explanation gave you what you want, but there again, I
know what he is saying.

>
> Yes and No. I think I <sort of> understand what you want to do.
> However, to comment I would have to know a lot more about how OO COBOL
> handles things like peer-to-peer communications (e.g., getters).
>
> For example, I am not a big fan of passing object references in
> interfaces except as setters to instantiate a referential attribute.
> But I don't even know if OO COBOL even supports referential
> attributes. [It obviously would if you are using one of the
> Java-flavored versions. But that just raises other issues like what
> to do with such attributes when the object is stored.]
>
Ahhhh "gets' and 'sets'. OO COBOL first went around the table with J4
(our Standards Committee) prompted by three people about '93. A draft
outline was produced. Once reasonably defined, IBM with VisualAge and
Hitachi and Micro Focus produced their versions. As time went on the
specification became more refined. Not quite sure of date, but then
Fujitsu joined the fray picking up on what was the latest draft spec at
that time -so Fujitus included "gets" and "sets".
I'm using Net Express V 3.1 which doesn't have them. But the latest, (at
a price of course), N/E V 4.0 does have "gets" and "sets" - from the
on-line manual I see it actually generates copy files for each "get" or
"set" you specify. I'm assuming the compiler does as search for those
copy files. The implications or how effective that is I don't know - I
don't have the compiler in front of me to use. So far as the Standard is
concerned - what the different vendors were doing only got ANSI/ISO
blessing as COBOL 2002. Even at this stage, Fujitsu, Hitachi and Micro
Focus have there own standard set of classes including the gamut of
various array classes, collections/dictionaries. The game moves slowly -
we are still waiting for the official version of what we already use -
you can foresee the fun and games when vendor X is told this is is not a
feature, or this is a new feature in the Standard. Does he bite the
bullet and keep classes covering all the developer code in existence and
then take account of the new ?

Anyway thanks for responding.

Jimmy, Calgary AB

Relevant Pages

  • Re: Definition of FACTORY
    ... > taking different elements in the record to create keys. ... COBOL provided nice syntactic file access support initially. ... the SQL part. ... > At a later stage, as need arises, I can include SQL syntax in other ...
    (comp.object)
  • Re: Conversion of data & associated logic from ISAM to RDB
    ... embedded SQL is not necessarily the best solution. ... feed it your ISAM COBOL definition (Source code) and it creates a Relational ... Database in third normal form. ...
    (comp.lang.cobol)
  • Re: Dynamiv SQL and multi-row access SQL from COBOL... some quick questions
    ... EXECUTE IMMEDIATE is for one time dynamic SQL. ... Perhaps you were referring to something other than host variables. ... COBOL using ACCESS 2003. ...
    (comp.lang.cobol)
  • Re: Thoughts on MF COBOL, Unix, and RDBMS
    ... On May 3, 12:51 pm, "Pete Dashwood" ... COBOL compiler available but it doesn't support SQL, ... the Unix Database (given ODBC for that). ...
    (comp.lang.cobol)
  • Re: SQL Expressions in Access, using Fujitsu COBOL
    ... I have been recovering from illness, but on the occasions when I have been ... surprised at how much SQL Language MS Access actually supports. ... I have noticed some limitations when using it from COBOL. ... actually written VB functions and had them processed by SQL as part of Jet, ...
    (comp.lang.cobol)