AS/400 asynchronous communication is funny. Not funny ha-ha, like a performance by Robin Williams or Whoopi Goldberg, but funny in that it comes in so many different flavors it’s difficult to decide which one is right for you.
Take dial-in access to the AS/400, for example. Most people think the only way you can reach the AS/400 over phone lines is to use Asynchronous Client Access, NetSoft Midrange Bundle, or some other packaged dial-in 5250 emulator. These packages are valuable in that they offer you a full range of features any remote user might want—things like remote printers, shared folders, file transfer, and the like. However, they are expensive in terms of performance and price.
If you’re not able to run Asynchronous Client Access 3.1 for Windows because you haven’t upgraded yet, you may find yourself fussing and fuming with a somewhat kludgy Asynchronous Client Access 3.0.5 or PC Support 2.3. If you get a more elegant solution, like dial-in NetSoft Midrange Bundle or RUMBA, you get good performance and a stable native Windows product, but you typically pay a price of $200 to $300 for each dial-in seat.
But what about different types of users? What about a salesperson on the road who doesn’t need an AS/400 printer attached to a laptop? How about a customer who wants dial-in access but doesn’t want to be bothered with CA/PCS DOS routers or shared folders or any of the other baggage that came with IBM’s pre-V3R1 solution? What if you have no control over what the software/hardware people are using to dial in to your AS/400s? What if the only thing you know for sure is that they have a computer and a modem? They neither want nor need additional software from you, and they want to call in from their current environments. How do you provide dial-in access in these cases?
Fortunately, there is a solution: dial-in VT-100 emulation for the AS/400. VT-100 emulation is a simple, no-frills terminal emulation that has been in use for years in
the communications world. Using a standard IBM PC and a modem, and another modem attached to your AS/400 ASCII workstation controller, your users can easily dial in to your AS/400 as a VT-100 terminal, get whatever information they need, print the screens, and hang up. No Asynchronous Client Access or PC Support and no expensive software packages. On the client side, if you have nothing more than Microsoft DOS 2.0 or above, you can dial in with almost any communications program.
The Basic Ingredients—Hardware
To perform VT-100 emulation, you only need a few basic ingredients. First, you need an asynchronous workstation controller on your AS/400. This controller must have one free PC modem that is not already configured for Asynchronous Client Access or another special purpose. The modem is only to be used for asynchronous VT-100 dial-in.
On the PC side, you simply need another modem and a communications package. In researching this article, I used ProComm Plus, but this configuration works with any other communications software that runs VT-100 emulation. A good communications package costs between $100 and $150 on the street. However, if you want to do this configuration on the cheap, you can use the freebie communications program Microsoft gives you with older versions of Windows—the Terminal program. The down side of using the Windows Terminal program is that it has been replaced in Windows 95 with a program called HyperTerminal that is not as easy to configure for VT- 100 emulation as the old Terminal program. So, when you upgrade to Windows 95, you also need to upgrade your VT-100 solution.
Armed with these basic tools, let’s discuss how to do it.
The AS/400 Side
The first step is configuring your AS/400 modem for VT-100 access. In an earlier issue, we discussed the steps needed to attach an ordinary Hayes-compatible modem to the ASCII workstation controller (see “PC Modem Equipment on the ASCII Workstation Controller,” Sept/Oct 1995 Client Access/400 Expert). The steps in that article tell you how to configure a modem for VT-100 access. In particular, pay attention to the type of modem cables you use, setting the NVRAM initialization string for the modem and any special dip switches that may need to be set on your modem to put it into autoanswer mode or to modify certain parameters upon answering.
Once your modem is configured and attached, you need to configure the ASCII workstation controller port for asynchronous VT-100 communications. This is a software configuration performed in OS/400 that allows your modem to be treated as an autoanswer VT-100 device. To set this up, you need two pieces of information: the port on the ASCII controller to which the modem is attached and the AS/400 controller name of the ASCII workstation controller. For our example, let’s assume that the modem is attached to port 01 on the CTL02 controller.
To designate this modem as a VT-100-compatible device, create a new device description for the port by typing in the Create Device Description (CRTDEVDSP) command. A sample printout of the CRTDEVDSP command to create a dial-in VT-100 device on ASCII port number 1 is shown in Figure 1.
From here, configuring your modem for VT-100 access is simply a matter of filling in the right parameters. This is a relatively painless job, but there are a few twists and turns in the road. For our sample configuration, here are the values you fill in for each field.
Device Description: The name of the VT-100 device you want OS/400 to create. Device Class: Whether or not this is a local, remote, or virtual device. For VT-100 emulation, your modem is a local device attached to your workstation controller. It is classified as a local, rather than a remote, device because it is attached locally to your AS/400 through the ASCII controller.
Device Type: Tells OS/400 this is a VT-100 modem when you select V100 as the device type. Device Model: Tells OS/400 what type of terminal or workstation the device is and what features it has. In this case, you do not have to specify a terminal type. Specifying it as an *ASCII device is satisfactory.
Physical Attachment: For asynchronous VT-100 modems, select *MODEM.
Port and Controller: Specify the port and the name of the Asynchronous Controller to which this modem is attached. In this example, that is port 01 and controller CTL02.
Emulating ASCII Device: Tells OS/400 whether or not this controller should accept the defaults for the device specified in device type, or if you can specify parameters outside of the OS/400 defaults. If you set this parameter to *YES, you are able to override the Line Speed, Word Length, Parity, and Stop Bit parameters with values that may not be listed in OS/400. Specifying *NO enforces the limits OS/400 may place on a VT-100 device. Select *YES.
Line Speed: Specifies the maximum physical speed at which your modem is able to communicate. Always set this to the highest value for which your modem is rated. When a connection is made, the AS/400 modem and the dial-in modem negotiate a suitable line speed for communication.
Word Length, Parity, and Stop Bits: Specifies the number of bits used to transmit a single character, what type of parity checking is used, and how many bits are used after each character to signify that a character has been sent. There are many choices here, but the standard, safest choice is to specify a word length of 8 bits, no parity checking, and 1 stop bit.
Text: A simple description that is attached to the device for information purposes only.
After you type in this information, press the Enter key. A new device description is created for that port. The modem automatically goes into autoanswer mode, and your AS/400 becomes ready to receive and process callers dialing in as VT-100 terminals. Any terminal dialing in to the AS/400 that matches the parameters specified here can start a display session on your machine.
The Personal Computer
It’s time to turn our attention to the client side of the configuration—the remote PC. The beautiful thing about dialing in as a VT-100 terminal is that most communication packages have default settings for this configuration. This is true in ProComm Plus, and, in the Windows 3.1 Terminal program, it’s one of the three standard terminal emulation options. It’s easy and it’s everywhere. You just have to make a few adjustments to make it work with the AS/400. There are three things to set for dialing in as a VT-100 terminal.
First, set your communications package to dial in as a VT-100 terminal. This sounds like a simple tip, but communication packages can be set up to call in as all kinds of wild devices. Make sure yours (or your customer’s) is set to VT-100.
Second, set your word length, parity checking, and stop bit parameters correctly. As with the AS/400 configuration described above, there are options for changing these parameters to almost any configuration you like. However, this
configuration must match your AS/400 modem configuration to work. Make sure you write down that configuration and pass it on to anyone who wants to dial in. Most communication packages allow you to change this configuration as a default or to change it on the fly as you dial in.
Third, reconfigure your keyboard for AS/400 emulation. For most communication packages, there are several vital AS/400 keys that are not mapped in the VT-100 keyboard package. ProComm Plus, for example, has no mappings for AS/400 function keys F1 to F24, the Roll Up and Roll Down keys, the Home and End keys, and Field Exit. All of these keys must be coded into your user’s configuration. In an earlier issue, we included an article on keyboard remapping for ProComm Plus (see “AS/400 Key Remapping for ProComm Plus,” May/June 1995, PC Support Expert). In that article, Joe Gendron discusses the procedure for remapping keys and gives the actual key mappings for the function keys, roll up and roll down, and the escape key. Figure 2 expands upon Joe’s original list of key remapping, adding the ASCII decimal code for each key, as well as several additional keys.
Key remapping assigns keystrokes that your communication package sends to the AS/400 when a key is pressed. If you want to use the F1 key when attached to your AS/400, you remap F1 in your communications package so that it sends OS/400 the key sequence ^[1. This is the same as pressing the Esc key on your keyboard, followed by the 1 key. Most keyboard remapping works in this manner.
It is important to have the actual keystrokes for remapping, but it is also important to have the decimal ASCII character codes they represent. In our F1 example, the ^[1 keystroke sequence could also be designated as decimal characters 027 033. Those are the ASCII decimal representations of the Esc character and the 1 character. This is necessary because certain keys cannot be emulated by sending out a character string to the AS/400. For example, in ProComm Plus, most AS/400 keystrokes can be emulated by sending out a sequence of keys, but there is no key sequence to emulate the Delete key. You can only map the Delete key by designating its numeric ASCII code. There are no keystrokes on your keyboard for typing in the Delete key character.
The documentation that comes with your communication package should include instructions on how to remap keys.
Windows 3.1 Terminal Program Considerations
As I mentioned earlier, it is possible to use the Windows 3.1 Terminal emulation program to do VT-100 emulation. This is an attractive option because it’s more or less free. Terminal comes with Windows, its default connection mode is VT-100, and you don’t have to pay for an emulation package like ProComm Plus. However, one major consideration in using this package is its ease of use, specifically the keyboard mapping.
In many communication packages, you change the keyboard mapping so that pressing individual keys sends different sequences of characters to OS/400. In Terminal, however, the keys are not remapped. Rather, you set up a total of 32 different function key remappings, which appear at the bottom of your connection screen in groupings called function key levels. There are four different levels. You can only show one level, or eight keys, at a time. You use these keys not by pressing the actual keyboard key, but by clicking on a button defined on the function key menu. To map F1 to F24, you do so in Terminal Settings. You might map F1 to F8 as level one of your function key button menu, F9 to F17 as level two, and F18 to F24 as level three. To use the F3 key, click on the F3 button on the function key menu. When you want to use F12, you click on a button to show the level two function keys, then click on the F12 button.
This does sound confusing, and it can lead to a very kludgy implementation. Depending on how your function keys are mapped, you could easily be clicking back and forth between different levels of function keys. It works and it works correctly, but the actual implementation can be frustrating and somewhat tedious.
The Easy Way
So, there you have it: an inexpensive way to set up asynchronous VT-100 terminals for your users without the overhead of Client Access or PC Support. The next time you have yet another request for terminal emulation over asynchronous phone lines, think about setting up a VT-100 line. It may turn out to be a very easy and cost-effective move for you and your remote users
Device description : VT100P01
Option : *BASIC
Category of device : *DSP
Device class : *LCL
Device type : V100
Device model : *ASCII
Emulated twinaxial device : 3196A2
Port number : 1
Emulating ASCII device : *YES
Physical attachment : *MODEM
Online at IPL : *YES
Attached controller : CTL02
Keyboard language type : USB
Character identifier : *KBDTYPE
Print device : *SYSVAL
Output queue : *DEV
Printer file : QSYSPRT
Library : *LIBL
Inactivity timer : *NOMAX
Line speed : 19200
Word length : 8
Type of parity : *NONE
Stop bits : 1
Workstation customizing object : *NONE
Text : VT-100 device
description for AS/400 connection.
Figure 1: Device Description for an AS/400 VT-100 Modem
Key Key Strokes Numeric Representation
F1 ^[1 027 049 F2 ^[2 027 050 F3 ^[3 027 051 F4 ^[4 027 052 F5 ^[5 027 053 F6 ^[6 027 054 F7 ^[7 027 055 F8 ^[8 027 056 F9 ^[9 027 057 F10 ^[0 027 048 F11 ^[- 027 045 F12 ^[= 027 061 F13 ^[! 027 033 F14 ^[@ 027 064
F15 ^[# 027 035 F16 ^[$ 027 036 F17 ^[% 027 037 F18 ^[^ 027 094 F19 ^[& 027 038 F20 ^[* 027 042 F21 ^[( 027 040 F22 ^[) 027 041 F23 ^[_ 027 095 F24 ^[+ 027 043 Reset ^[R 027 082 Tab ^I 009 Back-Tab ^[^I 027 009 Home ^[H 027 072 End ^[k 027 107 Page Up ^[U 027 085 Page Down ^[D 027 068 Field Exit ^[P 027 080 Enter ^M 013 Insert No keystroke 027 127 Delete No keystroke 127
Figure 2: Keyboard Mappings for AS/400 VT-100 Emulation
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