Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


All Hooked Up. (Circa 1957, Elvis Presley)

By Richard Morris, Posted on July 19, 2011 at 9:25 am

Avatar

Back in the day, Elvis Presley shook up a bit of a stir when his gyrating hips and dulcet tones came over the airways onto our little black and white TVs (so I was told, I’m not old enough!).  Today, Synergex is defining a development that will shake the Synergy world when it’s released with an upcoming version!  And it’s a development that we’ll all be hooked on.

In the specification phase at the moment is the ability to “hook” user definable logic against operations within the SDBMS file IO system.  This proposal offers the ability to perform logic when any operations on any SDMBS file (index or relative)  are executed.

For example, you can hook up a Synergy method that will be called “before” a record is read from a file, or before a record is stored into a file.  A method can be hooked up and executed when a record lock is encountered, records deleted or updated.

The possibilities are truly endless.  You could use this capability to debug your applications.  For example, you may have a system that occasionally encounters corrupt data – and you have no idea when the data got corrupted.  By implementing pre-store and pre-write event hooks you could validate the data and log to a file if it’s not valid.  Because it’s a Synergy method, in the calling stack, you can use routines like MODNAME to record the full stack trace and pinpoint the problem.

Implementing hooks for the pre-store and pre-update events can allow you to ensure that default data is correctly set.

Hooking up post-events could allow you to record modifications to your SDBMS data that you wish to replicate somewhere – in a third party relational database for example.  Or you could actually record the data being sent to a file for transaction/logging purposes.

All hooks will be on a per-channel basis, so if you currently have a generic file open routine you’ll be well placed to begin to implement this new exciting capability.  If you don’t, now’s the time to start thinking of adding one!

One thing to remember, performance!  Once you have bound a hook to an event then every operation of that type will cause your logic to be executed, so keep the code concise, specific and efficient!!

This development, for me, is on a par with the .NET API – it’ll open up a whole new world of possibilities.  I can’t wait to get hold of the alpha release so I can blog about it, and watch out for the early videos showing you the full power of this great new development.  And the best bit is that it’ll be supported on ALL platforms, so you won’t have to be a .NET guru to take full advantage!  I can already feel an SPC session in the making.

I’m hooked, line a sinker!


Hosting WCF Services in an ASP.NET Web Application

By Steve Ives, Posted on July 1, 2011 at 3:39 pm

Steve Ives

There are several ways that you can use Synergy/DE tools to expose WCF services, but regardless of which way you decide to create a service, the next decision you have to make is how to host it. By hosting a WCF service you expos the service and make it possible to use it from other applications. In this post I will introduce you to one way that WCF services may be hosted, via an ASP.NET web application and an IIS web server. In a later post I will show you how to host WCF services without this requirement for an IIS web server.

This is the third in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application (this post)
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

 

A WCF service is simply a collection of one or more classes in an assembly, but the whole point of implementing a WCF service is to make those classes available to be used by other applications. And those applications will often be located on different networked systems from the service itself. So, in order for a WCF service to be useful, it needs to be “hosted” somewhere, and that somewhere needs to be available on a network.

There are three basic ways that WCF services can be hosted:

  1. Inside a Web application located on a Web server.
  2. Using Windows Process Activation Services (WAS). This mechanism was introduced in Windows Server 2008 and provides a mechanism for hosting WCF services without requiring a Web server.
  3. Services can be “self” hosted by some custom .NET application. For example, developers often host WCF services inside a Windows Service application.

In this post I will show you the basics of hosting a WCF service in an ASP.NET web application. In a future post I will go on to show how to self-host services.

Setting up basic hosting for a WCF service inside an ASP.NET Web application is very easy, but as Synergy .NET doesn’t have support for creating Web applications. You’ll have to use another .NET language, either C# or VB.NET. However, don’t worry about that too much, because there won’t actually be any code in the Web application!

  • Start Visual Studio 2010 and create a new ASP.NET application:
    • From the menu, select File > New > Project.
    • Under Installed Templates, select Visual C# > Web > ASP.NET Empty Web Application.
    • Chose the name and location for your new Web application.
    • Click the OK button to create the new project.
  • Add a new WCF Service to the project:
    • From the menu, select Project > Add New Item.
    • Under Installed Templates, select Visual C# > Web > WCF Service.
    • Enter the name for your new service. The name will be part of the service endpoint URI that the client connects to, so pick something meaningful. For example, if your service allows orders to be placed then you might name the service something like OrderServices.svc.
    • Click the Add button to add the new service to the project.

You will notice that three files were added to the project:

image

 

In addition to the service (.svc) file that you named, you will see two C# source files. These files were added because Visual Studio provided all of the files that you would need in order to expose a new WCF service that would be manually coded in these files. But what we’re trying to do is host a WCF service that already exists in another .NET assembly.

  • Delete the two C# source files by right-clicking on each and selecting delete.

In order to expose a WCF service that exists in another assembly, the first thing we need to do is add a reference to that assembly, to make the classes it contains available within the new Web application.

  • From the menu select Project > Add Reference and then select Browse.
  • Locate and select the assembly containing your WCF service and add a reference to your project.
  • If the assembly you selected was created using xfNetLink .NET then you will also need to add a reference to the xfnlnet.dll assembly, as is usual when using xfNetLink .NET

You’ll need to know that namespace and class name of the WCF service in your assembly. If you can’t remember this that double-click on the assembly that you just referenced and then use Object Browser to drill into the assembly and figure out the names. All that remains is to “point” the service file at your WCF service class.

  • Double-click on the service (.svc) file to edit it. You should see something like this:

image

Edit the file as follows:

  • Change Language=”C#” to Language=”Synergy”.
  • Change Service=”…” to Service=”YourNamespace.YourWcfClass” (obviously replacing YourNamespace and YourWcfClass with the namespace and class name of your WCF service).
  • Remove the CodeBehind=”…” item … there is no code-behind, the code is all in the other assembly.
  • Save the file.

So you should now have something like this:

image

If your service is based on an assembly created using xfNetLink .NET then you have one final configuration step to perform. You need to tell xfNetLink .NET how to connect to xfServerPlus. You can do this by using the Synergy xfNetLink .NET Configuration Utility (look in the Windows Start Menu) to edit the new web applications Web.config file. If your xfServerPlus service is not on the same machine as your new web application then you must specify a host name or IP address, and if xfServerPlus is not using the default port (2356) then you must also specify a port number. When you’re done, the Web.config file should contain a section like this:

image

That’s it, you’re done. You should now have a working WCF service!

  • To see if the service has really been hosted, right-click on the service (.svc) file and select View In Browser.

You should see the service home page, which will look something like this:

image

