|
I am way behind on parsing some threads, so appologize if this already
satisfactorily answered. Your informant is both wrong and misleading
dated. The AS/400 world both supports earlier philosophies and supports
new ways of doing things. There are multiple opportunities for sorted
data, and multiple opportunities for abuse. Like this list is so
overwhelming in traffic volume, some newbies might get turned off.
Decades ago on systems that the AS/400 grew out of, such as S/34 & S/36,
the way we sorted records was a choice of:
* Physically rearrange large masses of records, which tended to eat a lot
of disk space, and take a while to get done. This harkens back to a
philosophy long before current computers, of physically sorting the
records before feeding them into a program that processed one record at a
time. There may be business applications where that makes sense today,
but I do not have much experience with them. More often, the records that
need to be accessed are dependent on the records processed so far. The
400 supports this today via FMTDTA & QSORT.
* Create an address index, in which the index records contain the basis of
the sort, and the addresses of the detail records, then sort this index,
which tended to go extremely fast, and not eat so much disk work space ...
this was called an ADDROUT sort. In today's programming world, we can
create and uncreate this kind of index on the fly ... a software job
stream creates the logical index needed, the main program processes the
data in the specified sorted sequence, then the index is uncreated, or
rather cleared is the modern approach. Even though some software may
explicitly call for a particular logical index, the 400 OS might use a
different one that seems more efficient for the current task, so the inner
logic needs to be explicit what records to include exclude, not rely
totally on specified logic path.
* Create a logical path accessing the records in the sequence desired. In
ancient S/36 days this was called an alternate index, but today it is
called a logical file. This was like a permanent ADDROUT file, kept
current with any updates to the physical records. There is some overhead
maintaining both the physical file and lots of logicals, offset by the
sheer speed of accessing the physical records any time we need them listed
in whatever sorted sequence, and low overhead for the system compared to
actually rearranging the records.
You need to be careful in how you name & store logical files, to avoid
hassles when restoring from backup.
Since the logical data may jump around a lot relative to how the data is
organized, you want to be very careful about whether you want to use the
design feature of blocking where you read in chunks of records at a time.
Now we can do a periodic reorganization of the data in a physical file,
such as to get rid of deleted records (or records coded for deletion),
where we specify a particular logical to be used as the sequence for the
physical. Generally you can't have other people accessing a physical file
during the reorganization, and this can be a burden on maintaining the
contents of various logicals over the file being rearranged.
Some files deliberately add records to the end, as opposed to dynamically
removing deleted, then looking for a hole to add new records, in the
interests of access speed during peak loads.
At program compile time, one set of files can be designated, then at
program execution time, the CL can use "data base override file" to use
different logicals than those used in the compile, which works so long as
they have the same layout. That applies to normal access, but it is
potentially a different reality for sub-programs & embedded SQL.
Since the AS/400 replaced S/36 & S/38, and as the AS/400 advanced to new
names, there has been an explosion of other programming languages, such as
SQL/400 supporting the equivalent of ADDROUT logical sequences on the fly,
of selected portions of a mass of physical files, and sub-sets of joins
between selected portions of multiple files.
Logical files are not only sequencing. They are also include omit. They
can be joins of multiple physical files, but they do have some
limitations.
For example, I recently needed to modify a program to sort the data by a
field that is not in the primary input file & I discovered that when you
do a join, all the data used for sequencing has to be in whichever file
you designate as the primary, so I used OPNQRYF ("open query file")
technique to build the work file then sued as the primary input. I do not
advise a newbie trying to start out with "open query file", you need to
learn CL first, and get pretty good in CL, which is unlike any control
language on prior platforms. However, "open query file" does have a lot
of parallels with embedded parameters of S/36 which is what I was on
before AS/400. I think SQL is a much cleaner programming approach than
"open query file", but my access to good documentation influences which
tools I rely on the most.
I use DDS in the design of all my logical files, but SQL can also be used
for this. Most of the SQL that I write is embedded inside RPG programs.
I assume it can also be embedded in COBOL. Basically in RPG / COBOL we
are reading one record of a file at a time, all column fields of the file
record, but with embedded SQL we can process some join of multiple files,
selected records, entire columns, at a time. I use both the DO IT in some
subroutine, and the CURSOR approach of setting up a pattern of wading
through a set of data.
I have heard of API's, not used many of them, need to learn more, since I
can see they are very powerful. I have not yet had occasion to explore
the QSHELL so there may be opportunities there I am missing out on.
I also use Query/400 a lot for data mining, quickie and simple reports.
List,
This is an iSeries newbie question so please bare with me. We are
getting
started on the project of migrating applications (all batch) from VSE
(mainframe) to iSeries. I was "told" by someone that is a long-time
AS/400
person that "there is no system sort on the iSeries". I find that very
hard
to believe. There must be some system provided sorting mechanism. I see
that
ILE/COBOL fully supports the SORT verb so that must be interfacing with
a
system-provided utility.
I searched for "sort" in the iSeries information center and could not
find
any explicit references to a sort program or utility.
Perhaps the person meant that there is no "sort program" that you can
explicitly execute in batch (as you can in the VSE world). Could someone
authoratively clear this up for me please? TIA
--
Regards,
Michael Rosinger
Systems Programmer / DBA
Computer Credit, Inc.
640 West Fourth Street
Winston-Salem, NC 27101
336-761-1524
m rosinger at cciws dot 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.
-
Al Macintyre
http://en.wikipedia.org/wiki/User:AlMac
http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor ... see
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.