Lawson 9 to 10 separate server issue

I'm not in front of a system right now, but don't you need the system code in it?
Try: 'verifyora11 srcpl ug ugzlog'

Kwane

Ok, I got on a system, and my age is clearly showing, as system code is optional.

I thought about the error more. It is thrown when the productline dictionary isn't found (or readable).
You shouldn't be running into security issues, as that would have trapped you first, before it threw this error.

Are you certain you have the dictionary and directory names in the correct case (assuming UNIX) and the perms on the dictionaries allow for reading?

Kwane

I'll double check. I built everything like it was on the source server.

I don't believe the log file is a parameter. Try re-directing to the log. Usually also turn Lawson Security off.

verifyora11 SRCPL > ugz.log

The verifyora11 srcpl ugzlog parameters are good. I believe there is a step missing in the dbdef or security setup for the product line.

verifyora11 scrpl would validate all tables in the srcpl. ugzlog is one of the upgrade tables that is in both the source and target product lines.

It looks like during dbdef that we should define the data area for the source environment but there is nothing in the instructions that you need to

I forgot to mention I have security turned off.

I can't find anything in dbdef that's helping. I defined a data area for the source product line on the target server and that didn't help.

Might check the Database Space in dbdef.

When you copied the source dictionary, was the source environment running? If so, the file might be corrupt.

I stopped the test envrionment which I'm using for my source environment and re-copied the files as directed in the documentation.

Since the product line dictionary I was copying had multiple data areas it didn't load them during the dbdef. At least that's what I'm assuming.
So I created a database space and data area on the targer server for the source product line. And tried the verifyora11 command again.

I'm past the original message:
verifyora11 failed with DBConfig.Init() failed
CLawConfiguration::Init() GetDict() failed

And now depending upon the values I'm using for the ORACLE file I get new errors
$ verifyora11 test901 ugzlog
verifyora11 failed with DBConnect.Connect() failed
Dictionary: 'test901' Program: 'verifyora11' DBServer: 'lawappstest'
COraDBConnection::Connect: Received Error while connecting to server 'lawappstest'
COraSqlStatement::Connect(1): Got OCI_MISC_CODE
ORA-12504: TNS:listener was not given the SERVICE_NAME in CONNECT_DATA

------I've tried almost every combination of the below ORACLE parameters. Again with mixed results
LAWGATENAME=oradb11
#DBSERVER=test
DBSERVER=lawappstest
LOGINNAME=vhtest901
PASSWORD=xxxxxxxx
#ORACLE_SID=test
#TNS_ADMIN=/oracle/admin/lawprod/network
TNS_ADMIN=/oracle/app/oracle/product/11.2.0/network/admin
TWO_TASK=test
#DBSERVER=test --no systemcode ugzlo on data area test901

----
I can query the source DB from the target server using sqlplus vhtest901/xxxxx@test
just fine. No issues. So I feel pretty good about the listener.ora and tnsnames.ora values.

Any ideas on the ORACLE file? Again I've tried just about every combination.

This ORACLE combination works the best, but it still doesn't look right. It requires the system code and that's not normal and when it does return the results it doesn't return the proper counts because the ugzlog table exists in the test901 product line.
LAWGATENAME=oradb11
DBSERVER=test
LOGINNAME=vhtest901
PASSWORD=xxxxxx
ORACLE_SID=test
TNS_ADMIN=/oracle/admin/lawprod/network
TWO_TASK=test

Here are the results of verifyora11 with and without the system code
$ verifyora11 test901 ugzlog
No SystemCode UGZLO on Data Area TEST901
verifyora11 failed with No SystemCode UGZLO on Data Area TEST901

$ verifyora11 test901 ug ugzlog
Verifying objects for selected Tables in the TEST901 Data Area:

Total files found in the Productline : 0
Total views unchecked : 0
Total files in Empty DB space : 0
Foreign files found In the Productline : 0
Total Files unchecked/unable to open : 0

Total Number of SQL tables checked : 0
Number of SQL tables with no errors : 0
Number of SQL tables missing : 0
SQL tables with incorrect definitions : 0
Number of SQL tables with warnings : 0

Number of DB Indexes checked : 0
Number of DB Indexes with no errors : 0
Number of DB indexes missing : 0
DB indexes with Incorrect definitions : 0

I'm pretty confident oracle tns is setup properly. sqlplus vhtest901/xxxx@test works fine from the target

