Advantages of DB2 CLI over embedded SQL

<div dir="ltr" style="text-align: left;" trbidi="on"><h1 style="text-align: justify;">Advantages of DB2 CLI over embedded SQL</h1><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgREk6eMWPtvXFPtVPVdshT7Iu_fPEbrZIDyaja-mGL7T6CQ1QC-HvWUFgK0n3O78dqb-d3JEdX37lvPMYBVmaKTX3DlNE3nSRREoZNjSJjLBPfnNeLb_ASPa_nq1XejRBp_TUsnTzpjAc/s1600/DB2-concepts+at+www.topnaukrialert.com.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="226" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgREk6eMWPtvXFPtVPVdshT7Iu_fPEbrZIDyaja-mGL7T6CQ1QC-HvWUFgK0n3O78dqb-d3JEdX37lvPMYBVmaKTX3DlNE3nSRREoZNjSJjLBPfnNeLb_ASPa_nq1XejRBp_TUsnTzpjAc/s1600/DB2-concepts+at+www.topnaukrialert.com.jpg" width="320" /></a></div><div><br /></div><div style="text-align: justify;"><span style="font-size: large;"><a href="https://www.blogger.com/null" name="idx301"></a><a href="https://www.blogger.com/null" name="idx302"></a>The DB2 CLI interface has several key advantages over embedded SQL. </span></div><div style="text-align: justify;"><span style="font-size: large;"><br /></span></div><ul type="disc"><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">It is ideally suited for a client-server environment, in which the target database is not known when the application is built. It provides a consistent interface for executing SQL statements, regardless of which database server the application is connected to. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">It increases the portability of applications by removing the dependence on pre-compilers. Applications are distributed not as embedded SQL source code which must be preprocessed for each database product, but as compiled applications or run time libraries. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">Individual DB2 CLI applications do not need to be bound to each database, only bind files shipped with DB2 CLI need to be bound once for all DB2 CLI applications. This can significantly reduce the amount of management required for the application once it is in general use. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI applications can connect to multiple databases, including multiple connections to the same database, all from the same application. Each connection has its own commit scope. This is much simpler using CLI than using embedded SQL where the application must make use of multi-threading to achieve the same result. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI eliminates the need for application controlled, often complex data areas, such as the SQLDA and SQLCA, typically associated with embedded SQL applications. Instead, DB2 CLI allocates and controls the necessary data structures, and provides a <span class="italic">handle</span> for the application to reference them. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI enables the development of multi-threaded thread-safe applications where each thread can have its own connection and a separate commit scope from the rest. DB2 CLI achieves this by eliminating the data areas described above, and associating all such data structures that are accessible to the application with a specific handle. Unlike embedded SQL, a multi-threaded CLI application does not need to call any of the context management DB2^(R) APIs; this is handled by the DB2 CLI driver automatically. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI provides enhanced parameter input and fetching capability, allowing arrays of data to be specified on input, retrieving multiple rows of a result set directly into an array, and executing statements that generate multiple result sets. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI provides a consistent interface to query catalog (Tables, Columns, Foreign Keys, Primary Keys, etc.) information contained in the various DBMS catalog tables. The result sets returned are consistent across DBMSs. This shields the application from catalog changes across releases of database servers, as well as catalog differences amongst different database servers; thereby saving applications from writing version specific and server specific catalog queries. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">Extended data conversion is also provided by DB2 CLI, requiring less application code when converting information between various SQL and C data types. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI incorporates both the ODBC and X/Open CLI functions, both of which are accepted industry specifications. DB2 CLI is also aligned with the ISO CLI standard. Knowledge that application developers invest in these specifications can be applied directly to DB2 CLI development, and vice versa. This interface is intuitive to grasp for those programmers who are familiar with function libraries but know little about product specific methods of embedding SQL statements into a host language. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI provides the ability to retrieve multiple rows and result sets generated from a stored procedure residing on a DB2 Universal Database (or DB2 Universal Database for z/OS and OS/390 version 5 or later) server. However, note that this capability exists for Version 5 DB2 Universal Database clients using embedded SQL if the stored procedure resides on a server accessible from a DataJoiner^(R) Version 2 server. </span></li><li class="MsoNormal" style="mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">DB2 CLI offers more extensive support for scrollable cursors. With scrollable cursors, you can scroll through a cursor as follows: </span></li><ul type="circle"><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">Forward by one or more rows </span></li><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">Backward by one or more rows </span></li><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">From the first row by one or more rows </span></li><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">From the last row by one or more rows. </span></li></ul></ul><div class="MsoNormal" style="margin-left: 0.5in; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; text-align: justify;"><span style="font-size: large;">Scrollable cursors can be used in conjunction with array output. You can declare an updatable cursor as scrollable then move forward or backward through the result set by one or more rows. You can also fetch rows by specifying an offset from: </span></div><ul type="disc"> <ul type="circle"><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">The current row </span></li><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">The beginning or end of the result set </span></li><li class="MsoNormal" style="mso-list: l1 level2 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list 1.0in; text-align: justify;"><span style="font-size: large;">A specific row you have previously set with a bookmark. </span></li></ul></ul><div class="MsoNormal" style="text-align: justify;"><span style="font-size: large;"><br /></span></div><div class="MsoNormal" style="text-align: justify;"><span style="font-size: large;"><br /></span></div><div class="MsoNormal" style="text-align: justify;"><span style="font-size: large;"><br /></span></div><div class="MsoNormal" style="text-align: justify;"><span style="font-size: large;"><br /></span></div><h3 style="text-align: justify;"><span style="font-size: large;">When to use DB2 CLI or embedded SQL </span></h3><div style="text-align: justify;"><span style="font-size: large;"><a href="https://www.blogger.com/null" name="idx303"></a><a href="https://www.blogger.com/null" name="idx304"></a>Which interface you choose depends on your application. </span></div><div style="text-align: justify;"><span style="font-size: large;">DB2 CLI is ideally suited for query-based graphical user interface (GUI) applications that require portability. The advantages listed above, may make using DB2 CLI seem like the obvious choice for any application. There is however, one factor that must be considered, the comparison between static and dynamic SQL. It is much easier to use static SQL in embedded applications. </span></div><div style="text-align: justify;"><span style="font-size: large;">Static SQL has several advantages: </span></div><ul type="disc"><li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">Performance </span></li></ul><div style="margin-left: 0.5in; text-align: justify;"><span style="font-size: large;">Dynamic SQL is prepared at run time, static SQL is prepared at precompile time. As well as requiring more processing, the preparation step may incur additional network-traffic at run time. The additional network traffic can be avoided if the DB2 CLI application makes use of deferred prepare (which is the default behaviour). </span></div><div style="margin-left: 0.5in; text-align: justify;"><span style="font-size: large;">It is important to note that static SQL will not always have better performance than dynamic SQL. Dynamic SQL is prepared at runtime and uses the database statistics available at that time, whereas static SQL makes use of database statistics available at BIND time. Dynamic SQL can make use of changes to the database, such as new indexes, to choose the optimal access plan, resulting in potentially better performance than the same SQL executed as static SQL. In addition, pre compilation of dynamic SQL statements can be avoided if they are cached. </span></div><ul type="disc"><li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">Encapsulation and Security </span></li></ul><div style="margin-left: 0.5in; text-align: justify;"><span style="font-size: large;">In static SQL, the authorizations to access objects (such as a table, view) are associated with a package and are validated at package binding time. This means that database administrators need only to grant execute on a particular package to a set of users (thus encapsulating their privileges in the package) without having to grant them explicit access to each database object. In dynamic SQL, the authorizations are validated at run time on a per statement basis; therefore, users must be granted explicit access to each database object. This permits these users access to parts of the object that they do not have a need to access. .</span></div><div style="margin-left: 0.5in; text-align: justify;"><span style="font-size: large;"><br /></span></div><div style="margin-left: 0.5in; text-align: justify;"><span style="font-size: large;"><br /></span></div><div style="margin-left: 0.5in; text-align: justify;"><span style="font-size: large;"><br /></span></div><ul type="disc"><li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">Embedded SQL is supported in languages other than C or C++. </span></li><li class="MsoNormal" style="mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-align: justify;"><span style="font-size: large;">For fixed query selects, embedded SQL is simpler. </span></li></ul><div style="text-align: justify;"><span style="font-size: large;">If an application requires the advantages of both interfaces, it is possible to make use of static SQL within a DB2 CLI application by creating a stored procedure that contains the static SQL. The stored procedure is called from within a DB2 CLI application and is executed on the server. Once the stored procedure is created, any DB2 CLI or ODBC application can call it. </span></div><div style="text-align: justify;"><span style="font-size: large;">It is also possible to write a mixed application that uses both DB2 CLI and embedded SQL, taking advantage of their respective benefits. In this case, DB2 CLI is used to provide the base application, with key modules written using static SQL for performance or security reasons. This complicates the application design, and should only be used if stored procedures do not meet the applications requirements. </span></div><span style="font-size: large;"><br /></span><div style="text-align: justify;"><span style="font-size: large;">Ultimately, the decision on when to use each interface, will be based on individual preferences and previous experience rather than on any one factor. </span></div></div>

