Converting Scripts
from DynaComm Elite/OpenConnect to DCS


This paper describes migration issues of upgrading from DynaComm/Elite or DynaComm/OpenConnect to the DynaComm Connectivity Series version 9. The objective of this paper is to provide an overview of the conversion process, the benefits and difficulties to be considered in migration, and specific steps in the process. The conversion effort required varies, but as a general rule, it pays to consider new features and plans up front instead of directly porting the existing environment and retaining the limitations therewith.


New Features of DCS 10

DCS 10 is a 32-bit product upgrade to several 16-bit versions of DynaComm, of which DynaComm/Elite and DynaComm/OpenConnect are two members. DynaComm/Elite and DynaComm/OpenConnect support multiple concurrent sessions to a host system, using either 3270 or 5250 emulation, and a single connection method. DynaComm Asynchronous for Windows supports many different emulations and connectors, only one of which can be used a time. The motivation behind DCS 10 was to provide a 32-bit product upgrade to all of these 16-bit products, supporting multiple concurrent connections to potentially different host systems, potentially using different emulations and different connection methods, all within a single application instance. Preserving backwards compatibility was a high priority, somewhat mitigated by the fact that DCS 10 is an upgrade to these different products.

Another goal of DCS 10 was to unify the different emulations and connectors supported under a consistent, intuitive user interface in a heterogeneous user environment. Since some features and appropriate defaults vary by host environment and emulation, these items are part of the emulation properties. Also, different user groups may use some host systems and not others, so product configuration should allow some standard and protected settings, but allow other values to be customized according to user preference. To accomplish this, application global settings must be stored in a different location than session specific settings, which deviates from the behavior of DynaComm/Elite and DynaComm/OpenConnect.

DCS 10 is a fully 32-bit application, which implies some required differences from DE3270, DO3270 and other 16-bit applications. DE3270 and DO3270 use an INI file in the Windows directory to store global application configuration, whereas DCS 10 stores this information in the Registry. Also, per Windows logo guidelines, application system directories should be stored under Program Files, so the default application directories have changed.

A final guiding principle for the development of DCS 10, with indirect albeit significant impact on conversion planning, was to use our experience in the heterogeneous host environment to identify features and flexibility most used by our customers, to make those features versatile and easy to use. This meant building a lot of customizability into the product, while retaining the administrators ability to set and protect vital settings. We’ve also incorporated ActiveX technologies for browser and application integration. Host applications can be integrated with Intranet sites and third party Windows applications which support OLE, retaining all the keymapping, attribute mapping, scripts and other customization features of the standalone DCS 10 product. These are really new features and not conversion requirements, but considering them during conversion planning may suggest easier alternatives, and worthwhile modifications that facilitate later developments.

The goals of integrating several products into a single 32-bit host access enterprise solution, with a consistent and intelligent interface, and support for multiple concurrent sessions and scripts, pretty much indicate the motivation of changes and the issues likely encountered in a conversion effort. The rest of this paper gives further details and implementation suggestions.

Return to top

Summary of Changes

Product file / feature DynaComm/Elite &
DCS 10
Session settings file DES file stores application global and session specific settings, Dynacomm.INI is default session file. SES files, no default loaded on startup, but can be set that way
Session specific vs. application global configuration Several features/settings had to be set the same for all sessions, such as autoconnect, graphical OIA, disconnect warnings, file transfer settings, mouse options, hot spots. Registry stores application global configuration, all configuration of session features is stored in SES files for maximum flexibility.
Keyboard Mapper KBM file is mapping of KBL to external 3270 KBT files Set in Session:Properties, Emulation, Keyboard tab, stored in new KBM file format, defaults are set by emulation
Color/Attribute Mapping CLM file, specific to 3270 emulation attributes Session:Properties, Attributes tab, stored in ACM file, mapable attributes determined by emulation
Toolbar Configurable in latest version, stored in a BAR file. Replaced by multiple floating toolbars, stored in Registry
Menu customization Done via script or INI file settings, application global Menu Editor based on child window type, stored in Registry. Also available via Script.
Program icons, shortcuts EXE name is DE3270.Exe, DO3270.Exe, or DO5250.Exe EXE name is DCSeries.Exe
Flashpad FPD file No equivalent, replaced by application global floating toolbars, but can be done via custom script. Can be associated with a specific session via script
Hot Spots HOT file, application global <planned>
Script Language DCP files, DCT files DCP files with modifications, recompile into valid DCT files for DCS 10.

