tiny-cobol-users

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

John Culleton wrote:

 > Unfortunately the cobcurses package contains
 > some wierd COBOL code that confuses my system.
 > Specifically there are literals full of tab characters
 > etc. that are so long that they overflow the line width.
 > This is in -free format per the Makefile.
 > Here is the first set of lines that causes the system
 > to blow up on "make":
 > 10  SCR-0015 PIC X(023)
 >     VALUE "
 >     3.Author:".

Strange.


 > The OC compiler sees the third line as an AUTHOR statement
 > (COBOL 68) and says it doesn't  meet COBOL 2002.  Well do tell.

Yes, OC defaults to the COBOL 2002 standard. Well parts of it anyway.
Have you tried using the '-std=cobol85' option.


 > Why there are tab characters in the middle of a COBOL
 > literal I cannot fully fathom.  I assume that they are
 > for positioning on the screen.
 > In legacy COBOL we used to use continuation characters
 > in column six for long literals but legacy is out of
 > style. Pity.
 >
 > So thanks for the suggestion but for me at least cobcurses
 > is more work than it is worth.

I haven't tried using 'cobcurses'. No time.

I'm surprised that you are experincing these sort of problems.
The developer is a COBOL programmer, and the application is based on a 
professional screen tool.


 > I used to get paid decent bucks for debugging someone else's
 > too too clever code but now I work for myself and I don't have
 > the time.

Yes, been there ...
I can assume you have encountered the '66 level ALTER statement' merry 
go round. Code who's real purpose was to ensure job security.

In any case it seams like a trivial but large bug of some sort.
May be worth your while to post it on the OC forum. I don't know if the 
developer subscribes to the OC mailing list.


 > My project objectives are fairly simple. Decades ago I wrote
 > a General Ledger package in RM COBOL. I have lost most of
 > the source code. The 8 inch floppies are in the bottom of
 > some landfill.
 > I want to recreate a useful GL package in COBOL and not
 > using Mysql etc.
 >
 > The one piece of code I still have is the program that created
 > a data file that when interpreted by a handler program would
 > display and accept a screen full of data.
 > It was a poor man's SCREEN SECTION if you will. RM COBOL of
 > course had positional ACCEPT and DISPLAY back in 1979 or so.
 > Basically I am starting from scratch, using the old user manual
 > and file layout as a loose guide.
 >
 > If I wanted to write the system in C or Perl, or Java, or Tcl/Tk
 > I would have done so.
 > I would like to write it in COBOL because I am far more fluent
 > in that language.

I can understand your point of view.
But using COBOL can be cumbersome and increase the amount of work.

For example you could use XHTML forms, and generate them using COBOL.


 > I am not familiar with MVC but I will google on it.

It is an acronym for Model View Controller. It was developed at X*rox 
Palo Alto, the same place were GUI's were born.

Simply put, it means that the application gets divided into 3 segments.
An interface (GUI, curses, etc.), a back end which does the actual work, 
and some glue which binds the two other segments together.


Cheers

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

On Monday 24 December 2007 10:46:29 pm David Essex wrote:

>  > I used to get paid decent bucks for debugging someone else's
>  > too too clever code but now I work for myself and I don't have
>  > the time.
>
> Yes, been there ...
> I can assume you have encountered the '66 level ALTER statement' merry
> go round. Code who's real purpose was to ensure job security.

There was the contract programmer who ensured job security by a) sucking up to 
the IBM SE and b) using fields called x1, x2 etc. as counters, later as 
indexes, and then as accumulators for storing numeric data, all in the same 
program.  He was of course fond of ALTER. 

-- 
John Culleton
Resources for every author and publisher:
http://wexfordpress.com/tex/shortlist.pdf
http://wexfordpress.com/tex/packagers.pdf
http://www.creativemindspress.com/newbiefaq.htm
http://www.gropenassoc.com/TopLevelPages/reference%20desk.htm

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

John Culleton wrote:

>  David Essex wrote:

>> I can assume you have encountered the '66 level ALTER statement'
 >> merry go round. Code who's real purpose was to ensure job
 >> security.
> 
> There was the contract programmer who ensured job security by a) sucking up to 
> the IBM SE and b) using fields called x1, x2 etc. as counters, later as 
> indexes, and then as accumulators for storing numeric data, all in the same 
> program.  He was of course fond of ALTER. 

Have you ever heard the story about some COBOL programmers employed in 
the financial sector.

Apparently these COBOL programmers had written some mission critical 
applications. They used so many 66 levels and ALTER statements, that it 
made very difficult for any else to understand the code.

Of course they used this code to ensure job security and what they 
considered a GOOD salary.

Eventually management, frustrated by this situation, secretly hired some 
programmers to rewrite these applications using structured programming 
methods.

Once the systems were up and running, they promptly fired all these 
COBOL programmers. To ensure this situation would not repeat
itself, they mandated that all applications must be written using 
structured programming methods.

I don't know if this story is true, but none the less, an interesting tale.


 >> May be worth your while to post it on the OC forum.
 >> I don't know if the developer subscribes to the OC
 >> mailing list.

I neglected to mention that I was referring to the OC forum located on 
the OC home web page (1).


Cheers

1) OpenCOBOL home web page
http://www.opencobol.org/

Re: [Tiny-cobol-users] Accounting Software

[<jw...@we...>]

Hi John,

