E1 9.0 Login Issue - Missing Key for Planner Data Source in spec.ini

[tiradoj]

Hello All

Well doing an 9.0 install Service Pack 898121 and once again the folks in Quality Control are to be found ...less than ideal.

I am convinced Oracle-JDE is completely incapable of getting their act together when it comes to creating a product that doesn't require a "Known Issues Document" and conducting painful frustrating and time consuming searches for answers on cryptic and semi cryptic jde log messages.

Some things I noticed with 9.0 - now we have multiple logs that are stamped with process ids on them. Not sure I like this but who cares what I think? Needed on enterprise server but seems over kill on dep server. Maybe there is a switch to turn this functionality off?

Also I installed 9.0 ok (but only after reading that the downloaded CD images from edelivery HAVE to be named and organized in a certain fashion-ugh--another "feature" that makes me wince in pain and wish I was a bartender who can make the same amount of money...) otherwise you get these "bean" errors and a note about how the 'Platform Pack has to be in place...yadda yadda" of course that's has nothing to do with issue--who is coding this crap?) which have no search results in Knowledge Garden. (wonderful)

Now when I try to sign into E1 I get an "Error Opening Table F98MOQUE and this in log"

Aug 12 11:45:49.062001 - 824/1972 MAIN_THREAD A value is not defined for the key, PLANNER_DataSource, in the SPEC LOCATIONS section of the spec.ini file.
Aug 12 11:45:49.062002 - 824/1972 MAIN_THREAD JDESPEC0000044 - Could not determine spec package name for the path code, PLANNER. Please check the key, PLANNER_Package, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.
Aug 12 11:45:49.062004 - 824/1972 MAIN_THREAD JDESPEC0000045 - Could not determine spec datasource name for the path code, PLANNER. Please check the key, PLANNER_DataSource, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.


MORE nonsense. I know where the file is but what SHOULD it say? Mine just says 'E900' - in 812 it said 'MASTER' Anyone seen this before? No hits on Knowledge Garden. This is RIGHT OUT OF THE BOX. Also minor irritant - the logical name of SPEC_MASTER db is now SPEC_E900. Can you say 'identity conflict'?

OS Server is 2003 SP2 Std Ed and I am using SQL Server 2008 Express Edition as the local instance planner dbs.

I can connect fine via OBDC - it's the crap &*^#%( middleware and poor messaging as usual.

I will keep looking but thanks in advance.

When E1 works, though, it is a beautiful thing.

Joe Tirado
Senior CNC Consultant
B714 through 9.0 and installs and upgrades are still a pain but I need the eggs .

 

[Sebastian Sajaroff]

Hi,

Have you confirmed that SQL2008 Express is MTR-compliant?
Are your Deployment local ODBCs created? Have they been
created on the proper ODBC driver?

I had issues in the past by mixing SQL2000 and
SQL2005 drivers while installing a Deployment.
As far as I know, your local ODBC entries should be
created with "SQL Native Client" (2005) driver, not
with "SQL Server" (2000) one.

Good luck!

 

[Starrjos]

We are running E9.0 on windows 2008x64 and sql svr 2008x64. We still are using sql s005 express db because 2008 express is not in the MTR.

Having said this, there are some requirements to the ODBC's as well as keeping the compilers in sync. In fact we just had your issue with the F98MOQUE error and it was part of an overall issue with the July 29th Windows security update that affected our manifest level (VS2005 had a security update applied changing the manifest level) information thus preventing packages from truly generating correctly and being in sync at run time.

1) MTR as of 8.98.1.2 did not have SQL SVR Express 2008. This will be a problem because your driver is probably not correct for the foundation requirements.

2) Make sure your visual studio did not take on the July 29th Microsoft Update and you have created a new package.

There can be one of many reasons from some of these messages. Can you provide the top level of your log where the first errors are logged? Do you have a debug log available to look at?

