Re: What Makes an Architecture Bizarre?

[Dan Espen]

jmfbahciv <See....@aol.com> writes:

> Dan Espen wrote:
>> jmfbahciv <See....@aol.com> writes:
>>
>>> Shmuel (Seymour J.) Metz wrote:
>>>> In <PM0004D76...@ac817560.ipt.aol.com>, on 03/08/2013
>>>> at 01:59 PM, jmfbahciv <See....@aol.com> said:
>>>>
>>>>>COBOL didn't require the expertise of systems programmers (old
>>>>>defintion). All other lanugages did,
>>>>
>>>> ROTF,LMAO! That's the dumbest thing I've read yet.
>>>>
>>> Then you're too young to know how things worked back then.
>>
>> Shmuel young?
>>
>> Pretty sure he's a cranky old codger just like you.
>>
>> Well, actually, with this apparent 70xx experience
>> I'm guessing he knows a whole lot more about "back then"
>> than you ever dreamed of.
>
> Now read what I wrote.

You didn't write "Then you're too young"?

> He didn't notice how other
> people did their work. I suspect you don't notice
> either.

If "didn't notice" means disagrees with you, yeah, then we
"didn't notice".

--
Dan Espen

[Anne & Lynn Wheeler]

Robert Wessel <robert...@yahoo.com> writes:
> The larger and faster 3330 disk shipped in about 1973. But assuming
> we're talking about before that, and assuming we're talking about
> early 370s or 360s, you were limited to no more than five selector or
> block multiplexor channels, each of which would address no more than
> 256 devices. Later models allowed 16* channels, and then channel set
> switching allowed several sets of 16 channels, and then XA made it 256
> channels, and now we can have multiple groups of 256 channels!

re:
http://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?

minor issue, 3330-II was twice the capacity ... i.e. twice as many
cylinders (808 cyls rather than 404 cyls). in my old tome about disks
relative system throughput decreasing (disks got less faster than the
rest of the system) ... one of the calculations was nominal
avg. no. accesses per second prorated by amount of data under an arm
... aka avg. no. accesses per second per mbyte.
http://www.garlic.com/~lynn/93.html#21 Too much data on an actuator (was: 3.5 inch *9GB* )
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/2003b.html#67 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#68 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006l.html#10 virtual memory
http://www.garlic.com/~lynn/2008e.html#60 z10 presentation on 26 Feb
http://www.garlic.com/~lynn/2008k.html#75 Disk drive improvements
http://www.garlic.com/~lynn/2009l.html#66 ACP, One of the Oldest Open Source Apps

as mentioned here current ("FICON") channels are an extremely
heavyweight protocol that rides on top of fiber-channel standard
that enormously cuts the native FCS throughput
http://www.garlic.com/~lynn/2013c.html#62 What Makes an Architecture Bizarre?
http://www.garlic.com/~lynn/2013c.html#63 What Makes an Architecture Bizarre?
http://www.garlic.com/~lynn/2013c.html#67 relative speeds, was What Makes an Architecture Bizarre?
http://www.garlic.com/~lynn/2013c.html#68 relative mainframe speeds, was What Makes an Architecture Bizarre?

internally ... one of the things we looked at in the transition from
3350 to 3380 ... if you replaced 3350s with 3380 having the same amount
of disk space ... there were fewer arms and worse throughput. to have
the same amount of throughput as 3350s, 3380s had to be configured at
80% of capacity.

at share user group meeting there was semi-facetious resolution asking
IBM for a "fast" 3380. It was a controller microcode load that only
allowed access to half the number of cylinders ... avg. access goes up
because only half the distance to travel. the suggestion was that ibm
could charge extra for the "fast" 3380 ... it was countermeasure to
datacenter administrators who saw it as false economy to not load a disk
to full capacity (this would be an ibm model that was limited to half
the capacity and would let datacenter adminstrator feel better by
charging them more money for the feature).

normal 360 two/multi-processor had shared memory but required
independent i/o channels. symmetric i/o operations were simulated by
configuring the two sets of independent channels with similar addresses
connected to "twin-tailed" controllers.

hover, while simplex 360/67 was essentially 360/65 with added
relocatable address hardware ... 360/67 multiprocessor (originally
designed to support 4-way ... but mostly 2-way were built except for
possibly one or two 3-ways) ... was a different beast. It had channel
controller allowing all processors to address all channels (something
not seen again to 3081/XA).

I've mentioned pereiodically that after failure of FS
http://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get (hardware & software) products back into 370
pipeline ... basically 303x effort was kicked off in parallel with
3081/xa efforts.

for 303x i/o, they took the integrated channel microcode from the 158
and made it into a channel director (six channels). a 3031 was a 370/158
engine with only the 370 microcode and a second 370/158 engine ("channel
director") with only the integrated channel microcode (and no 370
microcode). A 2-way 3031 multiprocessor was actually four 370/158
engines (two 370 processor engines, each having its own channel
director).

a 3032 was 370/168-3 configured to work with channel director.

a 3033 started out 168 logic mapped to 20% faster chips (chips also had
10 times the number of circuits by 90% initially went unused). Some
late optimization of logic got 3033 (using more circuits/chip) up to
1.5times 168. 3033 could have three channel directors (theoritically 18
channels, but only 16 could be used).

of the 148, 4341, 158, 168, etc ... the 158 channels were the slowest of
the bunch ... this shows up in some extensive tests that I had done
regarding how fast different processor channels could do 3330 head
switch
http://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What Makes an Architecture Bizarre?

158 was absolutely the slowest and the worst of the bunch ... which is
repeated for all models of 303x using 158 integrated channel microcode
for their channel directors.

for other drift old post discussing cutting inter-track gap on 3380 for
double & triple density models (original 3380, the inter-track gap was
20 track widths):
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?
http://www.garlic.com/~lynn/2009e.html#41 "A foolish consistancy" or "3390 cyl/track architecture"
http://www.garlic.com/~lynn/2010k.html#17 Documenting the underlying FBA design of 3375, 3380 and 3390?
http://www.garlic.com/~lynn/2011.html#57 Speed of Old Hard Disks
http://www.garlic.com/~lynn/2011.html#60 Speed of Old Hard Disks
http://www.garlic.com/~lynn/2011.html#69 Speed of Old Hard Disks
http://www.garlic.com/~lynn/2011j.html#47 Graph of total world disk space over time?
http://www.garlic.com/~lynn/2012o.html#58 ISO documentation of IBM 3375, 3380 and 3390 track format
http://www.garlic.com/~lynn/2012o.html#60 ISO documentation of IBM 3375, 3380 and 3390 track format

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

[Scott Lurndal]

nm...@cam.ac.uk writes:
>In article <proto-A199B2....@news.panix.com>,
>Walter Bushell <pr...@panix.com> wrote:
>>In article <1219.850T1...@kltpzyxm.invalid>,
>> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>>
>>> More often than you'd think. Try calculating a tax (which some
>>> government bean-counter has specified to 5 significant digits)
>>> on a billion dollars or so (12 digits when you include pennies).
>>
>>'If it happens one time in a million, it happens a dozen times a day
>>around here.' who said or somewhat close.
>
>That all? Try the HPC area. I teach the kiddies that a data race
>that happens one time in 10^12 is likely to lead to an unusable
>MTBF, and that even one that happens one time in 10^18 could do.
>That's scary, because x86 designs show a variation from sequential
>consistency of one time in 10^5 in a tight assembler loop.

That is likely due to SMM[*], something that is both hated and loved.

[*] System Management Mode, a special processor state that can be
entered by the hardware for certain reasons (an SMI - System
Maintenance Interrupt); when entered, all processors in the
system go into SMM mode. All this is completely invisible to
the operating system (being implemented as part of the BIOS
firmware).

http://en.wikipedia.org/wiki/System_Management_Mode

[Scott Lurndal]

Peter Flass <Peter...@Yahoo.com> writes:
>On 3/8/2013 2:40 PM, Scott Lurndal wrote:
>> Peter Flass <Peter...@Yahoo.com> writes:
>>> On 3/8/2013 12:36 PM, Scott Lurndal wrote:
>>>> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>>>>> In <gg3_s.29951$na6....@fed15.iad>, on 03/07/2013
>>>>> at 04:30 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>>>>
>>>>>> Burroughs medium systems used a special card as eof,
>>>>>
>>>>> EOF for the reader or just end-of-job?
>>>>>
>>>>
>>>> EOF for the reader; more precisely, EOF for the file in a program that was
>>>> attached to the reader (user app or LDCTRL). The OS would then
>>>> read the next card (if present) and if not a control record (1-2-3 punch
>>>> in column 1) would display an operator error and logically off-line the
>>>> reader until the operator issued a RY CC/UU command.
>>>>
>>>> The problem with EOF on card readers is that the absence of a card
>>>> in the reader cannot be considered EOF. Using a special card
>>>> to indicate EOF gives great flexibility and reduces the chance of
>>>> the operator forgetting to press the EOF button after a large deck
>>>> has been read.
>>>>
>>>
>>>
>>> Throw in a few '//' cards after.
>>
>> on the burroughs system a '//' card had no intrinsic meaning. JCL had no meaning.
>>
>
>Okay, so you toss in a few 1-2-3EOF cards...

That what I orignially wrote, but Shmuel snipped the ?END and ?ENDCTL card descriptions.

[Scott Lurndal]

John Levine <jo...@iecc.com> writes:
>>>> Assuming you had long relative branches, just let the linker or
>>>> loader fix them up.
>>>
>>> That would preclude dynamic linking, as existed in Multics and
>>> TSS/360.
>>
>>The point of relative branches is that they don't require fixups.
>
>They allow position independent code, where the whole module moves
>together. You still need a fixup when they link to other routines
>that can be at arbitrary places.
>
>Modern (since the late 1980s) Unix systems finesse this with a
>procedure linkage table in each module. For each outgoing reference,
>there's an entry in the PLT which is basically an indirect jump
>through a table in the data segment. Calls or jumps in the rest of
>the code make a relative branch to the PLT, which then jumps to the
>actual remote address. This lets them put all the fixups in one place
>and keep the code segments unpatched.

The first time a particular PLT entry is branched to, the PLT entry
will branch to the code which resolves the symbol then updates the
PLT entry to point to the resolved symbol (lazy binding). An optional
environment variable (or dlopen flag) can be used to force the binding when the shared
object is loaded (so you don't get an unresolved symbol potentially long
after the module is loaded).

For global data, the GOT (Global Offset Table) performs similar relocations.

scott

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?

http://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What Makes an Architecture Bizarre?

http://www.garlic.com/~lynn/2013c.html#77 relative mainframe speeds, was What Makes an Architecture Bizarre?

some other random disk refs:
http://forums.legitreviews.com/about16883.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html
http://www.staff.ncl.ac.uk/roger.broughton/museum/DASD/200427.htm

[Scott Lurndal]

jmfbahciv <See....@aol.com> writes:
>Scott Lurndal wrote:
>> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>>>In <gg3_s.29951$na6....@fed15.iad>, on 03/07/2013
>>> at 04:30 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>>
>>>>Burroughs medium systems used a special card as eof,
>>>
>>>EOF for the reader or just end-of-job?
>>>
>>
>> EOF for the reader; more precisely, EOF for the file in a program that was
>> attached to the reader (user app or LDCTRL). The OS would then
>> read the next card (if present) and if not a control record (1-2-3 punch
>> in column 1) would display an operator error and logically off-line the
>> reader until the operator issued a RY CC/UU command.
>>
>> The problem with EOF on card readers is that the absence of a card
>> in the reader cannot be considered EOF. Using a special card
>> to indicate EOF gives great flexibility and reduces the chance of
>> the operator forgetting to press the EOF button after a large deck
>> has been read.
>

