DIR_CT_RUN options

[Former Member]

There is a new Kernel option for those of us running 7.x kernels. Once again SAP have changed the IBM i SAP kernel structure.

I am interested if people have opinions about the best usage of this new option.

Below is the start of note #1632754

With SAP NetWeaver 2004s and associated products and with the application

basis 7.0x together with the 7.20 kernel, SAP introduces a new directory

structure with IBM i; you can use this to maintain a kernel while the

instances of the system are active. This minimizes the amount of time for

which the system is unavailable.

With the new directory structure, the SAP kernel is installed in a central

directory (indicated by the profile parameter DIR_CT_RUN). From there, the

kernel is copied during the system start to the instance-specific kernel

directories (indicated by the profile parameter DIR_EXECUTABLE). The kernel

is replicated using the program sapcpe. Each SAP instance then uses the

kernel from its own instance-specific directory.

So it looks like we can set DIR_CT_RUN to update the kernel from a central location.

Anyone got any plans or thoughts on this option?

Thanks

Matthew

[Former Member · Accepted solution]

A timely question. I tried to implement 1632754 in a dual stack (solution manager) system with the 7.20EXT kernel but sapcpe tried to update /usr/sap/SOL/D22 instead of /usr/sap/SOL/DVEBMGS22 even though DIR_INSTANCE resolves to the correct directory in AL11. The instance started but did not come all the way up (subsystems started but no work processes). I may have missed something but I've looked at it a few times and don't see what it could be. I did notice that the note for unix said to run sapcpe once first (prime the pump?) I may try that when I can get the system for a few hours again. Let me know if you have any success because this is a great idea.

[Former Member · Accepted solution]

Hi Rick,

The simplest solution to your D22 vs DVEBMGS22 is to change both:

DIR_EXECUTABLE = $(DIR_INSTANCE)/exe

DIR_CT_RUN = $(DIR_EXE_ROOT)/run

replace the DIR_INSTANCE and DIR_EXE_ROOT by the full access path eg:

DIR_EXECUTABLE = /usr/sap/SOL/DVEBMGS22/exe

DIR_CT_RUN = /usr/sap/SOL/SYS/exe/run

What we have done in the past when facing SAPCPE issues is just copy the libraries manually.

qsh cmd('cp -r /usr/sap/SOL/SYS/exe/run /usr/sap/SOL/DVEBMGS22/exe')

Then restart the system.

This worked for us.

Regards,

Yannick C.

[Former Member · Accepted solution]