If you see this page then your service is up and running. By the way, the URI in your browsers address window is the URI that you would use to add a “Service Reference” to the service in a client application … but we’ll get on to that in a later post.

Of course, all we have actually done here is set up a web application to host a WCF service, but we’re using Visual Studio’s built in development web server (Cassini) to actually host the service. If you were doing this for real then you’d need to deploy your new web application onto a “real” IIS web server.

We’re not done with the subject of hosting WCF services; in fact we’ve only really scratched the surface. One step at a time!

In my next post in this series I will show you how to Expose a WCF services using Synergy .NET Interop.


Exposing WCF Services using xfNetLink .NET

By Steve Ives, Posted on at 1:40 pm

Steve Ives

Following a recent enhancement to the product in Synergy 9.5.1, developers can now use xfNetLink .NET to create and expose Windows Communication Foundation (WCF) services. In this post I will describe how to do so.

This is the second in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET (this post)
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

 

The basic approach is pretty easy; in fact it’s very easy. In 9.5.1 we added a new -w command line switch to the gencs utility, and when you use the new switch you wind up with a WCF service. I told you it was easy!

So, what changes when you use the gencs –w switch? Well, the first thing that changes are the procedural classes that are generated, the ones that correspond to your interfaces and methods in your method catalog, change in the following ways:

  1. Three new namespaces (System.Runtime.Serialization, System.ServiceModel and System.Collections.Generic) are imported.
  2. The class is decorated with the ServiceContract attribute. This identifies the class as providing methods which can be exposed via WCF.
  3. Methods in the class are decorated with the OperationContract attribute. This identifies the individual methods as being part of the service contract exposed by the class, making the methods callable via WCF.
  4. If any methods have collection parameters, the data type of those parameters is changed from System.Collections.ArrayList to System.Collections.Generic.List. Changing the collection data type is not strictly necessary in order to use WCF, but results in a more strongly prototyped environment which is easier to use, and offers more benefits to developers in terms of increased IntelliSense, etc.

The next thing that changes are any data classes, the ones that correspond to the repository structures that are exposed by the parameters of your methods, that are generated. These data classes change in the following ways:

  1. Two new namespaces are imported. These namespaces are System.Runtime.Serialization and System.ServiceModel.
  2. Each data class (which corresponds to one of your repository structures) that is generated is decorated with the DataContract attribute. This identifies the data class as a class which can be used in conjunction with a WCF service, and which can be serialized for transmission over the wire.
  3. Each public property (which corresponds to a field in the structure) is decorated with the DataMemeber attribute. This attribute identifies each property within the class as one which will be serialized, and as a result will be visible to client applications which use the WCF service.

By the way, if you use a Workbench “.NET Component Project” to create your xfNetLink .NET assemblies then there isn’t currently an option in the component information dialog to cause the new –w switch to be used. So, for the time being, what you can do is add the switch to the Workbench “Generate C# Classes” tool command line. To do this you would go into project properties for the component project, go to the Tools tab, select the “Generate C# Classes” tool, then add the –w at the end of the command line, like this:

image

We’ll be adding a new checkbox to the component information dialog in 9.5.3 later this year.

By the way, by using the gencs –w switch you make it possible to use the resulting classes as a WCF service, but you don’t have to do so … you can continue to use the classes as a regular xfNetLink .NET assembly also. Why would you want to do that? Well, I sometimes use gencs –w just to turn my collection parameters into generic lists!

I have submitted a working example to the Synergy/DE CodeExchange, contained within the zip file called ClientServerExamples.zip. Within the example, the following folders are relevant to exposing and consuming a WCF Service using xfNetLink .NET:

Folder / Project

Description

xfServerPlus

Contains the Workbench development environment for xfServerPlus and the exposed Synergy methods. If you wish to actually execute the examples then you must follow the setup instructions in the readme.txt file.

xfNetLink_wcf

Contains the Workbench project used to create the xfNetLink .NET client assembly with the WCF attributes.

3_xfpl_xfnl_wcf_service

Contains the Visual Studio 2010 solution containing an ASP.NET web application used to host the WCF service, as well as three example client applications, written in Synergy .NET, C# and VB.

So, the gencs –w command line switch you make it possible to use the resulting classes to directly expose a WCF service, but there is still the matter of how to “host” the service in order to make it accessible to remote client applications, and that’s what I will begin to address in my next posting.


Optimizing your Visual Studio 2010 Experience

By Steve Ives, Posted on June 22, 2011 at 3:52 pm

Steve Ives

Visual Studio 2010 is one of the best IDE’s I have ever seen and worked with, and provides, out of the box, a truly impressive array of tools to make developers lives easier and more productive. But, as good as it already is, there is still room for improvement.

Luckily Microsoft has provided an extensible platform and an easy way for people who develop extensions to be able to publish those extensions to developers. Check out the “Extension Manager” utility that you will find on the Tools menu.

emThe extension manager, as suggested by its name, provides a simple UI which allows you to locate, download and install all kinds of Visual Studio extensions. The actual extensions are hosted on-line at a web site called the Visual Studio Gallery. Some extensions are written by Microsoft, some by third-parties. Some provide additional functionality throughout Visual Studio, while some are specific to a particular language. Some add new project or item templates to Visual Studio, while others add complex capabilities in a range of scenarios.

Go take a look, there are a lot of extensions to choose from. If you’re looking for recommendations then personally I think that there are two extensions that no Visual Studio 2010 developer should be without … apart from the Synergy Language Integration for Visual Studio extension of course. You’ll find these extensions in the gallery, and if you sort the list by “Highest Ranked” then they should be close to the top of the list … they are VERY popular! My favorite extensions are both published by Microsoft, and both are free. They are called:

· Productivity Power Tools

· PowerCommands for Visual Studio 2010

I won’t even attempt to go into detail about what these extensions do, because the list of enhancements is a long one. You can click on the hyperlinks above and read all about them in the gallery. Suffice it to say that if for some reason I wind up working on a system other than my own laptop, and these extensions are not installed, I miss them both terribly!


Building Distributed Apps with Synergy/DE and WCF

By Steve Ives, Posted on at 1:22 pm

Steve Ives

At the recent SPC’s in Chicago and Oxford several of the sessions that I presented were focused on networking, and in particular on the various tools and technologies that are available to Synergy developers to allow them to build and deploy distributed software applications. In particular I spent quite a bit of time talking about a technology called Windows Communication Foundation.

This is the first in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF (this post)
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

What is WCF

WCF is a part of the .NET framework that provides a powerful and flexible way to implement network communication between the various parts of a distributed software application. For many years Synergy developers have been able to build distributed applications using xfServerPlus and xfNetLink. Many have done so, and have deployed a wide variety of applications based on these technologies. When developing a new .NET client application developers would use xfNetLink .NET to gain access to their Synergy business logic and data.