>You could run a job which had more than one set of card decks. EOF
>didn't mean butkis on a 1620. You had a program deck, data deck,
>and maybe other stuff like a format deck. If the code used
>a compiler the program was preceded by the compiler's set of decks.

What is your point?

?CMP ABC WITH COBOL9 LIB MEM + 100.
?FILE CARD
IDENTIFICATION DIVISION.
AUTHOR. FRED JONES.
...
STOP RUN.
END.
?END <--------- Signals EOF on file "CARD" in the compiler
?EX ABC
?FILE SHORT/OUTPUT PBK
?FILE INPUT
DATA RECORD 1
DATA RECORD 2
DATA RECORD 3
?END <---------- Signals EOF for file INPUT of the compiled program ABC


This deck would be stacked in the reader. If it was larger than the reader
input hopper, it could be split anywhere.

[Scott Lurndal]

jmfbahciv <See....@aol.com> writes:
>Scott Lurndal wrote:

>>

>> All one needs to do is ensure that monetary values are representated
>> as an integral in the smallest part (i.e. the penny)
>
>Wrong. The stock market goes to 4 decimal points; you would be very
>upset if your reinvestments of dividends was to the penny.

I said smallest part, then gave penny as _AN EXAMPLE_. If millicent is
the smallest part, then use millicents.

>
>
>> then integer arithmetic is
>> sufficient.
>
>that just means that the program has to "remember" where the decimal point
>it. I certainly would rather fix a COBOL program than a C program
>which need to report interest earned when the rate is .01%.

How many C programs have you written?

scott

[Scott Lurndal]

jmfbahciv <See....@aol.com> writes:

I have
>brokerage statements which couldn't add nor round correctly.

That would be highly unusual and a violation of various securities
rules.

scott

[Scott Lurndal]

jmfbahciv <See....@aol.com> writes:
>Stephen Sprunk wrote:
>> On 08-Mar-13 09:50, hanc...@bbs.cpcn.com wrote:
>>> On Mar 7, 11:20 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>>>> On 07-Mar-13 15:23, hanco...@bbs.cpcn.com wrote:
>>>>> If so, how efficient are PERL executables on an IBM mainframe?*
>>>>> That is, say a program had to read a sequential file of 1,000,000
>>>>> records each being 512 bytes long, perform various tests and
>>>>> calculations on the fields** within each record, and generate
>>>>> several reports for those records that meet selection criteria.
>>>>> How long would the executable run as compared to a COBOL program
>>>>> doing the same thing?
>>>>
>>>> It would take about the same amount of time. Any overhead due to
>>>> being an interpreted language would just consume the time the CPU
>>>> spends waiting for the I/O system (or even RAM) to feed it data.
>>>
>>> Mainframe CPUs very often do not spend time "waiting". The systems
>>> were designed to run multiple tasks simultaneously. While the CPU
>>> is waiting on I/O on one job, it switches to serve the needs of
>>> another job.
>>
>> ... just like any other modern machine. Aside from exceptional cases
>> like video codecs, the CPU will spend the majority of its time stalled,
>> waiting for the rest of the system to catch up. We simply don't have
>> the technology to feed them data fast enough to stay busy. Even RAM is
>> ridiculously slow compared to modern CPUs.
>
>then make the hardware symmetric.

Grandmother. Eggs. Suck.

So, a typical processor can execute an instruction in 333 picoseconds[*]. The
fastest DRAM takes 60ns to fetch a "cache line" (64 bytes, typically); it is
more likely that the average DRAM access is on a multisocket system is closer
to 200ns.

If you've invented DRAM that can cycle in less than a nanosecond, go for it!

The processors use a small amount (relatively) of high-speed SRAM on-die to accelerate
memory accesses by the processor (see 'cache'). And that's sized to help
"feed them data enough to stay busy".

scott

[*] Well, 3 instructions in a nanosecond at 1 IPC, and some processors can do
more IPC (Instruction per cycle).

[Scott Lurndal]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

>In <F0s_s.728029$W71.2...@fed07.iad>, on 03/08/2013
> at 08:40 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>
>>Perhaps on IBM mainframes, but not on burroughs mainframes. Binary
>>subscripts wouldn't work at all since memory addresses (pointers) are
>>also BCD.
>
>That is only true of a dead line; the surviving line of Burroughs
>computers uses binary addressing.
>
>BTW, how many B2500 derivatives were shipped compared to other lines,
>e.g. 490, 1700, 5000, 6500?

Haven't heard of the 490. Are you refering to the electrodata 205 derivatives?

More medium systems were shipped than the 1700/1800/1900's.

I only have the numbers up through the 4700

1198 B[23]500 (total).
~1150 B[234]700 (as of 1976).

I don't have numbers for the B[234]800, B[234]900 or V-Series
systems, but I suspect they're in the same ballpark.

http://vseries.lurndal.org/

There were more large systems shipped, I believe.

scott

[Scott Lurndal]

Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
>Michael S wrote:
>> For the sake of the argument.
>> Even on my fast IvyB with my latest and greatest binary64_to_bcd
>> routines that implements Terje's finest ideas in 128b SIMD form, I can
>> not saturate 10GBE with the packed BCD results. With unpacked (ASCII)
>> results, on the other hand, I probably can.
>
>Probably not:
>
>Your IvyB almost certainly cannot saturate a 10 Gbit/s link: Depending
>upon OS type & overhead you might get to 60-90% though.
>
>OTOH, you can probably keep up with whatever the network can give you,
>using either ascii or binary math:
>
>10 Gbit/s of packet data is about 1 GB/s of application data, right?

That really depends on the packet size. At MTU 1500, that's probably
close. At 64byte (the smallest UDP packets), you're not gonna get
anywhere near line rate. Jumbo packets (9kb) are the best for
getting close to line-rate.

1Gbit uses 10b/8b encoding. 10GE uses 64b/66b encoding, so it
has 2 bits overhead per 8-bytes of data. 1GB with 10b/8b has 2 bits
of overhead per byte.

ARM based SoC's with multiple 10GE are around. Figure next gen will have
multiple 40GE ports. At this point, simply generating enough traffic to
saturate the port is difficult, don't even think of getting it off spinning media.

scott

[hanc...@bbs.cpcn.com]

On Mar 11, 8:41 am, Stephen Sprunk <step...@sprunk.org> wrote:

> > On the mainframe, storing the data in binary would require an
> > unnecessary conversion with a slow instruction.
>
> Slow: You keep using that word.  I do not think it means what you think
> it means.

As mentioned, I ran comparison tests of binary vs. packed decimal
fields. While it was a while ago, the result was that binary took
much longer to run than packed decimal.

What has been your experience?

[Shmuel Metz]

In <m338w2h...@garlic.com>, on 03/11/2013

at 09:58 AM, Anne & Lynn Wheeler <ly...@garlic.com> said:

>minor issue, 3330-II was twice the capacity

ITYM 3330-11; the (rare) 3330-2 was a 3330-1 with a single drive
drawer. The 3330-11 had two drawers each holding a 3336-11.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <PM0004D7A...@aca20377.ipt.aol.com>, on 03/11/2013

at 01:35 PM, jmfbahciv <See....@aol.com> said:

>He didn't notice how other people did their work.

Wrong again, tonto.

[Shmuel Metz]

In <PM0004D7A...@aca20377.ipt.aol.com>, on 03/11/2013
at 01:35 PM, jmfbahciv <See....@aol.com> said:

>With the arrogance you display here,

PKB.

[Shmuel Metz]

In <o7pqj8h7vsmvgaouf...@4ax.com>, on 03/11/2013
at 12:17 AM, Robert Wessel <robert...@yahoo.com> said:

>If we were talking S/360s, these were further limited to selector
>channels, which significantly prevented doing I/O on different
>drive on the same channel at once (the channel would be busy
>during much of the access delay).

The channel was busy during rotational delays and embedded seeks[1],
but not during the stand-alone seeks added by IOS.

>The larger and faster 3330 disk shipped in about 1973. But
>assuming we're talking about before that, and assuming we're
>talking about early 370s or 360s, you were limited to no more than
>five selector or block multiplexor channels,

Six[2] for S/360, except for 360/67-2, where it is 6 per channel
controller, and for 360/195[3] with EXTENDED CHANNEL FEATURE, where it
is 13.

[1] Imbedded seeks were rare, and usually were for short distances.

[2] Six per side for 65MP.

[3] The 370/195 was essentially the same machine with more
circuitry.

[Shmuel Metz]

In <npiqj89i6bn6kf0be...@4ax.com>, on 03/10/2013
at 10:18 PM, Robert Wessel <robert...@yahoo.com> said:

>My objection is not that Cobol lacked proper subroutines in 1959,
>my objection is that Cobol lacked proper subroutines in 1999!
>Whatever the other faults of Cobol, and there are many (they
>syntax was an interesting and worthwhile experiment in 1959,
>although it clearly was a mistake a few years later),

Keep in mind that COBOL was the product of the short range committee;
it was intended to be a temporary expedient until a better language
was released. Think of it as Algol 58.

[Shmuel Metz]

In <khj7q4$d2t$1...@dont-email.me>, on 03/10/2013
at 08:20 PM, Peter Flass <Peter...@Yahoo.com> said:

>PL/I exception handling applies to a large chunk of the program,
>"ON OVERFLOW..." applies until canceled ("ON OVERFLOW SYSTEM"),
>overridden by another "ON OVERFLOW", or until masked
>"(NOOVERFLOW): ...".

Not quite; ON was associated with the containing block and reverted on
block exit; condition prefixes only apply to a single statement.

>What it seems to most closely resemble is OS/360 SPIE handling, or
>maybe the actual operation of interrupts in hardware.

It doesn't resemble either; both are lacking a concept of block
structure.

[Shmuel Metz]

In <mdd4ngi...@panix5.panix.com>, on 03/10/2013
at 07:42 PM, Rich Alderson <ne...@alderson.users.panix.com> said:

>I've got a pair of TU78s on the 2065, a pair of M4DATA 9914s on
>the Toad-1, and a TU77 on a 2020. I'll put a TU45 on the KI when
>that is ready to go.

On the IBM side, do you have any working[1] Itel disk drives or Potter
tape drives?

[1] Not that I ever saw one working reliably.

[Shmuel Metz]

In <u15qj8tr8aa9cagju...@4ax.com>, on 03/10/2013
at 04:21 PM, Gene Wirchenko <ge...@telus.net> said:

>Why? What is so difficult about it that someone can not pick up
>the basics and be able to modify an existing program?

What is so difficult about PL/I that someone can not pick up the
basics of coding and be able to modify an existing program? More to
the point, learning the language is only a small part of programming,
and teaching the rest will take a while, regardless of the language.

[Shmuel Metz]

In <khj3m3$q58$1...@dont-email.me>, on 03/10/2013
at 04:08 PM, Stephen Fuld <SF...@alumni.cmu.edu.invalid> said:

>Not that I know of! :-) Of course, if you just looked at it, you
>knew immediately.

Well, yes, but if you *looked* at an IBM 2305 you could see
immediately that it wasn't a drum, so I was asking about the
nomenclature among those who couldn't be bothered to actually look.

[Patrick Scheible]

Stan Barr <pla...@dsl.pipex.com> writes:

> On Fri, 8 Mar 2013 20:16:36 +0000, Ahem A Rivet's Shot
> <ste...@eircom.net> wrote:

>> On Fri, 08 Mar 2013 17:33:22 GMT
>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> All one needs to do is ensure that monetary values are representated

>>> as an integral in the smallest part (i.e. the penny) then integer
>>> arithmetic is sufficient.
>>
>> I gather milli-pennies are needed for interest calculations.
>>
>
> We used them for hourly rate wage calculations. Strange
> management/union agreemments and paying to the exact minute made it
> necessary!

