I have migrated a system from Object COBOL v4.0 to Netexpress 5.1. I am having a problem with some cursor processes.
Originally the system used to have ISAM files and was converted to use DB2. Now the way this was done, to me, seems a complete waste of time as all that was done is the START statements were replaced by OPEN CURSOR statements and the READ NEXT by FETCH statements. All ok and it works.
Each table has it's own file handler program that handles all of the input / output for one table at a time.
Now in Netexpress I have some loops that process table A using aforementioned cursors and for each entry another table is processed using a different cursor. When completion of the inner loop is reached the program then attempts to read the next record from the outer loop. In Netexpress I receive a 501 error indicating that the cursor is not open.
Now I'm not looking for anybody to start debugging the code as I'm quite sure it's not that. It feels to me as though Netexpress is not allowing me to have more than one cursor open at a time, although I can't find any compiler setting for this.
Does anybody know if there is a setting I need?
Many thanks for reading
Ian
Hi Simon
I think I will try that.
These are the Project properties within Netexpress:
%FILENAME COBIDY(%TARGETDIR) WB3 WB CSI ANIM EDITOR(MF2) ENSUITE(3) CHANGE-MESSAGE"0837 N 0011 N" /CONSTANT VN(1700) /CONSTANT GOGO(0) REMOVE "SELF" DB2(DBMAN=DB2) DB2(BIND=%BASENAME.BND) DB2(DB=HMS1700) SPZERO STICKY-LINKAGE OOCTRL(-G+N-P+Q-W);
I'm afraid it's not ESQL unfortunately.
The COBOL code is very, very complicated. It's nothing like any COBOL I've maintained in 30 years experience. Basically, the program reads a list of Sites and for each Site it then reads all location codes for THAT Site. In between, the program allocates memory to store these location entries. I have actually narrowed down the problem to some code that is executed for each Site.
INVOKE OSMEMORY "newtable" USING
BY VALUE LENGTH OF WS-LOC-KEY
BY VALUE WS-OBJ-DIALOG
BY REFERENCE WS-OSMEMORY-ADDRESS
BY REFERENCE WS-OBJ-SLLIST
RETURNING WS-OSMEMORY-REPLY.
OSMEMORY.CBL is a class program that starts doing things like:
METHOD-ID. "newtable".
LOCAL-STORAGE SECTION.
01 WS-REPLY USAGE LONG.
LINKAGE SECTION.
01 LK-ENT-SIZE USAGE LONG.
01 LK-OBJ-PARENT USAGE OBJECT REFERENCE.
01 LK-MEM-POINTER USAGE POINTER.
01 LK-OBJ-MEMORY USAGE OBJECT REFERENCE.
01 LK-REPLY USAGE LONG.
INVOKE SUPER "new" RETURNING LK-OBJ-MEMORY.
INVOKE LK-OBJ-MEMORY "initializetable" USING
BY VALUE LK-ENT-SIZE
BY VALUE WS-ENT-TABLEMAX
BY VALUE LK-OBJ-PARENT
BY REFERENCE LK-MEM-POINTER
RETURNING LK-REPLY.
IF LK-REPLY NOT = WS-OSCLASS-OK
INVOKE LK-OBJ-MEMORY "finalize" USING
BY REFERENCE LK-OBJ-MEMORY
RETURNING WS-REPLY
END-IF.
EXIT METHOD.
-----------------------
METHOD-ID. "initializetable".
LOCAL-STORAGE SECTION.
LINKAGE SECTION.
01 LK-ENT-SIZE USAGE LONG.
01 LK-ENT-MAX USAGE LONG.
01 LK-OBJ-PARENT USAGE LONG.
01 LK-MEM-POINTER USAGE POINTER.
01 LK-REPLY USAGE LONG.
PROCEDURE DIVISION USING
BY VALUE LK-ENT-SIZE
BY VALUE LK-ENT-MAX
BY VALUE LK-OBJ-PARENT
BY REFERENCE LK-MEM-POINTER
RETURNING LK-REPLY.
MULTIPLY LK-ENT-SIZE BY LK-ENT-MAX GIVING WS-ENT-MEMSIZE.
COMPUTE WS-ENT-MEMSIZE =
((WS-ENT-MEMSIZE / WS-ENT-INCREMENT) + 1).
MULTIPLY WS-ENT-MEMSIZE BY WS-ENT-INCREMENT
GIVING WS-ENT-MEMSIZE.
INVOKE SELF "initialize" USING
BY VALUE WS-ENT-MEMSIZE
BY VALUE WS-OSCLASS-FALSE
BY VALUE LK-OBJ-PARENT
BY REFERENCE WS-ENT-CURRPTR
RETURNING WS-REPLY.
IF WS-REPLY NOT = WS-OSCLASS-OK
MOVE WS-REPLY TO LK-REPLY
EXIT METHOD
END-IF.
MOVE WS-TYPE-MEMORY TO WS-TYPE.
MOVE LK-ENT-SIZE TO WS-ENT-ENTSIZE.
MOVE LK-ENT-MAX TO WS-MAX-RECNO.
MOVE 0 TO WS-ENT-COMMITED
WS-ENT-RECSINENQ
WS-ENT-NEXTREC.
SET LK-MEM-POINTER TO WS-ENT-CURRPTR.
MOVE WS-OSCLASS-OK TO LK-REPLY.
EXIT METHOD.
END METHOD "initializetable".
*>*********************************************
*> Instance method - initialize * PRIVATE
*>*********************************************
METHOD-ID. "initialize".
LOCAL-STORAGE SECTION.
LINKAGE SECTION.
01 LK-MEM-SIZE USAGE LONG.
01 LK-MEM-COMMIT USAGE LONG.
01 LK-OBJ-PARENT USAGE OBJECT REFERENCE.
01 LK-MEM-POINTER USAGE POINTER.
01 LK-REPLY USAGE LONG.
PROCEDURE DIVISION USING
BY VALUE LK-MEM-SIZE
BY VALUE LK-MEM-COMMIT
BY VALUE LK-OBJ-PARENT
BY REFERENCE LK-MEM-POINTER
RETURNING LK-REPLY.
MOVE "VirtualAlloc" TO WS-LAST-FUNCTION.
IF LK-MEM-COMMIT = WS-OSCLASS-TRUE
MOVE WS-MEMRESCOMMIT TO WS-MEMFLAGS
ELSE
MOVE WS-MEMRESERVE TO WS-MEMFLAGS
END-IF.
CALL OSAPI "VirtualAlloc" USING
BY VALUE 0
BY VALUE LK-MEM-SIZE
BY VALUE WS-MEMFLAGS
BY VALUE WS-MEMREADWRITE
RETURNING LK-MEM-POINTER.
IF LK-MEM-POINTER = NULL
CALL OSAPI "GetLastError" RETURNING WS-LAST-ERROR
MOVE WS-OSCLASS-FAILED TO LK-REPLY
EXIT METHOD
END-IF.
MOVE WS-TYPE-MEMORY TO WS-TYPE.
MOVE LK-MEM-SIZE TO WS-MEM-SIZE.
SET WS-MEM-POINTER TO LK-MEM-POINTER.
SET WS-OBJ-PARENT TO LK-OBJ-PARENT.
IF WS-OBJ-PARENT NOT = NULL
INVOKE WS-OBJ-PARENT "register" USING
BY VALUE SELF
RETURNING WS-REPLY
END-IF.
MOVE 0 TO WS-LAST-ERROR.
MOVE WS-OSCLASS-OK TO LK-REPLY.
EXIT METHOD.
END METHOD "initialize".
---------------------------------
Hey, I have 20,000,000 lines of code just like this to maintain on my own. :-)
I'm afraid the OO stuff here is so over my head without anybody there to ask. All long gone.
Ian
In article ,
Bill Gunshannon wrote:
>In article ,
> docdwarf@panix.com () writes:
>> In article ,
>> razor wrote:
>>
>> [snip]
>>
>>>Originally the system used to have ISAM files and was converted to use
>>>DB2. Now the way this was done, to me, seems a complete waste of time as
>>>all that was done is the START statements were replaced by OPEN CURSOR
>>>statements and the READ NEXT by FETCH statements.
>>
>> This won't help you with your particular difficulty... but I cannot recall
>> the number of DB2 systems I've worked on where this can be seen. The
>> company started with flat files, then moved to indexed datasets and then
>> got dragged, kicking and screaming, into DB2.
>>
>> Since the Most Senior Programmers were proficient with indices - and the
>> Most Senior Programmers had the most say in the architecture of the DB2
>> installation - then the architecture resembled that with which they were
>> most comfortable.
>>
[snip of similar experience]
>Some of them actually do nothing but read the database data into flat files
>and then process the files. Try working with that that when the database
>structure changes and you need things like UNIONS and JOINS with new tables
>that weren't even thought of at the time of the conversion.
It may not have been available when it was needed... but DFSORT now
supports some options that are utterly stunning.
DD
In article ,
docdwarf@panix.com () writes:
> In article ,
> razor wrote:
>
> [snip]
>
>>Originally the system used to have ISAM files and was converted to use
>>DB2. Now the way this was done, to me, seems a complete waste of time as
>>all that was done is the START statements were replaced by OPEN CURSOR
>>statements and the READ NEXT by FETCH statements.
>
> This won't help you with your particular difficulty... but I cannot recall
> the number of DB2 systems I've worked on where this can be seen. The
> company started with flat files, then moved to indexed datasets and then
> got dragged, kicking and screaming, into DB2.
>
> Since the Most Senior Programmers were proficient with indices - and the
> Most Senior Programmers had the most say in the architecture of the DB2
> installation - then the architecture resembled that with which they were
> most comfortable.
>
Well, that last COBOL gig I did a couple years ago had gone through this
same thing. Was using VSAM and then databases came into vogue. Brought
in contractors to do the conversion. A simple read of the code they wrote
easily shows that the contractors had no idea how to program COBOL for
database use and the result is some really bad programs that perform poorly,
don't really do what the user wants and are nearly impossible to fix. But,
no problem, just blame COBOL like everyone else does.
Some of them actually do nothing but read the database data into flat files
and then process the files. Try working with that that when the database
structure changes and you need things like UNIONS and JOINS with new tables
that weren't even thought of at the time of the conversion.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include
In article ,
razor wrote:
[snip]
>Originally the system used to have ISAM files and was converted to use
>DB2. Now the way this was done, to me, seems a complete waste of time as
>all that was done is the START statements were replaced by OPEN CURSOR
>statements and the READ NEXT by FETCH statements.
This won't help you with your particular difficulty... but I cannot recall
the number of DB2 systems I've worked on where this can be seen. The
company started with flat files, then moved to indexed datasets and then
got dragged, kicking and screaming, into DB2.
Since the Most Senior Programmers were proficient with indices - and the
Most Senior Programmers had the most say in the architecture of the DB2
installation - then the architecture resembled that with which they were
most comfortable.
DD
On 29/08/2014 11:32, razor wrote:
> I have migrated a system from Object COBOL v4.0 to Netexpress 5.1. I am having a problem with some cursor processes.
>
> Originally the system used to have ISAM files and was converted to use DB2. Now the way this was done, to me, seems a complete waste of time as all that was done is the START statements were replaced by OPEN CURSOR statements and the READ NEXT by FETCH statements. All ok and it works.
>
> Each table has it's own file handler program that handles all of the input / output for one table at a time.
>
> Now in Netexpress I have some loops that process table A using aforementioned cursors and for each entry another table is processed using a different cursor. When completion of the inner loop is reached the program then attempts to read the next record from the outer loop. In Netexpress I receive a 501 error indicating that the cursor is not open.
>
> Now I'm not looking for anybody to start debugging the code as I'm quite sure it's not that. It feels to me as though Netexpress is not allowing me to have more than one cursor open at a time, although I can't find any compiler setting for this.
>
> Does anybody know if there is a setting I need?
>
> Many thanks for reading
>
> Ian
>
Hi Ian,
You may be best off speaking with Micro Focus Customer Support, but I'm
curious as to how you're accessing DB2 - either via ODBC through
OpenESQL (using the SQL directive) or using the DB2 ECM (using the DB2
directive), or precompiling with IBM's command line precompiler (db2
prep...) and compiling the output?
Could you provide a list of directives that you're using please?
If you're using OpenESQL, enabling ODBC tracing should show whether the
cursor has been erroneously closed.
thanks,
SimonT.
Mega Search
Sign Up 
