This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Locking HANA Database Users During Maintenance

Running SAP S/4HANA means there are now more direct HANA DB accesses through a variety of Analytics tools, development tools and external reporting systems.
This can present a problem when it comes to patching and maintenance of the system, since you would not want to officially release the HANA database back to end-users until you had performed your preliminary checks to conclude th patching was successful at all levels of the application stack.

Most BASIS administrators are familiar with the usual “tp locksys” command to be able to lock everyone except SAP* and DDIC out of the SAP ABAP application layer.
But what can be done to stop connections direct into the HANA database?
SAP note 1986645 “Allow only administration users to work on HANA database”, provides an attached SQL file which delivers a few new stored procedures and some new database tables.

The stored procedures include:
– 1 for “locking” out non-system users.
– 1 for “unlocking” non-system users (the exact reverse operation against the exact same set of users that was initially locked).
– 1 for adding users to an exception list table.
– 1 for removing users from an exception list table.

The tables are used to store an exception list of users to be excluded from the locking operation.
You will need to add the “SAPABAP1” S/4HANA schema, XSA DB user and cockpit user to the exception list!
Also add any backup operator user accounts needed to perform backups or if you need to leave enabled a specific set of test user accounts.
There is also a table used for storing the list of users on which the last “locking” operation was performed.

As well as “locking” (the HANA DB accounts are actually disabled) the user accounts, any active sessions for those user accounts are kicked off the database instantly.
This feature is useful in other ways (for example, emergency access to a severely overloaded/failing HANA database system).
Of course if you are running something other than S/4HANA on HANA (maybe Solman), then direct database access may not be a requirement, therefore this set of SQL stored procedures are not so relevant.

How do you implement the SQL?
– Download the SQL from the SAP note and save to a file.
– Either execute the SQL using in the TenantDB as the SYSTEM user in HANA Studio, HANA Cockpit or use hdbsql in batch mode (hdbsql doesn’t like the code to be pasted at the prompt).

How do you add users to the exception list:
– As SYSTEM in the TenantDB, simply execute the store procedures:


How do you utilise the feature?
– As SYSTEM in the TenantDB, simply execute the store procedures:


When you’ve finished and wish to “unlock” the previously locked accounts:


SAP Netweaver AS Java 7.50 End of Maintenance

If you’re a green-field or brown-field SAP customer and you will be deploying on-premise, you may well have a capability requirement to deploy Adobe Document Services for your SAP estate.
This is usually the case if you will be creating professional PDF documents, for example, for invoicing or payslips.

If you do have this requirement, then you need to be aware of the up & coming end of mainstream maintenance for SAP Netweaver AS Java 7.50.
You see, normally, the end of mainstream maintenance of SAP Netweaver based products is no big deal, you can always pay the extra cost for an extension to your maintenance agreement.  This is quite nicely titled “Extended Maintenance”.  Neat.
However, like the sub-title to a never ending action movie trilogy, “this time it’s different.”
SAP have definitively stated in SAP note 1648480 that there will be no extended maintenance for Netweaver AS Java 7.50!

Application Server Java within SAP NetWeaver 7.50 will be supported in mainstream maintenance to end of 2024. Extended maintenance will not be offered.

The SAP product availability matrix (PAM) and also SAP note 1648480 both state that Netweaver AS Java 7.50 is supported until 31 December 2024.
But why is this different to SAP Netweaver AS ABAP you may be asking?
It comes down to the third-party technology within the Java stack and the mismatch of available support cycles from the third-party vendors in accordance with SAP’s support cycles.
This is noted in the SAP note previously mentioned.

Although there is no detail in the SAP note, it does make sense if you know that SAP take updates for the SAP JVM from Oracle (the custodians of Java).
As we know from my previous article, the Oracle JVM 8 is being sunset, which could be causing a bit of a headache (cost) for SAP since the Oracle JVM 8 technology is incorporated into SAP JVM 8.
The SAP JVM 8 is the underpinning of Netweaver AS Java 7.50.
Coincidence?  Maybe.  But also remember from my article that Oracle are very kindly providing a paid-for subscription service for updates to JVM 8.
I guess SAP will be one of those customers.

