I have some cobol program source code for an order entry system that was used on the Tandy 6000 system. I have an emulator trs80gp.exe for this system.
According to the cobol development system that was used to write this system is RM-COBOL based on standard 74. I can compile and run this software on the emulator. I'm trying to compile this source code using GnuCOBOL.
I use the -std=rmparameter when compiling. I initially had many errors. I have the remaining errors I can't solve. I will appreciate any advice from this forum.
C:\TRS-6000\oe-source\all>cobc screen.cbl -std=rm
screen.cbl: in section 'LEVEL-2':
screen.cbl: in paragraph 'ENTER-ALPHA-NUMERIC':
screen.cbl:334: warning: CONTROL KEY is not implemented
screen.cbl:340: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'ENTER-ONE-DECIMAL':
screen.cbl:376: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'ENTER-TWO-DECIMALS':
screen.cbl:435: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'ENTER-THREE-DECIMALS':
screen.cbl:494: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'ENTER-NUMBER':
screen.cbl:563: warning: CONTROL KEY is not implemented
screen.cbl:570: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'ENTER-DATE':
screen.cbl:650: warning: CONTROL KEY is not implemented
screen.cbl:657: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'ENTER-ANSWER':
screen.cbl:704: warning: CONTROL KEY is not implemented
screen.cbl:710: warning: CONTROL KEY is not implemented
screen.cbl: in section 'DISPLAY-SECTION':
screen.cbl: in paragraph 'FIELD-NUMBER-TO-CHANGE':
screen.cbl:877: warning: CONTROL KEY is not implemented
screen.cbl: in paragraph 'DISPLAY--WAIT':
screen.cbl:954: error: syntax error, unexpected DISPLAY, expecting LINE or SCREEN
screen.cbl:960: error: syntax error, unexpected DISPLAY, expecting LINE or SCREEN
screen.cbl: in paragraph 'CLEAR--SCREEN':
screen.cbl:981: error: syntax error, unexpected ELSE, expecting LINE or SCREEN
I'm sure it will be helpful to see the source code. I'm not sure how I can submit this.
Last edit: Simon Sobisch 2023-08-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But looking at the error messages you are using a RM feature that is not supported CONTROL-KEY as I do not know what it does or did cannot suggest a replacement etc other than removing it and recompiling.
Note that that phase is NOT present in current RM compiler (v8) as just looked at the manual at :
Any chance of a full copy of this system including any documentation etc)
Would like to see if it can work under a Linux system and interact with
my open source ACAS system.
You could send it as a attachment to vbcoen@btconnect.com.
Vince
On 22/08/2023 17:08, John Grillot wrote:
I have some cobol program source code for an order entry system that was
used on the Tandy 6000 system. I have an emulator trs80gp.exe for this
system . According to the cobol development system that was used to write
this system is RM-COBOL based on standard 74. I can compile and run this
software on the emulator. I'm trying to compile this source code using
GnuCOBOL. I use the s-std=rm parameter when compiling. I initially had
many errors. I have the remaining errors I can't solve. I will appreciate
any advice from this forum.
I'm sure it will be helpful to see the source code. I'm not sure how I can
submit this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oe.tar is all the work I did to get the source code from the IMD files found in the archive into a format the TRS XENIX cobol compiler needs. For example, removing the / from file names. Since the original compiled program file names distributed for this system are lower case, I changed the source file names to lower case too. I'm not sure if this is necessary. I just did that because it made since to me. I had to change the source code to refer to the program & data file names to lower case. I also edited the code to change the data file names.to remove the ":3" and ":2" and ":1" from the data files opened. There were some other changes I made to get the code to compile. There are too numerous for me to explain now. I also uploaded the IMDs of the source code from the archive that are in the TRSDOS format. And the documentation for the order entry system.
So might begin your testing with the source in Oe.tar. You may also decide the changes I made were not necessary and you can start from scratch using the IMD files. I used notepad++ compare add on for inspecting changes I needed to add. You can use this to find the changes I made.
I hope you find a way to get this to run on Linux. Please keep me updated on your progress.
Last edit: Simon Sobisch 2023-08-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use the -std=rm parameter when compiling. I initially had many errors. I have the remaining errors I can't solve.
Which many errors did you have and how did you fix those?
He is using progs that used RS Cobol a rm cobol v4 that used the TRSDOS O/S.
It was like all of the kit then very short on Ram so heavy usage of segmentation and lots & lots of calls to progs to continue one or more steps of processing.
Had similar for MF Workbench - no not as bad but it was a very long time ago.
RS / RM uses special coding for screen, printer and file exception processing. The last is just a case of replacing terms etc.
The other two some what more but I am still looking through the code - assuming it is complete.
A lot of the issues is just a case of changing dialects and coding to cope with *nix and windoz etc and not using floppies.
Yes, coded around 1981 for a Tandy - enough said :)
Last edit: Simon Sobisch 2023-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the errors are listed on my first post of this thread. I haven't solved most yet. 2 days ago, you offered suggestions in a previous reply to my request for help. the ERASE SCREEN worked. I tried the CONTROL KEY issue suggestions Writing my own CHECK-FOR-FUNCTION-KEY-ENTERED is beyond my skills.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the errors are listed on my first post of this thread. I haven't
solved most yet. 2 days ago, you offered suggestions in a previous
reply to my request for help. the ERASE SCREEN worked. I tried the
CONTROL KEY issue suggestions Writing my own
CHECK-FOR-FUNCTION-KEY-ENTERED is beyond my skills.
Found the RS-Cobol v4 manual (based on RM Cobol v4) along with some
others for TRS80 all in the same .pdf file.
You can get it at :
That RS-Cobol manual is for the model 4. I have been doing my testing on the model 16 which can run XENIX and TRSDOS. There may be differences in that COBOL.versus the xenix.
Last edit: Simon Sobisch 2023-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had to make other changes when I get errors compiling the .cbl programs as cobc -m $i -T $i.prn etc
So getting a lot of errors mostly of errors in the code base
One very interesting error I get is where there is a data name that is the SAME as a procedure paragraph name the compiler is complaining of a redefinition issue. I.e.,
/home/vince/cobolsrc/oe/To Vince/src/copybook/acctno.pl:41: error: redefinition of 'DISPLAY-ACCOUNT-NO'
Now I would have thought that the compiler should distinguish between the two and should NOT be objecting.
@Simon ?
I cannot see a way of telling the compiler to deal with it :)
Before I forget please provide me your email address ... It will speed up comms between us.
Plus I do not think every one is interested in this topic - at least for now.
Vince
Last edit: Simon Sobisch 2023-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those "source data set files", which are "combined" can be extracted with a plain use of command line tools, can't they? How is the encoding of file names / separation done in those data sets?
Does the "old" code use copy cobybook-name in data-set-name?
How are the "main sources" stored?
I have had to make other changes when I get errors compiling the .cbl programs
Sight, which ones? Did you also have those with -std=rm-strict (can you recheck)?
I do not think every one is interested in this topic - at least for now.
That's not a mailing list and the few people that subscribe to the whole discussion board likely are interested. It is definitely interesting to have a peek at a "migration project", even if that is done mostly out of fun/interest.
For me personally, it is important and useful to see where issues are, also to improve GnuCOBOL's "easy use for migrations".
After all it can also be useful to include appendices to the programmer's guide "migrate from xyz" (we could have a general chapter in the main document and an appendix for each (set of) environments, that give insights about "map compiler options", "map io status", "things that need a rewrite", ...
One very interesting error I get is where there is a data name that is the SAME as a procedure paragraph name the compiler is complaining of a redefinition issue. [...]
Now I would have thought that the compiler should distinguish between the two and should NOT be objecting.
Yes, that is an old regression in GnuCOBOL, tracked in [feature-requests:#260]. If I have that right, then standard COBOL never allowed procedure-names to overlap with data-names (but other overlaps are OK), but most compilers do support this overlap.
There's also a "too much" change that covers that in https://github.com/OCamlPro/gnucobol/pull/31 which should be trimmed down to the procedure-names overlapping data-names; at least if my understanding is right. ... I'll ask the COBOL-committee and report back in that FR.
On 25/08/2023 07:45, Simon Sobisch wrote:
--- cut ---
Those "source data set files", which are "combined" can be extracted with a plain use of command line tools, can't they? How is the encoding of file names / separation done in those data sets?
Does the "old" code use |copy cobybook-name in data-set-name|?
How are the "main sources" stored?
Well, there is some code missing due to the way the old source are stored for TRS80 that was the work that John carried out and I will not know if there is any more until some testing of the application starts.
copybooks are used including within the procedure div and all such copybooks are in a folder with COBCPY set for this work.
I have had to make other changes when I get errors compiling the .cbl programs
Sight, which ones? Did you also have those with |-std=rm-strict| (can you recheck)?
I have been using the default settings but could try and use -std=rm and see what happens on a full recompile
For the moment all compiles are using -m until I work out what are the main programs and against called modules.
I do not think every one is interested in this topic - at least for now.
That's not a mailing list and the few people that subscribe to the whole discussion board likely are interested. It is definitely interesting to have a peek at a "migration project", even if that is done mostly out of fun/interest.
For me personally, it is important and useful to see where issues are, also to improve GnuCOBOL's "easy use for migrations".
After all it can also be useful to include appendices to the programmer's guide "migrate from xyz" (we could have a general chapter in the main document and an appendix for each (set of) environments, that give insights about "map compiler options", "map io status", "things that /need/ a rewrite", ...
Possibly but remember I am migrating a 1980 codebase used with RM Cobol v4 or there about as issued to Tandy for TRS80.
One very interesting error I get is where there is a data name that is the SAME as a procedure paragraph name the compiler is complaining of a redefinition issue. [...]
Now I would have thought that the compiler should distinguish between the two and should NOT be objecting.
Yes, that is an old regression in GnuCOBOL, tracked in [feature-requests:#260]. If I have that right, then standard COBOL never allowed procedure-names to overlap with data-names (but other overlaps are OK), but most compilers do support this overlap.
There's also a "too much" change that covers that in https://github.com/OCamlPro/gnucobol/pull/31 which should be trimmed down to the procedure-names overlapping data-names; at least if my understanding is right. ... I'll ask the COBOL-committee and report back in that FR.
There is a lot of code that uses the same name as in a variable in WS and as a paragraph name and the usage matches ie., a test for a 88 DISPLAY-FIELD for true then a PERFORM DISPLAY-FIELD. There is a lot of these and these dups are not getting packed up in the same run of the compiler (3.2 final)
RM COBOL is happy with this - I assume as I do not have the compiler :), - the doc for this application is detailed for a 1980s document and includes very basic program specs but omits details about compiling options so a bit of guess work really but this phase is just getting the code base through the compiler error and warning free.
Would be useful to turn this problem off using a compiler switch - it could join the many others.
Next went through all the .cbl files and changed :
While a global change is often useful the question for migrations is: what is actually needed.
All program names to lower case including calls.
That's just a style issue, no?
If all are upper-case then it should work a is, if not, then -ffold-call=lower should work, no?
Removed the noise word IS from most but not for the programs.
That's another style-only issue, no? cobc should have no problem with its use - if it has then this definitely needs a patch (which in 98% of the cases would be very simple), but as far as I know it just supports that everywhere other compilers do.
Removed bad or noise words for the DISPLAY and ACCEPT such as TAB, CONVERT, No BEEP, etc.
Again - cobc should support that and we would need issues created if its parser stumbles over any of these. Note that the mentioned ones also seem "functional", not "noise".
All that said with - should be compiled with -std=rm-strict.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Next went through all the .cbl files and changed :
While a global change is often useful the question for migrations is:
what is actually needed.
All program names to lower case including calls.
That's just a style issue, no?
If all are upper-case then it should work a is, if not, then |-ffold-call=lower| should work, no?
Removed the noise word IS from most but not for the programs.
That's another style-only issue, no?
|cobc| should have no problem with its use - if it has then this definitely needs a patch (which in 98% of the cases would be very simple), but as far as I know it just supports that everywhere other compilers do.
Removed bad or noise words for the |DISPLAY| and |ACCEPT| such as |TAB|, |CONVERT|, |No BEEP|, etc.
Again - cobc should support that and we would need issues created if its parser stumbles over any of these. Note that the mentioned ones also seem "functional", not "noise".
All that said with - should be compiled with |-std=rm-strict|.
Compiler did not like TAB, CONVERT and NO BEEP not so sure about the
last one.
More importantly, the compiler does not know the difference between variable and paragraph name being the same and that is causing a lot of issues.
In addition when I fix one reported issue regarding these reused names and recompile it finds yet another which I look for using the -T option.
How ever I gave up at 02:20 this morning so will take another look but did not get much sleep so will be working in zombie mode.
Last edit: Simon Sobisch 2023-10-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you provide some specific test programs that don't compile with std=rm-strict (with the variable-named-as-procedure issue fixed)? This would help improving the parser and/or the compiler dialect configuration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While it "might" work better if RM used as it still uses the standard
method capturing numeric data from screen it will not improve matters as
that is the biggest issue to date when using the module screen.cbl
At the moment I am trying to work out a way of still using it but use
A/N field to capture and display numbers with minimum changes to the
application itself - i.e., no coding changes other than to screen.
All programs that require screen i/o call this module that uses field:
SCREEN-NUMERIC-FIELD PIC S9(12)V9(3). *> 16 = 190 SHOULD
sign be removed ?
for capture and data transfer between the caller and the called
(screen.cbl) so considering changing that to (may be) :
05 Screen-Numeric-Field pic -(11)9v999
with a field above it say called 03 Screen-Numeric-Field-x.
And using that for accept and again for display by using numval SNF-X
(Screen-Numeric-Field-x) to temp-field -(11)9.999 field then move to SNF
for the caller to process. Just have to work out what to do the
opposite way when displaying the field as there is not a opposite
function to numval.
The only other options are related to changing every program that need
numeric processing and use numval and then fiddle to process the other
direction. - A very large pain and time waster and I am getting to the
age when I cannot afford it.
I appreciate the above might not be very clear and can provide the code
base of the OE system or just screen.cbl the total codebase is 2 Mb
which includes the system specifications manual as a pdf although there
has been a "few" change made.
Can you provide some specific test programs that don't compile with
|std=rm-strict| (with the variable-named-as-procedure issue fixed)?
This would help improving the parser and/or the compiler dialect
configuration.
OK, just done a quick scan and edit to all copy book items files end with ds, sl, fd, pl, ws and the area that I changed and more is needed is :
All file .sl entries needed changing to lower case and the file extensions to .dat.
Most if not all date handling routines need to be made millennium compliant, i.e., date format changed to :
CCYYMMDD instead of YYMMDD and likewise the reverse MMDDCYY from MMDDYY and allowance for users outside the USA for formats DDMMCCYY and CCYYMMDD (standard *nix format) and this will
involve a lot of data areas to be changed AND some processing but most is called or performed so less of a problem.
Also the get the date processes need to convert to using *nix format dates and storing of them possibly.
File handling will rear its head as status codes have to be changed and the gc copybook use different var names - no surprise there.
Printer processing and file layouts will need to be changed - I may see more when looking at the progs.
Screen, a lot of changes will be needed here.
Next is to look at the .cbl files and no doubt similar issues.
Jezz, who ever did this work for the original business sure make work hard for themselves but I might change my mind on that once I look through the programs.
I want to look at the manual - pity it is not as a text file but a PDF as it is not easy to read as is but shows it is from the 70's.
Be interesting to see if they have including programming specs for all progs which will be useful.
More later.
Vince
Last edit: Simon Sobisch 2023-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the accept is exited with any key but Return/Enter it moves the function key value (in case of ACUCOBOL-GT this can be externally remapped an also be remapped from COBOL, not sure how this is with RM/COBOL) to the numeric identifier, in this case FUNCTION-KEY-PRESSED.
GnuCOBOL can parse that, but it doesn't make any sense to directly map it as the control-key values differ. It is a bit like io status values which may be different, but much more..
Note that this is a warning which this "I'll ignore that". To not only let that compile but "work" you'd have to drop that and rewrite CHECK-FOR-FUNCTION-KEY-ENTERED to test the crt-status for the GnuCOBOL values (distributed in copy screenio.). The Programmer's Guide should have a note about how you can do this.
The root of the compile error is quite clear, especially when using GC 3.2, which often removes the need to send the complete source, too :-) :
screen.cbl:954: error: syntax error, unexpected DISPLAY, expecting LINE or
SCREEN
The first DISPLAY statement is not ended because the cobc version you use expects ERASE LINE or ERASE SCREEN... so the easiest way to fix that is just replace ERASE BY ERASE SCREEN.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know the packages you have all too well. Back in the day I purchased the source code for all of them: AP, AR, GL, etc. And screen.cbl came in very handy creating my own applications. Also looking to modify some code in those oldies for GNUCobol and having your same issues. Is there a way for us to connect outside of this group?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These builds occur every night at 00:00 UK time (GMT+1) and archive my current version of the sources but that will include any bugs as well.
I have currently stopped working on OE as they only difference in it against Invoicing within Sales Ledger is salesman and their commission, Back Orders etc, has now been included in Invoicing as well as a similar pair of reports of the new file bostkitm as well as the ability of amend, create and delete such records.
I will be looking at adding in the ability of the invoice program also to take the bostkitm file and use it to create such invoices for newly arrived stock as updated by the Stock Additions program (which now updates bostkim file with quantity added and date),
For direct comms use vbcoen@gmail.com
Vincent
Last edit: Vincent (Bryan) Coen 2024-04-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These builds occur every night at 00:00 UK time (GMT+1) and archive my
current version of the sources but that will include any bugs as well.
I have currently stopped working on OE as they only difference in it
against Invoicing within Sales Ledger is salesman and their commission,
Back Orders etc, has now been included in Invoicing as well as a similar
pair of reports of the new file bostkitm as well as the ability of amend,
create and delete such records.
I will be looking at adding in the ability of the invoice program also to
take the bostkitm file and use it to create such invoices for newly arrived
stock as updated by the Stock Additions program (which now updates bostkim
file with quantity added and date),
I have some cobol program source code for an order entry system that was used on the Tandy 6000 system. I have an emulator trs80gp.exe for this system.
According to the cobol development system that was used to write this system is RM-COBOL based on standard 74. I can compile and run this software on the emulator. I'm trying to compile this source code using GnuCOBOL.
I use the
-std=rmparameter when compiling. I initially had many errors. I have the remaining errors I can't solve. I will appreciate any advice from this forum.I'm sure it will be helpful to see the source code. I'm not sure how I can submit this.
Last edit: Simon Sobisch 2023-08-24
To help you we would need to see the source code.
But looking at the error messages you are using a RM feature that is not supported CONTROL-KEY as I do not know what it does or did cannot suggest a replacement etc other than removing it and recompiling.
Note that that phase is NOT present in current RM compiler (v8) as just looked at the manual at :
https://www.microfocus.com/documentation/rm-cobol/1214/RMC-UG.pdf
OR
https://supportline.microfocus.com/documentation/books/liant/Archive/rmcug80.pdf
Last edit: Simon Sobisch 2023-08-24
Here it is. Thanks for replying.
Any chance of a full copy of this system including any documentation etc)
Would like to see if it can work under a Linux system and interact with
my open source ACAS system.
You could send it as a attachment to vbcoen@btconnect.com.
Vince
On 22/08/2023 17:08, John Grillot wrote:
Hi, It's good to know I have a fellow programmer in the COBOL & business software field on discord.
I shared several files for you here
https://u.pcloud.link/publink/show?code=kZHCwaVZgNCTLxesVTftFpcyKoD4IfObkKwX
Oe.tar is all the work I did to get the source code from the IMD files found in the archive into a format the TRS XENIX cobol compiler needs. For example, removing the / from file names. Since the original compiled program file names distributed for this system are lower case, I changed the source file names to lower case too. I'm not sure if this is necessary. I just did that because it made since to me. I had to change the source code to refer to the program & data file names to lower case. I also edited the code to change the data file names.to remove the ":3" and ":2" and ":1" from the data files opened. There were some other changes I made to get the code to compile. There are too numerous for me to explain now. I also uploaded the IMDs of the source code from the archive that are in the TRSDOS format. And the documentation for the order entry system.
So might begin your testing with the source in Oe.tar. You may also decide the changes I made were not necessary and you can start from scratch using the IMD files. I used notepad++ compare add on for inspecting changes I needed to add. You can use this to find the changes I made.
I hope you find a way to get this to run on Linux. Please keep me updated on your progress.
Last edit: Simon Sobisch 2023-08-24
Which many errors did you have and how did you fix those?
On 24/08/2023 18:17, Simon Sobisch wrote:
He is using progs that used RS Cobol a rm cobol v4 that used the TRSDOS O/S.
It was like all of the kit then very short on Ram so heavy usage of segmentation and lots & lots of calls to progs to continue one or more steps of processing.
Had similar for MF Workbench - no not as bad but it was a very long time ago.
RS / RM uses special coding for screen, printer and file exception processing. The last is just a case of replacing terms etc.
The other two some what more but I am still looking through the code - assuming it is complete.
A lot of the issues is just a case of changing dialects and coding to cope with *nix and windoz etc and not using floppies.
Yes, coded around 1981 for a Tandy - enough said :)
Last edit: Simon Sobisch 2023-08-25
the errors are listed on my first post of this thread. I haven't solved most yet. 2 days ago, you offered suggestions in a previous reply to my request for help. the ERASE SCREEN worked. I tried the CONTROL KEY issue suggestions Writing my own CHECK-FOR-FUNCTION-KEY-ENTERED is beyond my skills.
On 24/08/2023 18:58, John Grillot wrote:
Found the RS-Cobol v4 manual (based on RM Cobol v4) along with some
others for TRS80 all in the same .pdf file.
You can get it at :
http://www.applewood.linkpc.net/files/RS-Cobol
I will use that location to include my updated source files.
At the moment I have gone through all of the fd, sl, ws pl etc files
then move them to folder copybook
Next went through all the .cbl files and changed :
All program names to lower case including calls.
Removed the noise word IS from most but not for the programs.
Removed bad or noise words for the DISPLAY and ACCEPT such as TAB,
CONVERT, No BEEP, etc.
Next to work out what needs to be compiled and see what happens
Needless to say print* screen will need a lot more work but want to see
what goes through GC first using default settings then -std=rm
Wow thanks for the contributions.
Last edit: Simon Sobisch 2023-08-25
That RS-Cobol manual is for the model 4. I have been doing my testing on the model 16 which can run XENIX and TRSDOS. There may be differences in that COBOL.versus the xenix.
Last edit: Simon Sobisch 2023-08-25
Noted but it was the only one I found.
Problem area : acctfile.ds hold 15Mb of source file from multiple sources files?
Needless to say it is bot a DECLAREATIVES.
I have renamed the original file to totalsrc.cbl and created this file
acctfile.ds as :
Hopefully it is correct :)
I have had to make other changes when I get errors compiling the .cbl programs as
cobc -m $i -T $i.prnetcSo getting a lot of errors mostly of errors in the code base
One very interesting error I get is where there is a data name that is the SAME as a procedure paragraph name the compiler is complaining of a redefinition issue. I.e.,
Now I would have thought that the compiler should distinguish between the two and should NOT be objecting.
@Simon ?
I cannot see a way of telling the compiler to deal with it :)
Before I forget please provide me your email address ... It will speed up comms between us.
Plus I do not think every one is interested in this topic - at least for now.
Vince
Last edit: Simon Sobisch 2023-08-25
Those "source data set files", which are "combined" can be extracted with a plain use of command line tools, can't they? How is the encoding of file names / separation done in those data sets?
Does the "old" code use
copy cobybook-name in data-set-name?How are the "main sources" stored?
Sight, which ones? Did you also have those with
-std=rm-strict(can you recheck)?That's not a mailing list and the few people that subscribe to the whole discussion board likely are interested. It is definitely interesting to have a peek at a "migration project", even if that is done mostly out of fun/interest.
For me personally, it is important and useful to see where issues are, also to improve GnuCOBOL's "easy use for migrations".
After all it can also be useful to include appendices to the programmer's guide "migrate from xyz" (we could have a general chapter in the main document and an appendix for each (set of) environments, that give insights about "map compiler options", "map io status", "things that need a rewrite", ...
Yes, that is an old regression in GnuCOBOL, tracked in [feature-requests:#260]. If I have that right, then standard COBOL never allowed procedure-names to overlap with data-names (but other overlaps are OK), but most compilers do support this overlap.
There's also a "too much" change that covers that in https://github.com/OCamlPro/gnucobol/pull/31 which should be trimmed down to the procedure-names overlapping data-names; at least if my understanding is right. ... I'll ask the COBOL-committee and report back in that FR.
Related
Wish List: #260
On 25/08/2023 07:45, Simon Sobisch wrote:
--- cut ---
Well, there is some code missing due to the way the old source are stored for TRS80 that was the work that John carried out and I will not know if there is any more until some testing of the application starts.
copybooks are used including within the procedure div and all such copybooks are in a folder with
COBCPYset for this work.I have been using the default settings but could try and use
-std=rmand see what happens on a full recompileFor the moment all compiles are using -m until I work out what are the main programs and against called modules.
Possibly but remember I am migrating a 1980 codebase used with RM Cobol v4 or there about as issued to Tandy for TRS80.
There is a lot of code that uses the same name as in a variable in WS and as a paragraph name and the usage matches ie., a test for a 88 DISPLAY-FIELD for true then a PERFORM DISPLAY-FIELD. There is a lot of these and these dups are not getting packed up in the same run of the compiler (3.2 final)
RM COBOL is happy with this - I assume as I do not have the compiler :), - the doc for this application is detailed for a 1980s document and includes very basic program specs but omits details about compiling options so a bit of guess work really but this phase is just getting the code base through the compiler error and warning free.
Would be useful to turn this problem off using a compiler switch - it could join the many others.
Related
Wish List: #260
Last edit: Simon Sobisch 2023-10-24
While a global change is often useful the question for migrations is: what is actually needed.
That's just a style issue, no?
If all are upper-case then it should work a is, if not, then
-ffold-call=lowershould work, no?That's another style-only issue, no?
cobcshould have no problem with its use - if it has then this definitely needs a patch (which in 98% of the cases would be very simple), but as far as I know it just supports that everywhere other compilers do.Again - cobc should support that and we would need issues created if its parser stumbles over any of these. Note that the mentioned ones also seem "functional", not "noise".
All that said with - should be compiled with
-std=rm-strict.On 25/08/2023 06:15, Simon Sobisch wrote:
Compiler did not like
TAB,CONVERTandNO BEEPnot so sure about thelast one.
More importantly, the compiler does not know the difference between variable and paragraph name being the same and that is causing a lot of issues.
In addition when I fix one reported issue regarding these reused names and recompile it finds yet another which I look for using the -T option.
How ever I gave up at 02:20 this morning so will take another look but did not get much sleep so will be working in zombie mode.
Last edit: Simon Sobisch 2023-10-24
Hi @vcoen!
Any update on this project?
Can you provide some specific test programs that don't compile with
std=rm-strict(with the variable-named-as-procedure issue fixed)? This would help improving the parser and/or the compiler dialect configuration.I am using the default config.
While it "might" work better if RM used as it still uses the standard
method capturing numeric data from screen it will not improve matters as
that is the biggest issue to date when using the module screen.cbl
At the moment I am trying to work out a way of still using it but use
A/N field to capture and display numbers with minimum changes to the
application itself - i.e., no coding changes other than to screen.
All programs that require screen i/o call this module that uses field:
SCREEN-NUMERIC-FIELD PIC S9(12)V9(3). *> 16 = 190 SHOULD
sign be removed ?
for capture and data transfer between the caller and the called
(screen.cbl) so considering changing that to (may be) :
05 Screen-Numeric-Field pic -(11)9v999
with a field above it say called 03 Screen-Numeric-Field-x.
And using that for accept and again for display by using numval SNF-X
(Screen-Numeric-Field-x) to temp-field -(11)9.999 field then move to SNF
for the caller to process. Just have to work out what to do the
opposite way when displaying the field as there is not a opposite
function to numval.
The only other options are related to changing every program that need
numeric processing and use numval and then fiddle to process the other
direction. - A very large pain and time waster and I am getting to the
age when I cannot afford it.
I appreciate the above might not be very clear and can provide the code
base of the OE system or just screen.cbl the total codebase is 2 Mb
which includes the system specifications manual as a pdf although there
has been a "few" change made.
On 24/10/2023 13:00, Simon Sobisch wrote:
Got it all now.
OK, just done a quick scan and edit to all copy book items files end with ds, sl, fd, pl, ws and the area that I changed and more is needed is :
All file .sl entries needed changing to lower case and the file extensions to .dat.
Most if not all date handling routines need to be made millennium compliant, i.e., date format changed to :
CCYYMMDD instead of YYMMDD and likewise the reverse MMDDCYY from MMDDYY and allowance for users outside the USA for formats DDMMCCYY and CCYYMMDD (standard *nix format) and this will
involve a lot of data areas to be changed AND some processing but most is called or performed so less of a problem.
Also the get the date processes need to convert to using *nix format dates and storing of them possibly.
File handling will rear its head as status codes have to be changed and the gc copybook use different var names - no surprise there.
Printer processing and file layouts will need to be changed - I may see more when looking at the progs.
Screen, a lot of changes will be needed here.
Next is to look at the .cbl files and no doubt similar issues.
Jezz, who ever did this work for the original business sure make work hard for themselves but I might change my mind on that once I look through the programs.
I want to look at the manual - pity it is not as a text file but a PDF as it is not easy to read as is but shows it is from the 70's.
Be interesting to see if they have including programming specs for all progs which will be useful.
More later.
Vince
Last edit: Simon Sobisch 2023-08-25
This is indeed the
CONTROL KEYextension:If the accept is exited with any key but Return/Enter it moves the function key value (in case of ACUCOBOL-GT this can be externally remapped an also be remapped from COBOL, not sure how this is with RM/COBOL) to the numeric identifier, in this case
FUNCTION-KEY-PRESSED.GnuCOBOL can parse that, but it doesn't make any sense to directly map it as the control-key values differ. It is a bit like io status values which may be different, but much more..
Note that this is a warning which this "I'll ignore that". To not only let that compile but "work" you'd have to drop that and rewrite
CHECK-FOR-FUNCTION-KEY-ENTEREDto test the crt-status for the GnuCOBOL values (distributed incopy screenio.). The Programmer's Guide should have a note about how you can do this.The root of the compile error is quite clear, especially when using GC 3.2, which often removes the need to send the complete source, too :-) :
The first
DISPLAYstatement is not ended because the cobc version you use expectsERASE LINEorERASE SCREEN... so the easiest way to fix that is just replaceERASEBYERASE SCREEN.This is very helpful. Thanks for digging into this and providing work a work-around.
Last edit: Simon Sobisch 2023-08-24
I know the packages you have all too well. Back in the day I purchased the source code for all of them: AP, AR, GL, etc. And screen.cbl came in very handy creating my own applications. Also looking to modify some code in those oldies for GNUCobol and having your same issues. Is there a way for us to connect outside of this group?
Oh that's great news. I'd love to hear your stories from back in the day. Here is my email jgrillot@att.net
Woul dbe interested in looking at those and even more if you have the manuals for them all.
You can grab my OE sources by going to :
http://www.applewood.linkpc.net/files/acas/nightlybuilds/
Where you will find OE and also the ACAS sources.
These builds occur every night at 00:00 UK time (GMT+1) and archive my current version of the sources but that will include any bugs as well.
I have currently stopped working on OE as they only difference in it against Invoicing within Sales Ledger is salesman and their commission, Back Orders etc, has now been included in Invoicing as well as a similar pair of reports of the new file bostkitm as well as the ability of amend, create and delete such records.
I will be looking at adding in the ability of the invoice program also to take the bostkitm file and use it to create such invoices for newly arrived stock as updated by the Stock Additions program (which now updates bostkim file with quantity added and date),
For direct comms use vbcoen@gmail.com
Vincent
Last edit: Vincent (Bryan) Coen 2024-04-03
Vincent,
Is the source open source? I am interested in collecting as much COBOL
code that actually works as I can find.
On Tue, Apr 2, 2024 at 8:28 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote: