Showing posts with label AS/400. Show all posts
Showing posts with label AS/400. Show all posts

Sunday, August 9, 2009

Trigger AS/400

This template deals with triggers on physical files.The triggered file itself need not be referenced here unless you have need to access it beyond the record that caused the trigger to be pulled.





/TITLE TRIGGER ** Trigger program shell **

* Pete Hall
* http://www.inwave.com/~peteh/

* Replace (PFile) with physical file name
* Replace (AFile) with ancillary file name

* ---------------------------------------------
* Ancillary files
* ---------------------------------------------
F(AFile) UF A E K DISK Commit(RunCommit) UsrOpn

* ------------------------------------------
* Entry Parameters
* ---------------------------------------------
DBuffer DS 32767
D PFName 10
D PFLibrary 10
D PFMember 10
D TrgEvent 1
D TrgTime 1
D TrgCmtLvl 1
D 3
D TrgCCSID 7B 0
D 8
D OrOffset 7B 0
D OrRcdLen 7B 0
D OrNBMapOfs 7B 0
D OrNBMapLen 7B 0
D NwOffset 7B 0
D NwRcdLen 7B 0
D NwNBMapOfs 7B 0
D NwNBMapLen 7B 0
D DataSpace 1 32767
D Bytes 1 Overlay(DataSpace) Dim(32767)

DBufferLen S 7B 0
* ---------------------------------------------
* Original Record
* ---------------------------------------------
D@OrRecord S * Inz(*Null)

DOrRecord E DS ExtName((PFile)) Prefix(OR_)
D Based(@OrRecord)

* ---------------------------------------------
* New Record
* ---------------------------------------------
D@NwRecord S * Inz(*Null)

DNwRecord E DS ExtName((PFile)) Prefix(NW_)
D Based(@NwRecord)

* ---------------------------------------------
* Constant Definitions
* ---------------------------------------------
* Commit Levels
DCL_NONE C '0'
DCL_CHG C '1'
DCL_CS C '2'
DCL_ALL C '3'

* Null byte status
DNB_NOTNULL C '0'
DNB_NULL C '1'

* Trigger events
DTE_INSERT C '1'
DTE_DELETE C '2'
DTE_UPDATE C '3'

* Trigger times
DTT_AFTER C '1'
DTT_BEFORE C '2'
C *ENTRY plist
C parm Buffer
C parm BufferLen


* ---------------------------------------------
* Main-line Procedure
* ---------------------------------------------

* Assign the record templates to their data space
C eval @OrRecord = %Addr(Bytes(OrOffset+1))
C eval @NwRecord = %Addr(Bytes(NwOffset+1))

* Execute the correct procedure based on trigger event
C TrgEvent caseq TE_INSERT DoInsert
C TrgEvent caseq TE_DELETE DoDelete
C TrgEvent caseq TE_UPDATE DoUpdate
C endcs
C return

* ---------------------------------------------
* Process a delete event
* ---------------------------------------------
CSR DoDelete BEGSR


CSR ENDSR

* ---------------------------------------------
* Process an insert event
* ---------------------------------------------
CSR DoInsert BEGSR


CSR ENDSR

* ---------------------------------------------
* Process an update event
* ---------------------------------------------
CSR DoUpdate BEGSR


CSR ENDSR

* ---------------------------------------------
* Program Initialization
* ---------------------------------------------
CSR *INZSR BEGSR

C if TrgCmtLvl > CL_NONE
C move *ON RunCommit
C endif
* > if TrgCmtLvl > CL_NONE
C open

CSR ENDSR

Reference from Pete Hall's web site .


Read more!

Friday, September 21, 2007

AS/400 Control Language (CL)



The AS/400 control language (CL) is reminiscent of JCL and consists of an ever expanding set of command AS/400 object|objects (*CMD) used to invoke traditional AS/400 programs and/or get help on what those programs do. CL can also be used to create CL programs (congruent to Shell script|shell scripts) where there are additional commands that provide program-like functionality (GOTO, IF/ELSE, variable declaration, file input, etc.)

The vast majority of AS/400 commands were written by IBM developers to perform system level tasks like compiling programs, backing up data, changing system configurations, displaying system AS/400 object|object details, or deleting them. Commands are not limited to systems level concerns and can be drafted for user applications as well.

Commands and programs

