Re: Simple record extraction from a sequential file

[Rick Fochtman]

-
I am of course familiar with production-control schemes. Production must 
be orderly, but in my experience bureaucratic controls alone do not 
reduce errors: They only diffuse responsibility.


I have, on admittedly rare ocaisions, seen some of those controls catch 
errors, usually where programmers made invalid assumptions about input 
data quality and/or quantity.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Rick Fochtman]

Frank Yaeger wrote:


Rick Fochtman on IBM Mainframe Discussion List  wrote
on 11/21/2011 01:38:29 PM:
 


Take a look at DFSORT, using INCLUDE/EXCLUDE control statements

   



For the record, that's INCLUDE/OMIT, not INCLUDE/EXCLUDE.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

 



Working from obviously faulty memory. Thanks for the correction, Frank.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of John Gilmore
> 
> You have a response that apparently meets your needs.
> 
> Your question interests me for another reason.  I asked two admittedly
very bright 15 year olds to
> write a  parameterized--a value V, a field of length L, and a
one-origin offset O of its first byte--
> PL/I procedure to do what you want to do.
> 
> It took them 10 and 13 minutes, respectively, to come up with correct,
working procedures complete
> with bullet proofing and test cases.
> 
> The use of the SORT to do this job seems to me to be much akin to
using a piledriver to set a ten-
> penny nail., and I should be interested to know why you sought a
canned solution to a problem of this
> sort.

"Everybody" has a SORT utility.  Not everybody has a [PL/I|other HLL]
compiler.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Shmuel Metz (Seymour J.)]

In <2216332688619964.wa.elardus.engelbrechtsita.co...@bama.ua.edu>, on
11/22/2011
   at 01:38 AM, Elardus Engelbrecht 
said:

>Those teenagers who can program in PL/I are very good, I admit, but
>what is the PL/I overhead?

For what? The last time that I looked the overhead for I/O was very
low. The overhead for bit manipulation was ludicrous; subroutine calls
for things that should have been inline code.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Ed Gould]

 Well we still have a issue as I have been burned with oem and IIRC IBM utility 
and for that matter JES2 changes that killed production because of a JCL or 
control card change. From a sketchy memory DFSORT, JES2 were all culprits of 
IMO unforgivable sin of changing rules. Without proper hold  actions or 
notifications to the users of changes. 
So as I would like to say in addition to user slipping in changes IBM is guilty 
as well.
Hold actions are. exactly for this, IMO. That is why SMPE and with proper hold 
actions are really needed.

Ed




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Anne & Lynn Wheeler]

elardus.engelbre...@sita.co.za (Elardus Engelbrecht) writes:
> Not everyone can program properly. Not everyone can program a fast
> tight code specially optimised for that specific record layout and
> format and do it in Assembler. Those teenagers who can program in PL/I
> are very good, I admit, but what is the PL/I overhead?

old email about high level POK executive giving presentation about vm370
would no longer be available on high-end machines.  HONE was the
internal vm370-based online system that provided for world-wide
sales&marketing support; most of the applications written in APL.  The
executive told them that they could migrate from vm370 to mvs if they
would just rewrite all the apl applications in assembler (overhead
reduction in apl->assembler would offset the enormous increase in
overhead from vm370->mvs)
http://www.garlic.com/~lynn/2007d.html#email790216

followup was that the executive had apparently been using
the wrong flipcharts for the presentation
http://www.garlic.com/~lynn/2007d.html#email790220

misc. past posts mentioning HONE
http://www.garlic.com/~lynn/subtopic.html#hone

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Shmuel Metz (Seymour J.)]

In
,
on 11/21/2011
   at 02:43 PM, Donald Russell  said:

>Though clearly the programming effort to write my own code to do this
>is trivial, the reason for wanting a "canned solution" is to avoid
>all the "business rules and procedures" associated with writing
>"custom code".

Except that it isn't a canned solution, since you have to write the
control cards whether you use IEBDG, IEBGENER or a sort. If they are
exempt from your QA procedures then you have a ticking time bomb on
your hands.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Farley, Peter x23353]