Can you confirm the native driver you are using? Are you using SQL Server Native Client or Native Client 10.0? I do not believe Native Client 10.0 will work with the foundation packages because they expect SSE 2005.

Are you getting errors telling you that there is a tam init failure?

If you can provide a bit more information it would be useful.

 

[tiradoj]

Hi Starrios and Sebastian
Thanks for your quick reply.
No I have not verified MTR for SQL Server 2008 - almost by design. Pushing the envelope I guess.

I have used SQL Server 2005 successfully in the past and I believe I have tried both the SQL Server driver and the native client one but I will confirm.

If I am bringing this issue upon myself shame on me, but I am stubborn and expected JDE should work with 2008.

By the way I have used and tested with SQL Server driver instead of native and it has worked but I will look more closely and check for driver issues in log and the security update you mention.

Thanks guys. I will let you know.
Joe Tirado

 

[tiradoj]

OK

I understand about the MTR stuff and all the local data sources are using native client 10.0 driver

However I was using SQL Server express editions on deployment LONG before JDE admitted it would work and I don't see a technical reason why it would NOT work if it works on the full 2008 edition on ent servr and the 898.X service packs are in place.


My question is it appears E1 is looking SPECIFICALLY for what it calls a "key" in the spec.ini file

The reference Planner_Package=E900 to be exact. What is E900? As I say in 812 this was "MASTER" and the only MASTER I know of is local SQL Servr db. Is this entry same in others spec.ini?

Is E900 to specify release level or a Planner db? I have no such thing. Does anyone else have other Here is spec.ini I have and log below (other tables and fetches work fine)

You can see that the odbc connection is working for other tables in debug log "success"

Thanks again

[SPEC LOCATIONS]
PLANNER_DataSource=Local - PLANNER Specs
PLANNER_Package=E900
DV900_DataSource=Local - PLANNER Specs
DV900_Package=E900
PD900_DataSource=Local - PLANNER Specs
PD900_Package=E900
PS900_DataSource=Local - PLANNER Specs
PS900_Package=E900
PY900_DataSource=Local - PLANNER Specs
PY900_Package=E900

########################################

jdedebug.log