Parameter (computer science)|Parameters (aka arguments) defined in the main procedures of all traditional AS/400 programs are hard coded lists that are be made up of parameters that can be numeric, alphanumeric, boolean, etc and the order in which Parameter (computer science)|parameters are passed is important. This is a stark difference from the Unix & DOS worlds where the parameter list in Unix Shell script|shell scripts and C programming language|C programs is a set or array of character pointers and more often than not the parameters are not positionally dependent.

The AS/400 developer's solution to this problem was the command AS/400 object|object (*CMD). While the parameters on the command can be specified in any order, each parameter is defined to be passed in a specific order to the program. The programmer can also define, among other things, the parameter's data type, unique parameter name, descriptive text (for prompting), default value (used only if the parameter isn't specified during execution), if the values are restricted to a certain set or range, if the data entered should be changed to another value before calling the program, etc.

At its most basic a command names a single program to call when the user types or prompts the command and presses the Enter key. The command takes all of the parameters typed by the user, and those not typed by the user, and builds a parameter list that it passes to the program when it's called.



Sample Code

The following is a sample of CL programming. The program interactively converts dates from julian to mdy and vice versa. Results are displayed on line 24 of the terminal. It accepts two parameters. The &IN parameter which is the date string to be converted. If a julian string it should be in the format yynnn where yy is the year number and nnn is the day number of the year. If a MDY string it must be in the format mmddyy. The second parameter is &TYP which is the type of date to be converted to. It must be 'J' (julian) or 'M' (mdy). For example: the command CALL PGM(ICVTDATC) PARM('04180' 'M') will convert the julian date 04180 to 062804 (June 28, 2004).




PGM PARM(&IN &TYP)

DCL VAR(&IN) TYPE(*CHAR) LEN(6)
DCL VAR(&OUT) TYPE(*CHAR) LEN(8)
DCL VAR(&TYP) TYPE(*CHAR) LEN(1)
DCL VAR(&MSG) TYPE(*CHAR) LEN(80)

IF COND(&TYP = J) THEN(DO)
CVTDAT DATE(&IN) TOVAR(&OUT) FROMFMT(*MDY) +
TOFMT(*JUL) TOSEP(*NONE)
ENDDO

IF COND(&TYP = M) THEN(DO)
CVTDAT DATE(&IN) TOVAR(&OUT) FROMFMT(*JUL) +
TOFMT(*MDY) TOSEP(*NONE)
ENDDO

CHGVAR VAR(&MSG) VALUE('IN=' || &IN || ' OUT=' || +
&OUT)
SNDPGMMSG MSG(&MSG)

ENDPGM

Retrieved from "http://csiwiki/index.php?title=AS/400_Control_Language"


Read more!

Thursday, September 20, 2007

RPG IV, a Modern Language


In 2001, with the release of OS/400 V5R1, RPG IV offered even greater freedom for calculations than offered by the Extended Factor-2 Calculation Specification: a free-format text-capable source entry, as an alternative to the original column-dependent source format. The "/FREE" calculation does not require the operation code to be placed in a particular column; the operation code is optional for the EVAL and CALLP operations; and syntax generally more closely resembles that of mainstream, general-purpose programming languages.

Today, RPG IV is a considerably more robust language. Editing can still be done via the simple editor or it can be edited via PC using IBM's Websphere Development Studio (a customized implementation of Eclipse). IBM is continually extending its capabilities and adding more built-in functions (BIFs). It has the ability to link to Java objects (See IBM's RPG Reference Manual [1] ), and i5/OS APIs; it can be used to write CGI programs with the help of IBM's Cgidev2[2]web toolkit, RPG xTools [3] CGILIB and other commercial Web enabled packages. Even with the changes it retains a great deal of backward compatibility, so an RPG program written 37 years ago could run today with little or no modification.

The OS/400 was later renamed i5/OS in correspondence with the new IBM System i branding initiative. The i5/OS V5R4 [4] (Version 5 Release 4) was released in January 2006 and is currently the latest version (as of August, 2007).


Read more!

RPG Language Evolution



RPG II was introduced with the System/3 series of computers. It was later used on System/32, System/34, and System/36, with an improved version of the language. International Computers Ltd also produced a version on its VME/K operating system

RPG III was created for the System/38 and its successor the AS/400 (a mid-range machine). RPG III significantly departed from the original language, providing modern structured constructs like IF-ENDIF blocks, DO loops, and subroutines.

