OS/2 Shareware BBS: 32 Periodic/32-Periodic.zip/MNLTXT.ZIP/wp_radio.txt

Text File | 1995-05-17 | 13KB | 329 lines

OS/2 Warp Radio is ON THE AIR...

A bunch of CAOS* guys take on Warp and LAN Server 4.0 to connect
a venerable Canadian public broadcaster.

* CAOS/2 - Central Alberta OS/2 Users Group



The Players|

Jerome Yuzyk - The author, chairman of CAOS/2:Central Alberta
OS/2   User Group, OS/2       Retail and VAR Products Marketing
Specialist for IBM Canada, owner of Bridge Scientific Services



Larry King - CKUA's man-about-the-station, running everything
from transmitters to the phone system. And computers too.



John Boles - A carpet-layer by day, John finds OS/2 much easier
on his knees, and lately for his pocketbook.



Tom King - Ex-CAOS secretary, by day, Master Corporal for the
Canadian Air Force,        stationed in Winnipeg. Otherwise a
rather new OS/2 torch-carrier in the Winnipeg area and Teamer
even if he doesn't say so.



Darrell Ouelette - CAOS Demo coordinator and hardware expert.
Otherwise a machinist and jack-of-many-trades.



The Setting

CKUA Radio is a long-time public broadcaster in the province of
Alberta. From the beginning, CKUA had one simple yet significant
assignment: to offer education to the people of Alberta.  They
signed on the air as CKUA AM in November of 1927 as the "Voice
of the University of Alberta" bringing lectures, music and local
plays to the Edmonton area. Today the station operates 16 FM and
1 AM transmitters broadcasting news, music and educational
programming across Alberta and over the border to BC,
Saskatchewan and Manitoba. Sometimes (depending on the weather)
it is heard as far away as Chicago!



 Act 1: The Consultation and Grim Reality of Choices Badly Made

Through the grapevine, I hear that CKUA is interested in using
OS/2 to operate a couple modems on a machine connected to a
Novell 3.12 LAN. No problem, I've connected OS/2 2.1 to Novell
before and connecting OS/2 Warp should be no problem.



Well, there was a problem, but not with OS/2 Warp. At some point
in the past someone decided that a 5-seat Novell licence would
be sufficient because there were only 5 immediate users for the
network. The machine I was asked to set up needed at least four
seats for itself! After a couple of calls to find out upgrade
prices it turned out that upgrading to a 25-seat licence would
cost more than buying a new licence, and even that licence
wouldn't be enough for all the planned users. With LAN Server
packaged as one Server chunk and a per-requester cost, the
economic choice was easy: "Buy what you need now and add more
later." Ergo, go with IBM LAN Server!



 Act 2: From CAOS comes order

On a cold February Sunday John, Tom, Larry and I set about
removing Novell and substituting LAN Server. There was no need
to migrate any files because the server hadn't been up long
enough to accumulate anything.  Along the way, we also
documented and tidied their News Room DOS workstations, and
installed OS/2 Warp as a communications server on another
machine to manage the traffic from 2 serial-fed satellite wire
services, one dial-in remote connection and an office-wide
fax/modem.



The installation went smoothly for the most part. Sure glad I
made disk copies of all the on-line documentation, though, and
suggest that as Step 1 for any other first-timers. The Server
machine is a Valuepoint with 16M and 540M SCSI disk running in
OS/2-only mode. It services an HP LaserJet III and an Okidata
roll-printer (yep, the brown newsprint stuff, without
perforations), a NEC 3x CD-ROM player, and a 2G Python SCSI DAT
tape drive. We used a shrink-wrap copy of OS/2 Warp and the LAN
Distance 60-day eval CD (with bonus copy of LAN Server 4.0).
Being a complete newbie to CD installs I had echoes of troubles
I've seen on the 'Net floating through my head.  It wasn't until
install Disk 4 that I realized that there would be no CD
problems (Duhhh... why am I sitting here waiting to feed the
next disk...?).



Once OS/2 was on, I ran through my usual tune-up routine: edit
CONFIG.SYS for performance, copy a bunch of Rexx scripts I've
written for full-time machines, create a few standard
directories and get them on various PATHs.  One of these days
I'll write my own custom system setup routine to do all the
things I usually do anyway, but that's another story...



Then it was on to LAN Server, and my #1 favorite thing about it:
it runs like "just another" OS/2 application. While the install
was copying files and making Desktop objects I was tooling along
unpacking more files from my "kit," editing some of my Rexx
stuff, and setting up the Desktop. No need to rely on a login to
the server in order to do anything meaningful with it!



While the Server was building and Tom & John did their thing to
the client stations, we took turns baby-sitting the Comm server
and its from-floppy install (the NEC is a SCSI drive, alas).
Fortunately, this machine is very similar to the one I use
desk-side, so I was sure there would be little problem. Larry
scuttled around stringing 10-baseT and power cables all over.
After OS/2 Warp and the OS/2 Requester were running, we
re-loaded the news-wire service and set up a couple icons to
start the capture and edit sides of the wire software (a DOS app
called DNEWS). There's only 8M on the machine, and so this setup
is a stop-gap measure until the modems and another 8M are in.
We toyed with dropping the WorkPlace Shell to pick up some extra
headroom, but decided to live with it for a while.



And, just because it has to be done sometime, once the server
was up, I did an in-your-face test of the Uninterruptible Power
Supply (UPS) (a TrippLite 450 looking suspiciously like the kind
of lunchpail I used to take to school) by just yanking the plug
from the wall while everything was up and Tom & John were
merrily setting up Client stations. All I got was an entry in
the System Error log from the UPS handler. S-m-o-o-t-h.



 Act 3: Up and Running!

