Re: Opinions on approach, please...
- From: Arnold Trembley <arnold.trembley@xxxxxxxxxxxxxxxx>
- Date: Sun, 25 May 2008 08:02:30 GMT
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. 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). It probably depends on whether "record not found" is a valid COBOL result for a START command.
It seems to me that IBM batch COBOL does not support READ PREVIOUS on an indexed file, but it would be nice to have.
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.
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.
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. 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.
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.
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
With kindest regards,
--
http://arnold.trembley.home.att.net/
.
- Follow-Ups:
- Re: Opinions on approach, please...
- From: Pete Dashwood
- Re: Opinions on approach, please...
- References:
- Opinions on approach, please...
- From: Pete Dashwood
- Re: Opinions on approach, please...
- From: William M. Klein
- Re: Opinions on approach, please...
- From: Pete Dashwood
- Opinions on approach, please...
- Prev by Date: mySQL
- Next by Date: Re: mySQL
- Previous by thread: Re: Opinions on approach, please...
- Next by thread: Re: Opinions on approach, please...
- Index(es):
Relevant Pages
|