Central Objects on AS/400, IXS

jeff_carey

Member
We are considering a few changes to our environment when we go to Xe, and
are wondering if anyone has any experience with them.

1) Central Objects on the AS/400
Currently, our central objects are in an Oracle database on our deployment
server (NT). If we move these to the AS/400, does that then eliminate the
need for an Oracle client on the OneWorld client? What should we expect
as a performance impact from doing this? Am I right that we still need an
NT deployment server if we do this?

2) IXS as deployment server - we are considering replacing our aging NT
deployment server with an Integrated xSeries (Netfinity) Server on the
AS/400 - basically an Intel motherboard on a card that sits in the AS/400
and uses AS/400 disk. We've heard that this can be a more stable
implementation of NT, is faster (at least in the lab) for OneWorld, has
greater manageability of backups and greater flexibility for copying the
disk (for testing or a "hot spare").

Of course, we are hearing this from IBM sources. Does anyone out there
have experience with a deployment server on an integrated NT server card
on an AS/400 / iSeries/400?


Jeff Carey
Technical Specialist
AS/400 Technology
Transaction Processing Systems
 
Jeff-

Users should expect a performance hit during package builds if you go with
the IXS, to say the least. We recommend against using these for this
reason, not to mention cost and complexity of upgrades for both the IXS and
OneWorld. We have assisted several clients in transitioning to the NT
platform from IPCS/IXS boards.

Package builds take longer with the IXS because the stability of using IBM
disk has the drawback of the added overhead in keeping it stable. You won't
need the Oracle client anymore, though - there is no more Oracle database.

Personally I'd stick with the NT box.....that is my .02

Regards,
David
 
We are using Xe with Central Objects on the AS/400. I am not familiar with
Oracle, but shouldn't think you'd need its client if you move CO's to the
AS/400. You would need Client Access Express if you don't already have it.

We are not live yet, and are only supporting 20 thick clients and just
starting to use some Citrix clients. Our deployment server is on the 700 INS
card in the AS/400. It has worked well for us so far, but we are wrestling
with two issues. First, when the deployment server space is backed up with
the AS/400, it is backed up as a storage space, and we have no way to
restore individual folders, files, etc from the deployment server space.
So, yes, backup is easier because it backs up along with other AS/400
objects; it's the restore that may be the problem. We need to discuss this
more with IBM and see if they have a solution for this before go-live.

Second problem may have absolutely nothing to do with the deployment server
being on the INS, but we are having performance problems with our thick
clients. Our client pcs are well about standards, AS/400 performance
monitor shows no problems, package builds are fine, and network analyzer
shows no slowdowns. So, it may just be the thick client is really slow.
Again, this probably has nothing at all to do with the INS card deployment
server, but I thought it worth mentioning.

Good luck!



JDE - Xe
AS/400 Mod830 V4R5 Enterprise Server/Central Objects
AS/400 700 INS Card - NT Deployment Server
WTS/Citrix & thick clients.

Judy Lessard
IT Specialist 4
Timken Super Precision (MPB)
603-352-0310 ext. 385
[email protected]
 
Wanted to make sure one point was corrected, plus a few other comments.

You DO NOT have to IPL the 400 whenever you reboot NT. This would make the
400 as unstable as NT, which wouldn't be acceptable to anybody. You can
boot the NT machine either locally or remotely, (through NT commands or
OS/400 commands) without taking the 400 down, without taking any subsystems
down, etc. All you have to do is vary off the IXS device and vary it back
on.

One of the big reasons for moving the central objects to the same database
as the database server is to get rid of the extra cost/admin of a secondary
database, so that is definitely a good reason to do it. You also have
centralized backups and a lot easier administration. As others have
pointed out, you lose some performance, since you are now accessing a
remote database vs a local one, so you are going over the network vs local
disk. I haven't seen any direct comparisons, so I'm not sure WHAT the
actual difference is, but you'll need to consider your frequency and
current speed of package builds.

As pointed out below, the (more reliable, longer MTBF), 400 disks ARE more
expensive. With a deployment server, especially when you at least double
disk space for an upgrade, you have a lot of disk space sitting around not
really being used too often. Is it worth it to have that tied up in more
expensive 400 disks or cheaper standard SCSI PC disks? It migh depend on
the size of your implementation. If you already have a large 400 and an
extra 30-50GB on the 400 isn't a big deal, then it might make sense. If it
is a smaller environment, where disk cost is a higher percentage of the the
overall cost, it might not.

