tiny-cobol-users

Re: [Tiny-cobol-users] Tiny-cobol-users Digest, Vol 7, Issue 9

[Pam & H. N. <phn...@ve...>]

Hi David,

I am accepting data via a 14 character variable "INPUT-NUMBER PIC X(14) 
JUST RIGHT".

This same process using tc version .58 apparently does not initialize 
the variable with spaces as the previous data is not overwritten.

As my customer got use to the behavior of the earlier version, he wants 
it to work again.  It doesn't bother me (or my customer) to have a 
unique compiler.

Is there any way to modify the compiler so it doesn't initialize a PIC X 
variable with spaces.

Thanks

Harold


> Subject:
> [Tiny-cobol-users] changes in accept using ncurses/screen section.
> From:
> Pam & Harold Norris <phn...@ve...>
> Date:
> Sat, 30 Dec 2006 19:51:08 -0500
> To:
> tin...@li...
>
> To:
> tin...@li...
>
>
> Hi all,
>
> I have been a firm believer in tc for years and it hasn't failed me 
> yet.  I am, however, having a time with changes which went into effect 
> between versions .58 and .62/.63
>
> I am accepting data on the screen using ACCEPT ON EXCEPTION.  
> According to what I saw in screenio.c, this means that the data is 
> being accepted using the SCREEN mode.  What the problem is, is: if 
> data is displayed on the screen at line 1 position 5 and I accept a 14 
> character variable at line 1 position 1, the data located at position 
> is instantly erased.  Using the same accept commands with tc version 
> .58, the existing data stays put until you input NEWdata at its location.
>
> Is there any way to fix this, either by modifying tc or my program??
>
> Thanks for the help
>
> Harold Norris
>
>
> If I understand your query correctly, the problem is that the 14 
> variable at line 1 position 1 gets initialized with blanks, assuming 
> it is an alphanumeric identifier.
>
> First of all are you using 'ACCEPT screen-n ...' or 'ACCEPT 
> identifier-n AT LINE/POS ...' ?
>
> Second is this expected behavior as found with other compilers, or 
> defined on some COBOL standard ?
>
> And finally, I don't think the behavior you are suggesting would work 
> for numeric variables, as these should display from RIGHT to LEFT.
> It is not what TC currently does, but it is the behavior on I*M 
> mainframes.
>
> In any case using group variables will not work, as the variable gets 
> initialized with blanks.
> And I don't see an option that disables the initialization.
> Maybe the variable should not get initialized with blanks (zeros), but 
> let the user do so, or not (risky).
>
>
>
>

Re: [Tiny-cobol-users] changes in accept using ncurses/screen section.

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

Harold Norris wrote:

 > I am accepting data via a 14 character variable
 > "INPUT-NUMBER PIC X(14) JUST RIGHT".

I will assume that you are using some thing similar to the example below.

...
01 INPUT-NUMBER PIC X(14) JUST RIGHT.
...
ACCEPT INPUT-NUMBER AT line 1 position 2.
...

 > This same process using tc version .58 apparently
 > does not initialize the variable with spaces as the
 > previous data is not overwritten.

I do not think that the input variable should be blanked. The current 
contents of the variable should be displayed.

In my view this is a bug. So unless some one objects, for some valid 
reason, I will try to change the code.

However, I don't think leaving the contents on the screen from a 
previous 'ACCEPT/DISPLAY', when the new fields are using the same screen 
location, is correct behavior.

There have been some modifications to the SCREEN-IO sources, between 
version 0.58 - 0.63.
I could be wrong, but I think what may have been happening in the past 
was unexpected behavior, and not what the programmer intended.

 > ...
 > Is there any way to modify the compiler so it doesn't
 > initialize a PIC X variable with spaces.

Actually, it is the RTL doing the work.

Have you tied using 'ACCEPT/DISPLAY screen-n'. It seams to work better, 
and this method will not blank fill the input-variable. The contents of 
variable will be displayed.

Using either groups or a combination of moves, your desired effect could 
be achieved.
See examples in 'test.code/t23' or 'test.code/t26'.

Hope this helps.

Re: [Tiny-cobol-users] changes in accept using ncurses/screen section.

[Nilo <nil...@gm...>]

