Well, finally we have a question that is self-answering! To be fair, established Client Access shops that cannot afford (in terms of retraining and so on) to make the switch to Transmission Control Protocol/Internet Protocol (TCP/IP) yet may not want to dump the nostalgic world of 1980s-style software, such as Client Access/400. But new installations should take heed of the new paradigm. To wit: Client Access (aka PC Support) is not, and doesn't seem like it ever will be, as solid and robust a product as TCP/IP.
Gee, let's just take a quick tour of some of the functions of Client Access vis-?-vis TCP/IP. You say you want file transfer? It's called FTP, and it's a drag-and-drop affair in many TCP/IP applications. Need 5250 emulation? Try TN5250. Shared folders or Virtual Print, you say? Hmm, how about NFS? Printer Emulation is an issue, you say? Well, habla LPD?
On another front, how many companies are working on Client Access enhancement products per se? A handful. How many companies are enhancing TCP/IP with slick GUI interfaces, drag-and-drop ease, and native Windows support? A zillion.
Documentation in Client Access? Don't make me laugh! TCP/IP, on the other hand, has been documented to death! You can't swing a box of dead OS/2 Warps without hitting a TCP/IP manual or article.
"Protocol coexistence," I hear you mutter. Dude, TCP/IP will coexist in one form or another with, well, anything!
Yep, the case seems clear-cut to me. Why would anyone in his right mind choose Client Access over TCP/IP? The answer is no one would.
-Kris Neely
Hey, Kris! Now here's an issue that's as controversial as...H20! Comparing Client Access to TCP/IP is like comparing bottled water to champagne: both liquids, right?
These two elements of the AS/400 tend to be confusing. But don't equate them. Next thing you'll be saying is that no one who has a LAN needs an AS/400. They're different by magnitudes, arriving now at the same place through different pathways because, quite simply, we need them. TCP/IP and Client Access/400!
TCP/IP is not a product. It's a service protocol that's now-finally-available in liquid form for the consumption of AS/400s. Client Access is a product. It makes use of the System Network Architecture (SNA) service protocol. IBM's gone to some significant expense to evolve Client Access from PC Support. Why? Because we told them to!
But is TCP/IP for everyone? That's the real question! In my opinion, yes, it could be. Eventually! Just as soon as we get people converted.
What do I mean? Well, PC Support has been around for so long that IBM has thousands of users running it. And I'm not talking about the more sophisticated uses of shared folders and file transfer. Just plain old 5250 emulation. How big a job do you think it will be to convert all of them? And what advantages would they get? Better terminal emulation? Big deal! Show me some real advantages to start a mass conversion, and I'll put it on the project board. We'll get to it! When? Right after you finish that last project you started of converting everybody to ATM!
Thank God IBM finally has TCP/IP up and alive on the AS/400. We've been asking for it for years, ever since the AS/400 came out. But thank goodness Rochester isn't dropping Client Access yet. It may not be the champagne you've been sipping, but it's a lot better than the tap water.
-Thomas M. Stockwell
Please, there's enough confusion about communications issues.... Let's not muddy the water. TCP/IP is a communications protocol; Client Access is a client/server application targeted at the AS/400.
Because TCP/IP is the protocol used by the Internet and many other computer networks, it's huge! It seems the whole world is using it. If there are computer networks on other planets, they probably use TCP/IP. It's no wonder that IBM includes support for TCP/IP beginning with the new V3R1 release of OS/400.
At this time, the majority of AS/400s use IBM's SNA and its APPC protocol, but I predict that you'll see a shift toward the TCP/IP protocol as more AS/400s integrate with other computer networks. PC Support (the predecessor to Client Access) requires the APPC protocol; Client Access does not.
Now, let's look at Client Access. Client Access is a client/server application package that provides client-centric access to AS/400 resources. It allows PCs to exploit the best of what the AS/400 has to offer, such as the DB2/400 database and the Integrated File System (IFS). Client Access also provides a rich set of APIs including open/standard interfaces such as ODBC, MAPI, and VIM. Client Access is a standard on which many PC products are built. There are numerous other client/server applications, including those built specifically for the TCP/IP protocol, but... none of them are quite as robust in AS/400 function as Client Access.
So we have a communication protocol and we have a client/server application. This is not an instead issue-it is an and issue. If you need the TCP/IP protocol to communicate with a network and you want the rich set of AS/400 client/server functions that Client Access offers, you can choose both. I use the TCP/IP protocol and I use Client Access.
So, right mind?... wrong mind?... I don't think it's a question of right or wrong. It's a question of what protocol and what applications meet your needs.
-Richard Shaler
The day you load V3R1 on your system is the day you can stop using Client Access. TCP/IP is a better way to attach your PC to an AS/400. There are many advantages to using TCP/IP applications instead of Client Access.
With V3R1, TCP/IP is included free as part of the base operating system, so there's no additional expense. Most PC operating systems also provide TCP/IP for free. You'll have to pay extra if you want Client Access, though.
TCP/IP is an open standard that's supported on most platforms. You can use TCP/IP to connect to almost any type of system. Client Access is proprietary. It will only connect your PC to your AS/400 and nothing else.
TCP/IP applications are rich in functionality. Almost everything you can do with Client Access you can also do with TCP/IP. Tons of TCP/IP applications let you perform such tasks as signing on to the AS/400, transferring files, and accessing AS/400 disk.
I've found that TCP/IP applications tend to perform better and use less PC memory than Client Access applications. IBM claims it will soon support the ability to run Client Access over TCP/IP (i.e., AnyNet). While this may sound like a good idea, I doubt it will be very usable. As in any situation where you're running one protocol over another, it's probably going to be extremely slow.
If you've used TCP/IP for other purposes, such as connecting to the Internet, then you already know what it has to offer. If you've never used TCP/IP before, then V3R1 is the perfect chance to get started; there's never been a better time. Take advantage of what TCP/IP has to offer and leave Client Access behind.
-Robin Klima
Being the instigator who created MC's network using TCP/IP (and NetBEUI, by the way), I'm not going to argue too strongly for Client Access. For years, I've considered PC Support and Client Access to be excessively bloated products that we unfortunately have had no real alternative to. With V3R1, using TCP/IP became a practical alternative. Not, as Robin says, because of price-it wasn't that expensive before-but because of performance and support. With V3R1 TCP/IP Connectivity Utilities, we finally started getting decent response time and a useful set of TCP/IP utilities.
Even the new Client Access for Windows is a poorly written application that I would use only as a how-not-to-write-a-Windows-application example. The only justification I have for using Client Access right now is that the V3R1 ODBC driver is a very good ODBC driver. (It is so good I suspect some other company wrote it for IBM.) However, I'm looking at a number of tools that make WinSock programming easier, which would make Sockets a reasonable alternative to ODBC.
About the only argument I can make in favor of Client Access is that I think it is actually easier to implement in a small shop than TCP/IP. If you don't have someone in your shop who understands topics such as subnet masks, DNS, DHCP, and WINS, implementing TCP/IP can be a challenge. We found that out here in the process of testing Kris's "Configuring TCP/IP on the AS/400" article (elsewhere in this issue); people who weren't familiar with those topics ended up bringing our network down. Running Client Access is pretty much a load-and-go proposition compared to fully configuring TCP/IP.
Other than for those smaller shops, thank goodness, we can finally say, "Client Access is dead. Long live TCP/IP!"
-Jim Hoopes
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online