Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Fujitsu Cobol Users
- Thread starter RASI
- Start date
I am just starting to use PowerCobol 5 myself. Our system
is currently written in Realia Cobol for the DOS environment and we will be using PowerCobol to convert the
application to a Windows application. I have already converted several forms and it works great. However, I would
like to use a third party grid control if I could find one that works.
is currently written in Realia Cobol for the DOS environment and we will be using PowerCobol to convert the
application to a Windows application. I have already converted several forms and it works great. However, I would
like to use a third party grid control if I could find one that works.
- Thread starter
- #3
Tomcat,
Thanks for the reply. Thought maybe I was the only one on this board using PCobol V5. Our current system is written in Realia V4.2 also. As you know, Realia has some really neat features that I have learned to use over the years. Have found it very interesting trying to use PCobol to do some things that were just "easy" in Realia. But, I have found some neat features in PCobol also. I have found the Active X's published by run well with PCobol V5. (The ones designed for VBasic..)
BTW, If you installed PCobol V5 from the cdrom and have not yet updated your system with the patches from you will find some third party controls do not work as expected!! Slow typing in control fields, controls that freeze, etc.
Cobol Happy,
rick rickj@intrstar.net
Thanks for the reply. Thought maybe I was the only one on this board using PCobol V5. Our current system is written in Realia V4.2 also. As you know, Realia has some really neat features that I have learned to use over the years. Have found it very interesting trying to use PCobol to do some things that were just "easy" in Realia. But, I have found some neat features in PCobol also. I have found the Active X's published by run well with PCobol V5. (The ones designed for VBasic..)
BTW, If you installed PCobol V5 from the cdrom and have not yet updated your system with the patches from you will find some third party controls do not work as expected!! Slow typing in control fields, controls that freeze, etc.
Cobol Happy,
rick rickj@intrstar.net
Hi Rasi,
Can you tell us something more about the differences you experience with PCobol V5 compared to CA-REALIA COBOL, why your company didn't change to CA-REALIA 6, what the mainreason was for the choice, things like that. We all want to know all about it!
Thanks!
Can you tell us something more about the differences you experience with PCobol V5 compared to CA-REALIA COBOL, why your company didn't change to CA-REALIA 6, what the mainreason was for the choice, things like that. We all want to know all about it!
Thanks!
- Thread starter
- #5
Crox,
I will post this info later this week. There were many factors involved..
The main factor was this...
1. CA which makes Ca-Realia didn't seem very eager to provide the cobol world with a true 32 bit GUI compiler and development system at the time we needed it. Hot shots like microsoft etc -- were providing Visual Basic , Visual C++ you name it. CA had only a "GUI" like code builder. You could not write TRUE GUI applications. Worst yet, we could not get a commitment that one would be provided in the future.
Fujitsu's answer to our problem....( BTW, a new 64 bit runtime will soon be released... )
A Restatement of Our Long-term Commitment to COBOL
At Fujitsu Software, we are extremely committed to the COBOL market and always try to put the needs of COBOL programmers first. We believe that it's the key to earning your respect and building a long-term mutually beneficial business partnership. We believe that COBOL programmers deserve a reasonably priced COBOL compiler with high performance, unmatched reliability, superior scalability, and royalty free COBOL run-times.
We want to make sure that the COBOL development community understands that all existing Fujitsu COBOL run-time features that have been free in the past are still free! In Version 5, we have created a new, optional multi-threaded run-time system targeted for enterprise server-based applications. We have tried to keep the prices low and to make the licensing simple. There will be a one-time charge for this optional run-time system*. COBOL programmers will continue to have access to the royalty-free Fujitsu run-time system and may develop and deploy COBOL applications with no license fees required (i.e. no strings attached…). These applications may include Internet (web) based components that are single threaded and may run on servers with no license fee required.
Fujitsu Software's business model regarding English-language COBOL products (sold outside of Japan, Korea and China) is to provide a robust, high performance, single-threaded COBOL development environment with no required run-time licensing fees. This allows developers to create and deploy COBOL applications without paying additional run-time fees or deal with tracking run-time licenses. Since we coexist with other established development products such as Visual Basic®, C++, and Java, we are trying to keep the price of our COBOL compiler and associated development tools competitive.
We believe that COBOL has a bright future. Our intention is to continue to invest in creating quality tools and COBOL compiler technology. We plan to keep our prices consistent with this optimistic outlook and help keep COBOL at the forefront of business programming in the 21st century.
Sincerely,
Ron Langer
Director, COBOL Sales and Marketing
I will post this info later this week. There were many factors involved..
The main factor was this...
1. CA which makes Ca-Realia didn't seem very eager to provide the cobol world with a true 32 bit GUI compiler and development system at the time we needed it. Hot shots like microsoft etc -- were providing Visual Basic , Visual C++ you name it. CA had only a "GUI" like code builder. You could not write TRUE GUI applications. Worst yet, we could not get a commitment that one would be provided in the future.
Fujitsu's answer to our problem....( BTW, a new 64 bit runtime will soon be released... )
A Restatement of Our Long-term Commitment to COBOL
At Fujitsu Software, we are extremely committed to the COBOL market and always try to put the needs of COBOL programmers first. We believe that it's the key to earning your respect and building a long-term mutually beneficial business partnership. We believe that COBOL programmers deserve a reasonably priced COBOL compiler with high performance, unmatched reliability, superior scalability, and royalty free COBOL run-times.
We want to make sure that the COBOL development community understands that all existing Fujitsu COBOL run-time features that have been free in the past are still free! In Version 5, we have created a new, optional multi-threaded run-time system targeted for enterprise server-based applications. We have tried to keep the prices low and to make the licensing simple. There will be a one-time charge for this optional run-time system*. COBOL programmers will continue to have access to the royalty-free Fujitsu run-time system and may develop and deploy COBOL applications with no license fees required (i.e. no strings attached…). These applications may include Internet (web) based components that are single threaded and may run on servers with no license fee required.
Fujitsu Software's business model regarding English-language COBOL products (sold outside of Japan, Korea and China) is to provide a robust, high performance, single-threaded COBOL development environment with no required run-time licensing fees. This allows developers to create and deploy COBOL applications without paying additional run-time fees or deal with tracking run-time licenses. Since we coexist with other established development products such as Visual Basic®, C++, and Java, we are trying to keep the price of our COBOL compiler and associated development tools competitive.
We believe that COBOL has a bright future. Our intention is to continue to invest in creating quality tools and COBOL compiler technology. We plan to keep our prices consistent with this optimistic outlook and help keep COBOL at the forefront of business programming in the 21st century.
Sincerely,
Ron Langer
Director, COBOL Sales and Marketing
Rasi,
Thanks for the Active X information and the upgrade to
PCobol v5, I will check out both of these. Have you tried
any of the Active X controls with PC v5? Do you know if
there is any way to use a data bound grid control like you
would use in Visual Basic?
Tom Winters
twinters@wdcsystems.com
Thanks for the Active X information and the upgrade to
PCobol v5, I will check out both of these. Have you tried
any of the Active X controls with PC v5? Do you know if
there is any way to use a data bound grid control like you
would use in Visual Basic?
Tom Winters
twinters@wdcsystems.com
- Thread starter
- #7
Tomcat,
Most OCX controls that are designed for Visual Basic seem to work well with PCobol. Most Vendors don't advertise this fact yet, because they are normally "blown away" if you call them and state that your using COBOl to drive their controls!! We use CommX from Greenleaf software for PC serial communications. ie Com1,Com2, modem programming. This control works great and is super fast. You can find them at
I have also used some controls written by sheriden software such as the TAB control etc. I try to stick with the controls found in PCOBOL at all possible for support reasons. I have not used a third party data bound grid control yet, so just experiment with one. Sheriden software seems to have a bundle of stuff called DATA Widgets. These controls should work. Just check and make sure you link any needed library with your application.
BTW,
What database are you using? Cobol Files, ODBC supported, SQL server???
Let me see,,, I bet you use Pervasive SQL or Btreive.
PS. Thanks for the email info. Will add it to my COBOL Support Ring Group. (No junk mail)
Have a good day..
RASI
Most OCX controls that are designed for Visual Basic seem to work well with PCobol. Most Vendors don't advertise this fact yet, because they are normally "blown away" if you call them and state that your using COBOl to drive their controls!! We use CommX from Greenleaf software for PC serial communications. ie Com1,Com2, modem programming. This control works great and is super fast. You can find them at
I have also used some controls written by sheriden software such as the TAB control etc. I try to stick with the controls found in PCOBOL at all possible for support reasons. I have not used a third party data bound grid control yet, so just experiment with one. Sheriden software seems to have a bundle of stuff called DATA Widgets. These controls should work. Just check and make sure you link any needed library with your application.
BTW,
What database are you using? Cobol Files, ODBC supported, SQL server???
Let me see,,, I bet you use Pervasive SQL or Btreive.
PS. Thanks for the email info. Will add it to my COBOL Support Ring Group. (No junk mail)
Have a good day..
RASI
Rasi,
You are correct, we are currently using Pervasive and Btrieve. My objective is to convert our application from Btrieve API calls to embedded SQL via ODBC so our code can be shielded from the data base manager (if possible) in order to be more portable. The largest piece of our application is currently running on a data base manager called MDBS, it is an Extended Network type data base that has served us well over the years but we would like to move into the SQL world.
Do you have any experience with the Pervasive SQL engine or words of wisdom?
You are correct, we are currently using Pervasive and Btrieve. My objective is to convert our application from Btrieve API calls to embedded SQL via ODBC so our code can be shielded from the data base manager (if possible) in order to be more portable. The largest piece of our application is currently running on a data base manager called MDBS, it is an Extended Network type data base that has served us well over the years but we would like to move into the SQL world.
Do you have any experience with the Pervasive SQL engine or words of wisdom?
- Thread starter
- #9
Tomcat,
My current applications only deal with Foxpro Databases using ODBC and just plain Cobol Index Files using native record locking calls. I have spent many research hours trying to select a company/database provider and Pervasive SQL seems to be the way to go. Their workstation options for the engine seem very attractive and the price is right. I assoicate the name TRUST with Btrieve. Most of the major accounting and Point-of-Sale firms use Pervasive as the database because it is so realiable on the user end and you don't need a Microsoft engineer standing by at the customers location. Sad- but true with the other SQL bigshots.
I suspect within the next few months, we will push forward with Pervasive SQL as time permits. You can email Fujitsu at support@adtools.com and request information regarding SQL calls within COBOL. I think they have specific instructions that is not found in the help documentation. Just let them know what database your using etc...
One note of caution about using the raw ODBC drivers supplied by Microsoft...
The drivers are written to produce "Window error boxes" to the user at the time of an expected error. It doesn't take long before you figure out these "error boxes with an OK button" are very confusing to your end users... You get these "ok" boxes before your logic has time make its own decision as to what route to take to let the user know an error has occured.
I'm in the process of writing a Radio Frequency program using a hand-held FM device for scanning UPC shelf prices in grocery stores. These error boxes don't work very well when your user is on the sale floor and not looking at the CRT as some cat at Microsoft assumed.. Oh well.
BTW, I will be out of town for a few days. Be back on Monday.
Good coding...
Rick at RASI
My current applications only deal with Foxpro Databases using ODBC and just plain Cobol Index Files using native record locking calls. I have spent many research hours trying to select a company/database provider and Pervasive SQL seems to be the way to go. Their workstation options for the engine seem very attractive and the price is right. I assoicate the name TRUST with Btrieve. Most of the major accounting and Point-of-Sale firms use Pervasive as the database because it is so realiable on the user end and you don't need a Microsoft engineer standing by at the customers location. Sad- but true with the other SQL bigshots.
I suspect within the next few months, we will push forward with Pervasive SQL as time permits. You can email Fujitsu at support@adtools.com and request information regarding SQL calls within COBOL. I think they have specific instructions that is not found in the help documentation. Just let them know what database your using etc...
One note of caution about using the raw ODBC drivers supplied by Microsoft...
The drivers are written to produce "Window error boxes" to the user at the time of an expected error. It doesn't take long before you figure out these "error boxes with an OK button" are very confusing to your end users... You get these "ok" boxes before your logic has time make its own decision as to what route to take to let the user know an error has occured.
I'm in the process of writing a Radio Frequency program using a hand-held FM device for scanning UPC shelf prices in grocery stores. These error boxes don't work very well when your user is on the sale floor and not looking at the CRT as some cat at Microsoft assumed.. Oh well.
BTW, I will be out of town for a few days. Be back on Monday.
Good coding...
Rick at RASI
This is the second Realia/Fujitsu post I've seen.
Here are the things I encountered in my conversions:
1. Use of Realia SMALLCOMP is duplicated using Fujitsu Binary(BYTE) directive -- but it's not QUITE the same. Fujitsu extends this behavior out to 8 bytes, while Realia only respectes it for 1 or 2 byte fields. You have to be careful with this.
2. Realia - USE SAME AREA is treated like USE SAME RECORD AREA, and the two are actally quite different. Realia (16 bit 4.2) actually does it wrong, but gives you the behavior you expect.
3. Realia doesn't care about the Program ID and allows numeric values. IE: PROGRAM-ID. 16.
Fujitsu, doesn't allow this. You have to put it in quotes.
4. The DOS_ and PC_ routines of Realia don't have Fujitsu equivalents. So I wrote some. I have these available, email me thane@softwaresimple.com for details.
5. Realia uses the .CBL extension to abbreviate the source by not saving the first 6 columns. You need to convert these programs to the realia COB format if you want to edit them with both compilers.
6. The Fujitsu editor behaves strangely when tabs are used - as is the default in Realia source. I use RED/N to save the file without the tabs.
7. The select statements in Realia use VARYING -- with Fujitsu you have to remove the VARYING.
8. File and record locking. This applies to Realia 4.2 - and file locking.
With Realia LOCK MODE EXCLUSIVE gives you an I/O exclusive lock. Multiple programs can read but only one can update. If a program has the file open for update, then no one else can have it open.
There is no real equivalent with Fujitsu, but specifying NO lock mode gets you close. We ended up chucking the exclusive access model and went to Lock Mode AUTOMATIC instead and we had better results, but we had to redesign some portions of the application. This is probably the biggest caveat in conversion.
Good Luck!
Here are the things I encountered in my conversions:
1. Use of Realia SMALLCOMP is duplicated using Fujitsu Binary(BYTE) directive -- but it's not QUITE the same. Fujitsu extends this behavior out to 8 bytes, while Realia only respectes it for 1 or 2 byte fields. You have to be careful with this.
2. Realia - USE SAME AREA is treated like USE SAME RECORD AREA, and the two are actally quite different. Realia (16 bit 4.2) actually does it wrong, but gives you the behavior you expect.
3. Realia doesn't care about the Program ID and allows numeric values. IE: PROGRAM-ID. 16.
Fujitsu, doesn't allow this. You have to put it in quotes.
4. The DOS_ and PC_ routines of Realia don't have Fujitsu equivalents. So I wrote some. I have these available, email me thane@softwaresimple.com for details.
5. Realia uses the .CBL extension to abbreviate the source by not saving the first 6 columns. You need to convert these programs to the realia COB format if you want to edit them with both compilers.
6. The Fujitsu editor behaves strangely when tabs are used - as is the default in Realia source. I use RED/N to save the file without the tabs.
7. The select statements in Realia use VARYING -- with Fujitsu you have to remove the VARYING.
8. File and record locking. This applies to Realia 4.2 - and file locking.
With Realia LOCK MODE EXCLUSIVE gives you an I/O exclusive lock. Multiple programs can read but only one can update. If a program has the file open for update, then no one else can have it open.
There is no real equivalent with Fujitsu, but specifying NO lock mode gets you close. We ended up chucking the exclusive access model and went to Lock Mode AUTOMATIC instead and we had better results, but we had to redesign some portions of the application. This is probably the biggest caveat in conversion.
Good Luck!
Rasi
I use REALIA 4.2 and 2.3 of CICS trying to migrate to FUJITSU 5. We used EBCDIC files then now with FUJITSU Im having problems with the programs dealing with the ASCII files sequence of the data. There is some info on how to deal with this but I wanted to know if anyone else had the same kind of problem.
I use REALIA 4.2 and 2.3 of CICS trying to migrate to FUJITSU 5. We used EBCDIC files then now with FUJITSU Im having problems with the programs dealing with the ASCII files sequence of the data. There is some info on how to deal with this but I wanted to know if anyone else had the same kind of problem.
I have used both Realia for DOS and Fujitsu for NT. I found that the "DOS_" routines in Realia have equivalents in Fujitsu as "CBL_" routines. For instance Realia's "DOS_OPEN_FILE" equals Fujitsu's "CBL_OPEN_FILE". Fujitsu says their routines are compatible with Mirco Focus' CBL subroutines. I don't know, never used Micro Focus.
The documentation for Fujitsu's "dos subroutines" is in the "COBOL Subroutines" area, under "COBOL CBL_Routine User's Guide". You have to link "F3BICBLR.LIB" if you use these routines.
The other thing to watch out for is signed numbers. If you have created data files with Realia using signed numbers, Realia's method of storing the sign is NOT the same as Fujitsu's. So running a Fujitsu program against the Realia data will not provide the correct results.
The documentation for Fujitsu's "dos subroutines" is in the "COBOL Subroutines" area, under "COBOL CBL_Routine User's Guide". You have to link "F3BICBLR.LIB" if you use these routines.
The other thing to watch out for is signed numbers. If you have created data files with Realia using signed numbers, Realia's method of storing the sign is NOT the same as Fujitsu's. So running a Fujitsu program against the Realia data will not provide the correct results.
Stefanwest
Programmer
I am currently using Fujitsu Cobol and Pervasive SQL 2000. My current problem is my lack of understanding about SQL cursor files and the use of database connections. We first started out just programming in PowerCobol with all of our SQL commands embedding in the form. Now it has been decided to move all SQL code to cobol batch programs. The connection of the database is done by one batch program and this works very well except SQL cursor files. Here is the situation. If I have a cursor file in the same program that executed the connection, that cursor file will work. On the other hand, if I call another batch program that has a different cursor file command, it does not work. I get spaces in the SQLSTATE instead of numbers when executing the Declare statement. What we are trying to eventally do is to have one program do the connect and disconnect to database and several other programs do the SQL commands. This seems to work except for cursor files. Do I somehow need to connect and disconnet for every program that has cursor file commands. If so, does this not cause some concern about performance with all of the connect and disconnet going on. Any advice would be helpful.
Steve
Steve
Stefanwest
Programmer
Hello everyone. Currently using Fujitsu Cobol 5 and I am having a problem getting my PowerCobol application to execute the Windows Html Help program. My knowledge on how to call Windows API subroutine is very limited and the F5 documentation is not very helpful. Ive used a product call RoboHelp to generate a ".chm" file but frankly, I dont know how to incorporated this help file into the application. Any detailed code examples along with what librabries to include in the PowerCobol would be of a great help.
Thanks
Steve
Thanks
Steve
- Status
Similar threads