Conference csc32::consolemanager

	I get the following error when starting console$startup:

$  @sys$startup:console$startup

               Starting POLYCENTER Console Manager Version 1.1
               ===============================================


 Defining Console Manager Logical names.


 Installing Console Manager Images.

%COPY-W-INCOMPAT, CONSOLE$ROOT:[DATA]CONSOLE_CFG.DAT;3 (input) and
CONSOLE$ROOT:
[TEMP]CONSOLE_CFG.DAT;1 (output) have incompatible attributes
$

						mike

	Renaming the file CONSOLE$ROOT:[DATA]CONSOLE_CFG.DAT to .OLD
	caused the accvio to disappear.

	I think it's time to start on reading the docs, huh? :-)

							mike

    Mike,
    
       Not sure what the problem is or was. It would appear that the
    configuration data file was corrupt, but how it got that way is the 
    mystery. There is a logical which you can turn on for debugging called
    CM$DEBUG along with associated logical names for the various modules.
    For the C3 it's DEBUG$C3 a,d for all the modules, it's DEBUG$ALL.
    
    Please let us know if this happens again.
    
    Dave

	Hi Dave,

	Is it documented the stuff about the debug logicals ?
	I'm very interested in this.
	I'm giving VCS customer support and VCS$DEBUG logical helped
	me a lot to troubleshoot customer problems.

	Thanks in advance.

	Rgds,

	Geert	

Hi,

  No, its not documented, but I see no reason why you internal
  guys shouldnt use it, please not, turning the debugging stuff
  on will cause a slight performance degradation!!

  Anyway, to turn it on you need to do the following...

  OpenVMS
  =======

	Define/System CONSOLE$DEBUG xx

  OSF/1 & ULTRIX

	setenv CONSOLE_DEBUG xx


  Do the definition BEFORE you start Console Manager (on any
  platform).

  The value of xx will be a string containing one or more
  of the following items (some are self explanatory, the
  others I will indicate what they do)...

	ALL	- this turns on everything, effectively all
		  the ones below

	API	  - debugging for the callable interface
	ENS	  - for ENS
	SHM	  - for the shared memory routines
	C3	  - 
	EVENTLIST - 
	DAEMON	  - Console controller daemon - LOTS
		    of meaningless output, be carefull!!
	EDIT	  - Both editors, doesnt do much except
		    create a backup copy of the database
		    when it is opened.

  Some of these will screw up the user interfaces, e.g. defining
  ALL the doing a connect will cause your screen to display a
  lot of meaningless data and your console output will be lost
  somewhere amongst it.

  Subsequent baselevels, releases of the software will increase
  the size of this list and the amount of data output.

  Please try to keep this internal to digital, I dont want
  lots of SPR's saying performance is lousy because someone
  has turned this stuff on!!

  Oh yeah, the definitions are case sensitive on ALL platforms,
  Uppercase is a must.

Cheers,
Phil

    Geert,
    
       This is not documented. Hopefully, when we're done with field test,
    there will be little need for this. the one drawback to making it
    public is that the debug code itself could have bugs, since it's not 
    exercised all the time.
    
    Dave

	Thanks for the pointers on the debug logical. Unfortunately, it
	is not helping. The probably seems to stem from the "imcompatible
	attributes" problem with the copy of the config file. That error
	doesn't allow the rest of CONSOLE$STARTUP to work. I'm trying to
	figure out why. I have deleted all the old config data files and
	recreated a new one with the editor and I still get the problem.

	Here is the HELP/MESSAGE output for the error.

INCOMPAT,  'input-file-spec' (input) and 'output-file-spec' (output)
            have incompatible attributes

  Facility:     Shared by several facilities

  Explanation:  This warning message indicates that file incompatibility may
                exist between files that have been appended or concatenated.
                This message occurs if files created by different methods are
                concatenated; for example, files created with the DCL command
                WRITE and files created by the DCL command SORT/RSX11. The
                command continues execution.

  User Action:  Determine whether the incompatibility presents a problem and
                if it does, delete the output files, modify the format of one
                or more input files, and reenter the command.

                The format of a file can be modified by editing the file with
                the SOS or SLP editors and creating a new version of the file.

	Here is a DIR/FUL of the file:

Directory AXELPC"system password"::CONSOLE$ROOT:[DATA]

CONSOLE_CFG.DAT;1             File ID:  None
Size:            1/3          Owner:    [1,4]
Created:   20-JAN-1994 11:05:09.00
Revised:   20-JAN-1994 11:05:10.00 (2)
Expires:   <None specified>
Backup:    <No backup recorded>
Effective: <None specified>
Recording: <None specified>
File organization:  Sequential
Shelved state:      (remote)
File attributes:    Allocation: 3, Extend: 0, Global buffer count: 0, Version limit: 0
Record format:      Stream_LF, maximum 32767 bytes
Record attributes:  Carriage return carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:R, World:R
Access Cntrl List:  None