This approach has served us well over the years, will continue to do so, and is still the most appropriate solution in some scenarios. But in some other scenarios using WCF might now be more appropriate, and could help developers to broaden the capabilities of their applications in several key areas, some of which are:

WAN Communication

Because the communication between xfServerPlus and xfNetLink uses a custom protocol which operates on a “non-standard” port, it may not be appropriate for use over wide area networks and the Internet. The primary problem here is that there is a high chance that this communication would be blocked by firewalls, some of which may be outside of your control. WCF supports multiple network transport protocols, the most basic of which is HTTP. This means that it is designed with the Internet in mind, and is very suitable for implementing applications which communicate over the Internet.

Multiple Endpoints

Another advantage of WCF is that the same WCF service can be exposed via multiple “endpoints”, and each of these endpoints can be configured to use different communication protocols and mechanisms. For example a single service could be exposed via one endpoint which uses HTTP and SOAP which would be suitable for a wide variety of client applications to be able to access from anywhere (including via the Internet), while at the same time being exposed by a second endpoint which uses low-level TCP/IP communications and binary messaging protocols suitable for use by applications running on the same local network as the service, at much higher performance. A single client application could even be configured to dynamically switch between these endpoints based on the current location of the user.

More Client Options

When using xfServerPlus and xfNetLink, client applications must be written in a programming language which is able to use one of the supported xfNetLink clients (COM, Java or .NET), but because WCF services can be interacted with via “standard” protocols such as HTTP and SOAP there are many more client application possibilities, because almost all development environments and programming languages are able to use these basic protocols.

Asynchronous Support

WCF also provides the ability to easily support asynchronous communication between clients and servers. When a client application calls an xfServerPlus method the client must wait for the execution of the method to complete, and for any resulting data to be returned, before performing any other processing. Using WCF it’s easy to support asynchronous method support, where the client application can call a method and then continue with other processing, later receiving an event when the remote method has completed its operation and when any resulting data is ready for use. This approach can make client applications appear to be much more dynamic and responsive.

Bi-Directional Communication

In many distributed software applications interaction between the client and the server is initiated by some event in the client application which requires some subsequent processing in the server application. But in some situations it is necessary for the server application to be able to, at will, initiate some processing in the client application. Unfortunately xfServerPlus and xfNetLink don’t really address this use case, but it can be addressed with WCF, because WCF service endpoints can be “self-hosted” within any type of .NET application. This means that as well as a client application having the ability to interact with a WCF service on some server somewhere, the client can also expose a WCF service, which the server application (or in fact any other application) could interact with.

WCF is an extensive subject area, and in this BLOG I’m not even going to attempt to teach you about the specifics of using WCF. Instead I’m simply going to try to make you aware of some of the reasons that you might want to explore the subject further, and make sure that you know about the various ways that you can get started.

There are several ways that Synergy developers can utilize WCF in their applications, and I’ll briefly describe each of these mechanisms below.

WCF via xfNetLink .NET

In xfNetLink .NET 9.5.1 a new feature was introduced which gives developers a lot of additional flexibility in the way that they build their applications, or rather the way that they communicate between the various parts of the application. This new feature is enabled through a new command line parameter to the gencs utility (-w). When you use this new option, two things change.

When you use gencs –w, the first thing that changes is that various attributes are added to the wrapper classes that are created by gencs. These attributes in turn allow those generated classes (and the assembly that they are compiled into) to be directly exposed as a WCF service. Previously, if a Synergy developer wanted to expose a WCF service which in turn exposed their Synergy business logic and data, they have to manually “wrap” their xfNetLink .NET procedural and data classes in other classes which in turn exposed a web or WCF service.

The second change when using gencs -w is that any collections which are exposed by the application API are transformed from un-typed “ArrayList” collections, to more useful and flexible “Generic List” collections. This change will require a small amount of re-coding in any existing client applications, but results in a significantly enhanced development experience.

This mechanism is likely to be of interest to developers who already have an existing solution using xfNetLink .NET and xfServerPlus, and want to take advantage of some of the additional capabilities of WCF, or to developers who wish to expose a new WCF service where the server application exposes code running on a UNIX, Linux or OpenVMS server.

WCF via Synergy .NET Interop

Another way that Synergy developers can expose WCF services is via Synergy .NET’s “Interop” project. The primary purpose of an Interop project is to allow developers with existing xfServerPlus applications to migrate their existing Synergy methods to a native .NET environment. By adding their method source code to an interop project they are able to execute those methods directly in the .NET environment, instead of using xfNetLink .NET and xfServerPlus to execute the methods with traditional Synergy on a remote server.

The Interop project works by generating Synergy .NET “wrapper classes” for your traditional Synergy methods (subroutines and functions) and data structures (records). The external interface of these wrapper classes is very similar to that of the C# wrapper classes produced by xfNetLink .NET’s gencs utility. The primary goal of the Interop project is to allow developers to migrate existing applications from a mixed .NET / traditional Synergy environment to a 100% .NET environment, with only minor changes to the code of existing client applications.

When you create an Interop project in Visual Studio, one of the options that you have (via the project properties dialogs) is to “Generate WCF contracts”, and as discussed earlier in this article, the effect of this is to add various attributes to the generated wrapper classes so that they can be directly exposed as a WCF service.

So again, for Synergy developers, this approach can provide a quick-and-easy way to expose a WCF service based on existing code. Again, this approach is likely to be primarily of interest to those who already have xfServerPlus based applications running on the Windows platform.

WCF via Synergy .NET

Both of the previous approaches were primarily focused on those who already use xfServerPlus, and both provide an easy way to get started with WCF. However in both of the previous scenarios, the external interface of your WCF service is directly defined by the interface to your underlying traditional Synergy methods (subroutines and functions), and the WCF data contracts that are exposed are defined by the repository structures exposed by the parameters of those methods. So, while the WCF capabilities provided by xfNetLink .NET and by the Synergy .NET Interop project are easy to use, you don’t get full control over the exposed interface and data. If you want that finer level of control, or if you’re just getting started with server application development and don’t have existing xfServerPlus methods, there is a better way to go.

The third way that Synergy developers can leverage WCF is by using Synergy .NET to create an all-new WCF service with native .NET code. This task was possible in 9.5.1 when Synergy .NET was first introduced, but has been made much easier through the introduction of a new “WCF Service Library” project template in 9.5.1a.

Creating a new WCF service via a WCF Service Library is the way to go for developers who want to write an all-new service application, or who don’t mind a little extra effort to re-work some existing code in order to factor out some of the “wrapper” layers involved with the previous two approaches. As a result you will have full control of the resulting WCF service, and the contracts that it exposes.

