Taking UCX SH COMM output to a file

[Sk Noorul Hassan]

Hi,

I want to take the output of UCX SH COMM to a file which can be further used for OPEN/READ by VMS program. I have tried by assigning SYS$OUTPUT but the output file is not comming in standard text format. If you TYPE that file, it looks OK but if you edit it, it shows lots of escape caharacters in it which is not usable for OPEN/READ by VMS program.

Pls suggest

[Joseph Huber_1]

Well, there are no escape-characters, just embedded carriage-control , namely pairs to format the output. After all, it is designed for terminal output, not for program input.
It is not convenient for parsing (and anyhow may change in future versions of TCPIP services).

What do You want to achieve ? Maybe there are other ways to get the information.

[John Donovan_4]

You can try using the SET FILE/ATTRIBUTE=RFM:STMLF command on the "DEFINE SYS$OUTPUT" file. This converts the file to Stream_LF which should work. It worked for me. If not there are some good DCL procedures located on Google Groups if you search for "" +OpenVMS which convert the file using FDL.

[Ian Miller.]

strictly the SET FILE/ATTR does not convert the file but changes how it is processed by changing RMS view of it.

[Jan van den Ende]

Hassan,

let me try to explain what the others said.

First, unlike UNIXes en Micro$oft Operating Systems, VMS knows of, and can handle, a lot of different ways to organise data into a file.
For Unix, a file ALWAYS is a stream of bytes, with a character separating records in text files. ANY other interpretation of the data MUST be known to the programm that reads the file, and is determined by that program ALONE.
For M$, it is the extension to the filename that (nearly) madatorily determines the type of content, and so, the programm to use on the file. For text files, that extension is .TXT, and those may be read with, eg, Notepad or Weird, (sometimes named Word).
For VMS, MUCH more info about the file is held in the File Header. One of things the header describes, is HOW the data in the file should be interpreted.

And now comes the "big fun" with programms that are ported (mostly from Unix): there is no way for those to know about the structure of the file.
Most notorious of these is FTP (because it is used to transfer files from other systems, that do not specify how they are to
be treated).
The least un-safe way to handle such files is to not do anything, and just fransfer byte-by byte ("Image transfer mode"). If it is KNOWN that the file contains just text records, then the user can set "ASCII transfer mode". Now, essentially, the processing goes record-by-record, and the record separators are added one way, and treated correctly the other way. The FTP info output itself will be separated records, which is quite ok for terminal output. But, recording that into a file, FTP is too stupid to let VMS know about that, so VMS creates a file with the default settings for command output.

It is comparable to TELLING you that this text is in Dutch, and your interpreter (your programm that processes it) has to translate it from Dutch into .
The result will be hard to understand, just like you experienced.
Now, if I leave this text as it is, but tell your interpreter it is in English, suddenly everything becomes understandable.

The interpreter in this story is RMS (VMS's Record Management Services), and John's "SET FILE/ATTRIBUTE=RFM:STMLF" is telling it, that in this case the file consistst of records, separated by characters, with the record lengths determined by the distance between the characters.

Note: now the will still be part of the record. So, the result will be even better, if you tell it that the record separator is
Try using HELP to determine how to change the SET FILE command to do that.

Hope this helps,

Proost.

Have one on me.

jpe

[Joseph Huber_1 · Accepted solution]

Friends, a lot of explanations, but not a solution for the original question:
The define sys$output produces a standard VMS variable length output, and the are part of the data (because TCPIP formats it for the screen). Just setting the record format to STM gets rid of the , but then there are the original record headers remaining , and the problem of parsing the data remains (and is even worse, because now the contain unprintable characters, because VAR record headers are 16bit integers, try and see !).

The only eventual solution could be to CONVERT the file using a RFM=STM output FDL.
Like:
$ define/user sys$output tcpip.tmp
$ tcpip show communication
$ convert tcpip.tmp tcpip.stream/FDL=sys$input
FILE
ORGANIZATION sequential
RECORD
CARRIAGE_CONTROL carriage_return
FORMAT stream
$EOD

Then the result file tcpip.stream is clean text.

[Joseph Huber_1]

Correction to my reply: the $EOD is correct if the above sequence is in a command-file, replace it by control-Z if typed interactivly !

[John Gillings]

Sk,
Maybe you could use PIPE? You may not even need an intermediate file.

If that's not feasible, rather than CONVERTing your output file, you can usually make DCL append an existing file, and get the characteristics you want. For example, in this case:

$ CREATE/FDL=SYS$INPUT TCPIP.OUT
RECORD
FORMAT STREAM
$ OPEN/APPEND OUT TCPIP.OUT
$ DEFINE/USER SYS$OUTPUT OUT
$ TCPIP SHOW COMM
$ CLOSE OUT

[Sk Noorul Hassan]

John Gillings ,

I tried as per the example but it seems some line or command is missing as it is not comming to DCL prompt after
$CREATE/FDL=SYS$INPUT TCPIP.OUT
RECORD
FORMAT STREAM to give further commands.

Joseph,
Your help has solved my problem and I got a clear text file, thanks, cheers...

John Donovan,
Your help also has solved my problem for using F$extract lexical but is still part of the file and is not a clear text file. Cheers..

Jan,
Thanks for your explanation of the subject and It is good..bye..

[Bojan Nemec]

Sk,

If you are typing commands on a terminal, type after the FORMAT STREAM line.

In a DCL procedure there is no need of this.

Bojan

[Jim Geier_1]

One of the slightly annoying "features" of TCP/IP Services is that when you define/user sys$output to a file, and that file exists, the output from the Tcpip command will append to the file. This allows the simplification of the procedure as presented by John Gillings to the following:

$ create/fdl=sys$input tcpip.out
RECORD
FORMAT STREAM
$ define/user sys$output tcpip.out
$ tcpip show comm
$ exit