Ed,

I did not say that a JCL sort (or any other "utility" job) with only control 
cards as "program" need not be tested at all, only that the lifecycle processes 
and paperwork *may* be less stringent and thus easier to navigate quickly when 
there is a need to do so.

Any process that even permits the possibility of something being "slipped in" 
without even a cursory review along the way to production gets what it deserves.

When you are dealing with other peoples' money (i.e., their data), it behooves 
one to be *quite* careful how it is handled.  Promotion to the street should be 
expected if adequate care is not taken.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ed Gould
Sent: Monday, November 21, 2011 7:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Simple record extraction from a sequential file

 Peter,

I both agree and disagree with you entry.
There Is a strong case for testing for even the most simplistic of programming 
whether it be a iebgener or sort or what ever utility you want to use. On at 
least 2 occaisons a programmer slipped into a production job stream untested 
and production went down in flames. All hell broke loose and we had two 
VP's fired and a programmer.
It's one thing for a COBOL compile it's something else for production.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Gilmore
> Sent: Monday, November 21, 2011 8:13 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Simple record extraction from a sequential file
> 
> My post provoked a good many responses, and I am happy thagt 
> it did so.
> 
> What is interesting about them is that the arguments against my view,
> many of them cogent, were bureaucratic, not technical.
> 
> One reason why mainframe shops are being supplanted by less effective
> and in particular less reliable technology is that they are usually
> much older and thus organizationally senescent too.  They are managed
> for the most part by people who either 1) never understood the
> technology or, worse, 2) understood it well circa 1975.
> 
> In the upshot these shops are bureaucratic, technically inadequate,
> shy of innovation, and risk-averse in general.  The technology is not
> obsolete; the culture is, irretrievably so I fear.
> 
> John Gilmore, Ashland, MA 01721 - USA

Curiously, around here, the "open system" arena is becoming as bureaucratic and 
"risk adverse" as anything in the z area. And the "Windows weenies" are 
becoming frustrated as well. Gone are the cowboy, shoot from the hip, days. 
Long gone are the days of getting the newest and glitziest hardware and 
software. Now, for everybody and everything, it is "money, money, money". 
Strange that this company is "leading edge" in this. 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Binyamin Dissen]

On Tue, 22 Nov 2011 01:38:10 -0600 Elardus Engelbrecht
 wrote:

:>John Gilmore wrote:

:>>My post provoked a good many responses, and I am happy thagt it did so.

:>:-D

:>>What is interesting about them is that the arguments against my view, many 
of them cogent, were bureaucratic, not technical.

:>There is a reason - if you are hosting other's data, you had be careful about 
their data - better go with their bureaucratic nonsense.

:>>They are managed for the most part by people who either 1) never understood 
the technology

:>Not everyone can program properly. Not everyone can program a fast tight code 
specially optimised for that specific record layout and format and do it in 
Assembler. Those teenagers who can program in PL/I are very good, I admit, but 
what is the PL/I overhead? 

:>>In the upshot these shops are bureaucratic, technically inadequate, shy of 
innovation, and risk-averse in general.  

:>'Risk-averse' - yes, especially if the data to be manipulated is NOT yours, 
but belongs to other OWNERs. Then you had better get your programs (utility or 
RYO) working, otherwise they will drop you in a nanosecond.

:>Just my opinion - and only my own opinion.

The eternal conflict between those that live in ivory towers and those that
understand business.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Elardus Engelbrecht]

John Gilmore wrote:

>My post provoked a good many responses, and I am happy thagt it did so.

:-D


>What is interesting about them is that the arguments against my view, many of 
>them cogent, were bureaucratic, not technical.

There is a reason - if you are hosting other's data, you had be careful about 
their data - better go with their bureaucratic nonsense.


>They are managed for the most part by people who either 1) never understood 
>the technology

Not everyone can program properly. Not everyone can program a fast tight code 
specially optimised for that specific record layout and format and do it in 
Assembler. Those teenagers who can program in PL/I are very good, I admit, but 
what is the PL/I overhead? 


