Open Menu

Synergex Blog


Old Dog … New Tricks … Done!

By Steve Ives, Posted on June 3, 2015 at 3:59 pm

The old adage tells us that you can’t teach an old dog new tricks. But after the last three days, I beg to differ! It’s been an interesting few days for sure; fun, challenging, rewarding and heated are all words that come to mind when reflecting on the last few days. But at this point, three days into a four-day engagement, I think that we may just have dispelled that old adage. For one this “old dog” certainly feels like he has learned several new tricks.

So what was the gig? It was to visit a company that has an extensive application deployed on OpenVMS, and to help them to explore possible ways to extend the reach of those applications beyond the current OpenVMS platform. Not so hard I hear you say, there are any number of ways of doing that. xfServerPlus immediately comes to mind, as do xfODBC and the SQL Connection API, and even things like the HTTP API that could be used to allow the OpenVMS application to do things like interacting with web services. All true, but there was one thing that was threatening to throw a “spanner (wrench) in the works”. Did I mention that the application in question was developed in COBOL? That’s right, not a line of DBL code anywhere in sight! Oh and by the way, until about a week ago I’d never even seen a single line of COBOL code.

Now perhaps you understand the reason that challenging was one of the words I mentioned earlier. But I’m up for a challenge, as long as I think I have a fighting chance of coming up with something cool that addresses a customers needs. And in this case I did. I didn’t yet know all of the details, but I figured the odds of coming up with something were pretty good.

Why all of this confidence? Well, partly because I’m really good at what I do (can’t believe I just said that), but seriously, it was mainly because of the fact that a lot of the really cool things that we developers just take for granted these days, like the ability to write Synergy .NET code and call it from C#, or write VB.NET code and call it from Synergy .NET, have their roots in innovations that were made 30+ years ago by a company named Digital Equipment Corporation (DEC).

You see OpenVMS had this little thing called the Common Language Environment. In a nutshell this meant that the operating system provided a core environment in which programming languages could interoperate. Any language that chose to play in that ball park would be compatible with other such languages, and most languages on OpenVMS (incuding DIBOL and DBL) did just that. This meant that BASIC could call FORTRAN, FORTRAN could call C, C could call PASCAL and … well you get the idea. Any YES it means that COBOL can call DBL and DBL can call COBOL. OK, now we’re talking!

So why is this such a big deal? Well it turns out that Digital, later Compaq, and later still HP didn’t do such a great job of protecting their customers investments in their COBOL code. It’s been quite a while since there was a new release of COBOL on OpenVMS, so it’s been quite a while since OpenVMS COBOL developers had access to any new features. This means that there isn’t a way to call OpenVMS COBOL routines from .NET or Java, there isn’t a way for OpenVMS COBOL code to interact with SQL Server or Oracle, and there isn’t an HTTP API … so don’t even think about calling web services from COBOL code.

But wait a minute, COBOL can call DBL … and DBL can call COBOL … so YES, COBOL CAN do all of those things … via DBL! And that fact was essentially the basis for my visit to Toronto this week.

I’m not going to get into lots of details about exactly what we did. Suffice it to say that we were able to leverage two core Synergy/DE technologies in order to implement two main things:

  1. A generic mechanism allowing COBOL code executing on OpenVMS to interact with Windows “stuff” on the users desktop (the same desktop that their terminal emulator is running on).
  2. A generic mechanism allowing Windows “stuff” executing on the users desktop to interact with COBOL code back on the OpenVMS system.

The two core technologies have already been mentioned. Outbound from OpenVMS was achieved by COBOL calling a DBL routine that in turn used the Synergy HTTP API to communicate with a WCF REST web service that was hosted in a Windows application running in the users system tray. Inbound to OpenVMS was of course achieved with a combination of xfNetLink .NET and xfServerPlus.

So just who is the old dog? Well as I mentioned earlier I probably fall into that category at this point, as do several of the other developers that it was my privilege to work with this week. But as I set out to write this article I must admit that the main old dogs in my mind were OpenVMS and COBOL. Whatever, I think that all of the old dogs learned new tricks this week.

It’s been an action packed three days but I’m pretty pleased with what has been accomplished, and I think the customer is too. I have one more day on site tomorrow to wrap up the more mundane things like documentation (yawn) and code walkthroughs to ensure that everyone understands what was done and how all the pieces fit together. Then it’s back home on Friday before a well deserved vacation next week, on a beach, with my wife.

