Restore SQL 2.2.1 Database To Another Server Automatically
Hi We have recently installed 2.2.1 for SQL version 7 databases and all looks fine, our TSM server is 4.2.1.9 running on Z/os 1.3 mainframe. For our DR testing, there are a small number of databases which i have been told would need to be made available to users asap, i.e. even before our mainframe is restored where i could begin TSM restores. We have an big SQL 7 Sever at our DR site which justs sits there waiting for a DR situation, when the data would be restored to it. I was wondering if it was possible to backup the SQL databases as normal (full/differential), then restore them automatically (TSM command schedule?) to the offsite server daily, therefore ensuring that the offsite server is always up to date. I know that to restore to a different server, the offsite server must logon to the TSM server as the same node name that backed up the data and therefore the remote server dsm.opt would have the original server's node name. I could manually remotely connect to the server and kick off the GUI and do the restore, but i would prefer to automate this procedure. Is there a way to automate this? Jeff White Senior Systems Programmer CIS Manchester UK * This e-mail may contain confidential information or be privileged. It is intended to be read and used only by the named recipient(s). If you are not the intended recipient(s) please notify us immediately so that we can make arrangements for its return: you should not disclose the contents of this e-mail to any other person, or take any copies. Unless stated otherwise by an authorised individual, nothing contained in this e-mail is intended to create binding legal obligations between us and opinions expressed are those of the individual author. The CIS marketing group, which is regulated for Investment Business by the Personal Investment Authority, includes: Co-operative Insurance Society Limited Registered in England number 3615R - for life assurance and pensions CIS Unit Managers Limited Registered in England and Wales number 2369965 (also regulated by IMRO) - for unit trusts and PEPs CIS Policyholder Services Limited Registered in England and Wales number 3390839 - for ISAs and investment products bearing the CIS name Registered offices: Miller Street, Manchester M60 0AL Telephone 0161-832-8686 Internet http://www.cis.co.uk E-mail [EMAIL PROTECTED] CIS Deposit and Instant Access Savings Accounts are held with The Co-operative Bank p.l.c., registered in England and Wales number 990937, P.O. Box 101, 1 Balloon Street, Manchester M60 4EP, and administered by CIS Policyholder Services Limited as agent of the Bank. CIS is a member of the General Insurance Standards Council CIS the CIS logo (R) Co-operative Insurance Society Limited
Re: SQL 2.2.1
Mehdi, This sounds more like the backups are not running at all when called from the server scheduler. I would look into that more closely, i.e. examine the TDP for SQL log for that time period to find out if it is even being executed. As far as TDP for SQL is concerned, it makes no difference how it is called... if the backups complete, then it will update the filespace information unless there is a communications problem. If you can't solve it, please call support. Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement. = What I have found since my previous email is this. If I run my SQLFULL.CMD from the ClientThe information is updated...But if the server schedule calls up the command this information is not updated.
Re: sql 2.2.1
Thanks.. I will try that. Can you possibly email me an example of your DSM.OPT for SQL. Mehdi Amini LAN/WAN Engineer ValueOptions 12369 Sunrise Valley Drive Suite C Reston, VA 20191 Phone: 703-390-6855 Fax: 703-390-2581 -Original Message- From: Edgardo Moso [mailto:edgardo_moso;KINDREDHEALTHCARE.COM] Sent: Thursday, November 14, 2002 7:54 AM To: [EMAIL PROTECTED] Subject: Re: sql 2.2.1 Mehdi, I am just curious of on error. I have a lot of TDP installed and I'm not getting this kind of error. Can you please try this sqlfull.cmd? rem rem This is the default SQLTEST.CMD file for TDP2.2 - created 7/19/01 rem this backs pubs to adsm rem @ECHO OFF set sql_dir=C:\adsm\TDPSql C: cd %sql_dir% rem == rem 2 lines below put a date and time stamp in a log file for you. rem == date NUL %sql_dir%\sqlsched.log time NUL %sql_dir%\sqlsched.log %sql_dir%\tdpsqlc backup pubs full /tsmoptfile=%sql_dir% \adsm\tdpsql\dsm.opt /sqlserver=sqlserver_instance /logfile=%sql_dir% \sqlfull.log %sql_dir%\sqlsched.log This will backup the pubs dB and save an output to log sqlfull.log and another log sqlsched.log. You can create a test schedule and call this sqltest.cmd as an object. If this the backup is successfull you can see sqlfull.log that looks like this: 07/24/2002 16:39:16 Request : FULL BACKUP 07/24/2002 16:39:16 Database Input List : pubs 07/24/2002 16:39:16 Group Input List : - 07/24/2002 16:39:16 File Input List : - 07/24/2002 16:39:16 Number of Buffers : 3 07/24/2002 16:39:16 Buffer Size : 1024 07/24/2002 16:39:16 Number of SQL Buffers : 0 07/24/2002 16:39:16 SQL Buffer Size : 1024 07/24/2002 16:39:16 Number of Stripes specified : 1 07/24/2002 16:39:16 Estimate : - 07/24/2002 16:39:16 Truncate Log? : - 07/24/2002 16:39:16 Wait for Tape Mounts? : Yes 07/24/2002 16:39:16 TSM Options File : C:\adsm\TDPSql\dsm.opt 07/24/2002 16:39:16 TSM Nodename Override : - 07/24/2002 16:39:16 Sqlserver : VC0699NTW1 07/24/2002 16:39:16 07/24/2002 16:39:21 Total SQL backups selected: 1 07/24/2002 16:39:21 Total SQL backups attempted: 1 07/24/2002 16:39:21 Total SQL backups completed: 1 07/24/2002 16:39:21 Total SQL backups excluded: 0 07/24/2002 16:39:21 Total SQL backups inactivated:0 07/24/2002 16:39:21 Throughput rate: 578.89 Kb/Sec 07/24/2002 16:39:21 Total bytes transferred: 1,786,640 07/24/2002 16:39:21 Elapsed processing time: 3.01 Secs Hope this will help. Edgardo Moso Sr. System Programmer ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by email, delete and destroy this message and its attachments. **
Re: sql 2.2.1
Below is my dsm.opt file. You must specify the tcpclientaddress when you used the service scheduler, otherwise it won't work.So you can change the nodename, tcpserveraddress, tcpclientaddress,tcpclientport, and the mgt class. For tcpclientaddress you may use the tcp/ip address or the hostname. DSM.opt *== * DSM.OPT file for TDP 2.2 *Tivoli Data Protection for Microsoft SQL Server * * *== NODename vc3000hc_SQL2 CLUSTERnode no COMPRESSIon no PASSWORDAccessGenerate *==* * TCP/IP * *== COMMMethodTCPip TCPPort 1500 TCPServeraddress adsm12gb TCPWindowsize 63 TCPBuffSize 32 *== * - Scheduling Options * The default scheduling mode is the client polling method. * To use server prompted scheduling, you must be sure to use a tcp * client port different than the one used by the regular backup * client. *== *SCHEDMODE Polling schedlogname c:\adsm\tdpsql\tdpsql.log errorlogname c:\adsm\tdpsql\tdpsql.error SCHEDLOGRetention 7,d errorlogretention 14,d SCHEDMODE Prompted TCPCLIENTADDRESS vc3000hc TCPCLIENTPORT 1502 *== * Include/Exclude Processing * For a more complete description of include/exclude processing see * the Tivoli Data Protection for Microsoft SQL Server Installation and * User's Guide (Chapter 3 and Appendix B) *== INCLUDE *MC100 *==* * The following include statements assign all meta objects to * management class SqlDbMetaMgmtClass and all data objects to * SqlDbDataMgmtClass * *== *INCLUDE \...\meta\...\* SqlDbMetaMgmtClass *INCLUDE \...\data\...\* SqlDbDataMgmtClass *==* * The following include statements assign all log meta objects to * management class SqlLogMetaMgmtClass and all log data objects to * SqlLogDataMgmtClass * *== *INCLUDE \...\meta\...\log* SqlLogMetaMgmtClass *INCLUDE \...\data\...\log* SqlLogDataMgmtClass *==* * The following exclude statements exclude all log backups for * databases master and msdb* *== *EXCLUDE \...\master\...\log* *EXCLUDE \...\msdb\...\log*
SQL 2.2.1
Can someone email me a good example of DSM.OPT, SQLFULL.CMD for SQL 2.2.1 as well as the batch file they use to start SQL Scheduler Service. I do run my SQLFULL.CMD successfully and the log shows me Number of bites sent but TSM Server does not update its FileSpace information. Thanks Mehdi Amini LAN/WAN Engineer ValueOptions 12369 Sunrise Valley Drive Suite C Reston, VA 20191 Phone: 703-390-6855 Fax: 703-xxx- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by email, delete and destroy this message and its attachments. **
Re: SQL 2.2.1
Mehdi, What filespace information are you referring to? DP for SQL will not update: Capacity (MB) Pct Util because it is ambiguous in the context of DP for SQL. Remember, those numbers correlate back to a volume capacity and how much of it is utilized. but DP for SQL will update: Node Name Filespace Name FSID Platform Filespace Type Last Backup Start Date/Time Last Backup Completion Date/Time Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement. Can someone email me a good example of DSM.OPT, SQLFULL.CMD for SQL 2.2.1 as well as the batch file they use to start SQL Scheduler Service. I do run my SQLFULL.CMD successfully and the log shows me Number of bites sent but TSM Server does not update its FileSpace information.
Re: SQL 2.2.1
It does not update Last Backup Start Date/Time Last Backup Completion Date/Time Mehdi Amini LAN/WAN Engineer ValueOptions 12369 Sunrise Valley Drive Suite C Reston, VA 20191 Phone: 703-390-6855 Fax: 703-xxx- -Original Message- From: Del Hoobler [mailto:hoobler;US.IBM.COM] Sent: Wednesday, November 13, 2002 9:28 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Mehdi, What filespace information are you referring to? DP for SQL will not update: Capacity (MB) Pct Util because it is ambiguous in the context of DP for SQL. Remember, those numbers correlate back to a volume capacity and how much of it is utilized. but DP for SQL will update: Node Name Filespace Name FSID Platform Filespace Type Last Backup Start Date/Time Last Backup Completion Date/Time Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement. Can someone email me a good example of DSM.OPT, SQLFULL.CMD for SQL 2.2.1 as well as the batch file they use to start SQL Scheduler Service. I do run my SQLFULL.CMD successfully and the log shows me Number of bites sent but TSM Server does not update its FileSpace information. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by email, delete and destroy this message and its attachments. **
Re: SQL 2.2.1
Del, The filespace information only shows be the backup start/end for the INSTANCE. I could go in an backup a single database and the filespace information will change? It doesn't tell me that there is a database in an instance that hasn't backed up in xx-days, like I could get that information from B/A client filespaces. I believe Mr. Lindsay Morris says that ServerGraph uses the filespace information to list filespaces that haven't been backed up in x-days, or even last night. He uses this information instead of the client completion or event records for successfully backups. Take DB2 for example...there is a filespace for each database backed up. Now the backup start/end times aren't maintained, but if they were this type of information would be of more benefit in tracking backups, cleanup,... Now I love the strides taken in the TDP agent reporting, but there are still some things I would like to see. Makes central monitoring a bit easier... Bill Boyer DSS, Inc. There are 10 kinds of people in the world those who understand binary and those who don't. - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L;VM.MARIST.EDU]On Behalf Of Del Hoobler Sent: Wednesday, November 13, 2002 9:28 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Mehdi, What filespace information are you referring to? DP for SQL will not update: Capacity (MB) Pct Util because it is ambiguous in the context of DP for SQL. Remember, those numbers correlate back to a volume capacity and how much of it is utilized. but DP for SQL will update: Node Name Filespace Name FSID Platform Filespace Type Last Backup Start Date/Time Last Backup Completion Date/Time Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement. Can someone email me a good example of DSM.OPT, SQLFULL.CMD for SQL 2.2.1 as well as the batch file they use to start SQL Scheduler Service. I do run my SQLFULL.CMD successfully and the log shows me Number of bites sent but TSM Server does not update its FileSpace information.
Re: SQL 2.2.1
Bill's right (as usual). The lack of backup start-end times on individual filespaces is pretty crucial. The way I'd like to see reporting of databases (if I were king) would be similar to client nodes: a client node has filespaces a database has tablespaces both of those things have (in concept at least) - a last-backup end time - a size in GB - a percent-full reading Presently, TDP for XXX agents don't tell you this at the filespace level. But there's a fairly easy way around it (OK, the below MIGHT be construed as advertising - be warned and hang up now if you're offended) sure seems like a problem-solver to me though... But there's a fairly easy way around it, if you're using Servergraph anyway: -- run a daily SQL script on the database clients, to generate a table like this: databasenametablespacename sizepercent-full backup-end(maybe) You can probably get the backup-end date by scanning the TDP client logs. -- use sgdwrite to pump that into the Servergraph database over the network. (We'll be glad to do this if somebody will write the Oracle/Informix/etc SQL.) Now Servergraph will treat the database and its tablespaces as just another client node with filespaces, and use the same logic as for client nodes to determine whether the DB was currently backed up. A great incidental benefit: since we keep trending history on all measurements, the percent-full reading will generate predictions and/or alerts on when each individual tablespace INSIDE the database will fill up! Your DBA's ought to love that. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L;VM.MARIST.EDU]On Behalf Of Bill Boyer Sent: Wednesday, November 13, 2002 10:13 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Del, The filespace information only shows be the backup start/end for the INSTANCE. I could go in an backup a single database and the filespace information will change? It doesn't tell me that there is a database in an instance that hasn't backed up in xx-days, like I could get that information from B/A client filespaces. I believe Mr. Lindsay Morris says that ServerGraph uses the filespace information to list filespaces that haven't been backed up in x-days, or even last night. He uses this information instead of the client completion or event records for successfully backups. Take DB2 for example...there is a filespace for each database backed up. Now the backup start/end times aren't maintained, but if they were this type of information would be of more benefit in tracking backups, cleanup,... Now I love the strides taken in the TDP agent reporting, but there are still some things I would like to see. Makes central monitoring a bit easier... Bill Boyer DSS, Inc. There are 10 kinds of people in the world those who understand binary and those who don't. - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L;VM.MARIST.EDU]On Behalf Of Del Hoobler Sent: Wednesday, November 13, 2002 9:28 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Mehdi, What filespace information are you referring to? DP for SQL will not update: Capacity (MB) Pct Util because it is ambiguous in the context of DP for SQL. Remember, those numbers correlate back to a volume capacity and how much of it is utilized. but DP for SQL will update: Node Name Filespace Name FSID Platform Filespace Type Last Backup Start Date/Time Last Backup Completion Date/Time Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement. Can someone email me a good example of DSM.OPT, SQLFULL.CMD for SQL 2.2.1 as well as the batch file they use to start SQL Scheduler Service. I do run my SQLFULL.CMD successfully and the log shows me Number of bites sent but TSM Server does not update its FileSpace information.
Re: SQL 2.2.1
All points are good ones. The design of TDP for SQL 2.2.1 was done in such a way to help performance and take advantage of the ability of SQL Server backups to stripe backups (up to 64 stripes on SQL 2000 backups) As a result, TDP for SQL does not create a single filespace for every single unique database. As you could see, with the ability of striping, this could create so many filespaces that it would be unmanageable. So, how do you monitor backups? Lindsay Morris discusses a way. Also, keep in mind that TDP for SQL does TSM Server logging for each and every database that was backed up (or failed to backup.) TDP for SQL also creates a single message at the end of each backup instance giving complete summary statistics for all databases. And so, you could examine the TSM Server activity log to find out the status that you are looking for. That is how it works... and you are right, you can't just do a QUERY FILESPACE to find out if all of your database where backed up... you need to issue other queries (QUERY ACTLOG) to get the information you are looking for. Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement.
Re: SQL 2.2.1
What I have found since my previous email is this. If I run my SQLFULL.CMD from the ClientThe information is updated...But if the server schedule calls up the command this information is not updated. Any idea? Mehdi Amini LAN/WAN Engineer ValueOptions 12369 Sunrise Valley Drive Suite C Reston, VA 20191 Phone: 703-390-6855 Fax: 703-xxx- -Original Message- From: Del Hoobler [mailto:hoobler;US.IBM.COM] Sent: Wednesday, November 13, 2002 10:38 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Mehdi, I suggest calling support since it should be working. It works when I back up my SQL 2000 server using TDP for SQL 2.2.1 to a TSDM 5.1.0 TSM server. BEFORE == Node Name: HOOBIE_SQL Filespace Name: HOOBIE\meta\ Hexadecimal Filespace Name: FSID: 55 Platform: TDP MSSQLV2 NT Filespace Type: API:SqlData Is Filespace Unicode?: No Capacity (MB): 0.0 Pct Util: 0.0 Last Backup Start Date/Time: 11/04/2002 16:17:53 Days Since Last Backup Started: 9 Last Backup Completion Date/Time: 11/04/2002 16:18:50 Days Since Last Backup Completed: 9 Last Full NAS Image Backup Completion Date/Time: Days Since Last Full NAS Image Backup Completed: Node Name: HOOBIE_SQL Filespace Name: HOOBIE\data\0001 Hexadecimal Filespace Name: FSID: 56 Platform: TDP MSSQLV2 NT Filespace Type: API:SqlData Is Filespace Unicode?: No Capacity (MB): 0.0 Pct Util: 0.0 Last Backup Start Date/Time: 11/04/2002 16:17:53 Days Since Last Backup Started: 9 Last Backup Completion Date/Time: 11/04/2002 16:18:50 Days Since Last Backup Completed: 9 Last Full NAS Image Backup Completion Date/Time: Days Since Last Full NAS Image Backup Completed: AFTER = Node Name: HOOBIE_SQL Filespace Name: HOOBIE\meta\ Hexadecimal Filespace Name: FSID: 55 Platform: TDP MSSQLV2 NT Filespace Type: API:SqlData Is Filespace Unicode?: No Capacity (MB): 0.0 Pct Util: 0.0 Last Backup Start Date/Time: 11/13/2002 10:34:32 Days Since Last Backup Started: 1 Last Backup Completion Date/Time: 11/13/2002 10:35:29 Days Since Last Backup Completed: 1 Last Full NAS Image Backup Completion Date/Time: Days Since Last Full NAS Image Backup Completed: Node Name: HOOBIE_SQL Filespace Name: HOOBIE\data\0001 Hexadecimal Filespace Name: FSID: 56 Platform: TDP MSSQLV2 NT Filespace Type: API:SqlData Is Filespace Unicode?: No Capacity (MB): 0.0 Pct Util: 0.0 Last Backup Start Date/Time: 11/13/2002 10:34:32 Days Since Last Backup Started: 1 Last Backup Completion Date/Time: 11/13/2002 10:35:29 Days Since Last Backup Completed: 1 Last Full NAS Image Backup Completion Date/Time: Days Since Last Full NAS Image Backup Completed: Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant improvement. = It does not update Last Backup Start Date/Time Last Backup Completion Date/Time ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by email, delete and destroy this message and its attachments. **
Re: SQL 2.2.1
And another thingthe end of backup statistics message that gets pumped up to the server is real long. So if you use a SQL query to get it from the activity log, you only get the first 250-chars. The real meat of the stats is past that. So trying to monitor/automate the backup stats for a TDP backup won't work. (found this one out the hard way...still got the teeth-marks on my butt where it bit me!!) I extracted the data using a SQL, piped it to a file -COMMA and brought it back to my office for analysis. Found I couln't analyze anything from the output. Everything was truncated at 250-chars. Just my rant-of-the-day. Bill Boyer DSS, Inc. There are 10 kinds of people in the world those who understand binary and those who don't. - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L;VM.MARIST.EDU]On Behalf Of Mr. Lindsay Morris Sent: Wednesday, November 13, 2002 11:27 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Bill's right (as usual). The lack of backup start-end times on individual filespaces is pretty crucial. The way I'd like to see reporting of databases (if I were king) would be similar to client nodes: a client node has filespaces a database has tablespaces both of those things have (in concept at least) - a last-backup end time - a size in GB - a percent-full reading Presently, TDP for XXX agents don't tell you this at the filespace level. But there's a fairly easy way around it (OK, the below MIGHT be construed as advertising - be warned and hang up now if you're offended) sure seems like a problem-solver to me though... But there's a fairly easy way around it, if you're using Servergraph anyway: -- run a daily SQL script on the database clients, to generate a table like this: databasenametablespacename sizepercent-full backup-end(maybe) You can probably get the backup-end date by scanning the TDP client logs. -- use sgdwrite to pump that into the Servergraph database over the network. (We'll be glad to do this if somebody will write the Oracle/Informix/etc SQL.) Now Servergraph will treat the database and its tablespaces as just another client node with filespaces, and use the same logic as for client nodes to determine whether the DB was currently backed up. A great incidental benefit: since we keep trending history on all measurements, the percent-full reading will generate predictions and/or alerts on when each individual tablespace INSIDE the database will fill up! Your DBA's ought to love that. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L;VM.MARIST.EDU]On Behalf Of Bill Boyer Sent: Wednesday, November 13, 2002 10:13 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Del, The filespace information only shows be the backup start/end for the INSTANCE. I could go in an backup a single database and the filespace information will change? It doesn't tell me that there is a database in an instance that hasn't backed up in xx-days, like I could get that information from B/A client filespaces. I believe Mr. Lindsay Morris says that ServerGraph uses the filespace information to list filespaces that haven't been backed up in x-days, or even last night. He uses this information instead of the client completion or event records for successfully backups. Take DB2 for example...there is a filespace for each database backed up. Now the backup start/end times aren't maintained, but if they were this type of information would be of more benefit in tracking backups, cleanup,... Now I love the strides taken in the TDP agent reporting, but there are still some things I would like to see. Makes central monitoring a bit easier... Bill Boyer DSS, Inc. There are 10 kinds of people in the world those who understand binary and those who don't. - ?? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L;VM.MARIST.EDU]On Behalf Of Del Hoobler Sent: Wednesday, November 13, 2002 9:28 AM To: [EMAIL PROTECTED] Subject: Re: SQL 2.2.1 Mehdi, What filespace information are you referring to? DP for SQL will not update: Capacity (MB) Pct Util because it is ambiguous in the context of DP for SQL. Remember, those numbers correlate back to a volume capacity and how much of it is utilized. but DP for SQL will update: Node Name Filespace Name FSID Platform Filespace Type Last Backup Start Date/Time Last Backup Completion Date/Time Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] - Never cut what can be untied. - Commit yourself to constant
