Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread Jackson, Rob
When I was in JHS we learned BASIC (and Pascal) with IBM BASICA on PS/2s 
(80286s with 20 MB HDDs).  The assignments required LET.

First Tennessee Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, April 26, 2018 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

[External Email]

On Thu, 26 Apr 2018 07:34:36 -0700, Phil Smith wrote:
>
>When you realized that
> DO25I=1,10
>defines the start of a loop, but
> DO25I=1.10
>is an assignment statement, you really wonder what about the FORTRAN compiler 
>parser! I'm sure it made sense at the time, and can see how it would be done, 
>but it still seems to me like a strange way to design a language.
>
Over a half century ago, a peer told me that FORTRAN, with a preliminary 
lexical scan, considered any statement with:
o an "=" not enclosed by parentheses, and o no "," outside all parentheses ... 
to be an assignment statement.  Anything else starts with a keyword.

A professor in the same era told his class that the oldest FORTRAN compiler 
parsed arithmetic expressions without using a stack.

Didn't oldest BASIC interpreters (or perhaps DEC's FOCAL) require that 
assignments be introduced by a keyword, "SET" or "LET"?  I never knew whether 
this was to simplify the parser or to aid novice (we all were) programmers' 
understanding tnat "=" meant assignment, not comparison.

Some DEC interpreters put assgnment targets on the right.  Some DEC shells put 
RENAME/COPY targets on the left (that's actually the better
way.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FIRST TENNESSEE

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread Chris Hoelscher
Of even older fortran

If x (100,200,300)

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Thursday, April 26, 2018 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] RECFM (was: IRS - 60-Year-Old IT System Failed ... )

And don't forget the (early):

5 = 3

which, in at least some compilers, would indeed make subsequent references to 
"5" use "3". I think that was considered a bug.

On Thu, Apr 26, 2018 at 11:26 AM, Binyamin Dissen < bdis...@dissensoftware.com> 
wrote:

> On Thu, 26 Apr 2018 07:34:36 -0700 Phil Smith  wrote:
>
> :>Binyamin Dissen wrote, in part:
> :>>And for the non-Fortran programmer
> :>>  DO 25  I  = 1,10
> :>>is identical to
> :>>  DO25I=1,10
> :>>but different than
> :>>  DO25I=1.10
>
> :>For the non-FORTRAN geeks who are wondering why anyone would ever 
> think the last is the same: NASA had a bug due to this. While often 
> blamed for the Mariner 1 failure, it seems that may not have been the 
> case after all, but it's still interesting. See 
> https://arstechnica.com/civis/
> viewtopic.php?t=862715
>
> :>When you realized that
> :> DO25I=1,10
> :>defines the start of a loop, but
> :> DO25I=1.10
> :>is an assignment statement, you really wonder what about the FORTRAN 
> compiler parser! I'm sure it made sense at the time, and can see how 
> it would be done, but it still seems to me like a strange way to 
> design a language.
>
> Unlike COBOL which required white space, Fortran completely ignored 
> white space. Also, COBOL has reserved words - Fortran does not.
>
> The first step in compiling was to squash the statement (while paying 
> special attention to FORMAT statements where you might have nnnH, 
> while recognizing that
>
> 30 FORMAT(I5,I10)=28
>
> is a valid assignment statement (as long a FORMAT was declared as an 
> array) while
>
> 30 FORMAT(I5,I10,6H =28) )
>
> is a Format statement
>
> --
> Binyamin Dissen  
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me, 
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems, 
> especially those from irresponsible companies.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them 
differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread zMan
And don't forget the (early):

5 = 3

which, in at least some compilers, would indeed make subsequent references
to "5" use "3". I think that was considered a bug.

On Thu, Apr 26, 2018 at 11:26 AM, Binyamin Dissen <
bdis...@dissensoftware.com> wrote:

> On Thu, 26 Apr 2018 07:34:36 -0700 Phil Smith  wrote:
>
> :>Binyamin Dissen wrote, in part:
> :>>And for the non-Fortran programmer
> :>>  DO 25  I  = 1,10
> :>>is identical to
> :>>  DO25I=1,10
> :>>but different than
> :>>  DO25I=1.10
>
> :>For the non-FORTRAN geeks who are wondering why anyone would ever think
> the last is the same: NASA had a bug due to this. While often blamed for
> the Mariner 1 failure, it seems that may not have been the case after all,
> but it's still interesting. See https://arstechnica.com/civis/
> viewtopic.php?t=862715
>
> :>When you realized that
> :> DO25I=1,10
> :>defines the start of a loop, but
> :> DO25I=1.10
> :>is an assignment statement, you really wonder what about the FORTRAN
> compiler parser! I'm sure it made sense at the time, and can see how it
> would be done, but it still seems to me like a strange way to design a
> language.
>
> Unlike COBOL which required white space, Fortran completely ignored white
> space. Also, COBOL has reserved words - Fortran does not.
>
> The first step in compiling was to squash the statement (while paying
> special
> attention to FORMAT statements where you might have nnnH, while recognizing
> that
>
> 30 FORMAT(I5,I10)=28
>
> is a valid assignment statement (as long a FORMAT was declared as an array)
> while
>
> 30 FORMAT(I5,I10,6H =28) )
>
> is a Format statement
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread Paul Gilmartin
On Thu, 26 Apr 2018 07:34:36 -0700, Phil Smith wrote:
>
>When you realized that
> DO25I=1,10
>defines the start of a loop, but
> DO25I=1.10
>is an assignment statement, you really wonder what about the FORTRAN compiler 
>parser! I'm sure it made sense at the time, and can see how it would be done, 
>but it still seems to me like a strange way to design a language.
> 
Over a half century ago, a peer told me that FORTRAN, with a preliminary lexical
scan, considered any statement with:
o an "=" not enclosed by parentheses, and
o no "," outside all parentheses
... to be an assignment statement.  Anything else starts with a keyword.