Total of 1 file, 1/3 blocks.


	Any help would be appreciated.

							mike

Mike,

  Your file (from dir/full) looks exactly like ours here! I
  noticed you are on an FT version of OpenVMS, any chance that
  "COPY" does soething funny on that version, the reason I ask
  this is the following...

     1) You get the error at startup when we perform a straight
        VMS COPY

     2) It appears the the editor can read/write the "permanent"
        database in CONSOLE$DATA: but the C3 cannot read the copy
        of the database in the CONSOLE$TEMP: even though both the
        C3 and the editors go through the exact same code path to
        read the data!

  Finally, try copying the database by hand from CONSOLE$DATA: to
  CONSOLE$TMP: if it gives you a problem, may I be so bold as to
  say that "COPY" is giving us some sort of corruption!

  Does anyone else out there have CM installed on FT of OpenVMS
  V6.1? If so, are you seeing this problem?

Cheers,
Phil

	I tried the copy "by hand" and got the same error. I was going
	to hunt down the copy maintainer and see if it's a real bug and
	if so, get it QAR'd. Maybe it's a casualty of fullnames?

	As for 2), does the C3 read the copy in CONSOLE$TEMP? If so,
	why?

	If you need a baselevel of 6.1, I'm sure I can get you a 
	pointer.

						mike

Mike,

  The running daemons and all the user components have to keep in sync
  with each other, the easiest way for us to do this at the time was
  to implement the concept of "permanent" and "volatile" databases, the
  one in the temp directory being "volatile". So to answer your question,
  yes, the C3 reads the copy in the temp area, in fact it is only the
  editors which read the copy in CONSOLE$DATA:

  Thanks for the offer of a V6.1 baselevel, I think Graham Steele has
  one on a system here, so when he comes in the office next week, I'll
  ask him to take a look at the problem.

Cheers,
Phil

Hi Phil,

	Graham sent me mail and I have given him a pointer to the
	latest Coral (6.1) kits. I'm also hunting down the copy
	maintainer to have him take a look. I'm sure we'll 
	figure something out soon!

						mike

	FYI: I talked with the Copy maintainer and we tried 
	copying the file on a 6.0, 6.1, and 5.5-2 system and
	got the error on all systems. I'm not sure it's a
	VMS problem now.
	
	I've copied the file to

	BULOVA::DISK$TRANSFER:[PUBLIC]CONSOLE_CFG.DAT;1

	If you want to take a look at it. 

						mike

  I'm going to be out of the office most of next week, so I will
  take a look at this when I get back (unless Graham can work out
  whats going on).

Cheers,
Phil

Mike,

  In the meantime, can you delete your database from CONSOLE$DATA:
  and re-create it.

  Just start the editor and import CONSOLE$TEMPLATES:CM_CONFIG.PORT,
  do an exit and then try the startup command, it could be that we
  have a problem with the install and it has given you a corrupt file!

  Of course, the copy may be successful, but CM wont start if you have
  no systems in your database.

  Let us know what happens.

Cheers,
Phil

The story goes something like this:


Copying a kosher file has no problems, however your copy of console_cfg.dat
is corrupt (should have many more blocks than just the 1).

The input file (console_cfg.dat) characteristics seem to be a bit screwy.
A dump of the file header indicates that the record size (i.e. longest record
size) is (64K - 2) bytes, whilst the max record size is 32 Kb
The RMS manual states that for any flavour of supported file/record format
the maximum record size is 32K bytes. However the dir/fu indicates that it is
64K-2 bytes. 
The COPY utility is testing (among other things) for :-
 cmpw in_lrl, out_mrs	; longest record length = ^xFFFD, max rec size = ^x7FFF
 blequ	10$		; this branch fails
 o/p incompat msg.


The config data file was originally a text file that is imported to the editor
and then output as the offending binary file during installation. For some
reason your console_cfg.dat  seems to have been corrupted. Have you any idea 
how this happened ? The junk max rec length is presumably a by product of
the file corruption (no trailing LF ?)

	/Graham

RE: .14

Hi Phil,

	I tried that and got the same error (incompatible attributes)

RE: .15

	I'm stumped also Graham, especially after doing what Phil 
	asked in .14. I can try a re-install if you'd like.

						mike

Mike,

  With our latest baselevel kit, I just did an install on Graham's V6.1
  system, it says its version is T6.1-5X5 which looks a little older
  than yours, however, the install went as expected, after which, I started
  the editor, added a Pseudo-Terminal system which did a "Mon Sys/Int=10",
  exited the editor and performed a "@Sys$Startup:Console$Startup" I now have
  running console manager software except that I cant connect to the system,
  but thats another story!!

  Any chance of a pointer to a more recent version of OpenVMS that we can
  install and try?