>In the upshot these shops are bureaucratic, technically inadequate, shy of 
>innovation, and risk-averse in general.  

'Risk-averse' - yes, especially if the data to be manipulated is NOT yours, but 
belongs to other OWNERs. Then you had better get your programs (utility or RYO) 
working, otherwise they will drop you in a nanosecond.

Just my opinion - and only my own opinion.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Ed Gould]

 Risk averse is not a great term when you are talking about billions of dollars.
And I do mean billions.  The stock market doesn't open. We are not talking 
about 1 programmer you are talking about groups of people. So what is being 
cautious when peoples jobs/lives are affected?
If multiple people are asked to sign off on a small change it's small 
inconvenience to get sign off, no?

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[John Gilmore]

My post provoked a good many responses, and I am happy thagt it did so.

What is interesting about them is that the arguments against my view,
many of them cogent, were bureaucratic, not technical.

One reason why mainframe shops are being supplanted by less effective
and in particular less reliable technology is that they are usually
much older and thus organizationally senescent too.  They are managed
for the most part by people who either 1) never understood the
technology or, worse, 2) understood it well circa 1975.

In the upshot these shops are bureaucratic, technically inadequate,
shy of innovation, and risk-averse in general.  The technology is not
obsolete; the culture is, irretrievably so I fear.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[John Gilmore]

Ford Prefect wrote:

| John,
|
| I think you'd be hard pressed to write a program in either C or PL/I that
| would even approach the I/O performance of DFSORT.  In fact, I doubt it's
| possible.

This is the received opinion, but it is wrong.

In C it would be all but impossible.  In PL/I it would be
comparatively easy in this particular situation.  (In general, of
course, assembly language can be made to yield noty just better but
much better performance., and DFSORT I/O is superb.  It is not,
however, optimized for a situation in which much of SORTIN is
discarded.)

What can be done in statement-level procedural languages and what is
usually done in them needs to be distinguished sharply.

COBOL I/O is not notorious for performance, but on Thursday my wife
and I shall be drinking the last two of six bottles of six bottles of
Le Montrachet that I won from a colleague who judged that high
performance was impossible in COBOL.  (For historical reasons COBOL
does better record I/O than C.  Things could be otherwise if it were
judged important that they should be, but they are not.)


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Gerhard Postpischil]

On 11/21/2011 6:13 PM, John Gilmore wrote:

I am of course familiar with production-control schemes.  Production
must be orderly, but in my experience bureaucratic controls alone do
not reduce errors: They only diffuse responsibility.


Some of us are handicapped by management uneasy with things they 
do not understand. Rigid and rigorous procedures for adoption of 
production changes are the most benign form of this; I worked as 
a contractor at a site where we failed to convince management 
that a particular approach would save them time and money. A 
manager unable to complete a work load in a batch window has 
plenty of excuses the higher-ups will understand (more work to 
process - we need a faster machine), whereas a radical change 
the manager can't explain may result in unemployment at the 
slightest hint of a problem.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Ed Gould]

 Peter,

I both agree and disagree with you entry.
There Is a strong case for testing for even the most simplistic of programming 
whether it be a iebgener or sort or what ever utility you want to use. On at 
least 2 occaisons a programmer slipped into a production job stream untested 
and production went down in flames. All hell broke loose and we had two 
VP's fired and a programmer. 
It's one thing for a COBOL compile it's something else for production.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Farley, Peter x23353]

John,

I have to disagree with you as concerns the efficiency of SORT I/O (of the main 
two SORT competitors at least) vs. statement level language I/O.  In my 
experience, the proprietary EXCP (or even lower) level algorithms used by SORT 
will almost always exceed the efficiency of even the best-written HLL 
applications program.  SORT can do things at a level just not available (or not 
easily available) to the general programming public.  I think it would not be 
inaccurate to state that channel programming is just not in the skill set of 
99.99% of programmers, and due at least to privilege requirements is not 
usually available to a programmer even if they have the skill set.

The observed performance numbers speak for themselves.  My admittedly 
unscientific observations have always seen a decrease in consumed resources *on 
the same task* for SORT vs. any HLL I have ever used, and in very large volume 
cases I generally see quite large decreases.

