Conference smurf::dec_mls_plus

From:	SMURF::BAT          "Barbara A. Thomson ZKO3-2/X46 1-2955" 23-APR-1997 12:13:15.90
To:	US2RMC::"ASCHEN.US.ORACLE.COM@oracle.com"
CC:	BAT
Subj:	RE: cobol installation


	You do have V4.0A -- but some subsets check for dependencies
	and the way they do is look for a specific file usually
	named somethingBASEsomething for an operating system.

	cd /usr/.smdb.
	grep DEPS *.ctrl

	You will see which subsets require which other subsets,
	and what they expect the subset's name to be.

	The best way to get around this is to create symlinks
	using the name the subset expects to the name it actually
	is., e.g.,

	ln -s MLSBASE410.inv OSFBASE410.inv
	ln -s MLSBASE410.scp OSFBASE410.scp
	ln -s MLSBASE410.ctrl OSFBASE410.ctrl
	ln -s MLSBASE410.lk OSFBASE410.lk

	I think you really only need to link the lock (.lk) file,
	but if you link all them you'll be safe.

    

From:	US2RMC::"ASCHEN.US.ORACLE.COM@oracle.com" "ASCHEN.US.ORACLE.COM " 23-APR-1997 22:27:26.94
To:	smurf::bat
CC:	
Subj:	Re: RE: cobol installation


--=_ORCL_37997132_0_11919704231952160
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"

 
Barbara, 
 
This does not work for me. 
 
Here is what I did: 
> cd /usr/.smdb.; grep DEPS *.ctrl 
> Then, I figured I can just type "grep DEPS *.ctrl | grep MFCBASE" and the 
result is: 
   MFCBASE400.ctrl:DEPS="." 
   >> I donot know what '.' means in this case. 
> So I tried the symlink method and reinstall COBOL; But, the installation 
fails with same error. 
> I also notice your example is "OSFBASE410" and hope you just gave an 
example. What I have on my system is "OSFBASE405". 
> I attach the output from "grep DEPS *.ctrl" command to this email for your 
reference. 
> Could this be a license issue?  (Because I have difficulty (not the same 
error) when installing FORTRAN too) 
   # setld -v DFABASE410 
     ... 
     IVP, information: Emptied scratch directory. 
     IVP, information: Compiling and linking. 
     License is invalid for this version of the product 
  
     DFABASE410, error: INSTALLATION VERIFICATION PROCEDURE FAILED. 
     setld: ivp failed. 
 
Thanks. 
===================================== 
Alex Chen 
Oracle Corporation               Phone: 415-506-2316 
500 Oracle Parkway             Fax:     415-506-7408 
M/S 3op7 
Redwood Shores, CA 94065

    Digital UNIX V4.0A Associated Products Volume 1
    AG-QTMAB-BE
    Volume 2 
    AG-QX6FB-BE

> cd /usr/.smdb.; grep DEPS *.ctrl 
> > Then, I figured I can just type "grep DEPS *.ctrl | grep MFCBASE" and the 
> result is: 
>    MFCBASE400.ctrl:DEPS="." 
>    >> I donot know what '.' means in this case. 

	DEPS="." means that the MFCBASE400 subset isn't looking for any subsets 
	as prerequisites from the standpoint of the setld .ctrl procedure.

> > So I tried the symlink method and reinstall COBOL; But, the installation 
> fails with same error. 

	The method suggested does not apply, because it turns out in MLS+ V4, 
	the subset names OSFBASE* already exist and are real so those layered 
	products should still be successful in finding the .lk files.

> > I also notice your example is "OSFBASE410" and hope you just gave an 
> example. What I have on my system is "OSFBASE405". 

	Yes, it was just an example, I happened to look at a V4.0B system.  
	I should have looked at a V4.0A MLS+ system, sorry.
    
	In any case, you should back out the change and reinstate OSFBASE 
    	files as they were.  This is what the V4.0A MLS+ box I'm looking at 
    	has:

ls -lg OSFBASE*
-r--r--r--   1 bin      bin          200 Feb 24 17:18 OSFBASE405.ctrl
-r--r--r--   1 bin      bin       151448 Feb 25 08:53 OSFBASE405.inv
-r--r--r--   1 bin      bin          347 Feb 24 17:50 OSFBASE405.lk
---x--x--x   1 bin      bin         4407 Feb 24 17:18 OSFBASE405.scp