A professor in the same era told his class that the oldest FORTRAN compiler
parsed arithmetic expressions without using a stack.

Didn't oldest BASIC interpreters (or perhaps DEC's FOCAL) require that
assignments be introduced by a keyword, "SET" or "LET"?  I never knew
whether this was to simplify the parser or to aid novice (we all were)
programmers' understanding tnat "=" meant assignment, not comparison.

Some DEC interpreters put assgnment targets on the right.  Some DEC
shells put RENAME/COPY targets on the left (that's actually the better
way.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread Binyamin Dissen
On Thu, 26 Apr 2018 07:34:36 -0700 Phil Smith  wrote:

:>Binyamin Dissen wrote, in part:
:>>And for the non-Fortran programmer
:>>  DO 25  I  = 1,10
:>>is identical to
:>>  DO25I=1,10
:>>but different than
:>>  DO25I=1.10

:>For the non-FORTRAN geeks who are wondering why anyone would ever think the 
last is the same: NASA had a bug due to this. While often blamed for the 
Mariner 1 failure, it seems that may not have been the case after all, but it's 
still interesting. See https://arstechnica.com/civis/viewtopic.php?t=862715

:>When you realized that
:> DO25I=1,10
:>defines the start of a loop, but
:> DO25I=1.10
:>is an assignment statement, you really wonder what about the FORTRAN compiler 
parser! I'm sure it made sense at the time, and can see how it would be done, 
but it still seems to me like a strange way to design a language.

Unlike COBOL which required white space, Fortran completely ignored white
space. Also, COBOL has reserved words - Fortran does not.

The first step in compiling was to squash the statement (while paying special
attention to FORMAT statements where you might have nnnH, while recognizing
that 

30 FORMAT(I5,I10)=28

is a valid assignment statement (as long a FORMAT was declared as an array)
while

30 FORMAT(I5,I10,6H =28) )

is a Format statement

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread Phil Smith
Binyamin Dissen wrote, in part:
>And for the non-Fortran programmer
>  DO 25  I  = 1,10
>is identical to
>  DO25I=1,10
>but different than
>  DO25I=1.10

For the non-FORTRAN geeks who are wondering why anyone would ever think the 
last is the same: NASA had a bug due to this. While often blamed for the 
Mariner 1 failure, it seems that may not have been the case after all, but it's 
still interesting. See https://arstechnica.com/civis/viewtopic.php?t=862715

When you realized that
 DO25I=1,10
defines the start of a loop, but
 DO25I=1.10
is an assignment statement, you really wonder what about the FORTRAN compiler 
parser! I'm sure it made sense at the time, and can see how it would be done, 
but it still seems to me like a strange way to design a language.

...phsiii (mild space geek)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-26 Thread Binyamin Dissen
On Wed, 25 Apr 2018 13:00:35 -0500 Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

:>This flaw is also present in the pervasive RECFM=FB,LRECL=80.  Consider
:>the FORTRAN statement:
:>  PI = 3.14   265


And for the non-Fortran programmer

  DO 25  I  = 1,10

is identical to

  DO25I=1,10

but different than

  DO25I=1.10

thus

DO  25  I = 1.10
  J(I)=I*I
25CONTINUE

will compile perfectly fine and will not do what is desired. Always good to
look at the variable XREF to see if there is an "unexpected" variable.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-25 Thread John McKown
On Wed, Apr 25, 2018 at 1:00 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 22 Apr 2018 18:29:38 -0400, Hobart Spitz wrote:
> >
> >*With the *nix/C record and string models, there are these issues:*
> >
> >   1. Errant/unexpected/unintended pieces of binary data in a text
> >   file/string can break something.
> >   2. Separate functions/methods/techniques must be used to manipulate
> text
> >   files/strings versus binary files/string. You *must* know what you are
> >   dealing with up front, and/or somehow code logic for both. (I'm not
> sure
> >   the latter is possible in the general case.)
> >
> Gee.  The program must know the format of the data it's dealing with.
> Hardly a surprise.
>
> >   3. Even with *nix/C oriented machine instructions, the need to inspect
> >   all characters up to a target point results in performance killing
> cache
> >   flooding.
> >
> This flaw is also present in the pervasive RECFM=FB,LRECL=80.  Consider
> the FORTRAN statement:
>   PI = 3.14   265
> ... the compiler must inspect the line to the end of the record for
> additional digits.
> Variable length records relieve this.  Yet FORTRAN (yet, AFAIK), HLASM,
> and Utility
> control files must be FB 80.
>

​Herman Hollerith, we love you! (signed, IBM). Your cards will live FOREVER
in our software!​


>
> And quote-delimited strings aggravate the problem.  FORTRAN had this
> solved, as in:
>   WRITE ( 6, 100 )
> 100 FORMAT( 13HHello, world. / )
> ... on encouhtering the 13H, the compiler can just MVC 13 bytes to
> SYSPUNCH without
> inspecting them.  Subsequently, designers came to believe that silicon is
> cheaper than
> carbon, so in C:
> fprintf( stdout, "Hello, world.\n" );
> ... the compiler, not the programmer can count characters in the string.
> Of course, the
> FORTRAN scheme was easier when the programmer coded on a form with columns
> numbered
> and handed it off to Data Entry to be punched and verified.
>
> ISPF addressed the waste of storing blanks with compressed format.
> Characteristically, IBM
> introduced this at the wrong implementation layer.


​Using ISPF "packed" is, IMO, obsolete (and never was really of much use).
Today, we compress data sets using the SMS ​DataClass and so it is
"transparent" to the application.


> It should have been done at the access
> method layer or even the control unit so it would be transparent to all
> programs.  Compression
> should have been indicated by a flag in the data set label, not by a
> "magic number" in the
> data,  which is susceptible to being broken by "[e]rrant/unexpected/unintended
> pieces of binary
> data".
>
> There's considerable merit in the UN*X/C scheme of using variable length
> records and using the
> TAB character ratner than multiple blanks for column alignment.  It's
> easier to type, it's fewer
> characters for the compiler to scan, and it economizes storage.
>

​I like tabs for semantic purposes (and yes, I like the way the Python
language uses them). The only problem which arises is the "wars" that I've
seen as to whether a  should be the equivalent of "n" spaces or should
align to the next column # which is a multiple of some value (typically 4
or 8?).​ Or, thirdly, a variable number of spaces which align to the
aforementioned column number (I have "vim" tabs set up this way since I
transfer data to z/OS UNIX and ISPF hates real tabs -- x'05' in EBCDIC).



