WASHINGTON AREA MIDRANGE

Newsletter - March 1999


Serving the community of IBM Midrange users.
Membership: $100.00.

























 

President's Message from Peter Maher

What Have You Done For Me Lately?

All too often we are judged by what we have done lately and when the WAM board met in January we tried to come up with some answers.

The biggest question on our minds was (and is) how can we add value to Our WAM membership. We know the JAM is the first and best value we offer and this year will be no exception. We feel that the monthly meetings serve a purpose and while not as well attended as we would hope, we know that those who come always get their money’s worth and more.

While not all the details are final I can now tell you a few of the programs we have planned for you.

The Man In The Cowboy Hat Returns!

Charlie Massoglia, who many agree is one of the best teachers of RPG programming in the biz, has agreed to come to Washington for an exclusive 1-day intensive seminar. While I do not have all the details regarding his presentation I can tell you that this seminar would cost $299.00 or more ANYWHERE else. As a current WAM member you will be able to attend this session for $100.00. (Non-members price is $150.00) Included in your price of admission is lunch and a session book, which sold for $75.00 at the last COMMON! As soon as I have the details regarding venue and time I will pass them on to you. But mark your calendars now for June 15th.

DISCOUNTS ETC

As a WAM member you are also entitled to many discounts from NEWS400 and Midrange Magazines. I would like to thank Don Rima who has done a great job of spearheading this effort. As an example of the discounts: if you register through Midrange Magazine as a user group member you can save $200.00 off the price of COMMON. You can also save $50.00 per year on Midrange Computing Magazine.

NEWS 400 has also agreed to "consult" with WAM when planning their all day seminar/"road shows". The idea here is that we will work with NEWS 400 to spread the word and in turn we will be offered the services of some of their speakers for our monthly meetings. Additionally, we will be offering a discount to our members who wish to attend the all day sessions. This is just the tip of the iceberg folks. I am sure that as we continue to develop these resources we will benefit even more."

This month’s Meeting

This month we are pleased to bring back Steve Drew from CAS. Steve will be giving us the scoop on WebSphere.

Steve has been one of our most supportive and helpful speakers and we thank him for all his contributions. If you get a chance at the meeting, stop by and thank him personally.

Lastly thanks to Mary McConnell who gave a great presentation on the features (and there are a ton) of V4R4 at last month’s meeting.

Looking forward to seeing you this month!

-Peter


AS/400 Magazine "Spotlight" Column Sports New Contributing Editor!

Washington Area Midrange Secretary, analyst, programming wizard, and raconteur, Don Rima begins new career. Be sure to see his work in the latest edition.


MARCH MEETING

WebSphere with Steve Drew

There are more questions than answers when it comes to WebSphere. Come to the WAM user group meeting to learn what you can do with this OS/400 feature. Yep, it's built in.

  • WebSphere, what is it and why do I care?
  • WebSphere, how can I use it if I'm not doing anything on the web with my AS/400?
  • WebSphere, is it more than just a fancy brand name for Java?
  • What's the difference between a Web Server and a Web Application Server?
  • XML (More alphabet soup?), what is it? Want free EDI? Learn more about XML!!
Steve Drew: Steve has been with CAS since last year. Prior to CAS Steve was with IBM for 10 years. He is located in Maryland and specializes in AS/400 Internet, Intranet, and Extranet projects. However, he brings a twist to the game in that he actually can "walk the talk". Steve works with customers answering any AS/400 e-business questions.

Tuesday Mar 16, 1999 18:00
Holiday Inn
U S Rt 1
College Park, Maryland (Parking is FREE !)

Board Meeting Immediately After !

  • 18:00 Attitude Adjustment
  • 18:30 Dinner
  • 19:15 Speaker
  • 20:15 Q & A
  • 20:30 Adjournment
RSVP (by 16:00 Friday 03/12) to Peter 703/834-3706 or 1stplace@crosslink.net $25.00/non-member


Treasurer's Message

Time to renew membership for 1999

