[Info-vax] OSU Web Server on OpenVMS VAX 7.3: SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Sat May 19 15:33:10 EDT 2018


On 2018-05-19 18:35:53 +0000, tuklu_san <\"supratim sanyal said:

> On 5/19/2018 13:45, Stephen Hoffman wrote:
>> 
>> https://groups.google.com/d/msg/comp.os.vms/OMoa3bTU0I0/_92DMhn3qSsJ
> 
> Thanks Stephen for the pointer. I forgot to mention I am using Phase IV.
> 
> Defining/Setting the task object does not seem to be enough, 
> unfortunately. Am I am missing something else as well?
> 
> 
> $  mcr ncp define object task number 0
> $  mcr ncp set object task number 0

That should never be necessary.

> Known Object Permanent Summary as of 19-MAY-2018 18:32:22

That's not how this works.

This is about the so-called task object.   The task object is a way to 
avoid defining a so-called known object,  Go read about known objects 
and task objects, and it's probably better to avoid using the NCP 
DEFINE command for now.

The task object is a DCL procedure that exists in the default directory 
of the specified username.  It must be present and it must also be 
read-accessible and executable.  This is the WWW_INIT.COM file, in this 
case.

Related reading and a complete client-server example:  
http://h41379.www4.hpe.com/wizard/wiz_0159.html

There's usually a log file created in the target directory as well, if 
the target directory is correctly writeable.  Usually NETSERVER.LOG and 
NET$SERVER.LOG on Phase IV/IV+ and Phase V, or use DIRECTORY 
/SINCE=TODAY *.LOG or however the log file can be identified and 
located.

When presented with an error on OpenVMS, see HELP/MESSAGE NOSUCHOBJ and 
such.  In this case, go troubleshoot the NOSUCHOBJ error.    Check for 
a missing file, and check the protections on the DCL procedure 
WWW_INIT.COM and on the parent directory, and look around in the login 
directory for a log file, and look for problems within the SYLOGIN.COM 
file and the target OSUHTTPD user LOGIN.COM file for network-mode 
access; put an $ EXIT or a if-network-mode-then-exit (IF F$MODE() .EQS. 
"NETWORK" THEN GOTO EXIT) very near or at the top of each of these 
procedures and see if things work better, though details on those sorts 
of SYLOGIN and LOGIN command errors are almost always included in what 
gets logged in the connection log file in the target OSUHTTPD user 
directory.

There are four modes, INTERACTIVE, NETWORK, BATCH and OTHER, and 
different modes allow different DCL commands.  Some commands will not 
work (will report errors) in some modes.  Sometimes you want to do 
different things in different modes, such as how the XQTYPE.COM 
procedure operates in INTERACTIVE mode and how it works in NETWORK 
mode.   When constructing SYLOGIN.COM and LOGIN.COM (or a DCL procedure 
being used as a DECnet object), choose wisely which commands execute in 
which modes.

http://h41379.www4.hpe.com/wizard/wiz_2328.html
http://h30266.www3.hpe.com/odl/vax/opsys/vmsos73/vmsos73/9996/9996pro_033.html



-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list