LANCP Outputting Strange Formatting Characters

[Jack Trachtman]

VMS V7.3-2

I'm working on a script which includes a PIPE cmd to capture the output from LANCP and format it. I noticed that I was getting an extra blank line in my output, which I eventually traced back to LANCP. When I enable "show control characters" in my terminal emulator I see the following:

$ run sys$system:lancp
)0[4l=LANCP>

Is LANCP using the Screen Management calls for some reason? Any ideas on how to suppress this or somehow swallow it?

Note that the blank line doesn't show when I execute the PIPE cmd at the DCL prompt, but does appear when I run the PIPE cmd within a script. The actual cmd I'm using in the script is: $ LANCP SHO DEV EWA0/COUNTERS

TIA

[Hein van den Heuvel]

Hi Jack,

Those escape sequences are soft resets for things like the graphics character sets.

Looks like LANCP.EXE gets them from SYS$SYSTEM:TERMTABLE.EXE

You can make'm go away with SET TERM/LA36
Of course that's too brute force to be practical, but it gives you a direction.
I also tried /NODEC_CRT but it needs more bits cleared than that.

Can you spell out how to get those characters into a pipe? A simple command file did not work for me.

For yuks I did a poor mans 'strings' on lancp.exe but did not spot something that could be a logical name to control this.
Of course it might come from some CRTL call LANCP makes and it could be one of the 100 or so DECC logicals that are tested.

Cheers,
Hein.

[Jack Trachtman]

Hein,

A script with the below two cmds shows the problem - a blank line appears before the SEARCH output.

$ LANCP :== $LANCP
$ PIPE LANCP SHO DEV EIA0/COUNTERS | SEARCH SYS$PIPE BYTES

I tried adding SET TERM/DEV=LA36 to the above but it did not help.

[John Gillings]

Jack,

I think I remember reporting this behaviour of LANCP in a pipe as a bug back a few years. It may have been fixed in a more recent version of OpenVMS.

If it's still doing the same thing on V8.3, please report it again. More complaints means more chance it will be fixed.

[John Gillings]

Curious...

V7.3-2 system with LANCP

Image Identification Information

image name: "LANCP"
image file identification: "X-65A2"
image file build identification: "XA99-0060111012"
link date/time: 3-AUG-2005 15:20:00.53
linker identification: "A11-50"

I don't see the behaviour you describe:

$ PIPE LANCP SHO DEV EIA0/COUNTERS | SEARCH SYS$PIPE BYTES
53370861058 Bytes received
53742261347 Bytes sent
844894470 Multicast bytes received
260654470 Multicast bytes sent


I also traced SMGSHR calls:

$ @fake_rtl smgshr
Defining FAKE_RTL environment
%COPY-S-COPIED, SYS$COMMON:[SYSLIB]SMGSHR.EXE;1 copied to DKA100:[FAKE_RTL]REAL_SMGSHR.EXE;1 (571 blocks)
Generating symbol vector for SMGSHR
%ANALYZE-I-ERRORS, DKA100:[FAKE_RTL]REAL_SMGSHR.EXE;1 0 errors
Generating MACRO code for SMGSHR
Compiling FAKE_SMGSHR
Linking FAKE_SMGSHR
$ define fake_dumpargs true
$ fake_smgshr
$ PIPE LANCP SHO DEV EIA0/COUNTERS | SEARCH SYS$PIPE BYTES
53370861058 Bytes received
53742261347 Bytes sent
844894470 Multicast bytes received
260654470 Multicast bytes sent
$ ty FAKE_ARGDUMP.LOG
Arg tracing started at 26-OCT-2007 09:03:26.13
exit status: 00000001

This indicates there were no calls to SMGSHR.

Link date 2005 is way after V7.3-2. Maybe you need a more recent LAN patch?

[Jack Trachtman]

John,

Did you run your test via a script versus directly entering the PIPE cmd? As I mentioned, the blank line only appears when the PIPE cmd is executed in a script.

I just looked at the output on an v8.3 system and the same problem occurs.

[John Gillings]

Jack,

Yes, I tried a command procedure and also a batch job, with and without the fake rtl stuff. No blank lines.

ITS250_ASX> @pipecheck
53456088104 Bytes received
53812757228 Bytes sent
846171816 Multicast bytes received
260976096 Multicast bytes sent

ty sys$login:pipecheck.log
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
Setting output rate to 1 second...
Defining FAKE_RTL environment
53460847030 Bytes received
53816868908 Bytes sent
846235986 Multicast bytes received
260992310 Multicast bytes sent
GILLINGS job terminated at 26-OCT-2007 10:40:15.91

Aha!, just found it. My terminal had been set to device type UNKNOWN. When I SET TERM/INQUIRE (putty telnet session) it changes to VT102, and I see your blank line, but ONLY if the command procedure has already written some output (not sure why). I also see a call to SMG$CREATE_VIRTUAL_KEYBOARD inside LANCP. I'm now fairly sure I have reported this. The bug is that LANCP shouldn't be creating the virtual keyboard until it knows it needs to read input.

Here's a fairly simple workaround:

$ PIPE (DEFINE/USER SYS$INPUT NL: ; LANCP SHO DEV EIA0/COUNTERS) | -
SEARCH SYS$PIPE BYTES

[Bart Zorn_1]

Ah!

Just yesterday I was struggling with exactly that same blank line!

The blank line appears in all versions of LANCP that I know of, including the one in the VMS83A_LAN-V0200 ECO.

I will report it to HP, as John suggested.

Regards,

Bart Zorn

[Bart Zorn_1]

For those of you who are parsing the output of LANCP: VMS83A_LAN-V0200 installs a new version of LANCP, which adds the node name to the first line of each device.

Example:

$ lancp show dev eia0

SPLZ03 Device Listing, volatile database (26-OCT-2007 13:33:29.10):
Device
------
EIA0*

* Device not in volatile database

Regards,

Bart Zorn

[Hein van den Heuvel]

Jack wrote>>
"A script with the below two cmds shows the problem - a blank line appears before the SEARCH output.
$ LANCP :== $LANCP
$ PIPE LANCP SHO DEV EIA0/COUNTERS | SEARCH SYS$PIPE BYTES
"

That was the exact script I tried and re-tried, but like John indicates it did NOT give a (seemingly) blank line. Not on Itanium 8.3. But when I added a "$SHOW TIME" it did add a seeminly empty line with escape sequences.
So now I am curious! What EXACTLY did you try?
( And if what you actually tried is not what was posted then what part of "Can you spell out " did you not understand? :^).

btw... here is perl one-liner to do a unix 'strings' like command on a file.
Yeah I know it might not correctly catch string sitting over record boundaries, but it's been good enough for most usages:

$ perl -ne "while ($_) { if (/([a-zA-Z\$_\-0-9]{4,})/){print qq($1\n); $_ = $'}else{last}}" sys$system:lancp.exe > lancp.txt

The -n implies a loop loads records in $_
Then the script has a loop going over $_ looking for a match on a string of more than 4 characters from a set A..Z, a..z, 0..9, _, $, -. If found, print that, and make $_ be the old string beyond the match point. If not found then it's the laost for this record and let implied outer loop fetch next record.

Cheers,
Hein.

[Jack Trachtman]

Bart:

- Thanks for the heads up on the LAN patch


Hein:

- I didn't include "exactly" what I was doing because the 2-line example I gave illustrated the problem

- Thanks for the PERL script - it helps me understand reg expressions


John:

- You're a genius! I added your code to my script and Voila! the blank line is gone

[Richard Stockdale]

LANCP isn't doing something intentionally that results in these characters. There isn't any fix in any patch kit for it.

This is on my list of things to resolve and I hope to get to it in a few months, presumably with a patch kit to follow.

- Dick Stockdale
VMS LAN drivers

[Hoff]

Dick, this is likely SMG-level behavior, as you're doing what most every other tool is doing with SMG; take a look at a couple of other tools that use SMG (EFI$CP is one) for command-line processing, and I'd bet you'll find this same sequence in this same context. The patch might be to SMG, and not piecemeal patches to higher-level components.

The other approach would be one of avoidance; parsing command output has always been dicey, and subject to tipping over at any update or upgrade. Here, this would involve breaking out the LAN driver counters somehow; for example, generating values via DCL symbols underneath LANCP, if it's not feasible to capture and present them via $qio or $getdvi or such, or via SNMP.

[John Gillings]

Hoff, Dick,

While it would be nice to implement a blanket fix in SMG, I don't see that it's possible. If you tell SMG to prepare a terminal for reading input, that's what it does! If that involves sending output to a terminal to put it in the right state, that's what will happen.

In this case, I believe the issue is that LANCP is creating a virtual keyboard to read from the terminal, BUT it's been activated with a one shot command, so it knows it won't be necessary to read any command line input. LANCP could (and imho, should) skip the SMG call for this mode of activation. That there are other utility programs that commit the same error doesn't make it any less of a bug! (OK, I guess SMG could defer the init output until the first input operation is actually requested..., but is anyone working on SMG at all these days?)


>parsing command output has always been
>dicey, and subject to tipping over at any
>update or upgrade.

True, but it's a necessary evil in the absence of APIs to access all the data fields that people want to access. There are ways to parse which are tolerant of things like extra blank lines, different carriage control or slight changes in format.

re: reproducer. Jack, your entry which said a 2 line sript would reproduce the problem was incorrect. Please take more care in posting reproducers to save other people's time. Both Hein and I spent considerable time scratching our heads trying to figure out why we couldn't reproduce your symptom. You'll also find that creating a working reproducer will often reveal a solution or workaround.

[Richard Stockdale]

Thanks for the ideas and suggestions. It is fixed now in LANCP and will be in the next LAN patch released for any version of VMS back to V7.3-2.

The problem was the location of the SMG create keyboard call - if delayed until LANCP actually needs the keyboard input, the extra blank line goes away.

- Dick

[Bart Zorn_1]

Today I got a reply on my support call about LANCP.

There are new LANCP images available if you need them before the ECO's are released.

VMS732_UPDATE V14 does not contain this new image.

Regards,

Bart