COBOL Line Numbers GnuCOBOL and Others

seasoned_geek · Mar 02, 2020#12020-03-02T16:31+00:00

I'm getting back into COBOL which is one of the reasons I'm once again looking at UltraEdit. Most PC editors tend to stink at this. I've included a screenshot of the Sublime Text plugin. Yes, they get some/many of the keywords correct for syntax highlighting. Yes, you can set a right margin indicator at 72. Where the wheels fall off the cart is the first 6 columns. (I've also included a picture of some COBOL coding sheets I have so the younger generations can understand. We used to have to write it by hand first.)

For an editor to honestly support COBOL, it has to support the FIXED (not shouting, it's just always typed upper case) source format. Editors on the big machines which do support this format auto-generate those zero filled line numbers (usually spaced by 10 but it tends to be configurable) as you are typing in code. Some will auto-generate a new line number when you attempt to insert a line and others will require you place a * or a + on top of the last digit of a line number to force new line generation. Most have a Re-number/Re-sequence option which will do either the entire file or just a range of lines. (Has to happen when you run out of line numbers in a particular spot.)

This is not a dead format. There are tens of millions of lines of code like this in production around the world. Believe it or not software vendors who sell the source to their customers also ship patches/updates in source with line numbers. Clients have to manually verify the new lines don't walk on any customizations they might have made, then they are appended to the .COB file before it is sorted and recompiled. The really good COBOL editors will let you do the sort in the editor.

I'm curious about this. Any information would be helpful in decision making.

Mofi · Mar 03, 2020#22020-03-03T06:15+00:00

Some (not all) COBOL related topis in forums:

There should be no problem to configure tab stops specific for COBOL. UltraEdit supports the definition of multiple tab stops for files with a specific file extension.

There should be no problem to use a (customized) COBOL syntax highlighting wordfile without keyword Nocase with all keywords in upper case and with Auto-correct keywords enabled in configuration to get all keywords defined in the wordfile automatically inserted into the file in upper case even on typing them in lower case.

There should be no problem to write a small UltraEdit script which renumbers the lines according to the COBOL coding rules in entire file or just in current selected block. It looks like the lines are numbered in steps of 10, except the line is empty (with exception of the line number) or there is an asterisk or a plus after line number in which case the line number is incremented by one. Those rules can be easily taken into account by UltraEdit script code for renumbering all lines of a COBOL file or just the lines of a selected block in a COBOL file.

A customized code folding should be also easy to define in the wordfile for syntax highlighting COBOL files.

seasoned_geek · Mar 19, 2020#32020-03-19T18:40+00:00

Mofi wrote: ↑
Mar 03, 2020
There should be no problem to configure tab stops specific for COBOL. UltraEdit supports the definition of multiple tab stops for files with a specific file extension.

Actually UE on Linux has had a long standing bug here. When one sets the tab stop to 4 and is configured to use spaces, the first tab key lands in 5 and the second tab key lands in 9.

Mofi · Mar 20, 2020#42020-03-20T07:46+00:00

I don't see a bug here. A tab stop of 4 with using spaces means clearly that pressing key tab at beginning of a line results in inserting four spaces and so the next character is at column 5 with counting first column of a line as column 1 as shown in status bar. One more tab results in inserting again four spaces and the caret is at column 9 as there are now 8 spaces before. The same column positions are achieved if a horizontal tab character in file represents up to 4 spaces on having a tab stop of 4 configured.

The ruler at top of a document window can be configured to count the columns with starting with 0 (useful for programmers) or with 1 (for all other text writers and also programmers if they prefer that). The status bar at bottom shows column number always with 1 for first column. I don't know any text editor which makes this different on using a tab stop value of 4. The column number indication can vary between 4, 8, 12, ... and 5, 9, 13, ... between the various text editors depending on first column of a line having number 0 or number 1.

seasoned_geek · Mar 20, 2020#52020-03-20T13:43+00:00

Mofi wrote: ↑
Mar 20, 2020
I don't see a bug here. A tab stop of 4 with using spaces means clearly that pressing key tab at beginning of a line results in inserting four spaces and so the next character is at column 5 with counting first column of a line as column 1 as shown in status bar. One more tab results in inserting again four spaces and the caret is at column 9 as there are now 8 spaces before. The same column positions are achieved if a horizontal tab character in file represents up to 4 spaces on having a tab stop of 4 configured.

That would be a completely false statement. It's a vicious bug.
This is why you never let people who've only used PCs and never written COBOL develop text editors. UltraEdit does not get this right. If you've never written COBOL and never used a physical terminal, then I can understand the lack of knowledge on this. If you've never had to use a manual typewriter, I can also understand the false assumption. A STOP placed in column 9 BLOCKS the cursor from going past column 8. We had character cells.

I couldn't find the image of an actual VT-100 with the setup on the screen. I ran into it the other day, but cannot find it now. I no longer have either my VT-100 or VT-220 so cannot take a shot myself. Given that we will first go here.

Well, I found one of the shots, just not the one I was looking for.

Now we have to think why COBOL's Area-A starts in column 8.

I screen scraped that from Tutorials Point if you want to wade through the entire thing.

On both manual and electric typewriters, well, IBM and Smith Corona which were the two biggest brands of the "modern" typewriters once we got rid of the Underwood that didn't even have all of the keys, the first physical tab stop put the next printable character at column 8. Wow! Someone had a good one of these!

The carriage/platen stop was always placed one character travel beyond the type guide. There was a gear with a toothed rail controlling all of this. Keypunch machines and paper terminals maintained this convention in large part because the early models of both were little more than customized typewriters.

COBOL programmers fortunate enough to have a VT-52, 100 or later were overjoyed. Not only did it allow you to manually set the tab stops, it came with two setups, A and B. A, the default power-on setup, was almost always left to factory tabs of 8. This was so if mere mortals needed to use it they could. Setup B was normally used by COBOL programmers. The first tab stop of 8 was left in place but an extra tab stop was placed at 12. If you worked at a shop that had a "final comment" standard, you added a tab stop which put your cursor in column 73.

The ultimate test is rather simple. Pull down GnuCOBOL. Use UltraEdit with soft tabs set to 8. Type in a simple "Hello World" COBOL program using the tabs you say are correct and the 80-column "fixed" card format pasted above. Compile the program. It will fail miserably because Area-A starts in the wrong place. When text editors implement tab stops correctly, this doesn't happen.

cobc -x -fixed -std=cobol85 COB001.COB

There was a method to the madness.

Mofi · Mar 20, 2020#62020-03-20T15:18+00:00

Thanks for all the details. I understand the issue now.

It is possible by pressing key TAB to stop on the COBOL areas on having configured 6, 1, 4, 61, 8 for Tab stop value and have the option Use spaces in place of tabs not checked to really insert horizontal tab characters on pressing key TAB.

But there must be inserted spaces and not horizontal tabs up to next tab stop value. For that reason the option Use spaces in place of tabs is checked in configuration. But now the values defined for the tab stops are used only for existing horizontal tab characters in the file. The key TAB results in inserting spaces according to the Indent spaces value.

For a COBOL programmer that is definitely not the wanted behavior. But it is not a bug in code of UltraEdit because of this behavior is by design and is described on help page Settings:Editor:Word wrap / tab settings. A bug is a mistake in code of a program resulting in program behavior being different as designed and described.

So a COBOL programmer using UltraEdit for writing COBOL code would need an UltraEdit script like this one with a hotkey assigned to the script (other than key TAB as this key has many different meanings depending on context) for quick inserting the spaces up to next COBOL area. Alt+Space would be in my point of view a good hotkey for executing this script for quick usage by a COBOL programmer.

Code: Select all

if (UltraEdit.document.length > 0)
{
   UltraEdit.insertMode();
   if (typeof(UltraEdit.columnModeOff) == "function") UltraEdit.columnModeOff();
   else if (typeof(UltraEdit.activeDocument.columnModeOff) == "function") UltraEdit.activeDocument.columnModeOff();
   // A simple string variable with 61 spaces which is the maximum to insert at once.
   var sSpaces= "                                                             ";
   var nCurrentColumn = UltraEdit.activeDocument.currentColumnNum;
   if (nCurrentColumn < 7)
   {
      UltraEdit.activeDocument.write(sSpaces.substr(0,7 - nCurrentColumn));
   }
   else if (nCurrentColumn == 7)
   {
      UltraEdit.activeDocument.write(" ");
   }
   else if ((nCurrentColumn > 7) && (nCurrentColumn < 12))
   {
      UltraEdit.activeDocument.write(sSpaces.substr(0,12 - nCurrentColumn));
   }
   else if ((nCurrentColumn >= 12) && (nCurrentColumn < 73))
   {
      UltraEdit.activeDocument.write(sSpaces.substr(0,73 - nCurrentColumn));
   }
   else
   {
      var nNextTabStop = ((nCurrentColumn + 7) & (~7)) + 1;
      UltraEdit.activeDocument.write(sSpaces.substr(0,nNextTabStop - nCurrentColumn));
   }
}

seasoned_geek · Mar 20, 2020#72020-03-20T15:28+00:00

Then it is bad design which itself is a bug. Even EDT on the PDP-11 did this correctly. The number of spaces inserted were controlled by the terminal. So did TECO, an even older text editor. Even Emacs gets this right. You can download it and try it yourself. Yes there is a version for the virus known as Windows.

In your .emacs configuration file insert the following 2 lines.
(setq-default intent-tabs-mode nil)
(setq default-tab-width 4)

Most programmers who work on both PC based and serious computers set tab width to 4 and turn off tabs. We also enable auto-indent so when we are working in Area-B the next line starts there. You only have to triple tab on the first line of a new paragraph.

Mofi · Mar 20, 2020#82020-03-20T17:47+00:00

Well, if you are not happy with the design on inserting spaces on pressing key TAB and you don't want to use the script for a customized solution, I can only suggest to write a feature request and send it by email to IDM support for getting the wanted behavior perhaps in a future version of UltraEdit. I cannot further help you if you are not happy with what I provided here in user to user forum.

seasoned_geek · Mar 22, 2020#92020-03-22T14:38+00:00

The issue with the TAB key shows a severe lack of industry knowledge was behind the product design. The definition and function of a TAB is by no means new.

It's basically like this. I shouldn't have to hack an editor someone expects me to pay for. Any tweaks should be a menu option or an add-on theme/profile/etc. that is just downloaded and used. When an editor is "free" as in beer I expect to have to hack. This goes for the C++ coding style especially. Most of the editors I use on various platforms have this as a radio button off a menu. Click Alman/BSD and tell it to apply. Even if it is running Artistic style in the background, the coding style is "just there."

So, Emacs, one of the oldest cross platform editors out there gets tabs right, works well for COBOL, and is free. VSCodium, well, see for yourself.

The first 2 gray lines mark the indicator column. First TAB takes you to the cursor position where the I in IDENTIFICATION is. Second TAB takes you to the first cursor position of Area-B. I didn't put any time into getting it to support the "free format" style of COBOL-85. I'm sure there is a way.

This editor is "free" as in air, not beer. It has all of the illegal/nasty Microsoft tracking software removed. I don't care that in the default text editor the TAB key is broken because someone who actually knew something created the COBOL support.

Mofi · Mar 22, 2020#102020-03-22T15:36+00:00

I cannot agree with what you wrote. No text editor can fulfill all requirements all users have on a text editor. If such a text editor would exist, all people would use that text editor and no other text editor would be available.

UltraEdit is a general text editor. It is not written with features specific for COBOL programming or for C/C++ programming or any other programming or scripting language. It is a general text editor and not an IDE - Integrated Development Environment - for a specific (set) of programming or scripting language(s). Visual Studio is an IDE, Eclipse is an IDE, Atmel Studio is an IDE.

Visual Studio is definitely the best program suite for people writing programs in C/C++/C# for Windows GUI and Windows console. On the other hand Visual Studio is not good for text editing purposes for which it is not designed for like viewing/editing a huge log file with several GB or for writing batch files or for editing text files with a custom format.

I really don't understand why you complain here in user to user forum that UltraEdit is not the best text editor for writing COBOL code and mention Emacs and VSCodium. If those applications are better for writing COBOL code, then use them instead of UltraEdit. If UltraEdit is not the best editor for C/C++ code using a specific style, and other applications do that better, than use those other applications.

Suggestions for new features, enhancements and improvements can be send to IDM support at any time and if enough users want a specific feature, enhancement or improvement, IDM Computer Solutions will definitely take that into consideration. You can also ask the UltraEdit user community here in user to user forum what they think about a suggestion you have for a future version of UltraEdit and discuss that with the UltraEdit users interested in that, too.

UltraEdit is for me the best general text editor and I use it daily for various text editing purposes. UEStudio is used by me for C/C++ programming and for HTML writing although there are IDEs for C/C++ and HTML writing which have features which UEStudio does not have. But I could compensate that with the usage of smart templates, macros and scripts to get a text editing environment which perfectly matches my coding requirements. None of my customizations are shared public anywhere because of those customizations are tailor-made for my coding work. Most of those customizations are not even shared with my programming colleagues because they prefer to write code different to me. A few colleagues use even a different application for their coding work. But guess how often my colleagues come to me per week and ask me to help them as they can't do something on their files which I can do with a few keystrokes using UltraEdit. I have an installation with my customizations on server just to be able to do such editing tasks on the files of my colleagues on their computers.

I have a personal life-time license for UltraEdit, for UEStudio and for UltraCompare. So I paid once years ago for the life-time licenses and use always the newest version of UltraEdit available for the three computers used by me. And I must say that for me the investment in those three life-time licenses is returned already thousands of times taking into account how much time they have saved me in the past in comparison to how much time my colleagues spend for doing something which I do with some keystrokes in a few seconds.

BTW: It would be also possible to configure for files with COBOL file extension to insert tabs instead of spaces with the tab stop values as written by me and use a small macro which is configured to be executed on every file save which saves a file with COBOL file extension with conversion from tabs to spaces. Then it would be possible to use key TAB as needed for COBOL coding and have in saved file nevertheless spaces instead of tab characters.

seasoned_geek · Apr 03, 2020#112020-04-03T13:43+00:00

Mofi wrote: ↑
Mar 22, 2020
I cannot agree with what you wrote. No text editor can fulfill all requirements all users have on a text editor. If such a text editor would exist, all people would use that text editor and no other text editor would be available.

Actually some are getting close. There is even a resurgence in Emacs now that it added ODT support.

Mofi wrote: ↑
Mar 22, 2020
Visual Studio is definitely the best program suite for people writing programs in C/C++/C# for Windows GUI and Windows console. On the other hand Visual Studio is not good for text editing purposes for which it is not designed for like viewing/editing a huge log file with several GB or for writing batch files or for editing text files with a custom format.

Professionals don't touch Microsoft products, especially their operating systems.

Mofi wrote: ↑
Mar 22, 2020
I really don't understand why you complain here in user to user forum that UltraEdit is not the best text editor for writing COBOL code and mention Emacs and VSCodium. If those applications are better for writing COBOL code, then use them instead of UltraEdit. If UltraEdit is not the best editor for C/C++ code using a specific style, and other applications do that better, than use those other applications.

Because people need to know before they waste their money. I used to be a paying customer. Every time I wanted to use UltraEdit for something real I would ask in here and I would get the same response: "This is a general text editor, it is not. If you want to do that hack this script, hack that script, hack hack hack and God forbid you want to migrate your settings to more than one VM/machine."

You shouldn't have to hack an editor you pay money for.

Right now I'm down to 4 full-time running desktop machines. This is the smallest number I've been using in years. Mostly that is due to VMs getting better. Different machines, different clients/projects/etc. When they cycle off project they run BOINC until needed again.

For someone using one laptop, hack hack hack is probably fine.

For a professional developer that is busting down and rebuilding machine environments for each project, the multi-install license is/was appealing, but it is only appealing when out of the box it does most of what you need or there is exactly one file you need to migrate between environments.

The invalid TAB implementation basically makes UE useless for anything I will be doing during the rest of my professional life. The hack hack hack makes it unappealing.

The fact that the Linux version is treated like the ugly red headed stop child chained in the basement is completely unappealing because professionals don't touch Microsoft products, especially their operating systems.

Before people pay money for it, they need to know these things.

Valid software companies actually monitor their user forums to identify what it is their customers are complaining about.

Hopefully this Tapa thing will stop notifying me of responses.

Apr 03, 2020#122020-04-03T13:44+00:00

Mofi wrote: ↑
Mar 22, 2020
I cannot agree with what you wrote. No text editor can fulfill all requirements all users have on a text editor. If such a text editor would exist, all people would use that text editor and no other text editor would be available.

Actually some are getting close. There is even a resurgence in Emacs now that it added ODT support.

Mofi wrote: ↑
Mar 22, 2020
Visual Studio is definitely the best program suite for people writing programs in C/C++/C# for Windows GUI and Windows console. On the other hand Visual Studio is not good for text editing purposes for which it is not designed for like viewing/editing a huge log file with several GB or for writing batch files or for editing text files with a custom format.

Professionals don't touch Microsoft products, especially their operating systems.

Mofi wrote: ↑
Mar 22, 2020
I really don't understand why you complain here in user to user forum that UltraEdit is not the best text editor for writing COBOL code and mention Emacs and VSCodium. If those applications are better for writing COBOL code, then use them instead of UltraEdit. If UltraEdit is not the best editor for C/C++ code using a specific style, and other applications do that better, than use those other applications.

Because people need to know before they waste their money. I used to be a paying customer. Every time I wanted to use UltraEdit for something real I would ask in here and I would get the same response: "This is a general text editor, it is not. If you want to do that hack this script, hack that script, hack hack hack and God forbid you want to migrate your settings to more than one VM/machine."

You shouldn't have to hack an editor you pay money for.

Right now I'm down to 4 full-time running desktop machines. This is the smallest number I've been using in years. Mostly that is due to VMs getting better. Different machines, different clients/projects/etc. When they cycle off project they run BOINC until needed again.

For someone using one laptop, hack hack hack is probably fine.

For a professional developer that is busting down and rebuilding machine environments for each project, the multi-install license is/was appealing, but it is only appealing when out of the box it does most of what you need or there is exactly one file you need to migrate between environments.

The invalid TAB implementation basically makes UE useless for anything I will be doing during the rest of my professional life. The hack hack hack makes it unappealing.

The fact that the Linux version is treated like the ugly red headed stop child chained in the basement is completely unappealing because professionals don't touch Microsoft products, especially their operating systems.

Before people pay money for it, they need to know these things.

Valid software companies actually monitor their user forums to identify what it is their customers are complaining about.

Hopefully this Tapa thing will stop notifying me of responses.

ajones · Apr 16, 2020#132020-04-16T19:15+00:00

I just wanted to say I think this thread is even more interesting as it started before some states started begging for COBOL programmers. I do think there could be some configuration option improvements in that area, even for a general purpose editor.

I think it would be important to clearly outline the items and send them to support [email protected] and not just post them here.
Clearly outline the needs and you may find some things get implemented.

TXWizard · Jun 23, 2020#142020-06-23T04:10+00:00

Thanks for the walk down memory lane. I remember every bit of what you showed, and enjoyed sharing the tour with my wife.

I wish you all the best as you delve into COBOL again.