• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Full Package Build

dave_laha

Active Member
Hi List,

I just finished building a completely new environment, pathcode - the whole
works. In order to test a client package prior to having to build a full
package, I copied the most recent PROD package (and its directories) in
Deployment and renamed it to the new package name. Pulled this package down to
a client ran all tests, ran UBEs locally and everything seemed to work fine!

Having tested it, I kicked off a full package build for the server and client
overnight. Unfortunately, I am finding that both the builds failed -
specifically building the SPEC records. In comparing this new environment to
our PROD (from where I copied all specs and data) I found the SPEC folder of the
new environment in deployment, enterprise and application servers does not have
all the files, specifically the gbrspec files.

What did I do wrong? Can I cheat, and copy these folders from a good PROD full
package to this new path's directories? But then, how will I know what really
caused the specs not to be build?

Thanks for any suggestions in advance.

Dave Laha
CNC
7332/SQL/NT
Deployment, 1 Enterprise + 2 Application Servers
Citrix Metaframe
 

rgz

Active Member
Check record counts in your F987* CO tables. Compare the prod counts against
your new pathcode counts.
Did you use R98403 or SQL to create the new pathcode? When moving CO's on
SQL, don't JDE suggest using the ube, rather than SQL tools, to get around
some known bugs?
 

dave_laha

Active Member
Dave :

It's weird that only gbrspec files couldn't be built.
Were all the other spec files successfully built?
Check that JDE SQL user has permissions on JDE_XXXB733 database
(the database that holds your custom C.O.).
For example, can I you checkin and checkout UBEs and APPLs on that
custom environment?

Sebastian Sajaroff
 

dave_laha

Active Member
Richard,

Thanks for the response. Record counts on PROD and the new environment for all
CO tables match. I did use R98403 ver 19 for the copy! What I am finding is
that for some reason the CO tables in the new environment do not have any key
fields identified as they should be, and as they are in the PROD or all other
environments. I wonder, if using option 'A' in processing options under the
Update while running the R98403 copy caused the tables to be recreated without
the appropriate keys. And if so, could this be the reason for the package build
to fail for spec objects?

Dave







richmanning <richmanning@hotmail.com> on 04/21/2001 11:25:43 AM

Please respond to jdelist@jdelist.com
MailTo: jdelistml@jdelist.com
cc: (bcc: Dave Laha/RLR/PCI/CHI/US)
Subject: Re: Full Package Build



Check record counts in your F987* CO tables. Compare the prod counts against
your new pathcode counts.
Did you use R98403 or SQL to create the new pathcode? When moving CO's on
SQL, don't JDE suggest using the ube, rather than SQL tools, to get around
some known bugs?






--------------------------
 

dave_laha

Active Member
Lisa,

I did check the datasources also! All the datasources for Central Objects,
Control Tables, Business Data, and LOCAL seem to be setup ok on this new
environment!

While creating the SQL tables for this new environment, I did not create any new
object owners for the tables in the new environment. I kept the owners the same
as they are in PROD for eg. PRODDTA, PRODB733, and PRODCTL for business data,
central objects and versions, and control tables respectively. But I doubt
ownership would be an issue (or is it?).

Dave







lisa stinebuck <lisa.stinebuck@us.logicaleboc.com> on 04/23/2001 11:23:58 AM

Please respond to jdelist@jdelist.com
MailTo: jdelistml@jdelist.com
cc: (bcc: Dave Laha/RLR/PCI/CHI/US)
Subject: RE: Full Package Build



Dave,
It sounds like you may need to go back and check your DataSource(s)
for your new environment.....

Lisa G. Stinebuck
Senior Service Delivery Technician
Logical EBOC Cincinnati
513-412-7950 x1021
lisa.stinebuck@us.logicaleboc.com






--------------------------
 

lisa_stinebuck

Active Member
Dave,
To my knowledge ownership COULD be a problem depending on which
database you are using (at least I think I remember reading this
somewhere..."OneWorld: A Complete Reference" maybe??). Maybe OneWorld
expects the owner of the database to conform to the OW naming convention
when setting up a new environment and/or pathcode.
Kind of like with Oracle you must set the DSN (data source name) in th
TNSNAMES.SQL file (and it must be exactly as you defined the name when
setting up the datasource in OW) or it will not work.
Data source problems were the first thing that came to mind when
reading your problem, but it seems strange that it didn't affect all
specs....only certain specs.
I'll keep thinking about this to see if we can get you past this...

Lisa G. Stinebuck
Senior Service Delivery Technician
Logical EBOC Cincinnati
513-412-7950 x1021
lisa.stinebuck@us.logicaleboc.com
 
Top