Thanks for the quick reply. In the interim, I did find what I had done wrong. It's kind of embarrassing but in the EXECUTE_00 statement in the start profile, I had a space between the $ sign and the (_PF). Once that was fixed, it did run. However, it did not copy all of the subdirectories. I realize this is controlled by the sapcpeft file but I am a little concerned that the file did not contain all of the subdirectories in the first place. Most notably the jvm subdir. Note 1632754 mentions changing values for javaVMLibPath in the vmprop files to use the instance directory but that won't work unless there is a jvm subdirectory (with all of it's subdirectories. I just deleted the vmprop files and let the system regenerate them and it did append the new instance directory on the end so I'm not sure if I need to worry about this or not. I could just do the manual copy you mentioned I suppose but I am wondering if there is any downside to that? Thanks -Rick

[Former Member · Accepted solution]

No worries the important thing is that it works.

We copy the jvm using these lines in the start profile.

_CPARG0 = list:$(DIR_CT_SAPJVM)/sapjvm_4.lst

_CPARG1 = source:$(DIR_CT_SAPJVM)

Execute_01 = immediate $(DIR_CT_RUN)/sapcpe$(FT_EXE) pf=$(_PF) $(_CPARG0) $(_CPARG1)

Then we reconfigure java using the menu options at the os level.

Menu option:

7. SAP Java Tasks

10. Configure SAP Java stack (CONFIGJVM)

2. Configure VM Options - Apply

Then just enter the JVM path to:

/usr/sap/SOL/DVEBMGS22/exe/sapjvm_4/bin

sapjvm_4 = should be based on your java version (sapjvm_4, sapjvm_5 or sapjvm_6)

Note that this need to be reconfigured if you change sapjvm version.

[Former Member]

Matthew personally I find the new kernel amazing! Once you get sapcpe fully functional it is wonderful. The online upgrade feature is really nice to minimize downtime, we dont use it this way but you could also upgrade multiple systems at the same time.

Once you upgrade to kernel 720 I would highly recommend at least trying sapcpe in a dev or sandbox environment.

Unless I am mistaking this functionality has been existing for some time now for windows/unix users, or so I heard.

Anyhow my opinion is that it works great, and actually simplified our life. Just note one thing upgrading the kernel will take much longer, but since the system stays live it`s not an issue for us.

Regards,

Yannick C.

[Former Member]

Thanks again Yannick. I would agree that the new kernel and APYSIDKRN are good things. One caveat. If you are using RFC calls (like in an EDI environment), make sure you check out note 1581595. There is another discussion about that on this forum here: http://scn.sap.com/thread/3233422.

[Former Member]

Yannick - a couple of notes if I might. The qshell copy command you cited:

qsh cmd('cp -r /usr/sap/SOL/SYS/exe/run /usr/sap/SOL/DVEBMGS22/exe')

actually put subdirectory /run (and all of it's files and subdirectories) inside of the instance /exe directory. In order to get rid of that, I removed /usr/sap/SOL/DVEBMGS22/exe and ran the copy from the hard link as follows:

qsh cmd('cp -r /sapmnt/SOL/exe /usr/sap/SOL/DVEBMGS22')

Also you specified using /usr/sap/SOL/DVEBMGS22/exe/sapjvm_4/bin as the JAVA_HOME directory when running the CONFIGJVM command. I don't think the /bin is necessary and my sapjvm_4 is actually buried (excuse me, "nested") a few levels deeper in:

/usr/sap/SOL/DVEBMGS22/exe/jvm/as400_pase_64/sap_4.1.023/sapjvm_4

which follows the standard naming convention. Then, when adding a patch, the new subdirectory might be something like sapjvm_4.1.025 which would need to be noted when re-running the CONFIGJVM command.

These are small things but I thought I should point them out just in case someone else (who might be as "java stupid" as I am) might be reading this. Thanks again for all your help. This should save me a lot of weekend hours and that is a very good thing.

[Former Member]

Well sorry I'll admit that the provided command was from memory, but I'm happy you got the idea.

For the CONFIGJVM, actually I think the BIN is not required, that was my mistake! I am truly not convinced about the path you provided though. Because in our case I have checked sapjava_4 and sapjvm_6 and none use the path you provided they all use '/usr/sap/<SID>/DVEBMGS<##>/exe/sapjvm_4'. The whole objective is to not have to change the config. every time we upgrade java.

If you could please check the sapcpe_sapjvm_4.log file in your work folder.

Review your source and target entries (make sure they look as below):

source: /usr/sap/SOL/SYS/exe/jvm/as400_pase_64/sapjvm_4.1.025

target: /usr/sap/SOL/DVEBMGS22/exe

Then navigate to your sapjvm_4.lst file (this contains what needs to be copied! it should look like below)

sapjvm_4.lst

sapjvm_4

sapjvmmanifest.mf

Now if everything looks the way it should this means that sapcpe is copying from the source folder everything that in the lst file to the target folder.

So in your "/usr/sap/SOL/DVEBMGS22/exe" you should find the files sapjvm_4.lst & sapjvmmanifest.mf and the folder sapjvm_4.

If you dont have this I would rerun sapcpe manually, this way you will save even more on weekend work! ;o)

sapcpe logs per execution so it is really handy, you can debug both sapjvm and standard kernel independently.

Let me know how it goes...

Regards,

Yannick C.

[Khouri]

To be honest I was not aware about SAPCPE in connection with SAPJVM and I appreciate your contributions and hints.

I fully agree with Yannic that SAPCPE provide a very nice functionality when exchanging Kernel components, never the less I think there is still room for improvements particularly :

1.) run time of spacpe during SAPSTART when no component of the kernel is exchanged

2.) I can't found any official statement about deleting SQL packages with sapcpe, it was self-understanding to do it when updating "non DCK kernel"! 

We still delete the SQL packages manually even SAP says that with sapcpe it needs only a restrat but I think it is not applicable for IBM i?

Best regards,

Hadi

[rdiger_hckel]

> 1.) run time of spacpe during SAPSTART when no component of the kernel is exchanged

I absolutely second that.

[Former Member]

My sapjvm_4 is in the directory I specified. However, I created it manually when I did the cp -r command from /sapmnt/SOL/exe. I suppose I could (and probably should) set it up the way you mentioned to avoid having to run CONFIGJVM every time I patch java. Basically get rid of what exists and then:

qsh cmd('cp -r /sapmnt/SOL/exe/jvm/as400_pase_64/sapjvm_4.1.023/* /usr/sap/SOL/DVEBMGS22/exe')

or something like that so I would have sapjvm_4.lst, sapjvmmanifest.mf, and directory sapjvm_4 right in /usr/sap/SOL/DVEBMGS22/exe??

I also agree with Hadi's point about the runtime of sapcpe when no compomnent is exchanged. It appears from my log that it runs "fixsapown" every single time even though nothing else has changed! (and that takes some time)

[Former Member]

Somewhere between kernel patch 312 and 416 (for kernel 720_EXT anyway), this seems to have been fixed. SAPCPE finishes very quickly now on the system where I applied that kernel update.

[Former Member]

Thanks. So that would give us the same option for the jvm? That is, the "live" version would be in the instance directory and we would do the updates to /usr/sap/SID/SYS/exe/jvm/as400_pase_64/sapjvm_<version>/sapjvm_4 and cascade the updates via the profile parameters you mentioned? I did note this in the online help: "Attention: If your system is already configured to replicate SAPJVM from a central directory to instance local directories via sapcpe, CONFIGJVM will reconfigure local instances to use the central copy of SAPJVM. This will likely be undesired and you should not use CONFIGJVM in such a setup." I'm taking that to really mean, "pay attention to what you are doing here."

[Former Member]

Essentially, yes! The sapjvm_4 directory will be copied under

"/usr/sap/SOL/DVEBMGS22/exe/". So when the instances is running it will use the sapjvm under ..DVEBMGS22/exe/ . This does give you the flexibility to update your sapjvm while the system is live!

Well as for the CONFIGJVM, if you use the default setting you might run into problems. But running it is a sure and easy way to change all the references of JAVA_HOME in the config tool to point to the right location. You can chose to go through the configuration manually but this is "real work".

So far we have not had any issues with running CONFIGJVM, however I would not recommend going against SAP recommendations.

The problem we faced using the standard java directory is that we needed to change the config every time we patched java. To us that was as close as we could get to "java hell". Kernel patches are standard operations and updating the config ever time we apply a small patch seemed crazy to us. sapcpe and CONFIGJVM is how we fixed the problem.

I really hope this helps you out...

Regards,

Yannick C.

[Former Member]

Indeed this is very helpful. Thank you. I am painfully familiar with "java hell". Is there a CONFIGJVM for windows app servers as well?

[Former Member]

In all honesty I know nothing about running SAP on Windows, so I am not sure I could be of any help. But my guest would be checking the sap mmc. If you can't find it there then unfortunately I cant help...