unable to start LPD CLIENT

[Volker Halle]

Jan,

TCPIP$LPD_STARTUP.COM includes quite a couple of commands. Exactly which one is giving the STARTFAIL/NOSERVREC error ? Which image and which shareabale libraries are used by that image reporting the error ?

I would assume, that the string 'LPD_CLIENT' should somehow be stored in that image. The string 'LPD_CLIENT' must certainly be a parameter for these 2 error messages. Any piece of TCPIP V5.4 ECO 4 software, which would still be using the string 'LPD_CLIENT' would be very suspect.

There are still a couple of un-answered questions, please re-read my previous posts.

As nobody seems to yet have seen this error, the problem solution mainly depends on the quality of the information you're supplying.

Volker.

[Walter Miller_1]

Maybe it would be worthwhile running sys$manager:tcpip$config.com. When you select LPR/LPD configuration under the "Server Components" menu the procedure runs several checks including to be sure the service defined in SYSUAF, TCPIP$SERVICE database and that the application proxy is enabled.

You might want to disable then enable the service through the menu and let it do all the necessary checks.

[Jan van den Ende]

AAAARRGH!!!

Sea my original post:
>>>
I am sure that it will be too trivial to enter into a manual, but we are at a loss right now.
<<<

As trivial as removing PRINTCAP.

Generate a new one.

_NOW_ the service start up, just re-enter all wanted data.

So,

-- STARTING the service does some (which?) checks on structure of or syntax in PRINTCAP, and refuses to start of failure. Does not seem to do ANYTHING with that data.
-- START/QUEUE READs and USES the data, obviously without, or with much less stricct, caring about structre and/or syntax.

I would expect such inconsystencies in m$ware, and to a lesser extent in U*x, but where is the logic in that? Seen trough VMS-tinted glasses?

Anyway,
thanks all that have contributed. You were all as mis-guided as I was.

Proost.

Have one on me.

jpe

[Jan van den Ende]

See above.

Proost.

Have one on me.

jpe

[Jan van den Ende]

Re my post of 10:10:59 GMT

What clumsy typing!

I spotted so many errors, but I think (hope) you can get the meaning nonetheless.

I DO intend to spend some more effort in proof-reading in the future (but that is still no guarantee).

Proost.

Have one on me.

jpe

[Jan van den Ende]

Hi,

some more hindsight info, & extra kinks.

- by default, the princap file resides in SYS$SPECIFIC
The is rather unwanted in a homogeneous cluster, and TCPIP$LPD_PRINTCAP can be defined to point to one single file.

Gotcha: if that definition, or the definition of the device or directory where it points to (directly or indirectly) is _NOT_ in EXEC mode in the LNM$SYSTEM_TABLE, then you have the perfect recipe for hte above trouble.

Bottom cause: we had that logical (as well as the concealed device where it points to) in the LNM$SYSCLUSTER_TABLE.

Note, that LNM$SYSTEM is a searchlist containing both, but that _NOT_ good enough, it has to be explicitly LNM$SYSTEM_TABLE.

Well, with this info I hope that somebody running into this issue will be able to solve it much more quckly.

Proost.

Have one on me.

jpe

[Jan van den Ende]

I solution WAS found, so I decided to add a bunny for those seeking answers that have already been found.

Proost.

Have one on me.

jpe

[Jan van den Ende]

.