So what are your options now you’re aware of the NW AS Java 7.50 end of maintenance?
There are currently no options available for deploying Adobe Document Services within an SAP Netweaver AS Java instance!
But, there is the possibility that you can use the new SAP Cloud Platform Forms by Adobe SaaS offering from SAP.
Quite simply, you pay per PDF.

In the short-term you may well decide to stick to the tried and tested method of deploying ADS in NW AS Java 7.50.
Just consider the overheads that this may induce and compare it to the SaaS option “SAP Cloud Platform Forms by Adobe”.

Examples of overheads:

– How many ADS instances you run: maybe 2x PRD (with HA/DR), 2x Pre-PRD (with HA/DR), 1x TST, 1x DEV, 1x SBX  ??
– Cost of SAP Netweaver licenses for each of those.
– Cost of any SSL licenses.
– Cost of operating system support.
– Cost of hardware & maintenance to run those.
– Cost of backups (admin & actual storage costs) to run those.
– Cost of HA/DR setup (cluster & replication maybe).
– Overhead of the risk assoiated with unplanned maintenance / outages (meltdown/spectre anyone?)
– Overhead of admin & regular security patching (we’re all doing the SAP super Tuesday patching – right).
– Overhead of yearly DR tests.
– Overhead of yearly backup & restore tests (are you even doing these?).
– Overhead of yearly PEN tests (if on the same subnet as your credit card transactional processing systems).
– Current rough uptime/SLAs.

Solution Manager 7.01 MOPZ Stuck Calculating Selection

I had an issue with Solution Manager 7.01 SP24 where I had created a maintenance transaction for an SEM system (with a sidecar Java stack) and it got stuck in the “calculating” step when in the “Selection” stage.
It would just sit on the screen with the blue circular logo spinning and nothing happening.  It did not timeout and when I left it for a day, it was still not progressing.

So, I opened another one, and it got stuck at the same point:

Solution Manager MOPz Calculating Stuck

I had made a change to the Java stack technical system in SMSY to indicate that the landscape pattern was “SIDECAR” as instructed by the SAP documentation, but this just didn’t seem to be working for me.

So I removed the “SIDECAR” definition and now want to cancel the two transactions:

MOPz transactions

Following SAP note 1296589, I opened transaction “/TMWFLOW/MAINTENANCE” and entered in the two “open”  transaction IDs and clicked Execute:



The SAP note goes on to say:  “If any MOPZ planning procedure is displayed in the search result with User Status other than “New”, then it’s the locking planning procedure.“.
So we can see that we have both transactions locking the planning procedure.  Woops!

Maintain the table TSOCM_COND_MAPP using SM30 (use a user other than DDIC for this!):


Find the line entry “SLMO  SLMO0001  E0002  40  SYSTEM_ASSIGNMENT…”:

Table TSOCM_COND_MAPP entries for SLMO

Change the column “MT” from “Cancel” to “Warning”:

Table TSOCM_COND_MAPP entries for SLMO

Save your change.  You will need to save the change to a transport request:


I then re-opened the maintenance transaction from SOLUTION_MANAGER and unfortunately it was still stuck on “Calculating…”.
So, the next step was to try and remove the two transactions.
The SAP notes and SCN both suggested using report CRM_ORDER_DELETE.
From SE38 I ran the report and entered the first transaction ID number (from the maintenance optimizer screen) and “Business Transaction Type” of SLMO:

Deleting SLMO entries

Deleting SLMO entries

I then went back into the Maintenance Optimizer and click Refresh:


It’s gone!  Only one to go:

MOPz Transactions

After removing both old transactions, I went and re-modified the landscape pattern to un-link the Java stack from the ABAP stack (non-SIDECAR).

I then reset the change to the TSOCM_COND_MAPP table and saved it.
I was then able to create a new maintenance transaction and successfully calculate the stack.

The SIDECAR landscape pattern in Solution Manager 7.01 SP24 doesn’t seem to work as it should and causes issues with the Maintenance Optimizer.  For the time being, it might be easier to try and maintain the ABAP and Java stacks independently.