Archive for December, 2010

December 30, 2010

H56H1R/ H56HSR Wrapper Programs

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.

  1. @RPGM – Function identifier
  2. @BRNM – Input branch
  3. @USID – User identifier
  4. @WSID – Workstation identifier
  5. @JTT – Function type
  6. DSAIM – Transaction serialisation
  7. @RREC – Return code
  8. @RMES7 – Error Message
  9. AOW – Warning Messages
  10. @ETK – Enigma transaction
  11. @ETN – Enigma transaction number
  12. @AEXT – Apply transaction during external input
  13. @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.

References: Misys Documentation

Advertisements
December 29, 2010

Calling AS/400 (AS400) RPG Programs using .NET

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.

just refer this link for start up.

iSeries Access for Windows

December 23, 2010

Hello WordPress

Finally i have moved my blogspot IT blog to wordpress for so many reasons. I am not going to discuss why did i moved? 🙂 anyhow wordpress looks good compared to blogger. So hopefully my future posts related to technical IT stuffs will be here.

December 20, 2010

MCTS : Microsoft BizTalk Server 2006

Well i sat for the MCTS 70-235 (Developing Business Process and Integration Solutions using Microsoft BizTalk Server 2006) exam yesterday and glad to inform that i have passed. mmm.. with regard to the paper, most of the questions were related to BAM, BRE, deploying a BizTalk application, debugging BizTalk applications (ex: debugging orchestration, etc), some of them related to schema creation (ex: minoccurs, validating a schema, etc), role links and general BizTalk questions.

Before sitting for the exam just go through the sarvanas’ preparation diary. It helped me a lot in addition to the following Apress and Wrox eBooks :

  • BizTalk 2006 Recipes – A Problem-Solution Approach – Mark Beckner, Benjamin Goeltz, Brandon Gross,
    Brennan O’Reilly, Stephen Roger, Mark Smith,
    and Alexander West
  • Foundations of BizTalk Server 2006 – Daniel Woolston
  • Wrox Professional BizTalk® Server 2006 – Darren Jefford, Kevin B. Smith, Ewan Fairweather