One of the Flexus cobol tools (see http://www.cobol.tv/) is Thin Client. This great software allows your programs to reside on a server and be accessed from PCs anywhere. Basically, copies of the screen formats etc. are held on each client and only the raw data required to fill these forms travels from client to server and back. This makes for a very fast and efficient network. We have even tested this on 56k dialup lines with reasonable performance.
The client PCs do not need to be powerful because they only run a small client module, do virtually no file handling or data processing. So second user or low specification PCs can be used for this purpose.
But the server is different. Have you ever tried installing and running Windows 2003 server? Even if you have the technical knowledge to configure this stuff you will find everything for "server" use is expensive. Try buying products like antivirus for W2003 server and you will soon find out what I mean. Even the free antivirus programs (do you really run these?) become expensive or will not run.
For many larger organisations, these costs are an evil necessity. They either send their staff on expensive training courses (so they can convert "Windows-speak" into something understandable) or buy in the expertise when needed. Then they grin and bear the continued costs to maintain these mental monsters they will never understand.
Yet for most of us it doesn't have to be like this. Consider the smaller business with perhaps a dozen small shops or offices scattered around the country. Each of these operates more or less independently on a day to day basis and has one or two staff who know how to run a PC properly. The solution is much cheaper both for initial purchase and ongoing maintenance. It's Windows XP.
To be more precise, Windows XP Professional. This can be run on a standard PC, configured as a standard PC, have much cheaper startup and ongoing maintenance costs and can be understood by most people operating a PC today.
As a server, Windows XP has a lot going for it. Loads of power and flexibility available if you need it (you probably won't) by using dual core or AMD X2 processors, huge storage space and good access speeds especially with the latest SATA2-300 hard drives, standard or security networking in workstation groups etc.etc.
Flexus Thin Client runs superbly on this "XP Server" setup and I'm sure most other networking stuff will also. So why waste your money and time on a "proper" server if you don't need to?
Monday 14 May 2007
Thursday 3 May 2007
A Major Lesson from Fortran IV
Fortran? Why talk about Fortran on a Cobol blog!
Well, just to pass on a little experience before it’s too late.
In the late 1970s I began selling Dec PDP11-03s through my small software business. These minicomputers, the size of a three drawer filing cabinet, had floppy drives taking 8” diskettes holding a “massive” 256kb of data, a visual display screen and a keyboard. A 30 character per second “line printer” was an optional extra. They were the first proper computers to be practical and affordable by small businesses and the only programming language available was Fortran IV.
My peers laughed at my crazy idea of programming business and commercial applications in Fortran. “You can’t do that, it’s a scientific language” were among the printable comments. But I was impressed by the speed of the compiled code, many times faster than the Basic used by the Wang computers I had worked on previously. So I got down to work.
I found Fortran allowed me to use subroutines. So I could write and compile utility routines with parameter driven input and output. Once written and tested, these routines could be “called” by any other routine. So I slowly developed a sizeable library of routines to handle everything from outputting a single character to a fixed point on a screen to a complete report generator.
After a while, I could develop new applications at lightning speed by using my library of generic subroutines while coding errors and testing time greatly decreased, improving the viability of my business.
So what has all this to do with Cobol?
Now, almost thirty years after my Fortran days, many Cobol programs are still being written from scratch with the only concession to efficiency being a little copying and pasting in an editor. The reasons are almost too many to mention but include the dreaded “screen section” coding which often varies from machine to machine and compiler to compiler and Cobol’s own self-documenting ability which encourages the use of unique data names in every program and suite.
But there is a better way. Much better!
When I first started using sp2 and FormPrint from Flexus (read all about this at www.cobol.tv) I realised that this great software enabled Cobol to be completely divorced from both input and output functions. I could therefore “think Fortran” and write generic code. Routines to handle file management, listing and other repetitive tasks could be written once and used again and again in any application. Using the ability of the Flexus software to quickly create and generate screen layouts, validations and reports, software suites can be quickly assembled using a very high percentage of tried and tested generic cobol.
So thank you to Fortran in the past and Flexus now and in the future for making Cobol my rapid development tool.
Well, just to pass on a little experience before it’s too late.
In the late 1970s I began selling Dec PDP11-03s through my small software business. These minicomputers, the size of a three drawer filing cabinet, had floppy drives taking 8” diskettes holding a “massive” 256kb of data, a visual display screen and a keyboard. A 30 character per second “line printer” was an optional extra. They were the first proper computers to be practical and affordable by small businesses and the only programming language available was Fortran IV.
My peers laughed at my crazy idea of programming business and commercial applications in Fortran. “You can’t do that, it’s a scientific language” were among the printable comments. But I was impressed by the speed of the compiled code, many times faster than the Basic used by the Wang computers I had worked on previously. So I got down to work.
I found Fortran allowed me to use subroutines. So I could write and compile utility routines with parameter driven input and output. Once written and tested, these routines could be “called” by any other routine. So I slowly developed a sizeable library of routines to handle everything from outputting a single character to a fixed point on a screen to a complete report generator.
After a while, I could develop new applications at lightning speed by using my library of generic subroutines while coding errors and testing time greatly decreased, improving the viability of my business.
So what has all this to do with Cobol?
Now, almost thirty years after my Fortran days, many Cobol programs are still being written from scratch with the only concession to efficiency being a little copying and pasting in an editor. The reasons are almost too many to mention but include the dreaded “screen section” coding which often varies from machine to machine and compiler to compiler and Cobol’s own self-documenting ability which encourages the use of unique data names in every program and suite.
But there is a better way. Much better!
When I first started using sp2 and FormPrint from Flexus (read all about this at www.cobol.tv) I realised that this great software enabled Cobol to be completely divorced from both input and output functions. I could therefore “think Fortran” and write generic code. Routines to handle file management, listing and other repetitive tasks could be written once and used again and again in any application. Using the ability of the Flexus software to quickly create and generate screen layouts, validations and reports, software suites can be quickly assembled using a very high percentage of tried and tested generic cobol.
So thank you to Fortran in the past and Flexus now and in the future for making Cobol my rapid development tool.
Subscribe to:
Posts (Atom)