AND COBOL
HI, I WOULD LIKE TO KNOW IF RMCOBOL RUNS IN FREEBSD, THANKS. GABRIEL ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AND COBOL
On Tue, 7 Mar 2006, Gabriel wrote: HI, I WOULD LIKE TO KNOW IF RMCOBOL RUNS IN FREEBSD, THANKS. GABRIEL DON'T KNOW ABOUT ANY RMCOBOL, BUT THERE EXISTS open-cobol AND tinycobol UNDER /usr/ports/lang. PS - NO NEED TO SHOUT, BUT I TRY TO ANSWER IN THE LANGUAGE IN WHICH I WAS ADDRESSED, WHERE POSSIBLE. hth. -- Chris Hill [EMAIL PROTECTED] ** [ Busy Expunging | ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AND COBOL
On Tuesday, 7 March 2006 at 18:47:25 -0500, Chris Hill wrote: On Tue, 7 Mar 2006, Gabriel wrote: HI, I WOULD LIKE TO KNOW IF RMCOBOL RUNS IN FREEBSD, THANKS. GABRIEL DON'T KNOW ABOUT ANY RMCOBOL, BUT THERE EXISTS open-cobol AND tinycobol UNDER /usr/ports/lang. PS - NO NEED TO SHOUT, BUT I TRY TO ANSWER IN THE LANGUAGE IN WHICH I WAS ADDRESSED, WHERE POSSIBLE. Modern COBOL dialects understand lower case. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers. pgpqi8ZlMv8bs.pgp Description: PGP signature
Re: AND COBOL
On Tue, Mar 07, 2006 at 06:47:25PM -0500, Chris Hill wrote: On Tue, 7 Mar 2006, Gabriel wrote: HI, I WOULD LIKE TO KNOW IF RMCOBOL RUNS IN FREEBSD, THANKS. GABRIEL DON'T KNOW ABOUT ANY RMCOBOL, BUT THERE EXISTS open-cobol AND tinycobol UNDER /usr/ports/lang. PS - NO NEED TO SHOUT, BUT I TRY TO ANSWER IN THE LANGUAGE IN WHICH I WAS ADDRESSED, WHERE POSSIBLE. Give the poor guy a break; he's a COBOL programmer, so he's used to thinking and typing in all-caps :-) Kris pgpPSxVGBxd7K.pgp Description: PGP signature
Re: AND COBOL
From: Kris Kennaway [EMAIL PROTECTED] Give the poor guy a break; he's a COBOL programmer, so he's used to thinking and typing in all-caps :-) And just think, both COBOL and AOL end in OL. I wonder if there is a relationship? Exit stage left FAST--{O,o} ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AND COBOL
On Tuesday 07 March 2006 15:56, Gabriel wrote: HI, I WOULD LIKE TO KNOW IF RMCOBOL RUNS IN FREEBSD, THANKS. HI, I WOULD LIKE TO KNOW IF YOU COULD POSSIBLY TURN OFF YOUR CAPS LOCK KEY. IT MAKES IT SEEM LIKE YOU ARE SCREAMING AND NO ONE WANTS TO ANSWER A QUESTION FOR SOMEONE WHO RANTS AND RAVES. HOPE THAT'S NOT TOO MUCH TROUBLE, MATE. KEEP THAT IN THE BACK OF YOUR MIND FOR FUTURE REFERENCE. :-) GABRIEL ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- --hackmiester Walk a mile in my shoes and you will be a mile away in a new pair of shoes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD/yYl3ApzN91C7BcRAoVVAJ97uhjh30nQ4hd9bQ90gJqiwsLEfgCeKSrg bVfqEeJ09WhO6Y51WHEHb6o= =VTUd -END PGP SIGNATURE- -BEGIN GEEK CODE BLOCK- Version: Geek Code v3.1 (PHP) GCS/CM/E/IT d-@ s: a- C++$ UBLS*$ P+ L+++$ E- W++$ !N-- !o+ K-- !w-- !O- M++$ V-- PS@ PE@ Y--? PGP++ !t--- 5--? !X-- !R-- tv-- b+ DI++ D++ G+ e h r+++ z --END GEEK CODE BLOCK-- Quick contact info: Work: [EMAIL PROTECTED] Personal: [EMAIL PROTECTED] Large files/spam: [EMAIL PROTECTED] GTalk:hackmiester/AIM:hackmiester1337/Y!:hackm1ester/IRC:irc.7sinz.net/7sinz pgphgVSldL5t1.pgp Description: PGP signature
Re: AND COBOL
On Tue, Mar 07, 2006 at 04:33:05PM -0800, jdow wrote: From: Kris Kennaway [EMAIL PROTECTED] Give the poor guy a break; he's a COBOL programmer, so he's used to thinking and typing in all-caps :-) And just think, both COBOL and AOL end in OL. I wonder if there is a relationship? LOL? Or maybe I've ingested too much PHENOL and ETHENOL, or been exposed to SOL without my PARASOL, or inhaled too much AEROSOL. I'm like TOPOL up on the roof and my mind's gone AWOL out in the TYROL with a MONGOL. I'll take some CALCIFEROL and call INTERPOL. Ja, jeg sitter på en STOL og synes det var litt FRIVOL. I couldn't figure out how to fit ALGOL in there. Ain't life a PISTOL? I'm sorry. What was the question? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: AND COBOL
I have used this in the past. It's Cobol script for building web sites that r/w to flat files and mysql database. Works much Like php in the way it interfaces with native html code. Their website is built using it as a demo of how fast it runs. Can download version with mysql for testing. http://www.cobolscript.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Sent: Tuesday, March 07, 2006 4:57 PM To: freebsd-questions@FreeBSD.org Subject: AND COBOL HI, I WOULD LIKE TO KNOW IF RMCOBOL RUNS IN FREEBSD, THANKS. GABRIEL ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AND COBOL
On 3/7/06, Bob Hall [EMAIL PROTECTED] wrote: ... I couldn't figure out how to fit ALGOL in there. Ain't life a PISTOL? After that, I need a Tylenol... -- Noel Jones ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AND COBOL
Noel Jones wrote: On 3/7/06, Bob Hall [EMAIL PROTECTED] wrote: ... I couldn't figure out how to fit ALGOL in there. Ain't life a PISTOL? After that, I need a Tylenol... -- Noel Jones ... because the whole thing sounded like folderol. ;-) Nonetheless, I'm not sure if I have yet laughed so hard today, and said day is almost done. TY, Bob. Kevin Kinsey -- The most disagreeable thing that your worst enemy says to your face does not approach what your best friends say behind your back. -- Alfred De Musset ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: In the last episode (Feb 04), Walter C. Pelissero said: A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this new flag? Linux IPC_64 support was added to the 5.x tree over a year ago but never got merged back to 4.x. It looks like there are different structures for the IPC_64 case, so just stripping the IPC_64 bit won't work. Take a look at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ipc.c.diff?r1=1.30r2=1.31f=h - it was a mega-commit, so there's more than just the IPC_64 stuff, but it's pretty easy to pick out the right bits (basically anything with a 64 in it :). I've been spending the last two days upgrading to 5.2.1.-RC. Well, beside the predictable cultural impact (a few things have changed from 4.9), the first impression was that the Linux emulator worked much better, in fact it runs Acu Cobol 6.0 for Linux flawlessly! There are still some minor details that don't work as expected (ACPI-S1 and cardbus) and some that stopped working (snd_pcm). These will probably require delving in the documentation or possibly waiting for 5.3. But devfs and devd alone are worth upgrading. Congratulations guys. You've done an awesome job! -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: In the last episode (Feb 04), Walter C. Pelissero said: A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this new flag? Linux IPC_64 support was added to the 5.x tree over a year ago but never got merged back to 4.x. Oops. Don't tell me Iv'e beeing trying to fix a bug that wasn't there. I'll try in the next days to install 5.2 at least on my laptop and see if it helps. (It's anyhow something that was already on my agenda.) -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
I tried linux_kdump (from ports) and things seem to clarify a bit. I concentrated on acushare, which is the daemon that supervises inter-process locking (locking on file access) and licence verification. Whereas acushare seems to start properly, an attempt to kill it through the recommended means (not with kill(1)), yields an IPC error. On Linux strace on the daemon process shows: msgrcv(256, {1, \254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...}, 100, 1, MSG_NOERROR) = 12 getpid()= 376 getuid32() = -1 ENOSYS (Function not implemented) msgctl(256, IPC_STAT, 0xba54) = 0 msgsnd(256, {428, x\1\0\0\6\0\0\0\6\0\0\0}, 12, 0) = 0 That is, msgrcv returns a 12 bytes long message and the daemon answers. On FreeBSD, on the other hand: 75838 acushare RET linux_ipc 12/0xc 75838 acushare CALL linux_getpid 75838 acushare RET linux_getpid 75838/0x1283e 75838 acushare CALL linux_ipc(0xe,0x5,0x102,0,0xbfbff444,0) 75838 acushare RET linux_ipc -1 errno 22 Invalid argument 75838 acushare CALL linux_time(0xbfbff49c) 75838 acushare RET linux_time 1075830865/0x401fe051 75838 acushare CALL write(0,0x2806f000,0x4a) 75838 acushare GIO fd 0 wrote 74 bytes acushare: 2004-02-03 18:54:25: Error replying to test message from run\ cbl That is, linux_ipc (possibly a catch-all name for the Linux IPC functions family), returns a 12 bytes long message, but when it is supposed to do the msgctl it fails miserably with an errno 22. I couldn't make sense out of the six arguments to linux_ipc shown in the kdump. Does anyone know how to interprete them? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
In the last episode (Feb 03), Walter C. Pelissero said: I tried linux_kdump (from ports) and things seem to clarify a bit. I concentrated on acushare, which is the daemon that supervises inter-process locking (locking on file access) and licence verification. Whereas acushare seems to start properly, an attempt to kill it through the recommended means (not with kill(1)), yields an IPC error. On Linux strace on the daemon process shows: msgrcv(256, {1, \254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...}, 100, 1, MSG_NOERROR) = 12 getpid()= 376 getuid32() = -1 ENOSYS (Function not implemented) msgctl(256, IPC_STAT, 0xba54) = 0 msgsnd(256, {428, x\1\0\0\6\0\0\0\6\0\0\0}, 12, 0) = 0 That is, msgrcv returns a 12 bytes long message and the daemon answers. On FreeBSD, on the other hand: 75838 acushare RET linux_ipc 12/0xc 75838 acushare CALL linux_getpid 75838 acushare RET linux_getpid 75838/0x1283e 75838 acushare CALL linux_ipc(0xe,0x5,0x102,0,0xbfbff444,0) 75838 acushare RET linux_ipc -1 errno 22 Invalid argument 75838 acushare CALL linux_time(0xbfbff49c) 75838 acushare RET linux_time 1075830865/0x401fe051 75838 acushare CALL write(0,0x2806f000,0x4a) 75838 acushare GIO fd 0 wrote 74 bytes acushare: 2004-02-03 18:54:25: Error replying to test message from run\ cbl That is, linux_ipc (possibly a catch-all name for the Linux IPC functions family), returns a 12 bytes long message, but when it is supposed to do the msgctl it fails miserably with an errno 22. I couldn't make sense out of the six arguments to linux_ipc shown in the kdump. Does anyone know how to interprete them? linux_ipc is emulated in /sys/machine/linux/linux_machdep.c, and in linux.h: #define LINUX_MSGCTL14 so the switch() in linux_ipc ends up calling linux_msgctl in /sys/compat/linux/linux_ipc.c. Do you have SYSV message queues enabled in your kernel? Stick options SYSVMSG in your config file and rebuild, or kldload sysvmsg if you have the module. If you do have sysvmsg loaded, you may have to start adding printfs in linux_msgctl() to trace which call is failing and why. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: If you do have sysvmsg loaded, you may have to start adding printfs in linux_msgctl() to trace which call is failing and why. Thanks. With your hints I made an interesting discovery that allowed me to improve the situation dramatically. In Linux's /usr/include/linux/ipc.h there is an interesting comment: /* * Version flags for semctl, msgctl, and shmctl commands * These are passed as bitflags or-ed with the actual command */ #define IPC_OLD 0 /* Old version (no 32-bit UID support on many architectures) */ #define IPC_64 0x0100 /* New version (support 32-bit UIDs, bigger message sizes, etc. */ In fact linux_msgctl receives a command 0x102 instead of 2. Although the following patch fixes the problem related to msgctl, I'm not quite sure it's enough to say that Acu Cobol runs perfectly on FreeBSD. Actually I've got the feeling msgrcv still doesn't work as expected, but I might be wrong. I'll probably reach a certain confidence in the following days. A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this new flag? Cheers, -- walter pelissero http://www.pelissero.de Index: compat/linux/linux_ipc.c === RCS file: /usr/home/src.cvs/src/sys/compat/linux/linux_ipc.c,v retrieving revision 1.17.2.3 diff -w -u -r1.17.2.3 linux_ipc.c --- compat/linux/linux_ipc.c5 Nov 2001 19:08:22 - 1.17.2.3 +++ compat/linux/linux_ipc.c4 Feb 2004 00:33:56 - @@ -233,7 +233,7 @@ bsd_args.semnum = args-semnum; bsd_args.arg = unptr; - switch (args-cmd) { + switch (args-cmd 0xff) { /* mask off the IPC_64 flag */ case LINUX_IPC_RMID: bsd_args.cmd = IPC_RMID; break; @@ -362,7 +362,7 @@ int error; bsd_args.msqid = args-msqid; -bsd_args.cmd = args-cmd; +bsd_args.cmd = args-cmd 0xff; /* mask off the IPC_64 flag */ bsd_args.buf = (struct msqid_ds *)args-buf; error = msgctl(p, bsd_args); return ((args-cmd == LINUX_IPC_RMID error == EINVAL) ? 0 : error); @@ -429,7 +429,7 @@ int error; caddr_t sg = stackgap_init(); -switch (args-cmd) { +switch (args-cmd 0xff) { /* mask off the IPC_64 flag */ case LINUX_IPC_STAT: bsd_args.shmid = args-shmid; bsd_args.cmd = IPC_STAT; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
In the last episode (Feb 04), Walter C. Pelissero said: A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this new flag? Linux IPC_64 support was added to the 5.x tree over a year ago but never got merged back to 4.x. It looks like there are different structures for the IPC_64 case, so just stripping the IPC_64 bit won't work. Take a look at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ipc.c.diff?r1=1.30r2=1.31f=h - it was a mega-commit, so there's more than just the IPC_64 stuff, but it's pretty easy to pick out the right bits (basically anything with a 64 in it :). -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
I realised that the ktrace log was rubbish; most of the syscalls names were not properly mapped. I tried to track down the exact spot were the Linux executable gets the SEGV signal, running strace on a Debian system and comparing the values passed to the system calls. Here is an extract: rt_sigaction(SIGTSTP, {0x8072ce0, [TSTP], SA_RESTART|0x400}, {SIG_IGN}, 8) = 0 rt_sigaction(SIGHUP, {0x8072ca0, [HUP], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8072bf0, [TERM], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGFPE, {0x804f910, [FPE], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGBUS, {0x804f940, [BUS], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSEGV, {0x804f910, [SEGV], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, {0x804f910, [ILL], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSYS, {0x804f910, [SYS], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0 brk(0x81c2000) = 0x81c2000 ^^--- SEGV on FreeBSD! brk(0x81c3000) = 0x81c3000 brk(0x81c4000) = 0x81c4000 brk(0x81c5000) = 0x81c5000 brk(0x81c6000) = 0x81c6000 So it was rt_sigaction() and not pwrite(); brk() and not ktrace(). Does this shed a new light? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
runcbl NAMI /compat/linux/dev 459 runcbl RET setrlimit 0 459 runcbl CALL open(0x282df2c5,0x18800,0) 459 runcbl NAMI /compat/linux/dev 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev 459 runcbl RET open 3 459 runcbl CALL mmap(0x3,0xbfbfe128,0x282e9aa0) 459 runcbl RET mmap 0 459 runcbl CALL semget(0x3,0x2,0x1) 459 runcbl RET semget 0 459 runcbl CALL __semctl(0x3,0x28303e68,0x1000) 459 runcbl RET __semctl 4084/0xff4 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/. 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/. 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/.. 459 runcbl NAMI /compat/linux 459 runcbl NAMI /dev/.. 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/.devfsd 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/.devfsd 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/cpu 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/cpu 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/shm 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/shm 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/misc 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/misc 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/mem 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/mem 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/kmem 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/kmem 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/null 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/null 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/port 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/port 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/zero 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/zero 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/full 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/full 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/random 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/random 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/urandom 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/urandom 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/fb 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/fb 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/tty 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/tty 459 runcbl RET setrlimit 0 459 runcbl CALL setrlimit(0x28302d58,0xbfbfe1d8,0x282e9aa0) 459 runcbl NAMI /compat/linux/dev/console 459 runcbl NAMI /compat/linux 459 runcbl NAMI /compat/linux/dev/console 459 runcbl RET setrlimit 0 459 runcbl CALL close(0x3) 459 runcbl RET close 0 459 runcbl CALL ioctl(0x2,0x5401 ,0xbfbfe304) 459 runcbl RET ioctl 0 459 runcbl CALL exit(0xff) The SIGSEGV happens at about half way. But, there probably are not many Cobol users on this list, so you need to give information that clearly establishes it as a problem with system libraries or whatever so people will feel in familiar territory. I'm not sure you can feel in familiar territory if you haven't seen that program before. Anyhow I'm not able to tell where the problem is (emulation or libraries), but using two different sets of Linux libraries yields
Acu Cobol 6.0 for Linux
[apparently the first message didn't get through; this is a repost] Did enybody try to run AcuCobol 6.0 for Linux on FreeBSD's linulator? I tried a couple of times (with old Debian libraries and more recently Gentoo libraries) but runcbl keeps on getting a SIGSEGV right away. ccbl (the compiler) seems to work, though. Any clue? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
[apparently the first message didn't get through; this is a repost] Your previous post got through. Probably the presumed answer is that no-one who saw it has tried this or feels competent to respond. You might some response if you could find a way to break the problem down a little more and give a little more detail. But, there probably are not many Cobol users on this list, so you need to give information that clearly establishes it as a problem with system libraries or whatever so people will feel in familiar territory. Someone might know another place (list) to ask as well. jerry Did enybody try to run AcuCobol 6.0 for Linux on FreeBSD's linulator? I tried a couple of times (with old Debian libraries and more recently Gentoo libraries) but runcbl keeps on getting a SIGSEGV right away. ccbl (the compiler) seems to work, though. Any clue? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Acu Cobol 6.0 for Linux
Did enybody try to run AcuCobol 6.0 for Linux on FreeBSD's linulator? I tried a couple of times (with old Debian libraries and more recent Gentoo libraries) but runcbl keeps on getting a SIGSEGV right away. ccbl (the compiler) seems to work, though. Any clue? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Question on which port is better for COBOL
I have a need to do some COBOL programming at home where I run FreeBSD 4.8. I see the ports collection has two options for COBOL compilers: tinyCobol and openCobol. The tinyCobol port has a higher version number than openCobol, leading me to believe it is more mature, but this is not always the case. Has anyone any experience with either (or preferably both)? Which one is preferred by users out there? Thank you for any assistance. -- Todd Stephens ICQ# 3150790 A witty saying proves nothing. -Voltaire ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]