CLS is kept in the system globals in each namespace. With some work you could probably write a COS routine to display the CLS in a human readable format.

Tom Fitzgibbon | gototomATg...l.com

Some ISPs block port 25, see the SMTP server specs for other ports you can use (465, 587, etc).

Code below has worked for me in the past.

Tom Fitzgibbon | gototomATg...l.com

-------------------------------------------------------------------------------------------------------

SendMail(Message,SendTo,Subject) ;send mail

s s=##class(%Net.SMTP).%New()

s auth=##class(%Net.Authenticator).%New() ; use default auth

s auth.UserName="user@domain.com"

s auth.Password="xxxxxxxx"

s s.authenticator=auth

s s.smtpserver="smtpout.secureserver.net"

s s.timezone="Local"

s s.port="80" ;for secureserver

s m=##class(%Net.MailMessage).%New()

s m.Charset="iso-8859-1"

s m.From="person@domain.com"

Send ;where to?

d m.To.Insert(SendTo)

;subject

s m.Subject = Subject

d m.TextData.Write(Message)

s status=s.Send(m)

d m.%Close()

d auth.%Close()

q status

I agree with Benjamin: VMs (and containers) are the way to make testing environments. Once you set up your VM/container structure it's easy to create/delete identical testing instances.  Obviously make sure that you carefully isolate your cloned Cache from the real world or it may start interacting with real world production.

Tom Fitzgibbon | tom@tec.today | 3474648531

If you've had any experience with packet monitors you probably should try Wireshark since it's the most widely used. Various plugins, addons are available. I've used to monitor CSP, SOAP, JSON, Ensemble and other transactional comm.

Fiddler is a bit more user friendly but once you're in the packet details you have to spend time deciphering no matter what monitor.

Tom Fitzgibbon | gototomATG...l | 3474648531

You can read cache.dat unless it's encrypted on the disk.

See http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY….

Tom Fitzgibbon | gototomAtG...l | 3474648531

If you haven't done so already, check with InterSystems.

I've rarely rebuilt indexes while moving Cache DBs. It's a complex added step that is probably not worth doing unless you have very large DB or limited copy throughput.

Tom Fitzgibbon gototomAtG...l

Having a refreshable image of your Cache/Namespace test area is the way to go.

Use Docker, VM machine image, backup image or other techniques to quickly reset full Cache image back to baseline for more testing.

Tom Fitzgibbon | gototomAtG...l | 13474648531

One thing to check is to make sure your users are not starting up multiple CSP sessions from the same or different browsers on the same device.

Some of our users learned that there was no limit, before we changed our software, to the number of simultaneous CSP application windows they could open.

Six months after we rolled out the application suddenly the entire user population started opening multiple windows and we ran out of license slots.

Bonne chance,

Tom Fitzgibbon | gototomAtG...l | 3474648531

Where is the SQL residing and how do want to trigger it?

If it's sitting on a local Cache server you can start it any number of ways: web page, Cache routine menu, text/email a listener routine, hit a JSON service, "Alexa, start my SQL query", push a big red button, etc.

If on the cloud somewhere or on someone else's server behind a firewall you have to get past authentication/firewall to start the query.

- Tom Fitzgibbon | 9179331226 | gototomAtG...l

Windows Cache or Linux Cache Mirroring and Clustering are available for mission critical systems.  Cache is one of most stable DBs around without any extra steps but you probably want to go further for critical production servers.

I ran mirrored Windows servers without data loss. Fairly easy to set up and maintain. Clusters a bit more complicated but may fit with your production model.

See http://www.intersystems.com/our-products/cache/provisioning-monitoring-managing-applications/high-availability/ and http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_failover.

Tom Fitzgibbon | gototomAtG...l.com | 917-933-1226

Obviously each project will have different requirements. But here are some generalizations from my experience:

Cache SQL: use when you want to expose your data to report writers who use SQL. Use Cache SQL write capability if you must but may be slower. Fairly easy to read code. But you do NOT need Cache SQL to create an app.

Cache Objects: used most often, especially if you are an object oriented programmer. Hard to not see the advantages of objects in most projects. Reasonable speed and code readability.

Cache Direct Global access: used for legacy programs (lots out there) and may be faster performance (depending on read/write code structure). Difficult to read after years of code changes.

Tom FItzgibbon | gototomAtG...l.com | 347-464-8531

Recent InterSystems Cache works rather well and has a tendency to make us lazy about checking the DB. SQL, Mongo, etc. DB admins must check/fix/maintain DBs on a regular basis.

For our smallish 100GB-200GB Cache DBs we scheduled daily background integrity checking but would typically find small damage only once every 3 years or more due primarily to hardware failures.

Cache appears to be incredibly resilient compared to other DBs.

Tom Fitzgibbon | gototomAtG...l.com | 917-933-1226

Licensing issues are best taken up directly with InterSystems. Most likely free test Cache software tricked up to not accept license to slow piracy.

Tom Fitzgibbon | gototomAtG...l.com | 917-933-1226

NYC needs a Cache/Ensemble/etc. user group. User groups generate sales and provide support for InterSystems.

I'm willing to volunteer some time to publicize and organize.

Anyone know about a space? We could try a meet to see who might be interested.

I'm assuming InterSystems (like a lot of vendors) would prefer to keep an arm's length approach to any user groups.

Tom Fitzgibbon | 3474648531 | gototomAtG...l.com

Scott -

We've had this problem many times with HL7 messages being "lost" after the sender claims they sent messages to our receiver software. Most of the time we found the sender actually did not send out the HL7 message or sent out a "malformed" message that our receiver rejected. Plus most HL7 sender software has filters that will not send particular messages for a variety of conditions.

Since HL7 is somewhat predictable text, it's pretty easy to parse. You can ask the sender for the missing message number and search for it in your capture stream, for example.

Receiving data from another vendor often creates arguments about "missing" data.

We troubleshot problems as below:

1) Examine any audit information given by Ensemble for errors, rejections, retransmissions and the like.

2) Set up a passive listener that records all data (not just HL7 messages) and examine with tools or your own diagnostic software.

3) Set up additional HL7 receiver software which takes the incoming messages and creates files on your platform (while doing the ACK/NACK with the sender). Then you can examine the files and later process with Ensemble.

Tom Fitzgibbon | 347-464-8531 | gototomAtG...l.com

A Cache script also allows you to do other user management, like look for similar named users across all instances, construct interesting user tables for permissions, etc.

Should be fairly straightforward for simple user adds, for example.

Tom Fitzgibbon | 347-464-8531 | gototomAtG...l.com