bill@twg.wimsey.bc.ca (Bill Irwin) (09/04/90)
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@twg.wimsey.bc.ca (604) 431-4329 (fax) | Integration