I think human has a great point.

While we wanted to keep prtcbl from being a syntax checker it does make sense that it could warn us about lines that violate the "fixed format" width.

jimc

To the "assumption" that nobody uses more than one line in COPY REPLACING:
I suggest to do a simple check on the buffers for COPY REPLACING, just do an INSPECT buffer with TALLYING for x'0A' and x'0D' - if one of them is in, quit with an error message. If the problem is the missing end of the copy (because you read the file LINE SEQUENTIAL instead of SEQUENTIAL), you can exit with an error quite easy, too.

human

Should there be any doubt, a "Standard conforming" compiler must accept X'0A" and X'0D" within an alphanumeric literal when compiling in fixed form reference format.

ALL characters within the computer's alphanumeric character repertoire are valid within alphanumeric literals - in fixed form reference format. In FREE form reference format, the implemewntor may restrict some characters.

Your idea of enforcing fixed etc as the result of the copy phase is out of keeping with the behavior of OC or any other compiler. It is the responsibility of the programmer to ensure that the result of a copy replacing clause on a fixed format source file does not exceed the limits imposed eg, going over cc 72.

This might be a useful test on OC to see what it does but I have a feeling that it follows the above logic.

I am going to try and use the Function SUBSTITUTE but have a nasty idea that it will not copy buffer 1 (pic x(1M) to buffer 2 (1M) [where 1M = 1048576 or 1024 occurs 1024] and substitute matching char strings but still copy over the others that are NOT matched and if it does not then I am struggling to see how it will help!

I am beginning to wish I had not started this !!

Doing this in Cobol, it just is not the right tool.

.. but I will continue at least in the kiss method as a starter, eg, using simple replacements with literal always on one line. Like most, I have never replaced anything that goes over a line, coming to think about it I have never replaced literals, what ho!!

PS. This system is NOT notifying me of new posts for this thread, another element that does not work

ok, found out why its not notifying me of new posts, did'nt change settings to tell me by email !!

I have now finished testing and loaded up for all to access the current version of printcbl (2.01.06) which seems to support the full set of COPY clauses with some exceptions.

Leading and Trailing is accepted but ignored when replacing due to usage of substitute that is doing the 'replacing' all other sub-clauses of copy are implemented including SUPPRESS but not ALSO as it is not in OC (Mind you I am not too sure of what its really useful for!).

Literals are processed one line at a time for the moment both for source (in COPY) and target in copy libs.

It has passed both OC regression tests along with mine (included in archive with manual and changelog).

Let me know how you get on with it but do read the manual first as you do have to make 2-3 mods before compiling.

You can download it at:
http://applewoodbbs.mine.nu/files/Cobol-Dev/printcbl-latest.zip or by anonymous ftp:
applewoodbbs.mine.nu and cd to pub/Cobol-Dev for the file printcbl-latest.zip

This is now a new installation of Mandriva 2011 pwd x64 so please let me know if you have any problems via direct mail to vbcoen at gmail.com

Thanks.

Vincent

If we can work this out the details of permissions and source tree layout with human, would you mind posting this up on SourceForge under the OpenCOBOL sources, SVN, something akin to



??

human? You think we should add to the source tree?

Cheers,
Brian

Brian;

Nope I have no problems with that.
I have already given in a similar way the code for Dectrans, cobxref etc to Arthur? so it should not be an issue providing it's easy for me to modify the files as eg, I have made two sets of changes over the last day alone to remedy minor issues.
I assume it wil be a reposity for all to get the latest versions of OC and various tools, etc.

Are you creating some forums and bug reporting on site to cover feedback from users?

Vincent.

We *could* add it to the svn repo, but as it is an own project (as long as it doesn't use/depend on OC-parts) it may would be better placed in an own project/repo?

SVN write access can be easily achieved (by being added to the opencobol-project, which can be done by me), finer access (only to /extras for example) cannot be done at SF yet, but I don't think it's a problem as every user must be added first, all changes can be simply reverted (it's a version control management system) and users can be warned/banned if they're writing to the wrong paths.

What do you think about adding code like this to the OC repo? How many new directories do we need and for what (what was the exact description to /extras?)?

And Vincent has a good point - we should either set up a new hosted app (like MantisBT) and add the community stuff there or add new categories to the main bug/feature tracker.

human

Moving to

Things at SourceForge

Cheers,
Brian