Advantages of DB2 CLI over embedded SQL

Advantages of DB2 CLI over embedded SQLThe DB2 CLI interface has several key advantages over embedded SQL. It is ideally suited for a client-server environment, in which the target database …

Read more »

AS/400-iSeries Concepts and Terminology

<div dir="ltr" style="text-align: left;" trbidi="on"><h1 style="text-align: center;"><b>AS/400-iSeries Concepts and Terminology </b></h1><div class="MsoNormal" style="text-align: center;"><b><br /></b></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimUkGJOyyz1I_HXROnf0RlDMvsby93p8srh_tdrioNvz6u98IgJuRa3dbqrW5F5PYLE12tfrAnNPKMoOT98v2xlJwiqsiFu62RHiVQoM7s9md8GRwG4KmeCfqJysO5ALfTlf19_MDSoN0/s1600/AS400-iSeries.png" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimUkGJOyyz1I_HXROnf0RlDMvsby93p8srh_tdrioNvz6u98IgJuRa3dbqrW5F5PYLE12tfrAnNPKMoOT98v2xlJwiqsiFu62RHiVQoM7s9md8GRwG4KmeCfqJysO5ALfTlf19_MDSoN0/s1600/AS400-iSeries.png" /></a></div><div class="MsoNormal" style="text-align: center;"><b><br /></b></div><div class="MsoNormal" style="text-align: center;"><b><u><br /></u></b></div><div class="MsoNormal"> <span style="font-size: large;">The purpose of this post is to give a high level overview of the AS400-iSeries and some of the components, features, terminology, and definitions.</span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">AS/400 Architecture</span></h3><div class="MsoNormal"><span style="font-size: large;">The AS/400 is a very complex integrated system that includes hardware, software, security, a database and other components. The AS/400 Advanced Architecture is unique in that it is extremely adaptable and can easily incorporate new technologies. This is important in today’s fast changing computer marketplace. The AS/400 is designed to separate the software and hardware so changes in one have little effect in the other. This is accomplished through the Machine Interface (MI) which is a software programming interface between the application, the operating system and hardware. The MI is a complete Application Programming Interface (API) set that all applications must use in order to get to the to the hardware. This is how the AS400 achieves the software independence. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">OS/400 Operating System</span></h3><div class="MsoNormal"><span style="font-size: large;">The Operating System for the AS/400 is called OS/400. The OS/400 resides above the MI. This allows the operating system to be independent from the hardware.  Most operating system components handle functions such as memory, process, program, and I/O management. On the AS/400 these lower level functions are handled by the Licensed Internal Code (LIC) which is the operating system software below the MI. The LIC protects application programs and OS/400 from hardware changes. Thus again, keeping the software separate from the hardware. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">Integrated File System</span></h3><div class="MsoNormal"><span style="font-size: large;">The AS/400 contains an integrated file system (IFS). This means applications written on other file systems, PC, Unix, etc., can access data stored on the AS/400.  The IFS integrates all file systems on the AS/400 with one interface and one set of rules. How the AS/400 developers accomplished this was to use a single root, like a PC file system, and put all other file systems under it.  From a Windows client the AS/400 would appear as a network drive. Under that drive you would have PC-like subdirectories for all the file systems the AS/400 supports. Currently there is support for PC file systems, Unix file systems, OS/400 libraries, and others.  The IFS provides access to the data. The data must be in compatible format for the requesting application. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">DB2/400 Database – The Integrated Database</span></h3><div class="MsoNormal"><span style="font-size: large;">The AS400 contains a relational database called DB2/400. DB2/400 is integrated into the AS/400 partly above the MI and partly in the LIC. Conventional databases are separate software components that reside on top of the operating system. Since DB2/400 is integrated throughout the entire system it can achieve a higher level of efficiency because it is tightly integrated with the components with which it communicates. The database management system (DBMS) is a framework for storing and retrieving data. A DBMS must have an interface so users can access and manipulate the data. There are two interfaces to the AS/400: The Data Description Specifications (DDS) and Structured Query Language (SQL).  The DDS, or the native interface, was carried over from the IBM System/38. It has a look and feel similar to IBM’s Information Management System (IMS). The second interface for the AS/400 is SQL. This is the industry standard for relational databases and is an optional product that you must purchase separately. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">Data Warehousing</span></h3><div class="MsoNormal"><span style="font-size: large;">DB2/400 supports data warehousing. The four main components that DB2/400 utilizes for data warehousing are:  transformation and propagation tools to load the data warehouse, the data warehouse database server, analysis and end-user tools, and tools to manage the information about the data warehouse. </span></div><span style="font-size: large;">Transformation and propagation tools are used to move and manipulate data into a form more appropriate for the warehouse. It transforms operational data into informational data. <br />IBM introduced special models of the AS/400 that are able to handle the types of workloads use in data warehousing applications. These database servers utilize parallel processing and multidimensional databases. The AS/400 uses parallel I/O processing (IOP). This allows parallel processing at the I/O level for a single job.  By doing this it helps increase I/O processing time. The AS/400 also can take a single query and break it down to independent queries and these are run in parallel across the multiple processors in the system. This can increase performance for the original query. <br />Most relational databases are organized as two-dimensional tables.  A multidimensional databases has one or more additional dimensions. DB2/400 can create a three-dimensional data structure. These structures have three axis’s and look like a three dimensional spreadsheet. <br />The DB2/400 uses business intelligence tools to analyse the data in the data warehouse. These include: Decision support (DSS) tools, executive information systems (EIS), and data mining tools. DSS tools allow the user to create questions, in the form of queries, to get answers to the questions. They enable the user to create ad hoc queries and build reports. EIS’s combine DSS tools with some extended analysis capabilities. Data mining tools allow for the discovery of information with little or no direction from the user. The system searches through the data to determine patterns or associations. </span></div><div dir="ltr" style="text-align: left;" trbidi="on"><span style="font-size: large;"><br /></span><h3><span style="font-size: large;">Objects</span></h3><div class="MsoNormal"><span style="font-size: large;">The AS/400 is sometimes described as an object based system because objects are a fundamental part of the design of the system. Almost everything in the AS/400 is an object. These include data files, user profiles, job queues, message queues, print queues, compiled programs, word processing documents, menus, etc. On the AS/400 objects are categorized by type, which allow the user to specify what type of objects are required for a given task. There are OS/400 objects and MI system objects. Some OS/400 objects map one to one with MI system objects, but other have a one to many mapping. This is because some OS/400 objects need to map to multiple MI system objects. All OS/400 objects map to at least one MI system object. The object is assigned an owner when it is created. The owner is either the user or the group profile that created the object. When the object is created, the owner is given all the object and data authorities to that object. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">Libraries</span></h3><div class="MsoNormal"><span style="font-size: large;">A library is an OS/400 object that is used to find other OS/400 objects in the database. <br />The library is organized as a single-level hierarchy, unlike the directory structure found on PCs which have a multilevel hierarchy. To find an OS/400 system object you need the name of the library and the name of the object.  The AS/400 identifies objects by their qualified name, which takes the form of LIBRARY/OBJECT.   For example, to find the object MONEY in the library PAYROLL you would reference this as PAYROLL/MONEY. Two or more objects can have the same name but they must be different types of objects. For example you could have a program named TEST and a data space named TEST, but not two programs named TEST. An object can exist in only one library. A library cannot reference other libraries except for the library called QSYS. This is the only library that can access other libraries. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">Physical Files</span></h3><div class="MsoNormal"><span style="font-size: large;">A physical file holds the actual data. The physical file record has a fixed set of fields. Each field can have variable lengths. A physical file has two parts. The first part contains the file attributes and field descriptions. The file attributes include the file’s name, owner, size, number of records in the file, key fields, and other attributes.  The field descriptions hold the attributes for each field in the record. The second part of a physical file contains the data. </span></div><div class="MsoNormal"><span style="font-size: large;"><br /></span></div><h3><span style="font-size: large;">Logical files</span></h3><div class="MsoNormal"><span style="font-size: large;">Logical files allow a user to access data in a format that is different from the way it is stored in one or more physical files. The logical file contains no data records. It contains the corresponding record number of the data record in the physical file. The logical file will contain the index to the physical file. Logical files provide the path to the physical file. There are four types of logical files. The first is the simple logical file. This maps data from a single physical file to another logical record definition. The second is the multiple-format logical file.  This logical file allows access to several physical files. The third type of logical file is the join logical file. The join logical file defines a single record definition that is built from two or more physical files, tables, logical files, or views. The total number of physical files and tables cannot exceed 32. The forth type of logical file is the SQL view. These are similar to join logical files but SQL view logical files locate the access path at run time by use of the Query Definition Template and are not maintained by each join. </span></div><h3><span style="font-size: large;"><br /></span></h3><h3><span style="font-size: large;">Collections</span></h3><div class="MsoNormal"><span style="font-size: large;">A collection is a grouping of related SQL objects. This is the SQL name for a library in the native interface. </span></div><h3><span style="font-size: large;"><br /></span></h3><h3><span style="font-size: large;">DirectConnect Related Issues</span></h3><div class="MsoNormal"><span style="font-size: large;">NULLID Collection – The AS400 Access Service (ACS) requires certain files on the AS/400. It looks for these files in a collection called NULLID. The collection must be created before installing the service. The NULLID collection contains the service package which the system creates when the ACS submits the first request to the AS/400. It also contains a package for each AS/400 stored procedure the user creates. Finally, the NULLID collection contains the SYSPROCS and SYSPROCCOL catalog stored procedures table. </span></div><span style="font-size: large;">The script cspas4.sql creates the tables SYSPROCS and SYSPROCCOL in the NULLID collection. If you are going to use Catalog Stored Procedures against the AS/400 you will need to run this script. <br /> </span><span style="font-family: "Times New Roman","serif"; mso-ansi-language: EN-US; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;"><span style="font-size: large;">In your DirectConnect configuration the TPName for the AS400 must be the value \x7F6DB. This is the transaction program name for the DRDA Application Server on the AS/400. <br /></span><!--[if !supportLineBreakNewLine]--><br /><!--[endif]--></span></div>

AS/400-iSeries Concepts and Terminology

AS/400-iSeries Concepts and Terminology  The purpose of this post is to give a high level overview of the AS400-iSeries and some of the components, features, terminology, and definitions.AS/400 Archit…

Read more »