Return to top

Script Conversion

Above, we discussed the advantages and reasons it is preferable to update scripts to use the features of DCS 10, instead of just porting existing behavior and limitations to the new product. This overview is divided into a section of minimal and recommended steps of conversion. Minimal steps are listed as pairs of changes and suggested solution for conversion from DynaComm/Elite or DynaComm/OpenConnect to DCS 10. Recommended steps also include the likely impact of omitting the recommended change.

Script Conversion - Minimal Steps

Change: Task files (DCT files) support additional functionality in DCS 10.
Suggestion: Use DCS 10 to recompile DCP files.
Change: Some commands and functions are no longer applicable in DCS 10, due to changes in product functionality or interface.
Suggestion: Commands and functions not supported by DCS 10 will encounter compile errors indicating the line or command which is not recognized. Consult the list of obsolete commands and functions in Appendix A for an equivalent command/function if available.
Change: The SYSTEM command and SYSTEM ( ) function are replaced with more meaningful names.
Suggestion: These commands and functions were “undocumented” features, which became documented over time. These may not give compiler errors, but are not implemented to do anything. These are treated as obsolete commands, see Appendix A below for replacement commands where available.
Change: A command / function in DCS 10 has more parameters than in earlier products.
Suggestion: Extra parameters have been made optional whenever possible. Otherwise, they will appear as compile errors and should be handled as above. For example, since multiple concurrent dialogs are supported, your DIALOG commands and functions support optional indexes.
Change: Default directory names and locations have changed.
Suggestion: This is not an issue if the DIRECTORY( ) function was used to get the directory path. Otherwise, search and replace hard-coded paths with the DIRECTORY( ) script function with appropriate parameter.
Change: Settings files in DynaComm/Elite used a file extension of DES, the new file extension for session files is SES. (These files are not compatible/convertible).
Suggestion: Search scripts for DES string, and if used as part of a filename, change to a valid SES filename.
Change: DE3270 and DO3270 stored default sessions in DYNACOMM.INI, which was loaded and connected if available.
Suggestion: DCS 10 does not have a default session file, but one can be implemented by using the AUTOSTRT script which runs when DCS 10 is launched. Write a script that says LOAD “SCR1.Ses”, save as AUTOSTRT.DCP, and compile. Be sure to create a valid session file with that name. Alternatively, if a script is going to be run anyway, it would be preferable to add the LOAD or CONNECT command to that script to minimize the number of scripts.
Change: The script which runs automatically when DCS 10 is run is called AUTOSTRT.DCT, not AUTOEXEC.DCT.
Suggestion: Find the AUTOEXEC.DCP and treat it as with other scripts for conversion.
Change: For 16-bit products, the LIBRARY CALL command calls 16-bit DLLs, for 32-bit products it calls 32-bit DLLs.
Suggestion: Recompile the DLL in 32-bit development environment. If the DLL calls 16-bit Windows functions not supported by Win 95 or NT, then some redevelopment of the DLL may be necessary.
Change: The application menus are changed.
Suggestion: If a script is used to customize the menus, it may use POPUP “MenuName” SYSTEM X where X is a number indicating a default menu (where File is 1, Edit is 2, ...). The symptom will be that the menu items correspond to a different popup menu. Search scripts for the word “System” and check if the word is used as part of menu modification, and update the number as appropriate. Also, since the menu bar is different depending on whether the child window is a Session, Script, Memo, or Main application window, make sure the correct window type is active when these script commands are invoked. When possible, use the Menu Editor instead of scripts to update the menu.

Return to top

Script Conversion - Recommended Steps

