Slip this advice into your briefcase as you pack for your trip.

by Barry DiGiacinto

You just got the news - your company is expanding into the international market, and it is up to you to ensure that the systems everyone in the U.S. has been using for years will all work overseas. At first you are excited about some business travel to Europe, but then you begin to hear people talking about reciprocal trade barriers, the EEC (whatever that is), 1992, and NUCs.

Suddenly your excitement starts to wane, and you feel the cold fingers of fear begin to clutch your psyche. You have visions of processor checks in Germany and twisted pair shorts in Paris just as the books are closing.

Relax.

While developing and installing systems in the international market has its own set of pitfalls, they can be negotiated. Some of them have been around for years; read on and we will review them. Others are new with the changing political situation in Europe, and you will just have to meet them head-on, and cope. Remember, behind every silver cloud is a dark lining...or something like that.

Working in the Community

Last year, in order to become more economically competitive with the U.S. and the Far East, the major nations of Europe were all signatory to the European Economic Community (EEC) treaty. This will effectively lower all international trade barriers within Europe by 1992, making it possible for businesses in one country to deal with those in another, without any import taxes or tariffs.

When you consider that Paris is closer to London than L.A. is to San Francisco, and Milan is closer to Frankfurt than Manhattan is to Boston, it does make a lot of sense.

Problems with the Computers

The first thing you must plan for is that the local employees in each of the countries to be automated will probably want to see all system messages in their own language. That means you must order a second copy of all system manuals for each site, in your own native language.

Asking a local employee to translate a system message will probably result in "The mouth of the table is not open now...", or something equally helpful. Try to have the manuals on-site before you arrive - trust me.

Date Format

The next thing you should be aware of is a "bug" in the SSP (for those of us still supporting the S/36). It seems that the date format is extracted from the operating system at the time of compile, and written into your object module.

So what? Well, some countries use a local date format of DDMMYY, not MMDDYY. Importing an object in this case will result in UMONTH (set at time of compile to be the first two bytes of UDATE), returning the day, and UDAY returning the month. When you reformat for your files to YYMMDD (either through a data structure or the time-tested MULT routine), you will actually get YYDDMM. Think about what that will do to your sorts!

There are two fixes for this unpleasant situation:

1) Less than perfect, but easy: in every program's source, you can specify the date format on the H-spec, in column 19. This will force the RPG compiler to understand what date format UDATE is in, and adjust UMONTH and UDAY accordingly. It also means you need to maintain two copies of your source.

2) Perfect, but a little involved: it is possible, by way of an Assembler subroutine, to have the system tell you the date format UDATE is in. You can then code a section of your housekeeping subroutine to "flip" UDAY and UMONTH back to their correct values.

The AS/400 is not free from this bug, although it takes a different form there (all of you guys migrating, beware that one bug will be replaced by a different bug).

The RPG compiler does not care about system value QDATFMT, where the system keeps track of the date format. All the RPG compiler cares about is the value coded in column 19 of the H-spec:

o 'M' or blank produces the MMDDYY format for UDATE.

o 'D' produces DDMMYY.

o 'Y' produces YYMMDD.

On the AS/400, however, reserved words UDAY, UMONTH, and UYEAR are correct according to column 19 of the H-spec.

Solutions to the above:

1) Maintain two source objects for each program, each with the H-spec indicating what date format your program should expect to work with.

2) Write a CL program to return the values of QMONTH, QDAY, QYEAR, QDATE, and QDATFMT to your RPG program.

3) Remember to make your reports and data entry validations conform to local format, so that your system will accept a day of 31, whether it's entered as 12/31/91 or 31/12/91.

Local Currency Symbol

While you have your RPG manual out (and I know you do), you just noticed column 18, "Local Currency Symbol," didn't you? You are right, that is something else you must contend with.

In the U.S., our "$" is a hex 5B. Unfortunately, this is not reserved internationally for the "$" symbol, but is used for the concept "local currency symbol". Therefore, in England you get a Pound Sign every place you put a 5B. Did I say #? NO. I said Pound Sign. The local currency is the U.K. Pound. Hence the Dollar Sign, becomes the Pound Sign, or .

