Re: Definition of FACTORY

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 05/24/04 

Date: Mon, 24 May 2004 19:21:35 GMT

Responding to Gavan...

> Well surprisingly there are still a large number using COBOL files, but
> there is a large switch to (R)DBMS - the actual split I don't know. As
> for the indexed files, since the 70's, in addition to the traditional
> PrimeKey you can have a series of Alternate Keys with or without
> Duplicates, and some compilers even allow for creating 'Split-Keys'
> taking different elements in the record to create keys. There is truly
> one big problem with COBOL files - where people used packed decimal
> values (binaries), and that is vendor independent as to how they are
> stored. So frequently in comp.lang.cobol you'll get, "I need to convert
> these old RM/COBOL files to Micro Focus format". Invariably he's in dead
> trouble because he hasn't even got the RM/COBOL compiler to do
> sequential reads and generate CSVs.

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.

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.

>
> At prompting by somebody in COBOL who goes back to the sixties using DBs
> - I have switched to using MS Access, as my data repository. And
> further on his advice, "Don't get seduced into using non-standard SQL
> syntax customized to a particular DB)..

I could argue with the Access part, but I wouldn't think of arguing with
the SQL part. B-)

>
> For convenience, doing a test application on creating a Treeview from a
> database, I did use three input text files and turned them into Indexed
> (ISAMS) because I already had the generic class templates to handle
> them.. However, it seems to me, SQL is the way to go - in my case pretty
> painless - the IDE has an SQL generator module - (1) Determine your
> tables in MS Access or any other DB, (2) register with the ODBC, (3)
> Bring up the Micro Focus tool, selectively choose columns in rows based
> on action - request CURSORS if necessary - BINGO - you have your
> complete SQL syntax which you can now paste into your program
> (procedural) or class. Goes through the compiler and is 100% clean.

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.

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.

>
> Perhaps if I re-phrase based on use of SQL. I'm one level above
> 'newbie'. Rightly or wrongly, I have chosen to create a separate Class
> per Table - so I have the following basic methods for a Table :-
>
> Method-id. "deleteRecord".
> Method-id. "makeCollection". DECLARE ? CURSOR FOR SELECT DISTINCT
> Method-id. "readRecord". SELECT DISTINCT
> Method-id. "rewriteRecord". UPDATE
> Method-id. "writeRecord". INSERT
>
> Note the methods are Identified with 'traditional' COBOL names, although
> as you can see the contents of the methods contain the appropriate SQL
> verbs. The advantage of this is, that at the DBI(DataBaseInterface)
> class level I can use common method names for either COBOL files or DB
> Tables - I don't have to mentally switch hats.

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.)

>
> At a later stage, as need arises, I can include SQL syntax in other
> classes using the DB or adding additional methods to the specific Table
> Class.
>
> So my question again, if you would be so kind :-
> -------------------------------------------------------------
> Working-Storage Section.
> 01 os-CustomerTable Oobject reference value null.
>
> . I can create an instance :-
>
> invoke CustomerTable ":new" returning os-CustomerTable
>
> - AND - I do not require a specific method in Factory called ":new": to
> achieve that.
>
> I may be missing something, but I fail to see that adding some sort of
> "initializer" method in FACTORY adds anything to using the methods in
> the OBJECT (Instance).

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.

>
> If anything I would use a "housekeeping" method in the Instance which
> passes any relevant parameters - for example I might pass the invoking
> Edit Class as a parameter calling it os-Caller in the receiving class,
> so that Class B has the ability, under given circumstances, to directly
> invoke back to Class A, without waiting for the automatic return from an
> Exit Method.
>
> The Class A and Class B concept is how I handle a template for Dialogs.
> When creating each control in Class B, for a particular event setup a
> callback, the majority in Class B, but there are occasions where you
> want the callback to be in Class A. (Example user keys in a Customer # -
> return the event immediately to Class A, where you check (1) is Key
> blank - if yes , refresh empty screen (2) Key not blank- check if
> record/row exists (2a) if Yes - display exisitng data in Dialog (2b) If
> No - accept fresh input data to Dialog.
>
> Does that clarify it at all ?
> -------------------------------------------

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.]

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Relevant Pages

  • 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: Definition of FACTORY
    ... COBOL code, but see if the following helps. ... invoke os-CustomerFile "readRecord" using Customer-Key returning ... > funny stuff around the SQL queries. ... Anyway thanks for responding. ...
    (comp.object)
  • Re: Reading sequential files in COBOL vs SQL
    ... Obviously in COBOL I'd having to allow for reading a high ... | If the files are already in the database and have an index that would allow keyed retrieval of the records you seek then SQL would ... | Mike Sicilian ... If your program can quit the search as soon as you find the record you are looking for, then a COBOL sequential search will be almost twice as fast as SQL because on average you will quit after reading half the file and SQL will always read the whole file. ...
    (comp.sys.ibm.as400.misc)
  • 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)
Quantcast