Converting Scripts from
DynaComm Asynchronous to DCS 10


This paper describes migration issues of upgrading from DynaComm Asynchronous or DynaComm TN3270 to the DynaComm Connectivity Series 10 (DCS 10). 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 Asynchronous (hereafter described as DCA) is one member. DCA is a single-session product, meaning that only one host session can be open per running instance of DynaComm. However, it supports several ways of connecting and seveal emulations. DCTN3270 is a single session TN3270 product, supporting one connection and one emulation per instance. Other 16-bit products include DynaComm/Elite and DynaComm/OpenConnect which support multiple concurrent sessions to one host and using one emulation (3270 or 5250). 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 was to unify the different emulations and connectors supported under a consistent, intuitive user interface. This necessitates several changes, since a single session product such as DCA or DCTN3270 can store session properties as application global settings, but a multiple session product must store them per session. Furthermore, configurable properties and appropriate default values vary with the choice of emulation and connection, so a further goal would be to have the interface knowledgeable of the features of the selected emulation and connection. DCS addresses this by implementing several features previously provided in DCA with the DynaComm Script Language as integrated parts of the product, leaving the Script Language free to implement custom functionality, and extending it to support multiple concurrent scripts.

DCS 10 is a fully 32-bit application, which implies some required differences from DCA and other 16-bit applications. DCA uses an INI file in the Windows directory to store global application values, whereas DCS stores this information in the Registry. 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 alot of configurability 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 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 Asynchronous DCS 10
Session file DCS file, Dynacomm.DCS is default, some INI files in DCS directory. SES files, no default loaded on startup, but can be set that way
Keyboard Mapper Done with script, mappings stored in DKM file Set in Session:Properties, Emulation, Keyboard tab, stored in KBM file
Color/Attribute Mapping Done via script, global, stored in DCASYNC.INI file Attributes, stored in ACM file
Toolbars Session toolbar definition stored in DCS file Replaced by application global floating toolbars, stored in Registry
Menu customization Done via script, application global Menu Editor based on child window type, stored in Registry. Also available via Script.
Program icons, shortcuts EXE name is Dynacomm.Exe EXE name is DCSeries.Exe
Dialer (in DCA) DCD files No equivalent, can be done via custom script
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 DCA to DCS. 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 written in DCA or DCTN3270.
Change: Some commands and functions in DCA 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 below 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 in DCA. These may not give compiler errors, but are not implemented to do anything. These are treated as obsolete commands. See the list of obsolete commands 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 file in DCA used a file extension of DCS, the new file extension for session files is SES. (These files are not compatible/convertible).
Suggestion: Search scripts for DCS string, and if used as part of a filename, change to a valid SES filename.
Change: DCA had a default settings file, DYNACOMM.DCS, 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 is launched. Write a script that says LOAD “DynaComm.Ses”, save as AUTOSTRT.DCP, and compile. Be sure to create a valid session file with that name. This may be one of the cases where DCA’s single-session limitation was built into the script, so this should be reviewed to see if it is appropriate to remove it. 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: DCA shipped with a AUTOEXEC.DCT that is 142 bytes in size, used to call a script called KEYMAP on startup. If the script is different from that, or considerably larger, it may incorporate functionality that should be converted to DCS 7.0 Find the AUTOEXEC.DCP and treat 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.
Change: The session toolbar is no longer configurable via script or the user. The floating application toolbars with Toolbar Editor is meant to provide this functionality.
Suggestion: Search scripts for @T and @F, or the word “Level” which are used to configure the session toolbar in DCA via script.

Return to top

Script Conversion - Recommended Steps

