Vistors

Categories

Blog Stats

Archive for ‘AS400 DB2’

H56H1R/ H56HSR Wrapper

The above wrapper accepts following parameters at the time of calling the program. The same following list applies when calling the program H56HSR.

These are the parameters and the details you can find below.

@RPGM – Function identifier

@BRNM – Input branch

@USID – User identifier

@WSID – Workstation identifier

@JTT – Function type

DSAIM – Transaction serialisation

@RREC – Return code

@RMES7 – Error Message

AOW – Warning Messages

@ETK – Enigma transaction

@ETN – Enigma transaction number

@AEXT – Apply transaction during external input

@AREC – Apply transaction during recovery

Function identifier

@RPGM – A(10)

This mandatory input field is used to identify the function API that is to be used.

Positions 1-6 must contain the name of the function’s API module to be used to process the transaction. For details of function API module names see the earlier section Function identification.

Positions 7-10 will normally be blank. However positions 7-9 may be used to specify an Equation option identifier. This is required when the same module is used to process two types of input, for example Open Customer Account and Open Internal Account. Specifying the option identifier ensures the correct option description appears on the journal report. It does not affect processing

Input branch

@BRNM – A(4)

This optional input field defines the default branch mnemonic for user entering the transaction.

The default is derived from the user profile of the job being used to call the API.

User identifier

@USID – A(4)

This optional input field is used to identify the user entering the transaction.

The default is the user profile of the job being used to call the API.

As an Equation user’s branch and other regional settings are often read once only by Equation programs in their initialization, sometimes changing the @USID throughout the lifecycle of transaction entry through one job may lead to unexpected results.

Workstation identifier

@WSID – A(4)

This optional input field is used to identify the workstation from which the transaction is being entered.

The default is the workstation of the job being used to call the API.

If any transactions are applied using on line external input during the day phase that would be actually called again during recovery (for example if called from an update user exit procedure) it is recommended that the field is set to ‘@GEN’ for inline processes and ‘@ASN’ for asynchronous processes.

If any translations are applied during the C15 phase of the end of day that would be executed again during recovery processing it is recommended that the field is set to ‘@EOD’.

This will ensure that the transactions appear on the Equation journal reports but in the event of recovery transactions where the @WSID is ‘@ASN’, ‘@GEN’ or ‘@EOD’ are ignored.

Function type

@JTT – A(1)

This mandatory input field is used to identify the type of transaction to be executed.

A Add transaction

M Maintain an existing transaction

D Delete or cancel an existing transaction.

Transaction serialisation

DSAIM – A(9999)

This mandatory input field is used to pass the details of the transaction to be entered. This is in the format of the journal detail file for the transaction type being processed.

The external system must ensure that each packed field passed across the interface into Equation contains valid numeric data. It must ensure that transaction identifiers such as deal references contain only characters in upper case.

Note that the key fields usually in positions 1-17 of all journal detail files are passed as blanks. If values are set up in these fields they are ignored. For further details see the individual journal file descriptions.

DSAIM must contain the data necessary for the transaction.

If the transaction would result in a continuation record on the GZVF1P file, the data from position 36 on the continuation record must be added to the end of the DSAIM parameter. The data must be added to overlap at the position of the hexadecimal x’0E’ delimiter character at the end of the initial transaction.

Return code

@RREC – A(1)

This returned parameter is a status indicator returned by the function API.

R The transaction was processed successfully

F The transaction failed.

Error Message

@RMES7 – A(37)

This returned parameter provides details of the first error message received by the recovery module. This field will only ever be returned if @RREC contains an F. The errors will be the standard Equation KSM messages that are catalogued in the message file KSMMSGF.

Up to three blocks of substitution text are returned for inclusion in the message. Each can be 10 characters long and relate to variables &1, &2 and &3 in the message. To determine the error message details, look up the message identifier on the System Messages List (see the Report Tailoring Guide).

1 – 7 KSM message identifier

8 – 17 Message parameter one

18 – 27 Message parameter two

28 – 37 Message parameter three

Warning Messages

AOW – A(740)

This returned parameter provides details of up to twenty warning messages that the function API module has automatically overridden.

The parameter is made of 20 blocks of 37.

1 – 7 KSM message identifier

8 – 17 Message parameter one

18 – 27 Message parameter two

28 – 37 Message parameter three

Enigma transaction

@ETK – A(4)

Not used.

Enigma transaction number

@ETN – S(7,0)

Not used.

Apply transaction during external input

@AEXT – A(1)

This optional Y/N indicator determines if the API should be applied during batch external input.

Apply transaction during recovery

@AREC – A(1)

This optional Y/N indicator determines if the API should be applied during Equation recovery.

Basically the equation units uses string (A), packed(P) and zoned type(S) of values. In other words the stings will be the normal texts, the packed are the numeric/decimal data and the zoned are the date values. A(10) means the data type of the field is string with the length of 10 digits. S(7) means the data type of the field is date and its length is 7 digits (including the century) with no decimal values. P(15,3) means the data type of the field is decimal and the length is 15 digits and it accepts 3 decimal places.

IBM’s iSeries Client Access provides a library named cwbx.dll (you will find the DLL in this location : c:\Program Files\IBM\Client Access\Shared\ and you need to install the IBM Client – iSeries Access for Windows to find the DLL, Install IBM iSeries Access to Windows. Also check for service packs updates if there any from this link.) , which makes it possible to call RPG programs running on an AS/400 from any Microsoft .NET application. Basically we have to call equation related enquiry and posting wrapper programs used in DB2 through our .NET application or component . There are scenarios where we may have to execute direct DB calls as we are doing in TSQL/PLSQL instead solely depending on only Equation API enquiry calls. In such cases we have to use the same IBMDA400 data provider to establish the connection between the application and the Equation Database.

Each Posting APIs are wrapped by following ILE (Integrated Language Environment) programs as mentioned below:

X56H1R

X56HMR

H56HSR

In addition to the posting APIs each enquiry APIs are wrapped by an ILE program as mentioned below:

H46HMR

The input parameters that we should pass to the above mentioned wrappers are different to each other. In other words the parameters that we should pass for the posting programs are different than for the Inquiry program.

iSeries Access for Windows

Throughout last few months i had a chance to work with AS400, Equation APIs. The purpose of these equations calls are that we have to develop WCF services on top of these API calls. These calls will be consumed by the BizTalk. Initially it was too hard as i couldn’t find any resources online. When i searched in gOOgle about the errors which come across at the time of developments, it does not return anything! It was some hard times and thank for my team lead for helping out on those situations. Hope to write something about AS400, C# in coming days…

What is an AS400?

The AS/400 (Application System/400) was introduced by IBM on June 20th, 1988. Some of AS400 models are designed as Servers, while others are used as terminals or “display stations”. OS400 is the operating system for the AS/400.

In October of 2000, IBM rebranded the AS/400 and announced its name as the IBM iSeries 400. AS400 uses RPG (Report Program Generator) as its own programming language. Initially the RPG originated as a report-building program used in DEC and IBM minicomputer operating systems and evolved into a fully procedural programming language.