big Unix file to dos
Duilio Foschi
What I'd like to do is to split the big file into N chunks of 1.44 MB
each, but I cannot understand how to do it.
Split and Csplit looked promising, but I cannot understand how to use
them.
Any hint ?
Thank you
Duilio Foschi
rollee
Can you connect the two systems together? I mean, can they talk to one
another? If so, then you could do a file transfer via ftp, which would
be easiest.
Jean-Pierre Radley
| how can I copy a big Unix file (>5MB) into a PC running DOS ?
|
| What I'd like to do is to split the big file into N chunks of 1.44 MB
| each, but I cannot understand how to do it.
|
| Split and Csplit looked promising, but I cannot understand how to use
| them.
|
split -n 1440k filename
--
JP
Matt Schalit
The fellow said he was using DOS, so the assumption is that
he has no networking. Using netware drivers and a nic, he
could get the DOS box on the network. But he'd still need
an ftp client of something to get the files.
I think kermit might be a solution for connecting and
communicating via a null modem cable or something, but
the file is small, so he's probably done it already :)
Matt
Karel Adams
"Duilio Foschi" <ded...@yifan.net> schreef in bericht news:3c0e2f9f...@news.libero.it...
If you could get an MSDOS version of tar,
it would be easy to tar the file onto several floppies
then the DOS tar client could read them.
I've never searched for such a program
but feel confident it must exist somewhere.
> Thank you
Prego!
> Duilio Foschi
KA
fred smith
> how can I copy a big Unix file (>5MB) into a PC running DOS ?
> What I'd like to do is to split the big file into N chunks of 1.44 MB
> each, but I cannot understand how to do it.
> Split and Csplit looked promising, but I cannot understand how to use
> them.
it may depend on which particular flavor of Unix you have. But on
my Linux box, I do it like this:
split -b1440000 filename
which produces one or more files beginning with 'xaa', then 'xab' and so
forth up through 'xzz', however many are required.
Fred
--
---- Fred Smith -- fre...@fcshome.stoneham.ma.us -----------------------------
But God demonstrates his own love for us in this:
While we were still sinners,
Christ died for us.
------------------------------- Romans 5:8 (niv) ------------------------------
Robert Carnegie
Why this and not (on OpenServer 5 or I /think/ UnixWare)
split -b 1423k filename
# just do it in an empty directory and pick up pieces xaa, xab, xac, ...
DOS "chkdsk a:" reports 1,457,664 bytes total disk space (~1423 kbytes,
k being 1024)
The supplied 'split' on SCO UNIX 3.2v4.2 didn't advertise splitting
on bytes, only on lines in text files. You could obtain an MS-DOS
uudecode tool, uuencode the big file into text, and split that -
"split -23500" is about right for 62 characters per text line.
I think the recipe for that system is then
cd /tmp
mkdir uuencode
uuencode /where/ever/bigfile bigcopy >bigcopy.u
split -23500 bigcopy.u
# copy files xaa, xab, ..., then on DOS -
C:\>copy /b xaa+xab+xac+xad+... bigcopy.u
(Then use the hypothetical MS-DOS uudecode tool)
Without uudecode, it is also feasible to feed the output of UNIX "hd"
into MS-DOS "debug" (with some scripted editing on UNIX first),
to recreate the original data at least in 64 kbyte pieces.
Rob S
-> split -n 1440k filename
-
didn't see the original post, but if it's a text file you may get the entire
thing onto a floppy if you get hold of info-zip's zip for openserver.
This can be PKunzipped or Infounzipped or even Winunzipped on your PC.....
rgds
-Rob
robatwork at mail dot com
Jean-Pierre Radley
|
| -> split -n 1440k filename
| -
| didn't see the original post, but if it's a text file you may get the entire
| thing onto a floppy if you get hold of info-zip's zip for openserver.
|
| This can be PKunzipped or Infounzipped or even Winunzipped on your PC.....
Why in the world would you use zip instead of gzip, or, still better,
bzip2?
--
JP
loki28
the kernal and mount it as a DOS filesystem.
"Duilio Foschi" <ded...@yifan.net> wrote in message
news:3c0e2f9f...@news.libero.it...
Rob S
-
-Why in the world would you use zip instead of gzip, or, still better,
-bzip2?
It works.
It's compatible with PKZIP on DOS
Ditto Winzip
Freeware
Has every option I need (other than spanning disks)
Openserver ready-compiled versions are easily available on the 'net
It would do what the original poster asked
Do the other progs you mention fulfill all these criteria and do spanning JP?
regards
Jeff Hyman
If you need to span disks, try DOS-TAR. Has compression and
bit-level verification too.
Jeff Hyman
Robert Carnegie
This one? http://www.cactus.com/products/cactus/dostar.html
Interesting and potentially useful, though you can't but mock this:
"Data compression guarantees to at least double the capacity of any
seeking device such as floppy or a named file on your hard disk."
And perhaps too much effort if you only have to do it once -
although if the file is commercially important then getting a
quick solution is better than getting a cheap one.
Of course there are many dozens of disk spanners for DOS or Windows,
although I got stuck when looking for one particular feature for
archiving - _redundant_ disk spanning. [snips rambling about CRCs
across volumes to create a checksum disk, crypto one-time-pad tools]
And come to think, any DOS tool which can grab images of diskettes
would copy the data off basic UNIX tar disks, with only the 512 bytes
header as added nuisance (plus if you're not using tar then you don't
know where end-of-file is). Windows InfoZip, for one, seems happy to
ignore a tar header when reading a "tar cvAf" archive, and get to the
zipped data inside; so apparently you could use any UNIX zip tool,
"tar cvA6" to write disks, any DOS/Windows diskette imager, the DOS
"copy" command to reassemble pieces, and any DOS/Windows unzipper,
to transfer data.
As far as I know, this wouldn't be the same as PK Zip disk spanning;
I believe that that uses regular files on MS-DOS formatted diskettes,
and tar of course just dumps data onto the medium from sector zero on
(well, data from sector one).
I haven't taken the trouble to get acquainted with gzip and bzip2
beyond knowing the names - for managing our fleet of servers, and given
some logistical and contractual issues, neither is a good fit for us -
and when I Googled them I glimpsed the word "incompatible" in relevant
texts, which, while not absolute, suggested "more trouble than it's
worth for a one-off job by a novice - don't bring it up". So I stopped
at suggesting uuencode, ASCII split, and doscp as my all-SCO solution.
Jeff Hyman
I watched this thread for some time before making a comment.
Bottom line is DOS-TAR _does_ span floppies.
If compressing Ascii text will reduce number of floppies by 80+ %.
It's also compatible with all the super-tars UNIX <--> DOS.
It's no big deal as I was just making a suggestion and not
trying to make a sales pitch. Any solution that is free on the
web will usually get my vote too.
- Jeff Hyman
Bill Vermillion
<sco...@cactus.com> wrote:
>Recently, Robert Carnegie wrote:
>> Jeff Hyman <sco...@cactus.com> wrote in message
>> news:<m16DnKt...@cactus.com>...
>> > If you need to span disks, try DOS-TAR. Has compression and
>> > bit-level verification too.
>> This one? http://www.cactus.com/products/cactus/dostar.html
>> Interesting and potentially useful, though you can't but mock this:
>> "Data compression guarantees to at least double the capacity of any
>> seeking device such as floppy or a named file on your hard disk."
>> And perhaps too much effort if you only have to do it once -
>> although if the file is commercially important then getting a
>> quick solution is better than getting a cheap one.
....
>I watched this thread for some time before making a comment.
>Bottom line is DOS-TAR _does_ span floppies.
>If compressing Ascii text will reduce number of floppies by 80+ %.
>It's also compatible with all the super-tars UNIX <--> DOS.
>It's no big deal as I was just making a suggestion and not
>trying to make a sales pitch. Any solution that is free on the
>web will usually get my vote too.
I think my DOS-TAR is older than yours :-) The tar.exe has
a date of June 16,1991 [just recently retrevied it from a Unixware
1.3 backup getting ready to move tapes to CD]. I think Windows
1.4 was out about then or maybe 2.x
From the descritpion file:
==================================================
This is an MS-DOS combined implementation of the un*x tar(1) and
compress(1) programs. It creates P1003 "Unix Standard" [draft 6]
tapes by default, and can optionaly compress and decompress files
compatible with the un*x compress(1) program using up to 16 bits
compression without intermediate files. ...
....
The tar engine of the program is pdtar written by John Gilmore
(g...@toad.com) and was only slightly modified to fix some bugs
and read / write compressed files on MS-DOS. In the README
file of the pdtar distribution is the following list of thanks:
This program is much better than it started, due to
the effort and care put in by Henry Spencer, Fred Fish,
Ian Darwin, Geoff Collyer, Stan Barber, Guy Harris,
Dave Brower, Richard Todd, Michael Rendell, Stu Heiss,
and Rich $alz. Thank you, one and all.
....
The compress program was written and improved by Spencer W. Thomas,
Jim McKie, Steve Davies, Ken Turkowski, James A. Woods and Joe Orost.
I would like to thank all the people above for making this
program possible.
Diomidis D. Spinellis d...@doc.ic.ac.uk
1 Myrsinis Str.
GR-145 62 Kifissia
GREECE
==================================================
Don't some of those names ring bells from past glory days of the
net!
This helps to prove that whatever you post on usenet never goes
away. Google just announced archives going back further than
before and I found an 1988 posting of mine - and a 1985 phone
reference to the phone number I'm posting form for my old BBS from
1981. [this is a combo DLS/modem line now].
With the latest drive/media developments it looks like we are only
18 months away from 600GB 3.5" x 1" drives. We are going to run
of things to store at this rate :-)
Robert Carnegie
> On Wed, 05 Dec 2001 08:50:48 -0800, rollee <rol...@genesis1st.com> wrote:
>
> >Duilio Foschi wrote:
> >
> >> how can I copy a big Unix file (>5MB) into a PC running DOS ? What I'd
> >> like to do is to split the big file into N chunks of 1.44 MB each, but
> >> I cannot understand how to do it. Split and Csplit looked promising,
> >> but I cannot understand how to use them.
> >> Any hint ?
> >> Thank you
> >> Duilio Foschi
> >
> >Can you connect the two systems together? I mean, can they talk to one
> >another? If so, then you could do a file transfer via ftp, which would
> >be easiest.
>
>
> The fellow said he was using DOS, so the assumption is that
> he has no networking.
Duilio, is the UNIX your Xenix system that you were working on?
Gale Gorman
Is there a way to send them over a serial cable? The two machines are side
by side.
I have SCSI in both if that is an option. The old box has an antique
Archive Viper 2150 tape drive. Don't know how I would get Windows to
recognize it if I moved it.
Dread the thought of zipping the files to floppies.
Thanks,
Gale
rollee
Yes, there are several ways to do this via serial cable. On the windoze pc, do
you have any kind of terminal emulator running that enables you to connect to
the xenix system and log in? If so, then it that program probably comes with
wome type of ftp software that you loaded on both systems. If not, then I
suggest you get Kermit for both xenix and dos/windoze. Then, using Kermit you
can easily transfer the files from xenix to windoze. I have done this many
times using kermit on a xenix system. Good luck.
--Jim
Ronald J Marchand
news:3C1A2539...@genesis1st.com...
You can use an emulator such as Anzio Lite with Kermit or Zmodem. But don't
forget that Windoze is case Ignorant.
Ron
James R. Sullivan
There are PC-based UUCP programs available (go search the web).
Combine that with the Xenix uucp and a simple serial cable
and you'll be transferring in no time!
--
Jim Sullivan
Director, North American System Engineers
Tarantella! http://www.tarantella.com
831 427 7384 - j...@tarantella.com
Gale Gorman
Thanks
Jean-Pierre Radley
| That may be my simplest solution. May take awhile to transfer 200Mb.
Gale, I for one cannot guess the antecedent of "That". What are you
talking about?
--
JP
Bill Vermillion
Since the xenitec mail posting break the pointer links in my readers
I don't know even know what article yours references, let along
finding the links to the first. However regarding the comment
that transfering 200Mb may take a long time, I've used kermit for
salvaging a system that was barely stable enough to keep itself up
and running - and even though the transfer took the better part of a
weekend it was totally hands off.
Gale Gorman
Thanks,
Gale
"Bill Vermillion" <b...@wjv.com> wrote in message news:GoD17...@wjv.com...
Frank da Cruz
: In article <20011215000...@jpradley.jpr.com>,
And not necessarily slow, within the limits of the processor and serial
port or network speed. I assume we're talking about Xenix? If it's
Xenix 2.3.4, there is -- would you believe -- a brand-new release of
C-Kermit for it (as there is is for SCO UNIX 3.2v4.2, OSR5, Unixware,
and Open Unix 8). It's not fully packaged yet, but the software itself
is ready:
http://www.columbia.edu/kermit/ck80binaries.html#sco
Incidentally, scenarios like this one where interruption is a possibility,
Kermit can recover gracefully if you have real and relatively up-to-date
Kermit versions on both ends, which means you'll need Kermit 95 for the
Windows end:
http://www.columbia.edu/kermit/k95.html
Then you can resume interrupted transfers from the point of failure.
This applies to the entire file group as well as to an individual file
(with some caveats).
- Frank
Bill Vermillion
Frank da Cruz <f...@columbia.edu> wrote:
>In article <GoD17...@wjv.com>, Bill Vermillion <b...@wjv.com> wrote:
>: In article <20011215000...@jpradley.jpr.com>,
>: Jean-Pierre Radley <j...@jpr.com> wrote:
>: >Gale Gorman propounded (on Fri, Dec 14, 2001 at 11:28:54PM +0000):
>: >| That may be my simplest solution. May take awhile to transfer 200Mb.
>:
>: >Gale, I for one cannot guess the antecedent of "That". What are you
>: >talking about?
>:
>: Since the xenitec mail posting break the pointer links in my readers
>: I don't know even know what article yours references, let along
>: finding the links to the first. However regarding the comment
>: that transfering 200Mb may take a long time, I've used kermit for
>: salvaging a system that was barely stable enough to keep itself up
>: and running - and even though the transfer took the better part of a
>: weekend it was totally hands off.
>And not necessarily slow, within the limits of the processor and serial
>port or network speed. I assume we're talking about Xenix? If it's
>Xenix 2.3.4, there is -- would you believe -- a brand-new release of
>C-Kermit for it (as there is is for SCO UNIX 3.2v4.2, OSR5, Unixware,
>and Open Unix 8). It's not fully packaged yet, but the software itself
>is ready:
I had done it on Xenix and later on Esix. I've also used it for
transfers from RS16's running Xenix too. I like the ability to
turn it loose and come back when it's done and know the transfer is
correct.
I've mentioned this before but a long time ago when the source for
Kermit was only about 30K and I had a system with NO communcations
ability - just 8 serial ports and a printer [Onyx on a Z8000], that
I put the source on a RadioShack model 4 with a transfer program
that permitted a line at a time transfer with a pause at the end of
each line, I opened up vi in the Onyx, and then transmitted into
vi, then saved it and compiled it.
I had to use line at a time because without vi would die - and not
gracefully.
It's a good tool to keep around. And thanks for all the years of
work you've put into it. Must be close to 20 now? Is that close
to being correct? Yours is the name I've always associated with
it since about 1983/4.
Bill
Frank da Cruz
: [kermit]'s a good tool to keep around. And thanks for all the years of
: work you've put into it. Must be close to 20 now? Is that close
: to being correct? Yours is the name I've always associated with
: it since about 1983/4.
:
The Kermit protocol was designed and the first software written just over
20 years ago, yipes! This was for CP/M, DEC-20, IBM mainframe, and the
then-brand-new IBM PC.
C-Kermit first appeared in 1985. Prior to that there was a very small
bare-bones (and sloooooow) Unix-only C version, which is probably the
one you were talking about. Today, there is also a very small Unix-only
C version, but it's fast:
http://www.columbia.edu/kermit/gkermit.html
C-Kermit itself is now a do-everything tool that is no longer just the
low-tech solution to problems that can't be solved any other way. I
won't bother to recite the long list of buzzwords, capabilities, and
features; they're all at the website:
http://www.columbia.edu/kermit/ckermit.html
- Frank
Bill Vermillion
>: [kermit]'s a good tool to keep around. And thanks for all the years of
>: work you've put into it. Must be close to 20 now? Is that close
>: to being correct? Yours is the name I've always associated with
>: it since about 1983/4.
>The Kermit protocol was designed and the first software written just over
>20 years ago, yipes! This was for CP/M, DEC-20, IBM mainframe, and the
>then-brand-new IBM PC.
So have you been involved with it from the first?
>C-Kermit first appeared in 1985. Prior to that there was a very
>small bare-bones (and sloooooow) Unix-only C version, which is
>probably the one you were talking about. Today, there is also a
>very small Unix-only C version, but it's fast:
That bare-bones was a life-saver for me though. And I've had the
C-Kermit also. The one on my BSD machine is only 1,430,000 LARGER
than my first one :-)
> http://www.columbia.edu/kermit/gkermit.html
That one comes in at 31K on this system. Nice to see small
programs. I wonder what it's size would be static? Guess I'll
have to try that someday.
Bill
Frank da Cruz
: In article <9vgjpr$8j2$1...@watsol.cc.columbia.edu>,: >The Kermit protocol was designed and the first software written just over
: >20 years ago, yipes! This was for CP/M, DEC-20, IBM mainframe, and the
: >then-brand-new IBM PC.
:
: So have you been involved with it from the first?
Yup. It was my group who designed the protocol and wrote the first
implementations in 1980-81. Plus I'm the one who stuck with it since
then.
: >C-Kermit first appeared in 1985. Prior to that there was a very
: >small bare-bones (and sloooooow) Unix-only C version, which is
: >probably the one you were talking about.
: That bare-bones was a life-saver for me though. And I've had the
: C-Kermit also. The one on my BSD machine is only 1,430,000 LARGER
: than my first one :-)
:
It's the old story. Application appears, people use it, people want
more features, new features are added, repeat for many years, and then
those same people start longing for the "lean and mean" days again.
Hence:
: > Today, there is also a very small Unix-only C version, but it's fast:
: > http://www.columbia.edu/kermit/gkermit.html
:
: That one comes in at 31K on this system. Nice to see small
: programs. I wonder what it's size would be static? Guess I'll
: have to try that someday.
:
In case anyone else is reading this thread: G-Kermit has been built
for Xenix 2.3.4, but who among you can build it for earlier Xenix
versions? Xenix/286? SCO UNIX versions prior to 3.2v4.2? If you'd
like join the fun, send me e-mail.
- Frank
Frank da Cruz
Manager
The Kermit Project
Watson Laboratory <-- See http://www.columbia.edu/acis/history/
Columbia University
612 West 115th Street
New York NY 10025-7799
USA
Email: f...@columbia.edu
http://www.columbia.edu/kermit/
Gale Gorman
It's quick on an old 486. Wonder if it will ever make a comeback.
Doubtful.
Gale Gorman
"Frank da Cruz" <f...@columbia.edu> wrote in message
news:9visv2$p7c$1...@watsol.cc.columbia.edu...
Bill Vermillion
Frank da Cruz <f...@columbia.edu> wrote:
>In article <GoEx1...@wjv.com>, Bill Vermillion <b...@wjv.com> wrote:
>: In article <9vgjpr$8j2$1...@watsol.cc.columbia.edu>,
>: Frank da Cruz <f...@columbia.edu> wrote:
>: >The Kermit protocol was designed and the first software written just over
>: >20 years ago, yipes! This was for CP/M, DEC-20, IBM mainframe, and the
>: >then-brand-new IBM PC.
>: So have you been involved with it from the first?
>Yup. It was my group who designed the protocol and wrote the first
>implementations in 1980-81. Plus I'm the one who stuck with it since
>then.
Thanks for all the work over the years. Somewhere in my piles of
books I have the Kermit manual - Digital Press ?? is that the name?
I'm guessing that was a late 80s printing. Thanks for the
continuing efforts.
Brian K. White
"Frank da Cruz" <f...@columbia.edu> wrote in message
news:9visv2$p7c$1...@watsol.cc.columbia.edu...
I have xenix 286 install media and licences (6150 tape and 5.25 floppy) but
I bet none of them includes the development kit.
Does anyone know what *ix will run on a 186 ? minix ? I have XT-CE for my HP
Jornada 548, which emulates a 186, on which you may run any DOS (msdos 6.22,
dr-dos, pc-dos, etc...) and "even some non-dos operating systems"
I think minix ran on 8088/86/186
even with dos... this means I might once again have a use for ... pcc! ahh
good old pcc from my first college days...
I still have a copy on my linux box that I run in dosemu. well, ran a few
times to satisfy my curiosity.
since xt-ce only emulates a 8 mhz 186 on a 75 mhz device, that means my 133
mhz device is only a 12 or 15 mhz 186, so you need the very tight fast code
generated by pcc.
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Frank da Cruz
Gale Gorman <ggo...@sbcglobal.net> wrote:
: The "lean and mean" part is the main reason I've stayed with Xenix so
: Doubtful.
In the various newsgroups, such as the Linux ones, you often see these
sentiments expressed, where some people have taken it on themselves to
produce compact client-only GUI-free Linux distributions, which are
somewhat Xenix-like. But yes, Xenix has staying power. It boots and
shuts down almost instantly, unlike, say Red Hat 7.2, which seems to take
20 minutes of doing who knows what. It's simple and it's fast. Readers
of these groups probably won't be surprised to hear that, at least until
recently, it was still to be found in countless doctors' and dentists'
offices and other businesses. The only problem with it now is that you
have to set the year to 1973, but this is wish fulfillment for some of us :-)
Actually some of the BSDs are like this -- they boot up quickly in text
mode with no GUI, they shut down instantly, they don't smother you with
user friendliness.
- Frank
Gale Gorman
math. Mine works fine.
I had a theory about the Windoze explosion. When the 486 came out, the
hardware manufacturers saw they had made a big mistake; you could no longer
type faster than the processor could work. They may have started to worry
they would not be able to sell a new annual upgrade like the past, so they
went to work on something that would demand more hardware.
GUI is like driving your car with the emergency brake on; it doesn't seem to
matter if you have enough horsepower.
Remember the Servel gas refrigerator? Same principle. Someone or a
consortium bought the rights to that and scrapped it.
Today I will put Kermit to work. I have to return to your site and figure
out how to pay for it online.
Thanks,
Gale Gorman
"Frank da Cruz" <f...@columbia.edu> wrote in message
news:9vl0ne$be0$1...@watsol.cc.columbia.edu...
Brian K. White
> 20 minutes of doing who knows what. It's simple and it's fast. Readers
> of these groups probably won't be surprised to hear that, at least until
> recently, it was still to be found in countless doctors' and dentists'
> offices and other businesses. The only problem with it now is that you
> have to set the year to 1973, but this is wish fulfillment for some of us
:-)
xenix itself can be patched for post-y2k
it's just most of the apps that are screwed, and some of those might be
fixed with fix2000. I had the frustrating case where the actual binary of my
app, bbx3 (basic interpreter) was OK for y2k even without using fix2000,
even though fix2000 corrects actual library routines that were compiled into
trhe binary. basis must have discovered the problem and worked around it
themselves in code, because I developed a program in bbx that would test all
of bbx's date & julian date math for correctness with dates before, after,
and spanning y2k and other gothca dates like feb 28th/march 1st, and another
important date I forget now. it did them all perfect without patching the
binary with fix2000, and did no different after patching, even though
fix2000 did report that it found something to patch in the binary.
it had one problem, which I beleive must have been the result of unexpected
results from polling the system for the current date behind the scenes. bbx
has a built-in variable "DAY" which contains the current date in a certain
format. this variable started returning junk after y2k, _but_ it's actually
possible to _set_ this variable to a correct value with a single short line
of bbx code at the top of your program, which uses the date() function,
which _does_ work.
I get this far and I think, "damn I'm slick, we won't have to buy all new
software after all!"
however, my stupid *&^*^^%$^ app used it's own brains instead of the built
in functions to do a bunch of date math, and it was too much for me to fix
(I'm not really a programmer, wasn't at the time anyway) and these routines
were completely dumb about y2k. the universe ended by then as far as they
were concerned. the univers also didn't exist too far before 1970 either.
--
Tony Lawrence
I had one where the customer just would not upgrade (he was trying to
sell off the business and didn't want the expense). He discovered that
the only real problems with the app were that it would get the date
wrong from the OS, but if he manually set the date ( using 00 for 2000)
within the app it would work, and that reports were sorted screwily (of
course).
So I wrote an expect script that would get todays's date, fire up the
app, enter the necessary keystrokes to set the date, and then release
control to the keyboard. On the report side, we talked about putting in
some simple printer interface processing to rearrange the sorting
(wouldn't have been hard at all), but he decided he didn't need that
part as the pre-2000 stuff would disappear from his reports fairly
quickly.
He was still using that until he sold the business just a couple of
months ago. The new owners were somewhat amused at my Y2K "fix" :-)
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Bill Vermillion
Well not quite instant - took over 5 seconds - from the CLI login
but with an X GUI on another screen.
Total time from shutdown to reboot and fully up and running was 40
seconds flat.
That included neworking setup, intializing IP filter, starting up
named, going to the net to get the time via ntpdate, loading in the
linkable kernel modules of ibcs2, linux, svsv4, and streams
modules, starting up X11, apache, arpwatch, Samba, and finally
sshd.
It would probalby be faster if it weren't running so much and only
running on a 180MHz DEC PentiumPro with 64MB and a 33MB UDMA IDA
drive. Maybe that's why I like it so much for servers, email, etc.
It reminds me so much of the earliest Xenix before it was
contaminated by System III ;-)
Dr. Hans Obermueller
here's a dentist still relying on Xenix which hasn't failed so far
(since 1988). Date math is not bad: i have to run the BIOS with minus
one day as all system funcions and commands work fine, but the NIAKWA
runtime is one day ahead since 29 feb 2000.
-Hans, parttime sysad and fulltime dentist
John DuBois
Brian K. White <br...@aljex.com> wrote:
>Does anyone know what *ix will run on a 186 ? minix ? I have XT-CE for my HP
>Jornada 548, which emulates a 186, on which you may run any DOS (msdos 6.22,
>dr-dos, pc-dos, etc...) and "even some non-dos operating systems"
Remember that XENIX ran on an 8086/8088. My introduction to SCO operating
systems was on such a machine.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Bela Lubkin
> : > Today, there is also a very small Unix-only C version, but it's fast:
> : > http://www.columbia.edu/kermit/gkermit.html
> In case anyone else is reading this thread: G-Kermit has been built
> for Xenix 2.3.4, but who among you can build it for earlier Xenix
> versions? Xenix/286? SCO UNIX versions prior to 3.2v4.2? If you'd
> like join the fun, send me e-mail.
The XENIX development system was pretty good at backwards compatibility.
The "built for XENIX 2.3.4" binary that you've built probably works at
least back to XENIX 2.2.0 '386. If you can't find a system on which to
test the theory, then it doesn't matter very much, does it? ;-}
Meanwhile, the same XENIX devsys had options to build '286 and '86
binaries. To build a 286 binary, add "-M2"; to build 8086, "-M0". You
should be able to test those binaries on your XENIX 386 2.3.4 system,
since it can run the older sorts of binaries. Of course running them on
386 XENIX doesn't prove they'll work on the target systems, but at least
if they fail you'll _know_ they're no good...
>Bela<
Brian K. White
"John DuBois" <spc...@deeptht.armory.com> wrote in message
news:3c1e88f3$0$79559$8ee...@newsreader.tycho.net...
> In article <IxfT7.275606$ez.38...@news1.rdc1.nj.home.com>,
> Brian K. White <br...@aljex.com> wrote:
> >Does anyone know what *ix will run on a 186 ? minix ? I have XT-CE for my
HP
> >Jornada 548, which emulates a 186, on which you may run any DOS (msdos
6.22,
> >dr-dos, pc-dos, etc...) and "even some non-dos operating systems"
>
> Remember that XENIX ran on an 8086/8088. My introduction to SCO operating
> systems was on such a machine.
I've got FreeDOS installed on it now, next comes filepro 4.1 for dos.... ;)
They have linux and netbsd ports of the kernel for actual cpu (sh3) but no
other platform hardware, just for other platforms using that cpu (dreamcast,
hp720). I would *love* to run a native 133mhz sh3 version of linux or netbsd
instead of DOS running on a 15mhz 80186 emulated within WindowsCE, but...
anythings better than that worthless windows ce conatcts manager. I actually
look up phone numbers in a kyocera spmartphone, simply because the palmos
contact manager actually works, I can actually find numbers, even though the
phone is not turned on as a phone right now, even though I carry the jornada
with me all the time and it has the same database, all the same records
exported from my unix filepro app.
the thing is turning out to bee good only for keeping miscelanious notes,
playing music and books-on-tape, and as a device for wasting time...(witness
my project to get an old version of filepro, for an old OS, to run on it via
an emulator that can only put out the equivalent of very old hardware, which
I will barely be able to *see* once it' does finally all work....) oh, and
the emulator drinks up my 8 hour battery in 2 or 3 :)
--
fred smith
>>Bela<
Just to expand a bit on this thread: 2.3.4 could run (some???) COFF
binaries. Depending on how your one "built for 2.3.4" was made (ON 2.3.4,
or only FOR 2.3.4??) it may or may not be COFF. If it IS (unlikely
though it may be) it nearly for sure won't work on the older versions.
--
---- Fred Smith -- fre...@fcshome.stoneham.ma.us ------------------------ ----
Do you not know? Have you not heard?
The LORD is the everlasting God, the Creator of the ends of the earth.
He will not grow tired or weary, and his understanding no one can fathom.
----------------------------- Isaiah 40:28 (niv) -----------------------------
Jeff Hyman
ftp.cactus.com/cactus/scox/kermit.scox
# what kermit.scox
KermitEL.c 1.5 3/10/94
Revision 3.1 3/10/94
- Jeff Hyman
Duilio Foschi
no.
I already saved the Xenix data.
(I realize I got to transfer a lot of bytes recently <g>)
Now I have to get a large binary file from the Unix box of a customer.
Duilio
Gale Gorman
I am currently moving a lot of large files from Xenix to Windows using
Kermit. Once I figured out my screwups it became very simple. Also very
slow because Xenix only wants to send at 9600 but NO errors.
Gale Gorman
Houston
"Duilio Foschi" <ded...@yifan.net> wrote in message
news:3c2b124c...@news.libero.it...
Frank da Cruz
Gale Gorman <ggo...@sbcglobal.net> wrote:
: I am currently moving a lot of large files from Xenix to Windows using
: Kermit. Once I figured out my screwups it became very simple. Also very
: slow because Xenix only wants to send at 9600 but NO errors.
Are you sure? What does "set speed ?" say at the C-Kermit prompt? I would
be very surprised if 19200 wasn't listed, and even a little surprised if
38400 was missing. (I don't have any Xenixes at hand at the moment or I'd
try it myself.) What doesn't work, of course, is hardware flow control --
you have to use Xon/Xoff.
- Frank
Bill Vermillion
<f...@columbia.edu> wrote:
It depends on how old his Xenix is. As I recall at least one early
version I had topped out at 9600. With Xenix on a non-Intel
platform running at 9600 would actually get you 6000bps through put
maximum. The bit timing was at 9600 of course, but that's the 'joy'
of asynch communication - the pauses between each 10 bits can be a
bit long. :-) or :-( depending on how you look at it.
Gale Gorman
There is a listing for 38400 under 'set speed ?' but when I tried to use it
I got a message to 'set line' first. Then 'set line' balks because uucp has
a lock. A prior problem was a simple fix. I had disabled tty1a and simply
forgot to enable again so K-95 couldn't get through to the Xenix side.
If I kill the locked process and and disable tty1a, how do I get through to
Xenix to issue the 'set line, set speed' commands?
--
Gale Gorman
Houston
"Frank da Cruz" <f...@columbia.edu> wrote in message
news:a0fmp8$rus$1...@watsol.cc.columbia.edu...
Gale Gorman
Gettydefs show an 'n' for 19200 and an 'o' for 38400. I think I reliably
used 19200 on Wyse60 terminal connections but it has been a long time.
--
Gale Gorman
Houston
"Bill Vermillion" <b...@wjv.com> wrote in message news:Gp0xB...@wjv.com...
Frank da Cruz
Gale Gorman <ggo...@sbcglobal.net> wrote:
: There is a listing for 38400 under 'set speed ?' but when I tried to use it
: I got a message to 'set line' first.
If you're coming in through Windows, then Xenix Kermit is on the remote
end, and you *don't* give a SET LINE or SET SPEED command. Those are for
when you are making connections *from* Xenix. When you come *into* Xenix,
the connection is at whatever speed you came in at.
> Gettydefs show an 'n' for 19200 and an 'o' for 38400. I think I reliably
> used 19200 on Wyse60 terminal connections but it has been a long time.
>
Then you can use it with K95. Just be sure to tell both Kermits to
"set flow xon/xoff". If you enable 38400 in Gettydefs, you can probably use
that too (I don't know what 'n' and 'o' mean).
- Frank
Gale Gorman
> end, and you *don't* give a SET LINE or SET SPEED command. Those are for
> when you are making connections *from* Xenix. When you come *into* Xenix,
> the connection is at whatever speed you came in at.
>
> > Gettydefs show an 'n' for 19200 and an 'o' for 38400. I think I
reliably
> > used 19200 on Wyse60 terminal connections but it has been a long time.
> >
> Then you can use it with K95. Just be sure to tell both Kermits to
> "set flow xon/xoff". If you enable 38400 in Gettydefs, you can probably
use
> that too (I don't know what 'n' and 'o' mean).
In /etc/gettydefs there are letters at the beginning of each line to tell
/etc/ttys to use the settings on that line. An 'm' is 9600, 'n' 19200, and
'o' 38400.
I am coming in through K-95 and getting a login: prompt from Xenix. Then I
escape back to K-95, cd to the directory I want, and type kermit -g
/u/dwgs/* and it's off and running.
I will change the speed on both sides and try it. I'm done with the really
big directories but it's not like I had to sit and watch<g>.
Gale Gorman
Houston
Brian K. White
"Frank da Cruz" <f...@columbia.edu> wrote in message
news:a0fmp8$rus$1...@watsol.cc.columbia.edu...
I told him in email that xenix only natively supported 9600, but that
usually a multiport serial card has been installed, and the driver for
that is the only way xenix gets to go faster, even when using the plain
serial ports. According to the xenix manual (the last version made) the
highest speed is 9600, and the two "speeds" EXTA and EXTB are not actually
functional by default, but 3rd party drivers usually use them for 19200
and 38400.
I have never had to test on a plain stock xenix box that never had a 3rd
party serial driver installed, so EXTA and EXTB have always worked for me
as 19.2 and 38.4, but I was relaying what I remember reading in a real
xenix manual a couple years ago when I was doing much the same task.
I also used kermit, although I had two boxes next to each other, both with
smart digiboards and the latest kermit. I made a script that split up the
data over two serial ports and used 115200 baud with hardware flow on
both, thanks to kermit and the digiboards the job flew.