So what did I learn this week?

  1. I really, really, REALLY don’t like COBOL!
  2. OpenVMS was WAY ahead of its time and offered LOTS of really cool features. Actually I didn’t just learn this, I always knew it, but I wanted to recognize it in this list … and it’s MY BLOG so I can Smile.
  3. Synergy/DE is every bit as cool as I always believed; and this week I proved it to a bunch of people that had never even heard of it before.
  4. New fangled elevators are very confusing for old dogs!

Breaking News … a New Life for OpenVMS?

By Steve Ives, Posted on July 31, 2014 at 4:15 pm

It seems like there is new hope for those organizations still running OpenVMS, after HP recently announced a partnership with a company called VMS Software Inc. (or VSI). There is now talk of adding support for Intel’s Itanium “Poulson” chips by early 2015, as well as the upcoming “Kittson” chip. There is talk of new versions of OpenVMS, and even mention of a possible port of OpenVMS to the x86 platform.

More information here:

http://www.computerworld.com/s/article/9250087/HP_gives_OpenVMS_new_life


Using Workbench to Build Applications on Remote Servers

By William Hawkins, Posted on February 18, 2010 at 4:21 pm

I recently went to a customer site, to help them integrate Workbench into their OpenVMS development environment.  As a source code editor, the “integration” is relatively simple, you just need to have NFS/CIFS/SAMBA installed, and use it to make your OpenVMS (or UNIX) drives look like they’re actually Windows drives.  However, when you want to compile or link your application, you either need to go back to your telnet window and build it there, or you can download the RemoteBuild utility from the SynergyDE CodeExchange.  There are two versions for OpenVMS out there right now, both provided by Chris Blundell from United Natural Foods Inc.

Synergex PSG decided that we wanted to provide a remote build facility that could talk to multiple environments using information from a single Workbench project.  We wanted to minimize any potential firewall issues (for companies that have internal firewalls), and we also wanted to build on the SynPSG.System classes (distributed with ChronoTrack – our SPC 2009 demonstration application) for the network communication.  For those of you unfamiliar with the SynPSG.System classes, they are a partial implementation of the Microsoft System classes written in Synergy, (so they work on all supported platforms,) but when we have Synergy for .Net available, we'll be able to use the native .NET framework System class without modifying code. (ok, we'll have to change the import statements, but that should be all.)

So PSG has posted our flavor of a remote building application into CodeExchange – it's called remoteServer.   There is a client component to install into Workbench, and a server component (written in Synergy) that runs on each development server.  If you have both SAMBA (or equivalent) and remoteServer installed and configured, you are able to compile your application on the remote system, and in the unlikely event of a compile error (I know, you never have any coding errors) you will be able to double click on the error on the output window, and go straight to that line of code in the source file on your remote server.

If you work in a multi-platform development environment, I would encourage you to go download any of the remote build offerings in CodeExchange, and start using the power of Workbench to help improve the productivity of your developers.


What’s in my library?

By William Hawkins, Posted on February 4, 2010 at 4:22 pm

The obvious answer that springs to mind is "books", but some may respond "what sort of library?".  Of course, in this context, I'm really referring to a library containing Synergy object code. 

When referring to Synergy subroutines and functions, on both Windows & Unix, you can perform a "listdbo" or "dblibr -t" on the object file/object library and peruse the output to see the names of your routines.  However, when referring to methods (in classes/namespaces), the name used is mangled.  This mangling process takes the fully qualified name of the method, the return type, and all the parameter types, and reduces it down to a mangled name.  In a lot of cases, you can look at the mangled name and stand a chance of actually recognizing the name of the routine, but decoding the parameters in your head may require the use of illegal drugs.

For example, if you see a mangled name of '7SYNPSG5CORE11UTILITIES3CC6SYNCC11GETCCNAME_O7SYSTEM7STRINGI', you could intuitively see that it's probably this routine: 'SYNPSG.CORE.UTILITIES.CC.SYNCC.GETCCNAME(I)@SYSTEM.STRING'. 

