Highlighted
Absent Member.
Absent Member.
7263 views

[archive] Wish Lists

[Migrated content. Thread originally posted on 31 May 2005]

What kinds of things do you have on your Acucorp wish list?

I'm sure I've sent some of these to support over the years, but some probably not. They are in no particular order.

- FUNCTION TRIM() to remove trailing spaces (if allowed as a source in a STRING) or perhaps a "DELIMITED BY TRAILING SPACES"

- Something like a DELIMITED BY COMMA WITH QUOTED-STRING option in UNSTRING for easy parsing of CSV files (where strings are quoted and can have embedded delimiters)

- Ability to display value of level 78 constants in the debugger

- Ability to change the accelerator key of a control (such as a button) at runtime

- Option to automatically increment/decrement a spinner when up or down arrow is pressed

- Allow Control-Tab to move through tabs in the tab control, like other Windows programs

- Allow drop down lists in cells in the grid control. ComponentOne FlexGrid control handles this nicely by allowing the list to be assigned to the column if it applies to all rows to save memory, or by enabling the firing of an event to set it on a cell by cell basis

- Allow functions using the sub85 interface to be in a DLL like the sub function can be (we need to get data types and sizes of items passed, so sub85 is required)

- Don't require a different license key for runtime versions - upgrading customers to new runtime versions is painful

- Support Samba for Vision files - sometimes Acuconnect is overkill

- Fix problem with tree view control not repainting correctly after screen saver is dismissed
0 Likes
25 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

I agree with a lot of your items (and have a few more of my own), but some of the things you are asking for are already fairly easy to implement.

The TRIM() funtionality can be done by using an INSPECT ... REPLACING TRAILING SPACES BY LOW-VALUES followed by a STRING with DELIMITED BY LOW-VALUE.

Once you write a module to do CSV parsing, you should never have to think about it again.

Seeing the 78's is a good idea, but I'd also like the debug source and compiler listing to reflect any COPY .. REPLACING changes. Any C preprocessor can do this, why can't Cobol?

While it would be nice to have the CTRL-TAB windows standard, we do this by using an accelerator key in the Tab name using the '&'. That way you get the added benefit of being able to go directly to the Tab you want rather than having to 'traverse' several Tabs to get to the one you want.

Yes, drop-lists would be nice in grids, as would spinners, checkboxes and radio buttons.

I don't understand your problem with Samba as this works fine for us now. We just map a drive on the client PC and then set the FILE_PREFIX to be something like 'H:\DATA\VISION'. Works really well and is quite fast. It's not really much different to using Acuserver.

I would add the following to a wish list:

- GUI support in X Windows (huge issue for us as we have non-Microsoft customers)

- Coloured push-buttons

- Scaled bitmaps (stretch or shrink to specified size)

- Better handling of modeless, threaded sub-applications within one runtime to allow for an integrated system with one 'launcher' (menu) front-end.

- CLICK events on the 'static' controls (Labels, Frames, etc)

- A heirarchical control (like a treeview) that has columns (like a list-box)

- Allow grid and list-box column sizing in CELLS

- Allow copy and paste in the GUI debugger command window

- Fix Alfred so it can cope with more than 16 fields in a key (although I hear that the source for Alfred will be made available in version 7.x)

I can't think of any others at the moment, but I'm sure there is more.

Cheers
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

The TRIM() funtionality can be done by using an INSPECT ... REPLACING TRAILING SPACES BY LOW-VALUES followed by a STRING with DELIMITED BY LOW-VALUE.

I've seen that technique used - the problem is that it modifies the source - or you have to copy the source to a temporary area first, all requiring more steps. I want to do it all within a single STRING. (I think my suggestion about a TRIM function is a proposed new feature for the next Cobol standard.)

While it would be nice to have the CTRL-TAB windows standard, we do this by using an accelerator key in the Tab name using the '&'. That way you get the added benefit of being able to go directly to the Tab you want rather than having to 'traverse' several Tabs to get to the one you want.

Of course we do this too (although if you have lots of tabs and also drop down menus, you run out of letters...). But for users who want to use the keyboard, the Windows standard is for Ctrl-Tab to cycle through the tabs, and we get complains that we are "non-standard" because our programs do not allow this.

I don't understand your problem with Samba as this works fine for us now. We just map a drive on the client PC and then set the FILE_PREFIX to be something like 'H:\DATA\VISION'. Works really well and is quite fast. It's not really much different to using Acuserver.

We have problems with Samba and Vision files when both Unix users and Windows users are accessing the same file and records are being locked and unlocked frequently. Although I have not tried it in a year or two with later version of Samba and Vision, I had a program that I could run on both Windows and Unix simultaneously that would beat on the same file (reads, writes, rewrites, locks, unlocks) and eventually the Windows program would hang if the file was on a Samba share. This reproduced a problem a customer was having.