We pay to the 1/100 of an hour :P

-- Patrick

[Patrick Scheible]

jmfbahciv <See....@aol.com> writes:

> Morten Reistad wrote:
>> In article <PM0004D79...@aca3577a.ipt.aol.com>,

>> Easier said than done.
>
> I know; we did have experience. :-)
>
>> Disk performance has gone up 75-100 fold since
>> the mid 1960s. CPU performance has gone up 10 000-20 000 fold. Memory
>> has gone up somewere in between, closer to disks.
>>
>> Memory sizes have expanded almost a million times. Disk the same. But
>> the bandwith to that storage has gone up only about a thousandfold.
>
> Similar scales of improvement also occured in the late 60s and early
> 70s, didn't they?
>>
>> So backups take longer, sometimes they are impossible to do, so we
>> have to rely on mirroring and transaction logs for most really large
>> installations.
>
> The computer biz has become so used to "fast" single perpherals that
> multiple peripherals acting as a unit has been forgotten. We talked
> about this about 12 or 14 years ago. (I can't believe it's been
> that long ago.)

Isn't that what RAID arrays are?

-- Patrick

[Scott Lurndal]

Peter Flass <Peter...@Yahoo.com> writes:

>> As I said _typically_ smaller recompilation jobs. If you modify a
>> widely shared object, you're going to get to recompile a lot of
>> modules. If you're changing those widely shared objects frequently,
>> you probably have a design problem of some sort.
>
>That's one of the minor problems of make. If you design, control blocks
>with unused space at the end - always considered good practice, AFAIK -
>it's easy to add new fields used by one or two modules without affecting
>anything else. However, make won't realize this and will force
>recompilation of everything that uses that control block.

I'd consider that a feature.

Even a linux recompile takes relatively little time on any modern CPU.

scott

[Scott Lurndal]

Multiple Peripherals acting as a Unit is for disks known as RAID, and it the
most common form of accelerating storage performance in existance.

Just look at a large EMC box; hundreds to thousands of drives which
appear to the hosts (plural) as one or many "logical units". Modern
storage virtualization abstracts the storage to the block level
(an arbitrary sized chunk of data, often in the 4kbyte range) where
the blocks can be distributed (and replicated) anywhere in the world
and access to the blocks (over 10GE converged ethernet or 8Gbs fibrechannel)
is much faster than legacy transports.

[Morten Reistad]

In article <PM0004D7A...@aca20377.ipt.aol.com>,

jmfbahciv <See....@aol.com> wrote:
>Morten Reistad wrote:
>> In article <PM0004D79...@aca3577a.ipt.aol.com>,
>> jmfbahciv <See....@aol.com> wrote:
>>>Stephen Sprunk wrote:

>>>> On 08-Mar-13 09:50, hanc...@bbs.cpcn.com wrote:
>>>>> On Mar 7, 11:20 pm, Stephen Sprunk <step...@sprunk.org> wrote:

>>>> ... just like any other modern machine. Aside from exceptional cases
>>>> like video codecs, the CPU will spend the majority of its time stalled,
>>>> waiting for the rest of the system to catch up. We simply don't have
>>>> the technology to feed them data fast enough to stay busy. Even RAM is
>>>> ridiculously slow compared to modern CPUs.
>>>
>>>then make the hardware symmetric.
>>
>> Easier said than done.
>
>I know; we did have experience. :-)

yes, you should have witnessed a cpu speedup of 100-500x from the first
KA10 to the latest VAX/Alpha, and an I/O speedup of 15-20 times.

>> Disk performance has gone up 75-100 fold since
>> the mid 1960s. CPU performance has gone up 10 000-20 000 fold. Memory
>> has gone up somewere in between, closer to disks.
>>
>> Memory sizes have expanded almost a million times. Disk the same. But
>> the bandwith to that storage has gone up only about a thousandfold.
>
>Similar scales of improvement also occured in the late 60s and early
>70s, didn't they?

With some minor speed bumps this development has been quite linear.
Individual CPUs stopped getting faster around 2004, but they still
obey Moore's laws of size and power usage, so we can fit more than
one even in iPhones.

>> So backups take longer, sometimes they are impossible to do, so we
>> have to rely on mirroring and transaction logs for most really large
>> installations.
>
>The computer biz has become so used to "fast" single perpherals that
>multiple peripherals acting as a unit has been forgotten. We talked
>about this about 12 or 14 years ago. (I can't believe it's been
>that long ago.)

No, this is what SAN and NAS are all about. The latter is network-
centric, the first machine (or, rather, cluster) centric.

With gigabit ethernet getting implemented cheaply everywhere we
can use it for disk i/o, even the latency is not any worse.

-- mrr

[Morten Reistad]

In article <PM0004D7A...@aca20377.ipt.aol.com>,
jmfbahciv <See....@aol.com> wrote:

>Gene Wirchenko wrote:
>> On Sat, 09 Mar 2013 23:47:19 -0600, Robert Wessel
>> <robert...@yahoo.com> wrote:
>>
>>>On 9 Mar 2013 15:11:06 GMT, jmfbahciv <See....@aol.com> wrote:
>>
>> [snip]
>>
>>>>I didn't say it was incapable. I simply stated that choosing PL/I
>>>>over COBOL for accounting (which is usually the business app) is
>>>>nuts. You can write a COBOL program with the security that you will
>>>>never have to look at it again because the business assistant can
>>>>do the maintenance. I can teach a secretary how to maintain a
>>>>COBOL program fairly quickly. It would take a lot, lot longer
>>>>to teach PL/I. The whoe goal of choosing the best lanugage for
>>>>a job is long-term maintenance for _somebody else_.
>>
>>>OK, you're clearly not being serious.
>>
>> Oh, she is quite serious. Your ox is getting gored though so you
>> have to reject it..
>
>ROTFLMAO. Thanks, Gene.
>
>>
>>>At the very least that someone else should be a professional
>>>programmer. No secretary (or anyone else) untrained in programming,

>>
>> Why? What is so difficult about it that someone can not pick up
>> the basics and be able to modify an existing program?
>>

>> Of course, you could design programming languages to deliberately
>> make it difficult. You could also design to deliberately make it
>> easy.
>
>I'd still pick the old COBOL to do this for people who aren't
>programmers.

You assume that the secretaries are trainable and have the inkling
to do programming. Coming from DEC you are biased, people there were
probably 10x more trainable and inclined to programming than a "normal"
business.

But having people from other professions train to become programmers,
or for some, just naturally migrate in that direction, is generally
a good idea. Just keep the workload correct. Don't give them assembly
or RPG programs the first week.

-- mrr

[Ahem A Rivet's Shot]

On 9 Mar 2013 15:11:01 GMT
jmfbahciv <See....@aol.com> wrote:

> Ahem A Rivet's Shot wrote:
> > On 8 Mar 2013 13:59:39 GMT
> > jmfbahciv <See....@aol.com> wrote:
> >
> >> Andrew Swallow wrote:
> >
> >> > Many COBOL programs also used all 9s as an end of batch card.
> >>
> >> I wonder how that got started. It was the end condition in all the
> >> programming classes I took for the 1620.
> >
> > I don't know how it started, but I do know it meant we had to test
> > everything in sight with 9th September 1999 as part of the Y2K scramble.
> >
> >
> <GRIN> Did you find any 9-bugs?

Nah, nothing we were working with was old enough to use conventions
like that. In most cases the languages it was written in weren't around
when that convention was common. We still had to run a full regression test
suite with the date set to that (and a bunch of other dates deemed risky),
as well as rolling the clock from 31 Dec 1999 to 1 Jan 2000.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Peter Flass]

Sounds like someone reinvented Multics.



--
Pete

[Peter Flass]

On 3/11/2013 9:58 AM, Anne & Lynn Wheeler wrote:
>
> at share user group meeting there was semi-facetious resolution asking
> IBM for a "fast" 3380. It was a controller microcode load that only
> allowed access to half the number of cylinders ... avg. access goes up
> because only half the distance to travel.

This is less than half a joke. I recall reading about a disk drive,
perhaps a 2311 for a 360/20 that had a stop installed so it could only
access half the platter.

--
Pete

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004D7A...@aca20377.ipt.aol.com...
> driftwood wrote:
>> On Sun, 10 Mar 2013 15:01:12 +0000, jmfbahciv wrote:
>>
>>> Who was forcing anyone? It just shows the bias I see in "expert"
>>> programmers. Simple maintenance of code/data should be possible for
>>> anyone to do. Now that everyone is really a system owner and needs more
>>> expertise than the old-style systems analysts, they have to
>>
>> s/have to/should/ !!!
>
> Nope. It's have to. I listened to two young women in the early 90s
> talking about their computer sytems and what they had to do about them
> that week. It was similar to setting in a meeting with all of the
> managers of the people mentioned below.

> Now, since everything including toilet have computers,
> people have to have these skills without thinking about them.

Nope, they just use systems like facebook that work fine without those
skills.

>>> be able to
>>> do what operators, field service, OS developers/maintainers app
>>> programmers/mmaintainers, buyers, and network nazis used to do.

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004D7A...@aca20377.ipt.aol.com...

> Robert Wessel wrote:
>> On Sun, 10 Mar 2013 15:09:03 -0400, Peter Flass
>> <Peter...@Yahoo.com> wrote:
>>
>>>On 3/10/2013 2:26 PM, hanc...@bbs.cpcn.com wrote:
>>>> On Mar 10, 2:19 am, Terje Mathisen <"terje.mathisen at tmsw.no">
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> The US us still living in the dark ages with so much of your financial
>>>>> systems actually using paper, including the quaint custom of printed
>>>>> check processing.
>>>>
>>>> US industry has been aggressively moving toward paperless
>>>> transactions. For instance, many companies now charge for a printed
>>>> statement as opposed to a free one that is emailed.
>>>>
>>>>> Even when we lived in Utah in 1991-92, we found it really quaint how
>>>>> we
>>>>> signed personal checks in the grocery store, and then later got the
>>>>> stubs back in the mail from our local bank!
>>>>
>>>> Banks no longer return checks, but send an image, if they still even
>>>> mail out a statement.
>>>>
>>>> Many transactions are handled by debit cards today.
>>>>
>>>
>>>I still refuse to use "online banking". That way I don't need to worry
>>>about someone stealing my information.
>>
>>
>> While I don't care if you use online banking or not, isn't the
>> question actually whether or not it's safer than the alternatives?
>> Pretty much all the offline banking transactions can be subverted too.

> But it has to be done locally.

Nope, not with check processing it doesn’t.

> Someone in China can't clear out your accounts.

I don’t care if they do, that’s the bank's problem because they
guarantee that if that happens, they get to wear that themselves.

> There is lanugage in my broker's contract which says any access
> to my account not done by me is not their problem because I'd
> have had to have given my password to that unauthorized person.
> I told them in writing I did not want any electronic access to my
> account.

More fool you. It would have made much more sense to find an
operation that had more of a clue about how to do electronic access.

> I'm assuming the same kind of weaseling is done by banks

Not one of my banks do that.

And if you are actually stupid enough to do all your transactions
using cash because of the risk with cards or checks, you are MUCH
more likely to get mugged for that cash than to have anyone steal
you personal details when you use a card to pay for stuff instead.

> since they're crookeder than brokerages at this time.

Even sillier.

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004D7A...@aca20377.ipt.aol.com...

> Morten Reistad wrote:
>> In article <PM0004D79...@aca3577a.ipt.aol.com>,
>> jmfbahciv <See....@aol.com> wrote:
>>>Stephen Sprunk wrote:
>>>> On 08-Mar-13 09:50, hanc...@bbs.cpcn.com wrote:
>>>>> On Mar 7, 11:20 pm, Stephen Sprunk <step...@sprunk.org> wrote:

