SLD Migration and GW - Acl - Mode - SAP Blogs

1/30/2018 SLD Migration and gw/acl_mode | SAP Blogs
Products
Products Industries
Industries Support
Support Training
Training Community
Community Developer
Developer Partner
Partner
About
About
 
Home / Community / Blogs + Actions
SLD Migration and gw/acl_mode

September 9, 2014 | 2,315 Views |
Matt Fraser
more by this author
SAP NetWeaver Enterprise Search

748 | error 748 | gw/acl mode | reginfo | sld | sld migration | sld nuc
share
0 share
0 tweet share
0
Follow
Almost every SAP installation today has one feature in common, and that is
the presence, somewhere in the landscape, of SLD, or System Landscape
Directory. For many, if not most, customers, SLD is integrated with another
necessary component, Solution Manager, on the same system, as this is a
https://blogs.sap.com/2014/09/09/sld-migration-and-gwaclmode/ 1/18
very quick and easy way to get a basic SLD up and running, and the
integration with Solution Manager is practically built-in. Other customers may
have had their first SLD as part of a PI installation, and much of what follows
below may apply in the same manner.
The Problem
Maintenance Downtime Dependencies

If you use Java software components in your productive landscape, such as
pre-WDA ESS or MSS, or your own custom Java WebDynpro developments,
these components depend upon the availability of SLD in order to function.
ABAP systems do not have this dependency; if SLD is down, the periodic
synchronization of system data will fail, but this will go completely unnoticed
by end users, as the system itself and its applications continue to operate just
fine. Java and Portal systems themselves also continue to operate in the
absence of SLD, but the Java WebDynpro software components will fail.
This means that SLD maintenance has a production impact, and so typically
must be scheduled for maintenance windows outside normal business hours.
If your SLD is integrated with Solution Manager, this same restriction therefore
applies to Solution Manager maintenance. Note, depending on which SolMan
scenarios you utilize, you may have this restriction anyway, but if your primary
purpose for SolMan is Maintenance Optimizer and landscape monitoring, then
your Basis team may be quite frustrated by the need for production downtimes
in order to maintain it.
Restriction to Older Release

Solution Manager is currently in release 7.1, but the underlying NetWeaver
release is 7.02. This means that your commingled SLD will be release 7.02.
However, newer releases of SLD, beginning with NetWeaver 7.1, have some
significant enhancements which are simply unavailable to you while SLD is
part of Solution Manager. See How to Get an SAP NetWeaver 7.1 System
Landscape Directory? and How to Ensure that SLD Data is Available during
Maintenance for some reasons why a newer SLD may be advantageous.
Load Balancing and Redundancy

You also may simply want a second, or multiple, SLDs for purposes of
redundancy and load balancing, especially if you have a busy landscape with
many WDJ components.
The Solution
Many customers therefore seek to separate SLD from Solution Manager,
migrating it to its own system, and thus insulating it and your production
landscape from Solution Manager maintenance activities. A number of
documents describe this process, so this isn’t the main focus of the current
post. However, here’s a quick overview of the process, along with links to
more detailed documents for each step:
1. Install new AS Java (currently in release 7.4 SR1)

1. Temporarily register it in existing ‘old’ SLD
2. Update AS Java to latest support package stack
3. Enable SSL, create administrative users
1. Configuring the Use of SSL on the AS Java – Network and
Transport Layer Security – SAP Library
4. Initially configure new SLD
1. Post-Installation Checklist – Configuring, Working with and
Administering System Landscape Directory – SAP Library
2. Configuring System Landscape Directory – AS Java
Configuration – SAP Library
1. This includes the following step, and using it to configure
the “System Landscape Directory” functional unit only
1. Java Functional Unit Configuration – SAP
NetWeaver Library: Function-Oriented View – SAP
Library
5. Migrate content from old SLD to new SLD
1. Demo: The Full Automatic Sync Feature in the SLD of SAP
NetWeaver 7.1
2. SLD and LMDB Topology: Replacing the Source SLD for the
LMDB
3. Once the initial unidirectional content sync is complete, the new
SLD should continue periodically pulling data from the old SLD.
The old SLD, being release 7.02, is not compatible with
bidirectional sync, so this is one-way.
4. The above procedures should also result in your LMDB (part of
Solution Manager) now receiving data exclusively from the new
SLD.
6. Configure data suppliers to sync to new SLD
1. A number of documents describe this process, but here’s a good
one to get you started:
1. Creation of an SLD connection from ABAP backend to
AEX SLD
7. Disable old-to-new SLD content sync
The New Problem

