tiny-cobol-users

[Tiny-cobol-users] Ncurses problem

[Walter G. <ga...@dm...>]

I=B4m sorry, i forgot to send the correction.

in compiler/htcobemt.c search for this code and coment the 2 lines

/*      Screen section io cleanup (curses library). */
// Even if you don=B4t use it in main program, call the =
tcob_do_scrio_finish
//        if (screen_io_enable !=3D 0) {
           asm_call("tcob_do_scrio_finish");
//        }

walter garrote

[Tiny-cobol-users] Ncurses problem

[Walter G. <ga...@dm...>]

Hi,

For developers.
Even if you don=B4t use the positioning feature in the main program, =
it=B4s must necessary call the tcob_do_scrio_finish() before stop run =
the main program.
Imagine that your main program don=B4t use the display or accept with =
line and column, but it calls another program that will use it..
In this case, when the subprogram returns to the main program the =
ncurses still open....when the main program stops run it thosen=B4t call =
the tcob_do_scrio_finish.

thanks,

walter garrote.

Re: [Tiny-cobol-users] Results of COPY work-arounds

[David E. <de...@us...>]

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.

Re: [Tiny-cobol-users] Request for feature

[David E. <de...@us...>]

John R. Culleton wrote:

 > In many other languages it is easy to send a command to the
 > operating system and view the results. on sysout.  I can I
 > suppose write an assembly language routine to do this, but it
 > would be nicer if someone else did it :<). I am thinking of
 > something along the lines of:
 >
 > CALL SYSTEM USING "ls -l *cpy".
 >
 > to get a listing of copybooks in the current directory.
 >
 > Thoughts?

You can call any C library function.

To achieve a 'system' call try using some thing like the following example.

Example:
...
01 parm1.
   05 parm1-value1 pic x(20).
   05 parm1-value2 pic x(01) value x"00".
...
move "ls -l *.cpy" to parm1-value1.
CALL 'system' USING parm1.

Note that since you a calling a C function, the string must be NULL
terminated.

[Tiny-cobol-users] Request for feature

[John R. C. <jo...@we...>]

In many other languages it is easy to send a command to the
operating system and view the results. on sysout.  I can I
suppose write an assembly language routine to do this, but it
would be nicer if someone else did it :<). I am thinking of
something along the lines of:

CALL SYSTEM USING "ls -l *cpy".

to get a listing of copybooks in the current directory.  

Thoughts? 
-- 
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

[Tiny-cobol-users] Results of COPY work-arounds

[Jim M. <ro...@vi...>]

Dave & Walter

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.

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.

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.

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.

Jim

Re: [Tiny-cobol-users] Subprograms calling subprograms.

[John R. C. <jo...@we...>]

On Thursday 11 August 2005 06:17 pm, David Essex wrote:
> John R. Culleton wrote:
> > Is there a problem with having subbprograms that call other
> > subprograms in hierachical fashion? Is there a limit to number
> > of levels?
>
> To my knowledge, there hasn't been any reports of that nature.
>
> AFAIK, no heavy duty stress tests have been performed for the CALL
> statement. And no tests for recursion have been performed.
>
> What kind of problem have you encontered ?

None. I am at the design stage and I need to make design
decisions, like what to do with my screen display subprogram. I
wrote it 20 years ago and am in the process of rekeying it from
an old listing.. 

I was a smart programmer back then. Unfortunately age takes its
toll :)  
-- 
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

Re: [Tiny-cobol-users] Subprograms calling subprograms.

[David E. <de...@us...>]

John R. Culleton wrote:

> Is there a problem with having subbprograms that call other
> subprograms in hierachical fashion? Is there a limit to number
> of levels?

To my knowledge, there hasn't been any reports of that nature.

AFAIK, no heavy duty stress tests have been performed for the CALL 
statement. And no tests for recursion have been performed.

What kind of problem have you encontered ?

[Tiny-cobol-users] Subprograms calling subprograms.

[John R. C. <jo...@we...>]

Is there a problem with having subbprograms that call other
subprograms in hierachical fashion? Is there a limit to number
of levels?
 