If I moved the file to a Windows server, there was no problem, or if the program ran on Unix only. But in a mixed environment with Samba being used to provide Windows programs access to the file, the program would always eventually hang.

Unfortunately, if you try to get any support about this, you are told the solution is to use Acuserver - which is overkill for us because we use very few Vision files - most of our data is stored in a SQL database.

- GUI support in X Windows (huge issue for us as we have non-Microsoft customers)

In fairness to Acucorp, I recall that they asked about interest in this a few years ago and there was not that much interest. That may have changed with the popularity of Linux.

For us it would not be that useful because we are now dependent on ActiveX controls.
- Better handling of modeless, threaded sub-applications within one runtime to allow for an integrated system with one 'launcher' (menu) front-end.


It's not quite the same, but we simulate this by having our menu start a separate runtime for every program selected from the menu.

- A heirarchical control (like a treeview) that has columns (like a list-box)

Definitely useful, although we use an ActiveX control for something like this.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

Seeing the 78's is a good idea, but I'd also like the debug source and compiler listing to reflect any COPY .. REPLACING changes. Any C preprocessor can do this, why can't Cobol?

This is sort of possible with 7.0.0. There is a new compiler listing flag "-Lp" which will create a "pre-processed" output file that can later be compiled to produce the same object code as the original source. The output includes the content of all COPY files and the results of all COPY REPLACING and REPLACE logic.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

While this is a step forward, I cannot see why the compiler cannot do this in one step. As I have said to Acu support in the past about this, it doesn't need to be the default behaviour. We don't mind adding a compiler switch to 'fix' the problem.

We use COPY REPLACING extensively throughout our 3 million-odd lines of code and it is a right pain not being able to double-click on a working storage item in the debugger because it hasn't been REPLACEd. What's worse is that we have generic pieces of code that we insert COPY REPLACING multiple times into a program (a bit like OO inheritence) and in the listing and debugger source you cannot distinguish between them.

The compiler is obviously doing the REPLACING internally as the symbol table reflects the changed names, so why can't it reflect this in the debugger source?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

There's definitely been a lot of good ideas posted!

An easier way to unstring comma separated value records containing quoted strings would be a huge help, and probably a huge performace gain over the way we are currently doing it.

One of the things I've run into repeatedly that I've had to code a routine manually to hanlde is a search and replace function that allows replacements of different sizes, so inspect/replacing can't handle it. I've had it done for years so it's not a maintenance or development problem, but performance is horrible. If it could be replaced with an internal function or library routine written in C I'm sure it would be much faster!

The copy/replacing in the debugger/list file is a no brainer to me, there's no way to even look at a listing and see what the actual program is. The new option in 7.0 to compile and output a file that can be compiled is nice (a little late?!?), but I have never understood why I can't compile the listing that is supposed to show what was compiled?

Brad
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

I'd like to amend my initial post in regards to displaying level 78 items in the debugger. I would also like to be able to display ActiveX control constants (event values and enumeration constants) in the debugger - that is, as a parameter to the "d" command.

Right now, I have to search backwards to get to the environment section to find out the value.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

Originally posted by phayes

One of the things I've run into repeatedly that I've had to code a routine manually to hanlde is a search and replace function that allows replacements of different sizes, so inspect/replacing can't handle it.
Brad


In 7.0 there is regular expression search, but what is really needed is both regular expression search and replace. Just surprises me sometimes that there isn't more consistent creative thinking put into enhancement requests at acucorp, or that enhancements aren't done in a more complete manner. Acuthin being the poster child lagging behind the runtime with piecemeal changes to library routines, dll functions calls, etc, etc.

I still believe that acucorp should come up with specs for enhancments proposed for their next release and then get feedback from beta testers BEFORE they are engineered. We often do this with a segment of our clients before we begin working on enhancments and it helps us create broader and fuller implementations of new features. After all, the end users will have to live with what you've created, wouldn't you want a broader understanding of how they think it should work?

Ok, enough griping. 😃
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

Originally posted by DanM
I still believe that acucorp should come up with specs for enhancments proposed for their next release and then get feedback from beta testers BEFORE they are engineered. We often do this with a segment of our clients before we begin working on enhancments and it helps us create broader and fuller implementations of new features. After all, the end users will have to live with what you've created, wouldn't you want a broader understanding of how they think it should work?

Ok, enough griping. 😃


This is a splendid idea! Is it just me, but I have no idea what is going to be available in 7.1, 7.2, 8.0 etc. We get a vague idea from the developer conference, but this is always understandably very cagey. I appreciate the desire not to want to commit too much, but we have to make strategic plans about what tools to use (i.e. AcuCobol or something else) based on whether the facilities will be available in AcuCobol in time.

