go to post Mark Hanson · Sep 8, 2016 This appears to be a duplicate of this item:https://community.intersystems.com/post/csp-erro-upgrade-cache-161The solution for how to lookup these error macros by wrapping them in $$$ERRORCODE is the correct approach. An alternative for the one error page you are having problems with is to manually include %occErrors.inc include file.
go to post Mark Hanson · Sep 7, 2016 I think we may need some more context of what the code looks like and exactly what error message you are getting. We do support $$$CacheError in 2016.1, for example: Set status=$$$ERROR($$$CacheError,$zerror) If you are trying to lookup the macro value then use $$$ERRORCODE($$$CacheError), then you can write logic like: If errorcode=$$$ERRORCODE($$$CacheError) Write "It was a Cache error",!
go to post Mark Hanson · Jul 23, 2016 You do not need to override the propGet method here as this will be generated automatically to call the sqlcomputecode if that is defined.
go to post Mark Hanson · Jul 7, 2016 Try:<script language="Cache" method="OnPreHTTP" arguments="" returntype="%Boolean"> Set %response.ContentType = "text/xml" Quit 1</script><?xml version="1.0" encoding="UTF-8" ?>As the cr/lf after the </script> will end up in the output we generate as this is part of the HTML output rather than inside the script itself.
go to post Mark Hanson · Jun 23, 2016 You are right, I had missed this was creating a %Status and thought they just needed the error code. To create a %Status value I would always use the $$$ERROR macro as you suggest.
go to post Mark Hanson · Jun 23, 2016 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.
go to post Mark Hanson · May 20, 2016 Thank you for this really useful article, there is some great information here.
go to post Mark Hanson · May 16, 2016 FYI: I get consistently slower performance with the 'for' loop variation here (around 10% slower) so at least in my simple test the while loop both looks nicer and runs faster.
go to post Mark Hanson · May 13, 2016 Much better, the main page request is down to 1.0s and total load time is 1.7s which while still slow is no where near as bad as >6s, thanks.
go to post Mark Hanson · May 13, 2016 The MAK4540 fix was approved for porting to 2016.1.1 and all later releases.