I also admit that for small data volumes the observed decrease in resource 
usage may not be (easily) observable.

I can certainly agree with your comment on the ultimate usefulness of 
bureaucratic controls alone as error-reduction mechanisms.

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John Gilmore
> Sent: Monday, November 21, 2011 6:14 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Simple record extraction from a sequential file
> 
> I am not at all hostile to DFSORT, which I now prefer slightly to
> SYNCHSORT.
> 
> I am, however, hostile to the notion that I/O in a statement-level
> language is always inferior to that of DFSORT.  Here both of my young
> programmers used a locate-mode READ-SET for the input records,
> examined each in its buffer, and an effectively asynchronous move-mode
> WRITE-TO a LOCATEd position in an output buffer for the selected
> records.  Their JCL included appropriate BUFNO=, etc.
> (Interestingly, something very similar could be but in fact is almost
> never done in COBOL with a reusable C or PL/I driver.)
> 
> I am of course familiar with production-control schemes.  Production
> must be orderly, but in my experience bureaucratic controls alone do
> not reduce errors: They only diffuse responsibility.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Jonathan Goossen]

Another reason to use Sort instead of a home grown program is 
maintainability. We have some home grown programs developed by two of us 
as a team. We each can support our own part, but no one else knows how to 
fix it. Yet we have many people who can change sort parameters.

Twice now I have a job go down because a software upgrade changed the 
column layout. It took a change to a column start parameter in Sort to get 
the data from the new column. The change to the Sort cards was much faster 
to push back through channels into production than a program change would 
have been. The sort cards were much fewer lines than a program would have 
been. Plus Sort is likely more efficient for our large files than I would 
do in my own program.

We use canned programs as much as posible and write our own when it looks 
like it makes sense. It all depends on the situation.

Thank you and have a Terrific day!

Jonathan Goossen, ACG, CL
Tape Specialist
ACT Mainframe Storage Group
Personal: 651-361-4541
Department Support Line: 651-361-
For help with communication and leadership skills checkout Woodwinds 
Toastmasters



IBM Mainframe Discussion List  wrote on 11/21/2011 
04:36:49 PM:

> From: "Farley, Peter x23353" 
> To: IBM-MAIN@bama.ua.edu
> Date: 11/21/2011 04:42 PM
> Subject: Re: Simple record extraction from a sequential file
> Sent by: IBM Mainframe Discussion List 
> 
> John,
> 
> I am not the OP, but I can imagine one very good reason -- 
> Production control procedures.
> 
> If the file that the OP is trying to extract is a production file 
> and the resulting file also has to feed another production program, 
> then a new program has to pass through all of the system development
> lifecycle processes, which can be quite bureaucratic in a large 
organization.
> 
> However, sort control cards for a production JCL sort job *may* 
> (depending on the organization) more easily and quickly pass through
> such procedures, sometimes with much less process and paperwork.
> 
> Besides that, sort is EVER so much more efficient at doing I/O 
> (especially to or from non-VSAM files) than any user-written HLL 
> program.  Sort is often my first choice on that basis alone 
> (assuming the selection and/or processing logic can be accommodated 
> with existing sort control verbs).
> 
> Just a couple of thoughts for your consideration.
> 
> Peter


This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[John Gilmore]

I have now read Donald Russell's riposte, and I find it persuasive in
the business context he describes.

A discussion of the radical deficiencies of this context would be
inappropriate here.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Ford Prefect]

John,

I think you'd be hard pressed to write a program in either C or PL/I that
would even approach the I/O performance of DFSORT.  In fact, I doubt it's
possible.

On Mon, Nov 21, 2011 at 6:13 PM, John Gilmore wrote:

