Conference 44.370::system_management

Hi Mob,

I have a problem with the CPS build at the moment (Since the EASE Upgrage).

MMS is executing the following line:

cop$cdd_tsk_tem.cps_eur_mri_temu_ddl^ : -
                cop$cdd_gen_ddl.cps_eur_user_control_ddl^, -
                cop$cdd_gen_ddl.cps_eur_task_control_ddl^, -
                cop$cdd_eur_rdb.rdb$fields.badge_no^, -
                cop$cdd_eur_rdb.rdb$relations.emplye_termtn^, -
                cop$dir_src:cps_eur_mri_temu_ddl.ddl

        CDDL/REPLACE cop$dir_src:cps_eur_mri_temu_ddl.ddl

And it falls over with:

%MMS-F-GWKNOPRN, There are no known sources for the current target
COP$CDD_EUR_RDB.RDB$FIELDS.BADGE_NO^.

In DTR when I try to set dic to: cop$cdd_eur_rdb.rdb$fields, I get the message:
Element "COP$DISK_DEV_UKO:[CDO]COP_UKO.CDD_EUR_RDB.RDB$FIELDS" not found in 
dictionary.

Can anyone help - I Don't understand CDD stuff ! Could this problem be because 
the CDD has been upgraded ? Do I need to do anything to recover ? Help !

Ta,

Wob

It looks like your using CDD+, so try this.

$ dictionary operator
CDO> verify/all/nofix COP$DISK_DEV_UKO:[CDO]    ! <- is this your anchor ?

If it complains about conversion required then do the following,

CDO> convert/dictionary COP$DISK_DEV_UKO:[CDO]
CDO> verify/all COP$DISK_DEV_UKO:[CDO]
CDO> exit

I have, in the past, had to do the convert and/or the verify more than once
to stop it complaining.

Over to you Lynn,

Ian.

	Thanks Mob for the notes and telephone help !

	It looks like I had a private CDD dictionary which needed converting.
	(I did read the DECStep release notes, but must have missed the CDD
	conversions)

	Anyway Thanks !

	Wob

	Hi Mob, tis me again !

	I have a small problem with what appears to be the CDD again. I get
	the following error when executing this MMS line:

cop$dir_pen:cps_uko_payrl_chng_env.pen : -
                        cop$dir_pen:cps_eur_gen_env.pen, -
                        cop$dir_pen:cps_eur_rel_env.pen, -
                        cop$cdd_tsk_int.cps_uko_payrl_chng_work_ddl^, -
                        cop$cdd_eur_rdb.rdb$relations.payrl_chng_uko^, -
                        cop$dir_src:cps_uko_payrl_chng_env.pas
    @COP$FIL_PASCAL_ENV cop$dir_src:cps_uko_payrl_chng_env.pas cop$dir_pen

%MMS-F-GWKNOPRN, There are no known sources for the current target
	COP$CDD_EUR_RDB.RDB$RELATIONS.PAYRL_CHNG_UKO^.

But in CDO if I set def to COP$CDD_EUR_RDB.RDB$RELATIONS and do a directory, the
objexct appears to be there. It has also been converted since the EASE Upgrade !

Any offers ?

Wob

You most probably have a rule that creates a CDD+ entry from a CDO file
and MMS is looking for payrl_chng_uko.CDO. It obviously doesn't understand
the RDB$RELATION stuff.

