W dniu 2010-07-07 18:41, Clark Morris pisze:
On 7 Jul 2010 07:48:56 -0700, in bit.listserv.ibm-main you wrote:
--------------------------------------<snip>-------------------------------------
Ted,
Well, I don't know what else to say Ted. These are real world examples that
provided significant IO and IO Time reduction for Banking and Credit Card
applications. I did not say "I recommend" these techniques, I said I have
"used" these techniques for over 10 years (with the stress on used).
I guess Banking Applications must be really unique in Canada, because this
method worked for Banking and Credit Card applications for over 20
countries.
I've worked for Banks for most of my working life, 20 years out of 32, if
that provides any weight to my experience. There was life before HDS...
Ron
-----------------------------------<unsnip>-------------------------------------
I've worked for manufacturing, trade associations and financial firms
and in each case I've known read/write ratios of about 4 reads to every
1 write.
In my experience, with ARCHIVER, the compression/compaction of the data,
while CPU intensive, has provided a considerable advantage in I/O
reduction. My problem, which led to my initial posting, is that
sometimes I get a long load-module record that expands rather than
shrinks when I try to compress it.
I may be in real trouble when 64K DASD records show up. :-)
What is interesting is that on the squatty boxes, single records can
be multiple megabytes in size (a 22 megapixel RAW photo for extreme
example) and we still worry about a 64K barrier. Even JPEGs can be
over a megabyte and pictures in catalogs probably can be well over
64K. Even if most of this sort of thing is in Unix files or in
databases, it would seem the rest of the systems need to be able to
handle much larger logical entities.
Yes and no.
You can store your photos in USS files. In PC world - FROM OS POINT OF
VIEW all files are unstructured. Just sequence of bytes. No records, no
access methods. Obviously the applications uses its own formats, most of
them are proprietary (DOC, XLS, PPT), some of them are common (DBF, JPG,
CSV, RTF). So - the PC world has those unstructured files ONLY, while we
have such files AND datasets.
The problem appears when one wants to use datasets and
"dataset-oriented" utilities to store binary data. But it's still
possible: just store your JPEG's or movies in PS U datasets or PO U ones
(I mean DSORG=PS/PO, RECFM=U - no records). Many windows programs
related to z/OS are delivered in datasets - HCM, OSA/SF, RMF PR to name
a few.
STK's http server even stored icons in members of PDS.
What's really disturbs us is:
a) naming convention - obvious
b) lack of tools. Yes, you can keep your photos in PS files, but how
would you want to browse them? There is no "quick view" option in PDF, I
haven't heard about Qick Time for z/OS. <g>
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym
BRE Banku SA bd w caoci opacone.
----------------------------------------------------------------------
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
