Re: CHAIN + DS as result field -- RPG400-L

But why would you pass by reference? If you pass by reference you are
saying you want the keys modified.

Second, is the idea of your SetLL to get a record near the one you
want or are you trying to get the record that matches the key?

If you are matching the key, you want

SETLL ( Filekey1 : Filekey2 ) MyFile;
If %Equal(MyFile);
READ MyFile;

But you are better to always do a

Chain (FileKey1:FileKey2) MyFile
If %Found(MyFile)

Setll followed by a Read requires two I/O operations vs one with the Chain.

See people do this all the time and never quite sure why.

In either case, the keys match and nothing changes.

Also, the field names of the key fields are different than the
database fields. How could the values get changed?

n Tue, Feb 17, 2009 at 9:25 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx> wrote:

Alan, I just replaced
Chain (Value1:Value2) FILE1 wRecord1;
With
Chain %Kds(WRecordKey) FILE1 wRecord1;

This morning and I was asking myself the same question.
Well, the code looked neater as one file had 2 key zones and the other 6 but that's no reason.

Then I was reminded of the problem I've had with parameters passed by reference being modified.

I'm reading a subfile and passing the key values I've read to the subprocedure a bit like this :

READC Mysubfile
GetDbRecord ( SFzone1 : SFzone2 )

GetDbRecord PI
Filekey1
Filekey2

I 'think' if you do something like this :

SETLL ( Filekey1 : Filekey2 ) MyFile;
READ MyFile;

You can modify SFzone1 and Sfzone2. Which wouldn't happen if I used the KDS.

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Alan Campin
Envoyé : mardi 17 février 2009 17:07
À : RPG programming on the IBM i / System i
Objet : Re: CHAIN + DS as result field

Just curious. Why would you ever want to use the form of

Chain %Kds(WRecordKey) FILE1 wRecord1;

instead of

Chain (Value1:Value2) FILE1 wRecord1;

I don't use file I/O anymore but it puzzles me why you would want to use the %Kds when you can just list the fields you want in the key. If you use the %Kds then you have to go look up the key values and you have to load the key values.

Just never understood the value.

On Tue, Feb 17, 2009 at 8:46 AM, Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx> wrote:

Without testing, doesn't the chain need to be like this:
CHAIN %kds(WrecordKey) FILE1 Wrecord1;

Also, don't forget, David, that you'll still have to load the key values, and they'll be qualified.

e.g. wRecordKey.key1 = myvalue;

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of M. Lazarus
Sent: Tuesday, February 17, 2009 9:13 AM
To: RPG programming on the IBM i / System i
Subject: RE: CHAIN + DS as result field

David,

You're missing the key on the CHAIN! Assuming that the key is
identical for both files, try this:

D WrecordKey DS LIKEREC ( RECORD1 : *Key )
D Wrecord1 DS LIKEREC ( RECORD1 : *INPUT )
D Wrecord2 DS LIKEREC ( RECORD2 : *INPUT )

When condition1
CHAIN WrecordKey FILE1 Wrecord1;
EVAL-CORR Globalrecord= Wrecord1;

When condition2
CHAIN WrecordKey FILE2 Wrecord2;
EVAL-CORR Globalrecord= Wrecord2;

-mark

At 2/17/09 04:16 AM, you wrote:

Thanks, Alan

I already had the global definitions as you suggest.

In my subprocedure, I now have :

D Wrecord1 DS LIKEREC ( RECORD1 : *INPUT )
D Wrecord2 DS LIKEREC ( RECORD2 : *INPUT )

When condition1
CHAIN FILE1 Wrecord1;
EVAL-CORR Globalrecord= Wrecord1;

When condition2
CHAIN FILE2 Wrecord2;
EVAL-CORR Globalrecord= Wrecord2;

So now I can put the result into one common DS, thanks again.

I don't find the compile message very clear. Just to test it, I tried :
CHAIN FILE1 Wrecord2;

File1 is a PF with RECORD1, File2 is an LF with RECORD1 renamed RECORD2.

This is an extract of the compiled listing : the gravity level of the
message is 20 although in the summary there is just one message at
level 30. If I look at the definitions of Wrecord1 and Wrecord2 they
are identical.

*RNF7701 20 1 La structure de données n'est pas admise pour l'opér
* * * * * F I N D U R E C A P I T U L A T I F D E S M E S S A
5722WDS V5R4M0 060210 RN IBM ILE RPG D126169V03/CL
R é c a p i t u l a t i f f i n a l
Nombre total de messages :
Information (00) . . . . . . . : 4041
Avertissement (10) . . . . . . : 11
Erreur (20) . . . . . . . : 0
Erreur grave (30+) . . . . . . : 1

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Alan Campin
Envoyé : lundi 16 février 2009 18:58 À : RPG programming on the IBM i
/ System i Objet : Re: CHAIN + DS as result field

What release level are you at? The new ability to pass a file to a
sub-procedure looks perfect for you. (V6R1).

The other one I could think of is why not just use an override? Have
one dummy input file overridden to the actual.

The other one I could think of is that you do not need a separate data
structure. Couldn't you declare a templete (Type defintion) in the
header and use EVAL-CORR?

d TD_FORMAT...
d e ds ExtName(LF1)
d Based(StdNulPtr)

d FileData...
d ds LikeDs(TD_Format)

FileData = GetFileData(values);

In Subprocedure

d FileData...
d ds LikeDs(TD_Format)

Chain LFILE1 DS1;

Eval-Corr FileData = DS1;

Return FileData;

This could be especially handy if you don't want all the data.

Not sure I am really answering your question.

On Mon, Feb 16, 2009 at 10:09 AM, David FOXWELL
<David.FOXWELL@xxxxxxxxx> wrote:

I don't understand why I can't do this :

I have a procedure that selects which LF to

CHAIN to depending upon its input parameters.
All the LF's compiled on the same PF.

Trouble is I seem to need a different DS

receptor for each LF. When I try to compile I get RNF7595 "Position
1of the DS doesn't contain a subzone for a record format".

If I look at the compile listing of the DS

definitions DS1 and DS2, they seem to be identical.

D DS1 LIKEREC(LFORMAT1 *INPUT)
D DS2 LIKEREC(LFORMAT2 *INPUT)

CHAIN LFILE1 DS1;

CHAIN LFILE2 DS2;

How can I get the result of the CHAIN into one common DS?

Thanks.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.