Wednesday, March 18, 2009

Unable to WRITE to MediaObject File : error after new OAS Tools release upgrade.

Folks,

I was getting below media object errors after the installation of new tools release on OAS 10.1.3.1 on Windows..

Tools release : 8.97.1.1
Web Server: Windows
JDE Release: E810

18 Mar 2009 11:49:12,978 [Line ?] [SEVERE] TESTMF - [JAS] Exception occured in the JDEOWDirect.saveFileMOWinNTShare():| source file Name :C:\OracleAS_10131\j2ee\OASMF\applications\TG_MF_OAS\webclient\moqueue\NARICHDEP\E810\MEDIAOBJ\OLEQUE\OLE-172-17-0-101-1517870716947013-1237391336384.doc java.lang.Exception: Unable to WRITE to MediaObject File : \\NARICHDEP\E810\MEDIAOBJ\OLEQUE\OLE-172-17-0-101-1517870716947013-1237391336384.doc
java.lang.Exception:
Unable to WRITE to MediaObject File : \\NARICHDEP\E810\MEDIAOBJ\OLEQUE\OLE-172-17-0-101-1517870716947013-1237391336384.doc
at com.jdedwards.jas.JDEOWDirect.saveFileMOWinNTShare(Unknown Source)


This issue got resolved after performing the below solution.

User assigned to start the web services was a local account. This was changed to a valid Domain user with administrator privileges.

Mapped a Network Drive to the Deployment Server Share folder E810 (where mediaobj directory resides) on the JAS server.

Verify that 'UseMOWinNTShare' is set to TRUE under [OWWEB] section of jas.ini otherwise it will require a ftp setup with userid and password.

Thanks

Thursday, March 12, 2009

No Applications were running after doing full Web Generation in 8.97

Folks,

After installing new OAS 10g R3 on Intel and installing new HTML Server 8.97.1.1 using Server Manager and performing full web generation, I was getting these errors on Screen while running P01012 (Address Book) Program.

""COULD NOT LOAD FORM
Please use the latest Java generator to regenerate the
form.P01012_W4210E_ZJDE0001"

In Jas.log Erors were:

[WARN ] PSFT - [BASE] binary2Object failed desaerializing a byte array java.io.InvalidClassException

After spending some hours in validating the install, I found that default jdk which I was using on generation machine from Websphere Express was not same as what got installed as part of OAS and after copying the JDK from JAS machine to the generation machine the above errors were gone and I was able to run the Applications as desired.

Steps to identify and resolve the issue.

1) On the JAS server navigate to the java directory (e.g. C:\OracleAS_10131\jdk\bin) and run command line : java -version and note the JDK version.

2) On the generation machine navigate to the java directory (e.g. c:\810\system\JDK\bin) and run command line: java -version and note the version.

3) Verify the java version - it must match between the generator and the JAS server.

IF NOT SAME THAN

4) Copy the jdk from the JAS machine to the generation machine i.e. JAS jdk: C:\OracleAS_10131\jdk to generation machine location: C:\e810\system\jdk

5) Truncate the F989999 and F989998 table via OMW -> Table Operation-> Generate Table

6) Launch generator

7) Generate the core objects and a single application (P01012)

8) If successful, execute a full generation.

Friday, March 6, 2009

Do you see a Time stamp Discrepancy on Package Build??

Folks,

Checkout this when you build a package and ready to deploy what is the application build date and time ?? Probability is high that JDE Release 8.9 and above you will be having a time stamp discrepancy. If you build a package at night 10pm it will show next days date and time due to this discrepancy of UTC hours.The build time that is displayed for packages in the package selection of the package installation application (from setup.exe) is exactly 4 hours ahead of the current time.

This is the explanation from Oracle for that discrepancy..

Development wanted the timestamp to be a global one, so always stamps the package's build time with GMT time. If you have multiple locations all over the world building packages, then the timestamps would be globalized rather than localized. This information is stored as the build date/time in the package's inf file as the AppBuildDate. This is used to compare to what is in the registry of the machine you are installing a package on, and will update the registry with this date when the package is installed.

You can change this under USER PROFILE Universal Time Tab and set a new entry for your country or location to match the current date and time if required and your company is not global.

How to default a UBE Version to run as Print Immediate??

You can set any UBE Version to run as Print Immediate without having user going to advance override and selecting Print Immediate on a day to day basis. This can be done by changing the flag to 1 in column VRVCC3 in Version Table (F983051) under each Environment's Central Objects.

Issues with Tools Release Upgrade from JDE 8.96 to 8.97 and above.

Folks,

I want to share the issues I encountered after upgrading my tools release from 8.96 to 8.97 I was required to change the following section under JDE.INI and there was no information about these in Tools Release install doc from Oracle.

I was getting errors in jde.log after starting services on New Tools Release 8.97 and later found that I have to make the below changes in JDE.INI to get rid of those jde.log startup error messages.

Changed the following sections in JDE.INI on Enterprise Server (iSeries/AS400).

#Before:
[JDENET_KERNEL_DEF30]
krnlName=METADATA KERNEL
dispatchDLLName=MetadataDispatch
maxNumberOfProcesses=1
numberOfAutoStartProcesses=1

#After : JDENET_KERNEL_DEF30 Section Replaced as per Oracle Support Doc ID 651830.1

[JDENET_KERNEL_DEF30]
krnlName=METADATA KERNEL
dispatchDLLName=MDSERIALIZ
dispatchDLLFunction=MetadataDispatch
maxNumberOfProcesses=1
numberOfAutoStartProcesses=1

#Before:
[JDENET_KERNEL_DEF31]
krnlName=XMLPUBLISHER KERNEL
dispatchDLLName=XMLPDispatch
maxNumberOfProcesses=5
numberOfAutoStartProcesses=0

#After : JDENET_KERNEL_DEF31 Section Replaced as per Oracle Support Doc ID 654237.1

[JDENET_KERNEL_DEF31]
krnlName=XMLPUBLISHER KERNEL
dispatchDLLName=XMLPUBLISH
dispatchDLLFunction=XMLPDispatch
maxNumberOfProcesses=3
numberOfAutoStartProcesses=0

#Before:
[JDENET_KERNEL_DEF32]
krnlName=MANAGEMENT KERNEL
dispatchDLLName=ManagementDispatch
maxNumberOfProcesses=1
numberOfAutoStartProcesses=1

#After: # JDENET_KERNEL_DEF32 Section Replaced as per Oracle Support Doc ID 661321.1
[JDENET_KERNEL_DEF32]
krnlName=MANAGEMENT KERNEL
dispatchDLLName=JDEMGMT
dispatchDLLFunction=ManagementDispatch
maxNumberOfProcesses=1
numberOfAutoStartProcesses=1


#RECYCLING of CallObject Kernels could cause the issue so if users reports of any session #blowouts of application close error you may have to comment the below section of RECYCLING

# Commented by as per Oracle Support Doc ID 663990.1

#[RECYCLING]
#krnlRecycleTimeOfDay=Sun:03:30
#krnlRecycleElapsedTime=
#inactiveUserTimeout=6:00
#timeToForcedExit=12:00