You’ll notice I’ve highlighted step 6 of the solution above. This is because you
will likely run into an unanticipated issue here with your ABAP systems. Your
Java systems, generally, will probably synchronize with the new SLD without
much hiccup, but your ABAP systems, including the ABAP stack of your
Solution Manager system, will encounter RFC gateway errors. The
SAP_SLD_DATA_COLLECT job will record something like the following in the
generated spool file:
Collection of SLD data finish
Data collected successfully
RFC data prepared
Used RFC destination: SLD_UC
RFC call failed: Error when o
So, you’ll check SM59 and the SLD_UC RFC connection will fail a connection
test. You’ll wallow about looking at gateway ports and services, checking RFC
listener statuses, etc (Tom Cenens has a great post about the things to check
that could go wrong at How to push ABAP system data to a Java only SLD).
When you have ensured that everything is configured correctly, that’s when
you realize there is a (mostly) undocumented step in configuring the security
on a gateway in newer NetWeaver releases. There is a small text file which
you must create and populate appropriately, and the documentation on the
need for this is mainly found in SAP Notes (see Notes 1843782: GW:
Installation changes default from gw/acl_mode to 1, 1480644: gw/acl_mode
versus gw/reg_no_conn_info, and especially 1069911: GW: Changes to the
ACL list of the gateway (reginfo)).
What is happening here is that a kernel parameter, gw/acl_mode, which has

existed for a long time, had its default setting changed from 0 to 1 for new
installations of NetWeaver 7.0x and higher since the end of 2012. If your
Solution Manager was installed prior to then, then you had the old behavior.
Your new SLD has the new behavior.
gw/acl_mode
So what does gw/acl_mode = 1 do?
It causes the gateway to reject registrations from external servers by default,

instead of accepting them. This is a security enhancement, and a good thing,
but it means you must do a little more configuration if you want your ABAP
systems to be able to register themselves to your new SLD. You may see
advice in the forums to set this parameter to 0, and that will work, of course,
but it is not the preferred solution. Setting the acl_mode to 0 opens up your
system to potential attack (though this was of course the default setting in the
past).
You probably won’t actually find this parameter in your SLD instance or default
profile, which means it will be at the default setting, i.e. “1.”
With this setting, the system will check for the existence of a reginfo or secinfo
file. However, by default, these files don’t exist unless you create them. In the
absence of explicit instructions coded into these files, the system reverts to the
default behavior of rejecting registrations from all external systems, and thus
your SLD updates from ABAP systems are not occurring.
REGINFO.DAT
The preferred method for allowing external systems of your choosing to
register with the gateway, and thus with SLD, is to create the permissions file.
The default location for the file is \usr\sap\<SID>\SCS<nr>\data, and the
default filename is REGINFO.DAT. You won’t find this file there in a fresh
installation, however, so you must create it yourself.
Note 1069911 (linked above) and Note 1105897 (GW: reginfo and secinfo with
permit and deny ACL) between them give an overview of the ways you can
format the reginfo file, but the bottom line is that you need something like the
following in it:
#VERSION=2
P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*
The file is case-sensitive, so you must user upper-case on the keywords

(VERSION, TP, HOST, etc). Also, the first line must have “#VERSION=2” or
the gateway will register an error on startup in the trace and not parse the rest
of the file.
The following lines (there can definitely be more than one) will start with either
P (Permit) or D (Deny). There are four keywords (TP, HOST, ACCESS, and
CANCEL) to be specified, each with their own list or range.
TP is where you specify the registration ID of the external server program.

Wildcards are allowed. In the case of SLD registrations, the external servers
register using either SLD_UC or SLD_NUC, depending on whether they are
Unicode or Non-Unicode systems. In some scenarios, they might also have a
SID listed as part of the registration or program ID, but it will always begin with
SLD_. Therefore, “SLD_*” works as a pattern to ensure the registrations are
only SLD-related.
HOST is where you can specify host or domain names, or IP addresses or

subnets, that are either permitted or denied. You could use
“*.yourdomain.com” to allow all hosts within “yourdomain.com” to register, or
you could use an IP subnet, such as 10.x.x.*, if all your SAP servers are on
this same subnet. You can create comma-separated lists as well, but do not
use spaces between the items in the list, only a comma. There are other ways
to get more complex about using the HOSTS keyword, and I recommend
checking Note 1069911 (linked above) for more details.
ACCESS is very similar to HOST. The difference is that HOST specifies the
servers that are allowed to log on, whereas ACCESS specifies the servers
allowed to use the registered server. It’s a very specific difference, and in most
cases you will probably have exactly the same list for HOST and ACCESS.
Again, see the Note for details.
CANCEL is the list of servers allowed to log off. Again, you will probably have
the same list for CANCEL as you do for HOST and ACCESS.
For all three, HOST, ACCESS, and CANCEL, the local system is always
included (permitted), so you don’t need to specify it explicitly. You only need to
specify external systems.
So, if all of your SAP systems are on the subnet 10.50.15.x, as an example,
then your REGINFO.DAT file will probably look like this:
#VERSION=2
P TP=SLD_* HOST=10.50.15.* ACCESS=10.50.15.*

CANCEL=10.50.15.*
If you need something more complex, I strongly recommend perusing Notes

1069911 and 1105897 carefully.
Conclusion
After creating your REGINFO.DAT file, there is no need to completely restart

the J2EE instance. It is enough to restart the gwrd process of your SCS
instance. If everything is formatted correctly, the trace file for gwrd (dev_rd in
the SCS work folder) will show this one line during startup:
GwIRegInitRegInfo: reginfo version = 2
In the work folder, the gw_log file (with datestamp) will have a set of lines
similar to:
(re)load reginfo file X:\usr\sap\<SID>\SCS<nr>\data\reginfo.DAT,

version=2 (2 entries)
P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*
And, of course, the RFC connection will now test successfully and
registrations will succeed.
More Information
For an overview of best practices, how-tos, and planning guides related to
SLD, I recommend visiting and bookmarking More on System Landscape
Directory, maintained by Wolf Hengevoss. Most of the documentation
available for SLD is linked from this highly informative page.
Alert Moderator
19 Comments
You must be Logged on to comment or reply to a post.
Andy Silvey
September 11, 2014 at 1:35 pm
Hi Matt,
excellent blog and explanations and advice, what about the SAP recommendation of
using PI as the SLD.
This is a common standard.
Best regards,
Andy.
Matt Fraser Post author
Hi Andy, and thanks for the compliment (means a lot coming from you).
We don’t actually have PI at my shop — I know, I know, you wonder how

we can possibly integrate anything, but then, we don’t have BW either —
we’re backwards in some ways, I guess. However, I recognize that many
customers probably got their first exposure to SLD when they implemented
PI, just as many others (like us) got it when they implemented Solution
Manager.
As every customer must have Solution Manager, but Solution Manager

doesn’t yet allow for running an SLD on NetWeaver 7.1 or higher and
therefore isn’t compatible with full bidirectional synchronization, then the
SLD integrated with PI is likely a better choice to be the central SLD for
landscape management. You’re still not precluded from using a completely
standalone SLD, and Wolf Hengevoss recommends this approach (SLD
Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?),
especially for larger or more complex landscapes, but either way, a
customer facing a scenario of redirecting their landscape systems from
Solution Manager to another SLD, whether in PI or standalone, will likely
face the same issues I raised here. The same solution I raised here should
work for the PI scenario as well.
Very good question, thanks for bringing it up.
Regards,
Matt
Andy Silvey
September 12, 2014 at 9:22 am
Hi Matt,
something to take into consideration when choosing where to

host SLD is,
if it is not planned to give the SLD its own dedicated instance,

then which system to install the SLD on ?
SLD is one of the components in the SAP Landscape which

needs to have the highest uptime and availability, because for
example, no SLD and Java WebDynPro’s in the SAP Portal or
CE will not work. Then there’s NWDI, which won’t work etc.
That’s why, in the SAP Master Guides it is recommended that

if the SLD is not going to have a dedicated Instance then PI is
a good system to host the SLD on, as PI also needs very high
uptime.
If you haven’t got PI, then when choosing which SAP system
to host the SLD on, I would advise pick the SAP system which
has the least chance/expectation/reason/behaviour of going
down – the SLD needs to be up all the time.
Best regards,
Andy.
Yes, very good decision criteria. In our case, we

just made the decision to separate SLD from
Solution Manager, where it had lived for the past
eight years, and give it is own dedicated server.
My effort to redirect our systems from the old to
the new SLD, and this small issue I encountered,
is what inspired this blog post.
Reduction of downtime for SLD was the primary

driver for this move, as Solution Manager seems
to need a fair amount of maintenance, and that
maintenance tends to take a number of hours.

SLD-specific maintenance, on the other hand,
tends to be fairly quick, so by separating the
components we achieve a reduced percentage of
planned downtime for our Java Webdynpro
applications.
Andy Silvey
something funny, thinking about

reduction of downtime of the SLD,
back in the day, let’s say, back in
2006, updating the CIM Content
used to take a number hours,
sometimes 5 or 6, these days the
same action takes a number of
minutes !
Andy.
Yes, you’re right, it is much faster

now! I recall something in the
release notes once, with one of the
updates, stating that it would itself be
a long-running update, but would
improve runtimes for future updates,
so that one must have restructured
things.
Muniyappan Marasamy
October 2, 2015 at 3:57 pm
recently we did the activity of separating slds.
initially all nod prod and prod systems were

pointing to DEV PI SLD. so if DEV PI is down, all
portal applications stop working.
then we configured PI prod sld and made all prod

systems point to PI prod sld. still portal
applications have dependency on PI Prod server.
first time i hearing ,having separating instance for

SLD. this seems great as SLD will be always up
and running.
i have one doubt. separate instance means,

having separate sever and creating instance? or
is it another instance in PI’s server. Please correct
me if my question is wrong.
Regards,
Muni
Hi Muni,
In my landscape, I put the SLD on a

separate server. However, it should
be entirely feasible to install this as a
separate instance co-located with a
prior SAP instance. Be aware,
though, that this will mean SLD
downtime whenever you do
maintenance on the server
hardware, the operating system, or
the database, so it may nullify some
of the benefit of separating SLD out.
Still, though, it will reduce the
frequency of that downtime, and it
will allow you to run SLD at the latest
and greatest NetWeaver release.
Cheers,
Matt
Muniyappan Marasamy
October 6, 2015 at 7:28 am
Thank you Matt
Isaias Freitas
March 24, 2015 at 1:51 pm
Hello Matt,
I believe that setting CANCEL, HOST and ACCESS to the same value is not ideal from a
security perspective. Maybe some servers are allowed to ACCESS the registered
program, but should not be allowed to CANCEL it.
And HOST should be a list of servers that are allowed to register the specific program
defined by TP.
You can take a look at Gateway Access Control Lists – Security and Identity
Management – SCN Wiki. I hope it helps .
Regards,
Isaías
March 24, 2015 at 7:00 pm
Hi Isaias,
Thanks for the link to the wiki. I never found that when I was trying to figure
out why my stuff wouldn’t work (which is what prompted me to write this
blog at the time). That is significantly more detail about how the ACLs work
than I was able to find. I was basing my information primarily on the

recommendations in Note 1069911.
However, I am a bit confused, and I hope you can enlighten me. Both your
wiki and Note 1069911 imply that CANCEL should in fact include the
servers that make up your SAP system or landscape, which is what I was
trying to illustrate (perhaps I was not clear enough that I meant an internal,
controlled list of IP addresses that represent the data center or the SAP
systems). Also, the Note says that CANCEL details which systems are
allowed to logoff from the gateway (which seems desirable), but your wiki is
less clear, implying that this allows the remote host to cancel the gateway’s
registration (which I agree would not normally be something we would do
for a server-server interface, unless it was just meant to be a one-time
interaction).
Cheers,
Matt
Isaias Freitas
March 24, 2015 at 8:35 pm
Hello Matt,
When filling up the CANCEL option you should ask “which