Regarding your question about speed. Generally the labs say that a given
MHz integrated card will perform better than the same speed standalone
server. If it is a very disk intensive workload, it will perform much
better, since the benefit comes from offloading the disk processing to the
400's disk subsystem, where on a normal PC type server, the intel processor
has to handle a lot of the disk workload as well as the regular processing.
In a package build, portions of which are very communications intensive,
(not necessarilty DISK intensive), and portions are processor intensive, it
is probably a wash and the net is you lose some performance because of the
communcications overhead. Also, some people recommend dual processor
systems for deployment servers, the integrated card is limited to a uni,w
hich works in a lot o environments The new 850MHz cards are a lot better
than the older, 333MHz cards, which still worked OK.

The nifty hot backup and easy switching of disk are definitely pluses for
the internal card, however, I'm not sure they are real important to a
deployment server. Depending on your environment, having a hot backup of
the deployment server redy to go, probably isn't a high priority. And
being able to have a NT4, W2k and other operating system image ready for
testing, probably doesn't apply to the deployment server either. They are
good for test boxes, or development environments, or having backup
webservers or TSE boxes, etc.

There is a new JDE whitepaper out on moving central objects, with steps on
how to do it that might be useful. I just saw it end of last week on the
Knowledge Garden. It's under the WWAT tips and techniques section,
entitled "Moving OneWorld® Central Objects to the AS/400® Platform"

Also, you can find some info on central objects and some on the Intergrated
card at:
http://www-1.ibm.com/servers/eserver/iseries/service/bms/jde-support.htm

I'm a proponent for of the integrated card, but of course, I'm one of the
IBMers that works with it, so take anything I say with a few grains of salt
:) Good Luck!


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


Sajaroff Sebastián <[email protected]>@jdelist.com on 04/20/2001
04:34:06 PM

Please respond to [email protected]

Sent by: [email protected]


To: "'jeff_carey '" <[email protected]>
cc: "'[email protected]'" <[email protected]>
Subject: RE: Central Objects on AS/400, IXS



Jeff :

a) You're partially right, if you move C.O. to the AS/400 (and you
have all your other tables there...) then you don't need Oracle anymore.
I've seen that packages builds deteriorates with C.O. on the
AS/400, remember that C.O. are read from a database. If that DBMS
resides on the Deployment server, it will be a local (and faster to
access to) resource. However, you will always need your Deployment.
It's impossible to have a OneWorld installation without a Deployment.
Deployment, among other things, creates client packages and you can't
compile them on an AS/400 box.
b) Another Horror story. Remember that NT needs quite frequent
reboots (for example, Service Packs, blue screens, software installations)
In case you need to boot your NT, you'll have also to IPL your AS/400!
Be aware that "cheap" NT will use expensive AS/400 disks, so ... if your
Deployment needs more disk you'll have to buy AS/400 disks not just
a 500$ SCSI Disk for Intel.

So, the morale of this story is :

a) A Deployment box is quite cheap now. Keep it separate from the AS/400.
b) According to my experience, fastest (and cheapest) packages build
occur on W2K/NT + MSSQL Deployment servers. Of course, I mean MSSQL
just for C.O., not for your data.
 
Hi Judy,

I haven't used it yet, (I'm in a lab environment, so of course I NEVER
backup!), but I thought file level backup and restore for the storage
spaces was added in V4R5. Are you on V4R5 or earlier?

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


lessardj <[email protected]>@jdelist.com on 04/21/2001 10:37:11 AM

Please respond to [email protected]

Sent by: [email protected]


To: [email protected]
cc:
Subject: RE: Central Objects on AS/400, IXS



We are using Xe with Central Objects on the AS/400. I am not familiar with
Oracle, but shouldn't think you'd need its client if you move CO's to the
AS/400. You would need Client Access Express if you don't already have it.

We are not live yet, and are only supporting 20 thick clients and just
starting to use some Citrix clients. Our deployment server is on the 700
INS
card in the AS/400. It has worked well for us so far, but we are wrestling
with two issues. First, when the deployment server space is backed up with
the AS/400, it is backed up as a storage space, and we have no way to
restore individual folders, files, etc from the deployment server space.
So, yes, backup is easier because it backs up along with other AS/400
objects; it's the restore that may be the problem. We need to discuss this
more with IBM and see if they have a solution for this before go-live.

Second problem may have absolutely nothing to do with the deployment server
being on the INS, but we are having performance problems with our thick
clients. Our client pcs are well about standards, AS/400 performance
monitor shows no problems, package builds are fine, and network analyzer
shows no slowdowns. So, it may just be the thick client is really slow.
Again, this probably has nothing at all to do with the INS card deployment
server, but I thought it worth mentioning.

Good luck!