>
> Fernando Wuthstrack wrote:
>
>  > In 2006, Rildo Pragana correct a lot of bugs in the
>  > ACCEPT/DISPLAY verbs. He did the necessary changes, but
>  > didn't upload the sources to SourceForge CVS.
>
> Actually, Rildo created a new CVS branch based on TC 0.62.x, I think.
>
>
>  > I have this and other changes here and I will do the
>  > upload on next week, but, before this, I need verify
>  > with David when I can do this, considering that it
>  > also is changing the TC source code.
>
> I have no objection to the addition of Rildo's code to TC.
> And I have downloaded Rildo's code from his CVS server on several
occasions.
>
> However there is a problem.
> SF and Rildo's CVS trees are no longer in sync.
>
> This means the you can no longer merge the two sources. And if you
> could, there is no guarantee that the code will work properly, and that
> new bugs are not introduced.
>
> In short you have to do it manually.
> Rildo and I discussed merging his code to SF CVS, but due to a number of
> reasons this never got done.
>
> In any case Rildo's changes do not fix all the problems with CURSES-IO.
>
>
>  > In December/2006, more one brazilian developer was
>  > joined to the project. His name is Nilo Paim and he
>  > is a great guy. He work with COBOL since 1978 and
>  > C since 1984. He who will make upload for the CVS.
>  > Welcome Nilo and thanks for your help!
>
> Fernando, Nilo, please wait until I complete the my changes.
> I should be finished in about 2-4 weeks.

Sure I'll wait your changes. I'm studying the code right now and I don't
wanna change anything until I've gain more knowledge about the compiler.

>
>
>  > David, I will write soon for you, OK?
>
> Fernando, I have some questions.
>
> First, is Nilo ware that the 'upload' will require more that a simple
> CVS merge ?

Sure I am.

>
> Is Nilo aware that the 'test_suite' must be run before and after the
> changes without any errors, or change in the results ?

Yes, certainly I am.

>
> Finally, is the most recent version of available on Rildo's CVS server ?
> And if not where can it be found ?

I'm not sure about it. Fernando can answer these questions.

>
> David Essex
>

David, I suppose the main environment for all the development of the
compiler is Linux. Otherwise I would like to direct my work on the use of
MinGW under Windows. So I've look the portions of code related to it and
have made some tests.

During these tests I've discover that I can't call a DLL written in Tiny
Cobol from another Tiny Cobol program.

Please, could you shed me some light about the way TinyCobol generates code
for Cobol written DLL's using switch '-m'? It seems to me that the generated
DLL doesn't export any symbols. Am I right? How should I use he compiler in
order to do that?

Thanks in advance.

Nilo R C Paim
Porto Alegre - RS - Brazil

[Tiny-cobol-users] TC updates (was: changes in accept ...)

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

Nilo Paim wrote:

 > David Essex wrote:
>>
>> Is Nilo aware that the 'test_suite' must be run before and after the
>> changes without any errors, or change in the results ?
> 
> Yes, certainly I am.

Some information about the 'test_suite'.

It will not fully test the compiler or run-time, but it does a fair job 
of trapping many problems.

One of the things it does not do is check any CURSES based programs, as 
STDIN/STDOUT/STDERR are not displayed.
On UN*X you can use pseudo-terminals (X-Win) in combination with GDB to 
debug and test CURSES based programs.
On Win32 I'm not aware of any way to test and debug CURSES based programs.

One final note, the 'test_suite' will run on Win32, but you need the DTK 
and MSYS (if I remember correctly).
Actually, the version of Perl which came with the DTK, is the only 
version I could ever get to run properly on Win32.


> David, I suppose the main environment for all the development of the
> compiler is Linux. 
 > Otherwise I would like to direct my work on the use of
 > MinGW under Windows.

Great, I'm been waiting for a TC developer with Win32 experience for 
looong time.

Generally speaking, compiler functionality is developed on UN*X mainly 
because it easier. Later equivalent functionality (if possible) is 
developed on Win32 using MinGW.

The development setup I use, to keep the MinGW/UN*X TC versions in sync, 
is to have two machines on a (closed) network.
Then using samba and Win32 shares with write access, I use the same file 
system directories.


> So I've look the portions of code related to it and have made some tests.
> 
> During these tests I've discover that I can't call a DLL written in TinyCobol
 > from another TinyCobol program.
 >
> Please, could you shed me some light about the way TinyCobol generates code
> for Cobol written DLL's using switch '-m'? It seems to me that the generated
> DLL doesn't export any symbols. 
 > Am I right? How should I use he compiler in order to do that?

Have a look at the samples in the test.code/t25 and t33 directories, and 
the source code in 'htglobals.c'.

Basically the export/import defines, and '.def' files are auto-generated 
by the MinGW compiler.

On Win32 calling a sub-program (function) in a DLL is problematic.

The reason being that a DLL can contain many sub-programs (functions), 
and the name of the DLL may not have any relation to the name of the 
sub-program being called.