Just to add to the confusion, most E-Mail networks, word processors, and even our minis are helpful enough to automagically translate the $ to the local currency symbol, without an abend, or any message that the translation has occurred. Imagine all your lovely reports detailing $'s Sold Year to Date, now reading Pounds Sold Year to Date. Think about memos stating "You are authorized to disburse $150,000..." being read and printed abroad as "You are authorized to disburse 150,000 POUNDS..." As the pound is currently trading at around 1.75 USD per, you could misstate corporate revenue, incorrectly bill your clients, issue invalid checks, all without a single warning from the system!

What should you do? Never use the dreaded hex 5B. Always use the internationally standard three-byte currency codes (USD, UKL, DMK, and others). On reports, screens, even in written correspondence - and especially E-Mails on any system - better safe than sued.

Other Special Characters

Remember our friend the Pound Sign, the ? Well, he has an identical twin brother, the pound sign, our old friend #. This lovely little hex 23 is also a pound sign, right? So take one guess how it is printed...you've got it. Once again, the . You now have RPGLIB, LIBRARY, and SDALIB. Now you understand why IBM used "Q" on the AS/400, right? They avoided special characters like the plague, and so should you.

Think about doing field maintenance to a program. You have to alter a field used to track record number. You named this field in the U.S. as REC#. Now when changing the program you have no choice but to modify REC. Did you get a hex 23, our number sign, or a hex 5B, the currency Pound Sign. Who knows? It's a crap shoot.

Bring the code back to the U.S., recompile, and suddenly REC# translated in and out of a European RPG compiler, has become REC$. Just like magic, nothing up my sleeve, no mirrors.

I do not mean to imply that this translation problem occurs only with England, and only with the $ and #. Unfortunately it occurs in all countries, with most special characters.

The # becomes the % in the Spanish SSP, and the # does not appear on the keyboard. So in Spanish you have %LIBRARY and %RPGLIB.

The special character sets in other countries are used to insert their local letters. What may have been a perfectly happy "@" in the U.S. has become umlauts in Germany.

What to do? To ensure that you can always maintain your source wherever in the world you find yourself, and read it for that matter, never use special characters, on a report, screen or even in your source code. RECNUM, or RECRRN is safe, while REC# is simply asking for trouble.

Now that we have covered some of the operating systems and compiler problems, let's move on to hardware. Yes, you have to worry about hardware too.

Hardware Hurdles

As we have already discussed, keyboards are different in every country. Please pay attention: there will be a test. I did not say "different in every language," I said "different in every country," and I meant it.

Our English keyboard is different from the U.K. English keyboard. By the same token, a Spanish keyboard is not the same in Spain as it is in Argentina. Naturally the keyboard is different between languages, but keeping the language constant does not ensure the same keystroke pattern and ASCII map.

What problems does this cause for the IS professional? What would happen if you purchased all your terminals (or PCs) in the U.S. due to a corporate policy of volume purchasing for discount purposes? You would get a good deal on price, but the users abroad who touch type in their own language would not be able to use them.

Your fault. You should have known. It was your job to know. Can you hear it already?

PC Firmware "Fixes"

Having installed a U.S.-manufactured PC in Argentina and returned home, the local PC wizard placed a driver call into the AUTOEXEC.BAT which remapped the keyboard to their local layout. This PC was for a U.S. employee working locally long term. She typed in U.S., but her secretary typed in the local format.

This worked flawlessly on all locally acquired software, including Lotus and a word processor. However, this driver and the 5250 emulation card did not get along at all. Trying to debug this over the phone was not a lot of fun.

Our final solution was to place the driver call on a PC menu, taking it out of the AUTOEXEC.BAT. Then using the mini connection, the user rebooted the PC and executed the twinax link without demanding the run of the driver. That avoided keyboard remap conflict.

German Modem Monopoly

With all the news about Germany, you would think someone would have mentioned the following problem. All German modems are produced by their Post Office. You cannot use a non-German modem in Germany. Just to add a touch of anxiety to your life, these modems are not compatible with any other modem you can buy.

Did I hear the sound of analysts dropping like flies?

