You can also view the line at the command prompt with:

ZZPRINT "main+45^LBZNSJHCACUPLB"

Or to view 5 lines before this line and 2 lines after:

ZZPRINT "main+45^LBZNSJHCACUPLB":5:2

Note that any time you build a query as a string if you allow users to insert parameter values or control the string you are building in any way into you need to be aware of SQL injection attacks. This is not a problem with '?' query argument substitution as it is designed to avoid injection attacks, but if you have say:

Set sql="select Name from MyTable where Age > "_userage

And the user supplies 'userage' then they could provide "100; drop table MyTable;" or worse.

Thanks for fixing the RSS feed, it looks great now.

Note that NIST has come up with new recommendations about password security, here is a good overview:

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-wh…

Specifically see this section:

No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”

So it recommends against complex patterns such as the one you are asking about. Also of interest is this one:

No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.

The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

Also this should be fast too:

Set id=1

&sql(select Name into :name from Test.Person where %ID=:id)

Write name,!

I second this request.

The 'Do While' is in fact identical to the 'For' block structure except it adds a redundant while condition at the end which is never false as it will have already exited this block from the 'Quit:Sub1=""' condition earlier, so you should probably remove this as it just takes the 'For' structure and adds this extra test which will slow the loop down.

A disadvantage of the 'While' structure is first you need to repeat the iteration construct, e.g. 'Set Sub1=$O(^Trans(Sub1))' before entering the loop and at the end. Also if you need to skip an item with say the 'For' structure you can just issue a 'Continue' but with the 'While' structure you have to advance the current subscript value manually before issuing a 'Continue'

In the 'Method Levels' the lines like 'Goto Level1' are not needed as the previous line says 'Set Sub2="" Goto Level2' so it will always be evaluating this 'Goto Level2' and so will never get to the next line. Rather than having this you can simplify to just 'Set Sub2=""' and remove both 'Goto' statements so it will just drop down into Level2 automatically.

The correct way to do this is:

set RunStatus=$System.Status.Error($$$ERRORCODE($$$GeneralError),"DXL Testing Run Error")

So use $$$ERRORCODE which can convert the error code to the number correctly.

Thank you for this really useful article, there is some great information here.

I fully agree with hoisting constants out of a loop and have recently spent a while optimizing code to use $listnext in SQL and so agree it is a much faster way to iterate over $listbuild structures.

However in your first case of a 'For' loop the end condition is evaluated when entering the loop the first time and is not re-evaluated at all, for example run this:

CACHE20164:USER>set a=2 for i=1:1:a { set a=10 write i,! }
1
2

As you can see it always stops at '2' rather than going on to '10'.

Also there is overhead in converting from a delimited string into a $list format in order to use the more efficient $listnext, you can avoid the O(n^2) overhead with the regular $piece(string,",",i) code in a loop using $find with a starting position and then $extract the item you need. This should perform better than $listnext version of the loop at least for mid sized strings as it avoids the conversion overhead.

On the initial page displayed if you click on any of the links such as the Improved SQL Processing Performance item it takes you to a link which eventually times out, looks like these are missing the 'beta' as the first part of their url:

http://docs.intersystems.com/csp/docbook/DocBook.UI.FramePage.cls?KEY=G…

I would generally advise against using %File class for reading files as this is a very low level wrapper around the COS file commands. For example if you want to apply a translate table you need to know about the 'K' flag on the open command. I much prefer using the %Stream.FileBinary or %Stream.FileCharacter classes as these provide a much more consistent interface to the file.

I often do this too, I think this sort of pattern is a good way to make the error handling simple and consistent.