Have you actually tried this? I don't think that this will work as you are proposing.
When you run OPNQRYF, if creates the equivalent of a temp LF. When COBOL reads this temp LF, it will read it as a PF (assuming no changes to the COBOL pgm to access C1BMNAM by key).
You would have to do CPYFRMQRYF after the OPNQRYF to order the physical data - then the COBOL pgm would read in the sequence that you desire.
If the requirement is to NOT touch the COBOL pgm, then the physical data must be re-ordered. I would expect FMTDTA to be faster than OPNQRYF/CPYFRMQRYF or any other method.
But, it is so simple to change the COBOL to read an indexed file. Maybe there are other constraints which require no changes to the COBOL.
Another option is SQL to re-order the data.
I don't see how OPNQRYF or LF or any kind of index will get you there.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Zak Metz
Sent: Tuesday, September 24, 2013 2:09 PM
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: Sort input file by arbitrary position/length
I have an existing COBOL application that cannot be changed, at least, let's say it can't.
The COBOL application accepts an input file of an arbitrary record length like so:
SELECT C1BMNAM
ASSIGN TO DISK-C1BMNAM
FILE STATUS C1BMNAM-FILE-STATUS
.
I want it to process the file sorted by a certain position/length (ZIP Code) determined at run time. But if I create an LF, it doesn't read it in order by key.
What I thought I could do was use OPNQRYF to do that sorting on the fly, something like:
OPNQRYF FILE((METZ3410/PF)) KEYFLD((*MAPFLD/ZIP)) MAPFLD((ZIP '%sst(pf 133 5)')) OPNID(C1BMNAM) SEQONLY(*NO) OPNSCOPE(*JOB)
That works for a file with one field. The COBOL is none-the-wiser.
But the input file might have multiple fields. All I know is the position/length.
Is there some way to make my MAPFLD substring the entire record without knowing what field the position/length actually falls into? I just want to substring the entire record.
Because the file may be very large, I do not want to take the performance hit of copying it to a single-field file. But if there were some other way to trick it...
Thanks in advance for any and all suggestions.
Zak Metz, Principal Software Engineer
Pitney Bowes Software
1664 Princess Ln | Frisco TX | 75034-8715 | USA
507-384-9069 | www.pb.com<
http://www.pb.com/>
zak.metz@xxxxxx<mailto:zak.metz@xxxxxx>
Every connection is a new opportunity(tm)
________________________________
midrange.com
