Product Information
DMO: shadow repository on target database for conversion to SAP S/4HANA 1909
Abstract:
SUM creates the shadow repository on the target database for all migration scenarios.
This blog provides background information as well as the current status of this new approach.
Latest News [added on June 10th 2020]
With SUM 2.0 SP 08, the approach “shadow-repository-on-target-database” is used for all migration scenarios, independent on the target release (and independent on target database type). This blog was updated accordingly
Introducing the shadow system and shadow repository
A shadow system basically consists of a shadow instance and a shadow repository:
- The shadow instance is an additional ABAP instance which is created by SUM on the application server on which the SUM was started. It is used to prepare steps executed during the downtime.
- The shadow repository exists on target product version level. This means that the shadow instance must use the target kernel to create the shadow repository with potentially new object types.
The shadow system is already created and exists during uptime processing of SUM. As a consequence, the downtime is reduced.
[i] You can check this blog for an introduction to the shadow system, but this description does not cover the migration case.
Until SUM 2.0 SP 07, SUM created the shadow repository on the source database specifically for the migration scenarios Database Migration Option (DMO), and System Conversion to SAP S/4HANA for source systems with no SAP HANA database. (Note that non-migration scenarios have only one database, so that is no differentiation of source and target database is needed.)
This has changed for a system conversion to SAP S/4HANA 1909 with SUM 2.0 SP 06 (and higher): SUM creates the shadow repository on the target database. (Again: This only applies if the source system is not yet on SAP HANA database and a database migration happens. Only then we have a source and a target database).
The figure illustrates:
- SHD REP: the shadow repository
- PAS: the primary application server
- PRD REP: the current (productive) repository of the source system
SAP S/4HANA 1909 and the ABAP kernel
SAP S/4HANA 1909 uses SAP kernel 7.77. This kernel version works exclusively with SAP HANA as database. As the shadow instance must use the target kernel, it is obvious that the shadow instance for SAP S/4HANA 1909 can’t work with a database other than SAP HANA DB. That is the reason why SUM has to create the shadow repository on the target database for a migration scenario targeting SAP S/4HANA 1909.
Note: SAP Kernel 7.73 as well only supports SAP HANA as database, but it can be used for the shadow repository on source db in the conversion process targeting SAP S/4HANA 1809.
No changes for SUM handling
(There is a new dialog sequence introduced with SUM 2.0 SP 06 – described in this blog – but this is not related to the shadow system.)
Advantages for conversions to S/4HANA 1909
Additional aspects of the story
- The requirement for a system conversion to have the source system on Unicode remains!
- This was announced long ago (see announcement), so SUM 2.0 does not cover the Unicode conversion, and will neither in the future.
- The conversion planning in Maintenance Planner still requires selecting both new kernels, for source and for target database.
- SUM 2.0 SP 06 and SP 07 use the shadow repository on the target database only for a conversion to SAP S/4HANA 1909.
- SUM 2.0 SP 08 and higher uses the same approach now for all migration scenarios
(also for the use of SUM 2.0 SP 08 inside the classical SAP Business Suite, e.g. for the migration of SAP ECC 6.0 from a non-HANA database to EHP 8 on SAP HANA DB).
Boris Rubarth
Product Manager SUM
Thanks Boris !! This is amazing, this cuts down lots of effort during source system preparation in a conversion project. On the other hand, DMO with system move is a restriction gives me a frown face. Can you please share a rationale for this?
Regards,
Prithivi Raj
Hi Prithivi,
up to now, "DMO with system move" had created the shadow repository on the source system landscape. This is no longer possible, as we can't assume to have a connection to the target (SAP HANA) database from the source landscape. The approach is more complex to be switched.
Regards, Boris
Nice read, also for me as a non-basis person.
So far, as an ABPAer, my contact with shadow instances is that during upgrade, there might be some PARDIST_SHD DISTRIBUTION ERRORS, fellow basis-person will let me know,
and I'll AdT into the shadow instance to activate some CDS-views.
Best
Joachim
Hi Joachim,
good part of the story is that connecting to the shadow system does not change. It uses the shadow instance, and their location does not change.
Best, Boris
Thanks Boris. This is great feature indeed! since lots of customers has lesser resource on source system and you know source is going away, no sense to add resources... This is Amazing!! Thank you again , Amit Lal
Thanks Boris,
it reduces the efforts of upgrading source DB. will this help in reducing UT_RUN runtime.
Hello Boris
Thank you for a great blog.
We are thinking of migrating to S4HANA/ Azure/ RHEL
from ECC6.0 EHP6.0/Oracle 11.2/On-premise/RHEL.
Reading youre previous blogs and sap notes, i know that for my above scenario, i need to use DMO with system move option and system update option.
So if from SUM SP06, system move option is not supported (when SP06 is great creating the shadow rep on target), then we dont have choice to go like below??
//Use SUM 2.0 SP05, go to S4HANA 1809 on Azure with system move option and afterwards update to 1909??
Can we use normal DMO when going from onpremise to Azure cloud, so that we can use SUM 2.0 SP06??
Regards
Hi Kotaro,
thanks for your question.
Regards, Boris
Hello Boris,
Thank you so much for an quick and informative reply!
Understood about your reply!
Btw, i heard when i was talking on the SAP expert chat that
from SUM 2.0 SP06, the os of application server of the target system has to be supported for the target SAP release only according to PAM, not also the ap server of source system.
Is it correct?
Hello Kotaro,
sorry, I guess I did not yet understand your scenario.
For a normal DMO scenario, the application server host remains, so there is no difference between AppServer of source and AppServer of target system.
Regards, Boris
Hello Boris,
In case of having HANA 1.0 on source system, will customers continue to have pre-requisite of updating HANA to a compatible DB version of S/4HANA Product (HANA 2.0), ahead of the Conversion Process?
Can you kindly share if SAP is planning also to extend the possibility of having contemplated scenario below, with this new fancy feature?
-> Source-> ECC 6.0 EHPxx running on HANA 1.0 SPS12
-> Target-> S/4 HANA 1909 running on HANA 2.0 SPS4
Kind Regards,
Claudio Quina
Hi Claudio,
thanks for asking - the requirement to start on SAP HANA 2.0 (if source is already on SAP HANA database) remains. The SUM never upgrades the source database software level, and this is true for SAP HANA db as well.
Kind regards,
Boris
Thank you for your always interesting and helpful articles,
I am preparing for a conversion from ECC 607 to S/4HANA 1909, my source DB is ORACLE 12.
From my understanding S/4HANA 1909 is based on ABAP Platform 1909 (SAP_BASIS 7.54), I am reading the note 2798588 - Database Migration Option (DMO) of SUM 2.0 SP06 to understand the prerequisites and found a confusing statement when your target database is HANA:
Oracle version 11.2 or higher if target SAP_BASIS is 750, or if target SAP_BASIS is 7.54 or higher
Oracle version 12 or higher if target SAP_BASIS is 751 or higher and lower than 7.54
Does this mean that my current Oracle version is not supported to run the conversión to S/4HANA 1909?
Thank you in advance for your comments
Hi Jorge,
sorry to say that I do not understand your concern:
Where is the question?
Thanks, Boris
Hello Boris,
Thank you for taking the time to reply. I was confused about the second statement, but I think I was missunderstandig it.
Thank you again!
Hi Boris,
Oracle 11.2 will support ? if the target conversion is S/4HANA 1909.
Thanks
Siva
Hello Boris,
Thanks for the excellent blog and keeping us updated with the latest features.
1. When will the System move option supported, any rough timelines.
2. When can we expect to support 1809 SP02
3. How much downtime we can save, creating shadow system on the target, any rough estimates.
Thanks & Regards,
Deepak Rade
Hello Deepak,
thank you for the feedback.
Concerning your question:
Regards, Boris
Hello Boris
Do you have any GA Date for DMO with System move for S4 1909 ? I have a requirement to move one customer from On Premise ECC to S/4 1909 version.
Mahesh Shetty
Hello Mahesh,
sorry to say that we can't provide a GA date yet. We will announce it as soon as we are confident, but it depends on the outcome of the development and validation tests. My personal hope is that it will be somewhere around mid of 2020 or Q3, but let's see.
Regards, Boris
Thanks Boris
But what options the customer has now when they would like to Migrate to S/4 1909 on SAP HEC.
The customer does not have much downtime and hence both the options seems to be a time consuming. Also the customer wanted to go live in April 2021 and cannot wait until 3rd Quarter for 1909 Support.
Let me know if there are any other best options with your experience.
Mahesh Shetty
Hello Boris,
thanks for your blog and to inform us about last development on SUM/DMO.
I'm in the same scenario of migration of ECC6 Ehp5 to S/4 1909. Without "System move" option it's for me a regression because of old infrastructure Source System.
As the migration should be done 'in-place", our current infrastructure is on OS (Linux RHEL5), DB (Oracle 11.2.0.3) and Kernel (7.22) infrastructure on the source must be compliante and upgraded with a target system before the beginning of the SUM process. It means new project with downtime, non-regression tests, etc before S/4 migration project...
"System move" is really a very good approach to migrate smoothly from old infrastructure system.
Hope this option will come soon because it' becomes an issue for S/4 Migration
thanks a lot,
regards,
Sacha Gosselin
Hello Sacha,
sorry, my answer took a while ... maybe you have already seen my other replies today concerning this topic:
Well, we are working on this option (“DMO with system move” for conversion target S/4HANA 1909) to become available in the future. What I can say is that the next SUM 2.0 SP version is expected in June, with the next Software Logistics Toolset - but disclaimer applies: we can't guarantee this delivery date, and we can't promise that the next SP version will allow this option. (But my strong hope is that it becomes true).
Hello Boris,
many thanks for this very informative overview about the DMO procedure for S/4HANA 1909!
Is there any schedule when the DMO with System Move function will be available?
This is such a useful feature we don't want to miss for our upcoming S/4Conversion.
Thanks and best regards
Anne
Hello Anne,
thank you for the feedback!
Well, we are working on the option ("DMO with system move" for conversion target S/4HANA 1909) to become available in the future. What I can say is that the next SUM 2.0 SP version is expected in June, with the next Software Logistics Toolset - but disclaimer applies: we can't guarantee this delivery date, and we can't promise that the next SP version will allow this option. (But my strong hope is that it becomes true).
Best regards, Boris
Dear Boris，
I am now doing an S/4 HANA 1909 conversion from ECC6.04 on HP-UX IA64 based Oracle 12g Database. The Target S/4HANA 1909 based on Linux platform X_86. SUM SP07.
System tell me that Shadow system is not allowed in the HPUX for S4 HANA version over 1709. I think that the shadow repository will be created in the HANA server. Do you have any idea on it?
Best Regards
Alan Zhu
Dear Alan,
sorry, no idea, hope you meanwhile got help or created an incident.
Best regards, Boris
Hi Alan,
I am performing S/4 Hana Conversion with the same exact setup. Can you please tell how did you approach this situation.
Regards,
Aditya
Hi Borris,
The only place I can seem to find conclusive info on DMO with System Move not being supported for 1909 is with you via this article or answers to other questions in this forum.
I don't see anything concrete listed in the release notes, restrictions or the latest versions of the SUM and DMO guides for SP06 or SP07 - in fact these guides actively talk about DMO with System Move which I think it what is confusing a lot of people. Is it just me, am I missing a reference somewhere?
Happy to post this as a separate question if needed or to log a formal note if needed since I have a customer with the same questions and I'm referring them here which is good since you are the SUM product manager 🙂
Thanks in advance, I find your content very professional and thoughtful.
thanks,
Paul
Hi Paul,
You can find this information in SAP Notes 2798588 - Database Migration Option (DMO) of SUM 2.0 SP06 and 2840346 - Database Migration Option (DMO) of SUM 2.0 SP07
Requirements for Target System and Target Database:
regards,
Sacha G.
Hi Paul,
thanks for asking, and thanks to Sacha for providing the answer.
I take this question as an opportunity to advertise our landing page for SUM: https://support.sap.com/sltoolset
You find a section with up-to-date information on SUM related scenarios with links to respective SAP Notes, guides, blogs, and a link to a dedicated page on SUM with more information.
Regards, Boris
Hi Sacha & Borris,
Yes thank you, I see note 2798588 for SUM SP06 was updated on 27 Jan 2020 to contain the info as you pointed out:
----------------< Update D029945 27/JAN/2020 >--------------------------
... I was using a version of that note just prior to this update which didn't have that info in it so thanks for being on top of it.
As a side note, I see SUM SP07 is now released and the same restriction around DMO with system move exists as described in note 2840346 - just FYI for anyone reading this now:
"DMO with System Move" is currently not supported for targeting SAP S/4HANA 1909
Thanks again Borris for great info and for this community.
Regards,
Paul
Hi Paul,
yes, SUM 2.0 SP 07 is out. Well, I am already eagerly waiting that we have SUM 2.0 SP 08 out. If everything works out well, this may be mid of June (still: not a promise, sigh)
Regards, Boris
Hi,
We are working on a conversion project converting from ECC6 running on Windows and MSSQL in one datacenter to S/4HANA 1909 hosted in a different datacenter. So initially we planned to use SUM DMO with System Move option, but realized from SAP Note "2840346 - Database Migration Option (DMO) of SUM 2.0 SP07" that this was not an option anymore.
As we se it we have two options now.
Do you have any experience creating the shadow system on the target server over a VPN tunnel (WAN link is a VPN tunnel between the two datacenters)
BR
Sveinung
Hi Sveinung,
I have no experience with that scenario, and in the respective SAP Note on DMO you will find that we do not support the approach to use "plain" DMO for a data center move (read the note to see the full text on that).
> ... [DMO with system move] was not an option anymore.
Well, we are working on this option to become available in the future. What I can say is that the next SUM 2.0 SP version is expected in June, with the next Software Logistics Toolset - but disclaimer applies: we can't guarantee this delivery date, and we can't promise that the next SP version will allow this option. (But my strong hope is that it becomes true).
BR, Boris
Hello Boris,
As always, your blogs are very concrete and informative. Thank you for taking your time out to create blogs to make our lives easier and for replying in a timely manner.
I am confused with the DMO with System Move with SUM 2.0 SP07. I just want to know if DMO with System Move is supported as of SUM 2.0 SP7 for target SAP S/4 HANA 1909 as the DMO guide actively talks about this option being supported (only it does not mention target as SAP S/4 HANA 1909).
Would appreciate your answer.
Regards,
Osman
Hi Osman,
thank you for the feedback!
And thanks for asking, I have updated the blog now concerning the restrictions: "DMO with system move" is not supported with SUM 2.0 SP 07 either - hopefully with SUM 2.0 SP 08 then, but we have to wait for the results of the validation tests.
Regards, Boris
Hello Boris,
Am I right that downtime-optimized DMO is supported for moving from ERP based on Oracle to S/4 HANA 1909?
Because note 2840346 - Database Migration Option (DMO) of SUM 2.0 SP07 says:
Note that System conversions to SAP S/4HANA 1909 are currently not supported
When note https://launchpad.support.sap.com/#/notes/2547309 says:
With SUM 2.0 SP 07, the target SAP S/4HANA 1909 is now supported for "downtime-optimized DMO"
I believe doDMO IS supported for conversion from ERP to S/4.
Kind regards,
Anton
Hello Anton,
thanks for asking, and sorry for my first reply, which was wrong. We have now updated the respective SAP Note 2840346.
As you state, “downtime-optimized DMO” is meanwhile supported for a system conversion to SAP S/4HANA, even for target version 1909. Still the questions is whether it is worth the effort: I guess that the migration of selected large application tables (which are not affected by the new data model of S/4HANA) is only a minor portion of the overall downtime. The portion of the FI data migration (executed after SUM is finished) is not reduced by “downtime-optimized DMO”.
Kind regards, Boris
Hi Boris,
With the release of SUM 2.0 SP08, is the DMO with system move for 1909 possible? It’s not specifically called out as not possible as it was in previous central notes but it’s not specifically listed as supported now. Could you clarify if it’s supported now? Thank you!
Regards,
Bryan
HI Bryan,
thanks for asking: yes, <"DMO with system move" for conversion target SAP S/4HANA 1909> is now supported with SUM 2.0 SP 08, since yesterday.
We always list the news on support portal pages:
Regards, Boris
Thank you, sir! That news makes my life much easier.
Hello Boris,
thanks a lot for the update!
regards,
Sacha G.
Hi Boris,
thanks for updating this blog post.
I have read that it is possible to perform an S4HANA Conversion to 1909 with option “DMO with System Move”, as per SUM 2.0 SP08 enhancement.
In the related SAP Note 2882441 – Database Migration Option (DMO) of SUM 2.0 SP08 this is not stated explicitly. It seems that there is no more this constraint just because it's not stated in paragraph “c) “DMO with System Move”: Requirements and Restrictions” as stated in previous DMO version notes.
Have I interpreted well?
Regards,
Giovanni
Hi Giovanni,
correct!
We have removed the restriction from the respective SAP Note (2882441 for SUM 2.0 SP 08) that was existing up to SUM 2.0 SP 07 (SAP Note 2840346) and we have listed this in the news section on http://support.sap.com/sltoolset. Direct link to the current news is https://support.sap.com/en/tools/software-logistics-tools/sltoolset-news_sps281.html
Regards, Boris
Hi Boris,
in the most recent version of the SUM SP08 note:2882441 is mentioned that the system move option is not valid:
"--------------------< D023536 17/AUG/2020 >------------------------------
Do not use System Move option until further notice!
Currently, too few objects are shown in the modification adjustment in transactions SPDD or SPAU. Therefore, do not use DMO with System Move until further notice!
As soon as this issue is fixed, this note will be updated accordingly by removing this entry. "
Can you add any further information on this topic and maybe another option for moving the application server and ASCS from a windows Server to a new linux server within the context of a S/4HANA Conversion?
thanks and kind regards,
Fabian
Hi Boris,
Thanks for updating this post. It was really helpful during the conversion !
Best Regards,
Belhassen
Hi Boris,
thanks again to share informations about last evolution on DMO. I’m little confused with the new “SUM/DMO with system move” and the fact that the Shadow system is now on the target system.
Before the shadow phase was during uptime and was not impacting the business downtime. Now the shadow (and SPDD stop with “double check” because SPDD transport order done on Dév is not fully compliant with the SPDD in next systems) is done during business downtime.
It is impacting production golive cut-over: new stop during the procedure and we need development people during the go-live and it could be lost of time if something go wrong at this phase
I understand that sometimes the OS level on the source system can’t support the shadow (and SUM tool) system but we have the option to run SUM on AAS with good OS prerequisites so I don’t understand why it’s better to move the shadow phase during the downtime instead the uptime which was transparent for business.
I know also SAP best pratices and we have to make dry-runs with production data copy but in real life it’s not always possible. The fact that shadow phase was during uptime was stressless and easier to manage with dev/business teams.
My 2 cents
[UPDATE]
It seems that with "parallel mode" the shadow activities can be start on the target before the end of data export on the source. It's save time for this part
regards,
Sacha
Hi Sacha,
thanks for asking and for pointing this out: with the new SUM approach of creating the shadow repository on target database (for all migration scenarios), for "DMO with system move" it is essential to use the parallel mode. Only with the parallel mode, the shadow operation activities in the target landscape are executed during uptime of the source system.
Regards,
Boris
Hi Boris,
in the provided picture it seems that shadow instace is always created on PAS source host. What about if the scenario is SUM/DMO with system move and parallel data transfer?
In this case, shadow operation will be performed on source or target host? As per SUM conversion guide, it seems on target host, but we are not so sure.
Regards
Hi Alessandro,
thanks for asking. For "DMO with system move", the shadow instance only exists in the target landscape (on the target AppServer host). Shadow operations happen in target landscape, and only for the parallel mode, this is uptime for the source SAP system.
Regards, Boris
Hi Boris
I have doubt for Database migration using Downtime-optimized DMO.
>Downtime optimized DMO option is available in SUM 1.0 SP26 or not because in my scenario target system release in SAP NetWeaver 740 and want to migrate database only. I have read the SUM 1.0 guide and not found Downtime-optimized DMO option.
> So in this scenario can we use DMO 2.0 with target system SAP NetWeaver 740 only for DB Migration.
Regards
zahid hussain
Hi Zahid Hussain / Manoj Dusad,
indeed downtime-optimized DMO is only supported when using SUM 2.0, so not for a target based on 7.40.
Regards, Boris
HI Boris,
Many thanks for keeping us updated on all latest features with SUM DMO. As you know in earlier releases of SUM(be it 1.0 or 2.0<SUM 2.0 SP06, it used to create shadow repository on source db which gets copied to target via pipe mode using parallel R3loads. Same is the case for application data in downtime.
With latest SUM(>=SUM 2.0 sp08), it creates shadow repository on target db avoiding uptime migration. Since we dont have target release kernel for source db, how the application data gets migrated to target hana db? How the connection happens between source db and target db for the transfer of appliaction data?
Regards,
Mohamed Sadiqulla.
Hi Mohamed,
the migration of application data works as before: SUM delivers the R3load as part of the SUM archive, and SUM starts several R3load pairs that work on "buckets" (work packages) using pipe mode, as you already stated.
Regards,
Boris
HI Boris,
Thanks for updating. So you mean SUM delivers whole kernel or just R3loads to copy application data. Other questions include
Regards,
Mohamed Sadiqulla.
Hi Mohamed,
R3load for source and target is part of the SUM archive (not the kernel). I still recommend to select both kernels in Maintenance Planner, although in midterm I can imagine that only the target kernel will be required.
Regards,
Boris
Hi Boris,
Thanks for the info provided here, as always.
Currently we are running an S/4HANA 2020 FPS01 conversion process with the following scenario:
Source system info: ECC 6.0 EHP7 on MS/SQL 2016 on Windows,kernel 753 (Azure subsciption1)
Target system info: S/4HANA 2020 on HANA 2.0 revision 55 on Linux, kernel 781(Azure subsc2)
Info: DMO with System Move from Windows to Linux with parallel export/import procedure
SUM version used: SUM 2.0 SP10 patch 7
While running the shadow instance creation process (target environment), we are facing the following error, which is also described in SAP Note:
RabaxException<ExcKindRbx_CatalogInconsistency> thrown: DDIC object <object_name> inconsistent: 'JSON document in DDNTT~FIELDS_DATA is empty'
https://launchpad.support.sap.com/#/notes/0003067758
Seems that there might be bug in the SUM 2.0 SP10 version which influenced the export of shadow repository to be done with R3load for kernel 7.53 instead of copying R3load for kernel 7.81. Basically SUM is not able to switch automatically the R3* executables from bin_781 to bin, before shadow instance creation, therefore we got in the situation described in the note above (https://launchpad.support.sap.com/#/notes/0003067758). To patch kernel in the source system to 781 upfront I would say is not an option as kernel 781 is not supported with Netweaver 7.4 according to PAM. Note was released last week.
Due to the above, we have decided to reset the process today and start again from the scratch the process by using SUM 2.0 SP11 patch 0, released 2 days ago.
Could you please check internally if the new SUM version (2.0 SP11) will overpass the current issue? Are there any manual steps required?
If needed, please forward the above interpretation to your colleagues.
SAP incident raised: 451892 / 2021
Thanks in advance, Boris!
Radu
Radu,
Resetting in upgrade and migration is definitely troublesome at any stage on SUM.
Just wondering programs such as - /SDF/RC_START_CHECK, didn't capture such misalignments on compatibilities issues esp. on the Kernel side and nametab tables go for a toss. Good Luck with your migration!
Amit
Hi Amit,
Simplification Item Checks are checking consistency on application level, not on kernel level. And I would not agree to your statement that "resetting in ... migration is definitely troublesome at any stage on SUM".
Regards, Boris
Hi Amit,
Thanks! On your questions, for SI report did not provided any hints on kernel mismatch or anything.
Actually the problem came from the fact that SUM while is creating the shadow instance in target is not able to switch automatically from old enqueueserver version ENSA1 (enserver) to new version for SAP ABAP Platforms ENSA2 (enq_server).
The issue got solved by following SAP note:
https://launchpad.support.sap.com/#/notes/2754662
Hopefully in the next version SAP will fix this and issue will dissappear.
Have a good day!
Radu
Hi Radu,
glad to read that your issue was solved meanwhile. Just a comment on your previous posting with error details: SUM has its own R3load version on board.
Regards, Boris
Hi Boris Rubarth ,
Indeed, thanks, it was a communication issue from my side.
Nevertheless it seems that SUM 2.0 SP10 or 11 is still not able to switch enqueue symbolic links from old en_server (ENSA 1.0) to enqserver (ENSA 2.0) automatically while starting shadow instance.
Manual changes are required by adjusting the shadow instance profiles using SAP note: https://launchpad.support.sap.com/#/notes/2754662
Is it something planned to be fixed in the new SUM versions?
Thanks,
Radu
Hi Radu,
patch level 1 for SUM 2.0 SP 11 was released today. It contains the fix.
Regards, Boris
Thanks Boris.
We would consider that while we start the next run.
Thanks again for your prompt feedback.
Radu