Conference csc32::consolemanager

>Now before anyone jumps down my throat about old versions and 
>unsupported operating systems, I *know* this is ancient, and the 
>customer sort of does too, but someone somewhere stuck us in a sticky
>situation so having to support this I'm just begging for any help
>I can get. 

>Customer has a MLS+ system, 3.1a, this is based on digital unix 3.2d.
>It is running POLYCENTER Console Manager V1.5 (yeah, antique).
>This is fine. 

>Customer has another system the same, same opsys, same versions, and 
>it too is fine if he manually adds nodes to the database. 
>
>However if he exports the database from machine 1 and imports it on 
>machine two, although it appears to import fine it has one small 
>problem. 

>When it comes up the icons do not "white over" he cannot connect 
>to the system because he doesn't get given the option of connect to 
>system cause the system icon is inactive.
    
    Hmmm...... it sounds like it isn't enabling the systems. Do the following 
    command:
    
    console -d -a
    
    Post the results or tell me what you see in the "STATE" field.

>They are set up to use telnet and he can sucessfully telnet to the 
>port outside of PCM. 


>So my question is:-   What is there that a manual addition of a 
>node to the database does that an import of a database doesn't, 
>and is it possible for him to do whatever this missing bit of 
>setup is himself so he can get this working without having to 
>manually reenter all the nodes into the second machines database.
>
>?????????

>I know this all dates back to before the company made the 
>interesting decision that we didn't need Simon et al in Reading, 
>however I guess I'm hoping someone (Dan? Dan! are you out there Dan!?!)
>will have come across this and remembers that there's a such 
>and such somewhere you need to reconfigure/add to the kernel
>/change the permissions on. 
    
    I really think the systems are disabled in the database. It's been so
    long since V1.5 I cannot remember if there was a bug in import that
    caused this. You can also go into the config editor and look see if the
    nodes are set "enabled".
    
    Also what happens if you try to use the CONNECT interface from the
    command line?
    
    Regs,
       Dan

Thanks lots... 

state is TYE 

I'll type the rest of the output in tomorrow 
(gotta rush tonight!) 

Jo. 

    I thought of something else. Tru renameing or deleting the .consolec3rc
    in the users directory. Go into the C3 and see what you get. Also,
    are the usernames identical between the two boxes? Yes, you said that
    you can add them from scratch and they work but the quesion is still
    valid. They may be using an account that has no access to any of the
    systems and they then use another account to edit the database, add
    them from scratch and then use the C3. What happens if you login to
    root?
    
    Regs,
      Dan

Full details from the customers fax: As you can see he's put
in a bit of effort himself at narrowing it down thankfully:



_________________________________________________________________________________

I have reproduced the problem with V1.6-100 on OSF3.2D1. 
Additionally I have simplified it to the following.

1. Create a system using the C3 interface, after reconfiguration 
the icon turns white and is connected - so far so good.

2.  Using Console -E export the system to a file. 

3. Using Console -E delete the system. 

4. Using console -E import the file. 

5. Start up console C3 and reconfigure. 

6. Icon refuses to turn white and does not allow connections.

The only way around this is to delete the system and add it 
again using the editor within C3. 

This seems entirely reproducable.  On V1.5 I have more grief 
with hanging processes, core dumps etc which can make it tricky
to demonstrate .  But I believe the same problem exists. 

The output of console -d -a on both systems looks like the following 
when connection is not possible. 


---------SYSTEM----------PID------STATE-- ----BYTE- --LINES- -EVENTS ----------------USER----------
1       test             1039       TYE          1      0     2
and when it is possible
1       test             1039       TYE          1      1     2


This is an excerpt from the exported file:

DELETE_SYSTEM:
	NAME: test
	END: 

ADD_SYSTEM:
	NAME: test
	INFO:
	PRIMARY_HOST: fxws58
	FAILOVER_HOST: fxws58
	CONNECTION_TYPE: TELNET
	TERMINAL_SERVER: fxter02
	LISTENER_NUMBER: 2001
	SCAN_NAME:
	ICON_FILE: Generic.xbm
	LOG_DATA: Y
	LOG_DIRECTORY: /var/opt/console/logs
	ENABLED: Y
END: 

This is the del & import sequence:

PCM Edit> delete system test
test deleted
PCM Edit> import system.PORT
Unable to delete system test, no such record!
PCM Edit> show system test
Full or Brief Listing? [f=full, b=brief] (b):f
Output file (stdout): 

System Name 		= test
	Information	= 
	Connection	= TELNET (terminal server)
	Terminal Server	= FXTER02
	Listener Number	= 2001
	Scan Profile 	=
	Icon filename	= Generic.xbm
	Console line 	= Enabled
	Logging is enabled, directory = /vat/opt/console/logs

    I don't have a DUnix box to test this on. Also, we would want to test
    against V1.6-312. This patch is now available from
    CSC32::PCM$KITS:PATCH312.TAR. If someone could load this up and try the
    customers experience I would appreciate it.
    
    One final questiont ot he customer is what happens if you try to
    connect to the system from the command line.
    
    Regs,
      dan