DE/RPG or Data Entry RPG was exclusively available on the IBM 5280 series of data-entry workstations in the early 80s. It was similar to RPG III but lacking external Data Descriptions (DDS) to describe data(files) like on the System/38 and its successors. Instead, the DDS part had to be included into the RPG source itself.

RPG/400 with a much cleaner syntax, and tighter integration with the integrated database. This language became the mainstay of development on the AS/400, and its editor was a simple line editor with prompt templates for each specification (type of instruction).

RPG IV (aka RPGLE, aka RPG/ILE) was released in 1994 and the name, officially, was no longer an initialism. RPG IV offered a greater variety of expressions within its new Extended Factor-2 Calculation Specification.


Read more!

Wednesday, September 19, 2007

The Application System/400 (AS/400)




The Application System/400 (AS/400), renamed to iSeries in 2000, further renamed to System i5 in 2006, is an IBM minicomputer for general business and departmental use, introduced in 1988 and still in production under the names iSeries and i5. The AS/400 is an object-based system with an integrated DB2 database that was designed to implement E. F. Codd's relational database model, which is based on Codd's 12 rules, in the operating system and hardware. All software necessary to run this computer is included and integrated. More than 2,500 business software applications were available when the first AS/400 was delivered in 1988. The AS/400 is well suited to a broad range of business, non-profit, and government applications, including back office, manufacturing, retail wholesale transportation, data base management, being an ISP. It is not a suitable platform for scientific number crunching or consumer applications.

The AS/400 was the result of the combination of the System/38 database machine (announced by IBM in October 1978 and delivered in August 1979) and the System/36. The first AS/400 systems (known by the development code names Silverlake and Olympic) were delivered in 1988, and the product line has been refreshed continually since then. IBM renamed the AS/400 to iSeries in 2000, as part of its e-Server branding initiative. The product line was further extended in 2004 with the introduction of the i5 servers, the first to utilize the IBM POWER5 processor. The AS/400 was the first general-purpose computer system to attain a C2 security rating from the NSA, and in 1995 was extended to employ a 64-bit processor and operating system. The architecture of the system allows for future implementation of 128-bit processors when they become available. Existing programs will utilize the new hardware without modification.


Features include an extremely fast DBMS, a menu-driven interface, multi-user support, terminals (IBM 5250) and printers, security, communications, client-server and web-based applications and an extensive library-based operating system, OS/400.


A big selling point is that applications can run without modification on any model in the product line, from small, single-processor machines up to those with 64 multi-core CPUs. For traditional business programming languages such as RPG, COBOL, C and SQL, it has support for external files, display files and object-based programming, which allows for increased programming productivity. It also supports Unix-like file directories, industry-leading support for Java, client-server technologies and a native Apache web server, for "modern" and GUI-style applications. IBM claims superior Total cost of ownership due to high system availability, which averages 99.98% uptime, and lower costs of administration and maintenance, when compared to Unix, Linux and Microsoft-based implementations.


The machine was originally based on a custom IBM CISC CPU which used a CPU architecture known as Internal MicroProgrammed Interface (IMPI) and an instruction set similar to the IBM 370. It was later migrated to a PowerPC-based RISC CPU family eventually known as RS64. The latest models are based on the POWER5 (announced 4 May 2004) processor.[1]


Here Debian is running natively on an iSeries Logical Partition.The machine survives because its instruction set (called TIMI for "Technology Independent Machine Interface" by IBM) allows the operating system and application programs to take advantage of advances in hardware and software without recompilation. This means that a program written and compiled on a S/38 can be run as a native 64-bit program. The HAL allows a system that costs $9000 to run exactly the same operating system and software as a $2 million system. The system can concurrently run multiple operating systems (i5/OS (OS/400), Linux, AIX) natively, and runs Windows Server and Linux on one or more single-CPU blade servers or externally-attached mutiple-CPU servers when installed. The 64-bit design provides for the seamless addressing of up to 16 exabytes (16 million terabytes) of storage.


The AS/400 enforces the use of the TIMI virtual instruction set for all user-mode programs; it is not possible for such programs to utilize the instruction set of the underlying CPU, thus ensuring hardware independence. This is conceptually somewhat similar to the virtual-machine architecture of programming environments such as SmallTalk, Java and .NET. The key difference is that it is embedded so deeply into the AS/400's design as to make all applications and even the bulk of its operating systems binary-compatible across different processor families. Note that, unlike other virtual-machine architectures in which the virtual instructions are interpreted at run-time, TIMI instructions are never interpreted. They constitute an intermediate compile-time step and are translated into the processor's instruction set as the final compilation step. The TIMI instructions are stored within the final program object, in addition to the executable machine instructions. This is how a program compiled on one processor family (e.g. CISC) can be moved to a new processor (e.g. PowerPC) without re-compilation. The program is saved from the old machine and restored onto the new machine, whereupon the OS discards the old machine instructions and re-translates the TIMI instructions into machine instructions for the new processor.


