AND COBOL

2006-03-07 Thread Gabriel
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

2006-03-07 Thread Chris Hill

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

2006-03-07 Thread Greg 'groggy' Lehey
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

2006-03-07 Thread Kris Kennaway
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

2006-03-07 Thread jdow

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

2006-03-07 Thread hackmiester / Hunter Fuller
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

2006-03-07 Thread Bob Hall
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

2006-03-07 Thread fbsd_user
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

2006-03-07 Thread Noel Jones
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

2006-03-07 Thread Kevin Kinsey

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

2004-02-07 Thread Walter C. Pelissero
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

2004-02-04 Thread Walter C. Pelissero
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

2004-02-03 Thread Walter C. Pelissero
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

2004-02-03 Thread Dan Nelson
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

2004-02-03 Thread Walter C. Pelissero
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

2004-02-03 Thread Dan Nelson
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

2004-02-02 Thread Walter C. Pelissero
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

2004-01-30 Thread Walter C. Pelissero
 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

2004-01-29 Thread Walter C. Pelissero
[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

2004-01-29 Thread Jerry McAllister
 
 [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

2004-01-27 Thread Walter C. Pelissero
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

2003-09-20 Thread Todd Stephens
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]