>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


RECFM (was: IRS - 60-Year-Old IT System Failed ... )

2018-04-25 Thread Paul Gilmartin
On Sun, 22 Apr 2018 18:29:38 -0400, Hobart Spitz wrote:
>
>*With the *nix/C record and string models, there are these issues:*
>
>   1. Errant/unexpected/unintended pieces of binary data in a text
>   file/string can break something.
>   2. Separate functions/methods/techniques must be used to manipulate text
>   files/strings versus binary files/string. You *must* know what you are
>   dealing with up front, and/or somehow code logic for both. (I'm not sure
>   the latter is possible in the general case.) 
>
Gee.  The program must know the format of the data it's dealing with.
Hardly a surprise.

>   3. Even with *nix/C oriented machine instructions, the need to inspect
>   all characters up to a target point results in performance killing cache
>   flooding.
>   
This flaw is also present in the pervasive RECFM=FB,LRECL=80.  Consider
the FORTRAN statement:
  PI = 3.14   265
... the compiler must inspect the line to the end of the record for additional 
digits.
Variable length records relieve this.  Yet FORTRAN (yet, AFAIK), HLASM, and 
Utility
control files must be FB 80.

And quote-delimited strings aggravate the problem.  FORTRAN had this solved, as 
in:
  WRITE ( 6, 100 )
100 FORMAT( 13HHello, world. / )
... on encouhtering the 13H, the compiler can just MVC 13 bytes to SYSPUNCH 
without
inspecting them.  Subsequently, designers came to believe that silicon is 
cheaper than
carbon, so in C:
fprintf( stdout, "Hello, world.\n" );
... the compiler, not the programmer can count characters in the string.  Of 
course, the
FORTRAN scheme was easier when the programmer coded on a form with columns 
numbered
and handed it off to Data Entry to be punched and verified.

ISPF addressed the waste of storing blanks with compressed format.  
Characteristically, IBM
introduced this at the wrong implementation layer.  It should have been done at 
the access
method layer or even the control unit so it would be transparent to all 
programs.  Compression
should have been indicated by a flag in the data set label, not by a "magic 
number" in the
data,  which is susceptible to being broken by "[e]rrant/unexpected/unintended 
pieces of binary
data".

There's considerable merit in the UN*X/C scheme of using variable length 
records and using the
TAB character ratner than multiple blanks for column alignment.  It's easier to 
type, it's fewer
characters for the compiler to scan, and it economizes storage.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN