connection.Up until recently, the only way I could get my Cisco VPN to work was to place my desktop in the DMZ. I really did not like having to do that. After considerable Internet searching, I could not find any information specific to my D-Link model (DIR 625) for allowing access using a Cisco VPN. Most of the information I was able to locate referenced other models and most made reference to making sure ‘VPN pass-through’ is enabled. Well, AFAIK, the DIR 625 does not have a ‘pass-through’ setting. Other information referred to forwarding port 10000 . However, those failed to mention port 10000 is only used when you configure the VPN to use TCP rather than UDP. My configuration was given to me by our network admin and it uses IPSec/UDP. When I tried to change it, the connection no longer worked even while in the DMZ. I could only conclude the target would only accept UDP.

After a couple of hours of experimentation, I was finally able to establish a connection without being in the DMZ. So that others who may happen to fall into the same situation have a solution, I am providing it here.

The very first thing you must do is to open your D-Link Admin screen, click the Advanced tab on top, and open the Inbound Filter on the left. You’ll need to create a new filter using the IP address where your VPN connects to. You can easily find this by looking at your D-Link log right after an unsuccessful  connection attempt (you’ll see the blocked attempt). An example of an Inbound Filter is given here but with my IP partially blocked. My source range is for one IP address. Pay attention to the ‘Name’ given, it will be used again.

image

After saving your inbound filter, you now need to open the Port Forwarding item on the left of your screen. You will then add a new rule to forward UDP ports 500 through 5000 65536 to your local machine using the filter created in the previous step. Its actually pretty easy because the filter name will be in the drop-down list for the Inbound Filter item. Take a look at this example screen shot:

imageдивани

Save your settings and you should now be able to use your Cisco VPN connection without resorting to using the DMZ.

This is one of those nasty little thorns that sticks you every once in a while.

You add a new SQL Server authentication login with Server Manager and you forget to uncheck the boxes for User must change password, Enforce password, and Enforce Expiration. Being this is an application user for which you don’t want to enforce password restrictions and which uses ODBC, therefore never seeing a login dialog, they never get an opportunity to change the password. Consequently the login can’t be used as is.
image

Ok, you realize your mistake too late. The login has been created. It has been associated with one or more databases and/or schemas. Permissions have been granted, etc., etc., etc. How do you fix it? Guess what? If you try to just want to uncheck the “User must change” check box, you can’t! It is greyed out.

This conundrum perplexed me to no end when first encountered. Searching the internet turned up several solutions like this one:
ALTER LOGIN test_must_change WITH PASSWORD = ‘newpass’,
      CHECK_POLICY = OFF,
      CHECK_EXPIRATION = OFF;

Guess what happens (you have three choices and the first two don’t count). You get this error message
Msg 15128, Level 16, State 1, Line 1
The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.

If you try to user Server Manager and just uncheck the ‘Enforce password policy’ or ‘Enforce password expiration’ boxes, you get this

THE FIX

You MUST change the password first and it must be done without changing the other password policy options. You CAN change the password to be the same as the existing one. However, you do it, you still must effect a change on the password an then change the policy options as a separate step. If you choose to use the Server Manager wizard, when you change the password, the ‘User must change password’ check box will become available and you can then uncheck it (do not uncheck the other policy check boxes if they already were). You can then save the change, open the wizard again, uncheck the other policy restrictions, and save it again.

If you decide to use a query, you can use code similar to this
USE Master
GO
ALTER LOGIN test_must_change WITH PASSWORD = ’samepassword’
GO
ALTER LOGIN test_must_change WITH
      CHECK_POLICY = OFF,
      CHECK_EXPIRATION = OFF;

Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604

I recently ran into this problem and because I could not find much relevant information to resolve it, I decide to write up my resolution process. I am not sure of all the reasons one can encounter a “604″ error and this process addresses a problem with corrupted blocks.

My Alert log contained an entry, just prior to the “604″, which indicated I had corrupt data blocks in my SYSTEM01.DBF data file.

Corrupt block relative dba: 0×00400037 (file 1, block 55) Fractured block found during buffer read Data in bad block: type: 0 format: 0 rdba: 0×00000000 last change scn: 0×0000.00000000 seq: 0×0 flg: 0×00 spare1: 0×0 spare2: 0×0 spare3: 0×0 consistency value in tail: 0×00001501 check value in block header: 0×0 block checksum disabled Reread of rdba: 0×00400037 (file 1, block 55) found same corrupted data Tue Sep 09 13:27:59 2008 Errors in file d:\oracle\product\10.2.0\admin\fmax\udump\fmax_ora_668.trc: ORA-00604: error occurred at recursive SQL level 2 ORA-01578: ORACLE data block corrupted (file # 1, block # 55) ORA-01110: data file 1: ‘E:\ORADATA\FMAX\ORADATA\FMAX\SYSTEM01.DBF’

At first I ‘googled” a search for the 604 error text and found meaningful information but no clear way of resolving it. Several suggestions referred to using the ‘START MOUNT’ followed with a ‘RECOVER DATABASE’. I tried that and the database did go through recovery but still would not start. After thinking about it a few minutes, I recalled using RMAN to recover corrupted blocks on an already running database. So, I said to myself: ‘Self, why not use RMAN again’? I knew the database would not open bu RMAN should be able to run against a ‘mounted’ database. I then issued the START MOUNT command in SQLPLUS, brought up another command window (this is a Windoze environment) and ran through the RMAN recover corrupt blocks process

RMAN> connect target connected to target database: FMAX (DBID=1458847106) RMAN> backup check logical validate database; Starting backup at 08-AUG-08 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=245 devtype=DISK channel ORA_DISK_1: starting compressed full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00005 name=E:\ORADATA\FMAX\ORADATA\FMAX\FMAX_DATA.DBF input datafile fno=00001 name=E:\ORADATA\FMAX\ORADATA\FMAX\SYSTEM01.DBF input datafile fno=00003 name=E:\ORADATA\FMAX\ORADATA\FMAX\SYSAUX01.DBF input datafile fno=00006 name=E:\ORADATA\FMAX\ORADATA\FMAX\TOOLS01.DBF input datafile fno=00002 name=E:\ORADATA\FMAX\ORADATA\FMAX\UNDOTBS01.DBF input datafile fno=00004 name=E:\ORADATA\FMAX\ORADATA\FMAX\USERS01.DBF channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25 Finished backup at 08-AUG-08 RMAN> BLOCKRECOVER CORRUPTION LIST; Starting blockrecover at 08-AUG-08 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:00 Finished blockrecover at 08-AUG-08 RMAN>

After completing the RMAN recovery, I then issued an ALTER DATABASE OPEN and the database opened just fine. I just hope this little bit of information may help any one else who encounters a similar problem.

One of my very first programming jobs was maintaining and developing a large Fortran application. The application consisted of numerous statistical analysis programs used by test developers at Educational Testing Services. So when I received my current Dr. Dobbs email subscription, the following article brought back a lot of fond memories. Because I could not find the actual article on the Dr. Dobbs WEB site, I have reprinted it here. If I eventually locate it, I’ll then include a link.

Fortran: Staying Up to Date

In an industry when things change at GHz speeds, there’s solace in the permanance of tools like Fortran, which has been around since…what, the 1950s? Well “yes,” now that I think about it. John Backus spec’d out the “IBM Mathematical Formula Translating System” in the early 1950s, and delivered the first Fortran compiler in the late 1950s, or thereabout.

Mr. Backus was my kind of guy. When asked many years later why he created Fortran in the first place, he responded that “much of my work has come from being lazy.” He went on to add that “I didn’t like writing programs, and so, when I was working on the IBM 701 (an early computer), writing programs for computing missile trajectories, I started work on a programming system to make it easier to write programs.”

What brought all this to mind is the note from Absoft that it has released the first commercial Fortran IDE for Windows and Linux (and MacOS not far behind). The IDE, which comes bundled with Absoft’s Pro Fortran 10.1 tool suite, supports development for multi-core processor from Intel and AMD by providing auto-parallelization and auto-vectorization. According to Absoft, performance tests with Pro Fortran 10.1 auto-parallelizing and auto-vectorizing compilers have demonstrated superscalar speed improvements on several industry benchmark programs. With the IDE, tools can be run from the GUI or the command line. It also accepts select third-party tools, such as compilers from Apple, GNU, and Microsoft and VNI’s IMSL numerical libraries.

There you have it. Even at 50 years old, Fortran is kicking up its heels. Which makes me wonder: What do you think Ruby or C# will look like 50 years from now?

– Jonathan Erickson
jerickson@ddj.com

Another good Fortran article worth a read locate at Dr. Dobb’s is Fortran and IMSL: It’s MacOS’s Turn

eHarmony’s Vice President of Technology, Mark Douglas, cites SQL Server’s row locking mechanics as the biggest detractor. It appears this was a major roadblock to scaling their application enough to accommodate their fast growth. Find out more from the entire article here…

eHarmony spurns Microsoft, finds match with Oracle 10g