> I am not at all hostile to DFSORT, which I now prefer slightly to
> SYNCHSORT.
>
> I am, however, hostile to the notion that I/O in a statement-level
> language is always inferior to that of DFSORT.  Here both of my young
> programmers used a locate-mode READ-SET for the input records,
> examined each in its buffer, and an effectively asynchronous move-mode
> WRITE-TO a LOCATEd position in an output buffer for the selected
> records.  Their JCL included appropriate BUFNO=, etc.
> (Interestingly, something very similar could be but in fact is almost
> never done in COBOL with a reusable C or PL/I driver.)
>
> I am of course familiar with production-control schemes.  Production
> must be orderly, but in my experience bureaucratic controls alone do
> not reduce errors: They only diffuse responsibility.
>
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[John Gilmore]

I am not at all hostile to DFSORT, which I now prefer slightly to SYNCHSORT.

I am, however, hostile to the notion that I/O in a statement-level
language is always inferior to that of DFSORT.  Here both of my young
programmers used a locate-mode READ-SET for the input records,
examined each in its buffer, and an effectively asynchronous move-mode
WRITE-TO a LOCATEd position in an output buffer for the selected
records.  Their JCL included appropriate BUFNO=, etc.
(Interestingly, something very similar could be but in fact is almost
never done in COBOL with a reusable C or PL/I driver.)

I am of course familiar with production-control schemes.  Production
must be orderly, but in my experience bureaucratic controls alone do
not reduce errors: They only diffuse responsibility.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Frank Yaeger]

Donald Russell on IBM Mainframe Discussion List 
wrote on 11/21/2011 02:43:10 PM:
> > The use of the SORT to do this job seems to me to be much akin to
> > using a piledriver to set a ten-penny nail., and I should be
> > interested to know why you sought a canned solution to a problem of
> > this sort.
> >
>
> Though clearly the programming effort to write my own code to do this is
> trivial, the reason for wanting a "canned solution" is to avoid all the
> "business rules and procedures" associated with writing "custom code".
>
> If I roll my own, it has to go through the whole QA process, and
> distributed to various geographically diverse MVS systems where I need
this
> capability.  DFSORT is available right now. It's been debugged, it's been
> accepted, it's in production, now.
>
> If DFSORT can do what I need, that's perfect. The cycles to run DFSORT
for
> this are less expensive than my and other people's time to properly
support
> it.
>
> If there's another "out-of-the-box" solution, I'm all ears. i.e. my
cms/tso
> pipelines solution suggested in my original post. (But I'm note sure we
> have PIPELINES on all our MVS systems.)
>
> I'm also a big believer in using existing wheels. Why do I want to write
a
> program that already does what another, already available one does?
>
> The reason I need this capability is so I can extract a subset of records
> from one or more tapes in various geographically diverse MVS sites, send
> that data to another MVS site that has USS and do some stuff with it
there.
> I could just copy the entire tape across the country/globe, but I do have
> some limits regarding wasted bandwidth/cycles. :-)
>
> It's a trade-off/balancing act.

I'm glad to hear that devoting most of my career at IBM to adding more and
more functions to DFSORT and DFSORT's ICETOOL hasn't been a waste of
time. :-)

It's nice to know I can't be completely replaced by a couple of teenagers
writing PL/I code.

The "use a utility" vs "roll your own" argument seems to come up every now
and
then.  Besides the QA process considerations and efficiency considerations,
it
often comes down to a "how complex does something have to be before you
stop
rolling your own" decision.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Donald Russell]

On Mon, Nov 21, 2011 at 14:02, John Gilmore wrote:

>
>
> The use of the SORT to do this job seems to me to be much akin to
> using a piledriver to set a ten-penny nail., and I should be
> interested to know why you sought a canned solution to a problem of
> this sort.
>

Though clearly the programming effort to write my own code to do this is
trivial, the reason for wanting a "canned solution" is to avoid all the
"business rules and procedures" associated with writing "custom code".

If I roll my own, it has to go through the whole QA process, and
distributed to various geographically diverse MVS systems where I need this
capability.  DFSORT is available right now. It's been debugged, it's been
accepted, it's in production, now.

If DFSORT can do what I need, that's perfect. The cycles to run DFSORT for
this are less expensive than my and other people's time to properly support
it.

If there's another "out-of-the-box" solution, I'm all ears. i.e. my cms/tso
pipelines solution suggested in my original post. (But I'm note sure we
have PIPELINES on all our MVS systems.)

