Activity for David Wall
-
David Wall posted a comment on ticket #195
Fine with me.
-
And ?? - 2 months later ?? - to be honest I've taken all my Cobol stuff OFF my pc onto a usb stick and lodged it in a cupboard - got tired of waiting.
-
What are you using to build the compiler with - Mingw needs to have GMP installed before building the compiler.
-
Forget 4.0 - when's 3.2 getting released - is more the burning question ?? Unless VISAM has had some major updates then it don't work - at least on Windows.
-
What 'package' did you download - you can download the whole kit/kaboodle from : https://www.arnoldtrembley.com/GnuCOBOL.htm see : GnuCOBOL Compiler install binaries - for with BDB / with VBIsam or without both. NO BUILDING REQUIRED> Unless you're trying to 'build' it from scratch - in which case - using what ????
-
What 'package' did you download - you can download the whole kit/kaboodle from : https://www.arnoldtrembley.com/GnuCOBOL.htm see : GnuCOBOL Compiler install binaries - for with BDB / with VBIsam or without both. Unless you're trying to 'build' it from scratch - in which case - using what ????
-
And 32-bit GnuCOBOL versions run well on 64-bit Windows. Not out of the box as if user wishes to run 32 bit on a x64 you have to install all the supporting packages to do so. The extra packages to do this will increase disk usage to store them and more CPU cycles to run any thing using them. What 'extra' packages do I have to install - since it seems to be working fine on my Win10 64bit system ?????????. I have a number of 32bit programs running fine - most of the commercial programs have both versions...
-
The build guide for Mingw 3.1.2 has both BDB & VBI instructions - I believe however that the Mingw64 guide only uses a file created by Simon S which only contains BDB. I build the Mingw version 3.1.2, 3.2 & 4.0x quite happily under Windows 10 64bit and I believe they are all 32 bit so what advantage having a 64bit version is - I don't know. IF you want to try one of those let me know - send an email to my SF address & I can send you one of those via dropbox. I don't run linux so I don't know if a...
-
3.2 hasn't been released yet but you can download a version of 3.1.2 with vbisam from the following: https://www.arnoldtrembley.com/GC312-VBI-rename-7z-to-exe.7z Perhaps you could explain what the actual difficulties have been for you - error messages etc: and I'm sure someone will have already been thru a similar situation.
-
Thank you Simon - Numbering with test name works fine - the only tests that didn't work (except those expected to fail) were: 17 Auto - still can't get the 2nd box to allow me to enter the 3rd box - pressing enter at the end of box 2 just exits the test. 23 Blink - (running on PC so actually expected) 27 Full & Required - Unable to enter the Y as it wouldn't exit the box - had to ctl/brk. 38 Underline - Running on PC again so expected ??. 46 Alt RT Arrow - moving right to end of field exited the...
-
The test topic and the number should be visible in the "original" test window, isn't that enough? I agree that it's in the 'original' running window - but that doesn't relate to the cmd window - you have to alt tab between them to see the topic & number. Maybe it's not necessary - but trying to understand what the test is actually trying to achieve would be nice. Which is the build folder - gnu or gnu/tests ??? I've tried 'as I've said' doing a cd msys/gnu/tests followed by a make checkmanual - as...
-
The usage of the tests is somewhat strange - as follows: You're asked to enter a y if the test displays what it says - however the majority of tests already display a Y in some position on the screen (although that isn't necessarily where the cursor end up). In addition - there is at least 1 test where you enter 5 characters and it jumps to another accept line where you enter another 5 characters and then press enter - it just exited the test at that point. IF you don't enter a y then I think it's...
-
I've moved this conversation to its own topic. The other one is complete. Simon said: So you've took the manual steps that where opened in a new cmd window, and found all good so answered with "Y" - correct? Did you recognize anything "new" to you related to GnuCOBOL screenio or things that seemed "special" with the new PDCursesMod? Can you picture more tests that may should be added for checkmanual? I've only run it the once with somewhat confused results against 3.2dev. Unpacked the source files...
-
Edited the atlocal.in file prior to running the configure and it all went thru - built my output folder fine. Ran it against 4.0 as opposed to 3.2 and failed 50 tests and skipped 1. See attached .log I'm off to bed as it's 1.30am here in OZ.
-
Edited the atlocal.in file prior to running the configure and it all went thru - built my output folder fine. Ran it against 4.0 as opposed to 3.2 and failed 50 tests and skipped 1. See attached .log
-
Edited the atlocal file prior to running the configure and it all went thru - built my output folder fine. Ran it against 4.0 as opposed to 3.2 and failed 50 tests and skipped 1. See attached .log
-
Well - edited my build script to add make checkmanual in after the build & install. see results attached - all 50 tests skipped ??. This was for the latest 3.2 dev downloaded yesterday.
-
Well - edited my build script to add make checkmanual in after the build & install. see results attached - all 50 tests skipped ??.
-
Although the file does exist in E:\MINGW\libx\gcc\mingw32\9.2.0\include ??.
-
Didn't get very far - stddef.h file not found - see attached log.
-
Maybe it's just me - I do a resetty to change the screen size and that can happen quite quickly - so maybe i'm imagining it. I sent a copy of my prog to AT - since he's the only one I know who would have PDC432 at hand. I've asked him to see if he thinks there's a problem or not. Still hoping to have a play with make checkmanual Am having keyboard problems at the moment - my PS/2 k/b is doing strange things in upper case so I've had to resort to a usb k/b - which I don't like.
-
I haven't done that yet - didn't know it existed to be honest. Will have a play today.
-
OK - I had 1 last try & as you say above - removed the reference to initscr_xZZ where ZZ was either 32 or 64 depending on which one I wanted to use in the Cob Build. Doing it the other way - by editing a pdcurses.h is a rather strange (in my opinion) way of doing the same thing - except that in your case it has to be edited EACH time you get a new PDC - whereas doing the CHTYPE & DPDC_DLL stuff on the Cobc Configure - no change has to be made to the PDC at all. Horses for Courses I suppose. Anyway...
-
Simon - Since I'm originally from the UK - I 'understand' the words - BUT the context once again goes right over my head. I've NO idea what a 'wrapper' is or "real" headers. I've always built PDCurses with the following configure lines: make -f Makefile INFOEX=N CHTYPE_32=Y DLL=Y and the compiler with the following: ./configure "CPPFLAGS=-DCHTYPE_32 -DPDC_DLL_BUILD -Dinitscr=initscr_x32" --prefix=/mingw --with-vbisam --disable-rpath at least from pdc3.8 onwards. I just noticed that the cobc -info...
-
Actually - removing the savetty & resetty made no difference - other than the program no longer crashes with the Assert fail. I get NO display whatsoever whereas it works fine under PDC 4.3 1. Ah well - shouldn't have bothered
-
One of my standard test programs is a screen display of all the colours - with the ability to resize the screen using savetty & resetty. Recently was advised of a later release of PDCurses 4.3.2a so decided to have a play. Built pdc432 & then rebuilt 3.2dev. Got a - Assertion failed: SP, file ../pdcurses/kernel.c, line 209 when test program run. line 209 & surrounding lines say: int savetty(void) { PDC_LOG(("savetty() - called\n")); assert( SP); ---- line 209 if (!SP) return ERR; _save_mode(PDC_SAVE_TTY);...
-
Already fixed.
-
Something wrong with the configure - every ten lines or so it's 'compilation terminated'. No wonder the make fails.
-
admittedly it's a comparison of a mingw build of 3.2 with a whatever yours is: but the difference (major that is ) starts about here: see attached comparison of my build log with yours. Don't know if it helps. - haven't kept a log of a 3.1 build for yonks.
-
With respect Brian - What 'griefs' are there in building from sources ??. I've built from source for the last 4 years using Mingw using originally the Guide put out by Arnold T & more recently setting up my own scripts to automate it. I 'did' have a gander at the winlibs site but was more confused than ever I have been. Also - I didn't see GnuCOBOL mentioned once on their website. ???
-
I used Numval in a test but got some strange result moving one field to another. 1 MOVE '987654321.123456789' TO X FIELD >987654321.123456789 2 MOVE NUMVAL(XFIELD) TO ANOTHER X FIELD >00987654321123456789 3 MOVE NUMVAL XFIELD TO S9(9)V9(9) FIELD >987654321123456789 4 MOVE NUMVAL XFIELD TO 9(9).9(9) FIELD >987654321.123456789 Why the extra 2 x 0's on the output field line 2. ?? Sample prog attached.
-
I used Numval in a test but got some strange result moving one field to another. 1 MOVE '987654321.123456789' TO X FIELD >987654321.123456789 2 MOVE NUMVAL(XFIELD) TO ANOTHER X FIELD >00987654321123456789 3 MOVE NUMVAL XFIELD TO S9(9)V9(9) FIELD >987654321123456789 4 MOVE NUMVAL XFIELD TO 9(9).9(9) FIELD >987654321.123456789 Why the extra 2 x 0's on the output field line 2. ?? Sample prog attached.
-
Just seems illogical ??.
-
It's NOT per record - it's just the default block size - depending on how many records you have the size taken is a multiple of 4096 bytes. With 201 if you have 2 records of 80 bytes then the .dat file is 160 chars. IF you have 52 records of 80 chars then the file is 4160 bytes. With 211 if you have 2 records of 80 bytes then the .dat file is 4096 bytes. IF you have 52 records of 80 chars then the file is 8192 bytes. I try not to use BDB because the index is scrambled in with the data.
-
ALSO - This discussion way back in Dec last year: https://sourceforge.net/p/gnucobol/bugs/791/#4b16/9b77
-
Maybe you could go thru this discussion - because from memory I couldn't get VISAM to work: So I reverted back to 211. https://sourceforge.net/p/gnucobol/discussion/cobol/thread/584b210bde/?limit=25#23fc Ron doesn't do any testing in Windows - so I guess it's NOT his problem - IS IT ??.
-
here's the files in question. File named with 201 - size 352 bytes - 2 records key 6 bytes (1-6). File named with 211 - size 4096 bytes- 2 records key 6 bytes (1-6). The .idx file is identical in both cases - 12288 bytes - 3x4096 ??? I would say it's wasted space - but then I'm not a programmer am I Vince ??
-
OK - Now the line 9 & 17 errors have gone but I still can't move an implied decimal point to an alphabetic field - lines 14 & 16 still occur. I know that error is the whole reason I'm moving the V field to the . field but it would still be nice if it could be done. AND - I still believe the Manual should indicate that . cannot follow an S. Thanks Simon.
-
Thanks Simon - I'll give that a go & see how we travel.
-
Vince - whilst I appreciate the above - it's actually NOT what I'm kinda complaining about. My only reason for using VBI over BDB is BECAUSE the VBI .DAT files are so easily read and displayed by mere text editors (because their index is a separate file). Compared to the somewhat mish mash of BDB where their index is mangled up with the data. However - VBI 201 seemed to only write the actual data to the .DAT file (NO extra padding) whereas VBI211 now writes the .DAT file out in either 1024 (32bit)...
-
I don't understand what you are getting at Vince. I moved a field described as 9(9)V9(9) to an edited field described as 9(9).9(9) with no error. BUT I moved a field described as S9(9)v9(9) to an edited field described as S9(9).9(9) with error. The error given was that the receiving field was described with a . that followed an S What I'm saying is that the Manual does NOT say having a. AFTER an S is illegal whereas the compiler giving an error seems to indicate that it IS an error. I thought my...
-
And there appears to be nothing in the Programmers Guide saying it's illegal to have a . in a Signed field and move Signed data with implied decimal place into it.
-
I'm desperately trying to get to be able to display comp fields in their normal format but have come across a problem. I can move a numeric field : 9(9)v9(9) to an edited field 9(9).9(9) without problem. But I get ' invalid source for move . cannot follow S ' when I try S9(9)v9(9) to S9(9).9(9) but moving it to 9(9).9(9) is ok. Could someone please explain ??. TIA The end result I want is to get the original field S9... or 9... into an x(20) field but I get the error invalid source for move IF I...
-
Recently had the need to compare Isam files and found immense difficulty in comparing the files created by VBI211 & those of it's predecessor 201. 201 created files .dat & .idx with the .dat file having a size of the actual data recorded. 211 creates .dat files (on my 64bit pc) with a minimum size of 4096 irrespective of the data and padded out with nul 00's. which is a distinct PITA. @sf-mensch - when you get round to making changes to VBI can you please pad the blocks out with space & not nul.
-
Inspect Tallying - incorrect error mssg
-
No Ralph, I was just commenting on the number of bytes the Xref indicated were used for each field. I'm now 73 and am please to say I've 'NEVER' used a floating point number - and I ain't about to start now :) OK - I'll ignore the comp-1 & comp-2 displays - but that doesn't cover what still appear to be errors in the comp, comp-4, comp-5, comp-n & comp-x type fields. And we haven't gone into decimal places yet.
-
Recently - trying to understand how comp fields get stored I knocked up scratch program that had variable sized fields from 9 to 9(9) described using all the variations of comp. Passing the file thru the Xref I believe I've found an error in how the field sizes are calculated: Please refer to the attached file - xx which is an extract from the Xref output of Cobc with reference to Numeric Field descriptions. C5 thru C9s are all indicated as having a size of 4 which seems wrong to me. C11 thru C19s...
-
Recently - trying to understand how comp fields get stored I knocked up scratch program that had variable sized fields from 9 to 9(9) described using all the variations of comp. Passing the file thru the Xref I believe I've found an error in how the field sizes are calculated: Please refer to the attached file - xx which is an extract from the Xref output of Cobc with reference to Numeric Field descriptions. C5 thru C9s are all indicated as having a size of 4 which seems wrong to me. C11 thru C19s...
-
Recently - trying to understand how comp fields get stored I knocked up scratch program that had variable sized fields from 9 to 9(9) described using all the variations of comp. Passing the file thru the Xref I believe I've found an error in how the field sizes are calculated: Please refer to the attached file - xx which is an extract from the Xref output of Cobc with reference to Numeric Field descriptions. C5 thru C9s are all indicated as having a size of 4 which seems wrong to me. C11 thru C19s...
-
Yes Eugenio, it's just that I thought that since the compiler knows how long the field being accepted is - then IF it was a single char in size then the backspace, left, right, home & end insert & delete keys are irrelevant & could be passed thru.
-
Never tried it - wouldn't know how.
-
Certainly the 'getch' routine that Carl Goldin gave me gives me all the normal, shift, Ctl & Alt centrepad keys as well as the same for the normal characterset.
-
Brian, Kicking the can has a somewhat different meaning in the UK :)
-
Would it be possible to extend the keys passed to a cobol program. We can actually get access to a Ctrl Left Mouse key or a Alt Right Dbl click which do seem somewhat esoteric - considering we don't get access to a Shifted left key or a Ctrl right key or a Alt key up. These are equally valid keys. Similarly would it be possible to get access to the same keys tested for in accept omitted - IF the accept field was only 1 character in size. Home/End/Insert/Delete/Backspace would have no meaning in such...
-
3.8 is Feb 2019 - why not look for PDCursesMod - the latest is Nov 2021. https://github.com/Bill-Gray/PDCursesMod In fact it was updated 2 days ago.
-
3.8 is Feb 2019 - why not look for PDCursesMod - the latest is Nov 2021. https://github.com/Bill-Gray/PDCursesMod
-
@sf-mensch & @vcoen It's easier to forget GnuCOBOL 3.2 completely & run it under 3.1 where at least it runs to completion and appears to do the right thing (at least on my source files). If and when 3.2 gets released to the wild then I expect this will be revisited by one or other of you.
-
The version in trunk tools shows the following: changeformat-f.cbl 2021-02-20 vcoen [r932] Added source for fixed format version as change... It's got your name against Vince it as opposed to the one following it: changeformat.cbl 2019-09-12 sf-mensch [r769] tool changeformat: fixed compiler warning ... which has Simons name. I picked the latest dated version with I presume the latest r number. It was compiled with -d & -ftraceall Regarding the skip whatever code is done in 549 - I tried that but...
-
Well I just ran it again with both the file you sent me and the original I uploaded & it crashed again on both. What's the size of the .cbl source of changeformat ?? - I have 53,822. By the way - I'm compiling using 3.2 - I'll try with 3.1. That's the problem - it works with 3.1 but not with 3.2 - out of bounds every time. Crashes at line 549 - see my original comments on the contributions board.
-
Well I just ran it again with both the file you sent me and the original I uploaded & it crashed again on both. What's the size of the .cbl source of changeformat ?? - I have 53,822. By the way - I'm compiling using 3.2 - I'll try with 3.1. That's the problem - it works with 3.1 but not with 3.2 - out of bounds every time.
-
changeformat
-
@sf-mensch - you've got me lost 'again'. Where do I need to 'format' what would appear to me to be a reasonably well constructed sentence - ok I didn't put a blank line between what I typed & the program output. OK - I edited my entry. On a second note: I 'looked' at cbl-gdb and noted that it would appear to be a text based debugger - In so much that you have to do some considerable entering of commands to produce the output - I'd rather use what I've developed over the last few years where the output...
-
@sf-mensch - you've got me lost 'again'. Where do I need to 'format' what would appear to me to be a reasonably well constructed sentence - ok I didn't put a blank line between what I typed & the program output. OK - I edited my entry. On a second note: I 'looked' at cbl-gdb and noted that it would appear to be a text based debugger - In so much that you have to do some considerable entering of commands to produce the output - I'd rather use what I've developed over the last few years where the output...
-
I realise that sounds a bit rough - but most programs I've tested it against - it crashes with the following display. libcob: changeformat.cob:549: error: subscript of 'WORD-TYPE' out of bounds: 0 libcob: changeformat.cob:549: warning: implicit CLOSE of INPUT-FILE ('desimake.COB') libcob: changeformat.cob:549: warning: implicit CLOSE of OUTPUT-FILE ('desimake.FIX') Last statement of "changeformat" was at line 549 of changeformat.cob Started by changeformat desimake.COB desimake.FIX TOFIXED The 'only'...
-
I realise that sounds a bit rough - but I generally code in FF nowadays & was deciding to give Ralph L's Winanim a try - to see how it runs. His program requires fixed format so - run changeformat & convert my code to FF. crash. Every program - 5 so far - I've thrown at it crashes in the same place: libcob: changeformat.cob:549: error: subscript of 'WORD-TYPE' out of bounds: 0 libcob: changeformat.cob:549: warning: implicit CLOSE of INPUT-FILE ('desimake.COB') libcob: changeformat.cob:549: warning:...
-
For several 'years' now - certainly since 2017 I've been investigating how to incorporate some sort of low value timeout on accept statements. I 'sort of' gave up my own ventures back in 2018 and was ably assisted by 'cdg' Carl Goldin - who has since appeared to have left the GnuCOBOL 'theatre' of war. He gave me a .c routine that simply read the keyboard and passed the results to my Cobol programs along with a .cpy module for the return-codes generated by the 'getch' routine he used. I needed another...
-
VBIsam Opening Shared between program not working.
-
@sf-mensch - Is there any resolve to this - 18 months later ???
-
I've been playing with one of my programs and added a 'beep' to a display statement. To my horror - instead of getting a simple 'beep' and the next statement is actioned, I get what sounds like an hour chime from Big Ben and lasts almost as long. My runtime.cfg has the line 'bell beep' in it but the output from my computer speakers is as I described - more of a bonnnnggg and lasts approx 1 second or more. The code line in question is very simple. DISPLAY DATKEY LINE 1 COL 10 BEEP. When I build the...
-
I've recompiled with --debug & get the error - see attached - many thanks.
-
Silly bar-steward I am - I put LS and not LF - of course it works - thanks.
-
What I was meaning was - where do I put it ?? I tried doing a set in my batch file but the LS file output still had 0D0A ??
-
Where exactly is this mentioned - not in the 3.2 guide - is it specific to 4.x ??.
-
I don't know whether to say 'thanks' or 'no thanks' - I may give it a try sometime shortly.
-
Yes - it's a 'based' field.
-
It's code i've inherited & don't quite understand the ramifications of it - basically there is a x(100) field which is 'based' (whatever that means). - I can't change that - it caused further complaints. This field is then partially displayed ie: field(1:5) which appears to be causing the problem when it is null. This didn't happen in 3.1 only in 3.2 or 4.x. I've sorta coded round it (again). Probably this can be bit bucketed as can most of my problems. :)
-
I think I've got it - the field I'm displaying when it crashes is sometimes nul ie: hex 00 hex 00 and whilst 3.1 & pdc 3.9 & 420 seem to accept it - 3.2 & pdc430 & 431 obviously do not.
-
I just can't see where anything I'm doing is causing this - same source code - same compile batch file - all I do is point my batch to the relevant compiler & press enter - the program runs perfectly well 90% of the time but when I select this particular option it crashes part way thru. I'll see if I can narrow it down to a particular place.
-
I also downloaded Arnold T's 3.1 with vbisam & pdc420 & it worked fine. ???
-
I started using a slightly different area of my major test program - which doesn't do anything unusual. It crashed with the following error: Assertion failed: str, file ../pdcurses/addstr.c, line 74 This was using the absolute latest 3.2 together with the latest pdc431 built this morning. I tried again with same result. I rebuilt pdc 430 & the latest 3.2 and got the same error. I then went back to an older compiler version 3.1 built back in early 2020 which used pdc 3.9 and of course this worked...
-
Thanks Vincent - you'd think it 'might' have been mentioned in passing on page 320 where READY TRACE is - however finding it on page 583 is just as good. Much app - I've been doing the redirection to filename.
-
I tried a redirection & that appeared to work for a straight .exe - now to try a .dll.
-
I don't believe they backported the changes Ron N was working on. In fact it may only have been to 4.x - refer: https://sourceforge.net/p/gnucobol/discussion/cobol/thread/584b210bde/?page=1&limit=25#8044 Not sure now..
-
Actually - it's just so slow that it eventually did do what I was expecting - when I finished the program the last part of the trace appeared on the screen - How do I capture all of it - maybe a redirection or cobc option ??.
-
Having compiled a program with READY TRACE. & compiled with -ftraceall - where does the output go & can I redirect it to a file of my choice. ?? I see part of the output on the screen but that then disappeared & didn't come back.
-
@sf-mensch - apologies - for some reason I never received this as an email so missed it. Yes - the latest version of 3.2 fixes up the odd extra External references. Thank you.
-
I found a bit of C code on the net & added it to a C routine I use for keystroke/mouse input.
-
Vincent - I thought this extra 0D only occurred in 3.2 or 4.x ?? & was fixed recently by Ron N. see: https://sourceforge.net/p/gnucobol/discussion/cobol/thread/584b210bde/?limit=25&page=2#a06f I must admit having to compare files produced under MIngw with those under Windows caused me some hassle till I started running a sfk (swiss file knife) against them to completely remove all 0D & 0A from both files - leaves a single long record occasionally but can actually be compared & match.
-
Again with reference to my convo with Vincent re cobxref - it would appear the problem is with some subroutine in his program - sorry for the 'jolt'. It seemed so strange that I could write LS files without the extra 0D whereas his prog added it. Back to all quiet..
-
@sf-mensch - this fix seems to have reverted ? somehow - see my conversation with Vincent regarding the cobxref - his program now produces 2 files a .lst & a .pro - the .lst is single spaced - 0D0A at end record - whereas the .pro is double spaced - 0D0D0A at end of record. Both files are described the same ????? - tried this with your latest : Built Dec 15 2021 03:45:46 Packaged Dec 14 2021 13:43:46 UTC C version (MinGW) "9.2.0"
-
By the way Vincent - is it your program that does the extra line skip on the .pro file - I'm getting a 0D0D0A on the end of each line of that but not on the .lst file. Strange because they're all described as line sequential. Maybe another bug in 3.2 ??. - I'll try again with the latest (this one was Dec 03 2021.) Ok - tried with the absolute latest 3.2 - just built from Simons update - above. E:\COBV32\bin>cobxref cobolpr1.cob libcob: cobxref.cob:3966: error: offset of 'SourceFileName' out of bounds:...
-
I retried it - with and without a copy module statement. Crashed with the statement & went thru albeit with some displays when I removed the copy statement. If you're wondering what copy statement could possibly crash it - screenio.cpy - default with GnuCOBOL 3.2. With the copy statement it crashes. E:\COB32\bin>cobxref cobolpr1.cob libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2 note: current maximum subscript for 'CRT-Instance': 1 libcob: cobxref.cob:5993: warning:...
-
You're right - the demomath program ran fine after I changed the 128 to 64 - I reran it 'using my batch file' and it ran fine. The batch file sets the parameters for running cobol exe from a dos prompt in my system - it works for my programs. Your program did run but crashed - (when trying on the two larger programs) - that's different from saying it couldn't find a .dll which is what happens if I run it at a dos prompt without the batch file. I agree that the demomath didn't have any external used...
-
Simon - I love it when you talk dirty to me - even if it's about 1km above my head :)
-
@sf-mensch - attached source code & xref listing together with MIN (minimal display). Sorry - it's hardly a small program but it's reproducible - I think it's overflowing something since I tried with another large program that produced similar results but as I reduced the PD code the problem disappeared ????. Please ignore the code - it was a program I wrote for my wife to store her crossstitch collection - some years ago. (my coding still has not improved.)
-
As I said above: I tried creating a sample program using that same copy module but it refused to produce any reference to an 'external' data item - even though they all were such. I then thought it was to do with the fields being referenced in the actual program - but they are 'all' referenced at some time or other. Just strange I'll keep playing & see if I can get it to reproduce 'other' than with my somewhat large program.
-
Tried it with a fixed format file - somewhat similar results. - in fact identical. ??? libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2 note: current maximum subscript for 'CRT-Instance': 1 libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('COBOLSEQ.pro') Last statement of "printcbl" was at line 5993 of cobxref.cob Last statement of "cobxref" was at line 4131 of cobxref.cob Started by cobxref COBOLSEQ.cob Press any key to continue . . . Again crashed at...
1 >