On UN*X, there are functions calls you can use that will search the 
shared library paths and load that sub-program (function).
On Win32 (MinGW) there is no equivalent functionality (that I am aware 
of), so you have to write your own.

On TC version 0.63, I could not find a way to create that equivalent 
functionality. So you have to first load a specific DLL using the 
'CALL-LOADLIB identifier' extension.

On TC CVS, I found a way which seams to work.
Basically it finds, loads and checks DLL's in the 'TCOB_LD_LIBRARY_PATH' 
paths for that sub-program (function).
See 'lib/dyncall.c' for details.

Hope this helps.
If you have any further questions do not hesitate to ask.

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

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

Harold Norris wrote:

> Is there any way to modify the compiler so it 
 > doesn't initialize a PIC X variable with spaces.

After a quick look at the code, it appears that the SCREEN and LINE/POS 
methods are coded differently.

With the LINE/POS method if you use the 'UPDATE' attribute, the contents 
of variable are displayed, otherwise the screen locations are blanked.

I'm not sure that this inconsistent behavior between SCREEN and LINE/POS 
methods is a good approach. Maybe the code was not finished.

Anyway, I think I found a way to fix your problem.
Following your example.
...
01 INPUT-NUMBER PIC X(14) JUST RIGHT.
...
MOVE ... TO INPUT-NUMBER
ACCEPT INPUT-NUMBER AT line 1 position 2 UPDATE

All you have to do is use either groups or a combination of moves, and 
your desired effect can be achieved.
See example in 'test.code/t26'.

I still don't think leaving the contents on the screen from a previous 
'ACCEPT/DISPLAY', when the new fields are using the same screen 
location, is correct behavior.
So I will not change this behavior.

Hope this helps.

Re: [Tiny-cobol-users] changes in accept using ncurses/screenssection

[Fernando W. - I. S. I. Ltda. <fer...@in...>]

Hi David
Hi Harold

        In 2006, Rildo Pragana correct a lot of bugs in the ACCEPT/DISPLAY 
verbs. He did the necessary changes, but didn't upload the sources to 
SourceForge CVS. I have this and other changes here and I will do the upload 
on next week, but, before this, I need verify with David when I can do this, 
considering that it also is changing the TC source code.
        In December/2006, more one brazilian developer was joined to the 
project. His name is Nilo Paim and he is a great guy. He work with COBOL 
since 1978 and C since 1984. He who will make upload for the CVS. Welcome 
Nilo and thanks for your help!
        David, I will write soon for you, OK?
        Bye!

                                                                             
                Fernando Wuthstrack
                                                                             
                InfoCont Sistemas Integrados Ltda.
                                                                             
                Diretor
                                                                             
                Fone: (47) 3422-3536
----- Original Message ----- 
From: "David Essex" <de...@us...>
To: "tiny-cobol-users" <tin...@li...>
Sent: Monday, January 01, 2007 8:36 PM
Subject: Re: [Tiny-cobol-users] changes in accept using 
ncurses/screenssection


> Harold Norris wrote:
>
>> Is there any way to modify the compiler so it
> > doesn't initialize a PIC X variable with spaces.
>
> After a quick look at the code, it appears that the SCREEN and LINE/POS
> methods are coded differently.
>
> With the LINE/POS method if you use the 'UPDATE' attribute, the contents
> of variable are displayed, otherwise the screen locations are blanked.
>
> I'm not sure that this inconsistent behavior between SCREEN and LINE/POS
> methods is a good approach. Maybe the code was not finished.
>
> Anyway, I think I found a way to fix your problem.
> Following your example.
> ...
> 01 INPUT-NUMBER PIC X(14) JUST RIGHT.
> ...
> MOVE ... TO INPUT-NUMBER
> ACCEPT INPUT-NUMBER AT line 1 position 2 UPDATE
>
> All you have to do is use either groups or a combination of moves, and
> your desired effect can be achieved.
> See example in 'test.code/t26'.
>
> I still don't think leaving the contents on the screen from a previous
> 'ACCEPT/DISPLAY', when the new fields are using the same screen
> location, is correct behavior.
> So I will not change this behavior.
>
> Hope this helps.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users 

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

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

David Essex wrote:

> Fernando Wuthstrack wrote:
> 
>> In 2006, Rildo Pragana correct a lot of bugs in the
>> ACCEPT/DISPLAY verbs. He did the necessary changes, but
>> didn't upload the sources to SourceForge CVS.
> ... 
> I have no objection to the addition of Rildo's code to TC.
> ... 
> However there is a problem.
> SF and Rildo's CVS trees are no longer in sync.

Fernando, Nilo, I nearly forgot.