I'm also a big believer in using existing wheels. Why do I want to write a
program that already does what another, already available one does?

The reason I need this capability is so I can extract a subset of records
from one or more tapes in various geographically diverse MVS sites, send
that data to another MVS site that has USS and do some stuff with it there.
I could just copy the entire tape across the country/globe, but I do have
some limits regarding wasted bandwidth/cycles. :-)

It's a trade-off/balancing act.

Cheers

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Farley, Peter x23353]

John,

I am not the OP, but I can imagine one very good reason -- Production control 
procedures.

If the file that the OP is trying to extract is a production file and the 
resulting file also has to feed another production program, then a new program 
has to pass through all of the system development lifecycle processes, which 
can be quite bureaucratic in a large organization.

However, sort control cards for a production JCL sort job *may* (depending on 
the organization) more easily and quickly pass through such procedures, 
sometimes with much less process and paperwork.

Besides that, sort is EVER so much more efficient at doing I/O (especially to 
or from non-VSAM files) than any user-written HLL program.  Sort is often my 
first choice on that basis alone (assuming the selection and/or processing 
logic can be accommodated with existing sort control verbs).

Just a couple of thoughts for your consideration.

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John Gilmore
> Sent: Monday, November 21, 2011 5:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Simple record extraction from a sequential file
> 
> You have a response that apparently meets your needs.
> 
> Your question interests me for another reason.  I asked two admittedly
> very bright 15 year olds to write a  parameterized--a value V, a field
> of length L, and a one-origin offset O of its first byte--PL/I
> procedure to do what you want to do.
> 
> It took them 10 and 13 minutes, respectively, to come up with correct,
> working procedures complete with bullet proofing and test cases.
> 
> The use of the SORT to do this job seems to me to be much akin to
> using a piledriver to set a ten-penny nail., and I should be
> interested to know why you sought a canned solution to a problem of
> this sort.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Steve Comstock]

On 11/21/2011 3:02 PM, John Gilmore wrote:

You have a response that apparently meets your needs.

Your question interests me for another reason.  I asked two admittedly
very bright 15 year olds to write a  parameterized--a value V, a field
of length L, and a one-origin offset O of its first byte--PL/I
procedure to do what you want to do.

It took them 10 and 13 minutes, respectively, to come up with correct,
working procedures complete with bullet proofing and test cases.

The use of the SORT to do this job seems to me to be much akin to
using a piledriver to set a ten-penny nail., and I should be
interested to know why you sought a canned solution to a problem of
this sort.

John Gilmore, Ashland, MA 01721 - USA


John,

It's the wave of the future. Actually, the wave of the present:
if I create it myself I will have to think. If I can take a
canned solution, the bulk of the thinking is done for me.

How many times have you seen people on this list say, proudly
even, "I'm lazy so ... ".

From a more practical standpoint: it's efficient to use existing
art. (Not counting the time it takes to find the existing art,
such as querying on ibm-main.)

The whole mantra of "code reuse" has always struck me as sort of
disengenuous. Java is not the only language that can create
methods that can be used by many other programs. Think subroutines.

But in large shops I have seen the number of subroutines be so
overwhelming that it's often easier to roll your own. So now
we get a proliferation of subroutines (or methods) available but
no one knows how to find them or use them (except for, perhaps,
the most frequently used 10%).

So it goes.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Frank Yaeger]

Rick Fochtman on IBM Mainframe Discussion List  wrote
on 11/21/2011 01:38:29 PM:
>
> Take a look at DFSORT, using INCLUDE/EXCLUDE control statements
>

For the record, that's INCLUDE/OMIT, not INCLUDE/EXCLUDE.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[John Gilmore]

You have a response that apparently meets your needs.

Your question interests me for another reason.  I asked two admittedly
very bright 15 year olds to write a  parameterized--a value V, a field
of length L, and a one-origin offset O of its first byte--PL/I
procedure to do what you want to do.

It took them 10 and 13 minutes, respectively, to come up with correct,
working procedures complete with bullet proofing and test cases.