> > I attach the output from "grep DEPS *.ctrl" command to this email for your 
> reference. 

	Thanks.  Because the error appears to be reported during the setld 
	command execution, and because the .ctrl file DEPS field does not 
	specify a dependency, then I would hazard a guess that there is 
	something specific to the MFC product in the .scp file.  The .scp 
	file is a shell script that setld runs, and they could do anything 
	there (it's non-standard but then hey.)  If you don't want to read 
	it, send it to me and I'll try and verify my guess.  

> > Could this be a license issue?  (Because I have difficulty (not the same 
> error) when installing FORTRAN too) 
>    # setld -v DFABASE410 
>      ... 
>      IVP, information: Emptied scratch directory. 
>      IVP, information: Compiling and linking. 
>      License is invalid for this version of the product 
>   
>      DFABASE410, error: INSTALLATION VERIFICATION PROCEDURE FAILED. 
>      setld: ivp failed. 


	Unless you are getting the MFC error message during the IVP execution, 
	then I'd say it is not the same.  BTW, the IVP itself is a shell 
	script, and you should be able to examine it and see what it is 
	expecting.

	Depending on whether it is really reading the license (lmf) database 
	or whether it is relying on the /usr/.smdb. files, I would make the 
	appropriate adjustments.

	I see that you are installing DFABASE410, meaning it is probably 
	looking for OSFBASE410.  In that case, I'd create symlinks OSFBASE410* 
	and link them to OSFBASE405* just to see if it works.

	In general, when a new layered product comes out, the layered product 
	people automatically change the DEPS to the then current version of 
	the base operating system (if they are using the DEPS method).  That 
	may or may not be a strict requirement.  In other words, that version 
	of FORTRAN may run just fine on earlier versions of the operating 
	system.  There may be no special changes to the current version of 
	the operating system to which that version of the layered product is
	linked.  On the other hand, there really may be some underlying 
	feature or fix on which they are dependent.

	We always have to look at the product plan to find out if there 
	really is a dependency.

	(The reason for this is that in general, DEC does not support older 
	versions when new ones come out;  but there are exceptions to those 
	rules, and this is one.)

	For your purposes, at the moment just to see if it works, just fudge 
	the links or modify the IVP or .scp scripts (save the originals of 
	course).
    

From:	US2RMC::"ASCHEN.US.ORACLE.COM@oracle.com" "ASCHEN.US.ORACLE.COM " 25-APR-1997 18:15:17.18
To:	smurf::bat
CC:	
Subj:	Re: re: Installing Micro Focus Cobol

Barbara, 
 
Somehow, I successfully install Cobol and Fortran on MLS+ 4.0a, but I still 
need to get a license to use Micro Focus Cobol.  I am asking Jay Botelho to 
get one for me, but If you can get one for me, then it is great. 
 
The story is that I installed 2 MLS+ 4.0a on two separate disks when I had 
OSF-BASE license problem on SMP machine and I was experimenting the lmf.  I 
can install compilers on one of the system which I did not experiment with 
those lmf PAK.  Since the compilers installation is working, I guess the 
reason I have installation problem must be the license manager was not happy. 
 
Anyway, sorry to confuse you.  Everything works fine now except I need a Micor 
Focus Cobol license. 
 
Thanks for your help and best regards. 
===================================== 
Alex Chen 
Oracle Corporation               Phone: 415-506-2316 
500 Oracle Parkway             Fax:     415-506-7408 
M/S 3op7 
Redwood Shores, CA 94065

    Alex, I don't "do" licenses -- Jay should be able to get all the
    licenses you want through the relationship manager -- you should
    actually get a "whole set" in one glob.
    
    I still haven't a clue what went wrong, but hey.
    
    Have a good weekend,
    BAT

Looks like I'm the one to blame on the checks with OSF versions on the
Micro Focus installation.   This may also apply to other compiler products
since I usually take the examples from their setld scripting.

Here's what's there now. 

========
    # Is OSFBASE installed? If not, issue a dependency warning.
    #
    if STL_DepEval "OSFBASE*" not
    then
        echo "
${subset_name}: error: Be *sure* to install OSFBASE before running
        the IVP (setld -v) and trying to use Micro Focus COBOL."
        exit 1
    fi

    if STL_DepEval "OSFBASE1??" "OSFBASE2??" "OSFBASE30?" "OSFBASE31?" or or or
    then
        echo "
${subset_name}: error: Micro Focus COBOL for Digital UNIX
        (MFCBASE) is not supported by versions of Digital UNIX
        earlier than Version 3.2.  MFCBASE cannot be installed on your system
        until the required version of Digital UNIX is installed.
"
        exit 1
    fi
===========

Are we running into a problem because the old subsets are seen in this 
check?   Or is it only due to the MLSBASE naming?   Any suggestions as to
what the script should look like?   

-Joanne           (tle::neschke)

    Joanne, the script looks fine to me -- on an MLS+ box, an
    ls of OSFBASE* returns only:
    
    OSFBASE405.ctrl  OSFBASE405.inv   OSFBASE405.lk    OSFBASE405.scp
    
    So, your if test should fail.  I think I was confused about what Alex
    was asking about -- it turned out he needed the license (lmf PAK), not
    that he needed to remap the subset names.

    Joanne and I found out today that:
    
    1.	If you give the user limit and ilnofloat privs, it works.
    
    2.	But you cannot give the cob or the rts32 the privs in their
    	granted sets -- it doesn't work.
    
    Don't know why yet.