Wrapping Up – For Now

So, as you can see, Synergy/DE is now providing you will all kinds of new and exciting things that you can do in your Synergy applications, and I firmly believe that WCF is one of the most important, and powerful. In the near future I will be writing several additional BLOG posts which will explain these three ways of exposing WCF services in more detail, and I’ll also try to provide more detail about WCF generally. So for now, be thinking about how your existing distributed applications are built, and what things you might wish to improve about them. Or be thinking about that all-new distributed application that you’ve wanted to get started on. If you’re thinking of enhancing or implementing a distributed application, then using WCF is almost certainly the way to go.


Shameless plug

By William Hawkins, Posted on March 28, 2011 at 4:38 pm

Avatar

I’ve just come back from the UK, where Richard Morris and myself attended DevWeek 2011.   The DevWeek conference was hosted at the Barbican center in London, and covered a multitude of various Microsoft / Windows technologies. As it wasn’t hosted by Microsoft, there were no significant goodies/toys given away, but we did gain a lot of great info on developing state-of-the-art user interfaces, and lose a few pounds climbing 4 flights of stairs between sessions.
After the conference, Richard and I visited a couple of customers and had planned to spend a couple of days performing analysis work for a prospective PSG project.  However, a few hours into this analysis task, we got a cry for help from another UK customer that Richard had been working with.
This customer was in the process of moving their application from OpenVMS to Windows.  They had already moved the executables to Windows and were using xfServer to access the data on OpenVMS.  Over the weekend that followed DevWeek, Richard had helped them do a test migration of the data from OpenVMS RMS files to Windows SDBMS isam files, and it all appeared to be working fine.  However, during their testing, a few files were showing spurious data in a few fields – hence the cry for help.
It turns out that the bad data was actually caused by integer fields, that everybody had assumed were decimal fields.  Now, when you unload data files, most people just use the standard isload/fconvert (or Convert on OpenVMS) to generate a sequential file, which works great for Synergy alpha and decimal fields, but when you have integer (aka binary) fields, regular sequential files no longer “cut the mustard”.  One of the issues you have to deal with is this.  If you have an integer field that contains the value 13, (aka a Carriage Return character) in a sequential file, the operating system assumes that it’s an end-of-record character and treats the record as truncated.  So now the next part of the same record is now treated as a new truncated record, and you have two “bad” records in the file, instead of one “good” one.
The way to resolve this class of issue is to use a “counted” file.  This is a special form of sequential file where the length of the record is included with each record, so when re-loading data, the application knows how many characters there are in the record, and it will ignore any “spurious” control characters in the middle of the record.   Job done, you would think, but no.  Being OpenVMS it wasn’t as simple as that, as we also had to use the OpenVMS Convert utility to change the sequential file into a stream file, so we can preserve the file as a counted file after it was FTP’d to Windows.

With Synergy version 9, the language supports several new data types (e.g. boolean, enum) which are really integer fields, so if you start to store these new data types in your Synergy DBMS files, you need to start using counted files, instead of regular sequential files when loading/unloading data.  Fortunately, (in this case) both OpenVMS and Windows are little endian systems, so there was no issue about changing endian type, but this is something that you may need to consider, should you consider moving integer data between systems.
Now, to come back to the topic I started with of “attending conferences” (and to issue a shamless plug), if you come to the 2011 SPC in Chicago or Oxford, you’ll be able to hear all about managing binary data in Synergy DBMS files.

Hope to see you there.


Free Stuff!

By William Hawkins, Posted on March 14, 2011 at 2:46 pm

Avatar

It’s a rare occasion where anything is truely free. Most of the time it’s simply a way for a marketing company to obtain information about you, so they can provide (or bombard) you with information about products that you have no interest in purchasing. However, there are some occasions when “free” really does mean that there’s no additional cost. The Synergex CodeExchange is (IMHO) one of those gems.
In may last blog, I discussed the process of validating a large number of the CodeExchange submissions with Synergy 9.5 and Synergy for .Net. In this blog, I want to highlight a couple of new submissions that you may find useful.

SynArrayList – this submission contains a couple of subroutines that allow you to sort an ArrayList in Synergy, either using a bubble sort or dynamic memory/qsort. You probably won’t need to use both methods of sorting, but they provide code examples to allow you to create custom sort routines of your own. This submission also contains an example of extending the ArrayList class, and creating a new class that processes Synergy alpha types natively.  This allows you to avoid the requirement to box/unbox your alpha variables as you process a collection.  Of course, the underlying arraylist still requires object types, but you don’t have to be concerned about that. And it has sort() and reverse() methods and some other ArrayList method that are part of the ArrayList class in .NET

SourceTree – this submission builds a utility that will parse your source code, and generate a data file that records the subroutine/functions in your application that call other subroutines/functions.  This allows you to create documentation on where routines are used in your application.  It can also be used to generate a list of routines called by a particular subroutine/function/mainline and all the routines that are called by those routines.

I’m also working on some other CodeExchange submissions – examples include a file I/O class and a utlity to create the xfNetLink attributes that can decorate your code.  Watch this space!!!


Mapped drives and Synergy

By Roger Andrews, Posted on January 31, 2011 at 4:27 am

Avatar

Some recent posts on our synergy-l listserv made me realize there are still some misperceptions about Microsoft network shares (mapped drives), so I thought I would address those here.

Microsoft designed network shares for single-user access to shared resources such as Word documents. The locking and caching algorithms they use assume that a local cache is desirable since multiple users are unlikely to do concurrent updates (though the algorithms try to cope with this situation). Of course the use of network shares has grown to much more than single-user systems. Many of our customers have used them and are still using them, and many of these customers have unfortunately encountered performance and file corruption issues. Most of these issues are associated with concurrent updates and cache flushing, and using mapped drives (as opposed to UNC paths) seems to exacerbate the problem. With older Windows versions–prior to Vista and Server 2008–you can mitigate file corruption issues by disabling oplocks on the server (which disables the local caching). (Syncksys, a utility we used to check settings on these older Windows systems, always checked for this.) Unfortunately, you can’t disable oplocks with SMB2 redirectors on the newer Windows systems.

Because of the number of issues our customers have encountered, Synergex can provide only very limited support for Synergy database access through network shares. (See the Synergex KnowledgeBase article listed below.) We have traced these problems to errors in the Microsoft SMB (mrxsmb10.sys, mrxsmb20.sys, mrxsmb.sys) and Redirector (rdbss.sys, srv.sys) subsystems.  We find that these problems get worse with network shares over a WAN and with multi-user access. It is fair to say that Microsoft has fixed many problems with Windows XP and Server 2003 over the years, but the problems have resurfaced with newer Windows operating systems. And now many organizations are using Windows Vista and Windows 7 machines as clients (alongside their Windows XP clients) to Server 2003 or Server 2008 servers, introducing newer operating systems with mapped drive subsystems that have regressed in functionality and performance.

