Re: Opinions on approach, please...



"razor" <iruddock@xxxxxxxxxxxxxxxx> wrote in message
news:810c2e53-88be-4cac-b545-84ebd69574ca@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Pete

Really good discussion this, and most useful to me. I've tried a bit
of this in the past but gave up when I got busy with 'real work' for
which I was to get paid for. I had a couple of problems that stopped
me in my tracks and I could not get answers to.

1. When we typically read a Customer Record in COBOL, we read with
lock and present the details to the user, allow them to amend, rewrite
and then unlock. How can we do this as an equivalent within a COBOL
program. Your routines would convert a very simple READ to a very
simple SQL statement. The user may take 10 mins to change the details
and the thing I don't understand is how we can ensure the record (row)
is locked and another user cannot change the data. I do admit that my
SQL knowledge is limited and I may be missing something here.

Would you hold a record lock in an application for 10 minutes? I don't think
so, even if you were working in an environment where you could.
(Mainframe environments using TP monitors like CICS and what used to be
IMS/DC, dequeue as soon as they respond to the terminal, and at this point
all locks are lost... A PC COULD hold a lock indefinitely, but it would be
poor application design to do so. Some applications address this by
re-fetching the record immediately before update.)

To answer your question: In a RDBMS system the RDBMS takes care of it. (You
can "help it out" by specifying things like "WITH UPDATE INTENT". )


2. My other problem was where I was trying to replicate the
'scrolling' of my screens. All of my screens have nine rows that allow
users to page up and down through a file (or between certain
parameters if dealing with say, an order lines file for order number
nnn). I have GUI and non-GUI versions of this and I don't bind these
objects to a data source as I want to retain the control within the
COBOL program. I use the cursors as you very first suggested with a
descending option when I need it and i also used a 'LIMIT 10' on each
one to only get 9 records. Anyway, when I came to try and replicate
the following code, I got problems:

FD ORDER-LINES.
01 ORDERL-REC.
03 ORDERL-KEY.
05 ORDERL-NO PIC 9(7).
05 ORDERL-PRODUCT PIC 9(6).
03 ORDERL-QTY PIC 9(7).

..
..
..
MOVE ORDERH-NO TO ORDERL-NO.
MOVE WS-LAST-PRODUCT TO ORDERL-PRODUCT
START ORDER-LINES KEY IS NOT LESS THAN ORDERL-KEY

PERFORM 9 TIMES
READ
BLAH, BLAH
END-PERFORM


Its a couple of years ago now but as I recall I could only pass one
parameter from the COBOL program to the dynamic part of the SQL code.
The way I tried to do it was by having an additional 13 character text
field as the key in the DB (order no and product code) and
manipulating this as a text string. This was obviously very wrong and
very clunky.

You may be being a little hard on yourself :-)

COBOL uses a hierarchic data system, the relational model doesn't. This
causes problems when converting. If you were building a RDB from scratch you
probably wouldn't use split keys, but you're not, so I don't think your
solution is so terrible.

I build RDBs from COBOL data definitions. That means they have group fields
on the database. There are two choices:

1. Remove the group field and amend the code that accesses it.
2. Retain the group field and make sure that it is updated when one of its
components changes (maybe a stored procedure...)

(My data conversion software can flag the names of group fields as an
option. This means they can be readily identified on the RDB, but it also
means that all existing code which uses them will fail. Individual
circumstances will dictate what you do about it and it usually comes down to
choosing the lesser of two evils. Life is about choices... :-))

How should I have done this Pete?

I'm not well enough qualified in this area to tell you how you SHOULD have
done it. (Remember there is seldom only ONE "right" way. For me, if
something works then that's pretty good. If it doesn't work well, then look
at improving it :-))

I CAN tell you that, given what you have described, I would probably have
done what you did :-).

Pete.
--
"I used to write COBOL...now I can do anything."




.

Relevant Pages

  • Re: How proprietary is the "COBOL file system"
    ... proprietary indexed system which is delivered with their COBOL ... I have only ever used ODBC to access RDBs, ... Yes, after migration, code conversion is the next major effort. ... For example, the existing code references various group fields, but the RDB ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... proprietary indexed system which is delivered with their COBOL ... Yes, after migration, code conversion is the next major effort. ... For example, the existing code references various group fields, but the RDB ...
    (comp.lang.cobol)