Any changes you decide to make, you will also need to test on Win32 
using PDcurses and MinGW.
I do not think these changes will be a problem, but you will need to check.

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

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

Fernando Wuthstrack wrote:

 > In 2006, Rildo Pragana correct a lot of bugs in the
 > ACCEPT/DISPLAY verbs. He did the necessary changes, but
 > didn't upload the sources to SourceForge CVS.

Actually, Rildo created a new CVS branch based on TC 0.62.x, I think.


 > I have this and other changes here and I will do the
 > upload on next week, but, before this, I need verify
 > with David when I can do this, considering that it
 > also is changing the TC source code.

I have no objection to the addition of Rildo's code to TC.
And I have downloaded Rildo's code from his CVS server on several occasions.

However there is a problem.
SF and Rildo's CVS trees are no longer in sync.

This means the you can no longer merge the two sources. And if you 
could, there is no guarantee that the code will work properly, and that 
new bugs are not introduced.

In short you have to do it manually.
Rildo and I discussed merging his code to SF CVS, but due to a number of 
reasons this never got done.

In any case Rildo's changes do not fix all the problems with CURSES-IO.


 > In December/2006, more one brazilian developer was
 > joined to the project. His name is Nilo Paim and he
 > is a great guy. He work with COBOL since 1978 and
 > C since 1984. He who will make upload for the CVS.
 > Welcome Nilo and thanks for your help!

Fernando, Nilo, please wait until I complete the my changes.
I should be finished in about 2-4 weeks.


 > David, I will write soon for you, OK?

Fernando, I have some questions.

First, is Nilo ware that the 'upload' will require more that a simple 
CVS merge ?

Is Nilo aware that the 'test_suite' must be run before and after the 
changes without any errors, or change in the results ?

Finally, is the most recent version of available on Rildo's CVS server ? 
And if not where can it be found ?

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screenssection

[Andrew C. <apc...@so...>]

David,

I agree and think it would be great if we could merge the code from
Sourceforge and Rildo's version.

I have not had much time to do any further work on TC myself.

Perhaps after the merge a new release may be a good idea.

Also if someone has time the fileio can be enhanced to have full support for
Variable IO as I never got to finish that part.

Regards
Andrew Cameron

-----Original Message-----
From: tin...@li...
[mailto:tin...@li...] On Behalf Of David
Essex
Sent: Tuesday, January 02, 2007 2:04 PM
To: tiny-cobol-users
Subject: Re: [Tiny-cobol-users] changes in accept using
ncurses/screenssection

Fernando Wuthstrack wrote:

 > In 2006, Rildo Pragana correct a lot of bugs in the
 > ACCEPT/DISPLAY verbs. He did the necessary changes, but
 > didn't upload the sources to SourceForge CVS.

Actually, Rildo created a new CVS branch based on TC 0.62.x, I think.


 > I have this and other changes here and I will do the
 > upload on next week, but, before this, I need verify
 > with David when I can do this, considering that it
 > also is changing the TC source code.

I have no objection to the addition of Rildo's code to TC.
And I have downloaded Rildo's code from his CVS server on several occasions.

However there is a problem.
SF and Rildo's CVS trees are no longer in sync.

This means the you can no longer merge the two sources. And if you 
could, there is no guarantee that the code will work properly, and that 
new bugs are not introduced.

In short you have to do it manually.
Rildo and I discussed merging his code to SF CVS, but due to a number of 
reasons this never got done.

In any case Rildo's changes do not fix all the problems with CURSES-IO.


 > In December/2006, more one brazilian developer was
 > joined to the project. His name is Nilo Paim and he
 > is a great guy. He work with COBOL since 1978 and
 > C since 1984. He who will make upload for the CVS.
 > Welcome Nilo and thanks for your help!

Fernando, Nilo, please wait until I complete the my changes.
I should be finished in about 2-4 weeks.


 > David, I will write soon for you, OK?

Fernando, I have some questions.

First, is Nilo ware that the 'upload' will require more that a simple 
CVS merge ?

Is Nilo aware that the 'test_suite' must be run before and after the 
changes without any errors, or change in the results ?

Finally, is the most recent version of available on Rildo's CVS server ? 
And if not where can it be found ?

David Essex



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Tin...@li...
https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

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

Andrew Cameron wrote:

 > ...
 > Perhaps after the merge a new release may be a good idea.
 >
 > Also if someone has time the fileio can be enhanced to
 > have full support for Variable IO as I never got to finish
 > that part.

Well there are too msny changes to make to TC, and not enough time.

So I will finish what I started, but after that I will not have much 
time to devote to this project.

As for a new release, well we will see.

David Essex