The AS/400's instruction set defines all pointers as 128-bit to allow seamless transition from older to new processor generations.


Another feature that was recently introduced to the AS/400, LPAR, came from IBM's mainframe line of computers. LPAR (Logical PARtitioning) facilitates running multiple instances of operating systems simultaneously on one AS/400 unit. A system setup with LPAR can even run different operating systems on different partitions while ensuring that one OS cannot run over the memory or resources of another. Each LPAR is given a portion of system resources (memory, hard disk space, and CPU time) via a system of weights that determines where unused resources are allocated at any given time. The OSes supported (and commonly used) under the LPAR scheme are OS/400, AIX and Linux. (Note: Currently Microsoft operating systems do not support Power-based processors.)


AS/400s are also capable of supporting mutiple instances of Linux, Microsoft Windows 2000 and Windows Server 2003, with either single-processor internal blade servers (IXS) or externally-linked mutiple-processor servers (IXA).


Even though AIX can now be natively run in an LPAR partition, the original implemenation was to allow AIX programs to be ported to the PASE environment. AIX programs ARE binary compatible with OS/400 when using OS/400's PASE (Portable Applications System Environment). PASE is essentially "an operating system within an operating system", supporting the most recent stable version of AIX. Binaries need to be re-compiled on the AIX system, with 16-bit (quadword) pointer alignment enabled. Once the program is compiled with this option, the executable can be FTP-ed to the AS/400, and executed under the PASE Korn Shell.


Additionally, tasks such as handling record locks and queuing updates are managed automatically by the system, making high-speed, multiuser applications easy to create and maintain, and extremely reliable.


Programming languages available for this machine include RPG, assembly language, C, C++, Java, COBOL, SQL, BASIC, PHP, PL/I, and REXX. Several CASE tools are available: Synon, AS/SET, Magic,and Lansa.

Commands in the Control Language (CL) are promptable and most provide cursor-sensitive help to make entering parameters easier. A command name consists of a three-letter verb and a subject part, also referred to as a noun. Some command names provide a "modifier" as well. This is intended to make it easy to understand CL code. Examples:

CRTUSRPRF - Create (verb) user (modifier) profile (noun) DLTLIB - Delete (verb) library (noun) CPYF - Copy file WRKACTJOB - Work with Active Jobs The AS/400 was designed as the successor of the IBM System/38 and the IBM System/36. The programmers who worked on OS/400, the operating system of the AS/400, did not have a UNIX background. Dr. Frank Soltis, the head architect, says that this is the main difference between this and any other operating system.


Despite the lack of a "UNIXy" background, the AS/400 has, over the years, picked up the programming/runtime model found on UNIX, Linux, and PC systems. Traditional AS/400 programming is a "one-stop shop", where a programmer writes computer code, compiles the code, and then executes the code. There is no link step that is found in other environments.


However, in 1995, that changed. IBM re-christened the one-stop shop programming style "OPM" (for Original Programming Model) and introduced a new language paradigm called "ILE" (for Integrated Language Environment). ILE had significant enhancements over OPM, including the ability to create modules (similar to .obj or .lib files), and then bind (link) the modules together into a single executable. The executable could be created as a program or a service program (service programs are similar to .lib or .dll files).


The real power of the ILE environment is in the "integrated" aspect, however. Modules in ILE-compliant languages (RPG, COBOL, C, C++, and CL) could be created and bound together. For the first time, AS/400 programmers could exploit the strengths of multiple ILE-compliant languages in a single program. Also, with the introduction of service programs, standard routines could be externalized more easily, and modularity increased. To ensure proper migration to the ILE environment, OPM RPG and COBOL programs could be migrated to ILE easily.


Interoperation with the Java language is also supported, though not as tightly as with the ILE languages. The iSeries Java implementation is distinguished by the depth of its embedment in the operating system.


iSeries servers also support common client-server-based technologies such as ODBC and JDBC for accessing its database from client-based software, created with languages such as Java, Microsoft Visual Studio .NET and other languages.


Read more!