Cheers,
Phil

	I sent Graham a location. It's BULOVA::SYS$KITS:[VMS061]
	
	I just checked, those seem to be older kits. I'll check tomorrow
	with someone and get the latest to you.

						mike	

	I just sent you both a new location of the VMS 6.1 sanity
	kits.

	I'll upgrade my system to that and re-install Console Manager
	and see if I get the error again.

						mike

Mike,

  Copying the kit now...

  Let us know how you get on.

Cheers,
Phil

	I deleted all references to CONSOLE on the system disk. I then
	upgraded to the sanity kit of VMS 6.1. However, I get the 
	following error during the install:

						mike


%CONSOLE-I-POSTINSTALL, Starting the POLYCENTER Console Manager Post
installation tasks.
%CONSOLE-I-CHECKFORDB, Checking for existing database file
%CONSOLE-I-CREATENEWDB, Creating system default database file

Copyright (C) 1992,1993 Digital Equipment Corporation. All Rights Reserved

Cannot open input file: CONSOLE$DATA:CONSOLE_CFG.DAT


%CONSOLE-I-ADDINGUSERS, Adding Users to database file

Copyright (C) 1992,1993 Digital Equipment Corporation. All Rights Reserved




        Installation of CONSOLE V1.1 completed at 17:46

                                                            

Copyright (C) 1992,1993 Digital Equipment Corporation. All Rights Reserved

Cannot open input file: CONSOLE$DATA:CONSOLE_CFG.DAT

This is not an error in this case. We have put a commwent in the instal now to
that effect.

Cheers Simon...

Mike,

  As Simon said, the message you saw is normal for a fresh installation
  because when the install runs the editor in order to add the default
  CM Events, the database doesnt exist, so one will be created when the
  editor exits.

  Have you tried importing your old VCS definitions and managing a system
  yet?

  We upgraded to the sanity kit and cannot reproduce your problem, adding
  one system as a Pseudo-Terminal and starting the software works, then
  starting up the C3 works OK.

Cheers,
Phil

Hi Phil,

	I'll try importing the VCS definitions again but based on last
	time, I suspect I'll continue to get the "incompatible 
	attributes" error which won't allow me to start CM.

						mike

Mike,

  I finally got this sorted, reproducing it for the first time on a system
  seems to be hit and miss, but, once it happens, I can reproduce it every
  time.

  Now, the good news, I have fixed the problem.

  The fix will be in our next FT Update (the final one before SSB). The bad
  news for all FT users is that you will have to export your database BEFORE
  you upgrade to the new FT version, this applies to ALL platforms.

Cheers,
Phil

P.S. Before you ask, the final FT kit will be in approx 2 weeks.

    FYI and FWIW
    
    The problem with incompatible attributes derives from a peculiarity
    in the C rtl. On file closure for a stream sequential file 3 XABs
    are linked to the FAB. The FHC XAB is used to set the record
    attributes. In the C rtl the field xab$w_lrl is being filled by
    the following instruction :-
    
    	mnegw #3,xab$w_lrl(r1)
    
    if the LRL is 0. It's anyone's guess why. I'm QARing it since other
    VMS utilities object to seeing a Longest Record Length that is greater
    than the maximum supported record length (32K). My assumption is that
    the LRL is not being set at all because the C rtl is actually doing
    blockio to this file rather than sys$put's. The problem has been
    sidestepped in the latest kit by using BACKUP to do the file copy.
    
    /Graham

    This problem has been fixed for both CORAL and EPSILON.  The LRL value
    will now be set to 32767 instead of 65533.  We apologize for the
    inconvenience that we have caused, but thank you for persuing this
    problem on our behalf.
    
    Duane Smith
    DEC C RTL Project

    Bravo Graham!

    
    Hi,
    
    What is the fix to this problem  ?  We are running CM V1.1 on a VAX
    system running T6.1-5Z0 ( there are plans to upgrade to SSB ).  The
    console$startup runs fine without error, however each time we attempt
    to do a 'console connect node', we get an accvio:
    
    %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual
    address=010E0019, PC
    =00028377, PSL=03C00000
    
      Improperly handled condition, image exit forced.
    
            Signal arguments              Stack contents
    
         Number = 00000005                00000009
            Name   = 0000000C                7FE6550C
                     00000001                00000000
                     010E0019                00000000
                     00028377                20000000
                     03C00000                7FE6553C
                                             7FE65528
                                             0002EABF
                                             00000002
                                             010E0015
     Register dump
    
            R0 = 010E0015  R1 = 002BC1B0  R2 = 000011D8  R3 = 00000E04
            R4 = 00000F3C  R5 = 00000000  R6 = 00000000  R7 = 00000001
            R8 = 7FFECA48  R9 = 7FFECC50  R10= 7FFED7D4  R11= 7FFE2BDC
            AP = 7FE654B4  FP = 7FE65474  SP = 7FE654F0  PC = 00028377
            PSL= 03C00000