Just a reminder that WAM membership is on a calendar year, so all 1998 memberships expired 12/31/98.

Many have already renewed for 1999. If you have not, please take care of this important task at your earliest convenience. It is your users group and your active support is needed for its continued functioning.

Sending in your check for the $100 annual fee made out to WAM will renew your membership:

    Washington Area Midrange
    12023 Blackberry Terrace
    North Potomac, MD 20878
If you have any questions about the membership, please call me at (301) 590-7121.

-K B Soni Treasurer


WAM Contacts:

Our home page is at http://www.wash-midrange.org. Send suggestions to Peter.

President: Peter Maher 703/834-3706 F) 703/834-3707 1stplace@crosslink.net
Vice President: John Blum 410/265-1300 F) - - jblum@bcpl.net
Vice President: Pam Johnson 703/978-5212 F) 703/978-5360 pjohnson@i-t-works-inc.com
Secretary: Don Rima 703/742-3744 F) 703/742-0448 dr2@cssas400.com
Treasurer: K B Soni 301/590-7121 F) 301/590-0213 kbsoni@aol.com
Past President: Jack Fugiel 301/489-1103 F) 301/474-1609 fugielj@wdni.com
Newsletter Editor: Tom Jones 301/515-4438 F) - - twjones@erols.com
At Large: Mark Grimley 703/264-0643 F) 703/264-1753 mgrimley@compuserve.com
At Large: Ross Massey 410/672-3783 F) 410/799-9066 rmassey@dpsolutions.com
Associate Director: Paul Lambert 410/381-6396 F) - - pg_lambert@prodigy.com
Associate Director: John Rodrigues 703/519-1569 F) 703/683-5100 majobo@aol.com


April Meeting Preview:

Using RPG to access the Integrated File Server
with John P. Carr, CDP

More and more information of the AS/400 world is starting to be stored in stream files on the IFS. Imagine from an RPG program summarizing, say, production after some batch run and put that summarized information in a comma delimited file so that your users could bring up the information and graph it in Excel or 123!

This session will provide examples of how to write to and read from IFS stream files using RPG IV. The techniques involve RPG procedures, calling IFS APIs from within an RPG IV program. Complete program examples will be provided.

John is President of EdgeTech, a Virginia corporation, and has 17 years experience working with the IBM Midrange environments. His expertise lies in helping companies develop and implement programming standards and methodologies. He has worked on and developed most major business applications including: Accounts Payable, Accounts Receivable, General Ledger, Sales Analysis, Production Scheduling, and Order Entry, to name a few. Through EdgeTech John has developed and markets ETIKIT (pronounced etiquette), a software package for the AS/400 that contains application program prototypes and APIs which radically increase programmer productivity and dramatically improve application consistency. ETIKIT also contains an advanced file driven menu/security system.


The following is exerted from AS/400 Application Development Software News and is included as a public service of this newsletter while some info is dated the points made are legitimate.

Is Your AS/400 Ready for Year 2000?

By Jennifer Gordon and Ian Brown

IN BRIEF:

Planning, testing, and upgrading are among the many things to consider when readying your AS/400 for Year 2000. You can't say we haven't had time to address the Year 2000 issue. As you check your watch and consult your desktop calendar, think about this: The roots of this dilemma can be traced as far back as the early days of the computer industry and the waning days of the Johnson administration. Consider that, on November 1, 1968, the U.S. Department of Commerce, National Bureau of Standards, issued Federal Information Processing Standards Publication 4. It specified the use of 6-digit dates--two digits for months (M), two digits for days (D), and two digits for years (Y)--for all information exchanged among federal agencies. Taking effect on January 1, 1970, the approved standard was MM/DD/YY. Some 30 years later, who would have guessed that general adherence of government and industry to such a seemingly innocuous standard would create such a conundrum? Who would have thought that such a simple formula would be riddled with miscalculations that could potentially disrupt the functions of governments, banking systems, and even household appliances? Who would have believed that the Rolling Stones would be better suited to thrive in the next millennium than the world's most powerful computer systems?