John Culleton 

Re: [Tiny-cobol-users] Compiler crash on COPY statement

[Jim M. <ro...@vi...>]

Thanks Dave

I'll try your work-arounds.

>
> And to make matters really frustrating, the same conditions (code) 
> which had caused a bug on my system, would no longer duplicate the 
> problem several day later.

I'm glad it happenned to you as well - I thought I was really losing it:)

Jim

Re: [Tiny-cobol-users] The same error - only different :)

[John R. C. <jo...@we...>]

On Thursday 11 August 2005 07:20 am, Jim Morcombe wrote:
> A Copybook by the name of "RGHELP-IO-WS" has caused the compiler to
> crash with the usual "Segmentation Error".  However, where the other
> problems disappeared when I changed the names of the copybooks, this one
> did not.  No matter what name I give the copybook, the compiler still
> crashes.
>
> However, if I edit the copybook and comment out a line at random, the
> compiler works.
>
> In the code below, I have commented out the definition for the variable
> "QGH-SUB-SCREEN-NO" in order to get the program to compile.  However, if
> I comment out the definition for "QGH-SCREEN-NO" or
> "MAX-SCREEN-CONTENTS" then the program will also compile.
>
> Note that none of these three variables are actually used in the
> program.  These are redundant lines of code and need not be there.

Is it possible that too many dashes in a copybook name or even
an internal name causes the problem?
-- 
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

Re: [Tiny-cobol-users] Compiler crash on COPY statement

[David E. <de...@us...>]

I could not duplicate any of the problems you described using version 0.63.

I think you may be experiencing an intermittent bug in the TC 
pre-processor reported on several occasions, and which I encountered a 
while back.

Unfortunately, I never did isolate the problem as any small change in an 
option, search path or copybook line and the problem would disappear.

To make matters even more frustrating, the conditions (code) which 
caused the bug on one system usually could not be duplicated on another.

And to make matters really frustrating, the same conditions (code) which 
had caused a bug on my system, would no longer duplicate the problem 
several day later.

Anyway, I think the problem is with the a stray pointer(s) in the 
copybook search sequence code.

The only thing I can suggest is to try some work-around, such as the 
following.
1) Enclosed the copybook names in quotes.
COPY 'some-copybook'.
2) Add an extra path delimiter at the end of the path.
... -I $COBCPY: -I $IO: gltest.cbl
3) Add an extra dummy path at the end of the path.
... -I $COBCPY:dummy -I $IO:dummy gltest.cbl

The TC pre-processor code needs to be cleaned up, and better integrated 
into the main compiler, but that is another story.

Re: [Tiny-cobol-users] Compiler crash on COPY statement

[Walter G. <ga...@dm...>]

Hi,

yesterday when i send my suggestion to the list i found the same error...
if you compile the same program in the same directory where you have the 
copy files (don´t use -I or global variable), you will not receive the 
segment fault.
i tried to search the error, but it occurs in parser when it tries to 
allocate 16k and return the pointer.
i only will have time to continue search the allocation problem next 
week....

walter



----- Original Message ----- 
From: "Jim Morcombe" <ro...@vi...>
To: "tiny-cobol-users" <tin...@li...>
Sent: Thursday, August 11, 2005 1:59 AM
Subject: [Tiny-cobol-users] Compiler crash on COPY statement


> This is a follow up to my previous post - which has not hit the mailing 
> list yet because I sent it from the wrong email account:)
>
> I have just compiled another program that uses "COPY GLBAL-IO-WS" and the 
> compiler crashed again with a Segmentation error.
>
> I copied the copybook to create a new copybook called "STUFFX" and then 
> modified the program to read "COPY STUFFX".
> The program now compiles.
>
> Is there anything suspicious about the name "GLBAL-IO-WS"?  I have 
> copybooks with names like "GLACCNT-IO-WS" and "GLTRAN-IO-WS" and these 
> compile okay.
>
> Jim
>
>
>
> -------------------------------------------------------
> 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
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.10.6/69 - Release Date: 11/8/2005
> 

