Can the cobol compiler provided by Fujitsu for win xp create cobol programs that are simular to those developed on an AS400?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
You can apply for a free account on a timeshare IBM iSeries to learn COBOL or any other compiler available on IBM's OS/400.
http://www.innovativesys.n
Yes, you can compile iSeries COBOL online.
Guess the free acounts are all gone. For $10mo you can get an iSeries account here: http://virtual400.com/
Is this compiler good?
http://www.freebyte.com/pr
eugene007:
Whether any COBOL compiler will help you will depend on what you will need to learn.
For example, files on an AS/400 generally have a quality that is named "externally-described". This isn't a common quality for files and most COBOL compilers have no way to take advantage of it. This is particularly true for display files, printer files and database files.
If you are expecting to understand file processing, then you should pay speciall attention to how files are described when you use COBOL on an AS/400.
However, if you are expecting to learn how COBOL describes variables in memory, how COBOL statements are specified in the procedural section, how COBOL statements such as PERFORM, INSPECT and others, work in general, then it isn't as important to learn on an AS/400.
Are you needing to learn AS/400s more than COBOL or do you need to learn COBOL more than AS/400s?
If AS/400s are more important for you to learn right now, then you should start on an AS/400. If the COBOL language is more important and you already have experience in other AS/400 languages, then it won't matter as much if you study COBOL on a different system.
Tom
In regards to "http://virtual400.com/"
Is it easy to compile a cobol program?. Im a beginner.
also in regards to "http://virtual400.com/" basic feature package I found this:
ILE Cobol
does it indicate any difference to the cobol that will run on a hogan (AS400) system?.
eugene007:
Q. In regards to "http://virtual400.com/" Is it easy to compile a cobol program?
A. It's easy for me to compile COBOL programs. I can only guess that virtual400.com provides the standard commands for compiles.
Q. also in regards to "http://virtual400.com/" basic feature package I found this: ILE Cobol. Does it indicate any difference to the cobol that will run on a hogan (AS400) system?.
A. I have no idea what "hogan" means; but if it's an AS/400 or a later system in that series, then the COBOL programming on virtual400.com will work on the "hogan" system as long as the releases are compatible. That is, if virtual400.com runs at V5R4, you won't be able to compile for another system that is older than V5R2. However, you could write and compile source code on virtual400.com that is compatible with earlier releases. In order to use that source code, the source code would need to be FTP'd to the older system and then compiled.
Tom
In regards to "http://virtual400.com"
Is the subscription on a monthly basis. In other words can I rent the service for a month?.
Regards.
In regards to virtual400.com
1) After your first month, if you do not cancel, we will bill you for the next month of service due.
- This I can understand.
2) You may cancel service at anytime. However, you still must pay for services due, if any.
- This means alot. "However, you still must pay for services due, if any".
I would expect "services due" to cover the remainder of a month when an account is canceled during the first days of the month for example. IIRC, there are also additional facilities that you can request beyond what is provided as a base. If extras have been requested that haven't been billed yet, you're still expected to pay for what you asked for. Just a guess.
Since I've never heard any complaints about the service, I wouldn't be very concerned if I opened an account -- my opinion only.
Tom
eugene007:
Virtual400.com offers different account types. The "basic" accounts are priced at $9.95US per month. They also offer "developer" accounts at $17.95US per month. Developer accounts appear to allow direct access to *.dat streamfiles.
The description of the Basic accounts looks like *.dat streamfiles would not be _directly_ accessible. However, if you don't mind changing the extension from [.dat] to [.usrspc], I think you could create the same programming.
The descriptions of the accounts at virtual400.com says that Developer accounts are given /home directories but Basic accounts are not. But "user space" objects in libraries can be accessed with the same APIs as normal streamfiles in directories. That generally means that the same programming will work for both.
There will probably be differences between reading a user space in a library as a streamfile and reading actual streamfiles from directories. But I would suggest that you would learn more by learning the differences.
Tom
eugene007:
Well, yes and no.
That is, you should be able to SELECT/ASSIGN just as you would in most any standard COBOL.
But, you wouldn't access a .DAT streamfile. You'd access a database file. I.e., it probably wouldn't have an "extension" such as ".DAT". There wouldn't be an extension at all. The object type would be assumed to be a *FILE object because you would create STUDENTS as a *FILE.
So, it would be:
SELECT StudentFile ASSIGN TO STUDENTS.
OPEN INPUT StudentFile
If it was absolutely necessary to access streamfiles in directories rather than database files, you would use the appropriate APIs -- open(), read(), write(), close(), etc.
Tom
The exact answer will depend on what virtual400.com allows. In that sense, they are the ones who can answer.
However, generally, you will have a library that you can create objects in. That library should be available to you whenever you signon to a telnet session. You will create a file that can hold your COBOL source statements. Because it will be intended to hold source statements to be edited and compiled, the file will have characteristics that are useful for source statements. The file will be a "source physical file" and will be created with a CRTSRCPF command. The "standard" name of a source file that is expected to hold COBOL source is QLBLSRC for older COBOL and QCBLLESRC for ILE COBOL, but the name can be any valid name.
Once the file exists, it can act as a container and receive records from a server function such as FTP. I don't know how virtual400.com controls in-bound FTP nor what restrictions or requirements they place on transfers.
You COBOL .COB file will be uploaded into a segment of your QCBLSRC (or QCBLLESRC) file that is called a "member". Source files can hold thousands of different members. Each member has a name. Usually, you would name the source member the same as the name of the program or module you want. (Modules can only be created with ILE COBOL. Modules allow you to compile multiple subprograms that you may bind together into executable programs. One module can issue a call to a procedure in a different module as long as they're bound to gether.)
So, create a source file and upload your source into a member. You compile members into programs (or modules).
Usually, developers have a tool (a product) that's known as PDM -- Programming Development Manager. I would expect virtual400.com to make it available by default.
Compiling your source into a program (or module) is easiest through PDM. You can start PDM with the STRPDM command. Three other commands are WRKLIBPDM, WRKOBJPDM and WRKMBRPDM. Those work with lists of libraries, with lists of objects in a library, and lists of members in a source file. The commands can be entered on a command line or accessed through the STRPDM menu. A number of elements of PDM can be customized for your preferences.
WRKMBRPDM is most useful for compiling. When you work with members in a source file, options are made available to you to act on each of the members. In your case, option 14 will compile a member into an executable program and option 15 compiles source into an object module for later binding.
When using PDM to compile, you need to assign a "type" to each of your source members. The type tells PDM what kind of source is being compiled. Source type for older COBOL will be CBL and for ILE COBOL will be CBLLE. The command that is used to compile is chosen based on source type.
To compile a standard old COBOL program, the command is CRTCBLPGM. To compile an ILE COBOL member into an executable program, the command is CRTBNDCBL. To compile an ILE COBOL member into a module, the command is CRTCBLMOD.
If you begin to create modules, you would eventually bind some of them together. To bind modules into an executable program, the command is CRTPGM. The modules must exist first. The CRTBNDCBL command combines CRTCBLMOD and CRTPGM into a single command that compiles the module and then creates a program from that single module.
I thought virtual400.com advertised V5R3. If so, the V5R3 manuals are online. For old COBOL:
http://publib.boulder.ibm.
For ILE COBOL:
http://publib.boulder.ibm.
Those links provide .PDFs for downloading. The User's Guides discuss elements of creating source files, editing members, compiling them and other parts.
Obviously, a full class is a bit beyond the scope of an EE question. But that should be enough to get you moving.
Tom
Business Accounts
Answer for Membership
by: tliottaPosted on 2008-04-18 at 19:32:04ID: 21390896
eugene007:
Yes and no.
That is, it depends on what you're asking. If the program source code involves standard COBOL structures and avoids vendor and platform extensions, then it's reasonable to expect that it wouldn't take a huge amount of effort to get the program to compile on either system.
But if the program source relies significantly on extensions and system calls to APIs etc., then the two versions of the program might not look much like each other at all.
Either way, the _output_ of the two compilers have almost zero chance of any resemblance at all.
Can you elaborate some on what you're looking for?
Tom