I have been wanting to get my software onto sourceforge for some time now,
but as with most of you out there, time seems to be something that I am
unable to find enough of.

I have a complete accounting, point of sale, Inventory etc system which I
want to get onto sourceforge to allow all the interested 'COBOL'
programmers to get involved with any future development. This is basically
to allow for the GUI interface, aswel as printing through windows and
cups.

The system has been written for microfocus and I had started to make the
necessary amendments for ACU, which has now become part of microfocus.
There will most likely be numerous changes for it to run on any of the
free COBOL compilers but the important, varyfication, IO, calculation code
etc is all there.

I need to get this code onto sourceforge for all this to happen. Have
already registered as APAC accounting on sourceforge, but need some advice
from those of you that have been using the system as to which is the best
method of moving forward.

Regards

James Lemmon


-------------------------------------------
South Africas premier free email service - www.webmail.co.za 
------------------------------------------------------------------
For super low premiums, click here http://www.webmail.co.za/dd.pwm

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

[Binyamin D. <bd...@di...>]

On Tue, 25 Dec 2007 14:51:12 -0500 David Essex <de...@us...>
wrote:

:>John Culleton wrote:

:>>  David Essex wrote:

:>>> I can assume you have encountered the '66 level ALTER statement'
:> >> merry go round. Code who's real purpose was to ensure job
:> >> security.
 
:>> There was the contract programmer who ensured job security by a) sucking up to 
:>> the IBM SE and b) using fields called x1, x2 etc. as counters, later as 
:>> indexes, and then as accumulators for storing numeric data, all in the same 
:>> program.  He was of course fond of ALTER. 

:>Have you ever heard the story about some COBOL programmers employed in 
:>the financial sector.

:>Apparently these COBOL programmers had written some mission critical 
:>applications. They used so many 66 levels and ALTER statements, that it 
:>made very difficult for any else to understand the code.

:>Of course they used this code to ensure job security and what they 
:>considered a GOOD salary.

Depends when it was done.

Back in Ye Olde Days, not only would it have been ridiculous to use 3M for a
simple Hello World program, one could not even guarantee 100K being available
(including buffers).

While overlays and ALTERS are most unstructured, they do allow for faster and
smaller code.

So if this code was written in the 90s, yes, there is something wrong.

If this code was written in the 70s, good code. And much more maintainable (by
the average programmer) than assembler.

--
Binyamin Dissen <bd...@di...>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

Binyamin Dissen wrote:

 > David Essex wrote:
 >
 >> Have you ever heard the story about some COBOL programmers
 >> employed in the financial sector.
 >
 >> Apparently these COBOL programmers had written some mission
 >> critical applications. They used so many 66 levels and ALTER
 >> statements, that it made very difficult for any else to
 >> understand the code.
 >
 >> Of course they used this code to ensure job security and what
 >> they considered a GOOD salary.
 >
 > Depends when it was done.
 >
 > Back in Ye Olde Days, not only would it have been ridiculous
 > to use 3M for a simple Hello World program, one could not even
 > guarantee 100K being available (including buffers).
 >
 > While overlays and ALTERS are most unstructured, they do allow
 > for faster and smaller code.
 >
 > So if this code was written in the 90s, yes, there is something
 > wrong.
 >
 > If this code was written in the 70s, good code. And much more
 > maintainable (by the average programmer) than assembler.

I agree that small code may have been good practice back in the
60s early 70s.

However, assuming this part of the urban legend is true, these
programs were replaced by structured programming methods.
So memory was not an issue.

Even if the programs were written back in the 60s, these
programs could have been easily converted by the maintainers
of these systems. Not to mention cheaper.

As to why management choose to replace these programmers, who
knows. Maybe it was just cheaper to replace them with less paid
programmers. Then used some excuse to justify their actions.
Nothing new under the sun here ...

That is the thing about urban legends, you never really know
what to believe.


Cheers

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

[Tim J. <te...@we...>]

On Wed, 2007-12-26 at 16:19 -0500, David Essex wrote:

> I agree that small code may have been good practice back in the
> 60s early 70s.
> 
> However, assuming this part of the urban legend is true, these
> programs were replaced by structured programming methods.
> So memory was not an issue.
> 
> Even if the programs were written back in the 60s, these
> programs could have been easily converted by the maintainers
> of these systems. Not to mention cheaper.
> 
> As to why management choose to replace these programmers, who
> knows. Maybe it was just cheaper to replace them with less paid
> programmers. Then used some excuse to justify their actions.
> Nothing new under the sun here ...
> 
> That is the thing about urban legends, you never really know
> what to believe.
> 
> 
> Cheers

At that time a typical computer ran 100,000 instructions per second. I
remember in 1977 using a "supercomputer" capable of 1,000,000
instructions per second.  

Program listings often had clock counts written next to each
instruction, so people could add up the counts to see what the impact on
performance was of a given change, such was the concern about running
times. Using an alter statement changed an evaluation followed by a
conditional branch to an unconditional branch saving at least one
instruction.

See how much work you can get done, given a budget of 1 hour of CPU time
on such a CPU (3,600 X 100,000 = 36,000,000 instructions or about 30
milliseconds on your modern computer. This amount of processing time
would have cost about $3,000).

On such a computer, a build of GCC would have taken about 6 months (if
it had fitted in memory, which it would not have by a factor of a few
hundred). 

Tim Josling