| Re: Fwd: Linux on a small memory PC [message #415503 is a reply to message #415330] |
Mon, 25 July 2022 00:23   |
|
|
Originally posted by: 25B.Z959
On 7/20/22 1:16 PM, Charlie Gibbs wrote:
> On 2022-07-20, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> COBOL IME was generally written by teams of coders after the analysts
>> had written the specification, to strict coding standards which if not
>> adhered to got you the sack.
>
> I once wrote some programs in a shop where I was given specs that were
> so detailed that I could probably have written a compiler for them.
> Unfortunately, I identified a number of cases that the specs didn't cover.
> When I asked about this, I was given the answer which is now at the top
> of my list of Famous Last Words: "Oh, don't worry about that - it'll
> never happen." Since I had enough experience by this time to know that
> "never" is usually about six months, I refused to proceed until all
> cases were accounted for. Beware of nasal demons!
The Bosses NEVER really understand what they're asking
for. That's not their function. They are task-masters,
not sages. THEIR bosses are even MORE oblivious, and
vengeful.
GET OUT of such establishments as FAST as possible even
IF it means less money. At least you'll still have your
pride and soul.
As I've said - what started as a Good Thing very quickly
became 'Dilbert' once Big Corporate got involved.
I always have this vision of a young Van Gogh getting a
steady job at "Popular Art (Amsterdam) Inc" ............
> As for coding standards, this shop's standards were so inefficient
> that it would take a job half an hour just to schedule, let alone run.
> I threw their precious standards into the trash can and wrote the system
> my way, which scheduled and ran in 30 seconds. When I was met with
> the predictable howls of anguish, I told them that I wanted to get things
> tested in a reasonable amount of time, and if they really wanted their
> standards that badly they could change it back when I was done.
> I doubt they ever did.
"Procedure" gives the Bosses an excuse for their paychecks.
Doing things fast and efficiently cuts them out - makes them
look as useless as they really are.
I was always able to find smaller outfits where Fast,
Efficient and Creative was coveted and appreciated.
I could identify Needs they didn't know existed and
act on them. The checks weren't quite as big - but ....
|
|
|
|
| Re: COBOL and tricks [message #415505 is a reply to message #415273] |
Mon, 25 July 2022 01:02 |
|
|
Originally posted by: 25B.Z959
On 7/19/22 8:27 PM, Charlie Gibbs wrote:
> On 2022-07-19, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> These days, of course, we’re awash in memory and it’s not worth doing
>> a lot of work to save a few bytes; not like the old days.
>
> In _The Mythical Man-Month_, Fred Brooks describes the decision to save
> 100 bytes by not having the date routine handle leap years.
Well, it's only wrong 25% of the time ... :-)
And hey, depending on the era and hardware, 100 bytes
MIGHT be critical.
Program micro-controllers ? I've done a number of apps
for them. You DO have to cut corners. 64-128 BYTES of RAM,
1k to 4K of EEPROM (or UV-Erase PROM) if you were lucky.
I still have a fondness for the PIC12-xxx series - 8-pin
wonders. Forget 'C' - go all ASM. ATMELs or AVRs might be
a little better these days. PIC32s - supercomputers ! :-)
Anyway, the bosses/taskmasters have to justify their
existence/paychecks ..... stupid decisions that SOUND
good gets them that. THEIR bosses are 10x MORE
oblivious - buzzword driven, dazzled by cost/profit
projection charts ...
CorpComp - it's all 'Dilbert' now. No wonder Winders
sucks - indeed is a National Security Threat.
Still have my UV-C box for erasing "JW" PIC chips.
That smell of ozone and NOx......
|
|
|
|
| Re: COBOL and tricks [message #415506 is a reply to message #415474] |
Mon, 25 July 2022 01:36 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-24, 25B.Z959 <25B.Z959@nada.net> wrote:
> FORTRAN is still pretty widely used also, esp in academic
> and engineering environments, mostly due to the huge volume
> of proven hard-core math routines which nobody wants to
> re-write.
Many rivals, with the benefit of hindsight, have crossed
swords with the old workhorse! Yet FORTRAN gallops on,
warts and all, more transportable than syphilis, fired
by a bottomless pit of working subprograms.
-- Stan Kelly-Bootle: The Devil's DP Dictionary
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415507 is a reply to message #415503] |
Mon, 25 July 2022 01:45 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-25, 25B.Z959 <25B.Z959@nada.net> wrote:
> I was always able to find smaller outfits where Fast,
> Efficient and Creative was coveted and appreciated.
> I could identify Needs they didn't know existed and
> act on them. The checks weren't quite as big - but ....
I've always gravitated toward smaller outfits . When I left $BIGCORP
for a smaller one, the hiring personnel director was baffled that
I would come to a job that paid less. But I got my sanity back,
and since the new establishment was closer to home, I saved $200
per month on gas plus a lot of commute time.
(Ten years later that outfit went Dilbert too, but that's another story.)
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: COBOL and tricks [message #415516 is a reply to message #415501] |
Mon, 25 July 2022 06:56 |
|
|
Originally posted by: Jack Strangio
"25B.Z959" <25B.Z959@nada.net> writes:
>
> Heh heh .... yea, we all get sick of writing out
> long "descriptive names" and "self documenting"
> code. Something about it just grates on the soul,
> impedes the creative impulse.
>
I was probably a bit different from most people in that I went from BASIC to
COBOL within a very short period of time back in the 1980s.
I still have some source files from that time.I have no idea what the BASIC
programs were doing and, more the point, *how* they did it. When you get lines
like:
740 !#H9 TAB(10),C$," ",E$,A$,TAB(22),D$,A$,E$
745 K7$=" "+D$+"M"+A$+E$\ WRITE#5,K7$\!">>>",K7$,"<"
750 GOTO460
760 READ#1%L,&X
770 M5=(X+O+1)
780 A=A7(M5)\B=B7(M5)
790 A$=A7$(2*M5-1,2*M5)
800 B$=B7$(10*M5-9,10*M5)
810 B$=B$(1,(B8(M5)))
820 RETURN
and then find COBOL lines like this:
0352 NEW-ORDER.
0353 DISPLAY SCREEN-CLEAR LINE-FEEDS LINE-FEEDS.
0354 PERFORM TYPE-CUST.
0355
0356 MOVE " * ORDER FROM " TO PAPER-TYPE.
0357 MOVE CUST-NAME TO ORGANISATION-D.
0358 MOVE CUST-CODE TO WHO.
0359 MOVE MONTH-S TO WHEN-MONTH.
0360 MOVE YEAR-S TO WHEN-YEAR.
0361 OPEN OUTPUT ORDER-FILE.
0362 MOVE HEADER-TYPE TO HEADER-TYPE-D.
0363 MOVE " * O/No " TO FORM-TYPE.
0364 PERFORM NEW-ORD-1.
it's easy to know which language's source-code I prefer to read after not
seeing them for years.
Jack
--
Why do meteorites always land in craters?
|
|
|
|
| Re: COBOL and tricks [message #415517 is a reply to message #415465] |
Mon, 25 July 2022 07:37 |
|
|
Originally posted by: Johnny Billquist
On 2022-07-24 00:23, Peter Flass wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> Sometimes that IS a factor ... you have to have people who
>> can write it. But 1990 ... IMHO it should have been 'C'.
>>
>
> IMNSHO, COBOL. C is a terrible language for those types of language.
Things
> that are so dimple in COBOL, like moving a character string with blank
> fill, or formatting numeric output, requires calling subroutines in
C, and
> lack of length checking on string moves is a recipe for disaster.
This is one of the weirder arguments I've ever seen:
"requires calling a subroutine in C". As if that somehow is a problem?
Not to mention it's a function, and not a subroutine. Any claim of "used
the language quite a bit" sounds hollow after that.
A statement to move a character string in COBOL will in the end be a
subroutine call as well.
And lack of length checking depends on the function. Nothing prevents
you from using strncpy in C. Or write your own, with whatever
characteristic you want. It will actually be pretty efficient.
Comparable to the provided functions.
> I have used both languages quite a bit, perhaps COBOL more, years
ago, but
> neither is my preferred language, so I have no dog in this fight.
> …
Seems like your C is both rusty and bad.
>> Mostly I like "terse" languages - less typing and lots
>> of room left over for comments at the ends of the lines.
>
> Sounds like assembler ;-)
>
> It’s too easy to write tricky code with side-effects in C. COBOL
might not
> be as self-documenting as advertised, but the operation of each statement
> is pretty obvious and easily understood.
What kind of side effects are we talking about? The operation of each
statement in C is very obvious and easy to understand.
Most people get into trouble because of memory handling. Not the
language semantics.
But that is where you get to the point where things gets even harder to
even do in COBOL. And if you manage to do it, it won't be easily understood.
Johnny
|
|
|
|
| Re: COBOL and tricks [message #415519 is a reply to message #415501] |
Mon, 25 July 2022 08:54 |
|
|
Originally posted by: Allodoxaphobia
On Mon, 25 Jul 2022 00:02:14 -0400, 25B.Z959 wrote:
> On 7/24/22 4:13 PM, Kerr-Mudd, John wrote:
>> On 23 Jul 2022 23:50:45 GMT
>> Allodoxaphobia <trepidation@example.net> wrote:
>>
>>> On Sat, 23 Jul 2022 19:32:03 -0000 (UTC), Lew Pitcher wrote:
>>>>
>>>> This development occurred in a large (1000+ branch) banking environment.
>>>> When we got specs from the users, they were along the lines of
>>>> you MULTIPLY the ACCOUNT BALANCE by the MONTHLY INTEREST RATE,
>>>> giving the INTEREST ADJUSTMENT.
>>>> you then ADD the INTEREST ADJUSTMENT to the ACCOUNT BALANCE,
>>>> giving the ADJUSTED ACCOUNT BALANCE.
>>>> which a programmer might convert into
>>>> MULTIPLY ACCOUNT-BALANCE BY MONTHLY-INTEREST-RATE GIVING INTEREST-ADJUSTMENT.
>>>> ADD INTEREST-ADJUSTMENT TO ACCOUNT-BALANCE GIVING ADJUSTED-ACCOUNT-BALANCE.
>>>>
>>>> The convenience was that the user's description /was/ the program code.
>>>
>>> Good luck finding white collar droids
>>> now-a-days that can write that clearly!
>>
>> Even in those days it might have been
>>
>> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>> SET OFILE-ADJACCTBAL = IFILE-ACCTBAL + 0800-INTADJ
>>
>> or somesuch "standard"
>
> Heh heh .... yea, we all get sick of writing out
> long "descriptive names" and "self documenting"
> code. Something about it just grates on the soul,
> impedes the creative impulse.
I can envision change requests and new development requirements
being *text'ed* into the programming departments these days.
Jonesy
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm
|
|
|
|
| Re: COBOL and tricks [message #415520 is a reply to message #415499] |
Mon, 25 July 2022 09:52 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
drb@ihatespam.msu.edu (Dennis Boone) writes:
>> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>
> More like
>
> MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
>
> or
>
> COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
>
> De
Or,
1150-CK-TIME.
IF KLINGONS > 0
ACCEPT WS-TIME FROM TIME
MOVE WS-MIN OF WS-TIME TO DS-MIN
PERFORM 1145-CK-FLAG THRU 1145-EXIT
MOVE WS-SEC OF WS-TIME TO DS-SEC
MOVE DS-TABLE TO S-DATE
ELSE
GO TO 1150-EXIT.
COMPUTE T-STORE = DS-DATE - S-DATE.
IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
MOVE 14 TO MAX-NO
COMPUTE W = ((HQ2 - 1) * 14)
COMPUTE Z = ((HQ1 - 1) * 14)
INSPECT MASTER-TBL REPLACING ALL "K" BY " "
MOVE 0 TO RX
PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
MOVE 1 TO ATTACK-FLAG
PERFORM 5900-TRANS THRU 5900-EXIT
IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
DISPLAY "WARNING - STAR DATE: " S-DATE
DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
IF NOT TOO-LATE
MOVE DS-DATE TO WS-DATE.
IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
- E
MOVE 1 TO TOO-LATE-FLAG
ADD 230 TO WS-DATE
ELSE
IF S-DATE > WS-DATE
MOVE 1 TO INDICATE-X
PERFORM 8200-CK-DONE THRU 8200-EXIT.
1150-EXIT. EXIT.
:-)
|
|
|
|
| Re: COBOL and tricks [message #415521 is a reply to message #415517] |
Mon, 25 July 2022 10:13 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> writes:
> On 2022-07-24 00:23, Peter Flass wrote:
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> Sometimes that IS a factor ... you have to have people who
>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>
>>
>> IMNSHO, COBOL. C is a terrible language for those types of language.
> Things
>> that are so dimple in COBOL, like moving a character string with blank
>> fill, or formatting numeric output, requires calling subroutines in
> C, and
>> lack of length checking on string moves is a recipe for disaster.
> This is one of the weirder arguments I've ever seen:
> "requires calling a subroutine in C". As if that somehow is a problem?
> Not to mention it's a function, and not a subroutine. Any claim of "used
> the language quite a bit" sounds hollow after that.
I suspect the poster was indicating that COBOL will generate the call
under the covers, while in C the programmer must code the call explicitly.
>
> A statement to move a character string in COBOL will in the end be a
> subroutine call as well.
Not on all systems, for example:
INSPECT COURSE-B REPLACING ALL " " BY ZEROS. 531 CARD 1 65864
01 065864 MVN 110607 000774 100008 CODE
01 065882 SEA 39B101 400000 600000 050384 CODE
01 065906 NEQ 25 0C065962 CODE
01 065916 MVA 10A202 F0F0F0 400000 CODE
01 065934 INC 01A107 200000 100008 CODE
01 065952 BUN 27 0C065882 CODE
or
MOVE "THIS IS A TEST" TO TEST-STRING. 235 CARD 1 109910
01 109910 MVA 101420 211148 213500 CODE
MVN -> Move numeric (moves 1 to 100 digits or zoned-digit bytes, truncating or padding)
MVA -> Move alpha (moves 1 to 100 bytes, truncating or padding the receiving field)
SEA -> Search memory (in this case, for the single byte EBCDIC space (0x40) character).
NEQ -> Branch if SEA didn't find search string.
INC -> Increment receiving field (by 2 in this case)
BUN -> Branch unconditionally.
|
|
|
|
| Re: COBOL and tricks [message #415535 is a reply to message #415520] |
Mon, 25 July 2022 15:57 |
Harry Vaderchi
Messages: 719
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 25 Jul 2022 13:52:19 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> drb@ihatespam.msu.edu (Dennis Boone) writes:
>>> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>>
>> More like
>>
>> MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
>>
>> or
>>
>> COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
>>
>> De
>
> Or,
>
> 1150-CK-TIME.
> IF KLINGONS > 0
> ACCEPT WS-TIME FROM TIME
> MOVE WS-MIN OF WS-TIME TO DS-MIN
> PERFORM 1145-CK-FLAG THRU 1145-EXIT
> MOVE WS-SEC OF WS-TIME TO DS-SEC
> MOVE DS-TABLE TO S-DATE
> ELSE
> GO TO 1150-EXIT.
> COMPUTE T-STORE = DS-DATE - S-DATE.
> IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
> MOVE 14 TO MAX-NO
> COMPUTE W = ((HQ2 - 1) * 14)
> COMPUTE Z = ((HQ1 - 1) * 14)
> INSPECT MASTER-TBL REPLACING ALL "K" BY " "
> MOVE 0 TO RX
> PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
> VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
> MOVE 1 TO ATTACK-FLAG
> PERFORM 5900-TRANS THRU 5900-EXIT
> IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
> DISPLAY "WARNING - STAR DATE: " S-DATE
> DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
> DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
> DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
> IF NOT TOO-LATE
> MOVE DS-DATE TO WS-DATE.
> IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
> - E
> MOVE 1 TO TOO-LATE-FLAG
> ADD 230 TO WS-DATE
> ELSE
> IF S-DATE > WS-DATE
> MOVE 1 TO INDICATE-X
> PERFORM 8200-CK-DONE THRU 8200-EXIT.
> 1150-EXIT. EXIT.
>
> :-)
That'd be about right!
--
Bah, and indeed Humbug.
|
|
|
|
| Re: COBOL and tricks [message #415539 is a reply to message #415502] |
Mon, 25 July 2022 16:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/23/22 6:23 PM, Peter Flass wrote:
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>>> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>>>
>>>> > On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>> >> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>> >>
>>>> >>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> >>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>> >>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> >> [snip]
>>>> >>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>> >>>>>> during the 60s by the guys with skinny ties. They work
>>>> >>>>>> very well, they're too expensive to re-do, so ....
>>>> >>>>>>
>>>> >>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>> >>>>>> there somewhere ... but money's so tight these days
>>>> >>>>>> and so many of those legacy apps are so super-critical
>>>> >>>>>> that they just can't/won't.
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> Maybe these are better than translators I have seen, but old ones produced
>>>> >>>>> unreadable code, and they might well miss some litte tricks that the old
>>>> >>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>> >>>>> expensive, but a lot better, is to extract the specs from the existing
>>>> >>>>> code, and there are re-engineering programs that can probably do a lot of
>>>> >>>>> that work, and then rewrite in the new language using programmers skilled
>>>> >>>>> in that language.
>>>> >>>>>
>>>> >>>>>
>>>> >>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>> >>>> language is 'do it by the book, and write the book as documentation, as
>>>> >>>> well'
>>>> >>>>
>>>> >>>
>>>> >>> How much would you like to bet? Yes, the language encourages
>>>> >>> straightforward programming, but I’ve seen things…
>>>> >>
>>>> >> A long time ago, I worked on many COBOL applications, including a
>>>> >> client (PC) / server (MVS) communications application. I've seen
>>>> >> things that I cannot unsee, coded things that I cannot uncode.
>>>> >
>>>> >
>>>> > Got any of it on a floppy or print-out anywhere ? I'd
>>>> > love to see how to do client/server only using COBOL.
>>>>
>>>> Both client and server used the same COBOL codebase, but with
>>>> different compilers and operating environments.
>>>>
>>>> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>>>> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>>>> (terminal communications) connection.
>>>>
>>>> The server was coded in IBM COBOL and ran under IMS DC on an MVS
>>>> system, using an SNA terminal LU as it's communications endpoint.
>>>>
>>>> As this was an in-house "inner platform" project (3 tier client/server
>>>> architecture, circa 1990), I did not keep personal copies of any
>>>> of the code. Suffice it to say that my first question to the architect,
>>>> my first day on that project, was "Why COBOL?" The answer was "Because
>>>> that's what the coders know."
>>>
>>>
>>> Sometimes that IS a factor ... you have to have people who
>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>
>>
>> IMNSHO, COBOL. C is a terrible language for those types of language. Things
>> that are so dimple in COBOL, like moving a character string with blank
>> fill, or formatting numeric output, requires calling subroutines in C, and
>> lack of length checking on string moves is a recipe for disaster.
>>
>> I have used both languages quite a bit, perhaps COBOL more, years ago, but
>> neither is my preferred language, so I have no dog in this fight.
>
>
> Sorry, I like 'C' - and have writ little functions, MY way,
> to do a lot of the things you were talking about.
>
> Only ASM gives you more control - and I've done my share of
> that over the years too.
>
>>
>>>
>>> Mostly I like "terse" languages - less typing and lots
>>> of room left over for comments at the ends of the lines.
>>
>> Sounds like assembler ;-)
>
>
> YES ! :-)
>
> ASM ... MMmmmmmmm !
>
>
>> It’s too easy to write tricky code with side-effects in C. COBOL might not
>> be as self-documenting as advertised, but the operation of each statement
>> is pretty obvious and easily understood.
>
> So ... COBOL is for BAD PROGRAMMERS who can't foresee
> downstream consequences hmmm ??? ;-)
>
No, COBOL is for the NEXT poor bastard who has to look at your code and
try to figure out what the heck you were trying to do. The more “concise” a
language is, the more write-only it tends to be.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415540 is a reply to message #415505] |
Mon, 25 July 2022 16:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/19/22 8:27 PM, Charlie Gibbs wrote:
>> On 2022-07-19, Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> These days, of course, we’re awash in memory and it’s not worth doing
>>> a lot of work to save a few bytes; not like the old days.
>>
>> In _The Mythical Man-Month_, Fred Brooks describes the decision to save
>> 100 bytes by not having the date routine handle leap years.
>
> Well, it's only wrong 25% of the time ... :-)
Not really, because the operator had to set the date and time at each IPL,
and many shops IPLed often enough that it wasn’t a problem. We used to IPL
every night at the end of third shift.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415541 is a reply to message #415520] |
Mon, 25 July 2022 16:56 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> drb@ihatespam.msu.edu (Dennis Boone) writes:
>>> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>>
>> More like
>>
>> MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
>>
>> or
>>
>> COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
>>
>> De
>
> Or,
>
> 1150-CK-TIME.
> IF KLINGONS > 0
> ACCEPT WS-TIME FROM TIME
> MOVE WS-MIN OF WS-TIME TO DS-MIN
> PERFORM 1145-CK-FLAG THRU 1145-EXIT
> MOVE WS-SEC OF WS-TIME TO DS-SEC
> MOVE DS-TABLE TO S-DATE
> ELSE
> GO TO 1150-EXIT.
> COMPUTE T-STORE = DS-DATE - S-DATE.
> IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
> MOVE 14 TO MAX-NO
> COMPUTE W = ((HQ2 - 1) * 14)
> COMPUTE Z = ((HQ1 - 1) * 14)
> INSPECT MASTER-TBL REPLACING ALL "K" BY " "
> MOVE 0 TO RX
> PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
> VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
> MOVE 1 TO ATTACK-FLAG
> PERFORM 5900-TRANS THRU 5900-EXIT
> IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
> DISPLAY "WARNING - STAR DATE: " S-DATE
> DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
> DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
> DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
> IF NOT TOO-LATE
> MOVE DS-DATE TO WS-DATE.
> IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
> - E
> MOVE 1 TO TOO-LATE-FLAG
> ADD 230 TO WS-DATE
> ELSE
> IF S-DATE > WS-DATE
> MOVE 1 TO INDICATE-X
> PERFORM 8200-CK-DONE THRU 8200-EXIT.
> 1150-EXIT. EXIT.
>
> :-)
>
If I had a programmer working for me who coded like that,be having a talk.
I HAVE seen code like that, usually written by someone who thought
programming was beneath him and was bored. Such people were usually
promoted to management, where they fit right in.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415542 is a reply to message #415516] |
Mon, 25 July 2022 16:57 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Jack Strangio <jackstrangio@yahoo.com> wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>>
>> Heh heh .... yea, we all get sick of writing out
>> long "descriptive names" and "self documenting"
>> code. Something about it just grates on the soul,
>> impedes the creative impulse.
>>
> I was probably a bit different from most people in that I went from BASIC to
> COBOL within a very short period of time back in the 1980s.
>
> I still have some source files from that time.I have no idea what the BASIC
> programs were doing and, more the point, *how* they did it. When you get lines
> like:
>
> 740 !#H9 TAB(10),C$," ",E$,A$,TAB(22),D$,A$,E$
> 745 K7$=" "+D$+"M"+A$+E$\ WRITE#5,K7$\!">>>",K7$,"<"
> 750 GOTO460
> 760 READ#1%L,&X
> 770 M5=(X+O+1)
> 780 A=A7(M5)\B=B7(M5)
> 790 A$=A7$(2*M5-1,2*M5)
> 800 B$=B7$(10*M5-9,10*M5)
> 810 B$=B$(1,(B8(M5)))
> 820 RETURN
>
> and then find COBOL lines like this:
>
> 0352 NEW-ORDER.
> 0353 DISPLAY SCREEN-CLEAR LINE-FEEDS LINE-FEEDS.
> 0354 PERFORM TYPE-CUST.
> 0355
> 0356 MOVE " * ORDER FROM " TO PAPER-TYPE.
> 0357 MOVE CUST-NAME TO ORGANISATION-D.
> 0358 MOVE CUST-CODE TO WHO.
> 0359 MOVE MONTH-S TO WHEN-MONTH.
> 0360 MOVE YEAR-S TO WHEN-YEAR.
> 0361 OPEN OUTPUT ORDER-FILE.
> 0362 MOVE HEADER-TYPE TO HEADER-TYPE-D.
> 0363 MOVE " * O/No " TO FORM-TYPE.
> 0364 PERFORM NEW-ORD-1.
>
>
> it's easy to know which language's source-code I prefer to read after not
> seeing them for years.
>
>
> Jack
>
>
+1
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415543 is a reply to message #415541] |
Mon, 25 July 2022 17:45 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> drb@ihatespam.msu.edu (Dennis Boone) writes:
>>>> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>>>
>>> More like
>>>
>>> MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
>>>
>>> or
>>>
>>> COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
>>>
>>> De
>>
>> Or,
>>
>> 1150-CK-TIME.
>> IF KLINGONS > 0
>> ACCEPT WS-TIME FROM TIME
>> MOVE WS-MIN OF WS-TIME TO DS-MIN
>> PERFORM 1145-CK-FLAG THRU 1145-EXIT
>> MOVE WS-SEC OF WS-TIME TO DS-SEC
>> MOVE DS-TABLE TO S-DATE
>> ELSE
>> GO TO 1150-EXIT.
>> COMPUTE T-STORE = DS-DATE - S-DATE.
>> IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
>> MOVE 14 TO MAX-NO
>> COMPUTE W = ((HQ2 - 1) * 14)
>> COMPUTE Z = ((HQ1 - 1) * 14)
>> INSPECT MASTER-TBL REPLACING ALL "K" BY " "
>> MOVE 0 TO RX
>> PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
>> VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
>> MOVE 1 TO ATTACK-FLAG
>> PERFORM 5900-TRANS THRU 5900-EXIT
>> IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
>> DISPLAY "WARNING - STAR DATE: " S-DATE
>> DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
>> DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
>> DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
>> IF NOT TOO-LATE
>> MOVE DS-DATE TO WS-DATE.
>> IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
>> - E
>> MOVE 1 TO TOO-LATE-FLAG
>> ADD 230 TO WS-DATE
>> ELSE
>> IF S-DATE > WS-DATE
>> MOVE 1 TO INDICATE-X
>> PERFORM 8200-CK-DONE THRU 8200-EXIT.
>> 1150-EXIT. EXIT.
>>
>> :-)
>>
>
> If I had a programmer working for me who coded like that,be having a talk.
> I HAVE seen code like that, usually written by someone who thought
> programming was beneath him and was bored. Such people were usually
> promoted to management, where they fit right in.
>
Speak to Kurt.
IDENTIFICATION DIVISION.
PROGRAM-ID. STREK.
AUTHOR. KURT WILHELM.
INSTALLATION. OAKLAND UNIVERSITY.
DATE-WRITTEN. COMPLETED SEPTEMBER 1, 1979.
*
*******************************************************
* STAR_TREK SIMULATES AN OUTER SPACE ADVENTURE GAME *
* ON A REMOTE TERMINAL. THE USER COMMANDS THE U.S.S. *
* ENTERPRISE, AND THRU VARIOUS OFFENSIVE AND DEFEN- *
* SIVE COMMANDS, TRAVELS THROUGHOUT THE GALAXY ON A *
* MISSION TO DESTROY ALL KLINGONS, WHICH ALSO MANEU- *
* VER AND FIRE ON THE ENTERPRISE. *
*******************************************************
|
|
|
|
| Re: COBOL and tricks [message #415545 is a reply to message #415540] |
Mon, 25 July 2022 18:52 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-25, Peter Flass <peter_flass@yahoo.com> wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/19/22 8:27 PM, Charlie Gibbs wrote:
>>
>>> On 2022-07-19, Peter Flass <peter_flass@yahoo.com> wrote:
>>>
>>>> These days, of course, we’re awash in memory and it’s not worth doing
>>>> a lot of work to save a few bytes; not like the old days.
>>>
>>> In _The Mythical Man-Month_, Fred Brooks describes the decision to save
>>> 100 bytes by not having the date routine handle leap years.
>>
>> Well, it's only wrong 25% of the time ... :-)
>
> Not really, because the operator had to set the date and time at each IPL,
> and many shops IPLed often enough that it wasn’t a problem. We used to IPL
> every night at the end of third shift.
Ah yes, the good old days before computers had battery-backed time-of-day
clocks (or anything to set them from). One of the trade rags ran an ad
that showed a teaspoonful of ICs, accompanied by the statement: "Soon
you'll have an IBM 3090 in your wristwatch!" Someone quipped: "Yeah,
you'll boot MVS on it and the first thing it'll do is ask you the time."
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: COBOL and tricks [message #415546 is a reply to message #415539] |
Mon, 25 July 2022 18:52 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-25, Peter Flass <peter_flass@yahoo.com> wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/23/22 6:23 PM, Peter Flass wrote:
>>
>>> It’s too easy to write tricky code with side-effects in C. COBOL might not
>>> be as self-documenting as advertised, but the operation of each statement
>>> is pretty obvious and easily understood.
>>
>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>> downstream consequences hmmm ??? ;-)
>
> No, COBOL is for the NEXT poor bastard who has to look at your code and
> try to figure out what the heck you were trying to do. The more “concise” a
> language is, the more write-only it tends to be.
I've cleaned up some pretty horrid COBOL code. Overly-verbose and
convoluted code can be just as bad as something overly concise.
A sufficiently determined programmer can write unreadable code
in any language. Convoluted code with no comments is even worse.
Convoluted code with outdated, incorrect comments is worse still.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: COBOL and tricks [message #415548 is a reply to message #415541] |
Mon, 25 July 2022 19:27 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> drb@ihatespam.msu.edu (Dennis Boone) writes:
>>>> SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>>>
>>> More like
>>>
>>> MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
>>>
>>> or
>>>
>>> COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
>>>
>>> De
>>
>> Or,
>>
>> 1150-CK-TIME.
>> IF KLINGONS > 0
>> ACCEPT WS-TIME FROM TIME
>> MOVE WS-MIN OF WS-TIME TO DS-MIN
>> PERFORM 1145-CK-FLAG THRU 1145-EXIT
>> MOVE WS-SEC OF WS-TIME TO DS-SEC
>> MOVE DS-TABLE TO S-DATE
>> ELSE
>> GO TO 1150-EXIT.
>> COMPUTE T-STORE = DS-DATE - S-DATE.
>> IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
>> MOVE 14 TO MAX-NO
>> COMPUTE W = ((HQ2 - 1) * 14)
>> COMPUTE Z = ((HQ1 - 1) * 14)
>> INSPECT MASTER-TBL REPLACING ALL "K" BY " "
>> MOVE 0 TO RX
>> PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
>> VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
>> MOVE 1 TO ATTACK-FLAG
>> PERFORM 5900-TRANS THRU 5900-EXIT
>> IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
>> DISPLAY "WARNING - STAR DATE: " S-DATE
>> DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
>> DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
>> DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
>> IF NOT TOO-LATE
>> MOVE DS-DATE TO WS-DATE.
>> IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
>> - E
>> MOVE 1 TO TOO-LATE-FLAG
>> ADD 230 TO WS-DATE
>> ELSE
>> IF S-DATE > WS-DATE
>> MOVE 1 TO INDICATE-X
>> PERFORM 8200-CK-DONE THRU 8200-EXIT.
>> 1150-EXIT. EXIT.
>>
>> :-)
>>
>
> If I had a programmer working for me who coded like that,be having a talk.
> I HAVE seen code like that, usually written by someone who thought
> programming was beneath him and was bored. Such people were usually
> promoted to management, where they fit right in.
Being a game, I'm not surprised. Business code would not look like that.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415549 is a reply to message #415517] |
Mon, 25 July 2022 19:42 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> writes:
> On 2022-07-24 00:23, Peter Flass wrote:
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>> Sometimes that IS a factor ... you have to have people who
>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>
>>
>> IMNSHO, COBOL. C is a terrible language for those types of
> language. Things
>> that are so dimple in COBOL, like moving a character string with blank
>> fill, or formatting numeric output, requires calling subroutines in
> C, and
>> lack of length checking on string moves is a recipe for disaster.
> This is one of the weirder arguments I've ever seen:
> "requires calling a subroutine in C". As if that somehow is a problem?
> Not to mention it's a function, and not a subroutine. Any claim of
> "used the language quite a bit" sounds hollow after that.
>
> A statement to move a character string in COBOL will in the end be a
> subroutine call as well.
And why do you think that?
I've sure seen lots of COBOL MOVE instructions generate a single
hardware instruction.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415559 is a reply to message #415543] |
Mon, 25 July 2022 21:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> drb@ihatespam.msu.edu (Dennis Boone) writes:
>>>> > SET 0800-INTADJ = IFILE-ACCTBAL * MIR
>>>>
>>>> More like
>>>>
>>>> MULTIPLY IFILE-ACCTBAL BY MIR GIVING 0800-INTADJ.
>>>>
>>>> or
>>>>
>>>> COMPUTE 0800-INTADJ = IFILE-ACCTBAL * MIR.
>>>>
>>>> De
>>>
>>> Or,
>>>
>>> 1150-CK-TIME.
>>> IF KLINGONS > 0
>>> ACCEPT WS-TIME FROM TIME
>>> MOVE WS-MIN OF WS-TIME TO DS-MIN
>>> PERFORM 1145-CK-FLAG THRU 1145-EXIT
>>> MOVE WS-SEC OF WS-TIME TO DS-SEC
>>> MOVE DS-TABLE TO S-DATE
>>> ELSE
>>> GO TO 1150-EXIT.
>>> COMPUTE T-STORE = DS-DATE - S-DATE.
>>> IF T-STORE < 90 AND NOT KLINGONS-ATTACKING
>>> MOVE 14 TO MAX-NO
>>> COMPUTE W = ((HQ2 - 1) * 14)
>>> COMPUTE Z = ((HQ1 - 1) * 14)
>>> INSPECT MASTER-TBL REPLACING ALL "K" BY " "
>>> MOVE 0 TO RX
>>> PERFORM 1170-MOVE-ON-HQ THRU 1170-EXIT
>>> VARYING KCTR FROM 1 BY 1 UNTIL KCTR > KLINGONS
>>> MOVE 1 TO ATTACK-FLAG
>>> PERFORM 5900-TRANS THRU 5900-EXIT
>>> IF (Q1 NOT = HQ1 OR Q2 NOT = HQ2)
>>> DISPLAY "WARNING - STAR DATE: " S-DATE
>>> DISPLAY "SCIENCE OFFICER SPOCK ADVISES"
>>> DISPLAY "YOU NAVIGATE TO QUADRANT " HQ1 "," HQ2
>>> DISPLAY "TO DEFEND STAR FLEET HEADQUARTERS".
>>> IF NOT TOO-LATE
>>> MOVE DS-DATE TO WS-DATE.
>>> IF S-DATE > WS-DATE AND Q1 = HQ1 AND Q2 = HQ2 AND NOT TOO-LAT
>>> - E
>>> MOVE 1 TO TOO-LATE-FLAG
>>> ADD 230 TO WS-DATE
>>> ELSE
>>> IF S-DATE > WS-DATE
>>> MOVE 1 TO INDICATE-X
>>> PERFORM 8200-CK-DONE THRU 8200-EXIT.
>>> 1150-EXIT. EXIT.
>>>
>>> :-)
>>>
>>
>> If I had a programmer working for me who coded like that,be having a talk.
>> I HAVE seen code like that, usually written by someone who thought
>> programming was beneath him and was bored. Such people were usually
>> promoted to management, where they fit right in.
>>
>
> Speak to Kurt.
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. STREK.
> AUTHOR. KURT WILHELM.
> INSTALLATION. OAKLAND UNIVERSITY.
> DATE-WRITTEN. COMPLETED SEPTEMBER 1, 1979.
> *
> *******************************************************
> * STAR_TREK SIMULATES AN OUTER SPACE ADVENTURE GAME *
> * ON A REMOTE TERMINAL. THE USER COMMANDS THE U.S.S. *
> * ENTERPRISE, AND THRU VARIOUS OFFENSIVE AND DEFEN- *
> * SIVE COMMANDS, TRAVELS THROUGHOUT THE GALAXY ON A *
> * MISSION TO DESTROY ALL KLINGONS, WHICH ALSO MANEU- *
> * VER AND FIRE ON THE ENTERPRISE. *
> *******************************************************
>
>
Well, in that case naming a variable klingons makes perfect sense. Maybe
not in a payroll program.
--
Pete
|
|
|
|
| Re: COBOL and tricks [message #415562 is a reply to message #415506] |
Tue, 26 July 2022 01:11 |
|
|
Originally posted by: 25B.Z959
On 7/25/22 1:36 AM, Charlie Gibbs wrote:
> On 2022-07-24, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> FORTRAN is still pretty widely used also, esp in academic
>> and engineering environments, mostly due to the huge volume
>> of proven hard-core math routines which nobody wants to
>> re-write.
>
> Many rivals, with the benefit of hindsight, have crossed
> swords with the old workhorse! Yet FORTRAN gallops on,
> warts and all, more transportable than syphilis, fired
> by a bottomless pit of working subprograms.
> -- Stan Kelly-Bootle: The Devil's DP Dictionary
>
Fully agree ... NOBODY wants to re-invent it - and
those subs are LONG-PROVEN while replacements would
not be able to make such a claim.
People design buildings, bridges, aircraft, nuclear
reactors, with FORTRAN code. Who would RISK doing
so with 'translations' that might have subtle 'pentium
bugs' within ???
Besides, it's not THAT bad of a language - not too
difficult (except for output formatting). Very
straight-up, not many cryptic symbols or such. Not
a zillion brackets or lambda statements. If you can
program a modern BASIC you can program FORTRAN
real quick. I hadn't touched it in like 40 years and
wrote a nice handy library of useful string and numeric
crap I use in almost every program - within 48 lazy hours.
Then I wrote a utility that translates text-based data
records into a couple of other forms you can more easily
import into common databases. Sure, COULD have wrote that
in Python or 'C' or Pascal ... but ....... :-)
The "modern" design where stuff doesn't have to be
in EXACT locations on the "punch card" DOES make it
all much nicer.
|
|
|
|
| Re: COBOL and tricks [message #415563 is a reply to message #415539] |
Tue, 26 July 2022 01:28 |
|
|
Originally posted by: 25B.Z959
On 7/25/22 4:55 PM, Peter Flass wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/23/22 6:23 PM, Peter Flass wrote:
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>>> > On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>>> >
>>>> >> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>> >>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>> >>>
>>>> >>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> >>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>> >>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> >>> [snip]
>>>> >>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>> >>>>>>> during the 60s by the guys with skinny ties. They work
>>>> >>>>>>> very well, they're too expensive to re-do, so ....
>>>> >>>>>>>
>>>> >>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>> >>>>>>> there somewhere ... but money's so tight these days
>>>> >>>>>>> and so many of those legacy apps are so super-critical
>>>> >>>>>>> that they just can't/won't.
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>> >>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>> >>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>> >>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>> >>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>> >>>>>> that work, and then rewrite in the new language using programmers skilled
>>>> >>>>>> in that language.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>> >>>>> language is 'do it by the book, and write the book as documentation, as
>>>> >>>>> well'
>>>> >>>>>
>>>> >>>>
>>>> >>>> How much would you like to bet? Yes, the language encourages
>>>> >>>> straightforward programming, but I’ve seen things…
>>>> >>>
>>>> >>> A long time ago, I worked on many COBOL applications, including a
>>>> >>> client (PC) / server (MVS) communications application. I've seen
>>>> >>> things that I cannot unsee, coded things that I cannot uncode.
>>>> >>
>>>> >>
>>>> >> Got any of it on a floppy or print-out anywhere ? I'd
>>>> >> love to see how to do client/server only using COBOL.
>>>> >
>>>> > Both client and server used the same COBOL codebase, but with
>>>> > different compilers and operating environments.
>>>> >
>>>> > The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>>>> > and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>>>> > (terminal communications) connection.
>>>> >
>>>> > The server was coded in IBM COBOL and ran under IMS DC on an MVS
>>>> > system, using an SNA terminal LU as it's communications endpoint.
>>>> >
>>>> > As this was an in-house "inner platform" project (3 tier client/server
>>>> > architecture, circa 1990), I did not keep personal copies of any
>>>> > of the code. Suffice it to say that my first question to the architect,
>>>> > my first day on that project, was "Why COBOL?" The answer was "Because
>>>> > that's what the coders know."
>>>>
>>>>
>>>> Sometimes that IS a factor ... you have to have people who
>>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>>
>>>
>>> IMNSHO, COBOL. C is a terrible language for those types of language. Things
>>> that are so dimple in COBOL, like moving a character string with blank
>>> fill, or formatting numeric output, requires calling subroutines in C, and
>>> lack of length checking on string moves is a recipe for disaster.
>>>
>>> I have used both languages quite a bit, perhaps COBOL more, years ago, but
>>> neither is my preferred language, so I have no dog in this fight.
>>
>>
>> Sorry, I like 'C' - and have writ little functions, MY way,
>> to do a lot of the things you were talking about.
>>
>> Only ASM gives you more control - and I've done my share of
>> that over the years too.
>>
>>>
>>>>
>>>> Mostly I like "terse" languages - less typing and lots
>>>> of room left over for comments at the ends of the lines.
>>>
>>> Sounds like assembler ;-)
>>
>>
>> YES ! :-)
>>
>> ASM ... MMmmmmmmm !
>>
>>
>>> It’s too easy to write tricky code with side-effects in C. COBOL might not
>>> be as self-documenting as advertised, but the operation of each statement
>>> is pretty obvious and easily understood.
>>
>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>> downstream consequences hmmm ??? ;-)
>>
>
> No, COBOL is for the NEXT poor bastard who has to look at your code and
> try to figure out what the heck you were trying to do. The more “concise” a
> language is, the more write-only it tends to be.
THAT'S why 60-75% of my programs are expository COMMENTS
and little TUTORIALS. YOU can EXPLAIN the code a LOT
better than any code can explain itself.
Even my ASM ... every line has a comment, an ongoing
narrative of what's happening and why. Based on that
you could translate it into a dozen higher-level
languages.
And then I see "examples" with 200 lines of 'C' or
whatever with like THREE cryptic comments. The rest
is apparently all Magic ....
|
|
|
|
| Re: COBOL and tricks [message #415564 is a reply to message #415546] |
Tue, 26 July 2022 01:35 |
|
|
Originally posted by: 25B.Z959
On 7/25/22 6:52 PM, Charlie Gibbs wrote:
> On 2022-07-25, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> On 7/23/22 6:23 PM, Peter Flass wrote:
>>>
>>>> It’s too easy to write tricky code with side-effects in C. COBOL might not
>>>> be as self-documenting as advertised, but the operation of each statement
>>>> is pretty obvious and easily understood.
>>>
>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>> downstream consequences hmmm ??? ;-)
>>
>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>> try to figure out what the heck you were trying to do. The more “concise” a
>> language is, the more write-only it tends to be.
>
> I've cleaned up some pretty horrid COBOL code. Overly-verbose and
> convoluted code can be just as bad as something overly concise.
I would not even begin to deny that Truth.
> A sufficiently determined programmer can write unreadable code
> in any language. Convoluted code with no comments is even worse.
> Convoluted code with outdated, incorrect comments is worse still.
SOME do it INTENTIONALLY - "job security" or pure ego
perhaps.
Hey, there's always Brainfuck .......
The vast bulk of my code is COMMENTS, lucid explanations,
an ongoing narrative of every step. No code can document
itself better than the programmer can whether it's ASM or
COBOL or LISP or whatever bizarre paradigm. Might take one
line, or 50, to explain what's going on and why.
|
|
|
|
| Re: COBOL and tricks [message #415565 is a reply to message #415562] |
Tue, 26 July 2022 02:13 |
|
|
Originally posted by: maus
On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/25/22 1:36 AM, Charlie Gibbs wrote:
>> On 2022-07-24, 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> FORTRAN is still pretty widely used also, esp in academic
>>> and engineering environments, mostly due to the huge volume
>>> of proven hard-core math routines which nobody wants to
>>> re-write.
>>
>> Many rivals, with the benefit of hindsight, have crossed
>> swords with the old workhorse! Yet FORTRAN gallops on,
>> warts and all, more transportable than syphilis, fired
>> by a bottomless pit of working subprograms.
>> -- Stan Kelly-Bootle: The Devil's DP Dictionary
>>
>
> Fully agree ... NOBODY wants to re-invent it - and
> those subs are LONG-PROVEN while replacements would
> not be able to make such a claim.
>
> in EXACT locations on the "punch card" DOES make it
> all much nicer.
++
--
greymausg@mail.com
"Are you sure that you can live on your investments after retirement?
If not, send us all your money."
|
|
|
|
| Re: Fwd: Linux on a small memory PC [message #415567 is a reply to message #415507] |
Tue, 26 July 2022 02:46 |
|
|
Originally posted by: 25B.Z959
On 7/25/22 1:45 AM, Charlie Gibbs wrote:
> On 2022-07-25, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> I was always able to find smaller outfits where Fast,
>> Efficient and Creative was coveted and appreciated.
>> I could identify Needs they didn't know existed and
>> act on them. The checks weren't quite as big - but ....
>
> I've always gravitated toward smaller outfits . When I left $BIGCORP
> for a smaller one, the hiring personnel director was baffled that
> I would come to a job that paid less. But I got my sanity back,
> and since the new establishment was closer to home, I saved $200
> per month on gas plus a lot of commute time.
>
> (Ten years later that outfit went Dilbert too, but that's another story.)
They all go Dilbert, must be a human/corporate-nature thing,
after awhile ... migrate to start-ups with exotic needs. That
keeps it interesting. I haven't felt like I was *WORKING A
JOB* in 40 years.
One of the bosses saw a Digital Signage example - and wanted
one ... but I couldn't find a decent cheap/free example. So
I wrote one in Python. Then I re-wrote it it Laz/FPC even
better and snappier and more capable. Runs on a rPI
velcro-ed to a Big Screen - you can even take it off
premises, web interface, assemble/arrange yer slide deck.
Some very bad/redundant PHP/HTML involved. FUN !
The mechanic wanted a working maint program - which
was PROMISED by a company as part of a larger package
TWO YEARS AGO and there's no sign of it. A few days
with Laz/FPC and he's got a flexible GUI app that
uses a PICK-style ascii-delimited multivalue database.
FUN ! Then the FORTRAN utility that can translate it
into several formats easy to eventually import into
several kinds of databases. FUN !
I've always loved making exotic dataloggers - micro-controllers
and hand-wired boards, unique sensors. Programming Meets Real
World. Admittedly devices like HOBO loggers can do a lot with
micro-power - and teeny little chips only robots can deal with -
but they tend to be oriented around a handful of "standard"
measurements/methods. What if you need something "different" ?
Well, you MAKE IT YOURSELF. (go with the SEEED LiPo/Solar
chargers, they hold the right output voltage regardless of
solar influx) How do you get +/- 2mm accuracy out of distance
sensors rated for +/- 10mm accuracy ? FUN !
Admittedly, I'm a fan of the immortal Steve Ciarcia who always
said his favorite programming language was "Solder". Amazing
what you can accomplish with a few parts and logic gates ...
stuff even affordable DSP chips will suffer to do ... and
there weren't any DSP chips for most of my career.
Consider eyes - they are little brains unto themselves. They
prep, qualify, quantify, format, "DSP", comment, the raw
input all by themselves before sending the condensed study
on to the brain. A very smart peripheral that makes the
main system MUCH more efficient and responsive.
And I got six figures, insurance and a retirement plan and
occasional peer awards for all this fun :-)
Smaller CAN be bigger. Find a niche you can LOVE.
But if you just HAVE to have the biggest mini-mansion
on the block and $125,000 matched Hiz/Herz SUVs and
the gigantic loan payments that come with it ... well ...
you may have to *WORK A HATEFUL JOB* for pointy-haired
bosses ... sorry .........
|
|
|
|
| Re: COBOL and tricks [message #415568 is a reply to message #415549] |
Tue, 26 July 2022 04:48 |
|
|
Originally posted by: Johnny Billquist
On 2022-07-26 01:42, Dan Espen wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>
>> On 2022-07-24 00:23, Peter Flass wrote:
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> Sometimes that IS a factor ... you have to have people who
>>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>>
>>>
>>> IMNSHO, COBOL. C is a terrible language for those types of
>> language. Things
>>> that are so dimple in COBOL, like moving a character string with blank
>>> fill, or formatting numeric output, requires calling subroutines in
>> C, and
>>> lack of length checking on string moves is a recipe for disaster.
>> This is one of the weirder arguments I've ever seen:
>> "requires calling a subroutine in C". As if that somehow is a problem?
>> Not to mention it's a function, and not a subroutine. Any claim of
>> "used the language quite a bit" sounds hollow after that.
>>
>> A statement to move a character string in COBOL will in the end be a
>> subroutine call as well.
>
> And why do you think that?
>
> I've sure seen lots of COBOL MOVE instructions generate a single
> hardware instruction.
Depends on the compiler and hardware, and so on...
Which actually leads to the point that the same is true in C.
You might think you are calling a function like strncpy(). And you are,
on an abstract level. However, modern C compilers understands what this
is, and will in fact insert the required code directly in the
instruction stream, which, again depending on the hardware, might end up
being a single instruction.
So in which way was COBOL better than C? In the end, claiming
superiority of a language based on that one have a function, while the
other have it as a statement is about as silly an argument as I have
ever seen. And all the extra claims to support that view are even sillier.
Johnny
|
|
|
|
| Re: COBOL and tricks [message #415569 is a reply to message #415568] |
Tue, 26 July 2022 05:40 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 26/07/2022 09:48, Johnny Billquist wrote:
> On 2022-07-26 01:42, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> > Sometimes that IS a factor ... you have to have people who
>>>> > can write it. But 1990 ... IMHO it should have been 'C'.
>>>> >
>>>>
>>>> IMNSHO, COBOL. C is a terrible language for those types of
>>> language. Things
>>>> that are so dimple in COBOL, like moving a character string with
>>>> blank
>>>> fill, or formatting numeric output, requires calling subroutines in
>>> C, and
>>>> lack of length checking on string moves is a recipe for disaster.
>>> This is one of the weirder arguments I've ever seen:
>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>> Not to mention it's a function, and not a subroutine. Any claim of
>>> "used the language quite a bit" sounds hollow after that.
>>>
>>> A statement to move a character string in COBOL will in the end be a
>>> subroutine call as well.
>>
>> And why do you think that?
>>
>> I've sure seen lots of COBOL MOVE instructions generate a single
>> hardware instruction.
>
> Depends on the compiler and hardware, and so on...
> Which actually leads to the point that the same is true in C.
> You might think you are calling a function like strncpy(). And you are,
> on an abstract level. However, modern C compilers understands what this
> is, and will in fact insert the required code directly in the
> instruction stream, which, again depending on the hardware, might end up
> being a single instruction.
>
> So in which way was COBOL better than C? In the end, claiming
> superiority of a language based on that one have a function, while the
> other have it as a statement is about as silly an argument as I have
> ever seen. And all the extra claims to support that view are even sillier.
>
> Johnny
Value judgements depend on ones ethical standpoint.
COBOL allowed teams of relatively untechnical people to create and
maintain large programs in a disciplined way. It allowed efficient use
of limited memory and good control over formatted printouts.
Its downside was massively large source code, and inability to get close
to the bare metal.
C is the exact opposite, terse, machine level assembler but faster
coded. It exactly suits a technically aware person who knows exactly
what they are doing and is capable of minding his on Ps and Qs.
Yer pays yer money...
--
Climate Change: Socialism wearing a lab coat.
|
|
|
|
| Re: COBOL and tricks [message #415570 is a reply to message #415568] |
Tue, 26 July 2022 07:44 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> writes:
> On 2022-07-26 01:42, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> > Sometimes that IS a factor ... you have to have people who
>>>> > can write it. But 1990 ... IMHO it should have been 'C'.
>>>> >
>>>>
>>>> IMNSHO, COBOL. C is a terrible language for those types of
>>> language. Things
>>>> that are so dimple in COBOL, like moving a character string with blank
>>>> fill, or formatting numeric output, requires calling subroutines in
>>> C, and
>>>> lack of length checking on string moves is a recipe for disaster.
>>> This is one of the weirder arguments I've ever seen:
>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>> Not to mention it's a function, and not a subroutine. Any claim of
>>> "used the language quite a bit" sounds hollow after that.
>>>
>>> A statement to move a character string in COBOL will in the end be a
>>> subroutine call as well.
>> And why do you think that?
>> I've sure seen lots of COBOL MOVE instructions generate a single
>> hardware instruction.
>
> Depends on the compiler and hardware, and so on...
> Which actually leads to the point that the same is true in C.
> You might think you are calling a function like strncpy(). And you
> are, on an abstract level. However, modern C compilers understands
> what this is, and will in fact insert the required code directly in
> the instruction stream, which, again depending on the hardware, might
> end up being a single instruction.
>
> So in which way was COBOL better than C? In the end, claiming
> superiority of a language based on that one have a function, while the
> other have it as a statement is about as silly an argument as I have
> ever seen. And all the extra claims to support that view are even
> sillier.
This is all true, an IBM mainframe C compiler CAN generate a single
instruction for a memcpy or strncpy. Providing the compiler can tell
the length of the move at compile time. Something that is a lot more
likely for COBOL than C.
For IBM mainframes the COBOL compiler is going to be way more efficient
than C because the COBOL compiler is way more likely to be using packed
decimal.
--
Dan Espen
|
|
|
|
| Re: COBOL and tricks [message #415571 is a reply to message #415569] |
Tue, 26 July 2022 09:13 |
Arne Luft
Messages: 321
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
The Natural Philosopher <tnp@invalid.invalid> writes:
> C is the exact opposite, terse, machine level assembler but faster
> coded.
“Assembler” is a terrible mental model for C.
richard@sfere:~/junk$ cat t.c
int f(int *ptr) {
int r = *ptr;
if(!ptr)
return 0;
return r;
}
richard@sfere:~/junk$ gcc -O2 -c t.c && objdump -dMintel t.o
t.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <f>:
0: 8b 07 mov eax,DWORD PTR [rdi]
2: c3 ret
If C really was some kind of ‘portable assembler’, the compiler would
preserve the test of ptr even though it follows the indirect read.
In C as actually specified, the compiler is free to remove it, and
compilers do just that.
In a user space application this mistake just leads to a crash; in the
Linux kernel a variant of it lead to CVE-2009-1897.
--
https://www.greenend.org.uk/rjk/
|
|
|
|
| Re: COBOL and tricks [message #415574 is a reply to message #415571] |
Tue, 26 July 2022 10:10 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 26 Jul 2022 14:13:56 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> C is the exact opposite, terse, machine level assembler but faster
>> coded.
>
> “Assembler” is a terrible mental model for C.
>
> richard@sfere:~/junk$ cat t.c
> int f(int *ptr) {
> int r = *ptr;
If ptr is 0 this is undefined behaviour aka probably SEGV.
> if(!ptr)
Did you mean !*ptr ?
> return 0;
> return r;
Or is it counting on ptr not really being followed until here ?
> Disassembly of section .text:
>
> 0000000000000000 <f>:
> 0: 8b 07 mov eax,DWORD PTR [rdi]
> 2: c3 ret
That would be consistent with optimising out a test for *ptr
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
|
|
|
|
| Re: COBOL and tricks [message #415575 is a reply to message #415574] |
Tue, 26 July 2022 10:41 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> writes:
> On Tue, 26 Jul 2022 14:13:56 +0100
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> C is the exact opposite, terse, machine level assembler but faster
>>> coded.
>>
>> “Assembler” is a terrible mental model for C.
>>
>> richard@sfere:~/junk$ cat t.c
>> int f(int *ptr) {
>> int r = *ptr;
>
> If ptr is 0 this is undefined behaviour aka probably SEGV.
To be fair, this was an actual example from the linux kernel a few
years ago.
|
|
|
|
| Re: COBOL and tricks [message #415576 is a reply to message #415574] |
Tue, 26 July 2022 10:52 |
Arne Luft
Messages: 321
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> C is the exact opposite, terse, machine level assembler but faster
>>> coded.
>>
>> “Assembler” is a terrible mental model for C.
>>
>> richard@sfere:~/junk$ cat t.c
>> int f(int *ptr) {
>> int r = *ptr;
>
> If ptr is 0 this is undefined behaviour aka probably SEGV.
Please see the remarks you snipped. If *ptr faults then the likely
outcome is a crash; but in some environments that does not happen.
>> if(!ptr)
>
> Did you mean !*ptr ?
No, I did not.
>> return 0;
>> return r;
>
> Or is it counting on ptr not really being followed until here ?
No, the code is buggy (the indirection and the test are the wrong way
around). But it’s a bug that happened in real life and the outcome is
not someone working with the ‘portable assembler’ mental model of C
would expect.
>> Disassembly of section .text:
>>
>> 0000000000000000 <f>:
>> 0: 8b 07 mov eax,DWORD PTR [rdi]
>> 2: c3 ret
>
> That would be consistent with optimising out a test for *ptr
Sure, but that’s not the test found in the source. It has optimized out
the if(!ptr) return 0.
--
https://www.greenend.org.uk/rjk/
|
|
|
|
| Re: COBOL and tricks [message #415577 is a reply to message #415571] |
Tue, 26 July 2022 11:12 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 26/07/2022 14:13, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> C is the exact opposite, terse, machine level assembler but faster
>> coded.
>
> “Assembler” is a terrible mental model for C.
>
> richard@sfere:~/junk$ cat t.c
> int f(int *ptr) {
> int r = *ptr;
> if(!ptr)
> return 0;
> return r;
> }
> richard@sfere:~/junk$ gcc -O2 -c t.c && objdump -dMintel t.o
>
> t.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <f>:
> 0: 8b 07 mov eax,DWORD PTR [rdi]
> 2: c3 ret
>
> If C really was some kind of ‘portable assembler’, the compiler would
> preserve the test of ptr even though it follows the indirect read.
Well C when I learnt it would have done just that. Today its full of
SmartShit™ because computer scientists got their hands on it and tried
to second guess what you really meant rather than what you actually wrote.
And that example is precisely the sort of coding that wasn't done by
someone who knew what they were doing
int f(int *ptr)
{
return(ptr? *ptr:0);
}
Is clearer and absolutely implies the ptr needs to be tested in order to
determine the result.
And it avoids trying to access the contents of a null pointer, which
might cause issues
>
> In C as actually specified, the compiler is free to remove it, and
> compilers do just that.
>
I don't see why. The return value is conditional on the test of ptr.
To me that looks like bad code and a compiler bug
> In a user space application this mistake just leads to a crash; in the
> Linux kernel a variant of it lead to CVE-2009-1897.
>
Whoever wrote that code needs sacking, You do not reference memory
pointers that may be null.
Nor should a compiler assume that if a pointer has been referenced it is
therefore not null.
--
The lifetime of any political organisation is about three years before
its been subverted by the people it tried to warn you about.
Anon.
|
|
|
|
| Re: COBOL and tricks [message #415578 is a reply to message #415576] |
Tue, 26 July 2022 11:20 |
The Natural Philosoph
Messages: 238
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 26/07/2022 15:52, Richard Kettlewell wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>> C is the exact opposite, terse, machine level assembler but faster
>>>> coded.
>>>
>>> “Assembler” is a terrible mental model for C.
>>>
>>> richard@sfere:~/junk$ cat t.c
>>> int f(int *ptr) {
>>> int r = *ptr;
>>
>> If ptr is 0 this is undefined behaviour aka probably SEGV.
>
> Please see the remarks you snipped. If *ptr faults then the likely
> outcome is a crash; but in some environments that does not happen.
>
>>> if(!ptr)
>>
>> Did you mean !*ptr ?
>
> No, I did not.
>
>>> return 0;
>>> return r;
>>
>> Or is it counting on ptr not really being followed until here ?
>
> No, the code is buggy (the indirection and the test are the wrong way
> around). But it’s a bug that happened in real life and the outcome is
> not someone working with the ‘portable assembler’ mental model of C
> would expect.
Once you introduce a bug and have a buggy compiler, that's exactly what
you do expect.
Carrying a mental model in assembler, what that code is , is to lead the
contents of a reference which may be null, then test if the reference is
actually null, and pass that reference contents or null back.
At assembly level that is pure nonsense. There is no point in testing a
pointer for null if you have already referenced it.
The fact that you have been able to reference it without a segfault
shows it is probably not null.
So the first point is that the actual code is crap. Written by someone
who didn't know what they were doing.
The second point is that the compiler is certainly behaving in a
questionable manner too.
--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain
|
|
|
|
| Re: COBOL and tricks [message #415580 is a reply to message #415578] |
Tue, 26 July 2022 11:48 |
|
|
Originally posted by: Pancho
On 26/07/2022 16:20, The Natural Philosopher wrote:
> On 26/07/2022 15:52, Richard Kettlewell wrote:
>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>> > C is the exact opposite, terse, machine level assembler but faster
>>>> > coded.
>>>>
>>>> “Assembler” is a terrible mental model for C.
>>>>
>>>> richard@sfere:~/junk$ cat t.c
>>>> int f(int *ptr) {
>>>> int r = *ptr;
>>>
>>> If ptr is 0 this is undefined behaviour aka probably SEGV.
>>
>> Please see the remarks you snipped. If *ptr faults then the likely
>> outcome is a crash; but in some environments that does not happen.
>>
>>>> if(!ptr)
>>>
>>> Did you mean !*ptr ?
>>
>> No, I did not.
>>
>>>> return 0;
>>>> return r;
>>>
>>> Or is it counting on ptr not really being followed until here ?
>>
>> No, the code is buggy (the indirection and the test are the wrong way
>> around). But it’s a bug that happened in real life and the outcome is
>> not someone working with the ‘portable assembler’ mental model of C
>> would expect.
>
> Once you introduce a bug and have a buggy compiler, that's exactly what
> you do expect.
>
> Carrying a mental model in assembler, what that code is , is to lead the
> contents of a reference which may be null, then test if the reference is
> actually null, and pass that reference contents or null back.
> At assembly level that is pure nonsense. There is no point in testing a
> pointer for null if you have already referenced it.
>
> The fact that you have been able to reference it without a segfault
> shows it is probably not null.
I think the point was that some OS (or is it CPU architecture) allows
you to read from the NULL memory address. I've no idea which one, but
presumably one does.
If the read from the NULL address throws a fault, then the C and
assembler will be equivalent.
> So the first point is that the actual code is crap. Written by someone
> who didn't know what they were doing.
> The second point is that the compiler is certainly behaving in a
> questionable manner too.
C says the operation is undefined. I don't use C. Just thinking about it
makes me feel queezy.
|
|
|
|
| Re: COBOL and tricks [message #415581 is a reply to message #415580] |
Tue, 26 July 2022 12:17 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Pancho <Pancho.Jones@proton.me> writes:
> On 26/07/2022 16:20, The Natural Philosopher wrote:
>> On 26/07/2022 15:52, Richard Kettlewell wrote:
>> The fact that you have been able to reference it without a segfault
>> shows it is probably not null.
>
> I think the point was that some OS (or is it CPU architecture) allows
> you to read from the NULL memory address. I've no idea which one, but
> presumably one does.
The legacy BSD operating systems marked page zero of the virtual address
space as READ-ONLY and initialized the entire page with zeros. Trying
to store through a NULL pointer would fault, but loads would return zero.
Took a fair amount of work to fix BSD utilities to work on System V due
to this.
For microcontrollers etc that don't have virtual memory, address zero
was always legal.
In early processors, there were often registers located in the first
page of memory (e.g. the autoincrement memory locations in the PDP-8).
|
|
|
|
| Re: COBOL and tricks [message #415591 is a reply to message #415577] |
Tue, 26 July 2022 12:53 |
|
|
Originally posted by: Andy Walker
On 26/07/2022 16:12, The Natural Philosopher wrote:
> Well C when I learnt it would have done just that. Today its full of
> SmartShit™ because computer scientists got their hands on it and
> tried to second guess what you really meant rather than what you
> actually wrote.
Actually, it's rather the opposite. If you switch on "-O2", the
compiler will assume that you mean what you wrote.
[Richard K]:
>> In C as actually specified, the compiler is free to remove it, and
>> compilers do just that.
> I don't see why. The return value is conditional on the test of ptr.
If "ptr" is 0, then the behaviour is undefined. So if your code
crashes and burns, you have no-one to blame but yourself.
> To me that looks like bad code
Certainly a bug. Characterising it as "bad code" is a step further.
There are worse programming sins than perpetrating a typo that should be
detected during testing. Including the sin of /not/ detecting it during
testing. But there are worse sins even than that.
> and a compiler bug
Not so. The compiler has simply assumed ["-O2", remember] that
you want your code to run as fast as possible. Once you invoke undefined
behaviour, anything that happens is fair game. Don't blame the compiler
for bugs in the program.
> Whoever wrote that code needs sacking, You do not reference memory
> pointers that may be null.
If every programmer who ever perpetrated a bug was sacked, there
would not be a single [useful] programmer in employment.
> Nor should a compiler assume that if a pointer has been referenced it
> is therefore not null.
Whether a compiler "should" assume that is a matter of opinion.
But the compiler is /entitled/ to assume that, because if it is null then
the behaviour on dereferencing was undefined, and it scarcely matters,
/except as a courtesy to the user/, whether the actual behaviour is to
print a message saying "Yah, boo, sucks, you dereferenced a null pointer"
and halt or simply to let the program continue on its merry way until
Something Bad happens.
If you need nice behaviour, then run your programs with compilers
that build in checks against illegal dereferencing, out-of-bounds indexing,
uninitialised variables, and so on. If you don't, then feel free to go for
optimisation that removes all the checks.
Of course, what sensible programmers do is to test their code
with checks switched on, and when satisfied switch them off. Even then,
we should remember Dijkstra; switching checks off in production code is
like using water wings when splashing around in the pool and discarding
them when swimming out to sea.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Bull
|
|
|
|
| Re: COBOL and tricks [message #415595 is a reply to message #415577] |
Tue, 26 July 2022 14:34 |
Arne Luft
Messages: 321
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
The Natural Philosopher <tnp@invalid.invalid> writes:
> On 26/07/2022 14:13, Richard Kettlewell wrote:
>> In C as actually specified, the compiler is free to remove it, and
>> compilers do just that.
>
> I don't see why. The return value is conditional on the test of ptr.
>
> To me that looks like bad code and a compiler bug
It’s not a compiler bug. It’s permitted by the language spec as it’s
stood for the last few decades.
>> In a user space application this mistake just leads to a crash; in the
>> Linux kernel a variant of it lead to CVE-2009-1897.
>
> Whoever wrote that code needs sacking, You do not reference memory
> pointers that may be null.
If you sacked every programmer who created a bug there’d be none
left. (Maybe not such a bad thing.) But you’re missing the point, which
is that the ‘assembler’ model you proposed for C doesn’t match reality.
--
https://www.greenend.org.uk/rjk/
|
|
|
|
| Re: COBOL and tricks [message #415596 is a reply to message #415563] |
Tue, 26 July 2022 15:38 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to 25B.Z959 <25B.Z959@nada.net>:
> Even my ASM ... every line has a comment, an ongoing
> narrative of what's happening and why. Based on that
> you could translate it into a dozen higher-level
> languages.
i += 2; // Add 1 to i.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: COBOL and tricks [message #415602 is a reply to message #415562] |
Tue, 26 July 2022 16:43 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:
> The "modern" design where stuff doesn't have to be
> in EXACT locations on the "punch card" DOES make it
> all much nicer.
On the other hand, fixed locations means you know exactly
where to look. Each method has its advantages and
disadvantages - although I admit that I've converted
to CSV for just about everything.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
Members
Search
Help
Register
Login
Home
