|
 |
|
|
| |
|
Micro Focus [
return
] |
|
From |
Message |
kevin neville
9/13/2005
08:09:52
|
 Subject: web enabling with Microfocus NetExpress 3.1 bugs
Message:
Background:
We have a Windows client/server version of our software (Purchasing Management eXtra – aka PMX) in production that accommodates multiple users with no problems. We have created a web front end for one of our modules & the architecture/design consists of three basic pieces – the C# layer attached to the user interface, the COBOL, and a layer of C# that sits between the user interface and the COBOL. Please review the attached presentation for greater detail of each of these layers, their functions, and the general data flow.
Currently, we are unable to use the web version due to data integrity problems. To date, we are using Microfocus NetExpress 3.1 SP1 as our development compiler, and are considering migrating away from MF to something else (Fujitsu NETCOBOL is a specific product under consideration, but nothing has been confirmed or eliminated as options, including MF NetExpress 4.0, although that is the least likely candidate).
We’ve got three development versions of our code at the moment – a NetExpress 3.1 compiled version set to single-threaded, a 3.1 version set to multi-threaded, and a NetExpress 4.0 compiled version set to multi-threaded. None of them work correctly, however the issues are different. Logic tells us we need to be multi-threaded, but perhaps not. The COBOL code for the client/server version is single-threaded and runs with no problems. Input on the single- vs. multi-threaded settings would be much appreciated.
The 3.1 multi version doesn’t run at all – returns a Windows generic com error before it even gets into the COBOL code. Because of that, we are unable to test with it, and are considering it a non-option.
The 3.1 single and the 4.0 multi both run, but are generating errors where the error message isn’t readable – it’s returning errors from a variety of different temp files, depending on specific options we select, and we’re unsure which selections are correct, or more correct than the others, as nothing runs error-free. The error messages are just some sort of junk that’s mostly characters not available on the keyboard. Please see below for specific testing procedures & detailed results. Also, please review the attached file for screenshots of input and the output from a debug file generated by this testing.
Things we’ve tried:
Use of static declared variables has been removed from the web code.
We have concentrated on only two of the DLL calls (SCWLOGIN and SCWRQ) in order to limit what we need to test.
Calls to SWCLOGIN continue to work without error. SCWRQ has issues once we recompile it with the recommended "REENTRANT(2)" and multithread shared settings.
We have reworked the dlls to reduce their functionality and the call still fails.
Currently suggested culprits:
Microfocus uses “pinning” of memory, which is suspect in several people’s opinions.
The interop layer we have between the user interface and the COBOL is using .NET reflection to dynamically create an assembly with the static calls to the DLLs. Testing at this point has not shown that to be a problem but we are aware of this being an unusual way of writing the interop code (original author is gone so any input on issues with this technique is welcome).
Size of the data block
Suggested fixes
Moving to the Fujitsu NETCOBOL compiler
problem – 2 to 6 month minimum effort to convert – need to get a solution to customers before then
I have also attached some of our COBOL code and some of the Interop code. The COBOL is attached in a file with SCWRQ.CBL, SCWRQ.DLL, MNTRQWEB.CBL and MNTRQWEB.DLL. The dll's were linked without 'reentrant' and for the single thread environment. The Interop code is in PMX.BUSINESSINTERFACE.zip. If you have received or reviewed this code previously, these are the same files. If you would like other files to review, please let me know.
At this point, I’m at a loss for where to go, but we need a solution, if only a temporary one, asap, so all ideas are welcome.
***************************************************************************************************************************************
Testing & error description from one of our developers: (The errors, file status info, & file & program names are unique to our product, PMX. We can discuss in greater technical detail later.)
In version 3.1
1) During multi user testing with single thread
a) Getting an undefined SQL error for one user
b) Getting a file status code 47 on c37tmp file
c) Getting an undefined 'alert'
2) During single user testing with multi thread
a) Can't call the scwrq program
In version 4.0
1) During multi-user testing
a) Getting an undefined SQL error for one user
b) Getting a file status code 47 on c37tmp file
With Charles latest code, it gives unique req number but gets a "MNTRQ: ERROR RE-WRITING REQ. SCREEN FILE. FILE STATUS: 23" when two users trying to create a requisition.
*****************************************************************************************************************************************
Testing & error description from another developer:
OPEN ISSUES:
SINGLE THREAD Version 3.1:
With the current changes in 3.1 Single thread version- as of what Charles has – It does generate unique Requisition Number (primary key) but cannot proceed further as it gives error – FILE STATUS CODE 47 – c37tmp file.
SAMPLE TEST CASE SCENARIO followed by MAMTHA;
1. User WJA logs in
User NJC logs in
2. WJA switches to Maintenance Page.
NJC switches to Maintenance Page.
3. WJA -> Corp number 001 – tabbing away gets Req Number EX: 55.
Enter Header information, GO to Line page, Enter Line information.
NJC -> Corp number 001 – tabbing away gets Req Number EX: 56.
Enter Header information, GO to Line Page, Enter Line information.
WJA -> Save requisition -> Gives an ERROR.
NJC -> Save requisition -> Gives an ERROR.
The Error message seen by WEB is different but the Debug2.dat file always records it as follows–
SS-ERROR-MESSAGE OUT = 'ô ø ê3 : ERROR OPENING OUTPUT TEMPORARY C37TMP FILE FILE STATUS: 9/0004
SS-ERROR-MESSAGE OUT = 'Dì3 ì3 : ERROR DELETING TEMPORARY C37TMP FILE. FILE STATUS: 9/0004.
Thanks,
Beth Harney
Director of Product Development
Bellwether Software Corp.
9900 Shelbyville Road, Suite 6B
Louisville, KY 40223
office: 502/426-5463
fax: 502/423-8963
cell: 859/552-4418
email: bharney@bellwethercorp.com
|
|
|
|
|
|
|
|
|
|
|
[ Go to Top of Page ]
|
|
|
|
COBOL Forums |
Do you need COBOL help?
Let the COBUG members help you.
Post your issues!
|
|
|
New Local User Group |
Welcome!
COBOL User Group - Trivandrum (CUGTVM), India
|
|
|
COBOL Jobs |
Here are references to a wealth of
COBOL job resources.
|
|
|
Job and Resume Matchmaker! |
Employers submit your COBOL job openings.
Job seekers submit your resumes.
|
|
|
