Menu
▾
▴
tiny-cobol-users
|
From: David E. <de...@ar...> - 2002-06-05 04:06:33
|
At 09:25 PM 04/06/02 -0700, Eric Estes wrote: > That didn't work either. This had me stumped. > ... > Beginning DB library header search sequence > checking for db3/db_185.h... yes > Beginning DB library test link sequence > checking for -ldb3 (with 1.85 API compatibility)... no > checking for -ldb (version 3.x with 1.85 API compatibility)... yes > checking for ncurses.h... no > configure: error: header ncurses.h not found... aborting Actually it did solve your original problem, configuring for Berkeley's DB. The problem above is that the configure script can't find the ncurses library, which is required by TC for the SCREEN section and DISPLAY LINE/COL statements. Check if the ncurses library is installed on your system. If it is then it is configure problem. If it is not, then install it and then run configure again. Hope this helps. David Essex |
|
From: shaif k <sh...@re...> - 2002-08-08 09:37:58
|
help required.... Does this work on Solaris? Any changes required? I could build the compiler - with 722 shift/reduce conflicts, But the program statements are not being identified (parsed). Can somebody help? thanx, |
|
From: Ferran P. <fer...@re...> - 2002-08-08 14:38:47
|
The compiler by now only work on intel platforms, because we create asembler code from COBOL sources. Theorically with some work it could work on solaris for intel. But it is impossible for solaris on SPARC. Try to use opencobol. It transforms COBOL to C and it can be ported to solaris. shaif k wrote: > help required.... > > Does this work on Solaris? > Any changes required? > I could build the compiler - with 722 shift/reduce conflicts, > But the program statements are not being identified (parsed). > > Can somebody help? > > thanx, > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tin...@li... > https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users -- Salutacions / Regards +---------------------------------------------------------------+ | Ferran Pegueroles Forcadell | | mailto:fer...@re... | | Tels (+34)937252106 - (+34)667658535 | | C/Unió 44 2n 2a 08201 Sabadell (BCN) | +---------------------------------------------------------------+ |
|
From: Rod S. <rod...@ya...> - 2002-12-21 03:30:53
|
I AM A COBOL PROGRAMMER AND IF I CAN HELP YOU PROGRESS LET ME KNOW. HERE IS AN INTERESTING ARTICLE I FOUND WHILE I WAS SURFING AROUND THE WEB. ROD SCHELL Latest language in Web services: Cobol 09:46 Thursday 7th November 2002 Peter Judge Forty years on, Cobol is still growing. The latest money-saving idea is to put Cobol on Microsoft .Net Server Cobol, the biggest established language in the old-fashioned mainframe environment is set to make the jump to the new world of Web services. There is a still a vast amount of code in use that is written in the 40-year old programming language, and in the current downturn, users can't afford to junk it for new systems. The Cobol industry is set to continue, with products that link that code to Web services front ends, or port it to Web services platforms. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Sergio S. <ser...@ic...> - 2003-03-06 14:40:14
Attachments:
winmail.dat
|
Hello everybody. I finally got compiled TC in MinGW and have some notes: 1. It can't be compiled with MinGW version 2 (gcc 3+). I got compiler errors about DB symbol. 2. bison gives me an error about some swap file. YACC works well. 3. When I was compiling lib the compiler cant find flock structure in any include file. I grep all .h files in my MinGW directories (v1.1 and v2.0) also in TC sources but cant find such structure. I comment out where this structure is used in fileio.c and got lib compiled. 4. When compiling compiler, lib and preprocessor I have trouble with language support. I manually change the defines of TCOBXX_LANGUAGE define to TCOBXX_LANGUAGE_us to work arround this. I'm really new to C and unix like utilities (I'm Delphi / FireBird / Oracle developer), then please give me a hand with: 1. The problem in fileio.c (where the h*ll is flock defined!?) 2. Where I must change the language and all "substitutions" (such @tcob_lanuage@ and so) to avoid change the source directly? 3. How to compile without debug info? Regards. |
|
From: David E. <de...@ar...> - 2003-03-06 22:49:21
|
An 06/03/03, Sergio Samayoa wrote:
> I finally got compiled TC in MinGW and have some notes:
>
> 1.
> It can't be compiled with MinGW version 2 (gcc 3+).
> I got compiler errors about DB symbol.
That problem relates to the DB library.
Which version are you using, and where did you get it ?
> 2.
> Bison gives me an error about some swap file. YACC works well.
That is a problem with MYSYS, not with Bison. Something to do with paths.
If you use a command line window (C:\>), Bison will work.
> 3.
> When I was compiling lib the compiler cant find flock
> structure in any include file.
> I grep all .h files in my MinGW directories (v1.1 and v2.0)
> also in TC sources but cant find such structure.
> I comment out where this structure is used in fileio.c
> and got lib compiled.
TC version 0.60 will not compile on MinGW.
This problem has been fixed on the current CVS version.
> 4.
> When compiling compiler, lib and preprocessor I have trouble
> with language support. I manually change the defines of
> TCOBXX_LANGUAGE define to TCOBXX_LANGUAGE_us to work arround this.
What kind of trouble are you having ?
> I'm really new to C and UN*X like utilities (I'm Delphi
> / FireBird / Oracle developer), then please give me a
> hand with:
>
> 1.
> The problem in fileio.c (where the h*ll is flock defined!?)
The 'flock' structure is only available on UN*X, and not on native Win32
(MinGW).
If you add the following temporary fix, MinGW will compile TC.
static int
lock_record( int fd, int len ) {
#if defined(__MINGW32__)
return -1;
#else
...
#endif
}
void tcob_unlock( struct file_desc *f ) {
#if defined(__MINGW32__)
return;
#else
...
#endif
Or download the current CVS version.
> 2.
> Where I must change the language and all "substitutions" (such
> @tcob_lanuage@ and so) to avoid change the source directly?
This and other issues are normally handled by the configure script, which
does work on Linux and Cygwin.
Theoretically the configure script should work on MYSYS also.
Unfortunately I have not been able to run Perl (5.3 or 5.6 ) on my Win9x
machine. Required to generate the configure script.
So I have not been able to test this, nor make any modifications.
> 3.
> How to compile without debug info?
Remove the '-g' option from the TC Makefiles.
|
|
From: Sergio S. <ser...@ic...> - 2003-03-06 23:13:04
|
> Which version are you using, and where did you get it ? DB Version: 1.85 obtained from TC home page. > If you use a command line window (C:\>), Bison will work. I try in both (MSYS and CMD) but dont work. > This problem has been fixed on the current CVS version. I will get it when I can (I cant reach CVS from here, the port is closed at FW). > Theoretically the configure script should work on MYSYS also. As I said Im new to unix development environment. Which command I must run ? Thanks for the info. |
|
From: David E. <de...@ar...> - 2003-03-07 00:35:01
|
On 06/03/03, Sergio Samayoa wrote: > DB Version: 1.85 obtained from TC home page. What kind of problems are you getting ? With the headers or with the link ? GCC 3.x is reported to much more sensitive to certain types of old style C syntax. > I try in both (MSYS and CMD) but did not work. It works on Win9x, or DOS command line. MYSYS 1.0: $make -f Makefile.mingw flex -oscanner.c scanner.l bison -dv -b parser parser.y /usr/local/share/bison.simple: No such file or directory Win9x: >make -f Makefile.mingw flex -oscanner.c scanner.l bison -dv -b parser parser.y gcc -I/usr/include -I../lib -I../ -g -c parser.tab.c gcc -I/usr/include -I../lib -I../ -g -c scanner.c gcc -I/usr/include -I../lib -I../ -g -Wall -c cobpp.c gcc -o htcobolpp.exe parser.tab.o scanner.o cobpp.o -L/usr/lib -lgetopts -lm $bison -V GNU Bison version 1.28 What kind of errors are you getting ? >> Theoretically the configure script should work on MYSYS also. > > As I said I'm new to UN*X development environment. Well, MinGW is not UN*X. MYSYS (to a limited extent) and Cygwin provide a UN*X like (POSIX) emulation layer. A lot of tools have been ported to MinGW from UN*X. > Which command I must run ? Using MYSYS, type './configure' in the TC directory. On my Win9x system, the configure fails when it tries to configure for DB. It does not find the 'db.h' header, which is strange as it find the 'getopt.h' header which is in the same directory. The configure script is a bash script which can be created by the 'autoconf' command. However Autoconf requires Perl to be installed on your system. |
|
From: David E. <de...@ar...> - 2003-03-14 02:57:09
|
Sergio Samayoa wrote: > I finally got compiled TC in MinGW and have some notes: > ... > Bison gives me an error about some swap file. YACC works well. > David Essex wrote: >> If you use a command line window (C:\>), Bison will work. > > I try in both (MSYS and CMD) but does not work. OK, I think I may have found a partial solution. If you get the following message, then set the TMPDIR environment variable. yacc -dv -b parser parser.y yacc: f - cannot open "/tmp/yacc.aa42073" DOS or CMD: set TMPDIR=d:\temp MYSYS: export TMPDIR=c:/temp I do not know why Bison will abort with the following message on MYSYS or CMD, but will work on the DOS command line. bison -dv -b parser parser.y /usr/local/share/bison.simple: No such file or directory Anyway, hope this helps. |
|
From: Ronald A. <ro...@op...> - 2003-03-18 00:13:17
|
bug 704528/2: do you mean: the index only should be ended with ".idx" ? Andrew, or Rildo, any comment? I agree that index for indexed files should have the extension ".idx", I've seen this from MF / MS Cobol, but I don't know if this is just vendor specific/implemented. I think its a good and natural way to tell indexes apart from the actual data the index is being used for. (Just my opinion) :) Ron A. |
|
From: Jim M. <ji...@by...> - 2003-03-18 04:16:51
|
Beware! I am not sure about this, but in my opinion... I believe that the way in which Cobol files are mapped into physical files is not defined by the Cobol language. That is, we can pick any method of naming our data files. MF Cobol has no suffix on the data file and an extension of ".idx" on the index file. I like this approach - in fact I think we should eventually adopt all of MF's approach to file name mapping using the "$DD_" environment variables. However, there are a few products around that are meant to work with MF Cobol that expect the data file to have a ".DAT" suffix and the index file to have a ".IDX" ending. I also believe that if you link C-ISAM into MF Cobol, you also get these suffixes, but am not sure. In the short term, I think we should go with the MF conventions. However, in the long run, it would be nice to be able to specify the naming method. Jim ----- Original Message ----- From: Ronald Arenas <ro...@op...> To: Bernard Giroud <bg...@fr...> Cc: Tiny-Cobol-Users <tin...@li...> Sent: Tuesday, March 18, 2003 8:21 AM Subject: [Tiny-cobol-users] (no subject) > bug 704528/2: do you mean: the index only should be ended with > ".idx" ? Andrew, or Rildo, any comment? > > I agree that index for indexed files should have the extension ".idx", I've > seen this from MF / MS Cobol, but I don't know if this is just vendor > specific/implemented. > > I think its a good and natural way to tell indexes apart from the actual > data the index is being used for. (Just my opinion) :) > > Ron A. > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Tin...@li... > https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users > |
|
From: Bill G. <bi...@cs...> - 2003-03-18 13:37:30
|
On Tue, 18 Mar 2003, Jim Morcombe wrote: > Beware! > > I am not sure about this, but in my opinion... Let me throw my opinion in here as well. > > I believe that the way in which Cobol files are mapped into physical files > is not defined by the Cobol language. That is, we can pick any method of > naming our data files. I believe this is true as well, as it should be. > > MF Cobol has no suffix on the data file and an extension of ".idx" on the > index file. Being as it would be bad practice to access the files outsode of the program, as that could result in their corruption, it really should not matter. > I like this approach - in fact I think we should eventually adopt all of > MF's approach to file name mapping using the "$DD_" environment variables. Unless it is part of the standard, I would suggest not adopting any proprietary methods as that is likely to tie you to a particular vendors way of doing things resulting in other problems later on. > > However, there are a few products around that are meant to work with MF > Cobol that expect the data file to have a ".DAT" suffix and the index file > to have a ".IDX" ending. I also believe that if you link C-ISAM into MF > Cobol, you also get these suffixes, but am not sure. But just creating files with these extensions doesn't mean compatability. If the files are not exactly the same internally and you use this convention you increase the likelihood that someone will access the files using an incompatable system and corrupt their data. > > In the short term, I think we should go with the MF conventions. However, > in the long run, it would be nice to be able to specify the naming method. Unless you can be 100% sure your files will be the same as files created my MF COBOL I would recommend against it. In any case, the underlying structure and naming conventions should not be cinsidered important. The user should do all access through COBOL and need not even be aware of what the naming convention or external structure of the files are. Just my $.02. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bi...@cs... | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h> |
|
From: Hudson R. <hud...@gm...> - 2003-04-10 11:05:03
|
Hi Bill, > > I like this approach - in fact I think we should eventually adopt all of > > MF's approach to file name mapping using the "$DD_" environment variables. > > Unless it is part of the standard, I would suggest not adopting any > proprietary methods as that is likely to tie you to a particular > vendors way of doing things resulting in other problems later on. I agree with you. > > In the short term, I think we should go with the MF conventions. However, > > in the long run, it would be nice to be able to specify the naming method. > > Unless you can be 100% sure your files will be the same as files > created my MF COBOL I would recommend against it. In any case, > the underlying structure and naming conventions should not be > cinsidered important. The user should do all access through > COBOL and need not even be aware of what the naming convention > or external structure of the files are. Again, I agree with you.. :) Regards. Hudson -- Hudson Reis hud...@gm... http://hudson.tinycobol.org |
|
From: David E. <de...@ar...> - 2003-03-18 16:52:00
|
On 18/03/03, Jim Morcombe wrote: > I believe that the way in which COBOL files are mapped > into physical files is not defined by the COBOL language. > That is, we can pick any method of naming our data files. > > MF COBOL has no suffix on the data file and an extension > of ".idx" on the index file. Perhaps a resource file option can be added so that the user can define the index extension. > I like this approach - in fact I think we should eventually > adopt all of MF's approach to file name mapping using > the "$DD_" environment variables. TC has this feature. The 'EXTERNAL' clause in the 'SELECT' statement can be used to relate internal to external filenames at run time, by using environment variables. See the TC sources in the 'test.code/t19' directory for details. |
|
From: Hudson R. <hud...@gm...> - 2003-04-10 11:04:16
|
Hi David, > Perhaps a resource file option can be added so that the user can define the > index extension. Would be a good idea! Regards Hudson -- Hudson Reis hud...@gm... http://hudson.tinycobol.org |
|
From: Mirce V. <vm...@ma...> - 2003-03-18 21:44:28
|
About names of indexed files :
Isn't the "1" at the tail of the files name(example BYERS and BYERS1)
for the indexed files with alternate keys ? When i wrote some testing progs
to test TC, my program created two indexed files.One only had a primary
key,while the other file had primary and an alternate key with duplicates
allowed.And there was 3 actual files in the directory:One was witht the name
of file with one key,and there was two files with similar names(BYERS and
BYERS1) for the file that had one alternate key.
Sure I did not like that,but 'liking it' is not important. The important
thing is that I can't use the alternate key.At this moment I'm not sure if
it's a bug or it's me who is doing something wrong. If it is a known bug -
tell me, so I can save time looking for the right solution.
Now , about the naming conventions and having data/index in a same/diferent
physical file...
It does not realy meter the suffix of the index file (weter it is going
to be .idx or .vix or like MS-Cobol .key) , and are there separate physical
files for a same indexed file which we should access. AcuCobol allows the
user to choose which way to handle indexed files(they have V-VERSION
variable in the /etc/cblconfig that tells the runtime wheter to use the new
acucobol metod-separate data/key files or the old-one physical file for
both).I personaly prefer one and same file with both data and indexes.Why
beacouse when I type "ls -a" on the bash prompt , I want to see a small
number of files. Not two or more files per one actual file. I know it's
maybe stupid , but I LOVE it. I just see names of files. The view is much
cleaner. I also think runtime works faster that way. If DB allows one
physical file for one actual file, fine with me. If not ,well it's not realy
a big deal.
What realy metters is :does the chosen method do it's purpose , it's job
? As already mentioned in previous posts on this mailing list, it's more
important :
1. To LOCK files,and records (Linux is a multiuser environment , right)
2. my program to access that ALTERNATE KEY that it can't do now.
2a. Does DB supports primary and (posibly more than one)
alternate keys ?
3.To delete records safely regardles of was the record accesed by
primary or by alternate key.
4.To rebuild or reindex or re-whatever(AcuCobol has vutil) the indexed
file in a case of corruption
5. In one of those README files in the TC's documentation I read that
files created by one version of DB can't be accesed by other version of DB.
What if we have many computers (some of them older 486) with diferent
versions of linux , and DB ? I mean about computers on a PointOfSale
(warehouses , stores , bars , restaurants etc) that transfer their data to
Accounting Center for further processing. We can't just back-up and
restore.Yet simpler :suppose we upgrade the server to a newer version of
linux which has also a new version of DB. Again, no back-up and restore. Or
in the future using TC over SAMBA. Right now it's too complicated to solve
these problems.
Hudson :
>Bugs using files in TinyCOBOL:
>
>* If I declare a select without file organization, the compiler don't show
errors in compilation.
>example programs: open02.cob.
So far I used MS-Cobol, Acucobol and IBM COBOL for AS/400, and they all
support this.By default compiler assumes that you are declaring a LINE
SEQUENTIAL file unles you say diferently (ORGANISATION IS ....).
I guess it is not a bug , and I sugest TC treat this like mentioned
compilers.
By the way , is this a bug :
TC does not like the "SELECT PRINT-FILE ASSIGN TO PRINTER." .
It Prefers "ASSIGN TO DISK" , and when you close the printer file you should
do a
"call 'system' using 'lpr nameofprinterfile' ". If it accept devicename
PRINTER then printer file should be sent to default printer after a CLOSE
PRINT-FILE , and keep compatibility with other compilers.
Wwooooww !! it's the longest message I ever wrote. Don't hate me for this,
please, I had good intentions.
Mirce Vladimirov
Bul.Jane Sandanski 35-5-/13
1000 Skopje
Macedonia
home telephone +389 2 458 434
office telephone/fax +389 2 362 428
mobile +389 70 262 021
e-mail : vm...@ma...
|
|
From: David E. <de...@ar...> - 2003-03-20 12:29:32
|
On 18/03/03, Mirce Vladimirov wrote: > 5. > In one of those README files in the TC's documentation I read that > files created by one version of DB can't be accessed by other version of DB. > What if we have many computers (some of them older 486) with different > versions of Linux , and DB ? I mean about computers on a PointOfSale > (warehouses , stores , bars , restaurants etc.) that transfer their data to > Accounting Center for further processing. We can't just back-up and > restore. Yet simpler :suppose we upgrade the server to a newer version of > Linux which has also a new version of DB. Again, no back-up and restore. Or > in the future using TC over SAMBA. Right now it's too complicated to solve > these problems. True, the incompatibility of different DB versions is a potential problem. However, the TC documentation suggests that version 1.85.4 be used. The reason being that TC uses the DB 1.85 API only, regardless of which version of DB used. |
|
From: David E. <de...@ar...> - 2003-03-20 16:03:10
|
On 18/03/03, Mirce Vladimirov wrote: > ... > By the way, is this a bug : > > TC does not like the "SELECT PRINT-FILE ASSIGN TO PRINTER." . > It Prefers "ASSIGN TO DISK", and when you close the printer file > you should do a "call 'system' using 'lpr nameofprinterfile' ". > If it accept device-name PRINTER then printer file should be sent > to default printer after a CLOSE PRINT-FILE , and keep compatibility > with other compilers. According to the COBOL 85 standard, the select statement assign clause options are implementor defined. Assign clause options, such as LPT1, COM4, PRINTER, DISK are really left over from the DOS and mainframe COBOL legacy. For example, on the mainframe the 'PRINTER' option would add printer control characters to the output file, and spool the output to the queue. Note that on the mainframe, the printer control functionality is defined externally, and not by the COBOL program itself. In the UN*X environment, most files are on disk (including printer files). Print functions are handled by the printer utility in conjunction with printer filters. In order to avoid duplication of effort, TC has chosen to use the UN*X methodology. The only printer control (escape sequences) that a TC program will add to the output, are line-feed <LF> and form-feed <FF>. These control sequences are only added if the 'write ... (after | before) advancing ...' clauses are used, or if the file is defined as 'line sequential'. So the 'PRINTER' option as no effect on the output file. To automatically send the print file to the queue, a script (bash, perl ...) could be used, which would in essence be the equivalent to a mainframe JCL. |
|
From: Hudson R. <hud...@gm...> - 2003-04-10 11:03:58
|
Hi Mirce, > Isn't the "1" at the tail of the files name(example BYERS and BYERS1) > for the indexed files with alternate keys ? I think that the file with "1" suffix was a index file... :( > When i wrote some testing progs > to test TC, my program created two indexed files.One only had a primary > key,while the other file had primary and an alternate key with duplicates > allowed. Now I understand. That situation happen with me too. > Now , about the naming conventions and having data/index in a same/diferent > physical file... > > It does not realy meter the suffix of the index file (weter it is going > to be .idx or .vix or like MS-Cobol .key) , and are there separate physical > files for a same indexed file which we should access. AcuCobol allows the > user to choose which way to handle indexed files(they have V-VERSION > variable in the /etc/cblconfig that tells the runtime wheter to use the new > acucobol metod-separate data/key files or the old-one physical file for > both). I like from David's suggestion(to create a option to name of suffix in htcobolrc). > I personaly prefer one and same file with both data and indexes.Why > beacouse when I type "ls -a" on the bash prompt , I want to see a small > number of files. Not two or more files per one actual file. I know it's > maybe stupid , but I LOVE it. > I just see names of files. The view is much > cleaner. make sence... :) > What realy metters is :does the chosen method do it's purpose , it's job > ? As already mentioned in previous posts on this mailing list, it's more > important : > > 1. To LOCK files,and records (Linux is a multiuser environment , right) > 2. my program to access that ALTERNATE KEY that it can't do now. > 2a. Does DB supports primary and (posibly more than one) > alternate keys ? > 3.To delete records safely regardles of was the record accesed by > primary or by alternate key. > 4.To rebuild or reindex or re-whatever(AcuCobol has vutil) the indexed > file in a case of corruption Well, to make the fileio routine is more stable, we must test it and post bugs in bugtracker, to developers schedule a date to solve. > 5. In one of those README files in the TC's documentation I read that > files created by one version of DB can't be accesed by other version of DB. > What if we have many computers (some of them older 486) with diferent > versions of linux , and DB ? I mean about computers on a PointOfSale > (warehouses , stores , bars , restaurants etc) that transfer their data to > Accounting Center for further processing. We can't just back-up and > restore.Yet simpler :suppose we upgrade the server to a newer version of > linux which has also a new version of DB. Again, no back-up and restore. Or > in the future using TC over SAMBA. Right now it's too complicated to solve > these problems. In my point of view, to solve this problems, the best solution is to create a own library to indexing. > Hudson : > > >Bugs using files in TinyCOBOL: > > > >* If I declare a select without file organization, the compiler don't show > errors in compilation. > >example programs: open02.cob. > > So far I used MS-Cobol, Acucobol and IBM COBOL for AS/400, and they all > support this.By default compiler assumes that you are declaring a LINE > SEQUENTIAL file unles you say diferently (ORGANISATION IS ....). > I guess it is not a bug , and I sugest TC treat this like mentioned > compilers. Ok! Thanks for the info! :) > Wwooooww !! it's the longest message I ever wrote. Don't hate me for this, > please, I had good intentions. Don't worry about this.. And me? I always post longest messages. :) Best Regards! Hudson -- Hudson Reis hud...@gm... http://hudson.tinycobol.org |
|
From: Madaus, H. <hel...@en...> - 2003-06-13 08:21:16
|
Hi everyone,
The following code-fragment doesn't work because of the OR-Comparision
Best regards.
Helge
PROGRAM-ID. HELLO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 PARM1.
05 COMMID-REC PIC 9(08).
05 SND PIC X(05).
88 SND-ISSUE VALUE 'ISSUE'.
88 SND-RECEIVE VALUE 'RECEI'.
PROCEDURE DIVISION.
MAIN SECTION.
MOVE 'ISSU1' TO SND
EVALUATE TRUE
WHEN SND-ISSUE OR SND-RECEIVE
DISPLAY 'ISSUE'
WHEN OTHER
DISPLAY 'OTHER'
END-EVALUATE
GOBACK.
|
|
From: Hudson R. <hud...@gm...> - 2003-06-15 02:38:26
|
Hi, What's is OR-Comparision? Anyone could explain me? Thanks Hudson -- Hudson Reis hud...@gm... http://hudson.tinycobol.org |
|
From: MALKIAT B. <ben...@ya...> - 2003-08-11 11:01:45
|
Dear all, Pl. guide for the following syntaxes in tinycobol-0.60 : 1. For clearning the whole screen I am using syntax as : display spaces at 0101. Though it compiles without error but does not clear the whole screen. 2. To erase a specific line eg. display 'Want to delete this record ? (Y/N)' line 03 position 05 Now to erase this particular line I use the syntax as : display spaces at 0305 But I am not getting the effect of the same. 3. If a data file is created in a directory through a cobol program then to see its contents, we use in unix SCO 5.5 server the command as : cnv datafile.name <enter> then it displays the contents of the data file which helps us in assuring that the data file is building up and the data from the relevant fields are written to our data file, but in linux it does not recognise the command cnv. So what is alternative command in linux for viewing the data file created thr a cobol program, pl. guide and oblige. Though I have to use the cat command to view the contents of the data file which does not show correctly the written records. Rest everything is working fine in tinycobol. Pl. help and oblige. best regards, malkiat MALKIAT S. BENIPAL --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
|
From: <mas...@ma...> - 2003-09-01 17:00:00
|
Hallo, I replaced command line /usr/local/bin/htcobol -cvFP -o sourcename.int sourcename.cbl by /usr/local/bin/htcobol -c -v -t -F -P -o sourcename.o courcename.cbl. compilation freezes. I have compiled some of tests the few i tried succeed, excepting t15 wich gives error for test151.c in STEST1901. I do not know what to do. If anyone wants to inspect the source, please see http://formigasoft/usersftp/loginu.i http://formigasoft/usersftp/loginu.lis http://formigasoft/usersftp/makrc Could it be a matter of path settings? If so, which settings am I to insert in a, say, .bashrc? Thanks, Marcello |
|
From: David E. <de...@ar...> - 2003-09-01 17:50:41
|
Marcello wrote: > I replaced command line > /usr/local/bin/htcobol -cvFP -o sourcename.int sourcename.cbl > by > /usr/local/bin/htcobol -c -v -t -F -P -o sourcename.o courcename.cbl. > compilation freezes. > I have compiled some of tests the few i tried succeed, excepting > t15 wich gives error for test151.c in STEST1901. > I do not know what to do. > ... > Could it be a matter of path settings? > If so, which settings am I to insert in a, say, .bashrc? I used the 'loginu.lis' file to create a COBOL source file for a test compile. I do not know why it hangs, but the problem is with the 'special-names' clause 'console is crt'. special-names. decimal-point is comma cursor is crsr * console is crt crt status is crt-tus. If you comment that clause out, TC will function normally. |
|
From: David E. <de...@ar...> - 2003-09-02 01:55:22
|
David Essex wrote: > ... > I do not know why Bison hangs, but the problem is > with the 'special-names' clause 'console is crt'. > ... > If you comment that clause out, TC will function normally. This appears to be a problem (bug ???) with Bison. If the parser is compiled with YACC (yacc193), then the parser will function normally. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X