Menu
▾
▴
tiny-cobol-users
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(341) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(42) |
Feb
(22) |
Mar
(59) |
Apr
(12) |
May
(15) |
Jun
(30) |
Jul
(25) |
Aug
(13) |
Sep
(98) |
Oct
(51) |
Nov
(95) |
Dec
(99) |
| 2001 |
Jan
(105) |
Feb
(175) |
Mar
(411) |
Apr
(310) |
May
(294) |
Jun
(213) |
Jul
(132) |
Aug
(82) |
Sep
(26) |
Oct
(121) |
Nov
(181) |
Dec
(96) |
| 2002 |
Jan
(52) |
Feb
(128) |
Mar
(141) |
Apr
(111) |
May
(149) |
Jun
(164) |
Jul
(33) |
Aug
(77) |
Sep
(62) |
Oct
(92) |
Nov
(14) |
Dec
(33) |
| 2003 |
Jan
(33) |
Feb
(58) |
Mar
(120) |
Apr
(180) |
May
(206) |
Jun
(110) |
Jul
(232) |
Aug
(207) |
Sep
(103) |
Oct
(122) |
Nov
(42) |
Dec
(68) |
| 2004 |
Jan
(83) |
Feb
(107) |
Mar
(90) |
Apr
(7) |
May
(42) |
Jun
(36) |
Jul
(11) |
Aug
(24) |
Sep
(67) |
Oct
(116) |
Nov
(96) |
Dec
(22) |
| 2005 |
Jan
(29) |
Feb
(6) |
Mar
(12) |
Apr
(31) |
May
(47) |
Jun
(12) |
Jul
(76) |
Aug
(69) |
Sep
(7) |
Oct
(21) |
Nov
(5) |
Dec
(4) |
| 2006 |
Jan
(5) |
Feb
(7) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
(8) |
Aug
(13) |
Sep
(7) |
Oct
(2) |
Nov
(6) |
Dec
(30) |
| 2007 |
Jan
(43) |
Feb
(7) |
Mar
(2) |
Apr
(4) |
May
(11) |
Jun
(1) |
Jul
|
Aug
|
Sep
(22) |
Oct
(18) |
Nov
(6) |
Dec
(31) |
| 2008 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
(11) |
Nov
(8) |
Dec
|
| 2009 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(3) |
Nov
|
Dec
(8) |
| 2010 |
Jan
(15) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John R. C. <jo...@we...> - 2005-09-19 18:01:42
|
I have some old programs which use some nonstandard extensions of the ACCEPT and DISPLAY statements a la R/M COBOL. Specifically I used the the SIZE, REVERSE, and ERASE capabilities. Is there a way to compile TC with these capabilities? -- John Culleton |
|
From: John R. C. <jo...@we...> - 2005-09-08 23:22:10
|
On Thursday 08 September 2005 04:28 pm, John R. Culleton wrote: > I am pursuing this activity with some determination. I can > DISPLAY text successfully. I discovered that the header > Content-type=html/text > isn't really necessary. But the totall empty line that goes > before the first real DISPLAY statement is necessary. > > Now I am ready to start importing the fields of a FORM. I can > deconstruct the message after I get it, but my problem is that > my COBOL program never gets any input. Here is the web page: <snip> I solved the problem in an unexpected way. I changed from TinyCOBOL to OpenCOBOL. This was unexpected because in general TC has more features than OC. But for this app on my computer at least OC works and TC doesn't. Very interesting. -- John Culleton |
|
From: John R. C. <jo...@we...> - 2005-09-08 20:32:31
|
I am pursuing this activity with some determination. I can
DISPLAY text successfully. I discovered that the header
Content-type=html/text
isn't really necessary. But the totall empty line that goes
before the first real DISPLAY statement is necessary.
Now I am ready to start importing the fields of a FORM. I can
deconstruct the message after I get it, but my problem is that
my COBOL program never gets any input. Here is the web page:
---------------------------------------------------------
<html>
<body>
<FORM ACTION="/cgi-bin/test3.cgi" METHOD="POST">
<PRE>
First Name: <INPUT TYPE="text" NAME="first">
Nickname <INPUT TYPE=text" NAME="nickname">
<INPUT TYPE="submit"> <INPUT TYPE="reset">
</PRE>
</FORM>
</body>
</html>
-----------------------------------------------------------------
And here is the COBOL
-----------------------------------------------------------------
000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. TEMPLATE.
000030 AUTHOR. JOHN CULLETON.
000040 INSTALLATION. WEXFORDPRESS
000045 Eldersburg MD.
000050*REMARKS.
000060* THIS IS A TEMPLATE FOR OPEN COBOL AND HTCOBL.
000070 ENVIRONMENT DIVISION.
000080
000090 CONFIGURATION SECTION.
000100 SOURCE-COMPUTER.
000110 Linux.
000120 OBJECT-COMPUTER.
000230 Linux.
000140
000150 INPUT-OUTPUT SECTION.
000160 FILE-CONTROL.
000170 SELECT HOLDFILE ASSIGN TO "holdit".
000180 DATA DIVISION.
000190
000200 FILE SECTION.
000210 FD HOLDFILE.
01 HOLDREC PICTURE X(80).
000220 WORKING-STORAGE SECTION.
000230
01 BIGFIELD PICTURE X(80).
000240 PROCEDURE DIVISION.
000250 001-MAIN-PROCEDURE.
000260 DISPLAY "Content-type: text/plain".
DISPLAY "".
OPEN OUTPUT HOLDFILE.
ACCEPT BIGFIELD (1:79).
WRITE HOLDREC FROM BIGFIELD.
ACCEPT BIGFIELD (1:79).
WRITE HOLDREC FROM BIGFIELD.
CLOSE HOLDFILE.
DISPLAY "MARKER 2" BIGFIELD.
000270 STOP RUN.
---------------------------------------------
The only thing I get is the "MARKER 2" message.
I have tried the FORM statement with both GET and POST.
|
|
From: Andrew C. <apc...@so...> - 2005-09-04 20:39:10
|
Hi Hudson, We are all sorry to see you leave. I know how other commitments make It impossible for those of us to started out in the beginning to Commit the time we did back then. It is now up to the new members to Run with the project. Thank you for your commitment to the project. Regards Andrew Cameron ---------------------------------------------- Ordinary people are making EXTRAORDINARY money WORKING FROM HOME on the Internet! Get FREE info by email. =20 Send your request to : mailto:myo...@ge... Andrew Cameron e-Mail: apc...@so... URL: http://www.myownbusinessathome.com URL: http://www.moreinfo247.com/8763637/FREE URL: http://www.empowerism.com/e/96001 URL: http://signups-guaranteed.us/affiliates/2887072.php ---------------------------------------------- -----Original Message----- From: tin...@li... [mailto:tin...@li...] On Behalf Of = Hudson Reis Sent: Sunday, September 04, 2005 11:32 AM To: tin...@li...; cob...@li... Subject: [Tiny-cobol-users] Leaving the TinyCOBOL and COBOL-Utils = projects Hi friends: I'm leaving the TC and COBOL-Utils project. There isn't exist a specific or personal reason. Just the time missing. My personal and professional life change a lot in these last two years=20 and today I need to handle some responsabilities that I don't have=20 before. :) There a long time that I'm leaving our project in a dark side of my=20 priorities just because I'm working at full time, studying at university = at night, studying at home in weekends and taking care about the things=20 that wasn't solved during the week. With this responsabilities, the free time is very little and if I use it = to contribute in our projects, probably I will leave of have my personal = life. As all we know, without a personal life, the professional life=20 doesn't exist. :( I already removed my sourceforge accounts and I added like an admin=20 Fernando Wuthstrack, owner of InfoCont Sistemas Integrados Ltda(1), a TC = real user and a TC advocate in the last two years, one time that Rildo,=20 David and Bernard is not contributing anymore, and Andrew is not a a TC=20 or COBOL-Utils admin. I added Walter Garrote like a developer for he can do the commits in our = SF CVS server. For anyone lost any information with my out, I'm doing a package with=20 all informations that I got of our projects. I don't have time to finish = it in this weekend but I will finish this package and let it avaliable=20 to download in my website in the next week. I see yours in the next week. Thank you for all attention. Hudson. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO = September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile = & Plan-Driven Development * Managing Projects & Teams * Testing & QA = Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Tin...@li... https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users --=20 No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.18/89 - Release Date: 9/2/2005 =20 |
|
From: Hudson R. <hud...@gm...> - 2005-09-04 15:40:54
|
Hi friends: I'm leaving the TC and COBOL-Utils project. There isn't exist a specific or personal reason. Just the time missing. My personal and professional life change a lot in these last two years and today I need to handle some responsabilities that I don't have before. :) There a long time that I'm leaving our project in a dark side of my priorities just because I'm working at full time, studying at university at night, studying at home in weekends and taking care about the things that wasn't solved during the week. With this responsabilities, the free time is very little and if I use it to contribute in our projects, probably I will leave of have my personal life. As all we know, without a personal life, the professional life doesn't exist. :( I already removed my sourceforge accounts and I added like an admin Fernando Wuthstrack, owner of InfoCont Sistemas Integrados Ltda(1), a TC real user and a TC advocate in the last two years, one time that Rildo, David and Bernard is not contributing anymore, and Andrew is not a a TC or COBOL-Utils admin. I added Walter Garrote like a developer for he can do the commits in our SF CVS server. For anyone lost any information with my out, I'm doing a package with all informations that I got of our projects. I don't have time to finish it in this weekend but I will finish this package and let it avaliable to download in my website in the next week. I see yours in the next week. Thank you for all attention. Hudson. |
|
From: Merlin M. <mmo...@gm...> - 2005-08-29 18:18:24
|
On 8/19/05, Jim Morcombe <ro...@vi...> wrote: > Merlin >=20 > If this product was available, then I would certainly be interested, >=20 > As for the work involved in doing it - developers seem to be very short > on the ground at the moment. Well of course I would have to undertake any such effort myself :). I looked at the tinycobol sources for a bit to see how things are built and got a feel for the major challenges. I think the first and most important challenge is to abstract the file interface so that it can be selectable, preferrably on a per-file basis. I think the easiest way to do this is to move all file i/o calls behind a table of function pointers that can be linked in and swapped out at runtime. This leads to next major challenge which is to consider reorganizing the file interface a bit. For example, it might be worthwhile to consider separating the sequential, relative and indexed interfaces.=20 (maybe not). Also, the field information for all the fields that contain data need to be emitted from the cobol compiler at compile time (to be loaded when the file is opened) or passed through all the interface functions. Sorry if I'm presuming to much, I just dont all my hard work to go to waste. Our ISAM bridge here actually works better than the vendor supplied file system in most respects. Merlin |
|
From: John R. C. <jo...@we...> - 2005-08-24 17:33:57
|
After linking some names I got this program to compile clean via the Makefile. But when running it I get the error: /testgui01: error while loading shared libraries: libtcl.so: cannot open shared object file: No suchfile or directory Here is a listing from /usr/local/lib: -rwxrwxrwx 4 safe users 782964 2005-02-24 15:56 /usr/local/lib/libtcl* -rwxrwxrwx 4 safe users 782964 2005-02-24 15:56 /usr/local/lib/libtcl.so* -rwxrwxrwx 4 safe users 782964 2005-02-24 15:56 /usr/local/lib/libtcl8.4.so* -rwxrwxrwx 1 safe users 1732 2005-02-24 15:56 /usr/local/lib/libtclstub8.4.a* Here is a snippet from the /usr/local/share/htcobol/htcobolrc. I I added /usr/local/lib to the first line: LD_PATH: -L../../../lib -L../../lib -L/usr/local/lib #LD_PATH: # Libraries to pass to the link step # LD_LIBS: Obsolete - Use variables below # LD_HT1_LIBS: -lhtcobol #LD_HT2_LIBS: -lhtcobol2 #LD_MATH_LIBS: -lm LD_MATH_LIBS: -lm LD_READLINE_LIBS: -lreadline LD_EXTRA_LIBS: -ldl LD_DCALL_LIBS: -ldl #LD_DLOAD_LIBS: -lltdl #LD_DLOAD_LIBS: @htg_ld_args_ltdl@ LD_TERM_LIBS: -lncurses #LD_TERM_LIBS: -lpdcurses #LD_IO_LIBS: -ldb LD_IO_LIBS: -ldb ---------------------------------------------- I tried it without running mak.sh and with running mak.sh before compiling. -- John Culleton |
|
From: John R. C. <jo...@we...> - 2005-08-24 11:20:05
|
Pakced decimal, traditionally called COMPUTAIONAL-3, was basd on the hardware capabilities for the EBCDIC based IBM mainframes. The Intel 86 instruction set also allows us to put two decimal digits in a byte, but isn't nearly as handy for doing decimal arithmetic. So I have two questions: 1. In Tiny COBOL does the compiled program actually put two decimal digits in a PACKED-DECIMAL byte? 2. Is there any efficiency advantage in doing arithmetic on data fields classed as PACKED-DECIMAL as opposed to those classed as DISPLAY? (Of course being a traditionalist I always say COMP-3 in a program but some fool will abolish that form eventually.) -- John Culleton |
|
From: John R. C. <jo...@we...> - 2005-08-20 16:19:33
|
On Saturday 20 August 2005 02:01 pm, Jim Morcombe wrote:
> John
>
> I've got to disagree with you.
>
> The EVALUATE TRUE allows a whole heap of spagetti-coded IF, THEN, ELSEs
> to be replaced by a nice easy-to-follow slab of structured code. Just
> because Cobol 74 programmers never learnt new tricks doesn't doesn't
> mean they weren't worth learning.
>
> The EVALUATE TRUE improves program structure and anything that improves
> program structure needs to be supported.
>
> Jim
Well I have four problems with that.
First I don't understand EVALUATE TRUE.
Second I have four texts on my desk which
allegedly cover COBOL 85. Only the newest of these (pub date
2000) gives an example of EVALUATE TRUE and it is identical in
effect to a straight EVALUATE. The word TRUE could be omitted.
Two of these books represent the entire COBOL library of the
local community college.
Third since I don't know what it does obviously I have no
knowledge of a situation where it would be necessary or even
useful. Perhaps you can offer one.
I cannot offer an example of using EVALUATE TRUE because frankly
I don't understand it. But here is a fragment from a real
program written 25 years ago that I converted to EVALUATE form:
(example 1.)
EVALUATE SCREEN-FLAG
WHEN "L" PERFORM 150-INPUT-SCREEN
WHEN "E" PERFORM 200-CLEAR-FIELDS
PERFORM 400-ENTER-DATA
WHEN "C" PERFORM 400-ENTER-DATA
WHEN "O" PERFORM 405-SINGLE-ENTRY
WHEN "S" PERFORM 300-SHOW-SCREEN
WHEN "D" PERFORM 200-CLEAR-FIELDS
END-EVALUATE
EXIT PROGRAM.
-----------and here is an alternative form that I think is more
readable:
(example-2.)
IF LOAD PERFORM 150-INPUT-SCREEN.
IF ENTER-ALL PERFORM 200-CLEAR FIELDS
PERFORM 400-ENTER DATA.
IF CHANGE-ALL PERFORM 400-ENTER DATA.
IF CHANGE-ONE PERFORM 405-SINGLE-ENTRY.
IF SHOW PERFORM 300-SHOW-SCREEN.
IF CLEAR PERFORM 200-CLEAR-FIELDS.
EXIT PROGRAM.
Why no ELSE IF? Because the field SCREEN-FLAG can only hold one
value at a time. Therefore fall-through logic works. This would
be true for any real world WHEN type test.
Finally the ELSE IF logic can also be used to good effect. This is a
more general construct than example-2. IMO it is not spaghetti code. YMMV.
(example-3.)
IF LOAD PERFORM 150-INPUT-SCREEN
ELSE IF
ENTER-ALL PERFORM 200-CLEAR FIELDS
PERFORM 400-ENTER DATA
ELSE IF
CHANGE-ALL PERFORM 400-ENTER DATA
ELSE IF
CHANGE-ONE PERFORM 405-SINGLE-ENTRY
ELSE IF
SHOW PERFORM 300-SHOW-SCREEN
ELSE IF
CLEAR PERFORM 200-CLEAR-FIELDS.
EXIT PROGRAM.
The word WHEN has been replaced by ELSE IF. The effect is the
same.
Examples 2 and 3 use condition names. Example 1 doesn't.
Why? because condition names in a WHEN statement
gave an error in Tiny COBOL. Now that is something that needs
fixing.
John Culleton
|
|
From: Jim M. <ro...@vi...> - 2005-08-20 14:07:04
|
John I've got to disagree with you. The EVALUATE TRUE allows a whole heap of spagetti-coded IF, THEN, ELSEs to be replaced by a nice easy-to-follow slab of structured code. Just because Cobol 74 programmers never learnt new tricks doesn't doesn't mean they weren't worth learning. The EVALUATE TRUE improves program structure and anything that improves program structure needs to be supported. Jim John R. Culleton wrote: >On Saturday 20 August 2005 06:44 am, Arnold Trembley wrote: > > >>Jim Morcombe's sample COBOL program is perfectly legal COBOL. It >>compiles cleanly under Realia COBOL, the ANSI-85 "educational" version >>from about 1990. Of course, it does nothing upon execution. >> >>If you use the EVALUATE TRUE option, you can put pretty much any >>conditional statement you want in a WHEN clause. >> >>With kindest regards, >> >> > > >I have already been corrected on the matter of EVALUATE TRUE. It >appears that the EVALUATE construct is a marvel of complexity, >of which I have barely scratched the surface. But this very >complexity and power raises two additional questions: > >1. Is it sound programming practice to utilize all the arcane >variations of the EVALUATE verb? If I were bossing a programming >shop today I would be cautious about allowing programmers to use >every obscure variant of EVALUATE when there are other more >familiar options that will handle the program logic equally well. >In other words in my view all these variations fall in the "nice >to have" rather than the "got to have" category. The primary >COBOL objective of writing useful and maintainable code might be >compromised. > >2. More immediately, should we expect the maintainers of Tiny >COBOL to implement each and every new variant? At what point >does TC cease to be tiny? Remember that some standard texts on >COBOL acknowledge EVALUATE TRUE in an appendix but do not attempt to >teach it in the main text. > >It would be nice if the COBOL standard were broken down into >required and optional features. Then COBOL shops could write to >the standard subset and ensure both portablility across >compilers and understandability by all programmers. Those who >wanted to toy with every variant could find an appropriate >compiler and play to their heart's content. > >Years ago I headed up a programming shop that was given control >over the programmers in a newly acquired division in another >state. They had with the help of IBM taught themselves and got >working that monster PL/I. My internal standard already >specified COBOL for business type tasks and FORTRAN for >scientific/engineering work. I allowed them to continue with >PL/I instead of rewriting everything in COBOL. But I would have >been much happier if I had never been faced with the decision. >Similarly we face the potential of the same sort of tower of >babel in the COBOL community, IF THEN ELSE shops versus EVALUATE >shops, structured programming shops a la Murach and Noll versus >objective COBOl shops and so on. > >But I digress... > > > |
|
From: John R. C. <jo...@we...> - 2005-08-20 13:24:19
|
On Saturday 20 August 2005 06:44 am, Arnold Trembley wrote: > Jim Morcombe's sample COBOL program is perfectly legal COBOL. It > compiles cleanly under Realia COBOL, the ANSI-85 "educational" version > from about 1990. Of course, it does nothing upon execution. > > If you use the EVALUATE TRUE option, you can put pretty much any > conditional statement you want in a WHEN clause. > > With kindest regards, I have already been corrected on the matter of EVALUATE TRUE. It appears that the EVALUATE construct is a marvel of complexity, of which I have barely scratched the surface. But this very complexity and power raises two additional questions: 1. Is it sound programming practice to utilize all the arcane variations of the EVALUATE verb? If I were bossing a programming shop today I would be cautious about allowing programmers to use every obscure variant of EVALUATE when there are other more familiar options that will handle the program logic equally well. In other words in my view all these variations fall in the "nice to have" rather than the "got to have" category. The primary COBOL objective of writing useful and maintainable code might be compromised. 2. More immediately, should we expect the maintainers of Tiny COBOL to implement each and every new variant? At what point does TC cease to be tiny? Remember that some standard texts on COBOL acknowledge EVALUATE TRUE in an appendix but do not attempt to teach it in the main text. It would be nice if the COBOL standard were broken down into required and optional features. Then COBOL shops could write to the standard subset and ensure both portablility across compilers and understandability by all programmers. Those who wanted to toy with every variant could find an appropriate compiler and play to their heart's content. Years ago I headed up a programming shop that was given control over the programmers in a newly acquired division in another state. They had with the help of IBM taught themselves and got working that monster PL/I. My internal standard already specified COBOL for business type tasks and FORTRAN for scientific/engineering work. I allowed them to continue with PL/I instead of rewriting everything in COBOL. But I would have been much happier if I had never been faced with the decision. Similarly we face the potential of the same sort of tower of babel in the COBOL community, IF THEN ELSE shops versus EVALUATE shops, structured programming shops a la Murach and Noll versus objective COBOl shops and so on. But I digress... -- John Culleton |
|
From: Arnold T. <arn...@wo...> - 2005-08-20 06:45:09
|
John R. Culleton Morcombe wrote: > > Message: 2 > From: "John R. Culleton" <jo...@we...> > Organization: WexfordPress > To: tin...@li... > Subject: Re: [Tiny-cobol-users] A problem with EVALUATE > Date: Fri, 19 Aug 2005 08:06:05 +0000 > Cc: Jim Morcombe <ro...@vi...> > > On Friday 19 August 2005 07:50 am, Jim Morcombe wrote: > >>Here is another cut down listing. >> >>It demonstrates what I believe to be a bug in the compiler concerning >>the EVALUATE statement. >> >>When I compile it, I get the following error message: >> >>jim.cbl: 18: error: incompatible selection object, on or before '=' >> >>Jim >> >> IDENTIFICATION DIVISION. >> 2 000300 PROGRAM-ID. rgmssch. >> 3 001200 ENVIRONMENT DIVISION. >> 4 001700 >> 5 001900 DATA DIVISION. >> 6 002100 FILE SECTION. >> 7 002300 >> 8 002500 WORKING-STORAGE SECTION. >> 9 >> 10 01 LICENCE-DAYS PIC 9(5). >> 11 >> 12 >> 13 >> 14 019500 PROCEDURE DIVISION. >> 15 020200 MAINLINE. >> 16 >> 17 EVALUATE TRUE >> 18 WHEN LICENCE-DAYS = ZERO >> 19 CONTINUE >> 20 END-EVALUATE. > > > > I am not familiar with such a construct. According to the books > I have, (three at the moment) you EVALUATE FIELDNAME. > > And then the following WHEN statements are equivalent to > IF FIELDNAME = (value) (executable statement) > ELSE IF.... > > The EVALUATE TRUE statement in your program does not refer to a field name > but a condition-name. This in turn requires a level 88 appended > to a field name in e.g., WORKING STORAGE. > > CONTINUE is used in an IF statement. I have not found it used in > a EVALUATE statement. > > TRUE is not a field but a condition name attributed to a field > that has an 88 statement like: > > O1 WS-ANOTHER-RECORD PICTURE X. > 88 ANOTHER-RECORD VALUE "Y" FALSE "N". > > EVALUATE with WHEN statements is an alternative to the use of IF with > condition > names. Don't mix the two. Jim Morcombe's sample COBOL program is perfectly legal COBOL. It compiles cleanly under Realia COBOL, the ANSI-85 "educational" version from about 1990. Of course, it does nothing upon execution. If you use the EVALUATE TRUE option, you can put pretty much any conditional statement you want in a WHEN clause. With kindest regards, -- http://arnold.trembley.home.att.net/ |
|
From: Merlin M. <mmo...@gm...> - 2005-08-19 18:56:33
|
Hello, It may interest you to know that I have successfully integrated PostgreSQL with AcuCorp AcuCobol without using embedded sql. I did this by creating a wrapper for libpq (the C interface library for PostgreSQL) that generates queries from COBOL ISAM file i/o statements. I would like to open source the project but cannot because AcuCorp will not publish key headers necceary to link the libpq library to PostgreSQL as a file system. The performance of the PostgreSQL ISAM bridge (which I call PostISAM) is excellent and competitive with the built in file system. It may be possible to make a similar effort with TinyCOBOL. This would take a fair amount of work to remove the AcuCorp specific parts and to make everything compile within gcc. Do you guys think there would be any interest in this. Some of the features of PostISAM: * full support for row-level locks without using locktables. * automatic copybook generation from tables and views. * client side logging faclities (file trace). * support for many (but not all) cobol datatypes * full support for all file verbs including all combinations of start and read nex/previous Merlin |
|
From: John R. C. <jo...@we...> - 2005-08-19 16:52:30
|
On Friday 19 August 2005 04:27 pm, Jim Morcombe wrote: > John > > You must realise,Little Grasshopper, that the Cobol EVALUATE is a > statement of unimaginable power that outstrips the wimpy little case > statements and switch seen in other languages. > > The EVALUATE TRUE form is one of many that are available under Cobol 85 > that many people are not aware of. Including many authors of $85 textbooks. In any case I leave it to you to debug his code. EVALUATE is neat, but unnecessary, like most of the added features of COB 85. COB 85 is for the most part harmless (I do not miss ALTER) but it does bog down the compiler writer with more features to implement and the programmer with more arcane forms to understand when reading someone else's code. I think I will write a book called "Simple COBOL" that will deal with the necessary subset, not the expanding universe of new forms and new incompatibilities. Or as my father used to say, "things left off the automobile don't ever break down." John C. |
|
From: Jim M. <ro...@vi...> - 2005-08-19 16:41:57
|
John Also see http://www.csis.ul.ie/COBOL/Course/Selection.htm for more info on Evaluate. Jim |
|
From: Jim M. <ro...@vi...> - 2005-08-19 16:33:16
|
John You must realise,Little Grasshopper, that the Cobol EVALUATE is a statement of unimaginable power that outstrips the wimpy little case statements and switch seen in other languages. The EVALUATE TRUE form is one of many that are available under Cobol 85 that many people are not aware of. http://www.damos.dircon.co.uk/html/cobol_evaluate_verb.html We still get asked about using EVALUATE quite a lot, especially using multiple conditions on EVALUATE statements, so here are some quick pointers to using this statement. EVALUATE can be used in place of IF statements, it can often make the program more readable when you have complex nested conditions. In it's simplest form the EVALUATE statement goes something like this: EVALUATE condition WHEN value imperative-statements WHEN value imperative statements ........... END-EVALUATE. Here's a simple example: EVALUATE WS-X WHEN 1 ADD 15 TO WS-TOTAL PERFORM A-100-REPORT WHEN 2 ADD 16 TO WS-TOTAL MOVE 'WS-X IS 2' TO WS-DISPLAY PERFORM A-200-REPORT WHEN OTHER PERFORM X-100-ERROR END-EVALUATE. This will check the value of the variable WS-X and execute the statements depending on the value. Note the use of WHEN OTHER this will be executed if WS-X does not match any of the values, so in the example if WS-X is not equal to 1 or 2 then PERFORM X-100-ERROR will be executed. Sometimes you will want to have multiple conditions with lots of ANDs and ORs in an EVALUATE statement as you would in an IF statement. To do this with EVALUATE requires a slightly different approach. One way is to use EVALUATE TRUE (or EVALUATE FALSE). for example EVALUATE TRUE WHEN WS-X = 1 AND WS-Y = 2 PERFORM X-100-PROCESS1 WHEN WS-X =1 AND WS-Y NOT = 2 PERFORM X-200-PROCESS2 END-EVALUATE. Here, the whole condition on the WHEN statement is checked and if it is TRUE then the associated statement(s) are executed. The second way to do this is using EVALUATE ... ALSO. EVALUATE WS-AGE ALSO WS-SEX ALSO WS-WEIGHT WHEN 21 ALSO 'M' ALSO 150 PERFORM A-200-ACCEPT WHEN OTHER PERFORM A-300-DECLINE END-EVALUATE. In this example if WS-AGE is 21 AND WS-SEX is 'M' AND WS-WEIGHT is 150 then PERFORM A-200-ACCEPT is executed, if not then PERFORM A-300-DECLINE is executed. You can combine ALSO with the TRUE and FALSE conditions, so you could have EVALUATE TRUE ALSO FALSE for example. John R. Culleton wrote: >On Friday 19 August 2005 07:50 am, Jim Morcombe wrote: > > >>Here is another cut down listing. >> >>It demonstrates what I believe to be a bug in the compiler concerning >>the EVALUATE statement. >> >>When I compile it, I get the following error message: >> >>jim.cbl: 18: error: incompatible selection object, on or before '=' >> >>Jim >> >> IDENTIFICATION DIVISION. >> 2 000300 PROGRAM-ID. rgmssch. >> 3 001200 ENVIRONMENT DIVISION. >> 4 001700 >> 5 001900 DATA DIVISION. >> 6 002100 FILE SECTION. >> 7 002300 >> 8 002500 WORKING-STORAGE SECTION. >> 9 >> 10 01 LICENCE-DAYS PIC 9(5). >> 11 >> 12 >> 13 >> 14 019500 PROCEDURE DIVISION. >> 15 020200 MAINLINE. >> 16 >> 17 EVALUATE TRUE >> 18 WHEN LICENCE-DAYS = ZERO >> 19 CONTINUE >> 20 END-EVALUATE. >> >> > > >I am not familiar with such a construct. According to the books >I have, (three at the moment) you EVALUATE FIELDNAME. > >And then the following WHEN statements are equivalent to >IF FIELDNAME = (value) (executable statement) >ELSE IF.... > >The EVALUATE TRUE statement in your program does not refer to a field name >but a condition-name. This in turn requires a level 88 appended >to a field name in e.g., WORKING STORAGE. > >CONTINUE is used in an IF statement. I have not found it used in >a EVALUATE statement. > >TRUE is not a field but a condition name attributed to a field >that has an 88 statement like: > > O1 WS-ANOTHER-RECORD PICTURE X. > 88 ANOTHER-RECORD VALUE "Y" FALSE "N". > >EVALUATE with WHEN statements is an alternative to the use of IF with >condition >names. Don't mix the two. > > |
|
From: John R. C. <jo...@we...> - 2005-08-19 12:09:18
|
On Friday 19 August 2005 07:50 am, Jim Morcombe wrote:
> Here is another cut down listing.
>
> It demonstrates what I believe to be a bug in the compiler concerning
> the EVALUATE statement.
>
> When I compile it, I get the following error message:
>
> jim.cbl: 18: error: incompatible selection object, on or before '='
>
> Jim
>
> IDENTIFICATION DIVISION.
> 2 000300 PROGRAM-ID. rgmssch.
> 3 001200 ENVIRONMENT DIVISION.
> 4 001700
> 5 001900 DATA DIVISION.
> 6 002100 FILE SECTION.
> 7 002300
> 8 002500 WORKING-STORAGE SECTION.
> 9
> 10 01 LICENCE-DAYS PIC 9(5).
> 11
> 12
> 13
> 14 019500 PROCEDURE DIVISION.
> 15 020200 MAINLINE.
> 16
> 17 EVALUATE TRUE
> 18 WHEN LICENCE-DAYS = ZERO
> 19 CONTINUE
> 20 END-EVALUATE.
I am not familiar with such a construct. According to the books
I have, (three at the moment) you EVALUATE FIELDNAME.
And then the following WHEN statements are equivalent to
IF FIELDNAME = (value) (executable statement)
ELSE IF....
The EVALUATE TRUE statement in your program does not refer to a field name
but a condition-name. This in turn requires a level 88 appended
to a field name in e.g., WORKING STORAGE.
CONTINUE is used in an IF statement. I have not found it used in
a EVALUATE statement.
TRUE is not a field but a condition name attributed to a field
that has an 88 statement like:
O1 WS-ANOTHER-RECORD PICTURE X.
88 ANOTHER-RECORD VALUE "Y" FALSE "N".
EVALUATE with WHEN statements is an alternative to the use of IF with
condition
names. Don't mix the two.
--
John Culleton
Books with answers to marketing and publishing questions:
http://wexfordpress.com/tex/shortlist.pdf
Book coaches, consultants and packagers:
http://wexfordpress.com/tex/packagers.pdf
|
|
From: Jim M. <ro...@vi...> - 2005-08-19 07:50:53
|
Here is another cut down listing.
It demonstrates what I believe to be a bug in the compiler concerning
the EVALUATE statement.
When I compile it, I get the following error message:
jim.cbl: 18: error: incompatible selection object, on or before '='
Jim
IDENTIFICATION DIVISION.
2 000300 PROGRAM-ID. rgmssch.
3 001200 ENVIRONMENT DIVISION.
4 001700
5 001900 DATA DIVISION.
6 002100 FILE SECTION.
7 002300
8 002500 WORKING-STORAGE SECTION.
9
10 01 LICENCE-DAYS PIC 9(5).
11
12
13
14 019500 PROCEDURE DIVISION.
15 020200 MAINLINE.
16
17 EVALUATE TRUE
18 WHEN LICENCE-DAYS = ZERO
19 CONTINUE
20 END-EVALUATE.
21
|
|
From: Fred M. <fr...@mo...> - 2005-08-18 18:24:49
|
Jim Morcombe wrote: > > Here is a "cut down" listing of a program. > > The Working Storage variable, "DISPLAY-SELECTIONS" is defined a little > stranglely, but I think it should be legal. > > If I add the "03 FILLER." that the programmer forgot, then the program > compiles without an error. Without this "03 FILLER", the compiler > reports an error message when the variable S01-SELECT-LINE() is used. > > 000100 IDENTIFICATION DIVISION. > 000300 PROGRAM-ID. rgmssch. > 001200 ENVIRONMENT DIVISION. > 001700 > 001900 DATA DIVISION. > 002100 FILE SECTION. > 002300 > 002500 WORKING-STORAGE SECTION. > 003400 01 DISPLAY-SELECTIONS. > * When the following line is commented out, the compiler > * returns an error. > * 03 FILLER. > 003600 05 ROW-DISPLAY-SELECTIONS PIC 99 > 003700 VALUE ZERO. > 03 SC-S01-SELECT-LINE OCCURS 12 TIMES. > 05 S01-SELECT-LINE PIC X(17). I'm glad the compiler returns an error in case of the missing line with the 03 level. While I cannot find this described in the standard nice teachers learned me in the past that a certain form of symmetry is supposed with regard to the level numbers. in the above structure the level-number 02 cannot be used while 04 is acceptable. On the other hand, the level-number 03 for ROW-DISPLAY-SELECTIONS would be quite usable and removes the need for the FILLER line. -- Fred Mobach - fr...@mo... - pos...@mo... Systemhouse Mobach bv - The Netherlands - since 1976 website : http://fred.mobach.nl Q: servos ad pileum vocare ? A: servos fenestrae ad pileum rubrem vocare ! |
|
From: Fred M. <fr...@mo...> - 2005-08-18 17:05:31
|
(reposted after re-editing)
Jim Morcombe wrote:
>
> I have found a problem in my own conversion routines (not with Tiny
> Cobol) and am thinking about how to resolve it.
>
> I have a few files with strangely defined keys. Here is an example:
>
> 01 SOME-FILE-RECORD.
> 05 SOME-FILE-KEY.
> 07 SOME-FILE-KEY-NAME PIC X(5).
> 05 ANOTHER-FIELD PIC X(2).
> 05 Etc.
This data structure seems quite common to me.
> In the SELECT statement, the key name is defined as "SOME-FILE-KEY".
> However, in the START statement, the key is referred to as
> "SOME-FILE-KEY-NAME".
According to ISO/IEC FCD 1989 page 537 the START format contains :
data-name-1
START filename-1 [ KEY relational-operator { ----------------- } etc.
record-key-name-1
So the use of SOME-FILE-KEY in your example is the use of
record-key-name-1, the use of SOME-FILE-KEY-NAME is the use of
data-name-1. Both forms are correct.
--
Fred Mobach - fr...@mo... - pos...@mo...
Systemhouse Mobach bv - The Netherlands - since 1976
website : http://fred.mobach.nl
Q: servos ad pileum vocare ?
A: servos fenestrae ad pileum rubrem vocare !
|
|
From: Fred M. <fr...@mo...> - 2005-08-18 16:59:48
|
Jim Morcombe wrote:
>
> I have found a problem in my own conversion routines (not with Tiny
> Cobol) and am thinking about how to resolve it.
>
> I have a few files with strangely defined keys. Here is an example:
>
> 01 SOME-FILE-RECORD.
> 05 SOME-FILE-KEY.
> 07 SOME-FILE-KEY-NAME PIC X(5).
> 05 ANOTHER-FIELD PIC X(2).
> 05 Etc.
This data structure seems quite common to me.
> In the SELECT statement, the key name is defined as "SOME-FILE-KEY".
> However, in the START statement, the key is referred to as
> "SOME-FILE-KEY-NAME".
According to ISO/IEC FCD 1989 page 537 the START format contains :
data-name-1
START filename-1 [ FIRST | LAST | KEY relational-operator {
----------------- } etc.
record-key-name-1
So the use of SOME-FILE-KEY in your example is the use of
record-key-name-1, the use of SOME-FILE-KEY-NAME is the use of
data-name-1. Both forms are correct.
--
Fred Mobach - fr...@mo... - pos...@mo...
Systemhouse Mobach bv - The Netherlands - since 1976
website : http://fred.mobach.nl
Q: servos ad pileum vocare ?
A: servos fenestrae ad pileum rubrem vocare !
|
|
From: Jim M. <ro...@vi...> - 2005-08-18 16:36:39
|
Here is a "cut down" listing of a program.
The Working Storage variable, "DISPLAY-SELECTIONS" is defined a little
stranglely, but I think it should be legal.
If I add the "03 FILLER." that the programmer forgot, then the program
compiles without an error. Without this "03 FILLER", the compiler
reports an error message when the variable S01-SELECT-LINE() is used.
Jim
000100 IDENTIFICATION DIVISION.
000300 PROGRAM-ID. rgmssch.
001200 ENVIRONMENT DIVISION.
001700
001900 DATA DIVISION.
002100 FILE SECTION.
002300
002500 WORKING-STORAGE SECTION.
003400 01 DISPLAY-SELECTIONS.
* When the following line is commented out, the compiler
* returns an error.
* 03 FILLER.
003600 05 ROW-DISPLAY-SELECTIONS PIC 99
003700 VALUE ZERO.
03 SC-S01-SELECT-LINE OCCURS 12 TIMES.
05 S01-SELECT-LINE PIC X(17).
019500 PROCEDURE DIVISION.
020200 MAINLINE.
MOVE SPACES TO S01-SELECT-LINE(1).
|
|
From: Jim M. <ro...@vi...> - 2005-08-15 05:05:21
|
Dave, I am using gcc version 3.2 and bison version 1.35 here is the result of a "gcc -v" [jim@byrlin3 jim]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Here is the result of a "bison -V" [jim@byrlin3 jim]$ bison -V bison (GNU Bison) 1.35 Copyright 1984, 1986, 1989, 1992, 2000, 2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [jim@byrlin3 jim]$ David Essex wrote: > Jim, I can't duplicate any of the problems you have encountered, no > matter what option I try. > > What versions of GCC and Bison are you using ? > > Jim Morcombe wrote: > > > I tried out your work-arounds to get around the compiler crash. > > > > My preferred work-around would have been to play with the path > > by adding an extra delimited or a dummy path as then I could > > leave the Cobol source untouched. > > However, it didn't help. > > > > Moving the Copybook into my working directory didn't help either. > > Walter suggested not using either '-I' or environment variables on the > command line. > Did you try this option ? > > > > Placing the name of the Copybook in Quotes ( COPY "GLBAL-IO-WS") > > resolved two of my examples. These were the cases where I'd also > > managed to get the compiler to work by renaming the Copybook. > > By placing the copybook name on quotes, the resource file defined > suffixes are not added to the name. > > > > My third example wasn't resolved. This was the example where renaming > > the Copybook also didn't allow the program to compile - but when > > editted the Copybook and commented out a random line, the program did > > compile. > > If you add an extra comment line some where, does the program compile ? > > > > All three of these Copybooks were automatically generated by a program > > that reads through the "FD" for a file. Hence I am reasonably > > confident that the examples are similar and that there are no > > unique programming error of typing mistakes that exist in just one > > or two of these Copybooks.. > > > > It also means that if I have to, I can modify my conversion programs > > to automatically place Quotes in these COPY statements - but that > > still doesn't solve the third example. > > All these work-arounds are not really a solution, as there is no point > on having compiler features if you can't use them. > > > |
|
From: Jim M. <ro...@vi...> - 2005-08-15 05:00:34
|
I have found a problem in my own conversion routines (not with Tiny
Cobol) and am thinking about how to resolve it.
I have a few files with strangely defined keys. Here is an example:
01 SOME-FILE-RECORD.
05 SOME-FILE-KEY.
07 SOME-FILE-KEY-NAME PIC X(5).
05 ANOTHER-FIELD PIC X(2).
05 Etc.
In the SELECT statement, the key name is defined as "SOME-FILE-KEY".
However, in the START statement, the key is referred to as
"SOME-FILE-KEY-NAME".
Obviously these refer to the same field and MicroFocus Cobol is quite
happy with this. I had assumed that "SOME-FILE-KEY" would be used.
There will often be multiple fields within the key at the "07" level and
in these cases the "05" field name would have to be used.
Is it legal to use "SOME-FILE-KEY-NAME" in the START statement?
Does TinyCobol allow SOME-FILE-KEY-NAME to be used?
Even if it is legal, do others see this as an acceptable programming
practice?
Jim
|
|
From: Jim M. <ro...@vi...> - 2005-08-15 04:48:09
|
Dave If I move my Copybook into my working directory and compile it without changing the Include Path, then the compiler still crashes. If I remove the "-I $IO" from the compiler comand, then it compiles correctly. Jim |
24 messages has been excluded from this view by a project administrator.