It's true. A U.S. modem would take an "A" and say beep. A German will take an "A" and say bloop. There is zero compatibility. If you have to dial in, or connect to a German system, you must have a German modem at both ends.

Now I can hear you schemers plotting. "How will they know? What business is it of the government what modem I use?"

Once you leave the U.S. behind, you must realize you have become subject to your host country's laws. You may be an American, but if you break the law abroad, you have to pay the price, abroad.

Most foreign countries believe in corporate and personal liability. If you as the systems person install a non-German modem you can be held personally liable. Go to jail, go directly to jail, do not collect 350 DMK.

Getting In and Out Without Going to Jail

To truly appreciate personal liability, you must go to South America.

To obtain a business visa to some South American countries, you must show proof of financial stability (a recent pay stub and a copy of a bank statement), produce a letter from your local police attesting to your lack of a criminal record, and a letter from your company stating they agree to be "financially, morally, and ethically liable for you during your stay..."

What this translates to is if you try to "sneak just one little PC card" into Brazil in your luggage and you get caught, all your possessions are confiscated, and you are deported. Of course, this only happens after you are strip-searched, fined, and detained by the police.

Usually it is best to obtain a "tourist" visa. If you go to visit your good friend who just happens to be the controller of the local office, and you just happen to stop by for a few days...you get the picture.

If however, you enter the country on a business visa, the following may happen. It has. "You performed business, yes? So, in other words you earned money while you were in our country, yes? We have here a copy of your paycheck from your visa application, so we know how much you earn per week. You were here for four weeks. You must pay our tax on the money you earned while you were in our country. The tax is 60% of your gross, we take only cash, U.S. Dollars. Pay now, or you can't leave."

This may have been only one greedy customs official, but are you going to argue with the man holding the machine gun?

To be safe, always check with the consulate of the country you are visiting, your corporate travel agent, and most importantly, the local office in the country for which you are headed. Be sure to ask for the true practice, not the official policy.

One final word about visas: do not assume that what was true last year is still true. Over the past three years, France changed the rules four times. You needed one, then you didn't, then you did, but now you don't. Really.

Moving from government problems getting into and out of countries, next comes dealing with local laws during your stay.

Einfach Es Ist Nicht! (or, Easy It Is Not!)

If you are going to be working in Germany, you must come to grips with the German Labor Council (smile when you say that). Even if all your systems are fully approved by your internal auditors, your domestic users have small statuettes of you on their terminals as the patron saint of User Friendly Systems, and your upper management is nominating you to the board of directors in recognition of this masterpiece, the Labor Council can still say nein, and you cannot install.

No, I'm not kidding. You are awake, this is not a bad dream.

First, if there is any form of productivity tracking at all, the system is illegal. If you write User ID into your records, and the system tracks number of records entered by each data entry operator, you cannot install. If you can tell who entered which record, and managers can hold the clerks accountable, you cannot install. If you monitor keystrokes via an assembler subroutine, you cannot install.

Each system must be reviewed by the Labor Council for approval. Be prepared to be debriefed, cross-examined, and put through the wringer. You have to reveal a lot more than name, rank, and serial number. Bring Valium.

Once (or if) your system is approved, your physical site plan must also meet very stringent standards. We were required to have "a window with a northern exposure over the data entry operator's left shoulder," or we could not install CRTs.

Additionally, we had to install "backup terminals in the event of failure." However, when we did have a cable shot, the operators sat in front of the dead tubes. When asked why they didn't move to the backup devices, the reply was "we have not been instructed to do so by our supervisor."

Value Added Tax

Now that you have entered the country, and you have gotten approval to install your system from the local union, you must meet with the government to establish their requirements for automation.

Many countries abroad charge VAT, or Value Added Tax. This is a surcharge on the amount the raw materials were worth when you obtained them, versus what your finished good/service was worth when you sold it.

Now it gets complicated...some raw materials are not VATable, and some finished goods/services are also not VATable. Further, some countries allow you to deduct the VAT you paid for the raw materials from the VAT you charge for the finished goods. This creates VATable vendors, and nonVATable vendors, VATable finished goods/services, and nonVATable finished goods/services.

Okay? Deep breath.

