|
|
Post by sromes1 on Sept 19, 2022 10:12:38 GMT -5
hi all I retired yrs ago after being a cobol/db2 programmer for 35 yrs. I'd rather not learn a new language so was looking into gnucobol and using spfite to edit input data file and map it to a screen where I can edit the fields and save the values or create a add screen where inputed values are written to create a new record. I want to write a food program where I can use the usdafood database file to display food values, create additional food values and have other screens where I can create recipes made from various food items. for example suppose I want to determine the food values for a slice of bread from a loaf of bread I make. i want to input the various ingredients and number of servings it makes( slices in this case to determine the fat,carbs,protein etc in 1 slice of bread. Then make another recipe for say a peanut butter sandwich where I can input 2 slices of bread and a tablespoon of peanut butter to determine total fat,carbs,protein etc in the sandwich. using either the usda file for individual foods and recipes I created to create other recipe records and use the recipe records to create a record type "M" for meals where I can determine the fat,carbs,protein etc for the total meal. So I think I need an "I" record type for individual foods , "R" type for recipe records and a "M" type for meal records. ideally when I start typing a food value , the program will search the file and pop up a window where a scrollable list of similar food types will appear and I can select which one for example if I type in flour ...then flour wheat, flour white, flour rye entries appear . Would I be able to do this in gnucobol ? thx steve
|
|
|
|
Post by Stefan on Sept 19, 2022 10:57:47 GMT -5
Well, I'm not really sure exactly what you are asking, but... SPFLite will almost certainly allow you to create, edit and maintain your gnuCobol source files. But beyond that, and unlike ISPF/PDF from IBM, SPFLite does NOT provide a Dialog Manager with which you can 'paint' windows with fields, validate input, etc., etc.).
Whether a program written in gnuCobol can provide the capability you seek, e.g. build display windows with input or output fields which are referenced by gnuCobol variables, spot button press events, etc., etc., all in a Windows environment, I have to say I'm sorry, I have no idea. |
|
|
|
Post by sromes1 on Sept 19, 2022 14:08:26 GMT -5
thx robert/stefan ..I wasn't clear ...I only want to use spflite to edit the usda food file. Was hoping to use that file to create a indexed file ,I could process using Select file assign to "/tmp/myfile.txt". I should have prefixed my post with ...I know this isn't a spflite question but I want to know if anyone here has used gnucobol and would it be able to do this...... I posted on the sourceforge.net discussion group but no answers yet. sorry for the confusion
thxs steve
|
|
|
|
Post by sromes1 on Sept 19, 2022 17:39:52 GMT -5
hi robert when I go to sourceforge.net/projects/gnucobol/ it says this GnuCOBOL translates COBOL into C and internally compiles the translated code using a native C compiler. Build COBOL programs on various platforms, including GNU/Linux, Unix, Mac OS X, and Microsoft Windows. GnuCOBOL has also been built on HP/UX, z/OS, SPARC, RS6000, AS/400, along with other combinations of machines and operating systems. download is at gnucobol.sourceforge.io/steve |
|
|
|
Post by sromes1 on Sept 19, 2022 18:08:52 GMT -5
Well, I'm not really sure exactly what you are asking, but... SPFLite will almost certainly allow you to create, edit and maintain your gnuCobol source files. But beyond that, and unlike ISPF/PDF from IBM, SPFLite does NOT provide a Dialog Manager with which you can 'paint' windows with fields, validate input, etc., etc.).
Whether a program written in gnuCobol can provide the capability you seek, e.g. build display windows with input or output fields which are referenced by gnuCobol variables, spot button press events, etc., etc., all in a Windows environment, I have to say I'm sorry, I have no idea. hi stefan.not looking for any dialog manager abilities.Guess I'll see if any in the discussion group responds thx steve |
|
|
|
Post by arnoldtrembley on Nov 23, 2022 23:18:40 GMT -5
|
|
|
|
Post by sromes1 on Nov 29, 2022 18:36:12 GMT -5
hi R just a fyi ... I haven't installed gnucobol (otherwise I'd help). I'm still tryng to understand the relationships and data
in the food database I downloaded because the usda provides the data table layout but no infor on how they fit together.
Figured no sense on writing a program until I know the data. chuck hattvedt has helped me install LibreOffice Base and dbeaver
but I must say even setting it up with obdc etc would have been a challenge for me without his help. Being just a mainframe guy it has been a humbling experience ...at best |
|
|
|
Post by arnoldtrembley on Nov 29, 2022 19:21:21 GMT -5
Arnold, I looked at the linked you provided, but I can't say that I understand them. Any time I have tried to deal with Source Forge or GIT or GNU or any of these open source things, I get totally baffled and mystified. It seems like all of these sites assume that everyone knows how to build open source software. But, I don't. Is it possible you could provide a "complete idiot's guide" to going from zero to having the Gnu Cobol running on Windows 10? And, I *do* mean "zero". I have utterly no clue how to get this done. Mind you, I *do* know COBOL. I wrote tons of it for decades. I just don't get this open source stuff. Thanks in advance, if you can figure out how to explain this. R These instructions are for a Windows PC.
Then download the MinGW based GnuCOBOL compiler with BDB for ISAM files, from this link:
The file is about 24 megabytes. Rename the file extension from .7z to .exe (my Web Hosting service does not allow me to serve .exe files). Then execute that file. It's a 7-Zip self-extracting archive. It will ask you for a folder name to extract to. I suggest something like C:\GnuCOBOL or C:\GC312. It can be any disk or folder or path name you choose.
Then open a CMD.EXE shell (or Windows Terminal CMD.EXE session) and navigate to that folder. Read the STARTHERE.txt file. Then run the set_env.cmd file (just like a .bat file) to set the PATH and environment variables for the compiler and runtime libraries.
Then run the "testgc.cmd" script, which will compile the testfunc.cob program two different ways (as a .exe file and a .dll file) and execute it twice. Be aware that the exe, dll, and lst files created by testgc.cmd are temporary and will be deleted when the script ends. The purpose is to verify the compiler is installed correctly.
There is a gcx.cmd file provided for compiling COBOL programs (both .cob and .cbl are supported as file extensions identifying COBOL programs). You are free to customize gcx.cmd to your own needs or clone it to create your own compile script. I recommend keeping your COBOL source code and executables in a separate folder from the GnuCOBOL compiler.
The compiled COBOL programs will run in a CMD.EXE or Windows Terminal CMD.EXE shell.
Remember that you always need to run set_env.bat in your CMD.EXE window in order to make the COBOL runtime environment available to the executable programs. GnuCOBOL does not support building stand-alone executable programs like PowerBASIC. "set_env.cmd" needs to run in the folder where the compiler resides, but you can call set_env.cmd with its full path from anywhere. you can "send" the set_env.cmd file to the desktop as a shortcut. It will run and leave a CMD.EXE window open for you with the compiler folder as the current directory.
You can also ask questions in the GnuCOBOL Forums on Sourceforge. It is free to view or post, but if you register you can post for free without waiting for a moderator to review your post first.
Good luck!
|
|
|
|
Post by arnoldtrembley on Nov 29, 2022 21:29:43 GMT -5
In general, I recommend NOT setting the GnuCOBOL environment variables and PATH update in the registry, because it's difficult to change that from a script when upgrading to a newer compiler (in a folder with a different name), or when moving the compiler to a different folder/path.
Also, I have several different versions of the GnuCOBOL compiler installed under the same Windows UserID, and switching between them is much easier when using temporary environment variables for the current CMD.EXE or Windows Terminal shell. But you can certainly use permanent environment variables if you prefer to do it that way. As far as I can tell, you can only have one GnuCOBOL compiler and runtime library version per UserID when using permanent environment variables.
Thanks very much for the tip on CMD.EXE! I have redirected that help output to a text file and saved it, because it is multiple screens of text.
Kind regards,
|
|
