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.
Wednesday 4 April 2007
Cobol - Who Needs It?
Simple answer, Nobody. You don't need C, Access, Basic or any of the other programming languages either. You don't even need a computer and you certainly don't need Windows. What you need are answers. Results. You need them now and you need them to be right.
So how do you meet your needs? Remember that:-
Version 1.0 of anything never works properly
Seeing is not the same as believing
Simple is better than complex
Consider the wheel. Tried and tested, absolutely basic, does what you expect. Our software must be developed along the same lines. Like the wheel, Cobol software exists. It is proven code. It works. Why start again with a version 1 product?
In the early days of spreadsheets, you could probably cobble up almost anything for your shareholders or bank manager and because it was printed by a computer your submissions were taken as the absolute truth. Why? Because there was a history of computers producing accurate results after months of testing and manual checking. Most of this software was written in Cobol. Of course, we know better now about spreadsheets and databases (don't we?).
New software generators, solutions and languages have come and gone. Cobol is still here. Cobol programmers can:-
Pick up, read and understand a program listing that is 30 years old
Scan those yellowed pages into their PC, recompile and use the logic
Produce working software that will pass the test of time
The latest Cobol compilers can process old logic and methods or new, procedural or object oriented code and produce small, efficient and effective executable modules that programmers can use time and again, knowing they are robust.
By structuring programs in levels, the base code can run without being concerned about hardware, operating system, input and output methods or any other environmental issues, so that when, possibly many years later, modifications must be made, the programmer can be confident that the code can be read and understood. So Cobol will live on.
So how do you meet your needs? Remember that:-
Version 1.0 of anything never works properly
Seeing is not the same as believing
Simple is better than complex
Consider the wheel. Tried and tested, absolutely basic, does what you expect. Our software must be developed along the same lines. Like the wheel, Cobol software exists. It is proven code. It works. Why start again with a version 1 product?
In the early days of spreadsheets, you could probably cobble up almost anything for your shareholders or bank manager and because it was printed by a computer your submissions were taken as the absolute truth. Why? Because there was a history of computers producing accurate results after months of testing and manual checking. Most of this software was written in Cobol. Of course, we know better now about spreadsheets and databases (don't we?).
New software generators, solutions and languages have come and gone. Cobol is still here. Cobol programmers can:-
Pick up, read and understand a program listing that is 30 years old
Scan those yellowed pages into their PC, recompile and use the logic
Produce working software that will pass the test of time
The latest Cobol compilers can process old logic and methods or new, procedural or object oriented code and produce small, efficient and effective executable modules that programmers can use time and again, knowing they are robust.
By structuring programs in levels, the base code can run without being concerned about hardware, operating system, input and output methods or any other environmental issues, so that when, possibly many years later, modifications must be made, the programmer can be confident that the code can be read and understood. So Cobol will live on.
Thursday 29 March 2007
Bug Fix
We have corrected a bug in the www.cobol.tv buy page so you can now go to the Fujitsu Cobol support page correctly. We apologise for this error. If you find any other errors on the site, please email these to the address shown on the buy page.
Monday 26 March 2007
A Personal Cobol
I first met Cobol in 1967. Already a programmer in ICT 1300 machine code and punched card systems I thought this new language was verbose and clumsy. But even then Cobol had a major advantage in being (to some extent) portable across computer ranges from various manufacturers. At that time, programming was a laborious process. Having set out your task you would write your code on a specially designed coding form, being careful to be very precise and legible with your printing. Once complete, the pad of coding forms would be submitted to an operator who would accurately (you hoped) key in your code and create a pack of punched cards, one line to one card. If the punch room was busy, you would have to wait some hours to try your program.
It was important to start each line of code with a sequential line number. Why? Well, it was all to easy to drop your precious card pack and watch with horror as your 500 card program exploded across the computer room floor. By using line numbers punched in the cards, you could use a card sorter to rapidly restore your program to its original sequence. Then you would load your program into the computer card reader and type your compile command into the console. After five to ten minutes, the compile would finish and you would have a program listing on the printer. Inevitably, many errors would be found by the compiler and your would have to recode, re-punch and recompile your program, repeating the cycle until no errors remained.
Then your program was ready for testing. With no compile errors I was supremely confident that my first program would work. Wrong! A working program was still days away after many testing and debugging runs had been carried out.
A few years later, mini computers were developed and these could also run Cobol. I remember my first "personal" computer, a Burroughs B80 the size of two large desks shoehorned into our utility room at home. This "visible record computer" had a keyboard, printer, magnetic stripe ledger card processor and a tiny screen able to hold just a few short lines of data. I was immediately grateful to my wife, not just for allowing such a monstrosity into our house but for teaching me to type properly. Now I was able to type my own programs directly into the computer and modify them "online". But "mini" computer also meant mini power and compiling a Cobol program could take between 60 and 90 minutes.
Only the more expensive mini computers could run Cobol and the prices were still beyond the reach of many organisations. So for a while I programmed Wang and Dec computers in Basic and Fortran, returning to Cobol on ICL 2900 mainframes in the early 1980s. Now we had "terminals". Screens and keyboards connected to the mainframe enabling a number of programmers to simultaneously compile and test software.
I bought my first microcomputer. Sirius One. An early 16 bit micro with 2 floppy drives and Cobol. Using CIS Cobol (a "lite" Cobol) development could at last be done at a reasonable price. Today, with microcomputers many times the power of the old mainframes and the availability of superb construction tools, Cobol is in a golden age.
It was important to start each line of code with a sequential line number. Why? Well, it was all to easy to drop your precious card pack and watch with horror as your 500 card program exploded across the computer room floor. By using line numbers punched in the cards, you could use a card sorter to rapidly restore your program to its original sequence. Then you would load your program into the computer card reader and type your compile command into the console. After five to ten minutes, the compile would finish and you would have a program listing on the printer. Inevitably, many errors would be found by the compiler and your would have to recode, re-punch and recompile your program, repeating the cycle until no errors remained.
Then your program was ready for testing. With no compile errors I was supremely confident that my first program would work. Wrong! A working program was still days away after many testing and debugging runs had been carried out.
A few years later, mini computers were developed and these could also run Cobol. I remember my first "personal" computer, a Burroughs B80 the size of two large desks shoehorned into our utility room at home. This "visible record computer" had a keyboard, printer, magnetic stripe ledger card processor and a tiny screen able to hold just a few short lines of data. I was immediately grateful to my wife, not just for allowing such a monstrosity into our house but for teaching me to type properly. Now I was able to type my own programs directly into the computer and modify them "online". But "mini" computer also meant mini power and compiling a Cobol program could take between 60 and 90 minutes.
Only the more expensive mini computers could run Cobol and the prices were still beyond the reach of many organisations. So for a while I programmed Wang and Dec computers in Basic and Fortran, returning to Cobol on ICL 2900 mainframes in the early 1980s. Now we had "terminals". Screens and keyboards connected to the mainframe enabling a number of programmers to simultaneously compile and test software.
I bought my first microcomputer. Sirius One. An early 16 bit micro with 2 floppy drives and Cobol. Using CIS Cobol (a "lite" Cobol) development could at last be done at a reasonable price. Today, with microcomputers many times the power of the old mainframes and the availability of superb construction tools, Cobol is in a golden age.
Thursday 1 March 2007
Fujitsu Site Change
Thanks for letting us know that Fujitsu have changed their site from www.adtools.com to www.netcobol.com. We have now changed the links on the site to the new URL so they should work OK. Please let me know if there are any more problems.
Monday 26 February 2007
Welcome to 21st Century Cobol from www.cobol.tv
Hello world. If you have any interest in Cobol, either as a developer, user or teacher, you can chat about Cobol here. On our website at www.cobol.tv we show you how to try 21st Century Cobol for free, how to teach yourself the basics from an excellent book and provide numerous links to cobol related activities.
We distribute sp2 and FormPrint from Flexus (www.flexus.com) in the UK and Ireland. Please check out our website, download the software if you need it and find out just how easy it is to write Windows software in Cobol.
All your comments are welcome. If you have any queries we'll try to answer them here. Thank you for checking us out.
We distribute sp2 and FormPrint from Flexus (www.flexus.com) in the UK and Ireland. Please check out our website, download the software if you need it and find out just how easy it is to write Windows software in Cobol.
All your comments are welcome. If you have any queries we'll try to answer them here. Thank you for checking us out.
Subscribe to:
Posts (Atom)