W dniu 2010-07-31 00:30, Paul Gilmartin pisze:
On Tue, 20 Jul 2010 08:01:09 -0700, Edward Jaffe wrote:

I've seen other "old" programs with many hard-coded offsets and lengths
and always wondered why this was such common practice back then.

Was it because there were a lot of inexperienced assembler programmers
writing code? Was it because people thought the platform would not last
and treated every program as a "throw away"? Was it due to limitations
in the assembler itself?

But this reminds me of the current struggle to extend DASD
volume sizes beyond 54GB, largely because IBM apparently at
the introduction of the 3390 made a committment to support
forever programmers with the unconscionable habit of hard-
coding device geometry parameters rather than fetching them
dynamically from system services.  If no programmers had
hard-coded 15 tracks per cylinder, IBM could easily have
supported HH values up to 65535.  It's all virtual, anyway,
nowadays.

Agreed. However times are a changing. It's been looong time since integrated drive electronics virtualized cylinders, tracks and heads. It's been looong time since number of bytes on tracks isn't constant. LBA mode of addressing is the only reasonable nowadays, especially when consider SSDs. If we (IBM) decide for some incompatibility then maybe it's better to make bigger step and forget about CKD? IMHO that's better than changing CKD limits.


Joel C. Ewing wrote:
> Figuring out what TRK and CYL allocations would need to be
> changed, and how, to accomodate a change in device geometry would be a
> non trivial exercise.
IMHO it's quite trivial (but time consuming). However it would be much more trivial to leave the values unchanged! Let the TRK and CYL *values* remain unchanged, let's make their physical definition meaningless. In my JCL job I specify 1000 CYL just to describe amount of space, approx. 850MB. I don't care how many physical tracks or cylinders are taken, not to mention everything is emulated. I need some space on disk, that's all. Wouldn't it be nice, to allocated 1000 CYL dataset on USB stick attached to mainframe? <g>
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237
NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

----------------------------------------------------------------------
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

Reply via email to