Here is a great link to a Microsoft article for the latest hot fixes available for the network share subsystem: https://support.microsoft.com/kb/2473205 (for Windows Vista onwards)

https://blogs.technet.com/b/yongrhee/archive/2011/06/12/list-of-post-sp3-related-hotfixes-for-windows-xp-sp3.aspx (Windows XP)

Synergex has published the following KnowledgeBase article on the subject of network shares: https://resourcecenter.synergex.com/devres/kb-details.aspx?id=1811

This same information (from the KB article) was also published as an article in the 26 August 2010 edition of Synergy-E-News: https://www.synergex.com/ecards/20100826.html#mapped

We recently (and mistakenly) used a mapped drive internally for a project, and the ISAM files for the project were continually corrupted. (We have logged a premier support call to Microsoft for this issue.) We fixed the corruption with the recommended solution, xfServer, which not only solved the issue but improved performance.

File corruption issues aside, in most cases xfServer will significantly outperform a mapped drive in commercial situations with multi-user access when it’s set up to correctly use SCSCOMPR and SCSPREFETCH in conjunction with correctly opening files for input when just reading data sequentially. The known cases where xfServer is slower than a mapped drive is when a file is opened for update with a single user or exclusive access, or for output when the file is not large and/or the records are small (or ISAM compression makes them small), allowing the redirector to cache the data blocks locally. If oplocks are turned off on Server 2003, as recommended, this caching is disabled and performance degrades, though reliability increases. We are investigating an xfServer performance improvement that would provide comparable or better performance than a mapped drive in additional scenarios by allowing users to enable the cache on stores and writes to a file opened for output, append, or exclusive access.

We have provided a test utility in CodeExchange, IsamBenchMark, to help you test performance with your own physical files and network.  Using this utility, we saw the results described below.

The following tests were made on a Windows 7 machine connected to another Windows 7 machine over a 1 GB network. The machines each had 6 GB of memory and Core 2 3GHz CPUs. The Windows operating system cache was flushed using the Sysinternals CacheSet utility before each run on the server machine. Neither machine had an antivirus program running or any other software that accessed the network. Both machines were connected on the same physical switch.

Two files were used: one with eight keys and 128-byte records and the other with eight keys and 512-byte records. Each file was filled with 100,000 records during the test, and the files were created without ISAM file compression. We used Task Manager’s networking tab to generate the diagrams below (though we’ve added red vertical lines in one diagram).

Diagram 1 shows network overhead for our first test, which used xfServer to access the file with 512-byte records. The file was first accessed without compression and then with compression (i.e., with SCSCOMPR set). 

 

Using 4-5% of a gig link is equivalent to 50% of a 100 MB Ethernet, so the performance gained by setting compression for xfServer would be even greater on a slower Ethernet or WAN.

Diagram 2 shows network overhead for our second test, which accessed the 512-byte-record file in three ways:

  • via a mapped drive
  • using xfServer without compression
  • using xfServer with compression and READS prefetch support enabled (i.e., with SCSCOMPR and SCSPREFETCH set)

The test program stored 100,000 records, re-opened and used random read for 100,000 records, re-opened and used reads for 100,000 records. Note the change in scale from the previous diagram, and note the overhead of the stores is high (with the flush-on-close peaking with the mapped drive). The next segment is the random read, and then the next peak is the reads. Also notice the setup with SCSCOMPR and SCSPREFETCH makes the reads almost as fast as a local disk access and far faster than the mapped drive.

 

If this had occurred over a slower network, the stores would be slower on a mapped drive than xfServer and the SCSCOMPR form would outperform all other methods, given records with some degree of compression. If you have an ISAM file with ISAM compression, isutl –v can give you an idea of how much compression of the data can help with xfServer.

Diagram 3 shows network overhead when accessing the file with 128-byte records in the same three ways (mapped drive, xfServer without compression, and then xfServer with compression) and with the same program.

 

Diagram 4 shows the network overhead for… Well, there is no diagram 4. Our final test used two systems each with the remote 512-byte-record file opened on the network share. One just had the file open. The other ran the test. This setup used 50 MB of bandwidth constantly for several minutes, so the diagram would run off the page and would show only a pegged green line. Instead, here’s a table that summarizes our findings. The last row documents the results for the multi-user mapped drive setup and illustrates how much worse things get when using a mapped drive in a multi-user environment. Bandwidth is quickly overloaded, and it becomes difficult and time consuming for the network to accommodate large groups of packets. As pointed out earlier, these tests used a physical switch. xfServer becomes even more important when the network involves a hub.

 

Store
(in seconds)

Random read
 (in seconds)

Reads
(in seconds)

Mapped drive 1user

21

7

4

xfServer no SCS_COMPR

24

24

2

xfServer SCS_COMPR

21

20

.90

Mapped drive 2 user

882

193

32

One final thing to be gleaned from this is that running programs that transfer large amounts of data across a network, programs such as month-end or day-end processing or reports, can quickly overload a network. Do what you can on the server by using xfServerPlus, the new Synergy Language Select class, or by running the program on the server.

If your xfServer system is not performing in line with the results described above, I encourage you to contact our Developer Support team so we can assist you in optimizing your system. If you have questions or would like more information on this topic, contact Synergy/DE Developer Support or your account manager.

On this topic, a customer recently reported an ELOAD/System error 64, “The specified network name is no longer available.” When they changed the UNC path to use the IP address rather than the name of the machine, the problem appeared to be resolved. This would suggest poor DNS server performance lookups was causing the error. It appeared the problem was disconnecting client machines on the network, as well as the recovery mechanism used by the re-director after such a failure. In the recovery mechanism, it appears DNS must also work. The problem with DNS is that Microsoft caches “Failures” of DNS, so one failure can cause other issues.

 


The Final Chapter

By Richard Morris, Posted on December 17, 2010 at 6:00 am

Avatar

Using Synergy in all aspects of a new WPF based development is really quite exciting.  But when you start to bring in code that was written many years ago you really begin to see the power of a truly cross platform capable development environment.

The task I started while working with White Knight was to create a simple application that managed the communications with their customer base – basically a very simple CRM system.  The brief was to have a great looking windows desktop application and write it in Synergy – oh, and use all their existing library routines, data layout include files and database files.

And the solution, if you’ve followed my earlier blogs, was to utilise the new 9.5 release of Synergy.  With Synergy 9.5 we have the Visual Studio Integration which, in a nut shell, is Synergy language inside the powerful Visual Studio development environment.  Using this environment we can craft our user interface utilising WPF controls and Synergy language to bind to our data classes.  So, that’s the UI sorted.

