DESPERATE for: RM/Cobol-85 SCO XENIX 286 runtime.o file

[Bill Irwin]

This  article contains a fairly lengthy explanation of a severe problem I
currently  have.   If you have RM/Cobol-85 for SCO XENIX 286  (NOT  386),
preferably  version  2.02, then this is an appeal to you.  If  you  don't
have  this  product then you probably won't be able to help me,  but  the
article  makes for interesting reading about a comedy of errors, where  I
have been playing the star role.

A  few  weeks  ago  I  posted  a  shorter  version  of  this  request  to
comp.sources.wanted.   Because  some  of the replies I  received  offered
unviable  solutions (basically because of a lack of full understanding of
the  problem),  I have decided to post again to a wider distribution  and
with a complete description of my plight.

We use RM/Cobol-85 2.02 to run our accounting system, MCBA Classic.  When
you  buy  MCBA,  you have the choice of buying  a  "preconfigured"  Cobol
runtime  from  them,  or buying the Cobol separately and  configuring  it
yourself.   Since we were distributing Texas Instruments products at  the
time, our discount on RM/Cobol was better than MCBA offered, so we bought
it separately.

Part  of  the  MCBA installation involves taking an  MCBA  supplied  file
(mcba.o)  and  moving  it into your rmcobol directory.  You then  make  a
couple  of small modifications to Makefile and sub.c, so they know  about
mcba.o.   Then  you  type "make runcobol" and you "configure"  the  Cobol
runtime  to  be  able to work in a special way with the  MCBA  accounting
system.

My  problem  began when I was shipped a 286 version of Cobol  development
rather  than  386.  When I tried to exchange it for a 386 version,  Texas
Instruments  informed  me  that  they had decided not to  market  the  RM
flavour  of  386  Cobol,  but were going exclusively  with  Micro  Focus.
Ryan-McFarlane  wouldn't  exchange  an unused 286 development for  a  386
because  we  had not purchased directly from them.  Bottom line:   either
repurchase  a 386 version or live with the 286 one.  Being a believer  in
286/386  compatibility,  I  have  chosen to try to get  the  286  version
working.   I  know it will work because I have tested the theory with  an
MCBA analyst.  On to the runtime compile process...

The  compile complained that I was mixing 286 and 386 code together  (all
the  .o  cobol  files were 286 and the mcba.o was 386), so  I  moved  the
mcba.c  file  into the directory and began experimenting  with  different
compile  flags.  I finally hit the "-compat" flag which supposedly was to
make  286  binaries.  This compiled the mcba.c into a 286 mcba.o and  the
rest of the compile went fine.

The  resultant "runcobol" that this produced worked fine...for one  user!
As  soon  as  a 2nd user tried to run the accounting they got  a  library
error  and  kicked out.  I was able to have an analyst at MCBA  duplicate
this problem.  The bottom line is:  if you compile a 286 runtime on a 386
system and run on a 386, it only supports one user;  if you compile a 286
runtime  on  a  286  system, then move the runtime to a  386  system,  it
supports multiple users.

Great!   All  I needed now was a 286 system running SCO XENIX so I  could
load  RM/Cobol-85 onto it, recompile the runtime, then move it back to my
386  and  live happily ever after in multiuser land.  I have located  two
people  through  the Net who are running the right environments and  have
offered to compile my runcobol for me.  I have sent them the files needed
for  this  (including  the  mcba.c  file),  but  I  have  lost  the  file
"runtime.o" from my RM distribution.

Since we have changed computers and office location since we received the
RM/Cobol   development,  locating  the   original  diskettes  has  proved
fruitless.   I  did locate the floppy backups we made as well as  a  tape
archive  of the entire MCBA accounting system.  The tape was supposed  to
include the Cobol runtime, but didn't.  The floppies were written in cpio
(because the originals were) and have proved unreadable on our new system
(i386  with SCO XENIX V/386 2.3.2).  After posting an article  describing
my  CPIO problem, all suggestions have failed.  I am about to send a "dd"
image  of the diskettes to someone who has offered to try and extract the
one  file  I need, runtime.o.  Everything that could go wrong,  has  gone
wrong!

I don't know how significant the version of RM is to this runtime.o file.
It  is not even distributed in all versions.  I have a client running  an
Altos  system  and their same RM/Cobol-85 2.02 doesn't have  a  runtime.o
file in the "/usr/rmcobol" directory.  I think it must be specific to the
SCO  XENIX  V platform.  If you have a "runtime.o" file in  your  rmcobol
directory,  I would love to have it.  Following is the output of  running
"runcobol" on the version I am currently running.

-------------------------------------------------------------------------
RM/COBOL-85 Runtime (Ver 2.02.04) for XENIX.  Configured for  016 users.
(c) Copyright 1985, 1986 by Ryan-McFarland Corp.  All rights reserved.
Registration Number:  A890000-00000-16

Usage:   RUNCOBOL name [options] Options:  [-a arguments] [-b buffersize]
[-c  configfile]  [-d] [-i] [-k] [-l libraryname] [-m] [-s switches]  [-t
sortsize] [-x configmod]
-------------------------------------------------------------------------

I  don't think I should have much problem getting what I am looking  for,
with all the thousands of systems on the Net.  Since I am only asking for
one  file which, without the rest of the RM/Cobol-85 system is useless, I
don't anticipate any ethical concerns.

Well,  that's  about the whole sad story.  If you are still reading  this
article  and think you have the runtime.o that I need, please uuencode it
and  mail  it  to  me.  The couple of wrong versions  that  I  previously
received this way came through fine.

I  don't know how companies run a single user DOS accounting system.   It
is  driving me crazy having to take turns and trying to decide who's need
for information is the most critical at any given moment.

Here's hoping that you can help me out.
-- 
Bill Irwin    -   TWG The Westrheim Group     -    Vancouver, BC, Canada
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uunet!van-bc!twg!bill     (604) 431-9600 (voice) |     UNIX Systems
bill at twg.wimsey.bc.ca     (604) 431-4329 (fax)   |     Integration