AS/400 as Deployment Server (sort of)???

To all:

Has anyone configured a system to use the AS/400 as both the Enterprise Server, and the Deployment Server (via an emultaion card)? I know the AS/400 can't be used natively for the Deployment Server, but I was wondering if anyone configured the AS/400 as a Deployment Server, by running Windows2000 on it?

I would think there would be huge drawbacks to this configuration, ie performance, putting all the eggs in 1 basket, etc.


Thank you,

msouterblight1,

I had similar questions not too long ago, I have copied in some onf my questions and one of the responses I got to my inquiries.
----------------------------------------------------

Mr. Jump
After reading your article on storing JDE Central Objects on the AS/400 I
have a couple of questions.

Are there any performance issues with this solution?
If the AS400 is used as an enterprise server does having CO on the 400
improve daily runtime performance?
By storing the CO on the 400 does this impact package builds on the
Deployment server?
What about if the Deployment server is on an integrated X series card?

Any insight you can give me here would be helpful. I would love to put my
development server on an integrated X server but I keep hearing issues with
performance
in package builds may result.

Thanks in advance for your time.
---------------

Hi David,

I'll try to answer the easy questions first!

The central objects are accessed for installs, upgrades and package builds.
They do not get accessed much during normal processing, so having them on
the 400 or on a separate database shouldn't have any impact on your normal
daily processing.

Using the integrated card doesn't really impact things much either. even
though it is a card in the 400, it only uses the 400 for disk access. If
central objects are stored under OS/400, it would use the network to access
those objects. There is a virtual network connection that gets configured
when you install, between the internal card and the 400, but generally this
isn't used and pretty much functions as a 16Mb token ring, so using the
external nic, at 100Mb ethernet is faster.

The drawback of the IXS card is that it is a 1-way. It is currently at
850MHz and, because it is offloading disk access to the 400, it should
function faster than an external 850MHz server, but it is still a 1-way. A
lot of people prefer 2-ways as deployment servers. It depends on your
development environment. If it is critical that you have package builds
process as fast as possible than a 2-way would pronbably be better. On a
1-way, I would expect package builds to complete in somewhere between 7-11
hours. I've seen 5 hours for a combined server and client build, but it
can depend on a lot of factors.

Storing the central objects natively on the 400 still makes use of JDE's
workaround of splitting up the BLOBs into smaller chunks. I think there
probably is a little overhead for putting them back together, but I don't
think it is a big amount. I wouldn't expect it to be more than a few
percent degradation, and with all the different steps that make up a full
package build I wouldn't expect it to make a huge difference....this is a
guess, but maybe it would add on 15 min to an hour, but I doubt it is that
much.

If someone is looking for the absolute fastest full package builds, then I
would recommend a 2-way external box, and storing the central objects in a
local database on that server. This would be true whether it is a 400
install or an Intel or Unix install. Other platforms have the same issue
of communications and would benefit from storing central objects locally.
The difference is Oracle and SQL server do not have to go through the other
step of combining the BLOBs.

That said, I think you can still get acceptable package build times out of
a 1-way, (such as the integrated card), with central objects stored on the
400. Communications is key, making sure that everyhting is indeed
communicating at 100Mb full duplex, (not always the case when "auto-sense"
is used.) Also, compression for the ODBC datasource is critical.

I would expect the difference between an external setup with a local
database vs a 1-way to be somewhere around 5 hours on the 2-way to 6-7
hours on the 1-way.

I've heard about people having bad performance and package builds taking 16
hours or more, but I think those are due to specific problems, like
compression not being turned on, or communications not being right.

The decision comes down to how fast you need the package builds to complete
vs how you prefer to manage the server. If you are looking for absolute
fastest, then I would keep the central objects on a 2-way external
deployment server. If the difference between 7 hours and 6 hours or so
isn't a big problem, and you prefer to have central objects backed up at
the same time as the rest of your database, or you don't want the hassle of
having a separate database, then the IXS is a good option.

I'm not sure if this is much help or not. We don't have a lot of hard
data, but hopefully it will give you a little more to think about!

Let me know if you need more details or have further questions. Good luck
with the decision!

Best regards,

Rob Jump
Sizing Specialist
IBM/J.D. Edwards International Competency Center
303-334-1054
[email protected]
www.ibm.com/erp/jdedwards

One other limitation you may want to research is disk space usage. I was at a location where they only allocated 25 GB for the Deployment Server. When they realized that they would need to allocate more, they found out that they needed to blow away the Windows setup on the emulator card first. This meant having to backup the Dep Server stuff and then restoring once the additional HD space was added.

We began by using the 700mhz internal INS card on the AS/400 as our
deployment server. A year into the implementation, we moved it off to a
separate NT box. The issues were more surrounding the backup/restore
procedures for the INS than performance. At that time, we could not get
file-level backup working, so the deployment server was backed up at a
"space" and had to be restored to the AS/400 in total if we needed to
restore only one directory. This was a restore time and disk-space issue for
us. But, file-level backup may work fine with your setup. I would advise
that, if you go this route, you have your backup/restore procedures tested
and are happy with them.

As for CO on the AS/400, we have been very happy with that.

Good luck!




Xe, SP 19.1_E1, Update 6, ES=AS/400 V5R1, CO=AS/400, Thick & Citrix Clients

Thanks for all your responses. This has really given me some food for thought!

Thanks again,

A couple additional comments.

I'm not sure what versions they were on in the case below, but I don't
think you'd have to do that with curent versions of the IXS and OS/400. It
is pretty easy to add disk, and a lot of it can be done without even taking
down the IXS. The disk admin, through the ops navigator gui has gotten
MUCH better. It's actually very easy to ADD disk now, taking it away can
be trickier.

I haven't gotten a chance to try it yet, but with V5R2 the internal lan
connection has been improved. It used to function at about 16Mb token ring
speed, but from what I've heard it now gives you 1Gb performance over the
internal link. Since parts of the package builds are so communications
intensive, I'm hoping it will help them considerably, but haven't tested it
yet.

From a windows and usage point of view the IXS should function the same as
an external server. It usally uses a 100Mb ethernet card to communicate
with the 400 and other boxes. It acesses the disk over the HSL, so disk
response time should be very good and comparable to using any high
performance external storage. The way I look at it is the 400 becomes a
SAN with the benefit that you can do a lot of administration from the
400....shut down, start up, some user admin, some disk management, etc.
The key, as was mentioned on a previous post is that the IXS is a 1-way.
You can also use an IXA, (adapter to connect an external mutli-processor
xSeries) if you need more than a 1-way. It functions in pretty much the
same way....using the 400 disk.

Drawbacks are that 400 disk is probably more expensive than SCSI disks,
(although you probably get better performance and better reliability), and
it is a little "different". Once you get them installed they function just
like an external windows box, but they are a little more involved to
install and it requires a little more knowhow to administer, since you are
dealing with two operating systems, (Windows and OS/400), for some tasks.

Good Luck!


Rob Jump
Sizing Specialist
IBM/J.D. Edwards International Competency Center
303-334-1054
[email protected]
www.ibm-jdedwards.com


njcncadmin <[email protected]>@jdelist.com on 09/09/2002 09:26:45 AM