>>>>>> On 07-Mar-13 15:23, hanco...@bbs.cpcn.com wrote:
>>>>>>> If so, how efficient are PERL executables on an IBM mainframe?*
>>>>>>> That is, say a program had to read a sequential file of 1,000,000
>>>>>>> records each being 512 bytes long, perform various tests and
>>>>>>> calculations on the fields** within each record, and generate
>>>>>>> several reports for those records that meet selection criteria.
>>>>>>> How long would the executable run as compared to a COBOL program
>>>>>>> doing the same thing?
>>>>>>
>>>>>> It would take about the same amount of time. Any overhead due to
>>>>>> being an interpreted language would just consume the time the CPU
>>>>>> spends waiting for the I/O system (or even RAM) to feed it data.
>>>>>
>>>>> Mainframe CPUs very often do not spend time "waiting". The systems
>>>>> were designed to run multiple tasks simultaneously. While the CPU
>>>>> is waiting on I/O on one job, it switches to serve the needs of
>>>>> another job.
>>>>

>>>> ... just like any other modern machine. Aside from exceptional cases
>>>> like video codecs, the CPU will spend the majority of its time stalled,
>>>> waiting for the rest of the system to catch up. We simply don't have
>>>> the technology to feed them data fast enough to stay busy. Even RAM is
>>>> ridiculously slow compared to modern CPUs.
>>>
>>>then make the hardware symmetric.
>>
>> Easier said than done.
>
> I know; we did have experience. :-)
>

>> Disk performance has gone up 75-100 fold since
>> the mid 1960s. CPU performance has gone up 10 000-20 000 fold. Memory
>> has gone up somewere in between, closer to disks.
>>
>> Memory sizes have expanded almost a million times. Disk the same. But
>> the bandwith to that storage has gone up only about a thousandfold.
>
> Similar scales of improvement also occured in the late 60s and early
> 70s, didn't they?
>>

>> So backups take longer, sometimes they are impossible to do, so we
>> have to rely on mirroring and transaction logs for most really large
>> installations.

> The computer biz has become so used to "fast" single perpherals
> that multiple peripherals acting as a unit has been forgotten.

Bullshit. Its done all the time with cpus alone.

> We talked about this about 12 or 14 years ago.

And presumably mangled it as comprehensively then as you are doing now.

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004D7A...@aca20377.ipt.aol.com...

More fool you. Anyone with even half a clue uses a report generator instead.

>>>is going to be able to do a thing with anything other than the most
>>>trivial of programs, and then only by trial-and-error. That's *not*
>>
>> Not if the language design makes it easy.
>>
>>>the way to get your business applications updated. And a
>>
>> For simple changes, it would be an excellent way. It would free
>> up the professional programmers for the work that only they can do.

> Yup. the secretary doesn't have to tell a loose-lipped
> coder company confidential information.

Corse no secretary is ever loose lipped, eh ?

>>>non-professional user like that should be given a copy of Crystal
>>>Reports, or similar, and some training, and should never be forced
>>>into the bowels of a procedural programming language. Unless, of
>>>course, they were looking for a career change.

>> Or are not particularly stupid.

> I don't think I ever met a secretary who was stupid.

I have, plenty of them.

> The secretaries of our CEO and VPs couldn't be.

[Charlie Gibbs]

In article <kUl%s.6318$qe6....@fe10.iad>, sc...@slp53.sl.home
(Scott Lurndal) writes:

> jmfbahciv <See....@aol.com> writes:

>
>> Scott Lurndal wrote:
>>
>>> All one needs to do is ensure that monetary values are representated
>>> as an integral in the smallest part (i.e. the penny)
>>

>> Wrong. The stock market goes to 4 decimal points; you would be very
>> upset if your reinvestments of dividends was to the penny.
>
> I said smallest part, then gave penny as _AN EXAMPLE_.

<nit>
No you didn't. Otherwise you would have said "e.g." instead of "i.e.".
</nit>

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004D7A...@aca20377.ipt.aol.com...

> Morten Reistad wrote:
>> In article <PM0004D79...@aca3577a.ipt.aol.com>,
>> jmfbahciv <See....@aol.com> wrote:

>>>Shmuel (Seymour J.) Metz wrote:
>>>> In <PM0004D76...@ac817560.ipt.aol.com>, on 03/08/2013
>>>> at 01:59 PM, jmfbahciv <See....@aol.com> said:
>>>>
>>>>>COBOL didn't require the expertise of systems programmers (old
>>>>>defintion). All other lanugages did,
>>>>
>>>> ROTF,LMAO! That's the dumbest thing I've read yet.
>>>>
>>>Then you're too young to know how things worked back then.
>>
>> We still need that sort of programmer, the Application
>> Programmer. Even with all the various excel and other
>> user tools, we need someone to bring the business logic
>> into code.
>>
>> COBOL seems a nice tool, until you get bitten by the
>> verbosity, lack of functions or subroutines, and my
>> pet peeve, the codasyl grammar. An if test in cobol,
>> or a compute expression, will be resolved _very_
>> differently from what everyone else does.
>>
>> Once you realise that you need a programmer, then
>> other choices like PL/1, fortran/ratfor, or other
>> procedural 3rd generation languages work fine, almost
>> all of them. And on almost every sane OS you can
>> link routines together from different languages.
>
> Will you be able to hand over the code to someone whose
> job isn't coding? I was able to do this with COBOL.
> Similar work is done by today's spreadsheet software
> packages which didn't exist back then. I'm getting
> a tad testy w.r.t. the attitude that people, who orgranize
> spreadsheets so that it produces reports based on current
> data just keyed in, arent' programmers.

What is being discussed is SYSTEM programmers.

And spreadsheets don’t require the use of any dinosaur language ANYWAY.

> Even people who produced documents using RUNOFF needed programming skills.

Very few do it that way either, they just use word or acrobat
etc which again doesn’t require any dinosaur language or
even a more modern one like java etc either.

[Michael S]

1001st

[Shmuel Metz]

In <q8m%s.6321$qe6....@fe10.iad>, on 03/11/2013
at 02:47 PM, sc...@slp53.sl.home (Scott Lurndal) said:

>Haven't heard of the 490. Are you refering to the electrodata 205
>derivatives?

[Shmuel Metz]

In <q8m%s.6321$qe6....@fe10.iad>, on 03/11/2013
at 02:47 PM, sc...@slp53.sl.home (Scott Lurndal) said:

>Haven't heard of the 490. Are you refering to the electrodata 205
>derivatives?

No; the 490 architecture appeared in a number of guises. See, e.g.,

<http://en.wikipedia.org/wiki/AN/USQ-17>
<http://en.wikipedia.org/wiki/AN/USQ-20>
<http://en.wikipedia.org/wiki/UNIVAC_490>

[John Levine]

>> The first time a particular PLT entry is branched to, the PLT entry
>> will branch to the code which resolves the symbol then updates the
>> PLT entry to point to the resolved symbol (lazy binding). An optional
>> environment variable (or dlopen flag) can be used to force the binding when the shared
>> object is loaded (so you don't get an unresolved symbol potentially long
>> after the module is loaded).
>>
>> For global data, the GOT (Global Offset Table) performs similar relocations.
>>
>
>Sounds like someone reinvented Multics.

More like someone knew their history and used something that was known
to work.

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Stephen Fuld]

On 3/11/2013 7:47 AM, Scott Lurndal wrote:
> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>> In <F0s_s.728029$W71.2...@fed07.iad>, on 03/08/2013
>> at 08:40 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>
>>> Perhaps on IBM mainframes, but not on burroughs mainframes. Binary
>>> subscripts wouldn't work at all since memory addresses (pointers) are
>>> also BCD.
>>
>> That is only true of a dead line; the surviving line of Burroughs
>> computers uses binary addressing.
>>
>> BTW, how many B2500 derivatives were shipped compared to other lines,
>> e.g. 490, 1700, 5000, 6500?

>
> Haven't heard of the 490.

The 490 series was a Univac, not Burroughs architecture. It was long
gone by the time of the merger. The architecture was 30 bit
architecture. They could use a lot of the same peripherals as the 36
bit 1100 series and the 18 bit 418 series..


--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[William Clodius]

Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:

> Andrew Swallow wrote:
> > Although language designers forgetting to include BCD data types in
> > their languages means that COBOL has no problem proving that it is about
> > 10,000 times better for data processing that their nightmare child.
>
> Even _perl_ is an order of magnitude better than COBOL for data
> processing, including any possible combination of fp, integer and
> ascii/bcd numeric values...
>
> Terje
Could you write a high performance Cobol compiler in it?

[Gene Wirchenko]

On Mon, 11 Mar 2013 10:30:36 -0400, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:

>In <u15qj8tr8aa9cagju...@4ax.com>, on 03/10/2013
> at 04:21 PM, Gene Wirchenko <ge...@telus.net> said:
>
>>Why? What is so difficult about it that someone can not pick up
>>the basics and be able to modify an existing program?
>
>What is so difficult about PL/I that someone can not pick up the
>basics of coding and be able to modify an existing program? More to
>the point, learning the language is only a small part of programming,
>and teaching the rest will take a while, regardless of the language.

Of course it will take a while to learn it all, but one can start
with a small subset and work from there. Sometimes, the language is
such that a lot of work can get done with that small subset.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Mon, 11 Mar 2013 09:50:05 -0400, Dan Espen <des...@verizon.net>
wrote:

[snip]

>Spread sheets, secretary.
>
>COBOL program, programmer.
>
>Trying to quibble your way out of this?

Aren't you? A secretary could be a programmer. It might be on a
very basic level, but it would still be programming.

OTOH, I once wrote some code using double indirection using Lotus
Symphony (a spreadsheet program).

Sincerely,

Gene Wirchenko

[John Levine]

>> Even _perl_ is an order of magnitude better than COBOL for data
>> processing, including any possible combination of fp, integer and
>> ascii/bcd numeric values...
>>
>> Terje
>Could you write a high performance Cobol compiler in it?

I don't see why not. I've written adequately fast DNS servers in
perl, it can bash bits when needed.

This brings us back to the point that CPUs have gotten so fast that even
though perl is semi-interpreted, it's fast enough to outrun the disks.

[Stephen Sprunk]

On 11-Mar-13 07:28, Walter Bushell wrote:
> In article <khkjm8$5n1$1...@dont-email.me>, Stephen Sprunk
> <ste...@sprunk.org> wrote:
>> Remember, if something is on the news, that means it's rare enough
>> that you shouldn't worry about it. It's the things that _don't_
>> make the news, due to being so common, that you should worry
>> about.
>
> May I use this as a sig and if so do you want attribution?

I'd be honored.

> OTOH, it's the secret government actions, do you know how many people
> the government has disappeared?

Of course not; they're secret, right?

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Joe Pfeiffer]

When I saw this Subject:, I thought it was about PIC microprocessors.

Bizarre by any standard I can think of (and I've programmed CDC
6000-series and DG Nova in assembly code), but my favorite for little
embedded projects.

[Robert Wessel]

On Mon, 11 Mar 2013 10:49:49 -0400, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:

>In <npiqj89i6bn6kf0be...@4ax.com>, on 03/10/2013
> at 10:18 PM, Robert Wessel <robert...@yahoo.com> said:
>
>>My objection is not that Cobol lacked proper subroutines in 1959,
>>my objection is that Cobol lacked proper subroutines in 1999!
>>Whatever the other faults of Cobol, and there are many (they
>>syntax was an interesting and worthwhile experiment in 1959,
>>although it clearly was a mistake a few years later),
>
>Keep in mind that COBOL was the product of the short range committee;
>it was intended to be a temporary expedient until a better language
>was released. Think of it as Algol 58.


