I have just posted to ColeSoft's website a new version of my DSCOPY
program. The link is www.colesoft.com/Downloads/downloads_utilities.html.
DSCOPY and everything else that you find on that page is free.
DSCOPY is a generalized sequential file copying program. It features
include the following:
1.) DSCOPY can perform any number of separate copies in one jobstep.
2.) Input datasets may be sequential, direct, or individual members
of partitioned data sets, or a concatenation of any combination of
the above with any combination of DCB attributes (RECFM, LRECL, and BLKSIZE).
3.) Unlike-concatenations of input files are fully supported. Any
input file may be a concatenation of any supported datasets having
any combination of DCB attributes.
4.) Any record format is allowed (fixed, variable, undefined) for
input, and it may be changed to any other record format for output.
In addition, logical record lengths and/or block sizes may also be
changed. All such changes are automatically accommodated for.
5.) All information needed is specified through JCL or through the
PARM field. No control dataset (SYSIN, for example) is needed.
6.) Optionally, all 1st-quadrant bytes codes can be changed to
periods or blanks.
7.) Optionally, a large number of date related built-in symbols are
supported that can be replaced by either UTC-time related or
local-time related date/time values.
8.) DSCOPY contains basic support for copying only a portion of a dataset.
(Sam, if you're here, could you do me a favor? If DSCOPY is still on
the CBT mods tape, could you take it off and replace it with the
above hyperlink? Thanks.)
I need a short break from the code this afternoon, so I'm going to
indulge myself with a brief walk down memory lane. The more
here-and-now guys among you might want to stop reading at this point.
For the rest ...
I have been using DSCOPY for almost exactly 40 years now! I wrote the
first version in 1969. I had just changed jobs. I had been working
for the University of Pennsylvania's Computer Center (UPCC), and was
beginning a new job for one of their commercial customers in downtown
Philadelphia.
UPCC was running MFT with HASP (JES2's predecessor), and the SYSPROGs
there had written an RYO charge-back system that was completely
implemented as locally written mods to HASP. (HASP was a perfect
place to measure CPU seconds, I/O bytes, cards read/punched and lines
printed because it had intercepts all over the system, including in
the various interrupt new PSWs.)
Anyway, while working at UPCC, I discovered that their charge back
system had an interesting flaw: It did not begin to accumulate
accounting stats for any job until that job did it's first read/write
from/to a card reader, card punch or line printer (spool, actually). So...
If you could put all your "sysin" into files and write all your
"sysprint" out to temporary files, and then have a single, final
jobstep that would write all of those files, regardless of DCB
attributes, to the printer, then you could save a boatload of money!
(Real money, in the case of a commercial customer ...)
So I wrote DSCOPY... Needless to say, it did not take UPCC long to
find/fix their bug.
DSCOPY was one of my earliest Assembler programs. I had just begun to
learn Assembler only a year or two before. (I was a FORTRAN
programmer before that.) When I wrote DSCOPY, there were two things I
wanted to achieve. One was to be able to copy any number of
sequential files having any arbitrary DCB attributes, and to
transform those attributes in any way reasonable and as needed by the
output files/devices. So I learned a lot about DCB OPEN exits.
The other was to make it blindingly fast! At the time, pretty much
the only sequential copying program available from IBM was IEBGENER,
and it was abysmally slow! The way it did I/O basically led it to
read/write exactly one physical block per revolution of the DASD
device. If the file happened to be unblocked then oh my gawd!
So in the process of trying to make DSCOPY fast, I had to learn about
such things as DCBs, DEBs, IOBs, PCI CCW programming, chained
scheduling and track capacity calculations. (A 2314, for example,
held forty 80-byte blocks per track.) I still wound up just using
QSAM, but I did it right. I used PUT-LOCATE mode buffering, I used
OPTCD=C, and I used NCP=nnn where nnn was (where possible) the exact
number of blocks that could fit on a track. So DSCOPY would usually
be able to read/write an entire track's worth of data on a single rotation.
Nowadays, DSCOPY is still fast, but so is everyone else, so speed no
longer is its advantage. But IMO it's still awful damned useful! Feel
free to take it, try it, and use it. Let me know how it goes ...
Dave Cole REPLY TO: [email protected]
ColeSoft WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