Naturally, each country's reporting requirements as far as reporting VAT collected, VAT paid, VAT liability, VAT discounted, and so on are totally different from every other country's requirements. But one thing remains the same - you must always track explicitly not only how much you paid your vendor, but how much was for product, and how much was for VAT. Likewise, you must track how much you charged your customers for your product/service and how much was for VAT.

When dealing with the local VAT authorities, you must also check the approved format of your output. For example, I learned the hard way that, in the U.K., if you invoice your customers at a summary level, the invoice is nonVATable. However, if you break out a detailed list of charges, the invoice becomes VATable. Why? Who knows. But that is the law, and if you suddenly make your company VAT-liable when they had never been previously, they may throw you out with your system.

Italian Tax Stamps

One last consideration is that of certification. What is that? In some countries, all legal documents (such as invoices, checks, and inventory statements) must have a government stamp on them, or else they are illegal. Italy is an example of a country with such a requirement.

Before deciding to regionalize your European processing, check local requirements for certification. Maybe you must have a remote that will dial in to a system so that documents can be printed (legally) locally. It may make sense to have all processing for central Europe done in Switzerland, and yet it may not be legally possible.

The Fate of Your Time-Tested Software

Now that you are ready to burn your passport and hide, let's look at your software for possible problems.

Field lengths that may have plenty of space for U.S.-based systems will be woefully small for foreign currencies.

What do I mean? Last year the Yugoslavian Dinar shot up to 150,000 to 1 USD. If your "amount" fields were defined at 9.2 or 9,999,999.99, that would have only equaled 66.66 USD. Perhaps you should store your history in USD, and add a new field of conversion rate. This will allow you to back-convert to local currency at a future time to recreate local amounts.

Naturally, your reports and screen fields must also handle columns up to the hundreds of billions.

When speaking of converting from one currency to another, it is important to mention that there is nothing as critical to a successful system. Some businesses require a monthly rate master, others require a weekly rate, others a daily, and certain stock or commodity applications require an on-line feed.

Will you divide or multiply? Do both. Present a screen to the user so he or she can enter it in the format required in that country. While you are at it, be sure your conversion rate field is big on both sides of the decimal place. Remember the Dinar! If the Yugoslavians had to divide, 1/150,000 yields a conversion rate of 0.0000066666. Plan ahead.

The concept of a Neutral Unit of Currency, or NUC, should also be mentioned. As opposed to converting from one currency directly into another, some applications require you convert from local to NUC, then from NUC to U.S. Dollars.

Sometimes the local government issues the conversion rates. Sometimes it is the national paper. In the U.S., most companies use the Tuesday edition of the Wall Street Journal. Maybe your users will have to keypunch out of Pravda - who knows?

Field editing also changes. The length of telephone numbers is a function of custom in each country. Unfortunately, 1-000-000-0000 is only the standard for the U.S.

A real shock is Zip or Postal Codes. In most countries they are alphanumeric, with 1AS 5SW being a valid value.

Lost in Translation

Finally, take a long look at your foreign staffing. Do the people understand English? Not just the office managers that you deal with. The worker bees who capture the data and produce the reports are critical. If they will not be able to read your screens, benefit from your help text, or understand your message numbers, you will have to translate them also.

Why? Well, do you really want to get lots of phone calls at 8:00 AM Frankfurt time? In my time zone, that's 2:00 AM. One call a week from each of several European locations translates to rarely getting an uninterrupted night's sleep.

Nothing you do will prevent all of the support calls, but the more work you put in up-front, the more calls on the back end you will prevent.

If you take the time to treat each installation as a unique event, and your users see that, they will meet you more than half way. Lose your "Ah'm un Uh-mur-ic-un, let me tell all ya fool foreigners how 'ta run the office" attitude, and listen.

Listening is our best tool, domestically and internationally. Giving users what they need and want is ultimately our business. Doing it well is our craft. Keeping users happy is our art.

Venturing forth from the womb of the good old U.S. of A. can be scary at first, but soon it will become one of the most rewarding experiences you can possibly have. Making friends all over the world is terrific, and knowing one of "your" systems is running five thousand miles away, on the other side of the planet is very satisfying, trust me.