But it did hang on, and become popular. Major revision happened in
1968 and 1974, upgrading some of the basics could (and should) have
been done. I'd say 1985 as well, but the committee that (finally)
produced the 1985 standard was approximately completely dysfunctional.

[Robert Wessel]

>data just keyed in, arent' programmers. Even people

>who produced documents using RUNOFF needed programming
>skills.

Anyone who has put a formula into a spreadsheet is programming. The
vast majority of people who have done so are not programmers.

That trivial programming jobs can be accomplished by non-specialists
is not surprising - you don't need a carpenter to hang a picture.

Once things get more complex than the most basic problems, the lack of
skills* tends to doom the effort. Look at the disaster that
non-trivial spreadsheets are. Of course "skilled" programmers
certainly introduce their shares of bugs. But those trivial problems
are not major parts of complex systems, and are frankly not relevant.
The basic reporting you've been describing is really peripheral to the
system, and if Cobol had been limited to that, no one would care - it
would be another niche report generator. But Cobol gets used for the
"real" parts of the system too. And it's a bad language for that.

Jean Sammet, a member of the CODASYL committee:

"The users for who COBOL was designed were actually two subclasses of
those people concerned with business data processing problems. One is
the relatively inexperienced programmer for whom the naturalness of
COBOL would be an asset, while the other type of user would be
essentially anybody who had not written the program initially. In
other words, the readability of COBOL programs would provide
documentation to all who might wish to examine the programs, including
the supervisory or management personnel. Little attempt was made to
cater for professional programmers."


*and that's not intended to be pejorative - I can toss some field
stitches into a good cut, but you certainly don't want someone with my
lack of surgical skills taking out your appendix

[Robert Wessel]

It would be a better language for writing a Cobol compiler than Cobol
(which has been done), although other choices would be better still.
As a semi-interpreted language, it would give up some performance to
some of the fully compiled choices.

[Robert Wessel]

On Sun, 10 Mar 2013 11:49:39 -0700 (PDT), hanc...@bbs.cpcn.com wrote:

>On Mar 10, 10:01�am, jmfbahciv <See.ab...@aol.com> wrote:
>
>> > "Do you want it fast or do you want it good?"
>>
>> Or do you want it consistent?
>
>Good points.
>
>The business-application world largely standardized and stayed with
>COBOL to gain that consistency. That was a also a contributing reason
>to stick with IBM--and why IBM has stuck with S/360 architecture for
>50 years.


Perhaps that was true in the 70s, but only a (very) small fraction of
business programming is now done in Cobol and/or on mainframes.

[Robert Wessel]

On 11 Mar 2013 13:35:40 GMT, jmfbahciv <See....@aol.com> wrote:

>Morten Reistad wrote:
>> In article <PM0004D79...@aca3577a.ipt.aol.com>,
>>
>

>> Disk performance has gone up 75-100 fold since
>> the mid 1960s. CPU performance has gone up 10 000-20 000 fold. Memory
>> has gone up somewere in between, closer to disks.
>>
>> Memory sizes have expanded almost a million times. Disk the same. But
>> the bandwith to that storage has gone up only about a thousandfold.
>
>Similar scales of improvement also occured in the late 60s and early
>70s, didn't they?

Disk yes, memory didn't drastically fall off the performance curve
until the early 90s.

>>
>> So backups take longer, sometimes they are impossible to do, so we
>> have to rely on mirroring and transaction logs for most really large
>> installations.
>
>The computer biz has become so used to "fast" single perpherals that

>multiple peripherals acting as a unit has been forgotten. We talked
>about this about 12 or 14 years ago. (I can't believe it's been
>that long ago.)


Only a partial solution. In the early 80s, you could read an entire
3380 disk in about five minutes (sequentially, of course), a 2314
could have been read in a bit under two minutes. Modern 3TB disks
take on the order of four hours, simply because you have to let the
things spin ~1.5 million times to get to all the data. Assuming we
keep using disks, current growth rates would increase that another
factor of 50 in the next 30 years, which will pretty much make backing
up a hard disk impossible (just a sequential read of a disk would take
over a week).

You could duplicate drives to increase the backup rate, but that has
pretty severe limits.

[Andrew Swallow]

On 12/03/2013 06:04, Robert Wessel wrote:
{snip}

>
> Perhaps that was true in the 70s, but only a (very) small fraction of
> business programming is now done in Cobol and/or on mainframes.
>

Which leads to the side thought - what language(s) are used for stock
control and payroll programs these days?

Andrew Swallow

[Terje Mathisen]

As John L also stated, the answer is obviously Yes!

The high performance would be in the resulting code, not so much the
actual compile times, although you could probably do a pretty good
pattern recognizing optimizer in perl:

Regexp is native operation in perl, as is also hash-based array access.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[nm...@cam.ac.uk]

In article <ib231a-...@ntp-sure.tmsw.no>,

Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:

>William Clodius wrote:
>>
>>>> Although language designers forgetting to include BCD data types in
>>>> their languages means that COBOL has no problem proving that it is about
>>>> 10,000 times better for data processing that their nightmare child.
>>>
>>> Even _perl_ is an order of magnitude better than COBOL for data
>>> processing, including any possible combination of fp, integer and
>>> ascii/bcd numeric values...
>>>

>> Could you write a high performance Cobol compiler in it?
>>
>As John L also stated, the answer is obviously Yes!
>
>The high performance would be in the resulting code, not so much the
>actual compile times, although you could probably do a pretty good
>pattern recognizing optimizer in perl:
>
>Regexp is native operation in perl, as is also hash-based array access.

Provided that you didn't mind too much which patterns it actually
recognised!

When I worked on it, simple regular expressions were optimised
out in the parser, which meant that all but one of the supplied
tests of its regular expression code didn't reach the code they
claimed to be testing. The problem there is that you CAN get
the same pattern through, and it almost certainly behaves
differently. I doubt that this has changed.

More recently, I teach regular expressions, and there is at least
one timing anomaly where it simply cannot execute the algorithm
that people expect. I haven't bothered to check if this effect
can be used to get unexpected results but would assume so. In
Perl-like regular expressions, there is essentially no concept
of incorrectness.

In my book, performance takes third place to correctness and
clarity, but I am an old fuddy-duddy.


Regards,
Nick Maclaren.

[Peter Flass]

On 3/11/2013 8:08 PM, Stephen Fuld wrote:
>> Haven't heard of the 490.
>
> The 490 series was a Univac, not Burroughs architecture. It was long
> gone by the time of the merger. The architecture was 30 bit

^^^^^^

> architecture. They could use a lot of the same peripherals as the 36
> bit 1100 series and the 18 bit 418 series..
>

Now *that's* bizarre.


--
Pete

[Peter Flass]

Or is really "programming" at all.

--
Pete

[Quadibloc]

On Mar 12, 1:07 am, Andrew Swallow <am.swal...@btinternet.com> wrote:

> Which leads to the side thought - what language(s) are used for stock
> control and payroll programs these days?

Visual Basic for Applications, from within Microsoft Access, to hazard
a guess? For the few mid-sized companies that actually hire their own
programmers to do this stuff, that is.

John Savard

[Walter Bushell]

In article <khm9hf$dv4$1...@dont-email.me>,

Stephen Sprunk <ste...@sprunk.org> wrote:

> On 11-Mar-13 07:28, Walter Bushell wrote:
> > In article <khkjm8$5n1$1...@dont-email.me>, Stephen Sprunk
> > <ste...@sprunk.org> wrote:
> >> Remember, if something is on the news, that means it's rare enough
> >> that you shouldn't worry about it. It's the things that _don't_
> >> make the news, due to being so common, that you should worry
> >> about.
> >
> > May I use this as a sig and if so do you want attribution?
>
> I'd be honored.
>
> > OTOH, it's the secret government actions, do you know how many people
> > the government has disappeared?
>
> Of course not; they're secret, right?
>
> S

Exactly!

If you're not paranoid, you're not paying attention. Myself, I just
annoyed.

--

Remember, if something is on the news, that means it's rare enough
that you shouldn't worry about it. It's the things that _don't_
make the news, due to being so common, that you should worry

about. -- Stephen Sprunk <ste...@sprunk.org>

[Walter Bushell]

In article <1kzl30j.ta7jpx1ypby3mN%wclo...@earthlink.net>,

That could be interesting, you could arrange to drop into Perl when
COBOL became to annoying, just like you used to be able to drop into
assembly language from FORTRAN.

[Scott Lurndal]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>In <q8m%s.6321$qe6....@fe10.iad>, on 03/11/2013
> at 02:47 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>
>>Haven't heard of the 490. Are you refering to the electrodata 205
>>derivatives?
>
>No; the 490 architecture appeared in a number of guises. See, e.g.,
>
> <http://en.wikipedia.org/wiki/AN/USQ-17>
> <http://en.wikipedia.org/wiki/AN/USQ-20>
> <http://en.wikipedia.org/wiki/UNIVAC_490>

Which would be sperry, not burroughs.

scott

[Scott Lurndal]

Peoplesoft, SAP and ORACLE.

(at least one of which is written in C).

scott

[hanc...@bbs.cpcn.com]

On Mar 11, 11:39 am, hanco...@bbs.cpcn.com wrote:

> As mentioned, I ran comparison tests of binary vs. packed decimal
> fields.  While it was a while ago, the result was that binary took
> much longer to run than packed decimal.

For the heck of it, I ran a rough quick test. Mainframe binary moves
still take twice as long CPU time as decimal due to conversion. It
appears the CVD and CVB are still relatively slow instructions.

Regarding disks, here is a blurb from IBM regarding "RAID"
technology. It would seem that disk speeds have increased more than
merely faster seeks and transmits.

"Redundant array of independent disk (RAID) is the technology of
grouping several physical drives in a computer into an array that you
can define as one or more logical drives. Each logical drive appears
to the operating system as a single drive. This grouping technique
greatly enhances logical-drive capacity and performance beyond the
physical limitations of a single physical drive.

When you group multiple physical drives into a logical drive, the
ServeRAID controller can transfer data in parallel from the multiple
drives in the array. This parallel transfer yields data-transfer rates
that are many times higher than with nonarrayed drives. This increased
speed makes the system better able to meet the throughput (the amount
of data processed in a given amount of time) or productivity needs of
the multiple-user network environment.

The ability to respond to multiple data requests provides not only an
increase in throughput, but also a decrease in response time. The
combination of parallel transfers and simultaneous responses to
multiple requests enables disk arrays to provide a high level of
performance in network environments."

[jmfbahciv]

Dan Espen wrote:
> jmfbahciv <See....@aol.com> writes:
>
>> Dan Espen wrote:

>>> jmfbahciv <See....@aol.com> writes:
>>>
>>>> Shmuel (Seymour J.) Metz wrote:
>>>>> In <PM0004D76...@ac817560.ipt.aol.com>, on 03/08/2013
>>>>> at 01:59 PM, jmfbahciv <See....@aol.com> said:
>>>>>
>>>>>>COBOL didn't require the expertise of systems programmers (old
>>>>>>defintion). All other lanugages did,
>>>>>
>>>>> ROTF,LMAO! That's the dumbest thing I've read yet.
>>>>>
>>>> Then you're too young to know how things worked back then.
>>>

>>> Shmuel young?
>>>
>>> Pretty sure he's a cranky old codger just like you.
>>>
>>> Well, actually, with this apparent 70xx experience
>>> I'm guessing he knows a whole lot more about "back then"
>>> than you ever dreamed of.
>>
>> Now read what I wrote.
>
> You didn't write "Then you're too young"?

Now go back and read what I wrote but smeul nipped.

/BAH

[jmfbahciv]