[Tiny-cobol-users] The same error - only different :)

[Jim M. <ro...@vi...>]

A Copybook by the name of "RGHELP-IO-WS" has caused the compiler to 
crash with the usual "Segmentation Error".  However, where the other 
problems disappeared when I changed the names of the copybooks, this one 
did not.  No matter what name I give the copybook, the compiler still 
crashes.

However, if I edit the copybook and comment out a line at random, the 
compiler works.

In the code below, I have commented out the definition for the variable 
"QGH-SUB-SCREEN-NO" in order to get the program to compile.  However, if 
I comment out the definition for "QGH-SCREEN-NO" or 
"MAX-SCREEN-CONTENTS" then the program will also compile.

Note that none of these three variables are actually used in the 
program.  These are redundant lines of code and need not be there. 



      *---------------------------------------------------------*
      *  RGHELP-IO-WS.
      *---------------------------------------------------------*
      *  RGHELP only has a single Index:
      *    Primary Key:        RG-HELP-KEY
      *---------------------------------------------------------*
       01  RGHELP-KEY-TO-USE    PIC X(30)  VALUE SPACES.

      *---------------------------------------------------------*
      *  Defining the Intermediate Variables used in
      *  reading RG-HELP table.
      *---------------------------------------------------------*

       01  MAX-SCREEN-CONTENTS      PIC 9(5)    VALUE 20.
       01  QGH-SCREEN-NO            PIC Z9 VALUE ZERO.
      *01  QGH-SUB-SCREEN-NO        PIC Z9 VALUE ZERO.

      *--------------------------------------------------------
~

[Tiny-cobol-users] Another example of COPY crash

[Jim M. <ro...@vi...>]

The compiler also crashes on the line "COPY GLRPT-IO-WS" but compiles 
okay if I change it to "COPY GLRPT-IOWS".

So far these are okay:
COPY GENERAL-IO-WS.
COPY GLACCNT-IO-WS.
COPY GLTRAN-IO-WS.
COPY GLUTRAN-IO-WS.
COPY GLRLINE-IO-WS.
COPY GLFRRUN-IO-WS.
COPY GLANAL-IO-WS.
COPY VERSION-IO-WS.

While these needed to be changed:
 *COPY GLBAL-IO-WS.
  COPY GLBAL-IOWS.
*COPY GLRPT-IO-WS.
 COPY GLRPT-IOWS.

The only thing I can see that these two files have in common is that the 
"GLBAL" and "GLRPT" and five characters in length while the other names 
are at least six character long.

[Tiny-cobol-users] Oops - More of COPY problem.

[Jim M. <ro...@vi...>]

Forget my last post - I had a typing mistake in my program.

My program compiles if I have "COPY GLBAL-IOWS", but the compiler 
crashes if I have "COPY GLBAL-IO-WS".

What is wrong with the name "GLBAL-IO-WS"?

[Tiny-cobol-users] More on my COPY file compiler crash

[Jim M. <ro...@vi...>]

If I have a copyfile named "GLBAL-IOWS" and the corresponding line "COPY 
GLBAL-IOWS" in my cobol program, then I get the following error message 
when I compile it:

htcobolpp: yyerror (934, 17): parse error, unexpected $, expecting 
TOK_REPLACING '.'

[Tiny-cobol-users] Compiler crash on COPY statement

[Jim M. <ro...@vi...>]

This is a follow up to my previous post - which has not hit the mailing 
list yet because I sent it from the wrong email account:)

I have just compiled another program that uses "COPY GLBAL-IO-WS" and 
the compiler crashed again with a Segmentation error.

I copied the copybook to create a new copybook called "STUFFX" and then 
modified the program to read "COPY STUFFX".
The program now compiles.

Is there anything suspicious about the name "GLBAL-IO-WS"?  I have 
copybooks with names like "GLACCNT-IO-WS" and "GLTRAN-IO-WS" and these 
compile okay.

Jim

Re: [Tiny-cobol-users] copybook suggestion

[David E. <de...@us...>]

