you should probably define it as USAGE(*INPUT: *OUTPUT) - at least that's one possibility
Announcement
Collapse
No announcement yet.
files, fields and records
Collapse
X
-
i tried that as well but this program is not writing any valid values corresponding from lp6( first file) it's writing as :-
Line ....+....1....+....2....+....3...
ID DOB NAME
000001 0 0001-01-01
000002 0 0001-01-01
000003 0 0001-01-01
000004 0 0001-01-01
000005 0 0001-01-01
000006 0 0001-01-01
****** ******** End of report ********
where as in LP6 data was like below:-
Position to line . . . . .
Line ....+....1....+....2....+....3.
ID DOB NAME
000001 1 05/03/85 N1
000002 1 05/03/85 N1
000003 1 05/03/85 N2
000004 1 05/03/85 N3
****** ******** End of report ********
Thanks..
Comment
-
Data in LP6:-
Code:Line ....+....1....+....2....+....3. ID DOB NAME 000001 1 05/03/85 N1 000002 1 05/03/85 N1 000003 1 05/03/85 N2 000004 1 05/03/85 N3 ****** ******** End of report ******** Data in LP 7 when program ran:- Position to line . . . . . Line ....+....1....+....2....+....3... ID DOB NAME 000001 0 0001-01-01 000002 0 0001-01-01 000003 0 0001-01-01 000004 0 0001-01-01 000005 0 0001-01-01 000006 0 0001-01-01 ****** ******** End of report ********
-
-
when the program executes statement 'WRITE REC2', nothing has been done to set the values of the fields in that Record Format, i.e. B_ID, B_DOB and B_NAME.
Probably, you'd need to add some code such as:
Code:B_ID = A_ID; B_DOB = A_DOB; B_NAME = A_NAME;
(if that's the intention of the program)
Comment
-
Thanks, after doing EVAL operations and correcting the date format in LP7 as *DMY now the program generated output like below:-
Code:Position to line . . . . . Line ....+....1....+....2....+....3. ID DOB NAME 1 05/03/85 N1 ****** ******** End of report ********
LP6( from file 1 or file A in general term) into LP7 (or into file 2 or file B in general term) but ideally unique record set should have been like below in lp7 (or in second file fileb,or file2 in general term):-
Code:ID DOB NAME 1 05/03/85 N1 1 05/03/85 N2 1 05/03/85 N3
Also here we did EVAL
for below fields used in files-
B_ID = A_ID;
B_DOB = A_DOB;
B_NAME = A_NAME;
But what about a case where we have multiple fields in file A and B
then for each such fields do we need such Eval operations for all the fields involved in FileA & B?
Is there any other alternative to avoid so many eval operations for these fields considering if we have many such fields involved in file A and B?
So 1) If I want output in second file ( in lp7 here ) below format in terms of unique data set ( considering here Key fields ID and DOB and third field Name which is not keyed in any of the files (LP6,LP7) then what changes should i do in this program ?
Code:ID DOB NAME 1 05/03/85 N1 1 05/03/85 N2 1 05/03/85 N3
2) Any alternative for avoiding multiple such Eval operations inside RPGLE program only ?
3) If we are selecting unique records for three fields ( though currently testing this program for two fields only) then file2 or second file or file B ( here file LP7 I have used for same purpose in my program) should also have the 'same key fields' defined in it ,I am saying so because when I tested this program without defining 'the same key fields' in file2 ( here on LP7) then program gave some compilation error related with key fields and it was resolved only when I declared file2 (lp7 here) with same set of key fields used in file1 (lp6 here) ?
Thanks...
Comment
-
The DDS for the tables does not specify that the key must be unique. That means each table can hold multiple records with the same key. https://www.google.com/search?client...dds+unique+key
So if table lp6 has multiple records with the same ID and DOB, it will write those duplicates to lp7.
If you run the program more than once, it will write the same records again and create duplicates.
You say you want unique records by ID and DOB. Do you mean you want only one record per ID and DOB?
So if lp6 has multiple records with the same ID and DOB, you want only one of those recordss to be written to IP7?
If so, how you would do that depends on which of those duplicates you want to write.
Comment
-
Yes, for only one record per ID and DOB
what changes in this program should i make to get output written in LP7 like below if i have below set of Data in LP6:-
Physical file P6 DDS:-
Code:SEU==> FMT PF .....A..........T.Name++++++RLen++TDpB......Functi ons+++++++++++++++++++++++++++ ... *************** Beginning of data ************************************************** 0001.00 R REC 0002.00 ID 3P 0 0003.00 DOB L DATFMT(*DMY) 0004.00 NAME 15A ****************** End of data ************************************************** ***
LP6 Data:-
Code:Line ....+....1....+....2....+....3. ID DOB NAME 1 05/03/85 N1 1 05/03/85 N1 1 05/03/85 N2 1 05/03/85 N3 ****** ******** End of report ********
Desired LP7 Data:-
Code:ID DOB NAME 1 05/03/85 N1 1 05/03/85 N2 1 05/03/85 N3
Code:Position to line . . . . . Line ....+....1....+....2....+....3. ID DOB NAME 1 05/03/85 N1 ****** ******** End of report ********
Thanks...
Comment
-
LP7 DDS without Unique keyword:-
Code:Columns . . . : 1 100 Browse SEU==> FMT PF .....A..........T.Name++++++RLen++TDpB......Functions+++++++++++++++++++ *************** Beginning of data ************************************** 001.00 R REC 002.00 ID 3P 0 003.00 DOB L DATFMT(*DMY) 004.00 NAME 15 005.00 K ID 006.00 K DOB ****************** End of data *****************************************
-
-
It appears that the CHAIN operation in your program is NOT finding the records that you've already written to file LP7, even though they should, in theory, have the same key values in fields ID and DOB.
I can think of two possible reasons for this (there may be more):
1) the key values being used on the CHAIN operation (fields A_ID and A_DOB) are somehow different to the values that get written to the file...
2) the file is being processed as Sequential Only (SEQONLY(*YES)) - that would mean that records are written out in blocks rather than one at a time and, in some situations, this can be the cause of records not being found by READ/CHAIN operations even though the record should, in theory, already exist.
I think it's very unlikely that 2) applies in this situation because you now have USAGE(*INPUT: *OUTPUT) specified for the file, however it's perhaps worth checking your compiler listing to see if contains message RNF7086 ("RPG handles blocking for the file...").
Comment
-
I would agree with JohnLewis that it is very likely the 2nd option as RPG will not be writing the records to the file straight away but caching them up and writing them in blocks (I had a similar issue with a program I had written). You will either need to specify BLOCK(*NO) on the physical file (LP6 I think) file specification or create a CL wrapper and issue an override to the file: OVRDBF FILE(LP6) SEQONLY(*YES 1). This will ensure it writes the record straight away and the LF reflects the data.
Comment
Comment