[root@RHEL7-cdmspkgconfig]# ls -all
total4
drwxrwx---2rootroot19Mar2815:41.
drwxr-xr-x.3rootroot111Mar2815:41..
-rw-r--r--1rootroot251Mar2815:41gmp.pc
I made sure that I added include /usr/local/lib in the /etc/ld.so.conf as was suggested, but when I perform the ./configure, I am getting the various messages to the screen regarding gmp
configure: Checks for GMP/MPIR ...
checking for gmp... no
checking for libgmp... no
checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
checking whether linking against libgmp with "-lgmp" works... yes
checking matching GMP version... no (header: 6.3 / library: 6.0.0)
configure: error: in `/data1/cdms/gnucobol-3.2':
configure: error: unable to use GMP
See `config.log' for more details
the config.log shows the following:
configure:15664: Checks for GMP/MPIR ...
configure:15699: checking for gmp
configure:15706: $PKG_CONFIG --exists --print-errors "gmp"
Package gmp was not found in the pkg-config search path.
Perhaps you should add the directory containing `gmp.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gmp' found
configure:15709: $? = 1
configure:15723: $PKG_CONFIG --exists --print-errors "gmp"
Package gmp was not found in the pkg-config search path.
Perhaps you should add the directory containing `gmp.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gmp' found
configure:15726: $? = 1
configure:15740: result: no
No package 'gmp' found
configure:15759: checking for libgmp
configure:15766: $PKG_CONFIG --exists --print-errors "libgmp"
Package libgmp was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgmp.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgmp' found
configure:15769: $? = 1
configure:15783: $PKG_CONFIG --exists --print-errors "libgmp"
Package libgmp was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgmp.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgmp' found
configure:15924: checking gmp.h usability
configure:15924: gcc -c -O2 -Wall -Werror conftest.c >&5
configure:15924: $? = 0
configure:15924: result: yes
configure:15924: checking gmp.h presence
configure:15924: gcc -E -Wall -Werror conftest.c
configure:15924: $? = 0
configure:15924: result: yes
configure:15924: checking for gmp.h
configure:15924: result: yes
configure:15930: checking whether linking against libgmp with "-lgmp" works
configure:15943: gcc -o conftest -O2 -Wall -Werror conftest.c -lgmp >&5
configure:15943: $? = 0
configure:15944: result: yes
configure:16122: checking matching GMP version
configure:16154: gcc -o conftest -O2 -Wall -Werror -Wall -Werror conftest.c -lgmp >&5
configure:16191: $? = 0
configure:16191: ./conftest
configure:16191: $? = 0
configure:16211: result: no (header: 6.3 / library: 6.0.0)
configure:16213: error: in `/data1/cdms/gnucobol-3.2':
configure:16215: error: unable to use GMP
See `config.log' for more details
the contents of the .etc.ld.so.conf is the following:
include ld.so.conf.d/*.conf
include /usr/local/lib
I am a COBOL programmer by skill, and only know enough about C to be very dangerous. I have downloaded and extracted again, and still no luck. Just not sure what else to do here.
I am on a RHEL server
$> uname -a
Linux RHEL7-cdms 3.10.0-957.27.2.el7.x86_64 #1 SMP Tue Jul 9 16:53:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Any advice would be greatly helpful. I did search Discussions for Configure gmp error, and just gmp and did not find anything that looked like my error.
Last edit: Simon Sobisch 2024-03-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Package gmp was not found in the pkg-config search path.
Perhaps you should add the directory containing `gmp.pc'
to the PKG_CONFIG_PATH environment variable
The reason is that the gmp install is not found in the default folders. You therefore have either to explicit set the relevant variables on the configure line or - even better - let pkgconf do this.
make-pbuild_rel# using a separate folder in case you may want to run "extended" debugging tools later cdbuild_rel
# building optimized for this system, drop the tune/arch if you have old GCC or want to distribute the generated GnuCOBOL binaries
../configurePKG_CONFIG_PATH=/usr/local/lib/pkgconfigCFLAGS="-O2 -g -march=native -mtune=native"
BTW: in the last 16 years of GnuCOBOL development and installations on several operating systems I never had to run ldconfig. But you may need to export LD_LIBRARY_PATH=/usr/local/lib to let the libraries be loaded at runtime (or specify a matching rpath with LDFLAGS - if you're not sure what that part mean "you are not the intended audience" - and setting LD_LIBRARY_PATH works fine).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
and am still getting this error message to the screen:
configure: Checks for GMP/MPIR ...
checking for gmp... yes
checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
checking whether linking against libgmp with "-L/usr/local/lib -lgmp " works...
yes
checking matching GMP version... no (header: 6.3 / library: 6.0.0)
configure: error: in `/data1/cdms/gnucobol-3.2':
configure: error: unable to use GMP
See `config.log' for more details
In the config.log I am seeing this, most of the errors have
disappeared, but not all:
so am I adding the "/usr/local/lib" as the environment variable for the PKG_CONFIG_PATH or the folder that I compiled the gmp in?
And where exactly do I add this environment variable in the configure script? I saw an area that had descriptions of various environment variables, but not exactly sure where to put this.
if I am to use /usr/local/lib as the environment, then why did I need to put the include /usr/local/lib in the /etc/ld.so.conf file? I figured this is why we did this?
And Thank you for getting back to me so quickly. I am a novice at best where this compiling of C programs is concerned.
Last edit: Simon Sobisch 2024-03-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If yes then consider using make checkall to ensure that everything works as expected (if you use the last release and don't have an exotic environment, then this is totally expected to just pass).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes it works and now am working on getting a few programs compiled.
We did use MF Cobol but an ancient version that we purchased in 1990. We still had to adhere to Cobol 85 because we were still supporting Pdp Rts Cobol, which I think was Cobol 77, Vax Cobol for Vms 5.1, and xeniX 3.2.2 and Unix 3.2.3.
We kept things at the oldest level of supported Cobol so we could just copy the code to each platform and compile. There were about 15-20 operating specific programs but the 3800 other programs were all the same. Some os specific copy libraries are maintained on each platform, which we kept that up even though we have not supported, PDP, VMS, Xenix since 2000. We do have customers on SCO Open Server virtual version 6 and RHEL.
With SCO not working in 2038, they all need to migrate to RHEL, the sooner the better because I do not plan on working until I drop dead, and I definitely am not going to be working in 2038. Ha.
Last edit: Simon Sobisch 2024-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In this case I'd expect the migration to go relatively smoothly.
For the operating system related programs, that are likely to CALL into C: ensure that you use the proper sizes and types there.
Note: instead of RHEL you may have a look at its derivates like Rocky Linux (my employer has customers with RHEL 8-9 and Rocky).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We had chosen RHEL because initially, we tried the OpenCOBOL and could not get any of the programs to compile but this was on version 1.1. We moved to RHEL because the MF cobol only supported RHEL and not CENTOS at the time. This enabled me to make the move with about 99% of the programs working, and did not have as much to move. Back in 2018, we were told that Open Server 6V might now run on VMWARE v7. We had to do something quickly as it was only myself that had to make the migration, It took me about 18 months to fix the 1% of the stuff that did not work, and debug a scroll region with Micro Focus, which turned out to be an Environment Variable, and not a programming issue. That was a nightmare to deal with MicroFocus - had to show them how it worked in 3 different Terminal Emulators, before the move to RHEL version of MF Cobol. After 3 months, I said to them, are we sure this is not a Environment Variable Switch that has to be set that is different. The lightbulb went off and 3 months of wasted time due to a Cobol SWITCH that needed to be set that was not there in a previous setting.
We use vt220 emulation, as we worked with DEC equipment for years, and we have Lines 5-22 setup as a scrolling region. It only scrolls in 1 direction, so things like reports will scroll in this region, with the report headings remaining STATIC on lines 1-4. without this particular switch it did not work. Then with the various terminal emulators, which all contain a scroll back area, we could use the terminal emulator to scroll back in that same region. None of this worked without that switch, but it always worked on any other COBOL that I have worked with, RSX COBOL on the PDP-11, VAX-COBOL on VMS 5.1 and MF COBOL circa 1990 on Xenix and Unix.
I became very disenfranchised with MF COBOL after that experience, and was terrifed to try to apply many more updates because I had no idea what new surprises I might find. The majority of the clients refused to pay the money for the RTS to MF again, and 6 years later, and closer to possible retirement, they clients are still not budging even though I have repeatedly told them in probably less than 14 years it is NOT going to work for them, and I am not going to be around to help them when it stops working. They just see this as plenty of time, and they know I am getting close to the age where I am going to leave.
We also want to stick with CENTOS or RHEL because all of our clients are HOSTED on a CLOUD, and they provide support for these 2 Operating systems, and a few other Linux but not all of them. Since the data centers are using RHEL more often than another OS, we will probably stay on that platform, but Thank you for the feedback. WE do have a few clients that are using MintLinux as a desktop client. We use Codeweavers (crossover - WINE) application to support any of the Windows terminal emulators that they were using on WIndows). I use MAC as my desktop client, because I did not like the lack of testing that was being done on Microsoft after Windows 7. From a support perspective, everytime Update Tuesday rolled around with Microsoft, I constantly had to walk people through fixing all of their Local Printers. It was exhausting.
Last edit: Simon Sobisch 2024-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, "scrollable" doesn't sound like COBOL85. This "may" be problematic, but for now just keep an eye for that while compiling the whole application once to see if there are general issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I attached the 3 programs which are EXTREMELY stripped down versions that just allowed Micro Focus to see 1 simple smallest file we have that when we choose to print the report to the screen by pressing the F4-key, it sets up the HEaders of the report on the first 4 lines of the page, in bold reverse video, then the lines below that become the forward scrolling region, until you press the key to end the output to the screen.
The Cobol switch that they had me set for the RHEL newer version of Visual COBOL 5 was COBCONFIG=/data1/cdms/TLS/rts-config-signal-regime-28
So in all previous versions of COBOL no such COBCONFIG was required, but this version of VISUAL cobol required it in order for the screens to work as they always have. all the strange little glitchy things went away, and the screens worked as they do on my MicroVAX 3500 (which I still have, and it runs, but I only turn it on to debug, as the VAX COBOL had the BEST debugger, much better than MF animator, and easier to use). I have tons of replacement parts for this MV3500 that were given to me by a VAX part reseller, who closed his business and moved to SC, so he gave me power supplies, mother boards, ethernet controller (which only LAT was supported on that version of VMS, Disk controllers, disk drives, TK70 tape drives).
I guess he figured it was cheaper than shipping it to SC.
I might have the open server 6 development suite.
I will have some time again next week.
If you are talking about the MV 3500,
I know we were able to compile a machine language program back in 1990, but honestly not sure what to look for in Help, I guess just C.
I will let you know.
Last edit: Simon Sobisch 2024-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is that old of a version of VMS going to have libraries that would work with gnucobol3.2? Would the gmp 6.3 be compatible?
This is before FTP and there is no way to unzip the file on the Vax because tar does not exist.
I can see if backup has some option that will extract a tar file, but I don't think so.
To get it to the Vax, I have to Kermit it down.
I just boot the dinosaur up, only other development lang is MACRO.
no C language, sorry.
Last edit: Simon Sobisch 2024-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think GMP could work on that, but without a C compiler and a bash that's not useful to check.
If you ever get to the point where you considering putting OpenBSD/Vax 5.8 on it, then we'd have everything - just drop a note (but that's not important).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't think the hardware would be supported on that version of the OS. It
is DSSI disk drives, and this is only a 2.2VUP processor speed with .25mb
of ram.
This is what these machines had back in Circa 1988. I joined CDMS with
DuPont in 1989 and this machine was already in place.
No tcpip stack at all. The network card supported LAT only. Vms 5.3 which
they considered open VMS did have Tcpip stack and used ssci disk drives.
This machine truly is an antique. At Dupont we had 20 people logged in and
processing on this machine, developing, testing, transferring patches to
clients.
It does luckily support a 1GB disk drive, but still DSSI.
I think GMP could work on that, but without a C compiler and a bash
that's not useful to check.
If you ever get to the point where you considering putting OpenBSD/Vax 5.8
on it, then we'd have everything - just drop a note (but that's not
important).
Simon, do you have a recommendation for either an Open Source DB or ISAM RTS that can be used. We did not use a DB under MicroFocus, and used MF Isam4 files. I know on the RHEL Visual Cobol version 5+, they supported ISAM8, and that would benefit a few of our clients on some of our files only, but only a few critical History files, most others are just small in comparison. We used separate ISAM files because many of our clients have Multiple TAX EIN numbers with different stores, but we were able to have each company be able to do implied transfer of inventory from one Corp to another. they could see the Inventory of all the Corps. Some of the data files were shared, such as the Inventory files, and each record had a store designation on it. But other files such as Accounts Payables, Accounts Receivable, payroll and General ledger are completely separate, and each company could not not view each others financial information, just inventory. The files were all grouped in different ENV Variables, so we could have the GL located in a completely different FOLDER than the other files, and so on. This gave us great flexibility in the setup of the customers, even though it definitely limited our "google" type of search in a Database. We would need to stick as close to our setup as possible, as we still have 5 clients that have multiple Corporations, and do not want to have to re-invent the wheel so to speak at this point. I would have to include the Company Code as the first field in every single record in the system in a single database, then we are tallking about a bunch of redundant programming that all has to be tested more thoroughly then if we just continued to use separate ISAM files.
I was told by a friend that Berkeley holds the ISAM RTS. I guess I will see what they offer.
Thank you for all of your assistance at this point. I am going to be tied up with Controller work until April 2, as it is accounting Month End, and we do consulting work for a few of our clients, reconciling their bank statements and such as well as our internal books.
Last edit: Simon Sobisch 2024-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest to create a new topic for this (actually for each separate topic), others would also have some recommendations for that (but it sounds likely you're fine with either the BDB or V-ISAM backend [the later currently needs patches to be usable]).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hoping to get this working, and see if I can get off of the Micro Focus Visual COBOL 5.0 but am on support and need to apply the newest updates before I drop support. I can't get a single one of my clients to move to RHEL because the fees to Micro Focus are just too high, the one time for the Runtime system is over 21K, and the yearly support they quoted for this year is 4800, but this goes up on average 10% per year.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Welcome to GnuCOBOL then. My employer moved most of his customers from MF (several versions) to GnuCOBOL 3.x; when starting this conversion "from scratch" I'd suggest to compile your COBOL sources with -std=mf-strict --debug, this will enable support for non-standard source code and setup some behaviour to match Micro Focus (for example initializing every data without an explicit VALUE clause, including internal index variables and pointers to SPACE), and enable runtime checks to inspect possible issues (if that's too much use at least -fec=bounds as an out-of-bound may produce different results than with MF).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gmp-6.3.0 compiled fine, no errors that I can see, and was able to do a make, make check, and make install
the various libgmp and the gmp.pc are in the /usr/local/lib
gmp.pc located in /usr/local/lib/pkgconfig
I made sure that I added include /usr/local/lib in the /etc/ld.so.conf as was suggested, but when I perform the
./configure, I am getting the various messages to the screen regarding gmpthe config.log shows the following:
the contents of the .etc.ld.so.conf is the following:
I am a COBOL programmer by skill, and only know enough about C to be very dangerous. I have downloaded and extracted again, and still no luck. Just not sure what else to do here.
I am on a RHEL server
Any advice would be greatly helpful. I did search Discussions for Configure gmp error, and just gmp and did not find anything that looked like my error.
Last edit: Simon Sobisch 2024-03-28
You nearly found that answer:
The reason is that the gmp install is not found in the default folders. You therefore have either to explicit set the relevant variables on the configure line or - even better - let pkgconf do this.
BTW: in the last 16 years of GnuCOBOL development and installations on several operating systems I never had to run
ldconfig. But you may need toexport LD_LIBRARY_PATH=/usr/local/libto let the libraries be loaded at runtime (or specify a matching rpath with LDFLAGS - if you're not sure what that part mean "you are not the intended audience" - and settingLD_LIBRARY_PATHworks fine).I tried using the
./configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfigand am still getting this error message to the screen:
In the config.log I am seeing this, most of the errors have
disappeared, but not all:
Should I make the entry in the /etc/ld.so.conf file be
INCLUDE /usr/local/lib/pkgconfig ????? instead of /usr/lib/local?????
and regarding the BTW on your first response, that was SO OVER MY HEAD. So apparently not the correct person, but not sure where I put this Variable?
export LD_LIBRARY_PATH=/usr/local/libdo I just set this before I do the configure??? or include it somewhere in the configure script?
Last edit: Simon Sobisch 2024-03-28
so am I adding the "/usr/local/lib" as the environment variable for the
PKG_CONFIG_PATHor the folder that I compiled the gmp in?And where exactly do I add this environment variable in the configure script? I saw an area that had descriptions of various environment variables, but not exactly sure where to put this.
if I am to use /usr/local/lib as the environment, then why did I need to put the include /usr/local/lib in the /etc/ld.so.conf file? I figured this is why we did this?
And Thank you for getting back to me so quickly. I am a novice at best where this compiling of C programs is concerned.
Last edit: Simon Sobisch 2024-03-28
I just used the entire line, after first typing in
Thank you.
Last edit: Simon Sobisch 2024-03-28
So your build now works?
If not then please attach config.log.
If yes then consider using
make checkallto ensure that everything works as expected (if you use the last release and don't have an exotic environment, then this is totally expected to just pass).Yes it works and now am working on getting a few programs compiled.
We did use MF Cobol but an ancient version that we purchased in 1990. We still had to adhere to Cobol 85 because we were still supporting Pdp Rts Cobol, which I think was Cobol 77, Vax Cobol for Vms 5.1, and xeniX 3.2.2 and Unix 3.2.3.
We kept things at the oldest level of supported Cobol so we could just copy the code to each platform and compile. There were about 15-20 operating specific programs but the 3800 other programs were all the same. Some os specific copy libraries are maintained on each platform, which we kept that up even though we have not supported, PDP, VMS, Xenix since 2000. We do have customers on SCO Open Server virtual version 6 and RHEL.
With SCO not working in 2038, they all need to migrate to RHEL, the sooner the better because I do not plan on working until I drop dead, and I definitely am not going to be working in 2038. Ha.
Last edit: Simon Sobisch 2024-03-29
In this case I'd expect the migration to go relatively smoothly.
For the operating system related programs, that are likely to CALL into C: ensure that you use the proper sizes and types there.
Note: instead of RHEL you may have a look at its derivates like Rocky Linux (my employer has customers with RHEL 8-9 and Rocky).
We had chosen RHEL because initially, we tried the OpenCOBOL and could not get any of the programs to compile but this was on version 1.1. We moved to RHEL because the MF cobol only supported RHEL and not CENTOS at the time. This enabled me to make the move with about 99% of the programs working, and did not have as much to move. Back in 2018, we were told that Open Server 6V might now run on VMWARE v7. We had to do something quickly as it was only myself that had to make the migration, It took me about 18 months to fix the 1% of the stuff that did not work, and debug a scroll region with Micro Focus, which turned out to be an Environment Variable, and not a programming issue. That was a nightmare to deal with MicroFocus - had to show them how it worked in 3 different Terminal Emulators, before the move to RHEL version of MF Cobol. After 3 months, I said to them, are we sure this is not a Environment Variable Switch that has to be set that is different. The lightbulb went off and 3 months of wasted time due to a Cobol SWITCH that needed to be set that was not there in a previous setting.
We use vt220 emulation, as we worked with DEC equipment for years, and we have Lines 5-22 setup as a scrolling region. It only scrolls in 1 direction, so things like reports will scroll in this region, with the report headings remaining STATIC on lines 1-4. without this particular switch it did not work. Then with the various terminal emulators, which all contain a scroll back area, we could use the terminal emulator to scroll back in that same region. None of this worked without that switch, but it always worked on any other COBOL that I have worked with, RSX COBOL on the PDP-11, VAX-COBOL on VMS 5.1 and MF COBOL circa 1990 on Xenix and Unix.
I became very disenfranchised with MF COBOL after that experience, and was terrifed to try to apply many more updates because I had no idea what new surprises I might find. The majority of the clients refused to pay the money for the RTS to MF again, and 6 years later, and closer to possible retirement, they clients are still not budging even though I have repeatedly told them in probably less than 14 years it is NOT going to work for them, and I am not going to be around to help them when it stops working. They just see this as plenty of time, and they know I am getting close to the age where I am going to leave.
We also want to stick with CENTOS or RHEL because all of our clients are HOSTED on a CLOUD, and they provide support for these 2 Operating systems, and a few other Linux but not all of them. Since the data centers are using RHEL more often than another OS, we will probably stay on that platform, but Thank you for the feedback. WE do have a few clients that are using MintLinux as a desktop client. We use Codeweavers (crossover - WINE) application to support any of the Windows terminal emulators that they were using on WIndows). I use MAC as my desktop client, because I did not like the lack of testing that was being done on Microsoft after Windows 7. From a support perspective, everytime Update Tuesday rolled around with Microsoft, I constantly had to walk people through fixing all of their Local Printers. It was exhausting.
Last edit: Simon Sobisch 2024-03-29
Hm, "scrollable" doesn't sound like COBOL85. This "may" be problematic, but for now just keep an eye for that while compiling the whole application once to see if there are general issues.
It worked in Cobol 77.
Vax cobol which was Cobol85.
It uses a few escape sequences to the screen to control it.
I will forward a test program.
Last edit: Simon Sobisch 2024-03-29
We write this to the terminal line, and it sets up the forward scroll region until we send the end.
I attached the 3 programs which are EXTREMELY stripped down versions that just allowed Micro Focus to see 1 simple smallest file we have that when we choose to print the report to the screen by pressing the F4-key, it sets up the HEaders of the report on the first 4 lines of the page, in bold reverse video, then the lines below that become the forward scrolling region, until you press the key to end the output to the screen.
The Cobol switch that they had me set for the RHEL newer version of Visual COBOL 5 was COBCONFIG=/data1/cdms/TLS/rts-config-signal-regime-28
So in all previous versions of COBOL no such COBCONFIG was required, but this version of VISUAL cobol required it in order for the screens to work as they always have. all the strange little glitchy things went away, and the screens worked as they do on my MicroVAX 3500 (which I still have, and it runs, but I only turn it on to debug, as the VAX COBOL had the BEST debugger, much better than MF animator, and easier to use). I have tons of replacement parts for this MV3500 that were given to me by a VAX part reseller, who closed his business and moved to SC, so he gave me power supplies, mother boards, ethernet controller (which only LAT was supported on that version of VMS, Disk controllers, disk drives, TK70 tape drives).
I guess he figured it was cheaper than shipping it to SC.
Last edit: Simon Sobisch 2024-03-29
I guess you don't have a C compiler on that machine - Do you? I'm always interested in checking what works with GnuCOBOL on ancient machines/OS.
In any case if you ever have one of those machines running OpenBSD, then please drop me a note.
I might have the open server 6 development suite.
I will have some time again next week.
If you are talking about the MV 3500,
I know we were able to compile a machine language program back in 1990, but honestly not sure what to look for in Help, I guess just C.
I will let you know.
Last edit: Simon Sobisch 2024-03-29
Is that old of a version of VMS going to have libraries that would work with gnucobol3.2? Would the gmp 6.3 be compatible?
This is before FTP and there is no way to unzip the file on the Vax because tar does not exist.
I can see if backup has some option that will extract a tar file, but I don't think so.
To get it to the Vax, I have to Kermit it down.
I just boot the dinosaur up, only other development lang is MACRO.
no C language, sorry.
Last edit: Simon Sobisch 2024-03-29
I think GMP could work on that, but without a C compiler and a bash that's not useful to check.
If you ever get to the point where you considering putting OpenBSD/Vax 5.8 on it, then we'd have everything - just drop a note (but that's not important).
Don't think the hardware would be supported on that version of the OS. It
is DSSI disk drives, and this is only a 2.2VUP processor speed with .25mb
of ram.
This is what these machines had back in Circa 1988. I joined CDMS with
DuPont in 1989 and this machine was already in place.
No tcpip stack at all. The network card supported LAT only. Vms 5.3 which
they considered open VMS did have Tcpip stack and used ssci disk drives.
This machine truly is an antique. At Dupont we had 20 people logged in and
processing on this machine, developing, testing, transferring patches to
clients.
It does luckily support a 1GB disk drive, but still DSSI.
On Fri, Mar 29, 2024, 12:47 PM Simon Sobisch sf-mensch@users.sourceforge.net wrote:
At least with GC3.2 it doesn't work to have NUL bytes as part of literals (however you got them in) - use hex literals instead:
But then those are too big, so I guess you don't actually have the leading zero-value there...
With MF and GnuCOBOL you can define those as constants (level 78) as well.
Simon, do you have a recommendation for either an Open Source DB or ISAM RTS that can be used. We did not use a DB under MicroFocus, and used MF Isam4 files. I know on the RHEL Visual Cobol version 5+, they supported ISAM8, and that would benefit a few of our clients on some of our files only, but only a few critical History files, most others are just small in comparison. We used separate ISAM files because many of our clients have Multiple TAX EIN numbers with different stores, but we were able to have each company be able to do implied transfer of inventory from one Corp to another. they could see the Inventory of all the Corps. Some of the data files were shared, such as the Inventory files, and each record had a store designation on it. But other files such as Accounts Payables, Accounts Receivable, payroll and General ledger are completely separate, and each company could not not view each others financial information, just inventory. The files were all grouped in different ENV Variables, so we could have the GL located in a completely different FOLDER than the other files, and so on. This gave us great flexibility in the setup of the customers, even though it definitely limited our "google" type of search in a Database. We would need to stick as close to our setup as possible, as we still have 5 clients that have multiple Corporations, and do not want to have to re-invent the wheel so to speak at this point. I would have to include the Company Code as the first field in every single record in the system in a single database, then we are tallking about a bunch of redundant programming that all has to be tested more thoroughly then if we just continued to use separate ISAM files.
I was told by a friend that Berkeley holds the ISAM RTS. I guess I will see what they offer.
Thank you for all of your assistance at this point. I am going to be tied up with Controller work until April 2, as it is accounting Month End, and we do consulting work for a few of our clients, reconciling their bank statements and such as well as our internal books.
Last edit: Simon Sobisch 2024-03-29
I suggest to create a new topic for this (actually for each separate topic), others would also have some recommendations for that (but it sounds likely you're fine with either the BDB or V-ISAM backend [the later currently needs patches to be usable]).
Thanks
Last edit: Simon Sobisch 2024-03-29
Hoping to get this working, and see if I can get off of the Micro Focus Visual COBOL 5.0 but am on support and need to apply the newest updates before I drop support. I can't get a single one of my clients to move to RHEL because the fees to Micro Focus are just too high, the one time for the Runtime system is over 21K, and the yearly support they quoted for this year is 4800, but this goes up on average 10% per year.
Welcome to GnuCOBOL then. My employer moved most of his customers from MF (several versions) to GnuCOBOL 3.x; when starting this conversion "from scratch" I'd suggest to compile your COBOL sources with
-std=mf-strict --debug, this will enable support for non-standard source code and setup some behaviour to match Micro Focus (for example initializing every data without an explicitVALUEclause, including internal index variables and pointers to SPACE), and enable runtime checks to inspect possible issues (if that's too much use at least-fec=boundsas an out-of-bound may produce different results than with MF).This is very helpful information, once I get gnucobol compiled. Thank you.
Last edit: Simon Sobisch 2024-03-28