But what about this one: '7SYNPSG5CORE11UTILITIES3CC6SYNCC11GETCCNAME_O7SYSTEM7STRINGSP0P1P2P39CARDTYPE'?  It’s the "same" overloaded routine, but it has a SYNPSG.CORE.UTILITIES.CC.CARDTYPE parameter instead of an integer parameter.  Similarly, if you saw '7SYNPSG5CORE11UTILITIES8WORKING9SHOWFORM_XO7SYSTEM7STRING', you could probably see that it's 'SYNPSG.CORE.UTILITIES.WORKING.SHOWFORM(@SYSTEM.STRING)'.  Now, what if you saw this '7SYNPSGCR1UTLTESWRKNGSHW9HTGB13'?   Well, it's surprisingly the same SHOWFORM method, but it's been mangled beyond recognition.  The term used here at Synergex is "crushed".  In fact, if you have a crushed name, it's basically impossible to determine the original method name. If the mangled name of the method is too long for the environment, the mangled name is crushed down to the maximum size permissible.  OpenVMS has a limit of 31 characters, 64-bit systems have a 188 character limit, and 32-bit systems have a 200 character limit. Actually, the limit is one character less, because we use the rule that if the name is exactly the maximum size, it must be a crushed name.  As the last 7 characters of a crushed name is a checksum, on OpenVMS you’re only left with 24 characters for a human “readable” name.

So how, exactly, does a mangled name become a crushed name? Well, characters are removed, one by one, until the name is exactly the correct length. First non-alphanumeric characters are removed, then vowels, then letters from the name of your first born child, then random letters based on the cycle of the moon, until you eventually get a name that fits. So, with only 31 characters for method ames, the OpenVMS users out there will have to become accustomed to seeing crushed (i.e. indecipherable) method names inside Shared Image Libraries.  If you need to create an OpenVMS Shared image library, I would recommend creating an object library, and using the make_share.com file to convert to a shared image library.  However, you may need to review the use of the MATCH qualifier on your shared image libraries, as method names can change with the modification of a parameter (or return) type. So changing a method to (for example) have an additional optional parameter will cause a new method name to be created.  Unless you rebuild your application to see (and use) the new name, you could find that the application starts giving “routine not found” errors.

You might think that not knowing the name of the routine would be a problem – it's not really, because the compiler has a consistent supply of the same high quality drugs, and given a constant method signature, will always generate the same crushed name.  So it really doesn't care that that your code said  "object.showform(1)", because it'll know that you really want to call the method '7SYNPSGCR1UTLTESWRKNGSHW9HTGB13' from your library.

For most developers out there, the actual name of the method inside a library is unimportant, but I though the more curious of you out there would be interested in this.


Picture This!

By Richard Morris, Posted on January 28, 2010 at 11:29 pm

In days of old, carrying your trusted, heavy weight camera around your neck, you’d take the perfect snap.  You’d then continue snapping away until the film was full, which, for the impatient among us, meant taking a large number of “I was just finishing off the film darling” type shots. On returning home you’d quickly rewind the film back into its cartridge, unless you had one of those fancy modern “advanced” film cameras of course, where the camera did it for you, and then pop it into your “postage free” envelope.  And off you sent it, in the hope that your “once in a life time” shot would be processed and returned to you post haste.

And what of the results?  Normally a hazy, slightly out of focus, batch of glossy pictures that really don’t give your artistic prowess justice.  After all, the subject must have moved because you’d never intentionally crop the top of the head of the bride, just above the eye line, and why was the gentleman third from the right picking his nose?

If this sounds like your photography experiences, the chances are if you live in the UK the people processing your film were a company called Harrier L L C.  You may know them better as “TRUPRINT”.  At their peak they were processing 85,000 rolls of film per day!  Today, however, they are processing no more than 1,000 films.  Not really a great statistic if film processing is your business.  But Harrier saw the potential of the digital world and has embraced the processing of the digital image.  Today they average over 200,000 prints a day, which can rise to over 1,000,000 prints at times like Christmas.  However, although this figure is significantly lower than the prints they were processing in the heyday of film, it’s now a very small part of their product portfolio.  The key to success was to diversify.  Today, in this digital age, people want more than just a glossy print of their blurred, half-cropped pictures.  They want the t-shirt, a coffee mug and of course the family calendar, all donned with their own artistic compositions.  Today, with a few clicks of a mouse you can upload your pictures and have them delivered to your door on anything from coffee mugs, placemats to a full size framed canvases.  You can even have your prized picture delivered to you in lots of tiny pieces – in the form of a jigsaw!

So where does Synergy fit into their IT strategy?  Their OpenVMS based Synergy /DE applications manage the order processing and management of every item they process.  Once an order is accepted through the many portals including a host of web sites, major supermarket chains, leading pharmacies, and of course by post, the Synergy application takes control.  It manages the processing or the required prints, storybooks or mugs (to name but a few product lines – they have over 500) through to despatch and successful delivery to the customer.  The Synergex Professional Services Group is assisting Harrier to evaluate to work needed to migrate their Synergy/DE applications from the OpenVMS platform to Microsoft Windows.


Don't miss a post!

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

Recent Posts Tag Cloud Archives