Using the Synergy .NET API I can continue to use my existing Synergy language routines to load my new WPF UI Library, and manage the data communication between my program and the UI controls using WPF’s powerful data binding techniques.  So that’s the existing program logic and data access sorted.

And the results:

A fully functional UI, all written in Synergy and XAML (the WPF portion of the UI) managing our SDBMS data and Synergy business and validation logic. 

So what about your application?  If it’s in need of a bit of a user interface upgrade, download the latest 9.5 release of Synergy and let your imagination run wild.  You’ll be surprised just how much you can do in a short space of time. 

As we head towards the end of 2010 we’ve already started our plans for SPC2011 – watch this space for details!  I’m really excited about the prospect of presenting these great new capabilities that Synergy offers.  I can’t believe how quickly this year has gone by.  I hope you all have a great holiday season and here’s to a bright WPF New Year!


The .NET Rollercoaster

By Richard Morris, Posted on November 24, 2010 at 1:28 pm

Avatar

Sometimes my job feels like I’m on a rollercoaster with some great highs and some scary lows, and the adrenaline rushes between the two. Version 9.5, complete with the Visual Studio integration with Synergy, was officially released yesterday. I’m sure I was not the first one, but I was straight to the resource centre at www.synergex.com to download and install 9.5. The installation went without issue and we were ready to begin to build our CRM application.

The first task was to rebuild our existing Synergy routines using the Synergy 9.5 DBL compiler. This new version has tightened things up even more and the compiler found another subscripting error which was duly fixed! Things were looking great – the rollercoaster car was slowly making its assent.

The next step was to build our Visual Studio projects and run the new CRM application. The builds completed and the car was teetering on the brink. But what goes up must come down. With that stomach in the mouth feeling the car came spiralling down from the dizzy heights. Our CRM didn’t run quite as we’d hoped. Now don’t get me wrong. I’m extremely impressed with the release of 9.5 and the integration with Visual Studio. Just the ability to build code written when Bill Gates was a lad in this environment is testimony to the strength of Synergy. But this is a brand new release and I’m pushing it to the limit. This is no “Hello World” development!

Now the customer wants a new CRM, and I’m determined to complete the job using Synergy. And so a new plan was hatched. Why can’t we use Synergy/DE and Workbench to build the program to host our new UI? We can use the .NET API to achieve this, and we know all the existing routines work because they have been executing the code for years. So straight away we have half of the application in Synergy, written and working. Given that the problems we were having with the Visual Studio side of 9.5 centred on arrayed fields, changes that have been made to the way error trapping works, and the debugger, why not build our WPF UI using Synergy. And this side of the Visual Studio integration worked for us all day without issue. Building simple class files to expose our Synergy data as .NET types was a breeze with the code snippets available. Some of this code could, I guess, be code generated, but to be honest generating code can strangle the flair of the developer. Plus we only wanted to expose selected fields and manipulate the format of the data to suit our needs.

We soon had our data classes built and the application was returning data ready to expose to our new WPF UI. And this is our task for tomorrow. The car is well and truly back on track and heading for the exciting twisty section of the ride. And I’m still only programming in Synergy. There is not a single line of C# or VB.NET!

So, should you wait before you try 9.5? Certainly not! Download it, install it, and start to build not only your code but your dreams of that new slick looking application – and all in Synergy. I’ll post the results of all our hard work at the end of the week. Please keep all hands and feet within the car and hold on tight to the hand rail. You’re going to love the ride!


.NET is a blast

By Richard Morris, Posted on November 23, 2010 at 3:19 pm

Avatar

One great aspect about my job is not only helping people utilise Synergy to the full, but to see the results of their hard work. And there is no better place to do this than “at the coal face”. Today’s coal face is, of course, on the shop floor at White Knight laundry. I was given a guided tour after lunch to see just how the Synergy system tracks items through the process.

The washing machines are huge, several feet taller than me. I shudder to think just how many pairs of socks you can wash within one of them, and they have several, all lined up together. It’s no wonder they have to tag every single item. Once items are cleaned they are dried in large driers and then the cool automation happens. Sheets are taken out of the dryers and each is laid out in turn at one end of a machine. If you are quick enough and sprint around to the other side of these large machines out pop a beautifully pressed and folded sheet. The shirt press is a blast, literally. It’s a two stage operation. Firstly the collar and cuffs are placed onto a machine and pressed. Then the shirt is placed over a frame, then it’s whisked off and steam blasted through it, and out comes a perfectly pressed shirt fit for a king.

And so to our CRM development. Our first task was to build the White Knight core routines into a native .NET assembly, which is the equivalent of an executable library. This task was achieved within a couple of hours. After all, it’s the same Synergy Language just a new compiler. The current system runs under Synergy version 8.3 and this code, I would say, hasn’t changed much since version 5.9 days. It’s testament to the power of Synergy to be able to take this code and build it under a brand spanking new development environment called Visual Studio 2010! To successfully build the new assembly required a few code changes. The compiler caught parameter mismatch declarations and some over subscripting. All the modifications we made improved the stability of the code.

We are now ready to begin to integrate our tried and tested logic with our new WPF UI. But there is a little more work to do first. Our data is a little shy and we need to gently coax it from the dark depths of our SDBMS files. Remember, some of this data was written away to the file a long time ago and those little single alpha character chaps that store our Y or N values work just fine in Synergy land, but for WPF we need to coerce these values to native types. So we are writing some very simple classes that take our Synergy records and expose only the fields our UI will be interested in as native .NET types.

Now we are building the WPF interface and binding to our new Synergy classes, exposing our existing Synergy data…


Taking .NET to the cleaners

By Richard Morris, Posted on November 22, 2010 at 2:23 pm

Avatar

Ding dong, “Laundry service”! Now you could be mistaken for thinking that I’m staying in a rather nice hotel, being called upon by the maid for my dirty laundry. Not so, I’m afraid, I’ll be taking my dirty ‘smalls’ home with me. But for one of our customers, this is their calling card. The customer is White Knight, based near London and their business is laundry, run by Synergy.

It’s true. People and many of them are well known celebrities, have their laundry collected every Monday and returned within a few days, cleaned dried and perfectly ironed. Some ten thousand “items” pass through the machines at this site and this is a small site. Their other sites handle in excess of two hundred thousand articles every week.

To manage this workload across all sites is a suite of Synergy programs running on a Linux machine. Traditional character based systems handle all aspects of the process from collection, cleaning through to delivery of the right items to the correct customers.