Cheat by adding a line, (I havn't tried this)

PAYRL_CHNG_UKO.CDO : Name-of-file-used-to-create-rdb-database
	@ CONTINUE

You may what to change the continue, to the command required to build the
database.


Also check your .SUFFIXES list to make sure you only have what you need and
its in the correct order and possibly add the .RDO (is this what you 
use to create the DB) to the list.

Ian.

	Hi All,

	Thanks Ian for your help, I think the fact that CDD aws corrupted
	wasn't helping. Anyway it seems to be fixed now, apart from the fact
	that now that's fixed, I've got further in the build, and something
	else has gone wrong.

	Bascically the RDML precompiler is having a fit over our use of
	segmented strings. The attached extract from the notes conference
	details that this problem is fixed in Rdb V4.1, but also suggests
	a temporary fix for V4.0A.

	Could someone suggest how to modify the .PAS file output from the
	RDML pre-compiler as suggested in the attached notes, or alternatively
	Would anyone on CURRNT be impacted if we upgraded Rdb from Rdb V4.0A
	the EASE supplied version, to Rdb V4.1


	Thanks and Regards,

	Rob

	              <<< NOVA::NOTES_DISK:[NOTES$LIBRARY]RDB_40.NOTE;2 >>>
             -< Rdb/VMS - Digital's Strategic Relational Database >-
================================================================================
Note 2120.0      Problems with RDML/PASCAL and segmented strings       6 replies
RUTILE::BERNARD "or so it seems to me"               60 lines  10-DEC-1991 06:27
--------------------------------------------------------------------------------
Hi,

I have a problem while using RDML/PASCAL (V1.4-7, Rdb V4.0A). For a reason 
unknown to me, the preprocessing of a couple of source files generates  .PAS
files in which the preprocessor includes some declarations (related to segmented
strings it seems) with weird array values (see below extracts of a .PAS file). 
Of course, the PASCAL compiler can't handle these values afterwards. 

I've tried to find out where these values came from, but with no success. 
Has anybody ever faced that before, or has an explanation?

Thanks in advance

Christophe


(...)

%INCLUDE 'SYS$LIBRARY:RDMLVPAS.PAS'
	  [HIDDEN] TYPE
(...)

	  [HIDDEN] VAR
(...)

	  RDB$SEGSTR_HANDLE_1 : [HIDDEN] RDML$HANDLE_TYPE := 0;
	  RDB$SEGSTR_1 : [HIDDEN] RECORD
	      CASE INTEGER OF
		0:(
		  LEN: 		  RDML$UWORD_TYPE;
		  VAL: 		  PACKED ARRAY [1..-1536] OF CHAR
		  );
		1:(
		  ACTUAL_VAL: 		  VARYING[-1536] OF CHAR
		  );
	    END;
	  RDB$SEGSTR_HANDLE_2 : [HIDDEN] RDML$HANDLE_TYPE := 0;
	  RDB$SEGSTR_2 : [HIDDEN] RECORD
	      CASE INTEGER OF
		0:(
		  LEN: 		  RDML$UWORD_TYPE;
		  VAL: 		  PACKED ARRAY [1..-1536] OF CHAR
		  );
		1:(
		  ACTUAL_VAL: 		  VARYING[-1536] OF CHAR
		  );
	    END;
	  RDB$SEGSTR_HANDLE_3 : [HIDDEN] RDML$HANDLE_TYPE := 0;
	  RDB$SEGSTR_3 : [HIDDEN] RECORD
	      CASE INTEGER OF
		0:(
		  LEN: 		  RDML$UWORD_TYPE;
		  VAL: 		  PACKED ARRAY [1..-1536] OF CHAR
		  );
		1:(
		  ACTUAL_VAL: 		  VARYING[-1536] OF CHAR
		  );
	    END;

(...)
================================================================================
Note 2120.1      Problems with RDML/PASCAL and segmented strings          1 of 6
NOVA::SMITHI "Lay a wallaby baby ball away, Al..."    9 lines  10-DEC-1991 08:25
                                 -< SPR time >-
--------------------------------------------------------------------------------
Is the database attached by FILENAME or by PATHNAME during the precompile.

If you do a SHOW FIELD FOR relation-name in RDO you should see large value for
the segmented string length.  I think RDML is treating this as a SIGNED WORD,
when it should be an UNSIGNED WORD.

Please send an SPR reporting this problem.

Ian
================================================================================
Note 2120.2      Problems with RDML/PASCAL and segmented strings          2 of 6
RUTILE::BERNARD "or so it seems to me"                9 lines  10-DEC-1991 08:54
--------------------------------------------------------------------------------
Hi,

Thanks for the quick answer. Database is attached by filename and segment length
is 64000.

Regards,

Christophe

================================================================================
Note 2120.3      Problems with RDML/PASCAL and segmented strings          3 of 6
NOVA::SMITHI "Lay a wallaby baby ball away, Al..."    4 lines  10-DEC-1991 09:46
--------------------------------------------------------------------------------
So yes the largest SIGNED word is 32767, and thus RDML is output the wrong
value.

Ian
================================================================================
Note 2120.4      Problems with RDML/PASCAL and segmented strings          4 of 6
NOVA::TSENG                                           4 lines  10-DEC-1991 12:39
                               -< fixed in 4.1 >-
--------------------------------------------------------------------------------

This problem is fixed in 4.1

HuiLing
================================================================================
Note 2120.5      Problems with RDML/PASCAL and segmented strings          5 of 6
NOVA::SMITHI "Lay a wallaby baby ball away, Al..."    8 lines  10-DEC-1991 13:01
--------------------------------------------------------------------------------
In V4.1 we store the segment length as a SIGNED LONGWORD, so your problem will
be fixed.  In the meantime you have two choices:

	1: change the segment size to 32767 (maximum signed value)

	2: edit the output from RDML so that is legal.

Ian
================================================================================
Note 2120.6      Problems with RDML/PASCAL and segmented strings          6 of 6
RUTILE::BERNARD "or so it seems to me"                3 lines  10-DEC-1991 17:43
--------------------------------------------------------------------------------
Thanks a lot for your help. I'm looking forward V4.1

Christophe

    
    Rob,
    
    Rdb V4.1 is still in Field Test and hasn't been officially released.
    
    You'll have to do a string search and replace on your daft values
    using your favourite editor, I'm afraid. (Unless anyone knows better?)
    
    Regards,
    
    	David
    

    Rob, if you can persuade all the European sites to also update to Rdb 4.1 
    there will be no problem supporting their software.

    Otherwise it'll be easier to drain the swamp.

     Rob, we will be using RDB V4.0A for the JUly/August 92 DECstep EASE
     migration too, as V4.1 is still in field test.
    
    Pop round and see me if this is still a problem to you.
    
    Peter.

	Thanks guys.

	FYO released a patch that they've had since they experienced the
	problem a while back - to substitute the correct values in the .PAS
	file, generated by the RDML pre-compiler. Nice of them to let me
	know in advance !!!!!!

	Wob