We haven't opened the facility up yet so it's not on our location page.

> 1. Are the MF applications APPC or screens? There are tools for
> both that can move data between the mainframe and the NT systems.
> MS SNA Server, BEA Connect for Mainframe (Tuxedo), or Java Connect
> for Mainframe (BEA WebLogic). IBM has the same stuff.

They are various screens built from Wylbur execs, CICS, and who
the hell knows what else. We've turned DB2 off about 3 months
ago as the last DB2 app was ported off. This is strictly a flat file
system. We will NOT be doing any fancy connections to any application.
We will totally replace 9 out of 10 applications. The final one will have
transaction files fed into it, just like it does now, only they will
come from the PC based system.

We've got TCP/IP to the MF. We tossed the SNA years ago. I can move
files around from within FTP sessions from Perl from the Linux box.
I'll keep a Linux master control box in this environment if I can.
I can also submit jobs into the MF JES Queue from an FTP session.
I'm pretty good at glue. I can also run MF/Unix programs on OS/390,
but they are very slow.

My major hole of knowledge (that I know about) is interfacing with the
canned app via their API, general windows Perl program, and general
windows "issues". So I tend to fall back onto the Linux side for any
core infrastructure code if I need it in a hurry.

> 2. You need to convince your management to think in terms of systems
> that will build quickly and integrate well. BEA Systems does this well.

Hehehehe. We are not going to invest ANYTHING in a BEA like environment.
Remember, the old MF mentality of it being the center of the universe
is gone. It is merely a slow, expensive compute server that we are not
ready to turn off yet due to limited legacy application requirements.
We will do a little at possible to create a tight integration between
the old and new. The direction is more to understand what the old is
doing so it can be replaced without causing any harm in the process.

Since we already have the PC based system totally running one arm of
the operation it is not a matter determining if it CAN do the job.
We know it CAN. It is more a matter of the corporate will to move to it.

This is about a 2 year time frame. Not quick, not easy.

> 3. If you're already a Microsoft shop, you might take a look at SNA server
> to get your MF stuff down in the short term. Using the MF as a DB server
> is typically a good strategy (but expensive), because the procedures are
> already in place to back up the system, run it reliability, etc.

No SNA, as stated above. No DB2, as stated above. We are PRIMITIVE.
Which makes it easier to get off it.

> Most
> companies are already running their back-office systems on the mainframe
> anyway (EDI, accounting, payroll, etc.) FYI, if you do run your core/central
> databases on SQL Server INSIST that you get the mainframe budget. Corp
> execs like to kill the mainframe thinking that they are saving money
> because they "don't have to do so much stuff anymore". The truth is,
> you still have to follow the same types of procedures (planning storage,
> backups, moving transaction logs, running on SAN hardware), otherwise
> you end up with a major company-ending disaster in a few years, when you
> lose your accounting system with no reasonable workable disaster
> recovery solution.


Our PC/NT network backup it already very good. We have a robotic tape
library that can pull a file in about 30 seconds. And yes, this WAS
tested when the previous NT admin boobood and wiped out a system.

Note: "previous".

We always have RAID disks as well as ongoing backups. And while we
have serious SAN space for our marketing databases we do for clients,
this side is TINY. I'd be happy about with 2 mirrored 72 GB SCSI
disks in 2 servers. Their ENTIRE storage allocation for the current
system on the MF is about 1 GB!!!!

We have 5 buildings at our current office area. 1 is on a separate
power area. Don't know what to call it, just that we rarely blackout
at the same time. We have fiber links between all buildings except
the remote one, which has a dedicated T1. I can mirror servers across
the dedicated link between these building as needed.

Our primary data center has full room UPS that will power for about 15
minutes. The deisel generator kicks on to full power in 7 seconds.
This includes running the mainframe, a 21 TB EMC, 8 TB of SAN storage,
8 SUNs, 2 dozen highend Intel based servers, and the HVAC systems.
We only draw 50% so we have room to grow.

None of this is going away,

We are not killing the box, only selected applications. And those
applications are home grown. So the only cost "savings" is our ability
to do business better, grow faster, etc. Except now that all the
core operational data is in SQL tables not flat files, so we can
query via standard tools, not write COBOL programs.


> 4. Communicating between VB and C++ DLLs are pretty easy, so I
> assume that it would be the same with Perl. If it is a dynamically
> typed language, you need to understand (at a bit/byte level) how
> the Perl equiavalent of a Variant is stored. Then you need to
> understand whether things are being passed by reference (pointer)
> or by value (non-pointer). And finally, you need to understand how
> the functions are returned. OK, may it's not so simple, unless
> you've done it before. I'm sure you'll be able to figure out how
> to do it on the web.

Never done it on windows, but I am comfortable with C VS Pascal
call stacks, reference vs values, etc. We'll figure it out.