Quantcast
Channel: Visual COBOL - Forum - Recent Threads
Viewing all articles
Browse latest Browse all 4356

RE: File remains locked after managed COBOL returns to ASPX caller

$
0
0

jholland's suggestion, as I understand it, would require adding FILE STATUS clauses to every SELECT statement in over 250 programs, plus logic code after every IO statement to test-and-branch.  We were hoping the conversion from native to managed wouldn't involve such a massive coding effort.

I don't understand Mr. Glazier's suggestion of "add exception handling around the call statement using try/catch syntax".  In the ASPX program?  That is what the programmer has already done, but by that time the COBOL program has exited and the log file is locked.  In the COBOL program?  What "call statement" is he referring to?

The "open-->write-->close" method has been debated, but we were (are?) hoping for another solution that would be more "automatic", such as the what happens in native code after a STOP RUN.

The non-COBOL programmer doing the actual work of replacing the COBOL .exe task programs with ASPX versions looked over the documentation and for reasons I don't understand (because I'm so new to VS and don't know hardly anything about .Net and ASPX?) has balked at using Run Units.  Something about "your calling a COBOL program in order to call a COBOL program when its all managed code and I don't see the point"?  Do I understand correctly that a Run Unit would have to be instantiated before every call to a managed COBOL .dll, and then terminated before the next call?


Viewing all articles
Browse latest Browse all 4356

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>