Walter Garrote wrote:

 > my suggestion to tiny developers is to modify htglobas.c,
 > function copytrip, include 4 lines.
 > ...
 > with these you can specify in htcobolrc environment variable,
 > like that
 > COPYBOOK_PATH: $GPFONTES

The current TC copybook search sequence is relatively complex, some
would say confusing.

In my view, the addition of another option would further confuse users.

In any case you could achive a similar result by using the COPY library
name clause.

Syntax:
COPY text-name-1 [{ OF | IN } library-name-1] ...

Example:
COPY 'TEST02.cpy' IN GPFONTES ...

$export GPFONTES=path1:path2: ... :pathn

[Tiny-cobol-users] copybook suggestion

[Walter G. <ga...@dm...>]

Hi,

my suggestion to tiny developers is to modify htglobas.c, function =
copytrip, include 4 lines.

  if (pt1 !=3D NULL) {
    if ((i =3D pt2 - pt1) >=3D 0) {
// lines to include
       if(*pt1 =3D=3D '$') { // walter garrote: get the environment =
variable
         pt1 =3D getenv(pt1 + 1);
         i =3D strlen(pt1);
       }
// end
       strncpy(sout, pt1, i+1);
       sout[i+1] =3D '\0';
    }
  }


with these you can specify in htcobolrc environment variable, like that
COPYBOOK_PATH: $GPFONTES


walter garrote

[Tiny-cobol-users] Help required with Compiler crash

[Jim M. <ji...@by...>]

I have a program that crashes with a Segmentation error.
(I have checked it carefully for unbalanced Quotes this time =EF=81=8A )

I compiled it on Red Hat Linux using TC version 0.62.0
I compiled it with the following command:

htcobol -c -g -t -C -D -F -P -I $COBCPY -I $IO gltest.cbl

I tracked the problem back to the statement =E2=80=9CCOPY GLBAL-IO-WS=E2=80=
=9D.

If I comment out this COPY statement, then the program compiles.
If I leave the COPY statement in the program, but delete every single=20
line from the copybook (so it is empty) then the compiler crashes.
If I rename another copybook (one that compiles) to GLBAL-IO-WS, then it=20
crashes.

If I rename GLBAL-IO-WS to STUFF2, then the program compiles.

I deleted every line I could to come up with a small example. Attached=20
is the result. It has two copybooks =E2=80=93 the offending GLBAL-IO-WS a=
nd=20
=E2=80=9CSTUFF=E2=80=9D. If the copybook =E2=80=9CSTUFF=E2=80=9D is remov=
ed, the compiler works and=20
reports an error. If STUFF is present, the compiler crashes.

I have attached gltest.cbl, STUFF and GLBAL-IO-WS

Any ideas?


Jim

Re: [Tiny-cobol-users] Fw: Access SQL Server (mysql or pgsql) from TinyCobol (Gateway)

[Jim M. <ro...@vi...>]

Carlucio

This sounds pretty good.  Tell us more :)

And tell us a little bit more about yourself.

Jim



Carlucio Lopes wrote:

>Hi,
>
>i include this feature in TinyCobol (gateway for sql server).
>
>For those that want access sql server (mysql or postgress) without chang=
e any cobol program lines. Yes, using open, close, start, read, write, de=
lete, rewrite...
>
>If you want other sql server, please send it to me...i will try to inclu=
de it.
>
>Take look at Readme-sql.txt.
>
>I only test with linux (slackware), i didn=B4t test with mingw for (wind=
ows)...please help me with that.
>
>Now i=B4m writing embedded sql for Tiny (mysql and postgress).
>
>Any question or suggestion will be fine.
>
>Many thanks for Carlucio Lopes and Fernando Wuthstrack.
>
>
>Have fun.
>
>
>Walter Garrote
>Brazil
>Goi=E2nia-Goi=E1s
>
>
> =20
>

Re: [Tiny-cobol-users] Connecting to subprograms.

[John R. C. <jo...@we...>]

On Saturday 06 August 2005 06:12 pm, David Essex wrote:
> There are several examples in the 'test.code' directories.
>

