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: Hudson R. <hu...@ti...> - 2002-09-30 23:13:54
|
Hi Win, > Yes and No. I am using the ACU cobol compiler with a very nice interface. To develop CGI programs isn't necessary use a special runtime library. Can be use also getting apache environment variables and treating the values in COBOL program. To show values in browser use the DISPLAY value. A other way is using cgi-util.c and htmlproc.c, which was C routines modified/written by Rildo. > The cgi-form is declared in working-storage as external, and can be read > using the ACCEPT statement. In TinyCOBOL, using the ACCEPT <var> from environment-variable "$QUERY_STRING", you could get the html form values, and treating using a UNSTRING verb. In htmlform you MUST use the method GET in <form> declaration. ex: <html> <title>Input Form</title> </head> <body> <form method="get" action="/cgi-bin/prog01"> <p><input type="text" name="ws-Field" value=""></p> <p><input type="submit" name="ws-Operation" value="ok"></p> </form> </body> </html> identification division. program-id. prog01. author. Hudson Reis. data division. working-storage section. 77 ws-Query-String pic x(512) value spaces. procedure division. display "Content-type: text/html" display x"00" accept ws-Query-String from environment-variable "$QUERY_STRING" display 'Query String: ' ws-Query-String no advancing stop run. Compile this program using htcobol prog01.cob, copy html file to htdocs directory, copy prog01 to cgi-bin directory and a webserver, execute firstly your htmlfile. Type any value in htmlform and click in OK button. The result is a string with the name of your tag <input> and your value. > In the same concept one can DISPLAY the form, and point to a html > template. In TinyCOBOL using the DISPLAY '<tag>' to show values in browser. You need to pass in first access a null-character and the kind of content-type. identification division. program-id. hello. author. Hudson Reis. procedure division. display "Content-type: text/html" display x"00" display "Hello World!" stop run. Compile this program using htcobol hello.cob, copy to cgi-bin directory and execute in your webserver. It should show the message "Hello World!" :) Notice that isn't necessary use a special runtime library or a vendor component! This is COBOL my friend! :) > The trick here, is that the compile can use the field-names for mapping to the > input-fields of the html-form. Which is hard to do in the runtime. You could create a html preprocessor in COBOL (see the file development/test.code/tdb03 to a base) or use a htmlproc.c (a html preprocessor written by Rildo in C). > RMCobol has a runtime module doing the same on a call-by-call basis (for > each field). > The RMComponent is known as CGIEX and is commercially available for > others compilers as well. In TinyCOBOL, isn't necessary have a runtime module to use COBOL programs as CGI scripts. > My point. Since all this cgi and web thingies are different per compiler, intend to develop a cgi interface (as described here and above) completely written in Cobol. I think that you are wrong, and your cgi interface isn't a good idea. > I"ve done similar things and a basic parser is already available. I'm found a XML cobol parser example (created by microfocus(tm) COBOL), look it. It was written in MF OO COBOL. I'm sending it in pvt(due the size of file, 400kb). If anyone interesting in it, please send me a e-mail. > What I basically need in the cobol-syntax is the statement > MOVE A TO B WITH CONVERSION. Isn't according from the ISO/IEC standard. I'm developing some examples to our test.code and I will add in our cvs in a later time. You have any idea? I hope this helps. Hudson. |
From: Hudson R. <hu...@ti...> - 2002-09-30 23:12:54
|
Hi Rod, > Is there a way to use tiny cobol in a cgi-bin with > data from a html form? Yes! from two ways: 1. Getting html form values from apache environment variables ($QUERY_STRING, $HTTP_COOKIE), treating values(using a UNSTRING verb) getting from the environment variables and show the values in browser using the DISPLAY verb(This way you could send to the browser some kind of character, as javascript verbs as XML or HTML tags). To preprocess html forms, you could create a html output form, with a special caracters(@@var@@, for instance), and use the SEARCH verb to locate the special characters and substitute it by values from your application. 2. Using cgi-util and htmlproc routines. This routines are written in C by Rildo. You could view a example(using cgi-util.c) this in development/test.code/tdb03. With the first way, you can create all routines in COBOL, but this way isn't portable, but it work only in apache. With the second way, I believe that is more portable in between html servers. > I have used rm\cobol by > www.liant.com and this options is available. It is > very usefull and if its available please let me know. By my explications, you should noticed that isn't necessary use nothing kind of vendor routines to use COBOL with web. With TinyCOBOL, isn't necessary also to use a specific run-time library to use COBOL programs with web. The libraries cgi-util.c and htmlproc.c in theory, I believe that work in any COBOL compiler. To confirm my explications, I was creating some examples using COBOL programs as CGI scripts, then please wait I finished it. Hope this helps. Hudson. |
From: Hudson R. <hu...@ti...> - 2002-09-30 23:09:17
|
Hi wim, > My name is wim niemans. My name is Hudson Reis. > My origin is Eindhoven, Netherlands. Momentary I reside in Bonn, > Germany. I'm live in Brazil and I reside in Contagem, Minas Gerais. Unfortunately, my english isn't good, then, sorry for anything. :( > I am an independent software developer (since 1979) and use mainly > Cobol for application development (since 1972). I'm have a 20 years old, and I'm a COBOL programmer at 3/4 years. (since 1998). I'm a begginner in COBOL, but I write systems using Micro Focus COBOL using CUI, GUI, WEB or a SQL interface. Currently, I'm studying OO COBOL. > My point of focus is standardized Cobol. Systems I write do have > source compatibilty between Cobol platforms. Paradigma is 'write > once - compile everywhere (where Cobol is the environment)'. This > as oposed to the Java paradigma 'write once-run anywhere'. Java is a language that have a very strong marketing, however small productivity in my point of view... The COBOL language is the best language in commercial/finance applications, but we, COBOL PROGRAMMERS, have to understand that COBOL isn't the best language of languages. Each language have your place and your mission... > Current project is to port a wms (see www.tinywms.com) to an > embedded Linux environment. Lately I did discover that the jargon for > this activity is 'reconfigurable'. I never use a wms system... > Because this (cobol written) system run through a webserver and > MUST use CGI, and I don't like C-calls (or whatever non-cobol calls), > I intend to develop a true Cobol (written) interface for CGI. For that? why? What you win with this? Working with COBOL calling C directly, without nothing make-up, who you to win is yourself, that not going depend a vendor or tool, only a COBOL compiler. > Comparable to the perl components cgilib.pl and/or CGI.pm. I don't know about cgilib.pl or CGI.pm.. then, I don't know talk about. > However, there might be some stuff around. In a week there will be a > specification available, though this will cover only my needs for CGI. I think that your idea isn't good, but you will need to modify the parser and others itens for a compiler to obtain the results that you need, then will be a proprietary. I'm wrong? > Therefor I call for ideas, contributions, suggestions, hints, and > whatelse might be usefull. I have a good idea: What do you think if me and you concentrate forces to develop web COBOL development in TinyCOBOL(using cobol and c existent routines)? We could create examples and documentation, or then you could contribute with ideas. All win with this and your goals will be very fast. Unfortunately, the COBOL vendors develop your own dialects(the COBOL cancer) and remove the COBOL Programmer liberty. While we don't concentrate forces, we don't have our liberty. Anything, good luck in your walk. Best Regards. Hudson |
From: Hudson R. <hu...@ti...> - 2002-09-30 23:07:03
|
Hi Bernard, > That's great: we need real applications. I think too. In my point of view, the compiler is in a usable state, however it isn't stable.. > A name like libxxcobolweb is fine for me, > but if it is non TinyCOBOL specific the xx should be empty, and in the > contrary I wonder if it should not be called tccobolweb or tcobolweb? cgi-util.c is a routine created by Bill Kendrick and Mike Simons, and modified by Rildo to use with TinyCOBOL. htmlproc.c is a routine created by Rildo to preprocess html from a CGI COBOL program. The some routines are licensed by GPL. The htcobolweb library name sounds good to me. For that we don't have which copy cgi-util.c and htmlproc.c files for each example in our test.code repository, the way is to create a package to this. > Well I already had discussions on that subject with Rildo, David and al. And the conclusion this discussions? > I personnally think we should create a new directory called examples, > filled with programs which demonstrates specific points which can > not be regression-tested, all in the same directory, and > pass all programs in subdir t?? of test.code in the small test_suite. The use of test.code and test_suite directories, currently, isn't good in my point of view. About directories, I have a following opinion: 1. We could modify the test.code and test_suite diretories to testcode and testsuite to windows compatibility(win9X especifically). 2. We could pass all testcode directories to testsuite, classify this directories according with the current testsuite directories and put in testcode only real applications. The name of directory (testcode), in my point of view, is very good. A name 'example' to a directory is very commercial, then I prefer the 'testcode' directory name. With this modifications, our users will win a lot of advantages: 1. More facilities to find examples and classify bugs to report. 2. More organization in our COBOL programs(standardization also). With this modifications, our developers will win a lot of advantages: 1. More facilities to answer users questions (more facilities to indicate a directory to solve your doubts). 2. More facilities to implement new features in COBOL programs and makefiles(due the organization). I subscribe myself to execute this tasks, if the developers agree. > With respect with declaratives, the last time I worked on them, > they were beginning to work, when they were used only on one > file at a time (i.e. no generic and no use on file_1, file_2 stuff). Ok. I'm waiting you finish it to I test again. Thanks for all! :) Hudson. |
From: Hudson R. <hu...@ti...> - 2002-09-30 23:05:53
|
Oi Carl=FAcio, joia? Hi Carl=FAcio, > no diretorio test.code/t23 existe o programa test23, que explica > como funciona SCREEN SECTION. acontece que quando =E9 digitado um valor > e apos avancar, =E9 mostrado o valor anterior, e nao o valor que foi > digitado. Bom, eu olhei o problema que voce reportou, entretanto nao vi nenhum proble= ma deste tipo, mas de qualquer forma, tente usar o par=E2metro UPDATE no ac= cept. Well, I look the problem that you report, however, I don't see nobody probl= em this kind, but from anything, try to use the statement UPDATE in accept. Hope this helps. Regards, Hudson --=20 Hudson Reis hud...@so... |
From: Hudson R. <hu...@ti...> - 2002-09-30 23:04:51
|
Hi all, As we have manfiles in four languages[english, french, italian and portuguese(brazil)], we could create a option --lang in configure script to that the own user to configure what makefile is need install to him. The default option is in english language. This way, manfiles would be more merited by users. ex: ./configure --lang=en ./configure --lang=fr ./configure --lang=it ./configure --lang=pt_br I talk with David about this in a four months later, but it was waiting more makefiles translations to add this feature in our configure script. Unfortunately this fact not occurred. :( Developers, is very hard add this feature in our configure script? This feature is very important to non english users(as me, for instance). Thanks for attention. Hudson -- Hudson Reis hud...@so... |
From: <bur...@ya...> - 2002-09-30 12:10:26
|
Hi I would think this would be ideal for alot of users, myself I am trying to convert hp3000 cobol programs to tc , which has worked, where I have hit a wall is converting the db calls to work with MYsql, I will have to start using perl/php/c++ to write some wrappers, to gain more acceptance of the package it would be so useful to have these libraries to hand , other than that the conversion has worked fine, I have had to work on some post 85 functions which are not available on the tc but apart from that it works great. Peter Burgess --- Bernard Giroud <bg...@fr...> wrote: > Hi all, > > Good news and bad ones! > On the good news front, I'm very pleased of the > final > ratification of COBOL 2002 by the ISO. > On the bad ones, we (Opensource Cobol compiler > projects developers) have still a long way to go, > just to implement the 85/89 standard. > > I think it is about time to try to work a little > more > together, following the tracks of David Essex and > Keisuke Nishida. > > So many things need still to be done (not in any > order), > like : > - other file support systems (Inodb, RMS, ...) > - decent sort library and interface > - Sql preprocessor for ODBC and MySQL > - COBOL prettyprinter (like indent for C) > - integration into GDB, DDD and IDE's > ... > > So I propose the following (I think Tim did agree > on the principle): design a common libcob, and > if necessary, migrate the corresponding compilers. > > Just to start the discussion, I see two main > approaches: > either take an existing one, "donate" it to the > cobol > project, and upgrade to the specs, > or just start from scratch again. > > No surprise, I'm in favour of the first; but which > one? > Well, it might depend on the specs we adopt. > So I think the best start is the specs for: > - the way the cobol field is accessed from the > routine > - a descriptor for a cobol field > - a descriptor for a cobol file > > Just to start the ball rolling, I will send this > message > to the compilers mailing list, but I think the > discussion > should be carried on in the cobol-util ML. > > First of all, Keisuke, what was the reason behind > having a descriptor with two pointers, one for > the attr desc and the other for the data, except > economy of paramters for the routines and > possible factorisation of field_desc ? > > Hoping to concentrate forces ... > > Bernard Giroud > > > > ------------------------------------------------------- > 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 __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: Ferran P. F. <fer...@re...> - 2002-09-29 14:05:33
|
A GPLed ISAM library hes been released.It supports sequential access transactions etc.... This is the list of features. Features: o ultra fast B* tree implementation for random lookups o transaction handling o sequential access methods o embedable small footprint, < 75 Kb o arbitrary size files, up to 4 Terrabytes o arbitrary number of records per file, up to 2 ^^ 48 records o duplicate keys and unique keys o advanced key compression for minimal size index files o keylength up to 255 bytes per index o keylength up to 1024 bytes per record o datalength up to 2 Gigabytes per record o ISAM files are binary compatible between arbitrary platforms o regression test frame o LGPL license You can find more info at : http://mission.base.com/peter/source/ I think this can be a good library for the TC file IO. |
From: Hudson R. <hud...@so...> - 2002-09-29 06:15:58
|
Hi Ferran, > I don't know if this is what you mean, but now the call statement when > using dynamic calls tries to search the program with this order. > 1. look fot prog08 linked in the program (as a routine on the same source) > 2. look for prog08.so in the current dir and in the path specified in > the TC_LD_LIBRARY_PATH env var. > 3. look for prog08 in all the shared objects found on the > TC_LD_LIBRARY_PATH. > > If it is not found, then the ON EXCEPTION or ON OVERFLOW condition is > executed. Thanks for your explanation. I don't have explain my doubt correctly. My question is this: Why I have to encapsulate the name of my program in a variable to call a shared library? (as the example below) move "programname" to ws-Program-Name call ws-Program-Name Is possible to create a way to call a shared library using the name of program between quotes or by a variable? (as the example below) call "programname" > Dymanic calls are used when the prog. name is a variable or if always if > you use the -C option when compiling. Looking the manfile now, I think that you answer my question. I don't believe this.. I translate a manfile to portuguese, but I'm not look before... and the answer have in it... :( > If TC don't work this way for you, tell me and send an exaple program > (and the makefile you are using) and I'll try to correct the bug. I found some bugs(are bugs?) in call and I'll report in some time(When I finish from to translate for english language). Please, sorry by my fault in ask before from search.. Is due the time(which is small).. :( Cheers Hudson |
From: Bernard G. <bg...@fr...> - 2002-09-28 07:05:14
|
Hi all, Good news and bad ones! On the good news front, I'm very pleased of the final ratification of COBOL 2002 by the ISO. On the bad ones, we (Opensource Cobol compiler projects developers) have still a long way to go, just to implement the 85/89 standard. I think it is about time to try to work a little more together, following the tracks of David Essex and Keisuke Nishida. So many things need still to be done (not in any order), like : - other file support systems (Inodb, RMS, ...) - decent sort library and interface - Sql preprocessor for ODBC and MySQL - COBOL prettyprinter (like indent for C) - integration into GDB, DDD and IDE's ... So I propose the following (I think Tim did agree on the principle): design a common libcob, and if necessary, migrate the corresponding compilers. Just to start the discussion, I see two main approaches: either take an existing one, "donate" it to the cobol project, and upgrade to the specs, or just start from scratch again. No surprise, I'm in favour of the first; but which one? Well, it might depend on the specs we adopt. So I think the best start is the specs for: - the way the cobol field is accessed from the routine - a descriptor for a cobol field - a descriptor for a cobol file Just to start the ball rolling, I will send this message to the compilers mailing list, but I think the discussion should be carried on in the cobol-util ML. First of all, Keisuke, what was the reason behind having a descriptor with two pointers, one for the attr desc and the other for the data, except economy of paramters for the routines and possible factorisation of field_desc ? Hoping to concentrate forces ... Bernard Giroud |
From: Bernard G. <bg...@fr...> - 2002-09-28 06:42:46
|
Hudson Reis a écrit : > Hi Bernard, > > > I hope to finish in a few days, so we can be free to issue > > a 0.59 release. > > > > As usual, any unexpected behavior ... > > I'm developing any web example applications with TinyCOBOL to insert in our test.code and I would like what do you think about we create a run-time library (ex: libhtcobol3.so or libhtcobolweb.so) to cgi and html preprocess routines(cgi-util.c, htmlproc.c and others to create). > That's great: we need real applications. A name like libxxcobolweb is fine for me, but if it is non TinyCOBOL specific the xx should be empty, and in the contrary I wonder if it should not be called tccobolweb or tcobolweb? > > I think also that, we could re-manage test.code examples to make easier life to user, including create a example in our test.code using declaratives. Talking about declaratives, is it full implemented?. > Well I already had discussions on that subject with Rildo, David and al. I personnally think we should create a new directory called examples, filled with programs which demonstrates specific points which can not be regression-tested, all in the same directory, and pass all programs in subdir t?? of test.code in the small test_suite. With respect with declaratives, the last time I worked on them, they were beginning to work, when they were used only on one file at a time (i.e. no generic and no use on file_1, file_2 stuff). > > Regards. > Hudson Bernard Giroud |
From: Carlucio L. <car...@te...> - 2002-09-28 03:08:52
|
oi pessoal, no diretorio test.code/t23 existe o programa test23, que explica como funciona SCREEN SECTION. acontece que quando é digitado um valor e apos avancar, é mostrado o valor anterior, e nao o valor que foi digitado. atualizei via CVS e este erro persite. O que devo fazer para solucionar. translation ----------- hi personal, in paste test.code/t23 there is the program test23, which explains as it works SCREEN SECTION. that happens when it is typed a value and after prosecuting, it is shown the previous value, and not the value that was typed. updated via CVS and this mistake persite. what should do to solve. Carlucio Lopes http://br.tinycobol.org Projeto Cobol Linux http://wiki.tinycobol.org tutoriais,dicas,etc. www.focalinux.org tutoriais Linux counter nr. 285056. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/02 |
From: Jeff S. <why...@ya...> - 2002-09-27 17:05:16
|
Bernard, I remember discussing this with David some time back, i.e. making all RTS calls use the tcob_ prefix. I was originally going to do this, but some major life stuff was going on for me then and it never happened. I am glad someone is getting it accomplished. I will try to keep tabs on your changes and let you know if I notice anything amiss. Hopefully, I will be able to contribute to the project some more soon. -- Jeff Smith --- bg...@fr... wrote: > Hi all, > > I've started to implement changes in the RTS routine > names, > adding or changing the prefix cob_ into tcob_. > > I hope to finish in a few days, so we can be free to > issue > a 0.59 release. > > As usual, any unexpected behavior ... > > Bernard Giroud __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com |
From: Ferran P. <fer...@re...> - 2002-09-27 14:34:14
|
I don't know if this is what you mean, but now the call statement when using dynamic calls tries to search the program with this order. 1. look fot prog08 linked in the program (as a routine on the same source) 2. look for prog08.so in the current dir and in the path specified in the TC_LD_LIBRARY_PATH env var. 3. look for prog08 in all the shared objects found on the TC_LD_LIBRARY_PATH. If it is not found, then the ON EXCEPTION or ON OVERFLOW condition is executed. Dymanic calls are used when the prog. name is a variable or if always if you use the -C option when compiling. If TC don't work this way for you, tell me and send an exaple program (and the makefile you are using) and I'll try to correct the bug. hud...@so... wrote: > Hi, > I´d thinking about CALL verb and a idea invited my attention: > Would be good if we will create an intelligence in CALL verb(using > quotes or no) for when a CALL verb be used in COBOL program, the > TinyCOBOL run-time system find a program as in your own object or in a > external file (like a shared library). > ex: > identification division. > program-id. prog. > author. Hudson Reis. > data division. > working-storage section. > procedure division. > call "prog08" > cancel "prog08" > stop run. > If the prog08.so not exist in disk, the run-time call a prog08 > subrotine in prog object enabling the statement ON OVERFLOW or ON > EXCEPTION. > What do you think? > Only was a Idea. > Regards. > Hudson > > > ------------------------------------------------------- > 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: <hud...@so...> - 2002-09-27 14:02:13
|
Hi, I´d thinking about CALL verb and a idea invited my attention: Would be good if we will create an intelligence in CALL verb(using quotes or no) for when a CALL verb be used in COBOL program, the TinyCOBOL run-time system find a program as in your own object or in a external file (like a shared library). ex: identification division. program-id. prog. author. Hudson Reis. data division. working-storage section. procedure division. call "prog08" cancel "prog08" stop run. If the prog08.so not exist in disk, the run-time call a prog08 subrotine in prog object enabling the statement ON OVERFLOW or ON EXCEPTION. What do you think? Only was a Idea. Regards. Hudson |
From: Hudson R. <hud...@so...> - 2002-09-27 07:21:47
|
Hi Bernard, > I hope to finish in a few days, so we can be free to issue > a 0.59 release. > > As usual, any unexpected behavior ... I'm developing any web example applications with TinyCOBOL to insert in our test.code and I would like what do you think about we create a run-time library (ex: libhtcobol3.so or libhtcobolweb.so) to cgi and html preprocess routines(cgi-util.c, htmlproc.c and others to create). I think also that, we could re-manage test.code examples to make easier life to user, including create a example in our test.code using declaratives. Talking about declaratives, is it full implemented?. Regards. Hudson |
From: <bg...@fr...> - 2002-09-27 06:27:14
|
Hi all, I've started to implement changes in the RTS routine names, adding or changing the prefix cob_ into tcob_. I hope to finish in a few days, so we can be free to issue a 0.59 release. As usual, any unexpected behavior ... Bernard Giroud |
From: Bernard G. <bg...@fr...> - 2002-09-26 06:12:30
|
Hudson Reis a écrit : > Hi Larry, > > > RE: [Tiny-cobol-users] Bugs in DISPLAYIs anyone considering adapting tinycobol to use a free IDE? > > Adapting? I don't understand your question. An IDE is a IDE. A compiler is a compiler... I don't see changes to use any IDE. I'm wrong? > > > Fujitsu Cobol ported their compiler to Linux and are using eclipse. See http://www.eclipse.org/cobol/ and www.adtools.com for details. > > > > I look this and a detail invited my attention. Look below: > Apparently, eclipse need a so-called bridge to talk to the underlying COBOL compiler and native debugger. But I agree on the principle: we could gain more audience if we have a better support. > License > This project is licensed under the Common Public License. > > What license is this? is GPL? > > > I believe tinycobol would see even a greater success if it had a good IDE and eclipse may be what we need. I don't know how to tie the two together. Maybe someone out there does. Any takers? > > > > Comments.anybody..... > > Exist a IDE called SourceNavigator in http://sources.redhat.com/sourcenav. I use it with TinyCOBOL with out problems(Compilation, Link step, Edition.). It does support Tcl, C, Java, COBOL, Fortran, Assembly.. look it! > I create a lot of screenshots in our wiki about SourceNavigator. See this in http://pragana.net/cgi-bin/wiki.pl?SourceNavigator. > > Regards. > Hudson > > ------------------------------------------------------- > 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 |
From: Fred M. <fr...@mo...> - 2002-09-25 10:44:55
|
Hudson Reis wrote: > > > RE: [Tiny-cobol-users] Bugs in DISPLAYIs anyone considering adapting tinycobol to use a free IDE? > > Adapting? I don't understand your question. An IDE is a IDE. A compiler is a compiler... I don't see changes to use any IDE. I'm wrong? > > > Fujitsu Cobol ported their compiler to Linux and are using eclipse. See http://www.eclipse.org/cobol/ and www.adtools.com for details. > > I look this and a detail invited my attention. Look below: > > License > This project is licensed under the Common Public License. > > What license is this? is GPL? It is not GNU GPL. I found the text at http://www.eclipse.org/legal/cpl-v10.html and, because I am not a lawyer, I cannot comment on it. However, the Common Public License Version 1.0 is approved by the Open Source Initiative, see http://www.opensource.org/licenses/. On the GNU website you can find at http://www.gnu.org/licenses/license-list.html : Common Public License Version 1.0 This is a free software license but it is incompatible with the GPL. The Common Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL. For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.) Regards, Fred -- Fred Mobach - fr...@mo... - pos...@mo... Systemhouse Mobach bv - The Netherlands - since 1976 website : http://fred.mobach.nl Safe Harbour for encumbered Free and Open Source software and links: http://apache.dataloss.nl/~fred/ |
From: Hudson R. <hud...@so...> - 2002-09-25 06:15:22
|
Hi Larry, > RE: [Tiny-cobol-users] Bugs in DISPLAYIs anyone considering adapting tinycobol to use a free IDE? Adapting? I don't understand your question. An IDE is a IDE. A compiler is a compiler... I don't see changes to use any IDE. I'm wrong? > Fujitsu Cobol ported their compiler to Linux and are using eclipse. See http://www.eclipse.org/cobol/ and www.adtools.com for details. > I look this and a detail invited my attention. Look below: License This project is licensed under the Common Public License. What license is this? is GPL? > I believe tinycobol would see even a greater success if it had a good IDE and eclipse may be what we need. I don't know how to tie the two together. Maybe someone out there does. Any takers? > > Comments.anybody..... Exist a IDE called SourceNavigator in http://sources.redhat.com/sourcenav. I use it with TinyCOBOL with out problems(Compilation, Link step, Edition.). It does support Tcl, C, Java, COBOL, Fortran, Assembly.. look it! I create a lot of screenshots in our wiki about SourceNavigator. See this in http://pragana.net/cgi-bin/wiki.pl?SourceNavigator. Regards. Hudson |
From: Dave C. <da...@co...> - 2002-09-25 06:04:12
|
"Larry Downs" wrote: >Fujitsu Cobol ported their compiler to Linux and are using eclipse. >See http://www.eclipse.org/cobol/ and www.adtools.com for details. Yes, but they omitted the entire SCREEN SECTION. Especially stupid since they have the code in other versions of the compiler. -- Dave Close, Compata, Costa Mesa CA "The cost of silicon chips has been da...@co..., +1 714 434 7359 steady at about $1bn per acre for dh...@al... 40 years." --Gordon Moore |
From: Larry D. <do...@mc...> - 2002-09-25 02:43:22
|
RE: [Tiny-cobol-users] Bugs in DISPLAYIs anyone considering adapting = tinycobol to use a free IDE? Fujitsu Cobol ported their compiler to Linux and are using eclipse. See = http://www.eclipse.org/cobol/ and www.adtools.com for details. I believe tinycobol would see even a greater success if it had a good = IDE and eclipse may be what we need. I don't know how to tie the two = together. Maybe someone out there does. Any takers? Comments.anybody..... Larry Downs |
From: <bko...@ma...> - 2002-09-24 12:28:20
|
Number 1 makes sense. Without the closing quote mark, the token continues until the end of the file. What behavior were you expecting? I have always created a screen of literals in WORKING-STORAGE rather than using a DISPLAY <literal> format. There are a few reasons for this: i) depending on the screen size (ROWxCOL) one can pretty easily lay out the screen so that it is easily viewable in WORKING-STORAGE as what you expect to see on the screen after the DISPLAY [an early wysiwyg :)]; ii) reusability, you may find a use for different parts of the screen at some later point; iii) maintainability, just easier for me to maintain my ewysiwyg. -----Original Message----- From: Hudson Reis [mailto:hud...@so...] Sent: Tuesday, September 24, 2002 2:02 AM To: Lista SourceForge Subject: [Tiny-cobol-users] Bugs in DISPLAY Hi all, I've had problems in DISPLAY verb. 1. Using a DISPLAY verb with literals, if the string isn't terminated(if the double quotes are opened and don't closed), the scanner shows the following message: "scanner token too large". If the string need be continued in other line and don't have the I/O screen statements(as line/position statement), the scanner shows the same message above. Example programs: disp02.cob, disp03.cob |
From: Ferran P. <fer...@re...> - 2002-09-24 07:00:39
|
I'll look this when I have some time. Thank's for the report. Hudson Reis wrote: >Hi all, > >I've had problems in ACCEPT verb. > >1. In execution, the no-echo statement don't work. >Example program: accept03.cob > >2. If I don't use nothing type of statement in accept(auto, update, etc), or nothing type of screen I/O, in execution, isn't respected the size of picture and permit that the user type any character (numeric/alphanumeric,etc). Also, function keys don't work. >Example program: accept00.cob, accept01.cob > >3. When I press Alt+TAB in any part from my program, it's exit from that operation. Why? > >Thanks. >Hudson > > > -- Salutacions / Regards +---------------------------------------------------------------+ | Ferran Pegueroles Forcadell | | mailto:fer...@re... | | Tels (+34)937252106 - (+34)667658535 | | C/Unió 44 2n 2a 08201 Sabadell (BCN) | +---------------------------------------------------------------+ |
From: Hudson R. <hud...@so...> - 2002-09-24 05:57:08
|
Hi all, I'm reporting some bugs founded in our compiler. If my english isn't good, and you don't understand any thing, please ask to me. :) Thanks for attention. Hudson |