Now that Warp Radio has been running for a while, we've made a
few changes and learned a few things.

= Some DOS applications just aren't made to multi-task.

The DOS application handling the satellite feed just refused to
be tamed.  With a brute-force polling method, no error-checking
or buffering and a very "bursty" incoming data stream there was
no way to reliably ensure we could receive every byte every
time, with everything we planned to throw at the machine.  No
problem: Larry had a spare 286 (a vintage AT with a 30M
MFM-controlled drive) that we tucked into a corner with its own
logon ID. Now we had one less (major) hassle to deal with on the
Comm Server and could actually start to have fun with it.



= LAN Server takes an extra amount of time to shut down so be
patient.

The OS/2 ShutDown function calls LAN Server to start shutting
down the server and then proceeds to close down all other
sessions. They all close except the Desktop, which waits for LAN
Server to shutdown. This takes a while, and it's threaded so
there's no clock to watch. Furthermore, Ctrl-Esc may bring up
the Window List showing the server not running.  LAN Server
newbies may (well, we did) think that the machine is hung and
re-boot.  DON'T! Be patient and wait.



= Make Backups Make Backups Make Backups Make Backups

But you knew this already, didn't you? :)



= The WorkPlace Shell can be "good value for the memory"

We weren't going to use the graphical shell on the Comm Server
so that we could use the extra memory for other tasks. But Larry
got another 8M for the machine, bringing it up to 16M, and the
reaction of the News Room guys to the graphical interface made
the choice easy. I think it was Ferns desktop bitmap that really
sold it, along with the descriptive icon names and the ability
to do a lot of things without commands. "You mean you just move
that picture over to that picture and it's done? Wow..." was a
rough summary of reactions.



I moved most icons off the desktop and created a CKUA folder
which I shadowed onto the LaunchPad. I also created a File
Transfer folder which shadowed the directories that collect
files from Dial-In users. The folder is marked as a Work Area
and opens up a couple other folders, one for each contributing
city. In each folder is a shadow of the floppy drive and a
NewsRoom directory on the server, so they can move files
manually. I showed them how they can cut text from the DOS
newsfeed editor and paste it into WordPerfect.



 = Do whatever you can to get a dial-in link working, especially
if you  work in a cold climate.

Edmonton can be a cold place in mid-February. Forty degrees
below zero with a wind. A dial-in connection to the LAN can be
the difference between a bone-chilling foray across town and a
comfy night at home in front of the electronic hearth with a
loved one.



The Dial-In side uses a setup I have used for over a year with
another OS/2 machine connected to a Novell server. I use
HyperAccess/5 (HA/5) running a modified Answer script wrapped in
a layer of Rexx. This lets me operate a dial-in connection fully
in the background with very little noticeable effect on
foreground operations. A little HA/5 scripting and a little Rexx
lets me log callers to a system-wide master log file, re-start
the link from remote, play a HELLO/GOODBYE indicator, and toss
uploaded files onto the network with logged, audible and printed
notifications. Right now I'm working on making the newsfeed
available to dial-in users, and as soon as we pick an e-mail
transport we'll connect HA/5's e-mail service to it.

= LAN Server Entry runs just great on OS/2 Warp.

It just sits on top of OS/2 like any other app (actually, some
pieces sit below), and if you pay for Advanced you get another
slice (HPFS386) that goes under OS/2 for even better performance.



Act 3.5: Some Gory Detail, Kind of Hints...

 Caution: This section is not for the casual end user. Read on
and enjoy if you like technical details and want to learn from
the experience of others.



= Tune OS/2 Warp first.

Out of the box, Warp is conservative in its settings. Read
Information->Performance Considerations, the FAQ or the CAOS
Warp Notes and then do some or all of what they say.



= Read through all the docs first, and do any planning
worksheets  *before* setting up the Server.

The GUI tools are fine, but if your plan is ill-formed they can
only help so much, and may actually get in your way. The LAN
Server documentation comes with about a half-dozen estimating
and configuration worksheets that can server as the basis for
your future network documentation.



= Forget FAT (File Access Table) and go straight to HPFS (High
Performance File System).

HPFS is much faster and much more stable, especially if you use
the (default) WorkPlace Shell. If you just want to "experiment"
and stick with FAT for a while because HPFS is new to you,
either have a decent backup procedure in place or do it on a
non-production machine. Warp works, LAN Server works, HPFS is
best: just do it.



= Learn Rexx and watch for ways to make your OS/2 machines think
and  act for themselves.

Out of the box, OS/2 Warp and LAN Server are fine for manual
control of a lot of things. But OS/2 has more than enough smarts
to think for itself (at least watch itself) if you are orderly
and treat the machine as an around-the-clock entity in the first
place. Learn some Rexx, and write StartUp and ShutDown code so
the machine can get everything up and take everything down in a
controlled fashion. Also write some "wrappers" for various
utilities so that you can do other (automatic) things with them.
The Comm server starts everything it needs from STARTUP.CMD and
can shut down and reboot itself from some other code I wrote.



= LAN Server installation is very modular, serving double-duty
for  Installation and Configuration.

We backed off a couple things for fear of starting an unwanted
Installation until we realized this. You should be able to
install just the on-line docs, or just read them from the disk
(in the Books folder). They are named with codes, but still just
INFs, so I just copied and renamed them with long file names.



= Neato administration and reporting feature: DSPDOMDF.CMD, or
DiSPlay DOMain DeFinitions.

This Rexx script should be run from an ADMIN logon at the server
for full reporting, though you can run it from any OS/2
requester with an ADMIN logon. It basically runs through a set
of NET inquiry commands and parses their output into a report of
your entire setup that can be redirected into a file.
*Definitely* do this regularly as an additional backup and
change-logging procedure.