Why is this so diffcult to space so it is readable?

Because it is rendered with HTML.

First, you’re not controlling the font. Simply pasting text without font specification allows the browsers to choose defaults. Second, HTML compresses consecutive whitespaces. If you don’t don’t put formatting codes into the HTML, it will provide default formatting. Third, if you copy/paste without including carriage-return/line-feed characters, you’ll get run-on results from one line to the next. (5250 green-screens don’t have ant CR/LF characters to copy, so none get pasted.)

The editor provides a {code} button. If you surround code with {code} tags supplied by the button, you’ll have better results. The “How to use…” link tells you about this so you don’t have to ask.

This is my error: *RNF7260 30 3 The Factor 2 operand is not valid for the specified operation.

The error apparently says that you have three source lines where you have something in the Factor 2 portion of the instruction that can’t be used there. CharlieBrowne possibly covers two of those.

I’d also question the EXCEPT FILE02 lines. I can’t quite determine what this line is trying to specify:

OFILE02     E                ADD

It’s not clear if “ADD” is intended to be an exception-name or a record-addition code. Either way, there is no exception-name of FILE02; that’s a file-name. (Maybe that works and just isn’t documented.)

Regardless, either 2 or 4 lines seem indicated as possible errors, yet the RNF7260 seems to be telling us “3″.

Without seeing readable code, and possibly more of the code, I don’t know what more can be said.

Tom

Your EXCEPT lines are specifying a file name not a output exception name.
Try EXCEPT ADD.

Better yet delete this crappy pgm and just do a CPYF command and select only records with RECTYP = “H”

…just do a CPYF command…

I’d suspect the subroutine MOVEREC simply moves the three input fields to the output fields. But without seeing the code, it’s just a guess.

…records with RECTYP = “H”

And do what with records with RECTYP = “N”?

Tom

Due to my inability to get the spacing right, I didn’t include the subroutine. Yes, it did just move the 3 fields to the new fields.

I did end up just creating the new file that will hold the set of records that I needed. I couldn’t use the CPYF command as it was important to keep the records in the order I was reading them. I also needed to change the M to an N as I was copying the records over.

I am going to try the suggestions you gave me, so I can see if that solves the problem with program described files.

Thanks everyone!

I will try

…it was important to keep the records in the order I was reading them. I also needed to change the M to an N as I was copying the records over.

CPYF can keep the records in the same order. A single SQL UPDATE statement could change all of the “M” codes to “N”.

Tom

Here is the data:
H…
M1…
M2…
M3…
M4…
N1…
N2…
N3…
N4…
M1…
M2…
:
T…
H…
M1…
:
T…

I copy the H to the new file, then the N* records, then the T, then the H, etc. They must all stay in the same order as they are in the file. While I can use SQL to update the N to an M, I can keep the records in the order that they are in in the input file and change the RECTYP in 1 program.

…I can keep the records in the order that they are in in the input file and change the RECTYP in 1 program.

Yes, but why write a program that has many instructions when you can do it with two instructions plus one SQL statement?

(Especially if the program is showing errors.)

Tom

Maybe this will help you achieve your goal. We use this technique for one-time situations or where performance is not a consideration. FROMRCD(1) will keep your output records in the same sequence as in file A. If your output file only contains the three fields the FORMAT parm will take care of that.

CPYF FROMFILE(A)                       
     TOFILE(B)                         
     MBROPT(*REPLACE)                  
     FROMRCD(1)                        
     INCREL((*IF RECTYP *EQ 'H'))      
     FMTOPT(*MAP *DROP)