Of course, we're now all intimately acquainted with the Year 2000 issue. The challenge that has IT problem solvers worldwide scratching their heads, so often preached about now, is to electronically tap into the legacy applications that remain integral in many organizations, and transform all date fields from the now-infamous MM/DD/YY to an 8-digit format: MM/DD/YYYY.

Superficially, it may not seem that important, but considering how much valuable information is dependent on accurate data and date maneuvering, the implications are clearly troublesome. Nowadays, the missing digits on our checks and credit cards (that we didn't think twice about before) are prime Year 2000 suspects.

Data-deficient nightmares are the topics of choice at high-level risk management and contingency planning conferences. Scarier still is the thought that even governments, known to routinely allocate millions for damage control situations, are antsy about the Year 2000 price tag. Maybe Gartner Group's prediction--that it will take $300-$600 billion to remedy the world's Year 2000 ills--is actually rounded down a bit.

In practically any computing environment, including the AS/400 world, Year 2000 spells trouble on a grand scale. The thought of what happens when a program fails and creates erroneous data can make any programmer weak-kneed (or a candidate for early retirement). But what are we afraid of? The fear is not exactly that system software could crash or otherwise spontaneously combust one stroke after midnight on December 31, 1999. The fear is that, if not properly remediated, it continues to run (the nerve!) and generates data calculations that don't necessarily take place in this century.

Response of the Computer Industry

Year 2000 readiness efforts will be frustrating, time-consuming, and costly. Most vendors providing automated tools and consulting services have reported that the problem of making application systems Year 2000-ready is amazingly worse than they expected, and the cost will be 30-40 percent higher than originally estimated. There is also the sobering thought that many vendors will be booked by as early as this spring and unable to take on additional conversion work.

For the majority of AS/400 customers, getting to a Year 2000-ready version of OS/400 means a system upgrade.

It is important to emphasize that, given the present time constraints, strategies such as reengineering all AS/400 application systems could be difficult to implement because of the high degree of resources and actual working hours needed. It's necessary for an enterprise to carefully evaluate the risks associated with complete reengineering strategies in order to ensure that they will be able to achieve readiness. The goal is simple: Reach compliance well before the arrival of the new millennium. "Compliance" can have several underlying definitions. The objective is the ability to handle dates before and after the millennium without compromising data quality. The caveat in this instance, as everyone agrees, is time--or the lack of it. Given the modular format of many AS/400 applications, the "assessment" period should be complete and remediation steps implemented today.

Compliance Status

So what's the status of AS/400 hardware? From a hardware standpoint, all AS/400 systems (Advanced Series and AS/400e series) are Year 2000-ready. OS/400 achieved readiness with Version 3 Release 2 (V3R2) and Version 3 Release 7 (V3R7) in September 1996. V3R7 and V4R1 (released in August) only support the recent ISC-based models first announced in 1995; OS/400 V3R2 supports all CISC-based models. The vast majority of the more than 450,000 AS/400s shipped to date incorporate IBM's CISC architecture, and a significant number of these run versions of OS/400 (V3R1 or earlier) that aren't Year 2000-ready. The first task for most AS/400 customers, then, is getting to a Year 2000- ready version of OS/400. For the majority of customers, that means a system upgrade. For customers still running CISC-based AS/400s, the easiest move is to a current Advanced Series model and OS/400 V3R2, though they're not the most up-to-date or fastest AS/400s. Moving to RISC involves additional considerations, notably having the appropriate "observable" applications code or a RISC version of the software.

But wait; the choice isn't so simple. Why? Because customers who run packaged applications, or those who intend to run packaged applications (and many AS/400 users run packaged software), should select a Year 2000-ready or near-Year 2000-ready software release--and that might require a move to one of the AS/400 RISC platforms.

Activity in the AS/400 user community seems to reflect a sense of ambivalence about AS/400's Year 2000 readiness. Wealthy organizations can purchase Year 2000-ready AS/400s and then test and modify their applications, or purchase Year 2000-ready or near-Year 2000-ready packages. However, many smaller businesses--generally those that have been unable to afford upgrades and still work with older systems--are caught like a startled rabbit in a car's headlights. And others, who simply view their AS/400 as a business tool that just keeps running, may still be unaware that this computer problem affects them. Although the latter are a shrinking minority, reaching this audience is still a problem. This is especially true in Europe, where many AS/400s have been purchased by "business people," not "computer people." To its credit, the AS/400 Division has been proactive in helping its customers through the Year 2000 issue. Go to IBM's Year 2000 Web site (www.ibm.com/year2000) and have the Year 2000 readiness of your system and software evaluated directly.

Apply Yourself Applications are central to any considerations about Year 2000 readiness. Many AS/400 customers run packaged applications, and it's essential to find out the current status of those applications. Because AS/400 hardware is so closely tied to a particular version of OS/400, application releases and new versions of software are similarly tied to a specific AS/400 model and its successors. That means that customers with an early version of an application--for example, SSA BPCS 5 or Marcam Solutions Inc. Mapics 1 and 3--running on an early pre-Advanced Series AS/400 may have to upgrade to a new version or much later release, such as SSA BPCS 6 or Marcam Proteon, which only runs on Advanced Series and RISC-based AS/400s. Upgrading can pose some serious cost implications, and those changes could encourage customers to look at migrating to newer versions of their applications. Whatever the case, AS/400 users need to start considering their options right now and ascertain the migration implications associated with the packages they're using.

Conversion Plans

A good plan of action is the best approach to making your AS/400 applications Year 2000-ready. Project managers must account for a host of concerns, but the primary goal is to bring systems into compliance. The working definition of "compliance" also extends to ensuring that data is passed in the right format before and after 2000, and even the fact that 2000 is a leap year. It's wise to devise several project plans to meet the goal of compliance. The project plan is similar to the objectives created in simple problem solving, except this plan is specific in addressing an AS/400 date-related dilemma. Achieving 8-digit compliance will become a less elusive goal if all project planning criteria are accounted for. Flexibility is needed, as some portions of your efforts may require more or less time to address a specific area in more or less detail.

Testing your changes is also an essential part of the conversion plan. Small changes made in one part of one program can dramatically affect another program. It is essential that the changes made be 100 percent correct; thus the necessity to test accurately. Testing provides the opportunity to avoid disaster by managing the consequences offline. The testing process should, at the very least, encompass the following steps:

1. Testing data fixes on individual programs

2. Integration testing every time a program is put together with other programs. This step requires regression testing whenever an error is discovered and corrected.

3. Volume and systems testing

4. Year 2000 simulation testing

It is important that the test data be rich in dates so that all date-sensitive areas of all modules are tested. In some cases, test data has uncovered date-sensitive areas that were not discovered during the earlier identifying process. The success of the AS/400 readiness effort will depend on the thoroughness of the test planning process and how extensively both the test data and the testing process are implemented. The entire testing process can consume a large amount of time, so be sure that adequate resources are allocated to cover all bases.

An Added Consideration For European users: In 1999, the European Union introduced a single "Euro" currency for member states. Not all European countries will join or be allowed to join, but all businesses that export goods, import materials, or do any kind of business in Europe outside of their own country will be impacted. At the very least, organizations will have to reprogram their software to take account of Euro transactions and deal with an additional currency running in parallel with their existing currency.

Businesses in countries that sign up to the Euro will have to produce and maintain accounts in both their home currencies and the Euro for the first few years of the latter's introduction. Again, customers should consult their software suppliers at the earliest possible occasion to find out the status of "Euro-ized" versions of their applications. They should also start looking at in-house applications immediately. The strategy and processes for assessing and dealing with the problem should be similar:

  • Identify which applications are used and which are affected.
  • Set priorities and a time frame; assess which applications are essential to change and start working on these first.
  • Consider the alternatives--upgrade to Euro-ready applications if and when they're available, buy a new Euro-ready package, hire additional programmers, look for a Euro service provider. Some vendors are already reflecting sales that are 100 percent ahead of plan worldwide due to the combined requirements of Year 2000 and the Euro. Either way, you should learn from your experience with one or the other of the problems. If we didn't know much about legacy code and conversion techniques, Euro and the Year 2000 dilemma are sufficient tutorials for future data migration projects.
Application Analysis Remedies

As mentioned, if you're not already on OS/400 V3R2, V3R7, or V4R1, an upgrade is necessary. If you're on an Advanced Series system running either V3R1 or V3R6, then, from a platform perspective, you're well off--you just need to update to V3R2 (CISC) or V3R7 (RISC). If you're not an Advanced Series OS/400 Version 3 user, then you've got more of a problem and greater expense. Because your existing applications may not be Year 2000-ready, you can't just look for a Year 2000-ready version of OS/400 and install that on your AS/400. The logical step would be to go to an Advanced Series model. Migrating from CISC to RISC is relatively straightforward, as the system itself will translate your software into the binary code that can run on the RISC processor. There's one proviso, though: You have to have the program template or "observable" code for the new system to be able to do the translation. If you don't have access to the observable code--because the original software supplier's no longer around, or you don't know where the code is stored, or you've wiped it out, or you never had it, etc.--that could be a problem. It may be easier to go with a CISC-based Advanced Series model and just concentrate on the Year 2000 issue. IBM development is no longer enhancing the CISC models, and V3R2 obviously doesn't have the functionality of V4R1, but at least they're still available. (With the advent of RISC models, more Advanced Series models are on the second- user market, and prices have tumbled accordingly.) If you've decided on a new packaged application and you don't want to transfer volumes of data to a new system, then the RISC systems--in particular the new AS/400e series--offer significant performance benefits. The AS/400e models are up to 13 times more powerful than the CISC-based Advanced Series. You'll also benefit from new features in OS/400, including integrated Internet software, improved PC interoperability, and forthcoming support for Lotus* Domino* server.

If you're purchasing new packaged software, it's likely you're also purchasing client/server rather than host-based

interactive applications. If you are, you can also benefit from purchasing the much less expensive e-Server models, which are from 35-75 percent less expensive than the equivalent interactive e-System models. The success of the AS/400 readiness effort will depend on the thoroughness of the testing process.

Finding Help

Often, an organization does not have the resources in-house to handle a problem as labor-intensive as code conversion. In such cases, an organization may outsource the job. Organizations should assess the pros and cons of all outsourcing arrangements, and keep in mind the impending deadline on this project. Thanks to gazillions of lines of code written over the last 40 years, a personnel shortage of experienced pros skilled in relevant programming languages exists. Senior Staff 2000, a California staffing resource company, is even preparing to introduce retired COBOL and assembler language programmers back into the workforce. Additionally, an organization should be prepared to devote approximately 22 percent of its total IS resources to addressing the Year 2000 issue. If you simply want to be rid of any date-related anxiety, there's the option to migrate to a Year 2000-ready product. For instance, if you're of the mind-set that new equals better, then SmoothStart service for BYPASS2000 provides an IBM service specialist to install and configure the new release of the OS/400. They'll even include HIPER program temporary fixes (PTFs) and cumulative PTF packages on your system. Whichever route you decide to take, remember the deadline and calculate realistic milestones into your project plan.

Y2K and the Future

Your Year 2000 project will require a lot of time, effort, and revenue, but most business necessities require this level

of attention. Use the Year 2000 dilemma as an opportunity to fully understand your organization's AS/400 environment and how its efficiency can be maximized well beyond the arrival of the year 2000. It will be an invaluable project management learning skill, and time well spent in one of the most meaningful IT transition challenges to date.

Respectfully submitted:

    Peter S. Maher - WebMaster
    Tom Jones - Newsletter Editor


Latest Update - March 1999