Wasn't that about the time that HLL insanity started? (where HLL
meant C or BLISS and their derivatives)

/BAH

[jmfbahciv]

Charlie Gibbs wrote:
> In article <kUl%s.6318$qe6....@fe10.iad>, sc...@slp53.sl.home
> (Scott Lurndal) writes:
>
>> jmfbahciv <See....@aol.com> writes:
>>
>>> Scott Lurndal wrote:
>>>
>>>> All one needs to do is ensure that monetary values are representated
>>>> as an integral in the smallest part (i.e. the penny)
>>>
>>> Wrong. The stock market goes to 4 decimal points; you would be very
>>> upset if your reinvestments of dividends was to the penny.
>>
>> I said smallest part, then gave penny as _AN EXAMPLE_.
>
> <nit>
> No you didn't. Otherwise you would have said "e.g." instead of "i.e.".
> </nit>
>
Thank you, Charlie.

/BAH

[jmfbahciv]

Ahem A Rivet's Shot wrote:
> On 9 Mar 2013 15:11:01 GMT
> jmfbahciv <See....@aol.com> wrote:
>
>> Ahem A Rivet's Shot wrote:
>> > On 8 Mar 2013 13:59:39 GMT
>> > jmfbahciv <See....@aol.com> wrote:
>> >
>> >> Andrew Swallow wrote:
>> >
>> >> > Many COBOL programs also used all 9s as an end of batch card.
>> >>
>> >> I wonder how that got started. It was the end condition in all the
>> >> programming classes I took for the 1620.
>> >
>> > I don't know how it started, but I do know it meant we had to test
>> > everything in sight with 9th September 1999 as part of the Y2K scramble.
>> >
>> >
>> <GRIN> Did you find any 9-bugs?
>
> Nah, nothing we were working with was old enough to use conventions
> like that.

Kewl. I don't think I would have thought of doing that test.

> In most cases the languages it was written in weren't around
> when that convention was common. We still had to run a full regression test
> suite with the date set to that (and a bunch of other dates deemed risky),
> as well as rolling the clock from 31 Dec 1999 to 1 Jan 2000.
>
It's too bad there isn't an "easy" way to test leap-year bugs. People are
still writing them.

/BAH

[jmfbahciv]

Rod Speed wrote:
>
>
> "jmfbahciv" <See....@aol.com> wrote in message
> news:PM0004D7A...@aca20377.ipt.aol.com...

>> Morten Reistad wrote:
>>> In article <PM0004D79...@aca3577a.ipt.aol.com>,

>>> jmfbahciv <See....@aol.com> wrote:
>>>>Shmuel (Seymour J.) Metz wrote:
>>>>> In <PM0004D76...@ac817560.ipt.aol.com>, on 03/08/2013
>>>>> at 01:59 PM, jmfbahciv <See....@aol.com> said:
>>>>>
>>>>>>COBOL didn't require the expertise of systems programmers (old
>>>>>>defintion). All other lanugages did,
>>>>>
>>>>> ROTF,LMAO! That's the dumbest thing I've read yet.
>>>>>
>>>>Then you're too young to know how things worked back then.
>>>

>>> We still need that sort of programmer, the Application
>>> Programmer. Even with all the various excel and other
>>> user tools, we need someone to bring the business logic
>>> into code.
>>>
>>> COBOL seems a nice tool, until you get bitten by the
>>> verbosity, lack of functions or subroutines, and my
>>> pet peeve, the codasyl grammar. An if test in cobol,
>>> or a compute expression, will be resolved _very_
>>> differently from what everyone else does.
>>>
>>> Once you realise that you need a programmer, then
>>> other choices like PL/1, fortran/ratfor, or other
>>> procedural 3rd generation languages work fine, almost
>>> all of them. And on almost every sane OS you can
>>> link routines together from different languages.
>>
>> Will you be able to hand over the code to someone whose
>> job isn't coding? I was able to do this with COBOL.
>> Similar work is done by today's spreadsheet software
>> packages which didn't exist back then. I'm getting
>> a tad testy w.r.t. the attitude that people, who orgranize
>> spreadsheets so that it produces reports based on current
>> data just keyed in, arent' programmers.
>

> What is being discussed is SYSTEM programmers.

NO IT"S NOT. My statement was aobut which language I'd choose if
I needed to teach a secretary how to use and maintain it.

JFHC.
/BAH

[jmfbahciv]

Morten Reistad wrote:
> In article <PM0004D7A...@aca20377.ipt.aol.com>,
> jmfbahciv <See....@aol.com> wrote:
>>Gene Wirchenko wrote:
>>> On Sat, 09 Mar 2013 23:47:19 -0600, Robert Wessel
>>> <robert...@yahoo.com> wrote:
>>>
>>>>On 9 Mar 2013 15:11:06 GMT, jmfbahciv <See....@aol.com> wrote:
>>>
>>> [snip]
>>>
>>>>>I didn't say it was incapable. I simply stated that choosing PL/I
>>>>>over COBOL for accounting (which is usually the business app) is
>>>>>nuts. You can write a COBOL program with the security that you will
>>>>>never have to look at it again because the business assistant can
>>>>>do the maintenance. I can teach a secretary how to maintain a
>>>>>COBOL program fairly quickly. It would take a lot, lot longer
>>>>>to teach PL/I. The whoe goal of choosing the best lanugage for
>>>>>a job is long-term maintenance for _somebody else_.
>>>
>>>>OK, you're clearly not being serious.
>>>
>>> Oh, she is quite serious. Your ox is getting gored though so you
>>> have to reject it..
>>
>>ROTFLMAO. Thanks, Gene.
>>
>>>
>>>>At the very least that someone else should be a professional
>>>>programmer. No secretary (or anyone else) untrained in programming,
>>>
>>> Why? What is so difficult about it that someone can not pick up
>>> the basics and be able to modify an existing program?
>>>
>>> Of course, you could design programming languages to deliberately
>>> make it difficult. You could also design to deliberately make it
>>> easy.
>>
>>I'd still pick the old COBOL to do this for people who aren't
>>programmers.
>
> You assume that the secretaries are trainable and have the inkling
> to do programming. Coming from DEC you are biased, people there were
> probably 10x more trainable and inclined to programming than a "normal"
> business.

We didn't import wage class 2 people. They came in off the street.

>
> But having people from other professions train to become programmers,
> or for some, just naturally migrate in that direction, is generally
> a good idea. Just keep the workload correct. Don't give them assembly
> or RPG programs the first week.

Which is why, in the days befoer spreadsheet packages, I would choose
COBOL (we didn't have RPG and I knew one person who did and she couldn't
chew gum and walk at the same time) to create a tool for inputting
numbers and printing a report.


/BAH

[jmfbahciv]

Morten Reistad wrote:
> In article <PM0004D7A...@aca20377.ipt.aol.com>,
> jmfbahciv <See....@aol.com> wrote:
>>Morten Reistad wrote:

>>> In article <PM0004D79...@aca3577a.ipt.aol.com>,
>>> jmfbahciv <See....@aol.com> wrote:

>>>>Stephen Sprunk wrote:
>
>>>>> On 08-Mar-13 09:50, hanc...@bbs.cpcn.com wrote:
>>>>>> On Mar 7, 11:20 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>
>>>>> ... just like any other modern machine. Aside from exceptional cases
>>>>> like video codecs, the CPU will spend the majority of its time stalled,
>>>>> waiting for the rest of the system to catch up. We simply don't have
>>>>> the technology to feed them data fast enough to stay busy. Even RAM is
>>>>> ridiculously slow compared to modern CPUs.
>>>>
>>>>then make the hardware symmetric.
>>>
>>> Easier said than done.
>>
>>I know; we did have experience. :-)
>
> yes, you should have witnessed a cpu speedup of 100-500x from the first
> KA10 to the latest VAX/Alpha, and an I/O speedup of 15-20 times.

>
>>> Disk performance has gone up 75-100 fold since
>>> the mid 1960s. CPU performance has gone up 10 000-20 000 fold. Memory
>>> has gone up somewere in between, closer to disks.
>>>
>>> Memory sizes have expanded almost a million times. Disk the same. But
>>> the bandwith to that storage has gone up only about a thousandfold.
>>
>>Similar scales of improvement also occured in the late 60s and early
>>70s, didn't they?
>

> With some minor speed bumps this development has been quite linear.
> Individual CPUs stopped getting faster around 2004, but they still
> obey Moore's laws of size and power usage, so we can fit more than
> one even in iPhones.

>
>>> So backups take longer, sometimes they are impossible to do, so we
>>> have to rely on mirroring and transaction logs for most really large
>>> installations.
>>
>>The computer biz has become so used to "fast" single perpherals that
>>multiple peripherals acting as a unit has been forgotten. We talked
>>about this about 12 or 14 years ago. (I can't believe it's been
>>that long ago.)
>

> No, this is what SAN and NAS are all about. The latter is network-
> centric, the first machine (or, rather, cluster) centric.
>
> With gigabit ethernet getting implemented cheaply everywhere we
> can use it for disk i/o, even the latency is not any worse.

Networking peripherals is "slow". It takes tons of code to move
one character from here to there. The HSCs were DEC's first
peripheral using the networking concept.

/BAH

[jmfbahciv]

Exactly. That's why I would choose COBOL for a program which was
to accept numeric data, munch on it, and output columnar tables
for VPs to look at. A report writer can be modified easily by the
secretary when she needs to adjust the format. The core of code
is something she can read without having to know algebraic
experssions. The system account she uses can be set up with
a cheat sheet for her to copy so she can login, start the program,
print the output and logout.

>
> That trivial programming jobs can be accomplished by non-specialists
> is not surprising - you don't need a carpenter to hang a picture.

You do need an iron monger if the nails have to be manufactured.

>
> Once things get more complex than the most basic problems, the lack of
> skills* tends to doom the effort. Look at the disaster that
> non-trivial spreadsheets are. Of course "skilled" programmers
> certainly introduce their shares of bugs. But those trivial problems
> are not major parts of complex systems, and are frankly not relevant.
> The basic reporting you've been describing is really peripheral to the
> system, and if Cobol had been limited to that, no one would care - it
> would be another niche report generator. But Cobol gets used for the
> "real" parts of the system too. And it's a bad language for that.

and where, in all of this, did I even susggest that COBOL be used for
that? I never would have stated such a thing. In addition, I would
never even try to teach a non-programmer how to code a device driver
or work in machine lanugage.

>
> Jean Sammet, a member of the CODASYL committee:
>
> "The users for who COBOL was designed were actually two subclasses of
> those people concerned with business data processing problems. One is
> the relatively inexperienced programmer for whom the naturalness of
> COBOL would be an asset, while the other type of user would be
> essentially anybody who had not written the program initially. In
> other words, the readability of COBOL programs would provide
> documentation to all who might wish to examine the programs, including
> the supervisory or management personnel. Little attempt was made to
> cater for professional programmers."
>
>
> *and that's not intended to be pejorative - I can toss some field
> stitches into a good cut, but you certainly don't want someone with my
> lack of surgical skills taking out your appendix

She missed a very important third reason: It specialty was decimal
arithmetic. You didn't have to keep track of decimal pionts when
faking decimal using integers representations. those non-programmers
who have to code think and read/write in decimal.

/BAH

[jmfbahciv]

Scott Lurndal wrote:
> jmfbahciv <See....@aol.com> writes:
>
> I have
>>brokerage statements which couldn't add nor round correctly.
>
> That would be highly unusual and a violation of various securities
> rules.

Pay attention to the interest for money market calculations.

/BAH

[jmfbahciv]

Scott Lurndal wrote:
> jmfbahciv <See....@aol.com> writes:

