| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2328.1 | It is in the PC | TOOK::R_SPENCE | Nets don't fail me now... | Wed Feb 12 1992 13:08 | 11 |
| Bear with me. I don't know much about PCs so don't know what the
current versions of software are, but, I do remember this problem
showing up last summer and I believe the DECnet DOS folks traced it
to a bug in NML on the PC (it might have been another componant - it
was a long while ago - but was a DECnet DOS problem).
The problem was that it didn't deallocate stuff correctly when it
cleaned up after an attempt by MCC to open multiple logical links
and after that the PC wouldn't let any get opened.
s/rob
|
| 2328.2 | has DNA4 AM changed a bit w/1.2 also? | TOOK::MCPHERSON | Scientific progress goes 'Boink!' | Wed Feb 12 1992 13:13 | 6 |
| Also, are the probs referenced in .0 based on DECmcc V1.1 (or earlier) ?
I seem to remember something about the DNA4 AM being changed somewhat w/1.2 to
better accomodate resource-scarce entities (i.e. DECrouters and PCs). Or was
that a flashback? ;^)
/doug
|
| 2328.3 | pb appear only on PWKS 4.1 | CLPR01::LOUIS | | Thu Feb 27 1992 12:24 | 18 |
|
Hi,
The problem appear only with Pathwork 4.1. We try Pathwork 4.0,
with the same pc (DECstation 325) and the registration was successfull.
The problem is the same with DECmcc FT1.2.
Does any body have more informations about this problem ?
I suppose that pb come from NML on PWKS 4.1 ..?..but is it sure ?
Tank's
yves
|
| 2328.4 | DECmcc/DNA4 AM and DECnet/DOS for PC | ZTOIS1::VISTA | Renato VISTA, SIS Strasbourg, France | Mon Mar 09 1992 09:41 | 125 |
|
Hello,
I'm working on an EMA/DECmcc V1.1 for VMS and I want to manage DECstations via
DECnet IV Access Module.
Althought NML object has been installed, I've got the same problem as
described in MCC notes as following but I've not found any solution nor patch
to run DECnet IV AM correctly with DECstations.
Have you got any idea about that problem (Insuffisant resources on target
entity i.e. DECstation 325 + DECnet) ?
Thank you very much for your help !
Renato VISTA
================================================================================
<<< NOTED::DISK$NOTES4:[NOTES$LIBRARY_4OF5]MCC.NOTE;1 >>>
-< DECmcc Network Management Product Family >-
================================================================================
Note 2328.0 PC Registration: Insufficient resources at remote node 3 replies
YUPPY::HEPWORTH 43 lines 12-FEB-1992 11:56
--------------------------------------------------------------------------------
This note has been cross-posted in the PATHWORKS conference, any help
appreciated.
Thanks
Bev...
<<< RANGER::$2$DUA8:[NOTES$LIBRARY]PWDOS4.NOTE;1 >>>
-< PATHWORKS for DOS/VMS 4.X >-
================================================================================
Note 1871.0 Insufficient resources at remote node 1 reply
YUPPY::HEPWORTH 17 lines 12-FEB-1992 11:31
--------------------------------------------------------------------------------
I have a two PCs running PATHWORKS for DOS 4.1 on Token Ring, with a
4100+ connecting the TR to Ethernet. Both PCs are running NML. From
NCP on a VAXstation on the ethernet, I can do NCP> tell pc show exec
char, etc.
I then try to register the PC as a DECnet node in DECmcc. This fails
with the error message Insufficient resources at target entity. If I
then try the NCP> tell pc show exec command again, this then fails with
the error message Unable to connect to listener, insufficient resources
at remote node.
The questions are: What resources are being used up, and is it
possible to get around this problem?
Thanks in advance,
Bev...
================================================================================
Note 1871.1 Insufficient resources at remote node 1 of 1
YUPPY::HEPWORTH 4 lines 12-FEB-1992 11:50
-< more info >-
--------------------------------------------------------------------------------
BTW, we have the same problem with PCs connected to Ethernet (no Token Ring
involved at all) ie insufficient resources at remote node.
================================================================================
Note 2328.1 PC Registration: Insufficient resources at remote node 1 of 3
TOOK::R_SPENCE "Nets don't fail me now..." 11 lines 12-FEB-1992 13:08
-< It is in the PC >-
--------------------------------------------------------------------------------
Bear with me. I don't know much about PCs so don't know what the
current versions of software are, but, I do remember this problem
showing up last summer and I believe the DECnet DOS folks traced it
to a bug in NML on the PC (it might have been another componant - it
was a long while ago - but was a DECnet DOS problem).
The problem was that it didn't deallocate stuff correctly when it
cleaned up after an attempt by MCC to open multiple logical links
and after that the PC wouldn't let any get opened.
s/rob
================================================================================
Note 2328.2 PC Registration: Insufficient resources at remote node 2 of 3
TOOK::MCPHERSON "Scientific progress goes 'Boink!'" 6 lines 12-FEB-1992 13:13
-< has DNA4 AM changed a bit w/1.2 also? >-
--------------------------------------------------------------------------------
Also, are the probs referenced in .0 based on DECmcc V1.1 (or earlier) ?
I seem to remember something about the DNA4 AM being changed somewhat w/1.2 to
better accomodate resource-scarce entities (i.e. DECrouters and PCs). Or was
that a flashback? ;^)
/doug
================================================================================
Note 2328.3 PC Registration: Insufficient resources at remote node 3 of 3
CLPR01::LOUIS 18 lines 27-FEB-1992 12:24
-< pb appear only on PWKS 4.1 >-
--------------------------------------------------------------------------------
Hi,
The problem appear only with Pathwork 4.1. We try Pathwork 4.0,
with the same pc (DECstation 325) and the registration was successfull.
The problem is the same with DECmcc FT1.2.
Does any body have more informations about this problem ?
I suppose that pb come from NML on PWKS 4.1 ..?..but is it sure ?
Tank's
yves
|
| 2328.5 | working on it. | MRMIPS::Lichtenberg | Notestuff: The *real* PC-Notes! | Mon Jun 29 1992 17:15 | 23 |
|
Howdy.
I'm trying to fix the CLD UVO_0868 which has to do with
registering PC nodes in DECmcc.
Well, I can't seem to get MCC running enough to do the
registration -- some questions:
If I do MCC> SHOW DOMAIN *, I get "DNS-E-NOCACHE, client
cache file not initialised"
I can't seem to open or create any domains. I always get
"Entity not valid. please check spelling."
Could someone help me figure out why MCC won't run properly so I
can fix this problem in PATHWORKS? (or at least look into it)
/Mitch.
(RANGER::LICHTENEBRG)
|
| 2328.6 | two people working on same problem? | BIKINI::KRAUSE | European NewProductEngineer for MCC | Tue Jun 30 1992 12:45 | 35 |
| I just sent the following mail to Jerry RAINBO::CLEMENTS. This applies to
CLD MUH-02167 which seems to be the same problem. The first half was
cured by the patch DNNETH.4_4_063. The rest currently is being
worked on by Jerry.
*Robert
It seems that a lot of information got lost along the way of this call. As the
specialist that originally worked on this call (DECmcc) I will try to briefly
explain what the problem is and how it was cured. Please forgive me if I don't
use the correct PC terms.
On a request for "SHOW KNOWN CIRCUITS" PCSA 4.1 returns the circuit name ETHER-1
with trailing blanks (total length 16 bytes). This is not a problem for display
only applications like NCP. But MCC during registration uses the returned
circuit name to issue the equivalent of "SHOW CIRCUIT <what it got> CHAR" and
the PC rejects this second request with "illegal circuit name" because of the
trailing blanks.
The fix was a patch to DNNETH.EXE. We simply patched the blanks following the
circuit name to binary zeroes. This caused the circuit name to be returned
without padding. BTW: in PCSA 4.0 the circuit name in DNNETH.EXE was padded with
zeroes, therefore the problem did not show up.
This looks like a classical C programming problem, i.e. assuming a zero
terminated string and ignoring the length field (which is correct in both
versions of PCSA).
Hope this helps to fix the problem on source code level.
*Robert
PS.: I do not know the distribution list for this call. So, please, forward this
mail to the appropriate distribution list. Thanks.
|
| 2328.7 | | PHOTON::Lichtenberg | Mitch Lichtenberg | Wed Jul 01 1992 10:36 | 26 |
|
Robert,
Jerry Clements manages the CLD's. I'm the engineer that wrote
DNNETH, and I'm assigned to fix it.
The problem with the trailing blanks is that fixing it in DNP isn't
enough, though I plan to do a workaround in DNP as well. True, DNP
was returning trailing blanks, but the length field _was_ being
returned properly, at least it was supposed to be. Anyway, the
blank-padded names get transferred into the DECPARM.DAT (permanent)
executor database file by NCP when the PC is first configured, and
are read back in on subsequent reboots, so changing it just in the
template data might not be enough. I'll see what's involved in
modifying DNP to null-terminate the circuit name on each reboot, no
matter what is in the file.
/Mitch.
PS: DNP's written in 8086 assembly language. It's a classic
assembly programming problem :-) :-)
|
| 2328.8 | P/works V4.1A PC's now register OK. | GIDDAY::BROOKS | | Tue Sep 01 1992 23:45 | 10 |
| Hi,
I have just received the new Pathworks for DOS V4.1A. I have loaded
it on My PC and have successfully managed to register and show circuit
counters for both DECMCC V1.1 and V1.2.
Regards,
Niguel Brooks
|