Ah what a treasure trove! I missed that completely. You won't
hear from me for a while. I will be plowing through examples.=20
=46rom all that I can almost write my own manual :)
=2D-=20
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

Re: [Tiny-cobol-users] Connecting to subprograms.

[David E. <de...@us...>]

John R. Culleton wrote:

> I assume that the COBOL code for creating and calling
> subprograms is pretty standard. 

On UN*X the first function to be executed (main-program) is called an 
entry point. This can be set, but the default is called 'main'.

With COBOL there is no easy way to determine which is a main-program and 
which is a sub-program.

Beginning with version 0.63, TC has several options giving the user to 
more flexibility.
The following options can be set in the compile time resource file, 
'htcobolrc', or on the command line.

# Specify the default main program (entry point) action
#
# auto  - Use the first encountered 'STOP RUN' statement,
#         and if found, generate a program entry point.
#
# first - Use the first encountered 'PROGRAM-ID' statement,
#         and if found, generate a program entry point.
#
# none  - Do not generate any program entry point.
#
PGM_ENTRY_POINT_AUTO
#PGM_ENTRY_POINT_NONE
#PGM_ENTRY_POINT_FIRST

The 'PGM_ENTRY_POINT_AUTO' option (-M auto) will try to guess at which 
is the main program.

The 'PGM_ENTRY_POINT_FIRST' option (-M first) will use the first 
encountered 'PROGRAM-ID' statement as the main program.

With the first/auto options, TC will generate a 'main' entry point and 
call the main program.

With the 'PGM_ENTRY_POINT_NONE' option (-M none) a 'main' entry point is 
not generated.

If for some reason all else fails, the '-e programid' command line 
option can be used to manually set the main program, if a 'PROGRAM-ID' 
statement is found with that entry.
In this case TC will set 'programid' as the main program, and generate a 
'main' entry point.

This approach is more complex but more flexible, in my view.


 > The tricky part for me is the compile options.
 > In OpenCobol for example the main program has to be compiled
 > with a special parameter indicating it is a main program.

The problem with that approach is that if you have a sequence of COBOL 
programs in one source, which is the main and which are the sub-programs.


 > The subprogram is compiled to a linkable object.
> Then both are compiled together to come up with an executable. 
> 
> I presume something similar is going one with TC but I can't
> guess what.
> 
> 1. Can/should the main program and sub program sources be resident in 
> the same directory?

They can reside in different directories, but generally it is the same 
directory.


> 2. What does the command line for compiling main program
> foo.cbl look like?
> 
> 3. What does the command line for compiling subprogram bar.cbl look like?
> 
> 4. What does the linking command (if any) look like?

Example: (with PGM_ENTRY_POINT_AUTO)
htcobol -c foo.cbl
htcobol -c bar-1.cbl
...
htcobol -c bar-n.cbl
gcc -o prog1 foo.o bar-1.o ... bar-n.o -lhtcobol -ldb ...

Example: (with PGM_ENTRY_POINT_NONE)
htcobol -c -M first foo.cbl
htcobol -c bar-1.cbl
...
htcobol -c bar-n.cbl
gcc -o prog1 foo.o bar-1.o ... bar-n.o -lhtcobol -ldb ...


> Thanks as always. The existing manuals don't address this issue
> AFAIK.

There are several examples in the 'test.code' directories.

[Tiny-cobol-users] Connecting to subprograms.

[John R. C. <jo...@we...>]

I assume that the COBOL code for creating and calling
subprograms is pretty standard. The tricky part for me is 
the compile options. In OpenCobol for example the main program
has to be compiled with a special parameter indicating it is a
main program. The subprogram is compiled to a linkable object.
Then both are compiled together to come up with an executable. 

I presume something similar is going one with TC but I can't
guess what.

1. Can/should the main program and sub program sources be resident in 
the same directory?

2. What does the command line for compiling main program
foo.cbl look like?

3. What does the command line for compiling subprogram bar.cbl look like?

4. What does the linking command (if any) look like?

Thanks as always. The existing manuals don't address this issue
AFAIK.
-- 
John Culleton