26-Oct-2005

The usual SOAP
(What happened since last episode)
A problem with the client is that the WSDL (WebService Description) that is created by AXIS cannot be handled by the .NET development environment, so the creation of a test client is blocked.
How to overcome this? I mailed it to a mailing list (axis-user@ws.apache.org), got an answer (including a German website with a lot of (English) information), but have to wait for an opportunity to check it out.
When the application code was generated on OTVMS1, a 7.3-1 system, one file was created where the classname exceeded 39 characters, and the filename was chopped to these 39. Renaming the file to the right name caused failures: the compiler failed to read it. So I had to change a number of sources before I got it compiled.
Had discussed this with Brad, and a question to upgrade to AXIS 1.3 (current).
Updated the commandprocedures to set the right environment varaibles and logicals for test and application, to match the physical environment on Diana (which is different than OTVMS1).
(Today's episode)
Got an answer from Brad on the Java issues, and gave him the answer it's weird that a file that should be named over 39 characters was chopped. Even on an ODS-5 disk, where case preservation worked (so it must be a ODS-5 disk anyway). Anyway, it IS consistent: java cannot create such a file, nor read it.
Brad also found out that update to AXIS 1.3 should not be a problem. "Just try".

Back to the real job (well, locally).

Job is to get it all built on Diana, environment must now be correct (just a physical difference, not a logical one).
Starting with the test sources.
NO WAY.
They don't compile. Because of variable format with carriage return carriage control? Might be a problem for java. So changed them to stream-lf and no record atributes - but that didn't help. The compiler seems to read the source as one line, and find illegal characters: \18, \0 - quite a number of them. Even worse: the files could not be edited: Input line (> 7000 bytes) exceeds user buffer.... get the files from OTVMS1; there may be something gone wrong with expanding the zipfile.

Turned to the application code and just tried brute force (invoke the building procedure) and pray for the best.
They all compile without ANY change.
Decided to give this long-named file a try on Diana, and found an unexpected difference with OTVMS1: On Diana compilation of a file with a name exceeding 39 characters succeeded without a problem, and checking the files's attrributes, found that though all files are variable format, carriage return carriage control, the Java compiler takes them.
That's the way I like it!!!!
On VMS1 though, the sources are all stream-lf and have carriage return carriage control. I haven't tried there (and won't since it compiles there AND files are editable)
The behaviour of Java is weird, at least, not consistent.
Or is it the C-runtime library? After all, VMS versions are different.

Back to the test sources: changed the format to variable and implied CC (carriage return carriage control) like the application sources. Compilation failed again, but differently: Now read line by line, but the same errors. DUMP/RECORD showed the reason: the files seem to have been VFC (Variable with Fixed Control): each line is preceeded with a word size (00 12 hex) which is (per byte) 0 and 18 decimal. Edited the files (luckily they are small) and behold: they compile.
But for one.
The biggest file does not compile. Changed that to stream-lf (just that), found it editable AND it did compile....
Mailed my experiences to Brad to pass the info.
(Preview)
Try out what has been specified to show the right WSDL on OTVMS1
Get the thing deployed on Diana - I now know how to do it.
Update to AXIS 1.3 - must be easy to do.