Re: Opinions on approach, please...



"Arnold Trembley" <arnold.trembley@xxxxxxxxxxxxxxxx> wrote in message
news:q29_j.13798$j41.5537@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pete Dashwood wrote:
"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:6R4_j.341990$XH2.206583@xxxxxxxxxxxxxxxxxxxxxxxxx
(snip) The one question that I would ask is whether you are "converting"
from a COBOL that supports both forward and backwards "browsing" of
ISAM, i.e.
START LESS THAN
and
READ PREVIOUS

If so, does the approach you are consider handle this?

A good thought (and one I hadn't thought of), Bill.

It is Fujitsu so I think it does. Fortunately (for me... :-)), I'm
pretty sure they never use it.

I think it could be achieved with:

EXEC SQL
DECLARE cursor cur01 for (SELECT * from Atable WHERE KeyField <=
someValue ORDER BY KeyField DESCENDING)
END-EXEC

...but I'm certainly not sure, and things are difficult enough without
that particular added complication :-).

I haven't used START against an indexed file in a batch COBOL program very
often (on IBM mainframe it would be KSDS VSAM of course). In CICS it
would be handled with EXEC CICS START BROWSE, READ NEXT (or PREV), END
BROWSE. If I recall correctly, START doesn't really do anything except
point to some position in the file for subsequent sequential processing.
The real action is in the READ NEXT or READ PREVIOUS.

Yes, that's correct. Normally there would be a series of READs following the
START. It's called "skip sequential" processing.

The process continues until either another START is encountered or EOF.

To emulate this I plan on using an SQL cursor. It would be defined and
opened by a START, following READs get translated to SQL FETCHes, and if we
hit EOF or another START is received, we CLOSE the cursor.

This is the bit I'm not too sure about at the moment. I could do it with
dynamic SQL, or I can have prebuilt static code snippets I can insert into
the application. (This is possible because all fields are always returned,
so the only "variable" part of the cursor is the condition specified in the
START. I can parse this and pass it as a relational operator and a value to
the MOST COM server, or I can pass it as a COBOL string and use dynamic SQL
to include it into the WHERE clause of a dynamic cursor within the MOST
server There are pros and cons and I keep spinning between them... :-)


I guess what I'm saying is that in order to emulate the behavior of START
on the indexed file, you need to know START returns to the COBOL program.
I would probably try to emulate START using a simple select for a specific
key (and I am no expert on SQL).

That would establish a position OK, but it means nothing. We need to fetch
sequentially from that point. That's why a cursor looks like being
necessary. I COULD do it with a resultset if it wasn't in COBOL or could
even use LINQ which would generate a Lambda for it, but that is all off the
table because of the environment it has to run in (Workstation COBOL). A
cursor is MUCH less efficient than a resultset or LINQ, but it is the best
solution I can see wioth ESQL in COBOL.


It probably depends on whether "record not found" is a valid COBOL result
for a START command.

Certainly, some of the programs specify INVALID KEY in the START command.
I'm building template code to deal with that by testing the SQLSTATE in the
application program and doing the same logic as INVALID KEY does presently.

It seems to me that IBM batch COBOL does not support READ PREVIOUS on an
indexed file, but it would be nice to have.


Fujitsu DOES support it and it also supports START with the REVERSED ORDER
clause. I don't plan to support this. If it is needed it wili have to be
coded manually.


The other question is what your converted code will do with
"file-sharing" in existing COBOL (that conforms to the old X/Open
specification, e.g. Micro Focus). Traditionally, I think this played a
significant part in programs that kept multiple indexes "in use" against
the same file.

Not quite sure what you mean by this... Locking? VSAM share options? :-)

It isn't going to do anything with it :-) I'm hoping the RDB (SQL Server)
will take care of it.

Thanks for the response, Bill.

Pete.

Without speaking for Bill, I assume that he meant record locking. I don't
see any point in trying to emulate VSAM file sharing options, and you're
probably right in hoping the RDB will handle all those issues.

Keeping my fingers crossed... :-)

In CICS, you can only have one indexed file record at a time READ for
UPDATE. That's an implicit record lock and there are only two ways to
release it, either by rewriting the record or by issuing an EXEC CICS
UNLOCK on the file. If one record is locked, you cannot read another
record for update in the same file.

CICS is not applicable for this environment, but I note your comments in
passing.

In IBM Batch COBOL, I am not aware of any way to specifically UNLOCK a
record read for update if the program does not rewrite it. Your RDB may
have its own issues with locking rows or tables, and your interface may
need to protect the COBOL program by managing commits and locks.

Nope. The RDB will handle it. That's what they do... :-)


I'm assuming you don't want to make any changes to the COBOL program's
logic except for automatically replacing the I/O statements on a one for
one basis.

Yes, exactly.


As I said before, I am no expert on SQL, and my indexed file experience is
only with VSAM in CICS and batch COBOL. So my thinking might not be very
helpful to your situation.

As I noted in response to Bill, all responses are of some value here. Your
post made me check on how START works...:-)

Interestingly enough, IBM offers an option to replace KSDS VSAM files with
DB2 tables, with no changes to the COBOL source code. I'm not sure if the
program even needs to be recompiled.
http://tiny.cc/8qIQE

I read this with great interest. This is exactly what I intend to provide
for the Workstation environment. They didn't mention how they cope with
Group fields and OCCURs in Indexed records when they convert to RDB.
(Technically, the relational model supports neither of these, although some
RDBMS are now supporting Repeating Groups (mainly because of pressure to
support Legacy COBOL.)).

My Migration Toolset splits tables within an Indexed record out to be
separate tables with an index (subscript) that is part of the key, and
attaches them back to the base table via a referential integrity constraint
and cascade deletes. This conforms with 2NF normalization, but it means that
subscripted references in the code need to be changed. MOST will actually
load the tables in the indexed record format from the attached tables when
it retrieves the base record, so what is presented back to the application
program is exactly what would have come off an indexed file.

I note that the IBM solution uses a generated driver for each file, which is
pretty much what MOST is.

Thanks for your post, Arnold.

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


.

Relevant Pages

  • Re: Opinions on approach, please...
    ... COBOL that supports both forward and backwards "browsing" of ISAM, ... It isn't going to do anything with it :-) I'm hoping the RDB (SQL Server) ... Code conversion is much more tricky. ... The job of the MOST template is to "translate" these Indexed file actions ...
    (comp.lang.cobol)
  • Re: Opinions on approach, please...
    ... applications that use Indexed files to RDB. ... Conceptually, I want to add a Data Access layer to the existing COBOL, ... I plan to generate from a template, a module that ... The job of the MOST template is to "translate" these Indexed file actions ...
    (comp.lang.cobol)
  • Re: Revisiting an Old Prejudice: READ INTO/WRITE FROM
    ... of that which can be chalked up to sloppiness, ... National Standard COBOL", and GC28-6396-5, ... COBOL F) show nearly identical sample programs for "Random ... storage being the NOMINAL KEY for the indexed file. ...
    (comp.lang.cobol)
  • Re: Micro Focus Net Express® with .NET
    ... > code for indexed file access. ... I need to distribute the Fujitsu runtime for Windows (and own ... > I could find) I don't think there is COBOL integration for Winforms ...
    (comp.lang.cobol)
  • 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)