The use of the SORT to do this job seems to me to be much akin to
using a piledriver to set a ten-penny nail., and I should be
interested to know why you sought a canned solution to a problem of
this sort.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Rick Fochtman]

---


I have a tape dataset from which I need to extract all records that begin
with a specific 2 byte prefix. The RECFM is VB or possibly U.

Is there an IBM utility that lets me just select those given records?

I thought IEBEDIT sounded like a good candidate, but that seems to deal
with actual job streams then I thought of IEBGENR, but that doesn't
appear to do what I want either.

Surely I'm missing something, I'd think this is a very common task.

For example, CMS/TSO PIPELINES
PIPE < input | STRFIND /xx/ | > output
 


-
Take a look at DFSORT, using INCLUDE/EXCLUDE control statements

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Donald Russell]

On Mon, Nov 21, 2011 at 10:31, Frank Yaeger  wrote:

> Donald Russell on IBM Mainframe Discussion List 
> wrote on 11/21/2011 10:16:26 AM:
> > I have a tape dataset from which I need to extract all records that begin
> > with a specific 2 byte prefix. The RECFM is VB or possibly U.
> >
> > Is there an IBM utility that lets me just select those given records?
> >
> > I thought IEBEDIT sounded like a good candidate, but that seems to deal
> > with actual job streams then I thought of IEBGENR, but that doesn't
> > appear to do what I want either.
> >
> > Surely I'm missing something, I'd think this is a very common task.
> >
> > For example, CMS/TSO PIPELINES
> > PIPE < input | STRFIND /xx/ | > output
>
> If you want to select VB records that have XX in positions 5-6 (after the
> RDW in positions 1-4), you can use a DFSORT job like the following:
>
> //S1 EXEC PGM=SORT
> //SYSOUT DD SYSOUT=*
> //SORTIN DD DSN=...  input tape file (VB)
> //SORTOUT DD DSN=...  output file (VB)
> //SYSIN DD *
>  OPTION COPY
>  INCLUDE COND=(5,2,CH,EQ,C'XX')
> /*
>
> However, DFSORT cannot process RECFM=U data sets.
>



Thanks... That's perfect...

Cheers,

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Ulrich Krueger]

Donald,
Think simple ... think SORT (IBM's SORT or any vendor's SORT)...


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Donald Russell
Sent: Monday, November 21, 2011 10:16 AM
To: IBM-MAIN@bama.ua.edu
Subject: Simple record extraction from a sequential file

I have a tape dataset from which I need to extract all records that begin
with a specific 2 byte prefix. The RECFM is VB or possibly U.

Is there an IBM utility that lets me just select those given records?

I thought IEBEDIT sounded like a good candidate, but that seems to deal
with actual job streams then I thought of IEBGENR, but that doesn't
appear to do what I want either.

Surely I'm missing something, I'd think this is a very common task.

For example, CMS/TSO PIPELINES
PIPE < input | STRFIND /xx/ | > output

Thank you,

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Simple record extraction from a sequential file

[Frank Yaeger]

Donald Russell on IBM Mainframe Discussion List 
wrote on 11/21/2011 10:16:26 AM:
> I have a tape dataset from which I need to extract all records that begin
> with a specific 2 byte prefix. The RECFM is VB or possibly U.
>
> Is there an IBM utility that lets me just select those given records?
>
> I thought IEBEDIT sounded like a good candidate, but that seems to deal
> with actual job streams then I thought of IEBGENR, but that doesn't
> appear to do what I want either.
>
> Surely I'm missing something, I'd think this is a very common task.
>
> For example, CMS/TSO PIPELINES
> PIPE < input | STRFIND /xx/ | > output

If you want to select VB records that have XX in positions 5-6 (after the
RDW in positions 1-4), you can use a DFSORT job like the following:

//S1 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=...  input tape file (VB)
//SORTOUT DD DSN=...  output file (VB)
//SYSIN DD *
  OPTION COPY
  INCLUDE COND=(5,2,CH,EQ,C'XX')
/*

However, DFSORT cannot process RECFM=U data sets.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html