JDE - Xe
AS/400 Mod830 V4R5 Enterprise Server/Central Objects
AS/400 700 INS Card - NT Deployment Server
WTS/Citrix & thick clients.

Judy Lessard
IT Specialist 4
Timken Super Precision (MPB)
603-352-0310 ext. 385
[email protected]




--------------------------
 
IBM is claiming to us that the performance actually increases, since the
IXS communicates with the AS/400 over a virtual LAN - basically over the
AS/400's optical bus. Granted, the IXS has far from the most powerful
Intel chip you can get, but it's miles ahead of out current DS.







David Silvasi <[email protected]>
Sent by: [email protected]
04/20/01 05:21 PM
Please respond to jdelist


To: [email protected]
cc:
Subject: Re: Central Objects on AS/400, IXS



Jeff-

Users should expect a performance hit during package builds if you go with
the IXS, to say the least. We recommend against using these for this
reason, not to mention cost and complexity of upgrades for both the IXS
and
OneWorld. We have assisted several clients in transitioning to the NT
platform from IPCS/IXS boards.

Package builds take longer with the IXS because the stability of using IBM
disk has the drawback of the added overhead in keeping it stable. You
won't
need the Oracle client anymore, though - there is no more Oracle database.

Personally I'd stick with the NT box.....that is my .02

Regards,
David




--------------------------
 
Hi Jeff,

Wanted to clarify one more point regarding your note below. hope this
isn't redundant, but I've heard a lot of confusion about this.

I always just think of the IXS, (Integrated xSeries server), as a regular
PC server that is using the 400 for its disk. Really the 400 is acting
like a SAN, (Storage Area Network). It is a very high speed connection
between the card and the disk. The IXS ONLY communicates over the high
speed bus for its DISK access. It gets the performance increase over
similar speed Intel processors because of offloading the disk work, since
the 400 passes I/O off to separate I/O processors, whereas the main
processor on a standard PC based server has to handle some of that disk
access workload.

The IXS generally does NOT use the high speed bus to handle regular TCP/IP
traffic, such as normal Oneworld. It IS POSSIBLE to do this, but it
normally doesn't give you any performance improvement, in fact it is
pobably worse in most cases than going over a 100Mb ethernet.

When you set up an IXS, there is a virtual token ring that gets
automatically configured over the internal bus. This sounds great, but it
effectively functions as a 16Mb token ring connection. (I'm not sure if
this is because of the added overead of making it act like token ring, or
what) About the only time it would make sense to use the internal token
ring is if you had a heavily congested network or if you wanted a
completely secure link. In most cases, going over the external card, on a
100Mb ethernet is going to perform better.

I think there might have been a statement of direction regarding changing
this in a future release, but I haven't seen it, so I don't have details.
But, for now at least, using the external network interface is probably
faster than using the internal interface for TCP/IP and other network
traffic.

As I mentioned before, I'm a proponent of the IXS, and I think they work
great in most situations, but I didn't want there to be misconceptions
about how it works and what its benefits are. please let me know if I can
answer any further questions. Good Luck!


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


jeff_carey <[email protected]>@jdelist.com on 04/23/2001 12:49:50 PM

Please respond to [email protected]

Sent by: [email protected]


To: [email protected]
cc:
Subject: Re: Central Objects on AS/400, IXS



IBM is claiming to us that the performance actually increases, since the
IXS communicates with the AS/400 over a virtual LAN - basically over the
AS/400's optical bus. Granted, the IXS has far from the most powerful
Intel chip you can get, but it's miles ahead of out current DS.







David Silvasi <[email protected]>
Sent by: [email protected]
04/20/01 05:21 PM
Please respond to jdelist


To: [email protected]
cc:
Subject: Re: Central Objects on AS/400, IXS



Jeff-

Users should expect a performance hit during package builds if you go with
the IXS, to say the least. We recommend against using these for this
reason, not to mention cost and complexity of upgrades for both the IXS
and
OneWorld. We have assisted several clients in transitioning to the NT
platform from IPCS/IXS boards.

Package builds take longer with the IXS because the stability of using IBM
disk has the drawback of the added overhead in keeping it stable. You
won't
need the Oracle client anymore, though - there is no more Oracle database.

Personally I'd stick with the NT box.....that is my .02

Regards,
David




--------------------------



--------------------------
 
Sorry this took so long to get back to you..but yes, we are on V4R5. Our
Systems person told me that he did not know how to do file level backup and
restore. Can you point me to some documentation that tells how to do this?
'Twould be greatly appreciated. Judy.



Xe, ES=AS/400 V4R5, CO=AS/400, Deployment=AS/400 INS Card, Thick & Citrix Clients
 
Back
Top