On a more specific note, being able to comment on the functionality available in some of the enhancements before they are finalised would be very useful. It seems strange that we ask for some functionality in a one-line email but no-one asks us for any more details about it, or asks for any comments on the proposals. This means the Beta testing effectively becomes a process of logging lots of enhancement requests for all the missing bits rather than actually testing the software. C$XML was a classic example where it was introduced allowing you to read XML files but not to be able to write them. Probably every developer asked for output capabilities and it arrived in the next version. Thin-client was another example where many features were missing in the first release and they gradually sneaked their way in over the next few releases.

Don't get this post wrong, I'm not intending to knock Acu or their products. They are great and we do feel that our responses are listened to and what we ask for goes into the product (we don't get this from our other suppliers). It would just be a) nice to know in more detail when things are coming and b) more efficient for Acu to have some consultation on the content.

Rant finished, time for some more performance profiling......
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

C'mon guys, lets be realistic about this.

I very much doubt that Acucorp have any major long-term plans about extending the Acucobol product.

Look at the release notes for the last few major versions (5.x onwards). 95% of the enhancements that have been made have fallen roughly into two camps: compatibility with other COBOLs, and interoperability with modern infrastructures (Java, .NET, etc). The bulk of this is to try and extend the life of customer legacy systems. Yes, I know, I hate the 'L' word too, and almost all of the thousands of lines of new code we write each day is in Cobol, but we all know we are living on borrowed time.

If Acucorp was serious about extending Acucobol they would be talking about implementing some of the 2002 OO COBOL standards.

In my opinion, Acucorp are at the tail end of this particular cash cow. Why else would they centralise all support and sales? I bet they are not going to pass on the savings of 'cutting out the middlemen' back to us as price cuts in the product range.

I very much doubt that they would be centralising sales and support if their customer base was expanding.

No we are grateful to Acucorp for staying afloat this long and in version 7.0 finally giving us the means to migrate gradually to Java. Let's hope that the customer base does not shrink too fast and they have to raise the prices too much in the short-term.

[NOTE: The above opinions are mine and mine alone, and do not reflect the opinions of McCarthy and Associates]
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

OOP is on my wish list too. Thanks for bringing that up Duncan.

Now, the response I've gotten from some acucorp folks, and fellow acucobol developers is "What do we need that for? Microfocus did it and it got them no where, fujitsu does it, but they haven't taken over the market either. I can do everything I need to do without having to fool with object oriented programming."

All valid responses for short term thinking, legacy thinking, but my response is to think longer term. Microfocus and fujitsu, in my opinion, make the mistake of primarily pushing OOP to exisitng cobol programmers and trying to force them to change. Well, it's no wonder they reject OOP programming, they don't want to "re-learn" how to program, nor do they want the expense of rewriting applications. OOP is obviosuly better suited to the new breed of programmer who is a product of the Java generation. OOP thinking, design, and development is continuing to grow. OOP langugages like Java, C#, VB.NET are all quickly becoming the top business application languages, especially for new systems, and this trend will continue. Universities favor teaching OOP principles and langugages and many developers and project managers are now well versed in it and prefer it. Where will tomorrows cobol programmers come from then? Overseas is not the answer, there will still be much hands on development happening here, especially in the growing small business vertical markets. Microsoft has no doubt taken notice of this. The growing OOP pool of programmers must be tapped and to do that acucorp needs OOP in acucobol, and they need to aggresively go after the OOP segment of product developers.

In my humble opinion, if acucorp wants to be considered more than just a cobol legacy migration tool, but a robust, viable development product for the future of new systems as well, then OOP is a requirement. Not because it is a superior programming methodology, but because it is becoming the unofficial standard programming methodology.

Interoperability with Java and .NET is key, and acucorp has addressed this, but once again in a legacy approach OOP principles are not being used in acucobol to more naturally fit with the object oriented frameworks of .NET and Java. For instance, I want to create a cobol object that implements a .NET or Java interface or an abstract class and fully implement all it's members in acucobol. That's what OOP programmers expect to able to do. But we have to push this all to the .NET and Java side and keep the acucobol side limited to dealing with handles. This is of course specific to .NET and Java, as opposed to just cobol OO which lets you create your own cobol classes, etc. But, in either case, it's the OOP methodology thats key.

Of course, I'm not naive, and I know this constitutes a ton of work for acucorp. They are more likely to put their efforts into the here and now issues that yield them the most near term profit, like migration, porting and interoperability, which is good business practice. So, unless they have the resources to section off a seperate group of software engineers, it is highly unlikely that we'll see any acucobol OOP in the near future. But, I thought it at least a topic worthy of some concern.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Wish Lists

Hey, hey, hey,

What is this? Have we got out of the wrong side of the bed this morning?

I must admit I get rather disappointed when I read the development of this thread. When it started out I figured it would be great with a wish list. But when we leave the feature wish list into discussing our business perspectives, I feel it is a bit misplaced.

Dear fellow COBOL programmers, allow me to be a bit frank and open in this posting. Please show some indulgence, there is no harm intended. Just a deep sigh from someone which really try to do the best, to make a better tool for you.

However, first allow me to think loud of things; From my personal point of view, I find the idea of letting users in on our project plan a bit interesting, but I can also foresee that it will cause an overhead of bureaucracy, administrative work. We are also talking features here, that *might* become a business advantage. Okay, we are not Microsoft or something, but sometimes, keeping stuff secret is a requirement for businesses not in the mega division as well.
Though, as I said, I kind of like the idea, and I will suggest internally something in between. That is, for a proposal that has come from a particular user, to allow that user to be able to look at the preliminary developer documentation while the new feature is still in design. Thus become able to contribute during the early phases of implementation.
This might as well be a problem of course, if this feature is close to, or uncovering another feature that is meant to be kept quiet about. But as stated, it will be a proposal, thus not a promise.

Another issue, one of you guys were surprised that when a new feature proposal of yours were accepted, we never came back and asked for details. That is not quite true, I for one has done this, but there may have been individual exceptions for a variety of reasons. It was mentioned C$XML specifically. I would like to turn that around and ask rhetorical; Why did you not provide the desired feature attributes in the first place? It is always easy to come around in the wake and say that this should have been done, and that should have been done. Why not be a bit proactive yourself? There is no blame in this from my side, just a sincere suggestion.

Thin Client have been and is an evolving technology. First of all, remember Thin Client was (is) a vast piece of development. Yes, there were inquiries for a feature like this from you before we eventually developed it, but could we be sure it would be a success? No.

If you are heading into a brand new area, where you don?t know the ground, you don?t settle a whole city on your first attempt, but you build house by house, brick by brick. Make sure it stands, is solid and that someone wants it.
Imagine if we had thrown in supporting all our features in the TC from day 1, I regret to say this, but we are not divine, so inadvertently there would have been bugs, probably, likely, many of them. Isn?t it then likely, that you guys might have thought this to be such a bad product, thus less demand, thus? Also, if we had been to do this, we would have had to put all our resources into this, and little or nothing else would have been developed. I suppose that would have been a boring release for those who couldn?t care less about TC (those exist too!).
At heart, it is a matter of learning to crawl before you walk. There is no other such product as TC in the business, it is unique. There is no book anywhere saying how you are supposed to do this and that. It is an unparalleled piece of software.
I tell you, I am very proud of being a part of this team.

As for our business perspective, first of all, allow me to state that this really is not a topic of this forum, and I will not be saying anything more about it. I consider this a one time reply and I kindly ask you to discontinue discussing the business strategies of Acucorp, Inc. This is a forum of technical discussion, nothing else. The business strategies of Acucorp, Inc. just don?t belong here. If you so desire, your sales contact within Acucorp, Inc. will be the correct channel.

As long as I have been with the company, there has been one big red thread through everything we do. That is the ANSI standard. We once aimed at the ANSI 85 standard. It should be no secret that we are committed to ANSI 2002 as well.
No, we have not discussed the individual issues and their priority in public, but why should we? The standard is available for anyone who wants to read it, we are working on it. We have our internal agenda, and yes we are committed.

How can you possibly state that we are not extending the ACUCOBOL-GT product line? Let us look down the last 5 years at extensions we have provided:

? ActiveX/COM/.net support
? Java interoperability
? XML support
? Thin Client
? External sort
? Intrinsic functions
? SOA
? And many more

These are big extensions, and it is extensions that have been preferred by a majority of our users above other features, like OO COBOL.
Mind you, we have done for all our conferences a survey for the attendees, for what to prioritize for the next development, and surprise, the answer has been following the general trend in the IT business. The majority has picked interoperability above the new ANSI features. Thus we have prioritized just like you have desired.
By saying this, I am not saying we don?t do the new standard.

When we chose to replace the middle layer which the distributors represented, that is as a matter of fact in an attempt to provide you with a better product. I am puzzled by this reaction of yours, I would consider it a benefit to be able to communicate directly with the source, rather than having to go via a middle layer. Add to this, that this move actually is more expensive for us, then I am sure you realize we do this for you, not for the benefit of us. We even open new offices, would we do that if we did not believe in COBOL?

If version 7.0 is the migration path to Java, I presume 5.0 was the migration path to COM then? That version 3.2 was the migration path to VB? I don?t even care to comment further on this, it is just beyond any reasonability.

I hope there will be no further uncertainty regarding Acucorp, Inc. and our commitment to COBOL and the standards, we have done this for almost 20 years now, and we are still doing it.

Gisle
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.