servers can cancel this registration?” (or logoff the program, as
you call it).
You should allow at least both involved systems (SLD and the
SAP system where the SLD programs are registered) to
cancel the registration.
The reason is that if you stop the SLD system, for example, to
do some maintenance task, the SLD must be able to cancel its
registration in a “nice way”, so the SAP system is “aware” that
the SLD is not available.
The same applies if you need to stop the SAP system. It must
be able to cancel the SLD registration, so SAP can stop
“nicely”.
Thus, a good starting point for CANCEL would be “internal,

<everything in HOST>”.
– “internal” is a keyword that means “all instances of this SAP

system”. It will not include remote SAP systems;
– “everything in HOST” because HOST is the option where

you define which servers can register the program defined at
TP.
An example of rule for the SLD would be:
P TP=SLD_UC HOST=<SLD server> ACCESS=internal,

<additional servers>
CANCEL=internal,<SLD server>
This allows the program “SLD_UC” to be registered from

“<SLD server>”.
Only this SAP system (“internal”) and “<SLD server>” can

cancel the registration.
All servers from this SAP system (“internal”) and any

“<additional servers>” can communicate with the SLD_UC.
I hope this clarifies more things than it complicates .
Let me know if something is still unclear .
Cheers,
Isaías
March 24, 2015 at 8:46 pm
Ok, that makes a lot more sense, thanks. But,

aren’t all of the systems in our SAP landscape
registering with the SLD_UC destination? Or
SLD_NUC in some cases. Or are you saying only
the SLD server needs to register this program, so
only the SLD server needs to cancel the
registration, whereas the other SAP systems are
merely users of the registration and only need to
be in the ACCESS list?
Isaias Freitas
March 24, 2015 at 9:02 pm
Hello Matt,
That is correct. The SLD system will

register the SLD_UC / SLD_NUC
programs at one SAP system only.
All other SAP systems would be just

using that same registration and,
therefore, should be added only to
the ACCESS list.
Cheers!
March 24, 2015 at 9:08 pm
I really appreciate this clarification.

I’ll update the blog itself shortly to
reflect this.
Gustavo Mac
Hi Matt,
Thanks for your post it’s really useful.
I’m configuring SLD in a standalone instance and you mention that basically the
following steps must be made:
4. Initially configure new SLD
1. Post-Installation Checklist – Configuring, Working with and Administering System Landscape

Directory – SAP Library
2. Configuring System Landscape Directory – AS Java Configuration – SAP Library
1. This includes the following step, and using it to configure the “System Landscape
Directory” functional unit only
1. Java Functional Unit Configuration – SAP NetWeaver Library: Function-Oriented

View – SAP Library
I have done step 4.1 and im fine but when I go to the 4.2 Java Functional Unit
Configuration I’m having issues with the roles that are assigned to the user but when i go
to the UME in the sld there are no basic roles like user admin to be assigned to my
current user, and so on with the rest of the functional units i select, and i wonder:
a. Which Java functional units must be configured?
b. What is the purpose of doing this configuration, is there an specific reason why we
should do this, if so what’s the reason?
c. Can we live without configuring the Java functional units?
d. Am i missing something in the installation of the Java AS for the SLD? If so what do i
need to do to get the basic roles in the sld ume?
Thanks
Hi Gustavo,
When you install the AS Java, there is a part where you can select a
functional unit to activate (i.e., ADS, Java Extensions, or, obviously, SLD).
However, it has been my experience that this doesn’t usually do the trick,
and after the install (and update) is complete, you usually have to go back
manually and activate the functional unit, by navigating to
http(s)://host:port/sld/fun.
The only functional unit you need to activate is System Landscape

