May the Lord comfort you in your loss.
I looked in what I think is the latest user guide, but TEST-FORMATTED-DATE isn't described. There is a reference to TEST-FORMATTED-DATETIME, but no description on how to use it. https://open-cobol.sourceforge.io/guides/GnuCOBOL%202.2%20NOV2017%20Programmers%20Guide%20(A4).pdf If we should be encouraged to use it, then I should open a ticket to have it added to the manual. Also, the tp.cob program shows this. $--,---.-- <== PIC $ $ 12.34 $ $-12.34 The currency sign is floating, even though it is only...
Ok I'll wait for a fix. Not a big rush for me.
Does that mean one has to test for numeric before testing with test-date-yyyymmdd? I would think test-date-yyyymmdd would do all of that, and correctly return 1 if not numeric. If numeric test is needed first, then the manual needs to be beefed up a bit.
Running tests on trunk. Only a few minor issues. Otherwise, it's looking good. The test-date-yyyymmdd is returning ok even when the day is blank. Then locale-date returns some bogus date. The pic is treating the $ like a floating, even when it only takes one position in the pic.
Running tests on trunk. Only a few minor issues. Otherwise, it's looking good. The test-date-yyyymmdd is returning ok even when the day is blank. Then locale-date returns some bogus date. The pic is treating the $ like a floating, even when it only takes one position in the pic.
Running tests on trunk. Only a few minor issues. Otherwise, it's looking good. The test-date-yyyymmdd is returning ok even when the day is blank. Then locale-date returns some bogus date. The pic is treating the $ like a floating, even when it only takes one position in the pic.
This won't compile in trunk. Something about variable length limits not defined.
This won't compile in trunk. Something about variable length limits not defined.
HOME and END keys toggle on current column. Backspace beep column 1. [301 see also r2540]
HOME and END keys toggle on current position. [301]
Yes, numeric accepts (or displays) are not handled well. As far as I know, decimal points and commas are not handled at all. I'm thinking we should not allow accept of numeric edited fields. That may make it too complicated right now. Maybe later. The first thing we should do here is to create a document of what is expected. If the coder accepts 9(09)v9(02) should the user have to enter the integer part and then the decimal part? Or just type 3.2 and the system lines up the decimal point and returns...
I like this. More logical. Thanks for the idea. I'll check these in tomorrow.
I like this. More logical. Thanks for the idea. I'll check these in tomorrow.
I like this. More logical. Thanks for the idea. I'll check these in tomorrow.
Yes, looks more elegant. Fewer variables to go wrong. I'll start on it.
Here are changes for reset Home and End keys. I've fixed an issue where Backspace now beeps at column 1. I've changed the checkmanual tests to include a SIZE. The tests should come out identical to what it was before. I want to make sure these keys work well with SIZE. Let me know if anything needs changing. I'll commit it in a few days.
Here are changes for reset Home and End keys. I've fixed an issue where Backspace now beeps at column 1. I've changed the checkmanual tests to include a SIZE. The tests should come out identical to what it was before. I want to make sure these keys work well with SIZE. Let me know if anything needs changing. I'll commit it in a few days.
I've been thinking about it and I'm beginning to like the idea. I'll go ahead and reset both toggles when the current changes. It may be a few days or maybe next week.
Yes, I had to remove a . The double did not work on my system. I haven't thought about toggle reset based on current. I don't have a feeling either way right now. Let's use it for a few months and see what it feels like. We should think like a user and go with what feels the easiest to learn.
okey dokey smokey. It's checked in. This also fixes a issue with the Insert key at column 1 eating characters. [feature-requests:#301]
Checked in. The alt-home and alt-end keys are replaced with toggles. Fixed an issue with the Insert key at column 1. It was "eating" the first typed character. Fixed other alt keys. Added key tests to the make checkmanual tests.
I found I could press any F-key and it would exit the test with a failed message.
Yes, on the second test I didn't use the arrow keys. I don't know how to use screen section. It will take some getting used to. It's like CICS, which I haven't used in ages. With extended accepts, each field is like its own screen, so you have to write your own arrow key processing. I've added 8 tests to the manual screen tests. One test found a bug for me. With insert mode on, and the field starts in column 1, it "eats" the first character typed in column 1. I've got a fix in now. I'll check it...
The one that says Enter "y" if you cannot continue without filling all of the below field: won't let me get out of the field, even when the field is full of characters. I would say "N" but I can't get past it.
This looks like a "N". Correct?
This looks like a "N". Correct?
I've attached an updated screenio.c to the ticket. It has the Home and End key toggles. And fixes to other alt keys. If someone wants to test it, let me know if anything comes up. I'll commit in a few days. I can't get the alt_bs (Backspace) key to work at all. cat > /dev/null does not return anything when pressing either Backspace or Alt-Backspace. I can't find anything when I google it either. Someone wiser than I will have to have to look at that one.
Attached Home and End keys toggle. And fixes to other alt keys. I will commit in a few days. Updating the info gnucobol file now.
checkout is very slow. It crashed. A cobol-trunk/tests/testsuite.src/run_initialize.at svn: E000107: malformed property list for node-revision 'a1-1.1-1821.r2473/5295' svn: E000107: Can't read file '/svn/p/open-cobol/code/db/revs/1/1792': Transport endpoint is not connected do-not-backup> Deleted it and tried again. Looks like I finally got it. What can I say? Just keep trying.
Opened ticket. [feature-requests:#301]
toggle HOME and END keys in ACCEPT
There have been several iterations of alt key work in the extended ACCEPT statement. Simon noticed that some of the alt keys in trunk don't work. I'm not sure what's going on right now. I'll be happy to look at it but I won't be able to look for several days. Some alt keys are not defined in the curses package. There has to be sample programs run to determine what is being returned. To complicate matters, different versions of curses return different things. I never heard back from the curses group...
The info gnucobol at 6.5.4 SIZE just runs on into a discussion about figurative constants. I'm thinking a 6.5.5 should be added. Current: ``SIZE ZERO'' `<`SIZE' option not specified>' Variable-1 or literal-1 displays with the field length. Certain figurative constants have special functions. `SPACE': Display spaces from LINE and COLUMN to the end of the screen. This is the same as WITH ERASE EOS. Probably should be updated to this: ``SIZE ZERO'' `<`SIZE' option not specified>' Variable-1 or literal-1...
I checked in the fix. The ask * Accept Special Keys should compile now.
Change cob-scr-page_up and cob-scr-page_down to hyphens.
Another question: when I look at /usr/local/share/gnucobol/copy/screenio.cpy, I see four-digit values (e.g. COB-SCR-F2 is 1002.) Clearly those values are meant to be stored in something larger than an unsigned char, which is 8 bits. There is a sample program in contributions that gets the returned value in the special register cob-crt-status. It returns the full (non-folded) number. So it's returning more than just 8 bits. Look at ask * Accept Special Keys. I just tried it, and it does not compile....
Another question: when I look at /usr/local/share/gnucobol/copy/screenio.cpy, I see four-digit values (e.g. COB-SCR-F2 is 1002.) Clearly those values are meant to be stored in something larger than an unsigned char, which is 8 bits. There is a sample program in contributions that gets the returned value in the special register cob-crt-status. It returns the full (non-folded) number. So it's returning more than just 8 bits. Look at ask * Accept Special Keys. I just tried it, and it does not compile....
Yes it's a reasonable change. If a user wants to put a character in a single character field, then that character should go there. They shouldn't have to hit other buttons to make that happen. If the single character prompts with a default action, the user should be able to easily enter something else. For example, an entry field for a menu. The default action might be letter "s" for "Search". So the accept with update displays "s" and waits for the user's entry. The user can just press enter and...
Pat, when changing this, please also update the gnucobol.info file. Explain in the Insert Key section (currently 6.4.6) about characters not rolling off the end when insert is on. And the new change, that if the field length is 1 the entry replaces what's there. If there's any other part of the ACCEPT and DISPLAY info that can be made clearer, please do. Sometimes, my documentation skills use a bit too much technical jargon.
There's been a routine added to the insert to not roll characters off the end of the field. I believe this routine should not be done if the length of the field is 1. Go ahead and do this if you wish.
There has been a routine added to the insert to not loose characters at the end of the field. I believe this routine should not be done if the length of the field is 1. (And perhaps there should be an environment variable to allow characters to roll off. But that's an issue for a later time.) Simon, Pat said he'd like to look at it. Unless I hear otherwise I'll let him give it a go.
I can't check out. What am I doing wrong? /tmp> svn checkout --username=cobcoder https://svn.code.sf.net/p/open-cobol/code/trunk open-cobol-code svn: E160013: Unable to connect to a repository at URL 'https://svn.code.sf.net/p/open-cobol/code/trunk' svn: E160013: '/p/open-cobol/code/trunk' path not found /tmp>
Looking... But why can't I check out so I can look at previous versions? /tmp> svn checkout --username=cobcoder https://svn.code.sf.net/p/open-cobol/code/trunk open-cobol-code svn: E160013: Unable to connect to a repository at URL 'https://svn.code.sf.net/p/open-cobol/code/trunk' svn: E160013: '/p/open-cobol/code/trunk' path not found /tmp>
Somebody please fix. [bugs:#498]
This error is found in trunk r2431.
Extended ACCEPT errors 1 byte field when Insert on
Thanks a heap bunch (pun intended). Rw is looking good.
I just got the rw branch and it works. Thanks a bunch. I'll be running further tests on the rw download sometime this week.
I want to thank everyone for taking time out to look into this. It's really a stickler for me. This is really an application logic error, but it should not cause the runtime code to abort. Yes, that's true for files opened in sequential access mode. There must have been a valid read before the rewrite. From a manual I have "the value in the prime record data item of the record to be replaced must be equal to the value of the prime record key of the last record read from this file." Maybe it should...
Is there (or should there be) a minimum version? If it helps, I'm using libdb-4_8. Version 4.8.30-30.4. The same with devel. I was going to suggest backing the suppress and split keys from trunk. Then allow me to put my own suppress in trunk. (Mine allows low-values also.) As far as I can tell, the code for suppress and split keys does not overlap. If that works, then the issue would be narrowed to split keys. Which can be put back in trunk when the issue is solved.
Same thing. /tmp/test2> cobc --info cobc (GnuCOBOL) 3.0-dev.0 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart Built Dec 26 2017 08:34:53 Packaged Dec 26 2017 13:08:24 UTC C version "4.8.5" build...
BTW, if the file pathname is not initialized (left spaces) it hangs the program. Someone might want to look at that.
Got a sample that gets a seg fault. It's different, but at least it's an error. /tmp/test2> cobc -x -std=notrunc -fdefaultbyte=75 /tmp/test2/tb.cob -o /tmp/tb /tmp/test2> /tmp/tb delete file delete file open open start > tbw-key start > tbw-key read next read next write write start >= tbw-alt start >= tbw-alt start > tbw-key start > tbw-key read next read next read next read next close close delete file delete file open open start > tbw-key start > tbw-key read next read next write write write write...
Here's the output (gdb) bt #0 0x00007ffff706691d in __bamc_refresh () from /usr/lib64/libdb-4.8.so #1 0x00007ffff70fbee1 in __db_cursor_int () from /usr/lib64/libdb-4.8.so #2 0x00007ffff7107b7a in __dbc_idup () from /usr/lib64/libdb-4.8.so #3 0x00007ffff710898d in __dbc_iget () from /usr/lib64/libdb-4.8.so #4 0x00007ffff7113959 in __dbc_get_pp () from /usr/lib64/libdb-4.8.so #5 0x00007ffff7ba3485 in indexed_write_internal () from /usr/local/lib64/libcob.so.4 #6 0x00007ffff7ba6761 in indexed_rewrite...
I put configure --enable-debug and added -debug -g to the cobc. I'm not getting any extra warnings. These are two runs. The 12082 is the rewrite. tb.cob: 12082: attempt to reference unallocated memory (signal SIGSEGV) *** Error in `tb': double free or corruption (!prev): 0x0000000001518690 *** Segmentation fault tb.cob: 12082: attempt to reference unallocated memory (signal SIGSEGV) *** Error in `tb': double free or corruption (!prev): 0x0000000000e7f690 *** Segmentation fault However, with a different...
I tried some changes to sift the error down. What I found is that it only happens after create file, write some records, one or more rewrites, close, delete file, open i-o, write some records, then it segfaults on the first rewrite. The first file create and processing does not get the error. The second one segs. So... I commented out the first, and then the second one (now the first) started processing fine. The third one (now the second) gets the seg. To me, it looks like either delete file or...
I tried some changes to sift the error down. What I found is that it only happens after create file, write some records, one or more rewrites, close, delete file, open i-o, write some records, then it segfaults on the first rewrite. The first file create and processing does not get the error. The second one segs. So... I commented out the first, and then the second one (now the first) started processing fine. The third one (now the second) gets the seg. To me, it looks like either delete file or...
Any idea what this is? It's happening on a key file rewrite that has 1 alternate key. The hex number seems to always be different when it errors. attempt to reference unallocated memory (signal SIGSEGV) *** Error in `tb': free(): invalid next size (fast): 0x00000000022f9670 *** Segmentation fault
Ok, r2275 looks good. The make test is identical. 583 tests behaved as expected. 6 tests were skipped. And the altkey.cob sample runs correctly. I'll be running my internal tests over the next weeks or months, depending on time. Thanks.
All keys are defined for now, so that probably won't be a problem.
All keys are defined for now, so that probably won't be a problem.
All keys are defined for now, so that probably won't be a problem.
Running now. ERROR: 583 tests were run, 2 failed (1 expected failure). 6 tests were skipped. The one unexpected failure is 352: Trace feature with subroutine FAILED (run_misc.at:8423)
Looks like some doc issues in rw... So this is in make and make check. Can't run tests... Making all in doc make[2]: Entering directory '/home/do-not-backup/cobol-2266-rw/doc' . ../tests/atconfig && . ../tests/atlocal && ../doc/cobcinfo.sh cbhelp.tex ../doc/cobcinfo.sh: creating cbhelp.tex . ../tests/atconfig && . ../tests/atlocal && ../doc/cobcinfo.sh cbrese.tex ../doc/cobcinfo.sh: creating cbrese.tex . ../tests/atconfig && . ../tests/atlocal && ../doc/cobcinfo.sh cbintr.tex ../doc/cobcinfo.sh:...
Looks like some doc issues in rw... Making all in doc make[2]: Entering directory '/home/do-not-backup/cobol-2266-rw/doc' . ../tests/atconfig && . ../tests/atlocal && ../doc/cobcinfo.sh cbhelp.tex ../doc/cobcinfo.sh: creating cbhelp.tex . ../tests/atconfig && . ../tests/atlocal && ../doc/cobcinfo.sh cbrese.tex ../doc/cobcinfo.sh: creating cbrese.tex . ../tests/atconfig && . ../tests/atlocal && ../doc/cobcinfo.sh cbintr.tex ../doc/cobcinfo.sh: creating cbintr.tex . ../tests/atconfig && . ../tests/atlocal...
Have the build instructions changed? I went to Tree[r2266]/branches/reportwriter and clicked on download snapshot. The configure command is not found: # ./configure bash: ./configure: No such file or directory I looked in trunk and it also does not have configure. What's up?
I won't be testing split keys at all. But I'll test the alternate suppress from RW when I get some time. I'll post then what I find. I only use db for now. So if VB can't support it, I'll just keep with db. Although, I hope VB supports it in the future. If RW works for me, then I won't be doing any pre-release tests on trunk until it gets merged. I simply haven't got the time to keep putting this back in.
I haven't had time to work on GC. But I really need the suppress when space clause. I wish to work on this, and check it in, hopefully sometime about March 2018, depending on my available time. I need to paint this bicycle rack. You guys and gals can go figure out the rest.... I'll try to help on other items later if I can. [feature-requests:#23]
I really want to get this in GC 2.3. I must have this. Every time I download a new GC I have to put this back in. This is getting very tedious. Especially since I want to test pre-release versions. I hope to have some time to work on this by March 2018. At least for db. And make it error for vbisam and others if they still doesn't support. Unless I hear any objections, I will check it in for the 2.3 release.
ACCEPT/DISPLAY SIZE no longer works
This is a thread from Possible feature request On EXCEPTION for use with ALLOCATE. Java is useless in batch. Call C++ or Java to run a GUI or web interface and get the user inputs. Then CANCEL the OO programs to free the memory and do the batch processing. I can think of a lot of enhancements to COBOL that would be far more productive than OO. OO would take a huge amount of work, for very little benefit. I would much rather see ORGANIZATION IS CSV in the SELECT. And design more flexible extended...
Be careful with batch processes. Allocating and freeing memory items for each record, when there are millions or billions of records can degrade performance. Sometimes to the point that the software is unusable. That's one of the main reasons when software written in OO languages do not scale up. With GUI and such, these performance penalties are hardly noticed. Beginners get used to doing it that way. But when they go into a batch environment then the excitement really gets started. Brian, you forgot...
GnuCOBOL supports both extended ACCEPT and SCREEN SECTION. Please be more specific. What is the problem? For an example program showing the use of extended ACCEPT, see this: sourceforge.net/p/open-cobol/contrib/HEAD/tree/trunk/samples/accept-keys/
Funge is to machine code what C is to assembler. Another esolang, arguably in the number two spot for popularity and wasting time. Agreed.
Have a look at this one too. This is the sort of business processing that COBOL does well. https://sourceforge.net/projects/acas/?source=directory ACAS contains Sales, Purchase and Nominal Ledgers (Accounts Receivable, Payable and General Ledgers) as well as Stock Control (Inventory Control) along with IRS (Incomplete Records System). This system is written in COBOL and uses Open/GNU Cobol ...
snips 6 characters from SOURCE-FIELD into TARGET-FIELD Just to clarify, it doesn't snip 6 characters. It snips 13. Move x (beginning:length) to y.
Ha, 7 8 9. I never saw that before. A programmer used to fill his unused memory with hex DEAD. It stood out real good in a core dump. But 3 should have been 4 because 3 is half of 8.
Since the zero is at the end, maybe stringz()?
I agree. I found that other peoples tab settings don't match each other, and don't match mine. It makes for a confusing read. Although, making this change to all files would make an svn diff really ugly. So I'm inclined to leave it as it is for that reason.
Then check for duplicates before the rewrite. In this example, the user read the record with all "1" keys. When the user changes one or more keys (to all "2" in this example), then check each of the keys that have a new value, before doing the rewrite. If one or more shows up as a duplicate then tell the user which one(s) are duplicate and let them change it (or some error routine depending on your application). Only do the rewrite if no duplicates are found.
Then check for duplicates before the write. In this example, the user read the record with all "1" keys. When the user changes one or more keys (to all "2" in this example), then check each of the keys that have a new value, before doing the rewrite. If one or more shows up as a duplicate then tell the user which one(s) are duplicate and let them change it (or some error routine depending on your application). Only do the rewrite if no duplicates are found.
I don't know of any vendor that supplies which keys were duplicate. I suggest writing a routine to return the duplicates. Maybe similar to this. Perform kc-key-check thru kc-exit when a duplicate is detected. Then check the flags. This could be performed before the write, if you wish. This only checks the index. It does not actually read a record. So it is fast. 01 key-master pic x(01). 88 key-master-no value low-value. 88 key-master-yes value high-value. 01 key-alternate-1 pic x(01). 88 key-alternate-1-no...
Numeric input conversion is accomplished by a scan of the input field according to the following rules: ... I would say open a ticket for this, if one is not already open, and attach these rules to it. Give everyone a chance to make comments. After a few months, after any discussion is settled, use this as the design document.
I'm not sure what the question is. It's valid COBOL, so it's "correct" in that sense....
Has anyone counted up the number of languages and packages that GnuCOBOL has interfaced...
Brian answered both questions better than I could. Maybe the book has to be bought....
There's those beltway bandits, I mean con artists, I mean consultants, that say "Let...
"Cobol is this code word for throwing disdain toward the mainframe platform," said...
1) Got this in make check: 60: Redefinition of program-name by other programs FAILED...
A work around is to ACCEPT a PIC X or group field. Then convert it to numeric. Modify...
If it is a random file, then we would need to know the file structure before determining...
It is not so much invalid as just wrong when printing. By using it as is having a...
Looks to me the setup should look something like, Select my-file assign to "my-file.bin"...
The HOME and END keys are available to the extended ACCEPT. Not to the screen section...
I forgot to mention svn diff --changelist. To me this is the most important svn feature...
Depends on the application. Let's say the program is reading through a file sequentially...
These techniques exist in programs where performance matters. For me, it is not just...
Adding to what Brian said, Using svn changelist helps me greatly to keep organized....
I have no idea how to trigger the error. All I know is that when I found the error...