>>Scott Lurndal wrote:
>>> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>>>>In <gg3_s.29951$na6....@fed15.iad>, on 03/07/2013
>>>> at 04:30 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>>>
>>>>>Burroughs medium systems used a special card as eof,
>>>>
>>>>EOF for the reader or just end-of-job?
>>>>
>>>
>>> EOF for the reader; more precisely, EOF for the file in a program that was
>>> attached to the reader (user app or LDCTRL). The OS would then
>>> read the next card (if present) and if not a control record (1-2-3 punch
>>> in column 1) would display an operator error and logically off-line the
>>> reader until the operator issued a RY CC/UU command.
>>>
>>> The problem with EOF on card readers is that the absence of a card
>>> in the reader cannot be considered EOF. Using a special card
>>> to indicate EOF gives great flexibility and reduces the chance of
>>> the operator forgetting to press the EOF button after a large deck
>>> has been read.
>>
>>You could run a job which had more than one set of card decks. EOF
>>didn't mean butkis on a 1620. You had a program deck, data deck,
>>and maybe other stuff like a format deck. If the code used
>>a compiler the program was preceded by the compiler's set of decks.
>
> What is your point?

A card-oriented machine doesn't have files; it has card decks.
Soft/hardware which was developed in an environment whose history
is cards will have the aspects of card-based computing for two
reasons: 1. the mindset of the developers are immersed in dealing
with card data/code and 2. backwards compatible. I had stated in
a previous post (which I think shmeul snipped) that FORTRAN had
been devloped based on cards, not files, so EOF conditions weren't
an afterthought or an extension with early oompilers.


>
> ?CMP ABC WITH COBOL9 LIB MEM + 100.
> ?FILE CARD
> IDENTIFICATION DIVISION.
> AUTHOR. FRED JONES.
> ...
> STOP RUN.
> END.
> ?END <--------- Signals EOF on file "CARD" in the compiler
> ?EX ABC
> ?FILE SHORT/OUTPUT PBK
> ?FILE INPUT
> DATA RECORD 1
> DATA RECORD 2
> DATA RECORD 3
> ?END <---------- Signals EOF for file INPUT of the compiled program ABC
>
>
> This deck would be stacked in the reader. If it was larger than the reader
> input hopper, it could be split anywhere.

How did Adm. Hopper and her group enter their code?

/BAH

[jmfbahciv]

Scott Lurndal wrote:
> jmfbahciv <See....@aol.com> writes:
>>Scott Lurndal wrote:
>
>>>

>>> All one needs to do is ensure that monetary values are representated
>>> as an integral in the smallest part (i.e. the penny)
>>
>>Wrong. The stock market goes to 4 decimal points; you would be very
>>upset if your reinvestments of dividends was to the penny.
>

> I said smallest part, then gave penny as _AN EXAMPLE_. If millicent is
> the smallest part, then use millicents.
>
>>
>>
>>> then integer arithmetic is
>>> sufficient.
>>
>>that just means that the program has to "remember" where the decimal point
>>it. I certainly would rather fix a COBOL program than a C program
>>which need to report interest earned when the rate is .01%.
>
> How many C programs have you written?

None. What does that have to do with choosing the best lanugage for
a job which depends on accurate decimal arithmetic and ease of use
for the person who is going to own and use the code?

/BAH

[Scott Lurndal]

hanc...@bbs.cpcn.com writes:

>On Mar 11, 11:39=A0am, hanco...@bbs.cpcn.com wrote:
>
>> As mentioned, I ran comparison tests of binary vs. packed decimal

>> fields. =A0While it was a while ago, the result was that binary took

>> much longer to run than packed decimal.
>
>For the heck of it, I ran a rough quick test. Mainframe binary moves
>still take twice as long CPU time as decimal due to conversion. It
>appears the CVD and CVB are still relatively slow instructions.
>
>Regarding disks, here is a blurb from IBM regarding "RAID"
>technology. It would seem that disk speeds have increased more than
>merely faster seeks and transmits.

RAID systems have been around since the 80's. They're not new.

[Ahem A Rivet's Shot]

On Tue, 12 Mar 2013 08:32:15 -0400
Walter Bushell <pr...@panix.com> wrote:

> In article <1kzl30j.ta7jpx1ypby3mN%wclo...@earthlink.net>,
> wclo...@earthlink.net (William Clodius) wrote:
>
> > Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> >
> > > Andrew Swallow wrote:
> > > > Although language designers forgetting to include BCD data types in
> > > > their languages means that COBOL has no problem proving that it is
> > > > about 10,000 times better for data processing that their nightmare
> > > > child.
> > >
> > > Even _perl_ is an order of magnitude better than COBOL for data
> > > processing, including any possible combination of fp, integer and
> > > ascii/bcd numeric values...
> > >
> > > Terje
> > Could you write a high performance Cobol compiler in it?
>
> That could be interesting, you could arrange to drop into Perl when
> COBOL became to annoying, just like you used to be able to drop into
> assembly language from FORTRAN.

I can just see it now:

IDENTIFICATION DIVISION.
PROGRAM-ID. COBSAMP.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
EXEC SQL INCLUDE SQLCA END-EXEC.
01 Sqlcode-Pic PIC +++999 USAGE DISPLAY.
LINKAGE SECTION.
01 Action.
49 VAR-LEN PIC S9(4) USAGE BINARY.
49 VAR-TEXT PIC X9(8) USAGE DISPLAY.
01 City.
49 VAR-LEN PIC S9(4) USAGE BINARY.
49 VAR-TEXT PIC X9(2) USAGE DISPLAY.
01 Country
49 VAR-LEN PIC S9(4) USAGE BINARY.
49 VAR-TEXT PIC X9(32) USAGE DISPLAY.
01 Response.
49 VAR-LEN PIC S9(4) USAGE BINARY.
49 VAR-TEXT PIC X9(80) USAGE DISPLAY.
PERL DIVISION.
@a=(Lbzjoftt,Inqbujfodf, Hvcsjt); $b="Lbssz Wbmm" ;$b =~ y/b-z/a-z/ ; $c =
" Tif ". @a ." hsfbu wj" ."suvft pg b qsphsbnnfs" . ":\n";$c =~y/b-y/a-z/;
print"\n\n$c ";for($i=0; $i<@a; $i++) { $a[$i] =~ y/b-y/a-z/;if($a[$i]eq$a
[-1]){print"and $a[$i]." ;}else{ print"$a[i], "; }}print"\n\t\t--$b\n\n";

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Scott Lurndal]

jmfbahciv <See....@aol.com> writes:

>Networking peripherals is "slow". It takes tons of code to move
>one character from here to there. The HSCs were DEC's first
>peripheral using the networking concept.

I recognize that this is alt.folklore.computers, but
30 years ago is not now. Networking has improved since the
Hierarchical Storage Controllers. Considerably. By at
least three full orders of magnitude.

Everybody from IBM mainframes on down is using network-attached
storage (FICON, Fibrechannel at 8gb/s), 10GE (10gbits/sec),
40GE (40gbits/sec) and on the horizen 100GE fiber backbones.

And it doesn't take "tons" of code by any possible metric.

scott

[Scott Lurndal]

How can you choose the best language without an evaluation of the
alternatives? If you know nothing about the alternatives, how
can you possibly dismiss them out of hand?

COBOL on any non-ibm-mainframe server will use binary integer arithmetic,
the same as C.

scott

[nm...@cam.ac.uk]

In article <c1dd281b-ef4d-4896...@h17g2000yqe.googlegroups.com>,

<hanc...@bbs.cpcn.com> wrote:
>
>> As mentioned, I ran comparison tests of binary vs. packed decimal
>> fields. While it was a while ago, the result was that binary took
>> much longer to run than packed decimal.
>
>For the heck of it, I ran a rough quick test. Mainframe binary moves
>still take twice as long CPU time as decimal due to conversion. It
>appears the CVD and CVB are still relatively slow instructions.

Well, any serious optimising compiler wouldn't use either for
simple moves. But let's ignore that.

If you are using a language like Cobol, emulating decimal fixed-
point using integers, and operating on databases, you don't HAVE
a conversion cost! Addition, subtraction and comparison are likely
to be a little faster, even if you need to use two integers, in any
reasonably designed hardware (which, in this context, does not
include System/370, but it may have been improved). Multiplication
is likely to be much faster, and division vastly more so.

Rounding isn't an issue for addition, subtraction and comparison
and is simple for multiplication using either decimal fixed-point
or binary. And it is truly evil for division in either, because
you can bet that the rules you need to follow won't be any of the
ones the hardware provides.

So that leaves conversion to and from human-readable text. But
the cost there is dominated by unpicking the characters and
creating the formatted form. The hardware doesn't help at all
for the first, and ED/EDMK+CVD always used to be slower than doing
the job by hand - I don't know if it still is.

The arguments in favour of hardware support for decimal arithmetic,
whether fixed or floating, are bogus and have been for 40 years.
Sorry, but no more tactful statement is accurate.

On the other hand, the arguments that it's a disaster are also
bogus, and have been for as long.

The reasons that it's a bad idea are:
(a) it's a significant complication and increases the hardware,
compiler and library cost, as well as requiringmore power (i.e.
heat and lower battery life) on small CPUs, and
lot more power on small CPUs, and
(b) it deludes the naive into believing that it is more
accurate or reliable, which it isn't (it moves problems around
rather than actually eliminating any).


Regards,
Nick Maclaren.

[Scott Lurndal]

I do. I also pay attention to dividend payments, DRIP investments
(which are often denominated in very small fractions of a share),
municipal bond interest, corporate bond interest,
money market fund interest (what little there is these days) and so forth.

I enter them into a SQL database for tracking and run various queries
to validate the data against statements and for determining cost basis
for tax purposes.

You do realize that Money Market interest may be computed on a daily/weekly
basis while your statement comes monthly. A simple calculation on
either the starting or ending balance given a specific interest rate
may not be sufficient to match the daily calculations used by the fund
manager. For that matter, the interest rate may change several times
a month if it computed daily and is derived from the LIBOR, T-bills,
or the like.


"Money market accounts don't pay a fixed interest rate. That's because
the interest rate is based on the yield of the government and/or
corporate bonds held by the money market fund. These funds buy
and sell short-term bonds with maturities that are usually 90
days or less. Consequently, the fund's holdings are constantly
changing and so is the interest rate. Usually money market rates
are updated and interest is calculated and added to the account
balance on a weekly basis. "


scott

[Dan Espen]

Not fair to Perl, at least show the code indented:

@a=(Lbzjoftt,Inqbujfodf, Hvcsjt);
$b="Lbssz Wbmm" ;
$b =~ y/b-z/a-z/ ;
$c =" Tif ". @a ." hsfbu wj" ."suvft pg b qsphsbnnfs" . ":\n";
$c =~y/b-y/a-z/;
print "\n\n$c ";
for($i=0; $i<@a; $i++) {
$a[$i] =~ y/b-y/a-z/;

if($a[$i] eq $a[-1]) {

print "and $a[$i].";
} else {
print "$a[i], ";
}
}
print "\n\t\t--$b\n\n";

Then it becomes clear that this is intentionally
obfuscated code.

Now write the same code in COBOL and compare to Perl.

Hey, Perl isn't so bad after all!

--
Dan Espen

[Dan Espen]

And you know this how?

After Y2K most shops adopted date routines that give reasonable results.
I haven't seen any evidence that this has changed.

In fact one of our sign off items is that new or changed code handles
date transitions. We'll see how well that works about 90 years from now.


--
Dan Espen

[Quadibloc]

On Mar 12, 8:26 am, sc...@slp53.sl.home (Scott Lurndal) wrote:

> RAID systems have been around since the  80's.  They're not new.

Of course they're new. They didn't have them in 1969, back when men
were walking on the Moon, and the IBM System/360 Model 195 introduced
the powerful one-two punch of combining a cache with pipelining!

