Is an add-in MCOD

[Former Member]

Is an add-in J2EE truly an MCOD system?

Please, no guesses, answer if you truly know.

if not, what is the difference?

[markus_doehr2 · Accepted solution]

Technicall it is - yes.

It creates a new schema in the system under a different and thus it´s MCOD.

I would avoid installing a Java Addin into an AS ABAP - administrative nightmare.

Markus

[Former Member · Accepted solution]

Sorry Marcus, I should have been more specific.

It is a seperate schema in Oracle so is technically as you say.

However it has the same SID as the other schema and so does that mean SAP treats it differently with its software.

My questions should have read "does SAP treat an add-in like a dual SID MCOD"

For clarity the issue is this.

a BW V7 J2EE add-in was installed on dev & QA. When it came to production the 32 bit limitations the customer had at the time meant it had to be installed stand alone as the database could not handle more connections or reduce the DB buffer more.

The systems will be going 64 bit soon and to resolve the conflicting types the onsite team have decided to have the systems stand alone so they can start seperately via MMC but MCOD.

This indicates to me that the system is now neither an add-in or stand alone and so just causes more complexity. On top of which I am worried taht some additional MCOD pain may be had if SAP treats it differently from an add-in with regard to anything (migratiosn/copies etc)

you seem like a man that can answer this ... 10 points in it for you sir!

[Former Member · Accepted solution]

The JAVA and ABAP systems can be started and shut down seperately even if their are installed on the same database as a MCOD system, without the database needing to be stopped if that makes sense

Their is no conflict.

The Java system can be restarted from the abap stack or from a utility on the commandline.

With Dule Stack systems SAP recommend the MCOD method, and its really easy to do the java install, once the initial ABAP stack is ready.

i wouldn't recommend a seperate JAVA database for a double stack system.

I've personally done installation, any further questions drop me an e-mail

Regards

James

[Former Member · Accepted solution]

Its not that hard :-).

i've done it for XI3.0, works fine witout any problems.

[Former Member · Accepted solution]

James

please reread my question for what I am truly asking. It appears I am not making myself clear so here goes again.

If you have a J2EE engine with a SID ABC in an MCOD with an ABAP of XYZ will SAP toold like SAPINST treat it any differently than if the J2EE and ABAP were both called GEF.

I suspect that SAP tools do treat an Add-in differently than two systems MCODded but I could not 100% say so, I am hoping someone in SAP that is clever can answer this for me.

[markus_doehr2 · Accepted solution]

Sorry Marcus, I should have been more specific.

It is a seperate schema in Oracle so is technically as you say.

However it has the same SID as the other schema and so does that mean SAP treats it differently with its software.

Combined ABAP + Java installation are treated differently "by default"

<...>

The systems will be going 64 bit soon and to resolve the conflicting types the onsite team have decided to have the systems stand alone so they can start seperately via MMC but MCOD.

A good decision - and I would stay with that even when on 64bit because

- memory sizing will be difficult/more complicated

- Java and ABAP will fight for CPU

- inter-dependencies (if you install SPs on BI you have to install them on Java at the same time on the same machine)

This indicates to me that the system is now neither an add-in or stand alone and so just causes more complexity. On top of which I am worried taht some additional MCOD pain may be had if SAP treats it differently from an add-in with regard to anything (migratiosn/copies etc)

defnitely.

Combined instances (and also Java standalone instances) can´t be copied by using database backups only, the filesystem must be backed up at the same time and being in sync with the database. One will need to use sapinst to do the copies (http://service.sap.com/systemcopy). For combined systems, there´s a "combined upgrade" necessary, means, SAPup and SAPJup must be run in parallel and you have to check the sync points. So from an administrative view it´s really a LOT more complicated than using a separate installation.

I´ve done an upgrade from SolMan 3.2 (also ABAP + Java) to SolMan 4.0 - and it was really a nightmare. 70+ notes, two upgrade guides, dependencies...

We use separate Java instances for all our applications (CRM, SRM, BI) - we have more "portal installations" then but it will keep us off from dealing with "combined" stuff.

Older installation/master guides recommended to install a combined instance but nowadays SAP recommends to install everything separately.

Markus

[markus_doehr2 · Accepted solution]

> Its not that hard :-).
> 
> i've done it for XI3.0, works fine witout any problems.

Yes - for XI you have no choice, you MUST use a doublestack installation.

It´s not the installation but the MAINTENANCE which is a mess.

Markus