Change: In DCS 10, you can use several concurrent host sessions, not just one.
Suggestion: If the script interacts with the session, you want to maintain its association with the appropriate session, even if the user opens a second session to do something else at the same time. Retrieve the window handle using the script command which opens the session, or use the WINDOWHND( ) or ACTIVE( ) function, or some other means of determining the window handle for the session window after it has been opened. Then use the optional WindowHandle parameter for script commands that interact with or monitor the session. Alternatively, the SETDEFAULTSESSIONHANDLE command sets the default window handle for commands not specifying one.
Impact: In the absence of setting the windowhandle for the target session, the script command will apply to the active window. This may work fine, but incur sporadic problems if other sessions or child windows are opened.
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. Most of these are rarely used, so the recommended approach is to compile the script and reference this list when necessary, rather than to search scripts for each of the commands listed.

A list of replaced commands and functions follows:

DynaComm Asynchronous
Script Command/Function
DCS 10 Alternative Command
Dialog WideButton DIALOG BUTTON
ResetSerial CONNECT
Set Answerback EMULCONFIG, undocumented DCS command
Set Blocksize TRANSFERS
Set ConfirmDisconnect Set in Session:Properties, General tab in DCS 10
Set Network CardNum CONNCONFIG, when/if NetBios is supported
Set Network LocalName CONNCONFIG
Set Network RemoteName CONNCONFIG
Set ParityCheck CONNCONFIG
Set RecordFormat TRANSFERS
Set RecordLength TRANSFERS
Set Stopalert Undocumented in DCA, set in Session:Properties, General in DCS 10
System 0x0100 WINDOW MESSAGE to DCS app, with menuID
System(0x0100) WINDOWNAME()
System 0x0105 Beep
System 0x0200 SELECTION
System 0x0201 DISPLAY (x,y)"" (dislay a null string, but specify coordinates)
System 0x0202 SELECTION
Set 0x0208 SCROLL
System 0x0300,
System 0x0301, or
System 0x0302
Use TABLE commands to read from file
System 0x0500,
System 0x0501, and System(0x0500)
System 0x0600,
System 0x0601
Can use LAUNCH command to specify a different viewer, or (DIALOG) PICUTRE cmd.
System 0x0F00,
System 0x0F01,
System 0x0F02
System(0x0F00), System(0x0F01), or System(0x0F02) GETPROFILEDATA()
WaitForCall SEND modem string to wait for call

A list of obsolete commands and functions follows:

DynaComm Asynchronous
Script Command/Function
Reason Eliminated
File View GIF GIF Viewer not included in product. Can use LAUNCH command to send GIF as commandline argument to an application which displays GIFs
File View RLE Not included in product.
Level Session Toolbar is not configurable by user
Merge Undocumented DCA command
Set AutoReset Undocumented DCA command
Set FkeysArrange Not applicable
Set FkeysIcons Not applicable
Set Fkeys OneRow Not applicable
Set IBMToAnsi Handled by emulations, translation profiles
Set InputMode Alternate ways to monitor display data
Set LimitWindowSize Not necessary; terminal fulfills role
Set Monitormode Trace functionality is modified; monitor mode not supported.
Set NetId CONNCONFIG, when Eicon X25 supported
Set Network ReceiveTimeOut No client timeout
Set Network SendTimeOut No client timeout
Set Password Passwords not sotredi n Session Files
Set ScrollMargins Specific to DG Dasher emulation
Set Taskyield Uses Win32 threading for process priority
Set TrueAttributes Attributes always true, handled by emulation
System 0x0016 Windows envir vars should be set via Win API, use LIBRARY CALL to DLL to call API
System 0x0080 Windows envir vars should be set via Win API; use LIBRARY CALL to DLL to call API
System 0x0400 Unnecessary for current connector set
System 0x0F03 Windows envir vars should be set via Win API; use LIBRARY CALL to DLL to call API
System(0x0001, 0x0002, 0x0016, 0x0201, 0x0202, 0x0211, 0x0212, 0x0301, 0x0302, 0x8000) Not available
Timer Timer no longer part of interface, per session
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

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 DCA and DCS 10 Technical Profiles.

Return to top