RE: Sort input file by arbitrary position/length -- MIDRANGE-L

Let's call it arrival sequence rather than physical sequence. There literally is no "physical sequence" to records scattered all over the disk by memory management. DB2i manages to maintain an arrival sequence only to emulate what some might have known to be physical sequence on other machines where files were stored in contiguous disk sectors.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Wednesday, September 25, 2013 9:34 AM
To: Midrange Systems Technical Discussion
Subject: Re: Sort input file by arbitrary position/length

I would try changing the program to reference the new logical - you might
then be able to get the original data sequence by pointing the OVR at the
original file - be worth trying. But like RPG COBOL will always read in physical
sequence if no keyed access is specified.

On 2013-09-24, at 9:54 PM, Zak Metz <Zak.Metz@xxxxxx> wrote:

Jon, sounds like you're saying I should change the Cobol. I'm assuming the

file spec will need to be different based on if the file is really keyed or not,
like RPG. That's a possibility, even if my initial plan was not to change the
Cobol. Keep in mind the input file is currently not keyed. I could generate the
DDS and compile an LF on the fly, though. Thanks for your expertise!

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-

bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris

Sent: Tuesday, September 24, 2013 3:54 PM
To: Midrange Systems Technical Discussion
Subject: Re: Sort input file by arbitrary position/length

I agree with Buck - the COBOL program really needs a small tweak. It is

reading in physical sequence because it has not been told it is a keyed file.
RPG would do the same if the file were defined without the K in the F-spec.

You could either leave the existing file refs in place and add a new indexed

file, or add indexing to the spec for the existing file.

I suspect that the COBOL program (as long as there is no actual START

operation or anything else that uses a key) will not actually check if the key is
in the spot specified - but telling it to use a key will make it request the data
in keyed sequence. No guarantees as the COBOL compiler does some stuff
just to ensure ANSI compliance - and since most systems don't have
externally described files key location may be tested at run time but ...

On 2013-09-24, at 3:54 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 9/24/2013 3:08 PM, Zak Metz wrote:

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.

I never imagined a tagalong sort would be a good fit in 2013.

I still don't.

This seems like a utility of some sort. If you're satisfied with the
OPNQRYF solution, consider writing a front-end that programmatically
generates those specs and compiles the CLP.

Considering the amount of work you are going to be going through to
keep the existing Cobol program unchanged, for the sake of
completeness you ought to consider the amount of work it would take to
tweak the Cobol program instead.
--buck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please

take

a moment to review the archives at
http://archive.midrange.com/midrange-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,

visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please

take a moment to review the archives at
http://archive.midrange.com/midrange-l.

________________________________

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.