Dibol & CGI

[Willem Grooters]

Weird problem!

In a web application, I use a DCL script that will at end execute an program written in Dibol that produices a report in HTML (or XML) format.
I have several webservers running in parallel (for testing), but each uses the same procedures, code, executables and dataas the others. You _would_ expect the same results: valid HTML for each.
Using OSU or SWS produces the expected output. Using WASd hoever just gives two spaces on each line and that's it. No error!
I've seen the same behaviour with Dibol programs that write to standard output, when running as a netwerk process or in batch it happens as well (but I have to confirm éxactly when and where), but running interactively, there is no problem at all.

Redefine of SYS$OUTPUT to TT doesn't help: Invalid Channel.

What causes thsi behaviour and how to overcome it (without extensive re-programmming...)

(VMS 7.3-2, Dibol 5.6.7 (development) 7.5.1 (execution - but the same has been found using 5.7.6), OSU 3.8, SWS 1.3-1, WASD 9.1.4)

[Willem Grooters]

Forgot to say: I'm already contacting Mark Daniel (WASD author) on this issue.

[Wim Van den Wyngaert]

Willem,

THE moment to try the excellent WATCH utility (in server basics).
What do you see in view source (in IE) ?

Wim

[David Jones_21]

What is the RMS file format produced by the Dibol script?
WASd might be trying to bypass RMS and not cover correctly the full range record formats.
If so, a simple tweak to the Dibol program would likely fix it.

[Willem Grooters]

Wim,
Mark hinted to that from the beginning (and I LOVE the feaure!)
David,
I cannot tell - it's probably somthing internal to the RTL; having said that, I don't think it'll be a "simple" tweak.
UPDATE:
I've been told that SWS writes to a BG device (so TCPIP traffic - quite obvious for a Unix program), OSU writes to NET: (obvious since it uses DECNet) and WASD writes to an MBX device (obvious for a non-decnet VMS program). Network processes could well use a mailbox as SYS$OUTPUT so that explains why the same thing happens there.
By deduction on what facilities are available, it's very well possible that the software we use (an external library) uses SMG for output, and that should now be bypassed. NOT an easy tweak, I guess.

[Wim Van den Wyngaert]

Willem,

And what about directing output to a file a doing a type of that file ?

Wim

[Willem Grooters]

In gateway.com:
@subproc "''report'"

and there:
$ define/user sys$output sys$scratch:x.x
$ mcr cgi_report 'p1'
$ type sys$srcratch:x.x

Data is still wrong: just spaces.
Even the interactive version that runs fine in batch as well, gives spaces in this case.
Doing this in the sub-script:

$ define sys$output sys$scratch:x.x
$ define sys$input sys$command
$ mcr run_report 'p1'
1
j
$ type sys$srcratch:x.x

will give a warning when run by the gateway:'

$ define sys$output sys$scratch:x.x
%DCL-W-SKPDAT, image data (records not beginning with "$") ignored
$ define sys$input sys$command
$ mcr run_report 'p1'
%DCL-W-SKPDAT, image data (records not beginning with "$") ignored
$ type sys$srcratch:x.x

[Wim Van den Wyngaert]

Willem,

When you did the TYPE, sys$output was still directed to the file. You have to do define/user.

I've read that SMG outputs in a faulty way (TCPIP does it too with SMG : try ucx show comm and watch what you get when you edit the output file).

If you create the file first as stream, it seems to work (but tcpip opens the file as erronious as append).
$ create/fdl=sys$input x.x
record
format stream
$ tcpip show comm

So, I guess you need to set the file to stream with set file/at=rfm=stm x.x.

Wim

[Willem Grooters]

I succeeded in making a small program that effectively does just that what the program in question does: Getting input from one file, and rewriting is - after CRLF has been removed - to SYS$OUTPUT. For this, it uses third-party routines - and given the nature of these routines, I suspect output is written using SMG-routines. It might be that removal of CRLF causes trouble. Writing output using lib$put_output works, even with removal of CRLF.

Digging even deeper: the program has not been build correctly and so it did not use lib$put_output where it should have. So I tried to build it properly - and the program crashed with ACCVIO.
It must have been as such for ages....Time to investigate and solve the issue propely!

But surely, it's a SMG-issue, because that's just the difference between the crashing program and the wrongly built one.

[Willem Grooters]

It's even more trivial...
Drilling deep into the code (including reversed engineering) lead to value returned by LIB$GET_FOREIGN.
The program is started with options, and LIB$GET_FOREIGN is used to retrieve them from the commandline, and all three webservers (OSU. SWS and WASD do return the remainder of the commandline. But where OSU and SWS did return the values in uppercase, WASD returned them in as specified: in lowercase. Since control of required options is done with an uppercased string, these are nmot foud when running under WASD.
If the options are specified in uppercase in the script, the program went flawlessly in WASD as well.

I wonder: do OSU and SWS process the CGI-procedure before processing? I didn't look into that. But it's good to know this difference.