I'm afraid I'm missing something in dbdef. The blddbdict looks good. verifyora11 is recognizing changes to the ORACLE file.

I set debug=true in the ORACLE files for source and target on the target server and compard the verifyora11 ugzlog to the verifyora11 ugzlog and both get down to Returning OK from CDBProgram: Startup().

Source:
$ verifyora12 vhtest9 ugzlog
No SystemCode UGZLO on Data Area VHTEST9
verifyora12 failed with No SystemCode UGZLO on Data Area VHTEST9
--In the trace file It simply stops at: Returning OK from CDBProgram::StartUp()

Target:
$ verifyora12 lawprod ugzlog
Verifying objects for selected Tables in the LAWPROD Data Area:
Checking Table LAWPROD.UGZLOG

Total files found in the Productline : 1
..-Continues on as expected
--The trace file continues on after Returning OK from CDBProgram::StartUp() with the execution of CSqlViewMaker
Returning OK from CDBProgram::StartUp()
Entering CSqlViewMaker::MakeView(), FileNum 2438, VersionInfo -2

Entering ConfigForTable()...
select
tablespace_name,
ini_trans,--etc

This sounds like a bug in verifyora11. I confirmed that system code should be optional as it is in the v9 system I jumped on to compare.

Since this is happening on the v10 side, I suspect that it's a big, since you said it is working when you add system code

That's another theory of mine, but I haven't given up hope yet. I still think maybe it's something in the ORACLE file or there is additional details missing from the product line dictionary setup in the separate environment instructions

And actaully verifyora11 returns output typical of a successful run, but the counts are correct. It has 0 for the table count and index count an they should have a value of 1. The trace file seems to stop after the DDBProgram::Startup(). Nothing is log after that anywhere. No ladb.log entries. Nothing.

I reviewed your counts, and you're right, they should say one.
That to me almost certainly confirms a bug.

That's what I'm afraid of. Any chance Lawson support will agree...

I believe the issue is with the product line copy and more specifically the dbdef instructions.

The SRCPL is about 45K on the source server. It's 45K after the copy to the target server.

After adding it via dbdef as instructed:
"Open the dbdef (database definition) utility. In the Product Line field, type 90xPROD, where
90xPROD is the name of the source product line. In the Launt or Unix field, select Yes. Tab to
the system code field and type UG. Press enter to save the new product line and escape out of
dbdef."

After performing the dbdef steps the SRCPL dictionary file becomes 208 bytes. I can't imagine this is correct.
Even after adding the database space and data areas and running blddbdict which runs cleanly it's still 208 bytes.

$ verifyora11 test901 ugzlog
No SystemCode UGZLO on Data Area TEST901
verifyora11 failed with No SystemCode UGZLO on Data Area TEST901

This is telling me that ugzlog doesn't exist. If you run verifyora on a production system it will return a similar message.
If you supply the system code it will generate a normal verifyora report with all zoroes. No error but the counts are 0. This tells me that dbdef of the source product line doesn't recognize the table. It's acting to me like the dbdef flushed everything out. By the way I checked the diction sizes and ran the verifyora just after running dbdef and also after running blddbdict which I'm not sure was necessary.

I know sqlnet net is working because if the run this command on the source server and the target server I can see in the listener logs on the source server both entries making it through.
So this confirms the ORACLE file is good and Oracle sql net is good.

There has to be a missing step in dbdef. Has anyone else done a separate server environment upgrade from 901 to 10? If so what steps did you have for linking in the source product line to the target product line on the target server?

Are you running blddbdict after the dbdef? If so, don't.

I tried it both ways. I'll do it again w/o the blddbdict.

It's actually when I click enter in dbdef after entering the soruce product line that the dict/SRCPL changes to the 208 bytes. The source product line is actually called TEST901

Ok. I think I see what might be the problem.

I'm using my test product line which is a clone of the production product line as my source. Which should be fine.
The problem might with the muliple data areas defined in the test product line.

When I copy the dictionary over and add the product line in dbdef it doesn't have a data area. Or it doesn't know which one to use. It's when I try to add the database space and data area that the dictionary size shrinks to 208 bytes.
If I don't add the database space and data area the verifyora11 fails:
$ verifyora11 test901 ugzlog
verifyora11 failed with DBConfig.Init() failed
CLawConfiguration::Init() GetDict() failed

My guess is I have to reduce the test product line down to one data area or build a new source product line and data area on the test server

The solution was to create a product line with one data area.