Change: Multiple scripts can be run simultaneously in DCS 10.
Suggestion: Search scripts for the commands PERFORM, EXECUTE, and LAUNCH, which may call other scripts. If the program flow is such that the scripts should be performed sequentially, it should work unchanged. The SPAWN command allows you to perform independent scripts, which may be desired if that suits the particular application, or to get around limitations on the number of WHEN commands. Choosing the menu item Script:Stop lists the running scripts if more than one is in execution at the time.
Impact: This additional flexibility may be useful for complex multitasking operations.
Change: Features which apply to session behavior are now configurable by session, instead of set in the product for all defined sessions. Startup scripts can also be associated to run when a particular session is run.
Suggestion: Approach session automation conversion from a session perspective. For example, define a session”s relevant properties and store to a SES file, create a script to perform session related automation and distribute the SES and DCT files together as a unit. This way, if an AS/400 or Tandem session is later added, your environment will not be affected.
Impact: This is a case of using new flexibility in the product, as opposed to porting limitations from earlier products.
Change: Multiple Dialog Boxes are supported, up to 16 concurrent ones.
Suggestion: Verify the DIALOG CANCEL command is used in the script after DIALOG END and WAIT RESUME. In DynaComm/Elite and DynaComm/OpenConnect, the DIALOG CANCEL function was implied when a new dialog was defined. Add the optional dialog index to the end of DIALOG commands, and use this optional parameter in referencing controls, such as the EDITTEXT( ) function, to indicate the control number and dialog.
Impact: Not using DIALOG CANCEL may cause multiple dialog boxes to stay on the screen, perhaps unnoticed if they are stacked in the same position. Not using Indexes for dialogs may create strange results if the script is later updated to include more than one dialog box displayed at the same time.
Change: New script commands are available for setting and reading product configuration.
Suggestion: CONNCONFIG, EMULCONFIG, DISPLAYCONFIG, and XFERCONFIG are available to set properties of the connector, emulation, display and file transfer. GENERALCONFIG and APPCONFIG configure general session properties and application global settings respectively. In many cases, earlier commands are still supported, though the newer syntax is preferable. The same applies to the SETTINGS( ) function, which is still supported but replaced by GETCONNCONFIG(), GETEMULCONFIG(), GETDISPLAYCONFIG(), and GETXFERCONFIG().
Impact: The new syntax makes scripts consistent and easier to follow for mixtures of connectors, emulations, etc. Some keywords for the SETTINGS( ) function are meaningless in DCS 10, since corresponding settings are not included in DCS.

Return to top

Obsolete/Replaced Commands & Functions

Some script commands/functions have been removed from the product as inappropriate to new product functionality, others have been subsumed by other commands/functions.

A list of replaced commands and functions follows:

DynaComm/Elite or DynaComm/OpenConnect
Script Command/Function
DCS 10 Alternative Command
System 0x801, System(0x801) Multiple concurrent dialogs supported in DCS 10
System (0x900) GETXFERCONFIG
Window Attachment KEYMAP LOAD, Application Toolbars replace flashpads, others defined in Session Properties
Folder( ) DIRECTORY( )

A list of obsolete commands and functions follows:

DynaComm/Elite or DynaComm/OpenConnect
Script Command/Function
Reason Eliminated
Set Taskyield Uses Win32 threading for process priority
System 0x800, System(0x800) Can’t write to status line (use DISPLAY (99))
System 0x701, 0x702 Use Launch command to specify WinHelp file, and Window Message 0xE146 to specify context
System 0x901 Can define a new dialog with new title
Video Load Attribute mapping integrated with emulation
Video Reset Attribute mapping integrated with emulation
Video Save Attribute mapping integrated with emulation
Video Style Attribute mapping integrated with emulation
Video Update Attribute mapping integrated with emulation
Video () Attribute mapping integrated with emulation

Return to top

New Commands & Functions

Functions Commands

Return to top

Additional Resources

Technical Profiles are available in the Support area of our web site. These give details of the product installation and footprints. Some of the recommendations of this paper can be derived from a comparison of the Technical Profiles.

Return to top