6 - 2880/2620 MAIN_THREAD Fetched the record
Aug 12 13:46:35.875027 - 2880/2620 MAIN_THREAD Fetched the record
Aug 12 13:46:35.875028 - 2880/2620 MAIN_THREAD Fetched the record
Aug 12 13:46:35.875029 - 2880/2620 MAIN_THREAD Fetched the record
Aug 12 13:46:35.875030 - 2880/2620 MAIN_THREAD No More Data found
Aug 12 13:46:35.875031 - 2880/2620 MAIN_THREAD Entering JDB_CloseTable
Aug 12 13:46:35.875032 - 2880/2620 MAIN_THREAD Entering JDB_CloseTable(Table = F98611)
Aug 12 13:46:35.875033 - 2880/2620 MAIN_THREAD Entering JDB_ClearSequencing
Aug 12 13:46:35.875034 - 2880/2620 MAIN_THREAD Exiting JDB_ClearSequencing with Success
Aug 12 13:46:35.875035 - 2880/2620 MAIN_THREAD Entering JDB_ClearSelection
Aug 12 13:46:35.875036 - 2880/2620 MAIN_THREAD Exiting JDB_ClearSelection with Success
Aug 12 13:46:35.875037 - 2880/2620 MAIN_THREAD Entering JDB_ClearAggregate
Aug 12 13:46:35.875038 - 2880/2620 MAIN_THREAD Exiting JDB_ClearAggregate with Success
Aug 12 13:46:35.875039 - 2880/2620 MAIN_THREAD Entering JDB_ClearGroupBy
Aug 12 13:46:35.875040 - 2880/2620 MAIN_THREAD Exiting JDB_ClearGroupBy with Success
Aug 12 13:46:35.875041 - 2880/2620 MAIN_THREAD ODBC:X DBFreeRequest(close) req=08944080 con=03924100
Aug 12 13:46:35.875042 - 2880/2620 MAIN_THREAD Entering JDB_ClearBuffers
Aug 12 13:46:35.875043 - 2880/2620 MAIN_THREAD Exiting JDB_ClearBuffers with success.
Aug 12 13:46:35.875044 - 2880/2620 MAIN_THREAD Exiting JDB_CloseTable(Table = F98611) with Success
Aug 12 13:46:35.875045 - 2880/2620 MAIN_THREAD Exiting JDB_CloseTable with Success
Aug 12 13:46:35.875046 - 2880/2620 MAIN_THREAD Entering JDB_OpenTable(Table = F00941)
Aug 12 13:46:35.875047 - 2880/2620 MAIN_THREAD ODBC:X DBInitConnection shr(5) con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 cur=0,3,6 sep=. (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.875048 - 2880/2620 MAIN_THREAD Exiting JDB_OpenTable(Table = F00941) with Success
Aug 12 13:46:35.875049 - 2880/2620 MAIN_THREAD Entering JDB_FetchKeyed
Aug 12 13:46:35.875050 - 2880/2620 MAIN_THREAD ODBC:X DBInitRequest(new) req=08993028 con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.875051 - 2880/2620 MAIN_THREAD SELECT * FROM JDEPlan900.DBO.F00941 WHERE ( LMLL = 'JDEPLAN' )
Aug 12 13:46:35.875052 - 2880/2620 MAIN_THREAD Entering DBPerformRequest
Aug 12 13:46:35.875053 - 2880/2620 MAIN_THREAD ODBC:X DBPerformRequest req=08993028 con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.875054 - 2880/2620 MAIN_THREAD Exiting DBPerformRequest
Aug 12 13:46:35.875055 - 2880/2620 MAIN_THREAD Opening up local metadata repository. Type - JDESPECTYPE_GBRLINK.
Aug 12 13:46:35.890000 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890001 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890002 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890003 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890004 - 2880/2620 MAIN_THREAD Package name not passed to SetupPackageRDB. Using current running package.
Aug 12 13:46:35.890005 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890006 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890007 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890008 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890009 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890010 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890011 - 2880/2620 MAIN_THREAD A value is not defined for the key, PLANNER_Package, in the SPEC LOCATIONS section of the spec.ini file.
Aug 12 13:46:35.890012 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890013 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890014 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890015 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890016 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890017 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890018 - 2880/2620 MAIN_THREAD A value is not defined for the key, PLANNER_DataSource, in the SPEC LOCATIONS section of the spec.ini file.
Aug 12 13:46:35.890019 - 2880/2620 MAIN_THREAD JDESPEC0000044 - Could not determine spec package name for the path code, PLANNER. Please check the key, PLANNER_Package, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.
Aug 12 13:46:35.890021 - 2880/2620 MAIN_THREAD JDESPEC0000045 - Could not determine spec datasource name for the path code, PLANNER. Please check the key, PLANNER_DataSource, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.
Aug 12 13:46:35.890023 - 2880/2620 MAIN_THREAD Local RDBMS data format is always XML.
Aug 12 13:46:35.890024 - 2880/2620 MAIN_THREAD SpecEncapsulation : jdeSpecOpenLocalOpt completed in error - JDESPECRESULT_FAILED.
Aug 12 13:46:35.890025 - 2880/2620 MAIN_THREAD jdeSpecOpenLocalOpt completed in error - JDESPECRESULT_FAILED.
Aug 12 13:46:35.890027 - 2880/2620 MAIN_THREAD Fetched the record
Aug 12 13:46:35.890028 - 2880/2620 MAIN_THREAD Entering JDB_CloseTable
Aug 12 13:46:35.890029 - 2880/2620 MAIN_THREAD Entering JDB_CloseTable(Table = F00941)
Aug 12 13:46:35.890030 - 2880/2620 MAIN_THREAD Entering JDB_ClearSequencing
Aug 12 13:46:35.890031 - 2880/2620 MAIN_THREAD Exiting JDB_ClearSequencing with Success
Aug 12 13:46:35.890032 - 2880/2620 MAIN_THREAD Entering JDB_ClearSelection
Aug 12 13:46:35.890033 - 2880/2620 MAIN_THREAD Exiting JDB_ClearSelection with Success
Aug 12 13:46:35.890034 - 2880/2620 MAIN_THREAD Entering JDB_ClearAggregate
Aug 12 13:46:35.890035 - 2880/2620 MAIN_THREAD Exiting JDB_ClearAggregate with Success
Aug 12 13:46:35.890036 - 2880/2620 MAIN_THREAD Entering JDB_ClearGroupBy
Aug 12 13:46:35.890037 - 2880/2620 MAIN_THREAD Exiting JDB_ClearGroupBy with Success
Aug 12 13:46:35.890038 - 2880/2620 MAIN_THREAD ODBC:X DBFreeRequest(close) req=08993028 con=0896CCC0
Aug 12 13:46:35.890039 - 2880/2620 MAIN_THREAD Entering JDB_ClearBuffers
Aug 12 13:46:35.890040 - 2880/2620 MAIN_THREAD Exiting JDB_ClearBuffers with success.
Aug 12 13:46:35.890041 - 2880/2620 MAIN_THREAD Exiting JDB_CloseTable(Table = F00941) with Success
Aug 12 13:46:35.890042 - 2880/2620 MAIN_THREAD Exiting JDB_CloseTable with Success
Aug 12 13:46:35.890043 - 2880/2620 MAIN_THREAD Entering JDB_OpenTable(Table = F00942)
Aug 12 13:46:35.890044 - 2880/2620 MAIN_THREAD ODBC:X DBInitConnection shr(6) con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 cur=0,3,6 sep=. (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.890045 - 2880/2620 MAIN_THREAD Exiting JDB_OpenTable(Table = F00942) with Success
Aug 12 13:46:35.890046 - 2880/2620 MAIN_THREAD Entering JDB_OpenTable(Table = F00945)
Aug 12 13:46:35.890047 - 2880/2620 MAIN_THREAD ODBC:X DBInitConnection shr(7) con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 cur=0,3,6 sep=. (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.890048 - 2880/2620 MAIN_THREAD Exiting JDB_OpenTable(Table = F00945) with Success
Aug 12 13:46:35.890049 - 2880/2620 MAIN_THREAD Entering JDB_FetchKeyed
Aug 12 13:46:35.890050 - 2880/2620 MAIN_THREAD ODBC:X DBInitRequest(new) req=04FAF3F8 con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.890051 - 2880/2620 MAIN_THREAD SELECT * FROM JDEPlan900.DBO.F00942 WHERE ( EMPATHCD = 'PLANNER' )
Aug 12 13:46:35.890052 - 2880/2620 MAIN_THREAD Entering DBPerformRequest
Aug 12 13:46:35.890053 - 2880/2620 MAIN_THREAD ODBC:X DBPerformRequest req=04FAF3F8 con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.890054 - 2880/2620 MAIN_THREAD Exiting DBPerformRequest
Aug 12 13:46:35.890055 - 2880/2620 MAIN_THREAD Opening up local metadata repository. Type - JDESPECTYPE_GBRLINK.
Aug 12 13:46:35.890056 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890057 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890058 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890059 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890060 - 2880/2620 MAIN_THREAD Package name not passed to SetupPackageRDB. Using current running package.
Aug 12 13:46:35.890061 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890062 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890063 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890064 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890065 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890066 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890067 - 2880/2620 MAIN_THREAD A value is not defined for the key, PLANNER_Package, in the SPEC LOCATIONS section of the spec.ini file.
Aug 12 13:46:35.890068 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890069 - 2880/2620 MAIN_THREAD PKGBLD: Entering IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890070 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890071 - 2880/2620 MAIN_THREAD Entering IntSvrPkgGetINIPaths
Aug 12 13:46:35.890072 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniFilePath
Aug 12 13:46:35.890073 - 2880/2620 MAIN_THREAD PKGBLD: Exiting IntSvrPkgGetSpecIniPrivateProfileString
Aug 12 13:46:35.890074 - 2880/2620 MAIN_THREAD A value is not defined for the key, PLANNER_DataSource, in the SPEC LOCATIONS section of the spec.ini file.
Aug 12 13:46:35.890075 - 2880/2620 MAIN_THREAD JDESPEC0000044 - Could not determine spec package name for the path code, PLANNER. Please check the key, PLANNER_Package, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.
Aug 12 13:46:35.890077 - 2880/2620 MAIN_THREAD JDESPEC0000045 - Could not determine spec datasource name for the path code, PLANNER. Please check the key, PLANNER_DataSource, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.
Aug 12 13:46:35.890079 - 2880/2620 MAIN_THREAD Local RDBMS data format is always XML.
Aug 12 13:46:35.890080 - 2880/2620 MAIN_THREAD SpecEncapsulation : jdeSpecOpenLocalOpt completed in error - JDESPECRESULT_FAILED.
Aug 12 13:46:35.890081 - 2880/2620 MAIN_THREAD jdeSpecOpenLocalOpt completed in error - JDESPECRESULT_FAILED.
Aug 12 13:46:35.890083 - 2880/2620 MAIN_THREAD Fetched the record
Aug 12 13:46:35.890084 - 2880/2620 MAIN_THREAD Entering JDB_FetchKeyed
Aug 12 13:46:35.906000 - 2880/2620 MAIN_THREAD ODBC:X DBInitRequest(new) req=04FC10C0 con=0896CCC0 env=03BF12A0 dbc=03BF2698 spid=52 (local) A (JDE@EnterpriseOne SSELocal)
Aug 12 13:46:35.906001 - 2880/2620 MAIN_THREAD SELECT * FROM JDEPlan900.DBO.F00945 WHERE ( RMRLS = 'E900' )

 

[Starrjos]

Did you install the Fixpack for 8.98.1.2?

 

[altquark]

[ QUOTE ]

If I am bringing this issue upon myself shame on me, but I am stubborn and expected JDE should work with 2008.


[/ QUOTE ]
Ummm...why ?

JDE take months to create their tools releases. Normally the development department are at least 3 months in advance of the latest "released" tools release.

Secondly it takes about 6 months for JDE to cater to the latest MS released software.

So, given that time lag, you're looking at 9 months from release of SQL2008 to when JDE might initially "support" it, based on experience in the past.

I think you're pushing the envelope very aggressively Joe and I hope you're doing this for a test environment - if not, I would suggest going back and researching your MTR's (which also, in the case of microsoft software, includes MAXIMUM technical requirements too !)

SQL2008 was officially released exactly a year ago - August 8th to be precise. I know that we'd hope that JDE would support it by now, but the likelyhood is that we could be right on the "cusp" of GOOD support ... without being a guineapig. BUT, good luck - sounds like you're uncovering some of the 9.0 issues with SQL2008 - and hopefully Oracle are giving you good support...

 

[tiradoj]

Yes to your question Starrios and to you Sir Jon -- yes it is my LAB environment. Ha I should have mentioned. (I try to prove a given configuration works BEFORE telling a customer regardless of what Oracle will commit to) -- I do state to people I consult for what is supported and what I have "gotten" to work. I leave it to customers to choose what risks they want to take. Like the early adopters of VMWare...which I recently played with Server 2.0 this weekend and created my own virtual machine and virtually networked it. I know I was a little behind curve on that but hey had no play time but I am down with it now. Pretty slick stuff. I want to play with Oracle's version next.

Now, some new info on this issue though. On an 812 instance I can sign into JDEPLAN without the spec.ini file altogether which brings up some interesting ideas. Of course things always change but now I am wondering whether the spec.ini is a decoy.

Thanks for input though. Going to do some more testing.
Joe Tirado

 

[Starrjos]

I agree. Although I had the option to use SSE2008 to push the envelope, I decided it would not be worth it because Oracle will question the MTR first when we are on the bleeding edge.

We installed on to Windows 2008x64 and sql 2008x64 and yes we have had issues but the drivers are issues when going between 64bit and 32 bit.

There are other issues as well. When I got that F98MOQUE error (just on Monday after a package build) I found 2 issues. 1) the microsoft update from July 29. This really only prevented the callbsfn.dll (and others) to fail because the manifest.dll did not match the deployment server vs client. 2) We added 6 gig of memory to our deployment server and then the hibersys.fil filled up my c drive. Although I didn't use the C drive on my deployment server for anything other than basic windows applications the drive needless to say became full and the package really was not building correctly. Check your C drive on your deployment server and make sure you have enough space. The package build might look like it worked but it is very possible the specs did not get written do to lack of space.

Let me know what you find.

 

[tiradoj]

Hey Starrios

I have not even been able to sign in. This is what I am saying. After running images of RunInstall and trying to sign into JDEPLAN for first time it's been a no go.

Joe Tirado

 

[Starrjos]

This is what Oracle explains in regards to this new configuration:

EnterpriseOne 9.0 comes in 2 different configurations, OEE and SSE. This issue applies for both OEE and SSE configurations.

Quote from KG: (not my grammer)

Development confirmed that the deployment server now use the Planner specs, this is correct. Here is in more details what is happening.

NOW, in ERP9.0, on the deployment server, you really should ONLY sign on as JDEPLAN or DEP environment. The PS, DV, PY or PD pathcodes are under the spec directory; if you look in there, they no longer have their own specs, they all point to the planner specs and that is what the spec.ini file is indicating. It is pointing to the planner specs.

Because of this, if you sign on as DV for instance.. then the specs in planner might not match the Bin32 under DV; because could be the case that ESUs were put into DV that might not have been put into planner, so the bin32 DV was updated when package was build, but not the planner specs which is what DV is using.
So, if this is your only issue, it is working as now designed

 

[altquark]

[ QUOTE ]
I want to play with Oracle's (VM) version next.

[/ QUOTE ]
Oracle VM is insanely difficult to get up and running. I personally am using VMWare ESXi - which is now free and is the most widely used virtualization product out there.

Oracle is more than likely going to dump Xen - for two reasons. First of all, Xen is now owned by Citrix (at least Xensource is owned by them). Secondly, Oracle owns Sun now, and with that came VirtualBox - Suns Virtual platform, which is a lot more mature than Oracle VM and supports a LOT more platforms (both host and guest). I'm going to try using VirtualBox after I get my ESXi E1 9.0 implementation completed (in my lab) - and will put it on the exact same hardware as the ESXi - so I'll be able to run performance benchmarks. I'll get a copy of Microsofts Virtual Server too and will run comparisons on it as well...

VMWare 2.0 is not bad, but its no enterprise product - but it IS free !

 

[tiradoj]

Oops I think I have your screenname wrong Starrjos yes? With a J? I apologize.

You wouldn't happen to have the KB number for the July 29th update would you?

I am looking at my Updates in Add Remove and I see that Visual Studio 2007 Tools for applications is installed aswell. Would that cause issues in builds?

I did not intend to install 2007 I have just been taking the latest updates indiscriminately since it was a lab machine.

"2) Make sure your visual studio did not take on the July 29th Microsoft Update and you have created a new package."

Thanks
Joe Tirado

 

[Starrjos]

KB973923 (Visual Studio C++ 2005 ATL Update).

Check your specs in the bin32....compare/validate the dll.manifest. Mine were out of sync (package build vs client spec manifest).

The old manifest looked like this:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>

The new one looked like this:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32'

name='Microsoft.VC80.CRT' version='8.0.50727.4053'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Note the 4053

processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>

 

[tiradoj]

Hello Starrjos

First to respond to your earlier note about Planner specs. I have NEVER used environments other than JDEPLAN and DEPXXX from the deployment server. We were trained why other environments were not real environments wayyyy back in 90s and I have never understood why others tried to use DV8XX etc from deployment server - and I train those I work with accordingly.

In any case, I am still not clear what "E900" is referring to.

Now regarding your manifest question, my xxx.dll.manifests are using the "old" version reference but again I am not sure how that affects sign in UNLESS E1 is expecting 4053 instead of 762 which would be bizarre but stranger things have happened.

Please clarify the manifest version mismatch issue and consequences.

Thanks
Joe Tirado

this is mine

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762'

processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>

 

[tiradoj]

It could be that E900 is referring to the E900 FOLDER under JDEdwards on my drive, yes?

Could it be a Windows security issue perhaps? I shared out E900 to Everyone as recommend--only lab machine

Assuming the problem is EXACTLY what the message in log states:


944/1660 MAIN_THREAD Wed Aug 12 15:38:42.796020 SpecOpen.c2804
JDESPEC0000044 - Could not determine spec package name for the path code, PLANNER. Please check the key, PLANNER_Package, in the SPEC LOCATIONS section of the JDE.INI file or the spec.ini file. This settings need to be availabe in one of these files.

Why is it having an issue with
'Planner_Package=E900' setting if that's what you have on your 9.0?

Joe Tirado

 

[Starrjos]

Are there any errors registered in your Attach_Planner log? There are some issues with SQL SVR 2008 in regards to attaching databases but were to have been resolved in 8.98.1.x however......they may not have looked at SSE2008 and maybe you don't have the database attached for planner??

 

[tiradoj]

First error says this in log

"A value is not defined for the key, PLANNER_Package, in the SPEC LOCATIONS section of the spec.ini file. "

But it isn't true. There IS a VALUE in there. It is E900. Is that what you have Starrjos?

Joe Tirado

 

[Starrjos]

My look like this:

[SPEC LOCATIONS]
PLANNER_DataSource=Local - PLANNER Specs
PLANNER_Package=E900
DV900_DataSource=Local - PLANNER Specs
DV900_Package=E900
PD900_DataSource=Local - PLANNER Specs
PD900_Package=E900
PS900_DataSource=Local - PLANNER Specs
PS900_Package=E900
PY900_DataSource=Local - PLANNER Specs
PY900_Package=E900


I believe they just append the E900 on the backside of the spec database for updates.

I also saw on the KG where some install disk were corrupt during installation that required a re-install of the deployment server.

 

[tiradoj]

Ok Update on this Issue. I am not sure why this would be an issue in 9.0 but I renamed my Planner SPEC_E900 logical name to SPEC_MASTER since that is what it's physical name is for local db. I also changed the E900 Planner_package paramter reference in the spec.ini to MASTER as it is in 8.12. (It is NOT a package it is a database table suffix more like-why they can't name things more accurately?)

Once I did that I could log into to 9.0 JDEPLAN environment perfectly. I don't know if this is in the manual or known issues doc somewhere (but I am tired and might have missed it) but I bet I could have used SQL Server 2008 Express. I put on SQL Server 2005 express quite reluctantly and now I want to know if there is an upgrade path to 2008. It irritate the bejesus out of me this can't install correct out of the box.

Starrjos now I know what you mean by adding to back end of table names as that is how login process connects to the SPEC MASTER tables and does the JITI.

As an aside, I wrote up a white paper of sorts that tells how to keep the Planner Specs in sync with a give Path Code specs (table specs) say DV812 so that R98403 could be run from the Deployment server if desired. I can hear the objections now but I run it often in JDEPLAN when I want to take advantage of deployment server speed.

Now we'll move on to pkg build and business functions. I suspect I will have a few issues to deal with there after I do my fix current.

Joe Tirado
Senior CNC Consultant