So they're extremely novel, coming long after such hallmarks of the
modern era as color television and the transistor.

John Savard

[Quadibloc]

On Mar 12, 8:34 am, n...@cam.ac.uk wrote:

>     (b) it deludes the naive into believing that it is more
> accurate or reliable, which it isn't (it moves problems around
> rather than actually eliminating any).

Hmm. I can see that as true in connection with decimal floating-point
used for the normal purpose of representing physical quantities; and
it's also true that an integer is an integer, no matter what base it's
in.

> (a) it's a significant complication and increases the hardware,
> compiler and library cost, as well as requiringmore power (i.e.
> heat and lower battery life) on small CPUs, and

I'm sorry, there's such a thing as a small CPU? I didn't know that
people were suggesting using decimal arithmetic on processors embedded
in automobiles or refrigerators.

Even smartphones these days use processors that look more like a
360/195 than anything else.

Decimal fixed-point arithmetic makes sense when used for its original
purpose: large-scale data-intensive systems where information is
stored in, or near, human-readable form, because it's mostly typed in
and printed out or displayed, with the occasional dash of calculation.

But somehow these occasional dashes still get to add up so that the
efficiency of decimal arithmetic versus converting both ways and then
doing a single multiply in between actually matters. That would assume
a lot of I/O capacity attached to one of those little microprocessors
- and I have to admit *that* sounds more like the '60s mainframe world
than any computer system today I can think of.

John Savard

[Shmuel Metz]

In <khmn51$5vs$1...@needham.csi.cam.ac.uk>, on 03/12/2013
at 07:57 AM, nm...@cam.ac.uk said:

>Provided that you didn't mind too much which patterns it actually
>recognised!

While regexen in perl are limited, they do have mechanisms for
controlling backtracking.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <khn5f4$un1$2...@dont-email.me>, on 03/12/2013
at 08:08 AM, Peter Flass <Peter...@Yahoo.com> said:

>Now *that's* bizarre.

Why is it bizarre to use the same peripherals for 18 bit, 30 bit and
36-bit machines? They're all multiples of six bits, and many
peripherals are character oriented. If you consider that bizarre, the
IBM 7000 series[1][2] all supported access to the 1301 disk drive and
7340 HyperTape, which were Basically 8-bit peripherals, even though
none of those machines had 8 bit characters.

[1] Except for the 7030, which used older devices

[2] 7010 - 6 bit characters
704x - 36 bit words
707x - 10 digir (sic) words
7080 - six bit characters
709x - 36 bit words

[Shmuel Metz]

In <uiktj81gfaopbleoa...@4ax.com>, on 03/12/2013
at 02:07 AM, Robert Wessel <robert...@yahoo.com> said:

>Disk yes, memory didn't drastically fall off the performance curve
>until the early 90s.

The reductions in core and semiconductor memory prices that I saw
through the 1990's certainly looked dramatic to me, as did the
improvements in speed.

[nm...@cam.ac.uk]

In article <3ddc1d86-c40b-443c...@j4g2000pbj.googlegroups.com>,

Quadibloc <jsa...@ecn.ab.ca> wrote:
>
>> (a) it's a significant complication and increases the hardware,
>> compiler and library cost, as well as requiringmore power (i.e.
>> heat and lower battery life) on small CPUs, and
>
>I'm sorry, there's such a thing as a small CPU? I didn't know that
>people were suggesting using decimal arithmetic on processors embedded
>in automobiles or refrigerators.

I can assure you that they are, or at least were!

>Even smartphones these days use processors that look more like a
>360/195 than anything else.

Precisely.

>Decimal fixed-point arithmetic makes sense when used for its original
>purpose: large-scale data-intensive systems where information is
>stored in, or near, human-readable form, because it's mostly typed in
>and printed out or displayed, with the occasional dash of calculation.
>
>But somehow these occasional dashes still get to add up so that the
>efficiency of decimal arithmetic versus converting both ways and then
>doing a single multiply in between actually matters. That would assume
>a lot of I/O capacity attached to one of those little microprocessors
>- and I have to admit *that* sounds more like the '60s mainframe world
>than any computer system today I can think of.

And I am pointing out that experience from the 1960s onwards shows
very clearly that using the fact that the time matters to prove
that decimal hardware is needed is a bogus argument.

The simple fact is that the systematic difference (if there is one)
is lost in the noise. Furthermore, micro-timing individual
operations is not a reliable indication of the effect on complete
applications. I have never seen a realistic comparison.

There have been a zillion successful, efficient Cobol compilers
that emulated decimal fixed-point, but their existence is swept
under the carpet by the pro-hardware brigade. It's bizarre.


Regards,
Nick Maclaren.

[nm...@cam.ac.uk]

In article <513f36b7$5$fuzhry+tra$mr2...@news.patriot.net>,

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>
>>Provided that you didn't mind too much which patterns it actually
>>recognised!
>
>While regexen in perl are limited, they do have mechanisms for
>controlling backtracking.

That's irrelevant. Take another look at the parts of my posting
you snipped.


Regards,
Nick Maclaren.

[Scott Lurndal]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>In <uiktj81gfaopbleoa...@4ax.com>, on 03/12/2013
> at 02:07 AM, Robert Wessel <robert...@yahoo.com> said:
>
>>Disk yes, memory didn't drastically fall off the performance curve
>>until the early 90s.
>
>The reductions in core and semiconductor memory prices that I saw
>through the 1990's certainly looked dramatic to me, as did the
>improvements in speed.
>

DIMM "Load-to-Use" _latency_ hasn't improved much. It's still in the
60-200ns range, depending on system design.

Memory bandwidth (or bandpass as burroughs called it) has
indeed improved with each generation of DRAM (SDR, DDR, DDR2, DDR3 and
now DDR4).

DDR4 is designed for peak transfer rates of 2133 million transfers/second,
with a bump to 4266 later this year or early next (17GByte/sec - 34Gbyte/sec).

DDR3 offers data rates of 800 - 2133 MT/second (6.4GByte/sec - 17GBytes/sec).

s

[Scott Lurndal]

Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On Tue, 12 Mar 2013 08:32:15 -0400

Burroughs COBOL9 (COBOL-68) had "ENTER SYMBOLIC" and "ENTER COBOL" verbs:

FUN DIVISION.
MOVE CORRESPONDING RECORD1 TO RECORD2.
ENTER SYMBOLIC.
MVW RECORD1, RECORD2 <--- Assembler code.
ENTER COBOL.
MOVE RECORD3 TO PRINTER.
STOP RUN.

They were removed from COBOL-74.

scott

[hanc...@bbs.cpcn.com]

On Mar 12, 10:34 am, n...@cam.ac.uk wrote:
> In article <c1dd281b-ef4d-4896-a63c-

> >For the heck of it, I ran a rough quick test.  Mainframe binary moves
> >still take twice as long CPU time as decimal due to conversion.  It
> >appears the CVD and CVB are still relatively slow instructions.
>
> Well, any serious optimising compiler wouldn't use either for
> simple moves.  But let's ignore that.

Would you know what IBM mainframe instructions are generated from
COBOL for a move from a display field to a binary field?

Thanks.

[nm...@cam.ac.uk]

In article <6c56db0f-0c83-4be8...@m12g2000yqp.googlegroups.com>,

<hanc...@bbs.cpcn.com> wrote:
>
>> >For the heck of it, I ran a rough quick test. Mainframe binary moves
>> >still take twice as long CPU time as decimal due to conversion. It
>> >appears the CVD and CVB are still relatively slow instructions.
>>
>> Well, any serious optimising compiler wouldn't use either for
>> simple moves. But let's ignore that.
>
>Would you know what IBM mainframe instructions are generated from
>COBOL for a move from a display field to a binary field?

I could make a damn good guess, but my experience dates from a while
back. And the most obviously first question is "What sort of display
and 'binary' fields?" The latter isn't a Cobol concept that was
much used in my day, as there was a collection of COMPUTATIONAL-x
fields of varying properties.

However, in both hardware and most programming language terms, that's
a conversion and not a simple move. All of the points I made stand
unchanged - that is not something that is often done when operating
on databases, but only when reading or writing human-readable
data.


Regards,
Nick Maclaren.

[Ahem A Rivet's Shot]

Yeah I know - I'm one of those who believe in writing readable
Perl - I was just trying to maximise the culture shock aspect of it.

> Then it becomes clear that this is intentionally
> obfuscated code.
>
> Now write the same code in COBOL and compare to Perl.
>
> Hey, Perl isn't so bad after all!

Oh I'd much rather read well written Perl than COBOL.

[Dan Espen]

Sadly I'm not sure I have access to a working COBOL compiler,
but I do have Enterprise PL/I.

Strangely:

DCL BIN_F FIXED BIN(31);
DCL CHAR_F CHAR(9) INIT ('123456789');
...
BIN_F = CHAR_F;

The assignment, statement "38" with OPT(3) generates:

000038 | LA r0,_Dsc_000002(,r4,16)
000038 | LA r5,BIN_F(,r13,208)
000038 | LA r14,CHAR_F(,r13,212)
000038 | L r15,=V(IBMQHCAA)(,r3,24)
000038 | LA r1,#MX_TEMP1(,r13,152)
000038 | ST r0,#MX_TEMP1(,r13,160)
000038 | LA r0,+CONSTANT_AREA(,r6,24)
000038 | ST r0,#MX_TEMP1(,r13,156)
000038 | LA r0,+CONSTANT_AREA(,r6,72)
000038 | ST r14,#MX_TEMP1(,r13,152)
000038 | ST r5,#MX_TEMP1(,r13,164)
000038 | ST r0,#MX_TEMP1(,r13,168)
000038 | BASR r14,r15

Not sure why this needs a subroutine call, perhaps there's
some error checking?

Packed decimal does better:

DCL DEC_F DEC FIXED(9,0) INIT(123456789);
...
BIN_F = DEC_F;

000040 | ZAP #pd755_1(8,r13,384),DEC_F(5,r13,224)
000040 | CVB r0,#pd755_1(,r13,384)
000040 | ST r0,BIN_F(,r13,208)



--
Dan Espen

[Stephen Fuld]

On 3/12/2013 7:34 AM, Scott Lurndal wrote:

snip

> COBOL on any non-ibm-mainframe server will use binary integer arithmetic,
> the same as C.

Probably true, except perhaps for Power servers where IBM implemented
decimal floating point.

But there are two points here, which I think are getting conflated.

One is what the hardware supports. It is clear that decimal floating
point can be emulated with binary integers at some cost. People seem to
disagree about which is faster, but that is am empirical question and
probably varies by system, usage, etc.

The second question is ease of use of decimal arithmetic in various
languages. No question that doing this is easier in COBOL than C, as in
COBOL, the compiler takes care of all the decimal point
adjustment/rounding for you, weather it is done by the hardware in
binary or decimal. In C the programmer has to do that in his/her code.

This is related to Roberts(?) earlier statement about the Computer
Science people ignoring the needs of the business programmer leading to
the continued use of COBOL.




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[Patrick Scheible]

Ahem A Rivet's Shot <ste...@eircom.net> writes:

Best laugh of the day.

-- Patrick

[Ahem A Rivet's Shot]

Well the TCP/IP stack is not a *small* amount of code, but yes
networking has long since stopped being a performance issue. I recall in
the mid 90s being surprised to discover that the storage I was using to run
compiles on was actually in Chicago while the workstation I was using was
in Phoenix - I was using that storage because it was *faster* than the disc
in the box I was using. Apparently the sites were linked by multiple ganged
T3 connections and the storage was mapped out of a large high performance
RAID, I suspect the limiting factor was the 100Mbps fast ethernet on the
workstation.