Directory. Scroll down the list to this one, and choose Enable Automatically.
At this point, a wizard launches which proceeds through a bunch of steps to
ensure that the SLD functionality is properly activated in your AS Java. If
other functional units are required as prerequisites to SLD, this process will
activate those as well without you having to manually choose them (I don’t
think there are any others required, though). It is possible to do all this
configuration manually, but generally speaking this is going to be much
more efficient.
Can you live without it? Maybe. But it’s probably better to fix any problems
so that this process can complete successfully. I think this wizard will setup
the SLD-specific roles for you.
So, before running it, you need to make sure your user account is in the
Administrators group, or use the built-in Administrator user to run the
wizard. My guess is that perhaps you ran it with a user lacking the full
authorization to perform the activities.
Double-check that your basic AS Java installation and configuration is

correct. You might have a look at NetWeaver 7.4 SR2 Java Basic
Configuration to make sure you didn’t miss anything here (this document is
not specific to SLD installations, but generic for AS Java as a whole).
Cheers,
Matt
Jill Diesman
Hi Matt,
Thanks for the excellent blog — it’s very helpful.
In the case of a stand-alone Gateway Instance, does the REGINFO.DAT file go in

/usr/sap/<SID>/G<nr>/data?
Best regards,
Jill
Isaias Freitas
Hello Jill,
Yes, that is the default path of the reginfo file.
Notice that on UNIX/Linux servers, the filename is “reginfo” only (with no

extension).
Only at Windows servers that the filename is “reginfo.dat”.
You can change the path/name of the file by setting the parameter
“gw/reg_info”.
Best regards,
Isaías
Share & Follow

Privacy Terms of Use Legal Disclosure Copyright Trademark Sitemap Newsletter

SLD Migration and GW - Acl - Mode - SAP Blogs

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SLD Migration and GW - Acl - Mode - SAP Blogs

Hochgeladen von

Copyright:

Verfügbare Formate

1/30/2018 SLD Migration and gw/acl_mode | SAP Blogs

SLD Migration and gw/acl_mode

SAP NetWeaver Enterprise Search

Maintenance Downtime Dependencies

Restriction to Older Release

Load Balancing and Redundancy

1. Install new AS Java (currently in release 7.4 SR1)

The New Problem

Collection of SLD data finish

Data collected successfully

RFC data prepared

Used RFC destination: SLD_UC

RFC call failed: Error when o

What is happening here is that a kernel parameter, gw/acl_mode, which has

It causes the gateway to reject registrations from external servers by default,

P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*

The file is case-sensitive, so you must user upper-case on the keywords

TP is where you specify the registration ID of the external server program.

HOST is where you can specify host or domain names, or IP addresses or

P TP=SLD_* HOST=10.50.15.* ACCESS=10.50.15.*

If you need something more complex, I strongly recommend perusing Notes

After creating your REGINFO.DAT file, there is no need to completely restart

GwIRegInitRegInfo: reginfo version = 2

(re)load reginfo file X:\usr\sap\<SID>\SCS<nr>\data\reginfo.DAT,

P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*

September 11, 2014 at 1:35 pm

This is a common standard.

Matt Fraser Post author

September 11, 2014 at 4:50 pm

We don’t actually have PI at my shop — I know, I know, you wonder how

As every customer must have Solution Manager, but Solution Manager

Very good question, thanks for bringing it up.

September 12, 2014 at 9:22 am

something to take into consideration when choosing where to

if it is not planned to give the SLD its own dedicated instance,

SLD is one of the components in the SAP Landscape which

That’s why, in the SAP Master Guides it is recommended that

Matt Fraser Post author

September 12, 2014 at 3:55 pm

Yes, very good decision criteria. In our case, we

Reduction of downtime for SLD was the primary

maintenance tends to take a number of hours.

September 17, 2014 at 8:22 am

something funny, thinking about

Matt Fraser Post author

September 17, 2014 at 3:21 pm

Yes, you’re right, it is much faster

October 2, 2015 at 3:57 pm

recently we did the activity of separating slds.

initially all nod prod and prod systems were

then we configured PI prod sld and made all prod

first time i hearing ,having separating instance for

i have one doubt. separate instance means,

Matt Fraser Post author

October 5, 2015 at 6:53 pm

In my landscape, I put the SLD on a

October 6, 2015 at 7:28 am

Thank you Matt

March 24, 2015 at 1:51 pm

Matt Fraser Post author

March 24, 2015 at 7:00 pm

than I was able to find. I was basing my information primarily on the

March 24, 2015 at 8:35 pm