Larry Simmons

Simon, I will let you know about the decision on open source. The regression testing librrary that we used contained 713 COBOL Program Members plus an additional 238 COBOL Copy Members. The programs we chose for "compile and test" were batch jobs that processed traditional file structures supported by COBOL. If you want more information about the Cobol Members (i.e. Lines of Code, Record Count, etc.) then refer to the following link. http://www.simotime.com/aphtml01.htm The report includes details...

Jay, We are sorry you were not able to easily find or access the copy members. When we first created our website it was much smaller and limited in scope. Initially, we did receive request for additional or missing source members along with request for more functions. Our helpdesk responds to 90 percent of these requests within 24 hours. We still receive numerous request for additional function or further clarification of concepts discussed in our documentation. However, the number of request for...

Simon, As per your request for a sample of "The ACCEPT ENVIRONMENT function under Micro Focus was liberal in its coding syntax and coding techniques. GnuCOBOL was more precise in the syntax editing."? We had a version of MFENVARS.cbl that would compile in an IBM or non-IBM dialect under Micro Focus. If memory serves me correctly it failed to compile under Open COBOL 1.0 using the IBM dialect. GET-ENVIRONMENT-VARIABLE. move SPACES to ENV-VAR-VALUE display SPACES upon ENVIRONMENT-NAME display ENV-VAR-NAME...

Brian, Simon... As per your request, "As the keeper of the GnuCOBOL FAQ, can I cite some of your numbers?" My answer is, "Yes. However, you may want to consider where I am at in this project. I have compiled the programs but I am still in the middle of testing. Things are on schedule and looking very good at this point in time. We have approximately 30 days to go before we wrap-up the test phase. I will keep you posted on the progress." You may want to view the following. It is a work-in-progress...

Simon, we removed the -o and the -fixed and things seemed to work AOK. cobc -std=ibm $SLIB/COBOL/$nameuc.cbl $TLIB/$nameuc.so -I SIMOSAM1/DEVL/COBCPY1 -t $LLIB/$name.prn However, when we copied a couple of new programs and compiled for the first time we got the following message. cobc: HOLD/MODS/MFENVARS.so: No such file or directory We put the -o back and it compiled. Once the .so was created we removed the -o and it would compile AOK. cobc -std=ibm $SLIB/COBOL/$nameuc.cbl -o $TLIB/$nameuc.so -I...

Brian, we did system maintenance over the weekend and needed to reboot our system. We had a set of folders that were used for the GnuCOBOL 1.0 version and this was moved off the system and archived. After seeing your note we decided to back-out the work around in MFENVARS.cbl and it worked AOK. We now get the same results you are getting. I do not have an explanation as to why. I did want to give you a heads-up so you could focus on other things. We will be running a larger suite of application and...

Brian, First, let me focus on improving my "cut-and-paste" skills to include the version number. cobc (GnuCOBOL) 2.0.0 Now let me focus on the original topic. The following link should provide the detail you requested. http://www.simotime.com/cblenv01.htm Lat me know if you need additional information. I am very interested in pursuing this item but I am not in a rush since I have the work around. Larry

I am using GnuCOBOL 5.4.0 20160609 to retrieve an Environment Variable. WORKING-STORAGE SECTION. 01 ENV-VAR-LOCAL PIC X(1024). LINKAGE SECTION. 01 ENV-VAR-VALUE PIC X(1024). ACCEPT ENV-VAR-VALUE FROM ENVIRONMENT ENV-VAR-NAME When ENV-VAR-VALUE is in the LINKAGE SECTION the text string within the field gets truncated at 256 bytes. The following works as I would expect. ACCEPT ENV-VAR-LOCAL FROM ENVIRONMENT ENV-VAR-NAME MOVE ENV-VAR-LOCAL to ENV-VAR-VALUE What am I missing here? Is this a bug or a...