COBOL Objects with IO statements, wrapped by WSIT

[Maurizio Rondina]

I have many 3GL Cobol Application, that I want componentize with WSIT.

I wrap few cobol objects to re-use them as WebService JSP client. Now I can access some of theese object form Internet explorer, but only is these object don't have IO statements. In this case, the problems are two:

- within the cobol object there are some assignmant external variables. Example:
SELECT FILE1 ASSIGN TO LOGICAL_FILE1
where LOGICAL_FILE1 is a logical name that OpenVms User Login Procedure set to the corrispondance phisical location of the file.

- also if i put the phisical location on the select statement: example:
SELECT FILE1 ASSIGN TO "SYS$MANAGER:FILE1.DAT"
when the JSP page try to open the file, The browser return me this message:
"The following exception occurred while calling :
javax.servlet.jsp.JspException: %COB-F-EOF_DETECTED, end of file detected"

Note, The statement who cause the errore is OPEN, not READ. I more fine a messase as "file non find", instead a massage of EOF.

[Hein van den Heuvel · Accepted solution]

>> Note, The statement who cause the errore is OPEN, not READ.

How do you know it is the OPEN statement?!
I see no indication of that in the error message.
All I see is EOF which, can only come from a READ, not an OPEN.

>> I more fine a messase as "file non find", instead a massage of EOF.

Agreed, I expect an error like FNF or FLK from open, not EOF.

I did not understand the part about LOGICAL_FILE1. Where are you going with that? Does that give a different error or no error?

how are the cobol modules written / called? No colbol v3 rules in effect?
Cobol can surprise some by 'falling' through into the next executable statement after an EXIT PROGRAM

" General Rules
1 If EXIT PROGRAM executes in a program that is not a
called program, it causes execution to continue with the
next executable statement.
2 If the EXIT PROGRAM statement executes in a
called program without the INITIAL clause in its
PROGRAM-ID paragraph, execution continues with
the next executable statement after the CALL statement
in the calling program."

Debugging suggestions:

1) Believe the EOF status and start wondering how you got to the read code.

2) SET FILE/STAT on the file in question and use my rms_stats tool to keep the section open and display the total counters.

3) Use John's FAKE_RTL or my COBRTL intercept tools to trace the cobol IO statements.

[Maurizio Rondina]

Thank you for the reply,

I'm sure that the statement was OPEN, because I cut all other statements on one my simply test program, and newly create the .OBJ with OPEN as the only statement, and build end deploy again the WSIT application. but the result was the same.

With the cobol costruct "SELECT filename ASSIGN TO external_name" I normally use as the "external name" an environment variable, that i set externally fron DCL .COM procedure.

Example:
$ DEFINE LOGICAL_FILE1 SYS$MANAGER:FILE1.DAT
$ RUN myprogram
instead to use the phisical name inside the cobol source.
This is useful on a traditional OpenVms user session, but i don't know if this is possible with WSIT, and if i can use external logical names in this case.

To avoid problem, I modify the test program, and replace the logical name with the phisical name, but the EOF message remain.

Thanks for the general rules for the EXIT PROGRAM statement.
The EXIT PROGRAM statement is the last of the simply test program, but I' m at the begin of my test project, and i don' t still use chained calls. But I will have this feature next days.

Thanks for the debug suggestion, can you say me where i can found your tools?


Now I copy the test program T001 with the name T002, include all the statement of the external copyfile (such as TW0T001L.LIB), into the new program T002. I create the OBJ and build and deploy the application and now the EOF message don' t happen. Instead any thing i do in T001 the EOF message always remain.

the T001's program procedure division:
LINKAGE SECTION.
COPY TW0T001L.
PROCEDURE DIVISION USING T001-LS.
INIZIO.
IF T001-FNZ-CLOSE
GO TO CHIUDI.
IF T001-FNZ-OPEN
GO TO APRI.
IF NOT T001-FNZ-OPEN
GO TO ELAB.
APRI.
OPEN INPUT WTAB ALLOWING ALL.
GO TO FINE.
APRI-CALL.
SET IOF-OPEN-INPUT TO TRUE.
IF T001-OPEN-MMTA9 EQUAL 1
CALL 'FMMTA9' USING IOF-PARM, MMTA-RECORD
MOVE 2 TO T001-OPEN-MMTA9.
IF T001-OPEN-MMAG EQUAL 1
CALL 'FMMAG' USING IOF-PARM, MMAG-RECORD
MOVE 2 TO T001-OPEN-MMAG.
FINE.
EXIT PROGRAM.


the T002's program procedure division:

LINKAGE SECTION.
01 T002-LS.
03 T002-FNZ PIC X.
88 T002-FNZ-OPEN VALUE 'O'.
88 T002-FNZ-ELAB VALUE 'E'.
88 T002-FNZ-CLOSE VALUE 'C'.
03 T002-CHIAVE PIC X(4).
03 T002-DATI PIC X(59).
PROCEDURE DIVISION USING T002-LS.
INIZIO.
IF T002-FNZ-CLOSE
GO TO CHIUDI.
IF T002-FNZ-OPEN
GO TO APRI.
IF T002-FNZ-ELAB
GO TO ELAB.
APRI.
OPEN INPUT WTAB ALLOWING ALL.
GO TO FINE.
ELAB.
MOVE T002-CHIAVE TO WTAB-CHIAVE.
READ WTAB INVALID KEY
MOVE ALL '0' TO WTAB-DATI.
MOVE WTAB-DATI TO T002-DATI.
GO TO FINE.
CHIUDI.
CLOSE WTAB.
FINE.
EXIT PROGRAM.

I don't uderstand why T001 program cause the EOF message, and T002 not.

[Hein van den Heuvel]

My tools are on the OpenVMS freeware:
http://h71000.www7.hp.com/freeware/freeware60/rms_tools/

[ For several of those tools I have improved versions for my customers. ]

I think I see a potential problem.
Imagine the choice field T002-FNZ contains 'x' or a low value.

In case T001 that value hits
'IF NOT T001-FNZ-OPEN' and goes to ELAB

In case T002 that hits
IF T002-FNZ-ELAB GO TO ELAB.
and will not jump but rather fall through to APRI, the open code.

Sloppy coding in both cases!

Hein.

[Maurizio Rondina]

in both cases, I'm sure that the choice field T002-FNZ contain "O", and go to APRI label. I make a COBOL main program that call T001, and debug it in traditional environment.

May be that the problem is not in cobol statements, but in the TOMCAT environment (that i use for the tests) or in the build and deploy phase, that not overwrite all the components generated by ANT utility?

Thanks for the URL of your tools, and for your intrest for my problem.

[Richard J Maher]

Hi Maurizio,

Can you not just call "lib$signal" with ss$_debug and then step through the code with the lovely VMS debugger?

Cheers Richard Maher

[Willem Grooters]

On the logicals:
I have found (in my Apache+Tomcat days) that logicals should be defined _before_ Tomcat and Apache are started - and NOT be changed after that: changes are not always reckognized, SWS might even crash. Nor can these logicals hold a searchlist, only the first entry will be used (if at all).

The logicals are easiest defined /SYSTEM but that might not be acceptable. They could be defined /GROUP - have that defined in the Tomcat startup (since Tomcat needs te be started before SWS and runs under the same UIC as SWS (usually)). It requires the javabean run under the same group account as well - and I don't know if that is the case.
/PROCESS or /JOB may be possible as well but that must be done in the startup for both Tomcat and SWS, and is only acceptable if the java bean runs as a thread in the Tomcat process, or as a subproces under control of eitrer Tomcat or SWS.

EOF on OPEN could well be related to this issue. Java has it's own funny way of signalling.

[Maurizio Rondina]

Thanks to all, i find that the problem is not in the language sintax, but on TOMCAT that keep old images. New buld and deployment of a wrapped application not overwrite the previous version.

I try with the http://tomcatserver:8080/manager/html to "undeploy" and "reload" functions, i try also shutting down and restart TOMCAT, i try also deleting all files and directory of the application trees, but i some cases is impossible that TOMCAT "forget" the first original build and deployment.

for the logical names problem, there is the possibility to insert a SetupCommandFile in the wsi$root:[deploy]application.wsi. There is an apposite tag.

Now I am in touch with a consultant of Atlanta HP support, i try other tests.

[Willem Grooters]

Stopping and restarting TOMCAT alone might not be sufficient. IIRC, Tomcat must be started before SWS. That implies that if you want to restart Tomcat, you should adhere to the sequence:

* Stop SWS
* Stop Tomcat
* Start Tomcat
* Start SWS

WG

[Maurizio Rondina]

With the support of Dale Selby (HP Atlanta), and many tests, I have solved many problems.

I discover all the datatype corispondences between COBOL and JAVA data types.

The problem with logicals is solved:
For test environment I use the in-process model and in this case the DEFINE commands must be inserted in login.com procedure of APACHE$WWW UAF profile. When I will use the production environment with the out-of-process model is possible to insert a .COM procedure in the the application's .WSI file, on the SetupCommandFile Tag.


The problem with refreshing application is solved:

Is necessary to use Tomcat Manager to unload and reload the JSP or servlet after it is modified.
This can be accessed from the main Tomcat page, or by the URL http: //node.name:8080/manager/html. This requires a login. An account can be setup in the file apache$common:[jakarta.tomcat.conf]tomcat-users.xml. I added the following line to my file:


Then restarted Tomcat. When I go to the Tomcat Manager enter in the username and password for the user that has the role of manager.

Remain only one problem, with interprogram communication: if a wrapped COBOL OBJECT call an other non-wrapped traditional cobol object, there are problems with the PERFORM THRU execution. The EXIT statement after the foot-label not return the control at the statement just follow the PERFORM statement. The EXIT statement is ignored, and all the statement from there to the end of source are executed. So the result of application is impredicable. This problem is now scaled to HP engineering. I wait for reply.

[Hein van den Heuvel]

Maurizio, Those rules 1 & 2 I posted earlier were direct quotes from the manual.
This is how it is, and how it is intended to be, so it is how it stays. This may still be relevant for your problem.
I do not have much handson experience with this, I just know several
folks were surprised by this behaviour over time.
$ help cobol proc exit
$ help cobol proc stop

I guess I would make sure to put some printout and/or lib$signal and/or sys$exit calls between a suspect 'exit program' and the next paragraph.

Hmmm, which reminds me, did you try with a compile /STANDARD=V3?

From an old (1997) note:

V2.4-919 A problem has been corrected which involved the use of the
EXIT PROGRAM statement in a local USE procedure of a COBOL main
program which was compiled with the qualifier /STANDARD=V3.
The problem was that such an EXIT PROGRAM statement did not cause the
execution of the run-unit to terminate immediately, as it does in VAX
COBOL. Instead, the EXIT PROGRAM statement was causing the execution
of the run-unit to continue by returning immediately to the main-line
code of the main program.

Good luck!
Hein.