But things don’t always go right. So when the customers call in and say “you’ve washed the spots off my favourite pair of shorts” it all needs to be recorded and processed. This calls for a CRM (Customer Relations Management) system. And here is where I enter the story. White Knight has invited me down to assist them to begin to write a fully functional CRM system in Synergy. They want a Microsoft Windows desktop application with all the bells and whistles with access to new and existing Synergy data and logic. Easy!

So today we hatched a plan. Graham from White Knight was fully prepared for my visit with a functional specification, data layouts and design utilising xfServerPlus. “But for a desktop application?” I asked. “Why are we not using WPF (Windows Presentation Foundation) and .NET?” Because I’m not strong with C#, I know enough to do my web site!” Graham replied. Well, given the imminent release of Synergy v9.5 and the integration of Synergy Language within Microsoft Visual Studio 2010 it would be a perfect candidate. We’ve created our Visual Studio projects and begun to define our WPF User Interface in XAML. Our existing Synergy routines are being imported into a new class library project and we are crafting Synergy classes to facilitate the communication between our application elements. For those of you at SPC 2010 you’ll recognise this as the Model-View-ViewModel pattern!

And how did we do? Well I’ll update my blog over the next few days of how well we do, writing our first Synergy for .Net application…..


Dig into Synergy/DE 9.5 – Using CodeExchange

By William Hawkins, Posted on November 19, 2010 at 12:46 pm

Avatar

Like many of you, I’ve been waiting with bated breath for the release of Synergy/DE 9.5, and the general availability of Synergy .NET. The development team has been working on this project for a few years (I’m sure it seems like longer for them). But it wasn’t until the beta release earlier this year, that it became something with which you could actually start to write code that really did something useful. Those of you who were at the SPC a few weeks ago had an opportunity to use Synergy/DE 9.5 to develop a WPF application that used Synergy for all the (non-XAML) code in Visual Studio 2010.

As part of the beta testing effort, I’ve been using and updating code that has been submitted to the CodeExchange, and I thought I’d share what I did. Hopefully you can leverage the modifications that were done to the CodeExchange items to help with a possible migration to the .NET environment.

In order to make my life easier, I created a folder C:\Development\CodeExchange and deposited all of the CodeExchange submissions that were created by Synergy PSG, into subfolders.

Phase 1 Test the code in traditional Synergy 9.5.

As I knew I’d be doing a lot of test builds, I wanted to use the project build system built into Workbench (in Synergy/DE 9.3). So I created an empty workspace, and added all the Workbench projects that were in the subfolders. For those projects that didn’t have a Workbench projects, I created one, and for the few projects that didn’t have a mainline program, I created one of those too. Most of the time spent in this phase was in setting the Workbench build environment. As you would expect, the code didn’t require much (if any) modification.

Phase 2 Test the code in Synergy .NET 9.5.

When taking the CodeExchange submissions and building them in Visual Studio, it turned out to relatively easy. In order not to “pollute” the standard CodeExchange folders with Visual Studio “stuff”, I decided to create a separate folder for Visual Studio project. This was C:\Development\CodeExchangeVS, and under this folder is a subfolder for each submission – just like the Workbench folders. Inside these subfolders are a Visual Studio solution and a Synergy project. The Synergy project contains references to the code in the Workbench folders, so that I can use the same code in both places. If you just add a source code file to a Visual Studio project, what you’re really doing is copying the file to the project folder, but all Add Reference does is point the project to the appropriate source file. Now that I have a Visual Studio project, it’s just a matter of hitting the F6 button to build my application. If only it were that simple…..

When building the CodeExchange code in Visual Studio, the code falls into a number of different categories;

1) Requires no/minimal changes

2) Uses features (functions/subroutines) that are not supported

3) Needs recoding

4) Uses features (APIs) that are not supported

Again, most of the code fell into the first category, as it had already compiled using the traditional Synergy compiler. One thing that fell into the “minimal changes” category was the introduction of a logical to point to an include folder (usually the same folder as the source). As Visual Studio was using sources from a different folder, we could no longer rely upon the include file being in the “current folder”. For the purposes of CodeExchange sources, wherever a logical is required to access an include file, the source will use INC:

Also, there was very little code that required recoding – this was almost exclusively required by the use of %DLL_CALL(), which needed to be changed to %DLL_NETCALL(). The coding change was relatively straightforward. (See example below.)

.ifdef DBLNET

begin

argArray = new object[2]

argArray[1] = (object)^addr(spec)

argArray[2] = (object)^addr(WIN32_FIND_DATA)

srch_hdl = %dll_netcall(dll, DLL_TYPE_WINAPI, ‘FindFirstFileA’, argArray)

end

.else ;DBLNET

srch_hdl = %dll_call(dll, DLL_TYPE_WINAPI, “FindFirstFileA”, ^addr(spec), ^addr(WIN32_FIND_DATA))

.endc ;DBLNET

The bulk of the changes needed were mostly to deal with unsupported or not yet implemented features. I first started this project in Feb/Mar 2010, and as time progressed, the number of issues grew significantly smaller as the Synergy development team implemented features omitted from the early betas. At the time of writing, the unsupported features that got caught by the compiler are the use of HTTP_SERVER, %SS_FATAL() and W_CAPTION(). Another problem feature is the use of UI Toolkit. While there is a version of UI Toolkit that you can use when you build using Visual Studio, it’s not a complete implementation. The UI Toolkit provided with Synergy .NET is primarily aimed at allowing UI Toolkit code to be used with xfNetLink .NET and/or .NET interop projects – which are projects that do not use UI Toolkit for the User Interface. If you actually run the application and call a UI-related Toolkit routine, a runtime error will be thrown. For all the projects that used UI Toolkit, I added a try-catch around the entire application, so that I can catch any errors thrown by UI Toolkit. From a CodeExchange perspective, use of UI Toolkit is the main item that falls into the fourth category. The RCB API is another example of an unsupported feature in Synergy .NET.

One difference between traditional Synergy and Synergy .NET, is that there is no “stop message” dialog. “Hurrah!” I hear a lot of you say. Me too. However, with the CodeExchange submissions, most of the test programs are console applications, and now that there’s no stop message, when they complete, the application goes away too. This doesn’t give you much time to read the screen. So I wrote myself a little StopMessage routine, and added it to every application that needed it. As it turns out, this change was by far the largest change that I had to do.

Along the way, we’ve also enhanced some of the submissions; for example, the StringUtil submission is now more functionally rich, and we also added some new submissions (e.g., isamBenchmarks, GetDirFiles, memProc, POP3mail and SelectExample). There is also a new submission CodeExchangeVS which contains all the submissions below, plus the Workbench workspace with all the Workbench projects and all the Visual Studio solutions.

Here are the CodeExchange submissions that are included in the CodeExchangeVS download;

addSourceControl, ASCIIEncoding, axlsort, Base64, Base64_convert, BatchFileConversion, COPY_HANDLE, creditCard, DateTime, DTKproto, dtk_i_enable_set, dtk_list_multi_select, FileLocks, FindNPchars, FixData, GetDirFiles, GetWindowSize, HTTPexample, HTTPqueryString, iConvert, IsamBenchmarks, isHoliday, ismKey, ismSts, lct_lmf, LicensingToolkitExample, ll_accept, memProc, PartialMatch, POP3mail, Registry, RemoteServer, rfa_hex, rpschk, rpssql, rpsxdl, rpsxml, SelectExample, SMTPmail, SocketExamples, StringUtil, synckodbc, SynPsg.Rps, UpsTrack, url_encode, uspsWebService, WinDir, xfnl_synergy, xfplini, xfpllog, xfspism2xml.

Also, one final change. At the request of Synergy/DE Developer Support, each submission includes all the code required to rebuild the application. Previously, some CodeExchange submissions required you to download other CodeExchange submissions.

If you’re using any of the CodeExchange items above, I would recommend that you download the updated version. Synergex PSG is constantly looking for new opportunities to enhance the CodeExchange code submissions, so if you have any suggestions for new items, please let us know.

A Synergy/DE 9.5 RC (release candidate) is available now, and the general release should be available soon.


Burned again!

By William Mooney, Posted on August 30, 2010 at 2:20 pm

Avatar

I’ve just been burned again by a third-party application that doesn’t integrate with Office 2010. To the bane of our IT department, I’m constantly upgrading to the latest and greatest version of everything—the latest being Office 2010. [Note to our ISVs:  I’m like that customer who makes you cringe when he/she calls… ;)] And while I really, really, really love Office 2010, it just doesn’t integrate well with the applications I use, almost negating all of its benefits. My first productivity loss came when my emails to customers weren’t automatically going into our CRM app.  I am not the only one who is just blown away that this major player in CRM does not support Office 2010—and is not expected to until later this year! Next came our VOIP telephone system, which, when integrated with Office 2007, practically eliminated the need for a telephone handset. Office 2010 has brought me back to the hand set, and I just learned it will be at least another 6 months before our phone system supports Office 2010!  So much for keeping current.  I was so excited to use a 64-bit program, but what’s the point if the apps I use don’t work with it?

Perhaps I am overly sensitive to this issue because it has always been so important to us to support new versions of third-party products before our customers need them. I recall several years ago when Roger Andrews, our Synergy/DE Architect, was urging us to prepare for native 64-bit support. I thought at the time that we were way too early in the game. But, as it turned out, we were just in time. We work diligently to keep up with current hardware and operating systems so our customers can plan and anticipate the needs of their users. The proliferation of 64-bit systems has actually caught many of our customers by surprise. While 64-bit systems have been out for several years, the O/S support hasn’t always been there. That’s not the case today. Today, customers (like me!) are expecting 64-bit hardware, 64-bit operating systems, and 64-bit applications. They view anything less as inferior. Many of our customers are now catching up. This brings me back to my Office 2010 dilemma. While I’m benefitting from the substantial application enhancements and incredible performance enhancements of a native 64-bit program, I am losing several productivity tools that don’t yet support Office 2010. Almost defeats the purpose of upgrading.

I’m sure that there have been cases where we have not been ahead of the game, but I’m appreciative of the effort we make to anticipate the requirements of our users, often before they even request them. My personal experience has really brought home the point that the best, shiniest product in the world doesn’t matter too much if the software you want to use doesn’t run on or with it. Lesson learned: keep your software up to date so your users don’t get burned like I did!

P.S. I still can’t believe Adobe has not released a 64-bit version of Flash on Windows — argghhhhh


Mr Numpty’s hair stood on end. It must be the static!

By Richard Morris, Posted on August 26, 2010 at 8:09 am

Avatar

One fine day (well, it was raining – it is the UK after all), not too long ago (yesterday), there was a man called Mr Numpty (names changed to protect the innocent).  Mr Numpty was a seasoned Synergy developer and wrote Toolkit applications in his sleep (amazing what Workbench can do for you these days).

This one day, Mr Numpty was browsing the spc.synergex.com web site for the early bird registration form when suddenly his big red support phone rang.  It has a unique ring tone and a strange light appears in the sky, which can be easily seen on the lovely grey storm clouds forming outside his window.  Mr Numpty says to himself “this must be very important” and reaches for his cloak.  Picking up the phone, a rather bemused voice, which he recognises immediately as his uncle, ‘Uncle Joe’, says;

“Numpty my man, things they be strange. My list is looking great, but my data’s in a rage.”

“Is it the new product browser?” asks Mr Numpty.

Uncle Joe replied;

“It is indeed, that’s the one.  ‘Been using it all day, ‘cos it’s so much fun.  The windows are great, and the tabs are a hit.  But when I print, the results are not that great!”

“OK Uncle Joe I’ll take a look” replied Mr Numpty.  He looked through the code but could not see any errors.  He ran the program, and clicked on the tab.  Uncle Joe was right.  The list looked great with all the right data.  Printing from here worked also and the results were fine.  Confused, Mr Numpty pondered and scratched his head.  He scratched so hard his hair stood on its end. From the corner of his eye he caught sight of himself in the mirror.  Wow he thought. My head looks funny. I must be fully charged with static!

Ping!  Suddenly he remembered a dim and distant UI Toolkit training course, and the voice of a PSG consultant began to haunt him… “Remember the golden rule: The list processor first updates the current non-window data area, processes the request, then returns the current non-window data!”  So something must be corrupting my non-window data, but only sometimes. 

Taking a closer look at his list routine he noticed his problem.  The data being passed to the list processor was defined as ‘stack’.  This means that each time the routine is called the data area is created, and the contents undefined.  Calling the routine for the first time creates the list, which is correctly loaded from the load method.  By clicking on other tabs means we leave the list routine.  Clicking back on the tab containing the list causes the list record area, defined as stack data, to be created with the contents undefined.  When this is then passed to the list processor the non-window data will be updated with this undefined data.  Visually, everything will look fine, but the data used by the program will be corrupted.

Taking inspiration from his static hair style, Mr Numpty changes the record declaration to ‘static’ and his program now fully works.  He updates Uncle Joe’s computer.

“Numpty my man, it all looks swell.  Now can we filter and sort the columns as well?”

Mr Numpty thought for a moment, “I’m not sure how to do that, but it sounds like a great idea.  Now where was I?”  Mr Numpty continues to complete the spc.synergex.com early bird application form, wondering if this year’s conference will give him the knowledge to give his uncle the features he wants.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives