Re: Article for the boss: COBOL will outlive us all

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2013c.html#11 Article for the boss: COBOL will 
outlive us all

more cobol related trivia ... other spin-offs from the science center
were companies that started offerring cp67 as commercial online service
... recent post in a.f.c
http://www.garlic.com/~lynn/2013c.html#56

regarding RAMIS, NOMAD, FOCUS, etc ... i.e. original 4th gen languages
... all done on virtual machine (cp67 or vm370 based) online services

nomad wiki
http://en.wikipedia.org/wiki/Nomad_software

from above:

Another example of Nomad's power is illustrated by Nicholas Rawlings in
his comments for the Computer History Museum about NCSS (see citation
below). He reports that James Martin asked Rawlings for a Nomad solution
to a standard problem Martin called the Engineer's Problem: "give 6%
raises to engineers whose job ratings had an average of 7 or better."
Martin provided a "dozen pages of COBOL, and then just a page or two of
Mark IV, from Informatics." Rawlings offered the following single
statement, performing a set-at-a-time operation, to show how trivial
this problem was with Nomad:

CHANGE ALL SALARY=SALARY*1.06 WHERE POSITION='ENG' AND AVG(INSTANCE(RATING)) GE 
7

... snip ...

other trivia was that the original relational/sql was also done on vm370
... mentioned in this recent post
http://www.garlic.com/~lynn/2013c.html#32 REFRPROT History Question

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

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

Re: Article for the boss: COBOL will outlive us all

[Anne & Lynn Wheeler]

cobol trivia in a.f.c. posts about cp67 group splitting off from the
science center (on the 4th flr) and moving to the 3rd flr, absorbing the
boston programming group (on its way to morphing into vm370):
http://www.garlic.com/~lynn/2013c.html#8 OT: CPL on LCM systems [was Re: COBOL 
will outlive us all]
http://www.garlic.com/~lynn/2013c.html#10 OT: CPL on LCM systems [was Re: COBOL 
will outlive us all]

Jean Sammat
http://en.wikipedia.org/wiki/Jean_E._Sammet

from above:

Sammet was employed by Sperry Gyroscope from 1955 to 1958 where she
supervised the first scientific programming group. From 1958 to 1961,
she worked for Sylvania as a staff consultant for programming research
and a member of the original COBOL group

... snip ...

http://www.computer.org/portal/web/awards/sammet

from above:

She joined IBM in 1961 to organize and manage the Boston Programming
Center. She initiated the concept, and directed the development, of the
first FORMAC (FORmula MAnipulation Compiler. (FORMAC was the first
widely used general language and system for manipulating nonnumeric
algebraic expressions.)

... snip ...

other recent posts on the subject:
http://www.garlic.com/~lynn/2013b.html#42 COBOL will outlive us all
http://www.garlic.com/~lynn/2013b.html#43 Article for the boss: COBOL will 
outlive us all
http://www.garlic.com/~lynn/2013b.html#45 Article for the boss: COBOL will 
outlive us all
http://www.garlic.com/~lynn/2013b.html#51 Article for the boss: COBOL will 
outlive us all
http://www.garlic.com/~lynn/2013b.html#52 Article for the boss: COBOL will 
outlive us all

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

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In <201302201529.55146.jlturr...@centurytel.net>, on 02/20/2013
   at 03:29 PM, Leslie Turriff  said:

>All issues with level numbers and usage clauses may be quickly
>resolved by  looking at the COBOL Language Reference manual 
>(unless one has an aversion to reading it).

Or, more likely, the syntax has concealed the fact that there is an
issue to look up.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In
,
on 02/20/2013
   at 09:15 AM, Thomas Berg  said:

>Do you in this regard prefer, e g, that:

>01  NAME1   PIC X.
>88  ONE  VALUE '1'.
>88  ZERO VALUE '0'.

>- instead be:

>01  NAME1   PIC X.
>WHEN VALUE '1' SETTRUE ONE.
>WHEN VALUE '0' SETTRUE ZERO.

>?

Not the syntax that I would have choosen, but certainly clearer than
88.

>But I can't see level number 77 be much confusing,

If you don't know that 77 is a magic number, it lookkks like an
element of a containing structure.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Clark Morris]

On 20 Feb 2013 13:37:40 -0800, in bit.listserv.ibm-main Leslie wrote:

>On Wednesday 20 February 2013 02:15:51 Thomas Berg wrote:
>> > It's not the features that are bad in those instances, but rather the
>> > syntax for requesting the features; that syntax is about as far from
>> > the purported English-like character of COBOL as you can get.
>> >
>> > >I can't immediately see that (except maybe COMPUTATIONAL-n).
>   In COBOL 2000 the Computational usages have been supplemented by

None of the BINARY usages below are recognized by the Enterpise COBOL
compiler even though they are in the 2002 standard and some would be
useful for dealing with SMF records.  The BINARY usages, especially
the new floating point usages that would be very useful in dealing
with other languages that recognize IEEE floating point, could
simplify inter-language calls with C and Java.  It is ludicrous that
COBOL, the business language does not recognize Decimal Floating Point
and the new rounding facilities even though Mike Cowlishaw of IBM Rexx
renown was one of the major pushers for the facility and it is in both
C/C++ and PL1 as well as Java.

Clark Morris
>BINARY *
>BINARY-C-LONG SIGNED
>BINARY-C-LONG UNSIGNED
>BINARY-C-LONG or
>BINARY-CHAR SIGNED
>BINARY-CHAR UNSIGNED
>BINARY-CHAR or
>BINARY-DOUBLE SIGNED
>BINARY-DOUBLE UNSIGNED
>BINARY-DOUBLE or
>BINARY-LONG SIGNED
>BINARY-LONG UNSIGNED
>BINARY-LONG or
>BINARY-SHORT SIGNED
>BINARY-SHORT UNSIGNED
>BINARY-SHORT or
>COMP *
>COMP-1 *
>COMP-2 *
>COMP-3 *
>COMP-4 *
>COMP-5 *
>COMPUTATIONAL *
>COMPUTATIONAL-1 *
>COMPUTATIONAL-2 *
>COMPUTATIONAL-3 *
>COMPUTATIONAL-4 *
>COMPUTATIONAL-5 *
>COMPUTATIONAL-X
>DISPLAY *
>DISPLAY-1 *
>FUNCTION-POINTER *
>INDEX *
>NATIONAL *
>OBJECT REFERENCE class-name-1 *
>PACKED-DECIMAL *
>POINTER *
>PROCEDURE-POINTER *
>PROGRAM-POINTER
>SIGNED-INT
>SIGNED-LONG
>SIGNED-SHORT
>UNSIGNED-INT
>UNSIGNED-LONG
>UNSIGNED-SHORT
>so this should no longer be an issue (unless they are prohibited by hide-bound 
>installation standards). (* indicates those recognized by z/COBOL.)
>> >
>> > If you're just learning COBOL, the magic numbers 77 and 88 totally
>> > obscure the intent; I consider them to be worse than COMPUTATIONAL-n in
>> > that regard.
>>
>> Do you in this regard prefer, e g, that:
>>
>> 01  NAME1               PIC X.
>>     88  ONE  VALUE '1'.
>>     88  ZERO VALUE '0'.
>>
>> - instead be:
>>
>> 01  NAME1               PIC X.
>>     WHEN VALUE '1' SETTRUE ONE.
>>     WHEN VALUE '0' SETTRUE ZERO.
>>
>> ?
>>
>> But I can't see level number 77 be much confusing, out of line of "normal"
>> COBOL and maybe superfluous but not much other than that.
>   66, 77 and 88 were perhaps an unfortunate choice by the Codasyl 
> Committee, 
>but simple code inspection makes their purpose clear even to a neophyte after 
>a few moments.  In COBOL 2000 we now have level 78 as well, to identify 
>constant identifiers:
>78 identifier-1 VALUE IS literal-1 .
>an alternative that may be preferred (I do) is use of the CONSTANT keyword:
>01 identifier-2 CONSTANT [ IS GLOBAL ] AS [literal-2 | LENGTH OF 
>identifier-3 | BYTE-LENGTH OF identifier-4].
>   All issues with level numbers and usage clauses may be quickly resolved 
> by 
>looking at the COBOL Language Reference manual (unless one has an aversion to 
>reading it).
>
>Leslie
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

In my previous post

= addr(s) ;

is properly

sp = addr(s) ;

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

No, unlike C, which has only pointers to functions, PL/I has procedure
variables, which may of course be based, pointed to.

A pointer, inclusive of a procedure pointer, should be just a pointer,
no different from a pointer to an aggregate or scalar.  What that
pointer points to may of course have an arbitrarily complex structure.

In PL/I, for example,

declare s character(254) varying, sp pointer, addr builtin ;

= addr(s) ;

sets sp to ploint not to the first data byte of s, but to its halfword
current-length prefix.

This is clean.  Depoartures from it are unclean.  About
object-oriented programming I weill limit myself to saying that I
judge it misguided at best.

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Paul Gilmartin]

On Wed, 20 Feb 2013 21:19:16 -0500, John Gilmore wrote:
>
>pointer
>procedure-pointer
>program-pointer
>
>are the poster children for this dubious practice.  I know what the
>differences among tgherm are, but if pointer had not been misconceived
>in the beginning they would have been unnecessary.  (There is no
>better case for associating ancillary information with a pointer than
>there is for associating it with a signed fullword.)
> 
In languages of the vintage of ALGOL-60, Pascal, (PL/I?), a procedure
reference also identifies the dynamic instance of the statically
enclosing stack frame at the point at which the reference was defined.
This is such ancillary information.

This was perhaps an embryonic attempt at object-oriented design.

-- gil

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

Some things improved when the future of COBOL was wrested from
Codasyl, and some did not.  We still have the proliferation of
distinctions among entities that ought not to be distinguished,
distinctions without substantive differences.

The three entities

pointer
procedure-pointer
program-pointer

are the poster children for this dubious practice.  I know what the
differences among tgherm are, but if pointer had not been misconceived
in the beginning they would have been unnecessary.  (There is no
better case for associating ancillary information with a pointer than
there is for associating it with a signed fullword.)

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Frank Swarbrick]

For what its worth, some of those you've mentioned are either IBM extensions, 
Micro Focus extensions, or both.  Specifically, all of the COMP[UTATIONAL]-# 
usages.  COMPUTATIONAL-X is Micro Focus.  FUNCTION-POINTER and 
PROCEDURE-POINTER are IBM, which MF followed.  PROGRAM-POINTER is COBOL 2000.

78 levels are a Micro Focus extension.  The 01 CONSTANT option is how COBOL 
2000 supports constants.  Not sure anyone supports that one yet!  (Maybe Micro 
Focus allows it along with their old 78 level.)

Oh what fun!





>
> From: Leslie Turriff 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, February 20, 2013 2:29 PM
>Subject: Re: SV: SV: SV: Article for the boss: COBOL will outlive us all
> 
>On Wednesday 20 February 2013 02:15:51 Thomas Berg wrote:
>> > It's not the features that are bad in those instances, but rather the
>> > syntax for requesting the features; that syntax is about as far from
>> > the purported English-like character of COBOL as you can get.
>> >
>> > >I can't immediately see that (except maybe COMPUTATIONAL-n).
>    In COBOL 2000 the Computational usages have been supplemented by
>BINARY *
>BINARY-C-LONG SIGNED
>BINARY-C-LONG UNSIGNED
>BINARY-C-LONG or
>BINARY-CHAR SIGNED
>BINARY-CHAR UNSIGNED
>BINARY-CHAR or
>BINARY-DOUBLE SIGNED
>BINARY-DOUBLE UNSIGNED
>BINARY-DOUBLE or
>BINARY-LONG SIGNED
>BINARY-LONG UNSIGNED
>BINARY-LONG or
>BINARY-SHORT SIGNED
>BINARY-SHORT UNSIGNED
>BINARY-SHORT or
>COMP *
>COMP-1 *
>COMP-2 *
>COMP-3 *
>COMP-4 *
>COMP-5 *
>COMPUTATIONAL *
>COMPUTATIONAL-1 *
>COMPUTATIONAL-2 *
>COMPUTATIONAL-3 *
>COMPUTATIONAL-4 *
>COMPUTATIONAL-5 *
>COMPUTATIONAL-X
>DISPLAY *
>DISPLAY-1 *
>FUNCTION-POINTER *
>INDEX *
>NATIONAL *
>OBJECT REFERENCE class-name-1 *
>PACKED-DECIMAL *
>POINTER *
>PROCEDURE-POINTER *
>PROGRAM-POINTER
>SIGNED-INT
>SIGNED-LONG
>SIGNED-SHORT
>UNSIGNED-INT
>UNSIGNED-LONG
>UNSIGNED-SHORT
>so this should no longer be an issue (unless they are prohibited by hide-bound 
>installation standards). (* indicates those recognized by z/COBOL.)
>> >
>> > If you're just learning COBOL, the magic numbers 77 and 88 totally
>> > obscure the intent; I consider them to be worse than COMPUTATIONAL-n in
>> > that regard.
>>
>> Do you in this regard prefer, e g, that:
>>
>> 01  NAME1               PIC X.
>>     88  ONE  VALUE '1'.
>>     88  ZERO VALUE '0'.
>>
>> - instead be:
>>
>> 01  NAME1               PIC X.
>>     WHEN VALUE '1' SETTRUE ONE.
>>     WHEN VALUE '0' SETTRUE ZERO.
>>
>> ?
>>
>> But I can't see level number 77 be much confusing, out of line of "normal"
>> COBOL and maybe superfluous but not much other than that.
>    66, 77 and 88 were perhaps an unfortunate choice by the Codasyl Committee, 
>but simple code inspection makes their purpose clear even to a neophyte after 
>a few moments.  In COBOL 2000 we now have level 78 as well, to identify 
>constant identifiers:
>78 identifier-1 VALUE IS literal-1 .
>an alternative that may be preferred (I do) is use of the CONSTANT keyword:
>01 identifier-2 CONSTANT [ IS GLOBAL ] AS [literal-2 | LENGTH OF 
>identifier-3 | BYTE-LENGTH OF identifier-4].
>    All issues with level numbers and usage clauses may be quickly resolved by 
>looking at the COBOL Language Reference manual (unless one has an aversion to 
>reading it).
>
>Leslie
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Leslie Turriff]

On Wednesday 20 February 2013 02:15:51 Thomas Berg wrote:
> > It's not the features that are bad in those instances, but rather the
> > syntax for requesting the features; that syntax is about as far from
> > the purported English-like character of COBOL as you can get.
> >
> > >I can't immediately see that (except maybe COMPUTATIONAL-n).
In COBOL 2000 the Computational usages have been supplemented by
BINARY *
BINARY-C-LONG SIGNED
BINARY-C-LONG UNSIGNED
BINARY-C-LONG or
BINARY-CHAR SIGNED
BINARY-CHAR UNSIGNED
BINARY-CHAR or
BINARY-DOUBLE SIGNED
BINARY-DOUBLE UNSIGNED
BINARY-DOUBLE or
BINARY-LONG SIGNED
BINARY-LONG UNSIGNED
BINARY-LONG or
BINARY-SHORT SIGNED
BINARY-SHORT UNSIGNED
BINARY-SHORT or
COMP *
COMP-1 *
COMP-2 *
COMP-3 *
COMP-4 *
COMP-5 *
COMPUTATIONAL *
COMPUTATIONAL-1 *
COMPUTATIONAL-2 *
COMPUTATIONAL-3 *
COMPUTATIONAL-4 *
COMPUTATIONAL-5 *
COMPUTATIONAL-X
DISPLAY *
DISPLAY-1 *
FUNCTION-POINTER *
INDEX *
NATIONAL *
OBJECT REFERENCE class-name-1 *
PACKED-DECIMAL *
POINTER *
PROCEDURE-POINTER *
PROGRAM-POINTER
SIGNED-INT
SIGNED-LONG
SIGNED-SHORT
UNSIGNED-INT
UNSIGNED-LONG
UNSIGNED-SHORT
so this should no longer be an issue (unless they are prohibited by hide-bound 
installation standards). (* indicates those recognized by z/COBOL.)
> >
> > If you're just learning COBOL, the magic numbers 77 and 88 totally
> > obscure the intent; I consider them to be worse than COMPUTATIONAL-n in
> > that regard.
>
> Do you in this regard prefer, e g, that:
>
> 01  NAME1               PIC X.
>     88  ONE  VALUE '1'.
>     88  ZERO VALUE '0'.
>
> - instead be:
>
> 01  NAME1               PIC X.
>     WHEN VALUE '1' SETTRUE ONE.
>     WHEN VALUE '0' SETTRUE ZERO.
>
> ?
>
> But I can't see level number 77 be much confusing, out of line of "normal"
> COBOL and maybe superfluous but not much other than that.
66, 77 and 88 were perhaps an unfortunate choice by the Codasyl 
Committee, 
but simple code inspection makes their purpose clear even to a neophyte after 
a few moments.  In COBOL 2000 we now have level 78 as well, to identify 
constant identifiers:
78 identifier-1 VALUE IS literal-1 .
an alternative that may be preferred (I do) is use of the CONSTANT keyword:
01 identifier-2 CONSTANT [ IS GLOBAL ] AS [literal-2 | LENGTH OF 
identifier-3 | BYTE-LENGTH OF identifier-4].
All issues with level numbers and usage clauses may be quickly resolved 
by 
looking at the COBOL Language Reference manual (unless one has an aversion to 
reading it).

Leslie

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

SV: SV: SV: Article for the boss: COBOL will outlive us all

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För Shmuel Metz (Seymour J.)
> Skickat: den 20 februari 2013 01:20
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: SV: SV: Article for the boss: COBOL will outlive us all
> 
> In
>  >,
> on 02/18/2013
>at 02:48 PM, Thomas Berg  said:
> 
> >Do you imply that these features is promoting/helping obfuscating ?
> 
> It's not the features that are bad in those instances, but rather the
> syntax for requesting the features; that syntax is about as far from
> the purported English-like character of COBOL as you can get.
> 
> >I can't immediately see that (except maybe COMPUTATIONAL-n).
> 
> If you're just learning COBOL, the magic numbers 77 and 88 totally
> obscure the intent; I consider them to be worse than COMPUTATIONAL-n in
> that regard.

Do you in this regard prefer, e g, that:

01  NAME1   PIC X.
88  ONE  VALUE '1'.
88  ZERO VALUE '0'.

- instead be:

01  NAME1   PIC X.
WHEN VALUE '1' SETTRUE ONE.
WHEN VALUE '0' SETTRUE ZERO.

?

But I can't see level number 77 be much confusing, out of line of "normal" 
COBOL and maybe superfluous but not much other than that. 



Regards
Thomas Berg

Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In
,
on 02/18/2013
   at 02:48 PM, Thomas Berg  said:

>Do you imply that these features is promoting/helping obfuscating ? 

It's not the features that are bad in those instances, but rather the
syntax for requesting the features; that syntax is about as far from
the purported English-like character of COBOL as you can get.

>I can't immediately see that (except maybe COMPUTATIONAL-n). 

If you're just learning COBOL, the magic numbers 77 and 88 totally
obscure the intent; I consider them to be worse than COMPUTATIONAL-n
in that regard. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Leslie Turriff]

On Monday 18 February 2013 23:20:46 Ed Gould wrote:
> Most places I have worked the use of ALTER was banned in the
> standards manual.
>
> Ed
Not this place; my "mentor" chastised me for using structured methods 
(he 
didn't understand it). :-P

Leslie

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Ed Gould]

Most places I have worked the use of ALTER was banned in the  
standards manual.


Ed

On Feb 18, 2013, at 7:45 PM, Leslie Turriff wrote:


On Monday 18 February 2013 05:16:45 Thomas Berg wrote:

(I really hate the ALTER command.)


Fortunately I haven't seen this the last +20 years or so.  Anf if  
I had I

would have strangled the programmer... :)


	I had one at my last application programming job last year.  (They  
never

heard of structured programming there.)I   refused to work on it.

Leslie

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


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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Leslie Turriff]

On Monday 18 February 2013 15:57:12 Clark Morris wrote:
> On 18 Feb 2013 08:30:24 -0800, in bit.listserv.ibm-main you wrote:
> >The plumbing needed to implement Paul Gilmartin's suggestion is more
> >complex than he perhaps implies it to be.  An implementation is
> >straightforward in PL/I, e.g.,
> >
> >declare infile file record sequential buffered ;
> >...
> >declare read_file aligned bit ; /* boolean */
> >...
> >on endfile(infile) read_infile = '0'b ;
> >...
> >open file(infile) input ;
> >...
> >read_infile = '1'b ;
> >do while(read_infile) repeat(read_infile) ;
> >  read file(infile) set(inrecp) ;
> >end ;
> >
> >Unfortunately there is nothing in COBOL corresponding to the
> >asynchronously entered ON unit here.  COBOL is resolutely synchronous.
>
> If you add status codes to the SELECT statement for a file, you can
> code
> IF HOLD-FILE-A-KEY not = HIGH-VALUE
>   READ FILE-A
>   IF FILE-STATUS = '00' '97'
> PERFORM PROCESS-FILE-A
>   ELSE
> MOVE HIGH-VALUE to HOLD-FILE-A-KEY
>   END-IF
> END-IF
>
> There also are declaratives which are separate and that I never
> bothered figuring out how to use.
>
The Declaratives Section essentially works the way "on " 
works in 
PL/I:

   Declaratives.

Section-name-1 Section.

 Use after standard error procedure on File-Name-1.

  *  Statements to do something when an error occurs during I/O on
  *  File-Name-1.

 Use after standard error procedure on File-Name-2.

  *  Statements to do something when an error occurs during I/O on
  *  File-Name-2.

   End-Declaratives.

Leslie

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

Re: SV: SV: SV: Article for the boss: COBOL will outlive us all

[Leslie Turriff]

On Monday 18 February 2013 05:16:45 Thomas Berg wrote:
> > (I really hate the ALTER command.)
>
> Fortunately I haven't seen this the last +20 years or so.  Anf if I had I
> would have strangled the programmer... :)

I had one at my last application programming job last year.  (They 
never 
heard of structured programming there.)I   refused to work on it.

Leslie

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Clark Morris]

On 18 Feb 2013 08:30:24 -0800, in bit.listserv.ibm-main you wrote:

>The plumbing needed to implement Paul Gilmartin's suggestion is more
>complex than he perhaps implies it to be.  An implementation is
>straightforward in PL/I, e.g.,
>
>declare infile file record sequential buffered ;
>...
>declare read_file aligned bit ; /* boolean */
>...
>on endfile(infile) read_infile = '0'b ;
>...
>open file(infile) input ;
>...
>read_infile = '1'b ;
>do while(read_infile) repeat(read_infile) ;
>  read file(infile) set(inrecp) ;
>end ;
>
>Unfortunately there is nothing in COBOL corresponding to the
>asynchronously entered ON unit here.  COBOL is resolutely synchronous.

If you add status codes to the SELECT statement for a file, you can
code 
IF HOLD-FILE-A-KEY not = HIGH-VALUE
  READ FILE-A
  IF FILE-STATUS = '00' '97'
PERFORM PROCESS-FILE-A
  ELSE
MOVE HIGH-VALUE to HOLD-FILE-A-KEY
  END-IF
END-IF

There also are declaratives which are separate and that I never
bothered figuring out how to use.

Clark Morris   
>
>John Gilmore, Ashland, MA 01721 - USA
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Article for the boss: COBOL will outlive us all

[Ted MacNEIL]

I must be a dummy.
I read it -- I entered the University of Waterloo in 1976.
And, I NEVER understood the bennies of readahead.
To me, there is no major difference in the coding.

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Wayne Bickerdike 
Sender:   IBM Mainframe Discussion List 
Date: Tue, 19 Feb 2013 07:36:02 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Article for the boss: COBOL will outlive us all

Pity Michael Jackson seems to have not made it to the mighty USA.

His seminal 1975 work which I cut my teeth on handles this without all
the silly convolutions.

It has been rediscovered, oh joy!

http://pythonconquerstheuniverse.wordpress.com/2011/07/22/read-ahead-and-python-generators/

The brilliant but simple read ahead. The flowchart is to blame.



On Tue, Feb 19, 2013 at 4:41 AM, Ed Finnell  wrote:
> "But Dad it takes so long to get a can down that tiny little hole."
>
>
> In a message dated 2/18/2013 8:09:01 A.M. Central Standard Time,
> mitchd...@gmail.com writes:
>
> so if  that comes on, you've got bigger trouble than being a quart  low.
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Wayne V. Bickerdike

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

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

Re: Article for the boss: COBOL will outlive us all

[Wayne Bickerdike]

Pity Michael Jackson seems to have not made it to the mighty USA.

His seminal 1975 work which I cut my teeth on handles this without all
the silly convolutions.

It has been rediscovered, oh joy!

http://pythonconquerstheuniverse.wordpress.com/2011/07/22/read-ahead-and-python-generators/

The brilliant but simple read ahead. The flowchart is to blame.



On Tue, Feb 19, 2013 at 4:41 AM, Ed Finnell  wrote:
> "But Dad it takes so long to get a can down that tiny little hole."
>
>
> In a message dated 2/18/2013 8:09:01 A.M. Central Standard Time,
> mitchd...@gmail.com writes:
>
> so if  that comes on, you've got bigger trouble than being a quart  low.
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Wayne V. Bickerdike

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

Re: Article for the boss: COBOL will outlive us all

[Ed Finnell]

"But Dad it takes so long to get a can down that tiny little hole."
 
 
In a message dated 2/18/2013 8:09:01 A.M. Central Standard Time,  
mitchd...@gmail.com writes:

so if  that comes on, you've got bigger trouble than being a quart  low.



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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

The plumbing needed to implement Paul Gilmartin's suggestion is more
complex than he perhaps implies it to be.  An implementation is
straightforward in PL/I, e.g.,

declare infile file record sequential buffered ;
...
declare read_file aligned bit ; /* boolean */
...
on endfile(infile) read_infile = '0'b ;
...
open file(infile) input ;
...
read_infile = '1'b ;
do while(read_infile) repeat(read_infile) ;
  read file(infile) set(inrecp) ;
end ;

Unfortunately there is nothing in COBOL corresponding to the
asynchronously entered ON unit here.  COBOL is resolutely synchronous.

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

Epigonoi and its descendents are good words.  The insistent question

| Perché gli Epigoni dovrebbero essere inferiori ai progenitori?

has been repeated for two odd millenia now, but the pejorative sense
of these words fills a need, and I think that the best response to
this question is that descendents who are not inferior should not
be/are not properly called epigoni.

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Paul Gilmartin]

On Mon, 18 Feb 2013 09:23:52 -0600, John McKown wrote:

>A friend of mine had something similar. He did a
>
>PERFORM UNTIL FILE-EOF
>  READ ... AT END SET FILE-EOF TO TRUE.
>  IF NOT FILE-EOF THEN ...
>the rest of the program
>  END-IF
>END-PERFORM
> 
In any wisely designed language, READ is a function returning
a boolean value indicating success or failure which can be tested
in the loop control statement:

WHILE READ ... PERFORM
the rest of the program
END-PERFORM

-- gil

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[John McKown]

A friend of mine had something similar. He did a

PERFORM UNTIL FILE-EOF
  READ ... AT END SET FILE-EOF TO TRUE.
  IF NOT FILE-EOF THEN ...
the rest of the program
  END-IF
END-PERFORM

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[David Andrews]

On Mon, 2013-02-18 at 09:26 -0500, John Gilmore wrote:
> This notion was later reified by Dijkstra's epigoni into
> an interdiction: all GOTOs as bad in all circumstances.

"Epigone", what a great word.

In my undergraduate days, in the immediate wake of Dijkstra's CACM
letter, acquaintances of mine complained that their COBOL programs
containing:
READ MYFILE AT END GOTO END-OF-JOB
were being instantly returned as unacceptable: no GOTOs allowed.
Identical code resubmitted as:
READ MYFILE AT END PERFORM END-OF-JOB
were deemed correct.  Argh.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

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

Re: SV: Article for the boss: COBOL will outlive us all

[David Andrews]

On Sun, 2013-02-17 at 13:45 -0500, zMan wrote:
> Can you do that for fields in an existing copybook?

ADDRESS OF (sender) works for anything that isn't level 66 or 88.  It
even works for reference modification:
SET MY-POINTER TO ADDRESS OF CHAR-FIELD(5:1)

While you're able to do limited pointer arithmetic with REDEFINES
COMP-5, be wary: there's no code portability here, and it's a hack.
When/if Tom gets around to implementing 64-bit support that'll bite you.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

GOTO DEPENDING certainly has its uses; and this usefulness can serve
as the anchor for a more general observation.

Dijkstra's original GOTO paper did not interdict them; it suggested
that thickets of GOTOs were undesirable and set out the metric that
the quality of a program is inversely related to the number of GOTOs
it contains.  This notion was later reified by Dijkstra's epigoni into
an interdiction: all GOTOs as bad in all circumstances.

The result has been a game of hide-the-GOTO.  Modern statement-level
procedural languages contain too many constructs that are really
disguised GOTOs.  (The C break statement is an obvious example).  They
are judged to be somehow more 'structured' and less 'anarchic' than
GOTOs, but they in fact lend themselves to abuse too.

All instructions indeed lend themselves to misuse and, in most cases,
to appropriate, beneficent use too.  A focus on infantilizing
programming languages in order to make it impossible for novices to
misuse them has 1) impaired the expressive power of these languages
and 2) failed, in the sense that the misuses they address continue
unabated.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Article for the boss: COBOL will outlive us all

[Dana Mitchell]

On Sat, 16 Feb 2013 20:55:07 +0800, Timothy Sipples  wrote:

> We have these things called PCs (and Macs) with user interfaces that
>support at least two windows, and Alt-Tab (or Command-Tab) is one way among
>many to toggle between them. Copy/paste seems to work, too.
>

Timothy,

I think I've got Alt-Tab thing figured out pretty well, thanks.

My point was that z/OS isn't in this situation *yet*  and I'm hoping it doesn't 
happen.

>For comparison -- and far worse when you think about it -- most automobiles
>have at least two ways of checking the oil level. One way is a binary
>readout, located on the dashboard. If the light is not illuminated, you
>have enough oil. 

Most cars I'm familiar with the dash light is for oil pressure,  so if that 
comes on, you've got bigger trouble than being a quart low.

Dana

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[David Andrews]

On Sun, 2013-02-17 at 15:54 -0600, Leslie Turriff wrote:
> (I really hate the ALTER command.)

Yes, but GOTO DEPENDING (branch tables) can be quite useful for e.g.
state machines.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

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

SV: SV: Article for the boss: COBOL will outlive us all

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För Shmuel Metz (Seymour J.)
> Skickat: den 18 februari 2013 13:07
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: SV: Article for the boss: COBOL will outlive us all
> 
> In
>  >,
> on 02/16/2013
>at 08:53 PM, Thomas Berg  said:
> 
> >COBOL is certainly not a programmers language. It's very restricted by
> >its syntax and functionality and is often very clumsy to use.  But
> that
> >is also a feature: it's hard to obfuscate
> 
> 77
> 
> 88
> 
> COMPUTATIONAL-n
> 

Do you imply that these features is promoting/helping obfuscating ? 
I can't immediately see that (except maybe COMPUTATIONAL-n). 



Regards
Thomas Berg

Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)

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

Re: SV: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In
,
on 02/17/2013
   at 08:47 AM, John Gilmore  said:

>G. H. Hardy wrote that 1) intellectual curiosity, a desire to know
>how things work, 2) craftsmanship, the need to do the  best job one
>knows how to do, and 3) a desire for recognition, even fame, are 
>sine quibus non for success at any intellectual task.

Gauss was a failure?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SV: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2013
   at 08:53 PM, Thomas Berg  said:

>COBOL is certainly not a programmers language. It's very 
>restricted by its syntax and functionality and is often very 
>clumsy to use.  But that is also a feature: it's hard to obfuscate

77

88

COMPUTATIONAL-n

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In <201302151911.49741.jlturr...@centurytel.net>, on 02/15/2013
   at 07:11 PM, Leslie Turriff  said:

>Not so much a mistake as short-sightedness; before 3270s were
>available,  keypunches could only do upper-case

In the same time frame IBM had software that supported dual case
using, e.g., 1050, 2740, 2741. I suspect that moncase had more to do
with corporate culture than hardware.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

SV: SV: SV: Article for the boss: COBOL will outlive us all

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För Leslie Turriff
> Skickat: den 17 februari 2013 22:54
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: SV: SV: Article for the boss: COBOL will outlive us all
> 
> On Sunday 17 February 2013 12:47:16 Thomas Berg wrote:
> > Some suggestions:
> >
> > * GO TO's from in the middle of one SECTION into the middle of
> another.
> > And then GO TO back again depending on a "switch"... * Programs with
> > nested PERFORMS (*only* PERFORMS!) in maybe 7 levels ending in a CALL
> > of another module. * Field name (variable) in (e g) MOVE statement
> > qualified resulting in more than 100 characters, then add the
> matching
> > length for the corresponding field. (Take this times 1000 fields...)
> > * Processing the same data sometimes in a character defined field,
> > sometimes in numeric defined fields (several different numeric
> formats
> > for the same data) without any reasonable explanation. * Need to
> check
> > four or five different result fields (depending on the situation
> etc.)
> > for eventual error from the CALL of another module.
> >
> > And other I have forgotten...
> >
>   :
>   PARAGRAPH-1.
>   GO TO PARAGRAPH-3.
> 
>   PARAGRAPH-2.
>   ALTER PARAGRAPH-1 TO PROCEED TO PARAGRAPH-4.
> 
>   PARAGRAPH-3.
>   ALTER PARAGRAPH-1 TO PROCEED TO PARAGRAPH-2.
> 
>   PARAGRAPH-4.
>   :
> 
> (I really hate the ALTER command.)

Fortunately I haven't seen this the last +20 years or so.  Anf if I had I would 
have strangled the programmer... :)



Regards
Thomas Berg

Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)



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

Re: SV: Article for the boss: COBOL will outlive us all

[zMan]

On Sun, Feb 17, 2013 at 8:26 PM, Clark Morris wrote:

> Read the current manuals.  As someone who has manipulated the SMF 30
> records using COBOL WITHOUT resorting to Assembler, I can state that
> for much problem program state work, COBOL is quite adequate.  I have
> also created a system usage report in COBOL that read files of IDR
> records created by an assembler program and parsed source program
> files to determine CALL and COPY usage.  Enterprise COBOL is a very
> powerful language and adding the 2002 improvements would make it even
> more so.


Well, I'm willing to believe that. I certainly don't claim to be a COBOL
jock, nor is my most common source for COBOL help. So I should probably
just shut up (hey, stop cheering!).
-- 
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: SV: Article for the boss: COBOL will outlive us all

[Clark Morris]

On 16 Feb 2013 13:15:06 -0800, in bit.listserv.ibm-main you wrote:

>On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford  wrote:
>
>> Thomas,
>>
>> I don't follow, writing in several languages , what awkward to do in
>> cobol, supervisory stuff yes for sure.
>>
>
>Yoda? Is that you? :-)
>
>If this was supposed to be asking "What is it that's awkward to do in
>COBOL?", try calculating the offset between two data elements. For one. I
>know that every time I go to write something in it, I run up against "You
>just can't do that in this language" and my response is "Seriously? Wow."
>(OK, or I write an assembler function to enable what I need...)

Read the current manuals.  As someone who has manipulated the SMF 30
records using COBOL WITHOUT resorting to Assembler, I can state that
for much problem program state work, COBOL is quite adequate.  I have
also created a system usage report in COBOL that read files of IDR
records created by an assembler program and parsed source program
files to determine CALL and COPY usage.  Enterprise COBOL is a very
powerful language and adding the 2002 improvements would make it even
more so.

Clark Morris
>
>Admittedly, COBOL isn't as bad as I'd been led to believe by three decades
>of avoiding it -- but as the saying goes, "You can write your program in
>, or you can write a story about your program in COBOL".

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Clark Morris]

On 17 Feb 2013 14:01:41 -0800, in bit.listserv.ibm-main you wrote:

>On Sunday 17 February 2013 12:47:16 Thomas Berg wrote:
>> Some suggestions:
>>
>> * GO TO's from in the middle of one SECTION into the middle of another. 
>> And then GO TO back again depending on a "switch"... * Programs with nested
>> PERFORMS (*only* PERFORMS!) in maybe 7 levels ending in a CALL of another
>> module. * Field name (variable) in (e g) MOVE statement qualified resulting
>> in more than 100 characters, then add the matching length for the
>> corresponding field. (Take this times 1000 fields...)
>> * Processing the same data sometimes in a character defined field,
>> sometimes in numeric defined fields (several different numeric formats for
>> the same data) without any reasonable explanation. * Need to check four or
>> five different result fields (depending on the situation etc.) for eventual
>> error from the CALL of another module.
>>
>> And other I have forgotten...
>>
>   :
>   PARAGRAPH-1.
>   GO TO PARAGRAPH-3.
>
>   PARAGRAPH-2.
>   ALTER PARAGRAPH-1 TO PROCEED TO PARAGRAPH-4.
>
>   PARAGRAPH-3.
>   ALTER PARAGRAPH-1 TO PROCEED TO PARAGRAPH-2.
>
>   PARAGRAPH-4.
>   :
>
>(I really hate the ALTER command.)

And it is deprecated if not removed in the current standards.

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

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Clark Morris]

On 17 Feb 2013 11:03:08 -0800, in bit.listserv.ibm-main you wrote:

>Thomas,
>
>I see your point ...writing in Cobol , because I must to support a product, I 
>have used a bunch of assembler routines, we are converting to C
You definitely should read the latest COBOL manuals thoroughly to see
which Assembler routines can be replaced with native COBOL.  And if
IBM had just implemented the portions of the 2002 Standard for which
there are SHARE requirements, even more of those routines could be
eliminated.  The latter includes such things as USAGE BIT and related
Boolean instructions, other true BINARY usages and other long overdue
facilities that I don't recall.

CLark Morris
>
>Scott ford
>www.identityforge.com
>
>Tell me and I'll forget; show me and I may remember; involve me and I'll 
>understand. - Chinese Proverb
>
>
>On Feb 17, 2013, at 1:47 PM, Thomas Berg  wrote:
>
>> Some suggestions: 
>> 
>> * GO TO's from in the middle of one SECTION into the middle of another.  And 
>> then GO TO back again depending on a "switch"...
>> * Programs with nested PERFORMS (*only* PERFORMS!) in maybe 7 levels ending 
>> in a CALL of another module.
>> * Field name (variable) in (e g) MOVE statement qualified resulting in more 
>> than 100 characters, then add the matching length for the corresponding 
>> field. 
>>  (Take this times 1000 fields...)
>> * Processing the same data sometimes in a character defined field, sometimes 
>> in numeric defined fields (several different numeric formats for the same 
>> data) without any reasonable explanation. 
>> * Need to check four or five different result fields (depending on the 
>> situation etc.) for eventual error from the CALL of another module. 
>> 
>> And other I have forgotten...
>> 
>> 
>> 
>> Regards
>> Thomas Berg
>> 
>> Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)
>> 
>>> -----Ursprungligt meddelande-----
>>> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> För Scott Ford
>>> Skickat: den 16 februari 2013 21:26
>>> Till: IBM-MAIN@LISTSERV.UA.EDU
>>> Ämne: Re: SV: Article for the boss: COBOL will outlive us all
>>> 
>>> Thomas,
>>> 
>>> I don't follow, writing in several languages , what awkward to do in
>>> cobol, supervisory stuff yes for sure.
>>> 
>>> Scott ford
>>> www.identityforge.com
>>> 
>>> Tell me and I'll forget; show me and I may remember; involve me and
>>> I'll understand. - Chinese Proverb
>>> 
>>> 
>>> On Feb 16, 2013, at 2:53 PM, Thomas Berg 
>>> wrote:
>>> 
>>>>> -Ursprungligt meddelande-
>>>>> Från: IBM Mainframe Discussion List [mailto:IBM-
>>> m...@listserv.ua.edu]
>>>>> För John Gilmore
>>>>> Skickat: den 16 februari 2013 20:25
>>>>> Till: IBM-MAIN@LISTSERV.UA.EDU
>>>>> Ämne: Re: Article for the boss: COBOL will outlive us all
>>>>> 
>>>>> Tony H wrote
>>>>> 
>>>>> | Now back to our regular COBOL, uh,  programming.
>>>>> 
>>>>> thus alluding to how many of us view of the language.
>>>>> 
>>>>> Over a now long career I never took COBOL seriously.  I was aware of
>>>>> it, and I even learned to write it by helping COBOL programmers with
>>>>> their problems.  It is a verbose but finally very simple language.
>>>>> That said, I could not, and did not, think much of a language
>>> without
>>>>> real storage management, strings, pointers, booleans, etc., etc.  It
>>>>> was move-oriented, compile-time bound, and synchronous, and I find
>>>>> these characteristics despicable.
>>>> 
>>>> COBOL is certainly not a programmers language. It's very restricted
>>> by its syntax and functionality and is often very clumsy to use.
>>>> But that is also a feature: it's hard to obfuscate - which can be
>>> seen as an asset from the point of maintenance and security.
>>>> (Which do not mean that you can't make unintelligible programs - I
>>> have seen many - but not at the lowest level.)
>>>> It's also helpful when you need to understand the underlying data
>>> structure the program is based on.
>>>> 
>>>> 
>>>> 
>>>> Regards
>>>

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Leslie Turriff]

On Sunday 17 February 2013 12:47:16 Thomas Berg wrote:
> Some suggestions:
>
> * GO TO's from in the middle of one SECTION into the middle of another. 
> And then GO TO back again depending on a "switch"... * Programs with nested
> PERFORMS (*only* PERFORMS!) in maybe 7 levels ending in a CALL of another
> module. * Field name (variable) in (e g) MOVE statement qualified resulting
> in more than 100 characters, then add the matching length for the
> corresponding field. (Take this times 1000 fields...)
> * Processing the same data sometimes in a character defined field,
> sometimes in numeric defined fields (several different numeric formats for
> the same data) without any reasonable explanation. * Need to check four or
> five different result fields (depending on the situation etc.) for eventual
> error from the CALL of another module.
>
> And other I have forgotten...
>
:
PARAGRAPH-1.
GO TO PARAGRAPH-3.

PARAGRAPH-2.
ALTER PARAGRAPH-1 TO PROCEED TO PARAGRAPH-4.

PARAGRAPH-3.
ALTER PARAGRAPH-1 TO PROCEED TO PARAGRAPH-2.

PARAGRAPH-4.
:

(I really hate the ALTER command.)

Leslie

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

Additionally, String and Unstring are very powerful verbs in Cobol. Good 
parsing is a essential when looking at data, some akin to Rexx would be great 
in Cobol...C you can use tokens 

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 3:42 PM, Scott Ford  wrote:

> The pointer addition to Cobol, you use very effectively. I have queried the 
> CVT ...for various fields successfully.
> 
> Scott ford
> www.identityforge.com
> 
> Tell me and I'll forget; show me and I may remember; involve me and I'll 
> understand. - Chinese Proverb
> 
> 
> On Feb 17, 2013, at 3:39 PM, Scott Ford  wrote:
> 
>> The pointer addition to Cobol, you use ver effectively. I have queried the 
>> CVT ...for various fields successfully.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

The pointer addition to Cobol, you use very effectively. I have queried the CVT 
...for various fields successfully.

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 3:39 PM, Scott Ford  wrote:

> The pointer addition to Cobol, you use ver effectively. I have queried the 
> CVT ...for various fields successfully.

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

The pointer addition to Cobol, you use ver effectively. I have queried the CVT 
...for various fields successfully.

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 2:45 PM, John Gilmore  wrote:

> Thomas Berg's notion that COBOL is hard to obfuscate is less true than
> it once was.
> 
> REDEFINES has always had its obfuscatory uses; but the availability of
> pointers now makes data-type punning easy in a language that has no
> tradition of its appropriate, in-good-taste use.
> 
> Let me repeat myself.  COBOL is not a defensible language, but that is
> not important.   COBOL is, massively; and all those millions of lines
> of COBOL source must be dealt with.  They cannot be wished away, and
> they cannot be replaced at all readily in the short term.   They can
> perhaps be refurbished in ways that do not aggravate the problems
> their existence poses.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

Thomas Berg's notion that COBOL is hard to obfuscate is less true than
it once was.

REDEFINES has always had its obfuscatory uses; but the availability of
pointers now makes data-type punning easy in a language that has no
tradition of its appropriate, in-good-taste use.

Let me repeat myself.  COBOL is not a defensible language, but that is
not important.   COBOL is, massively; and all those millions of lines
of COBOL source must be dealt with.  They cannot be wished away, and
they cannot be replaced at all readily in the short term.   They can
perhaps be refurbished in ways that do not aggravate the problems
their existence poses.

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

Thomas,

I see your point ...writing in Cobol , because I must to support a product, I 
have used a bunch of assembler routines, we are converting to C

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 1:47 PM, Thomas Berg  wrote:

> Some suggestions: 
> 
> * GO TO's from in the middle of one SECTION into the middle of another.  And 
> then GO TO back again depending on a "switch"...
> * Programs with nested PERFORMS (*only* PERFORMS!) in maybe 7 levels ending 
> in a CALL of another module.
> * Field name (variable) in (e g) MOVE statement qualified resulting in more 
> than 100 characters, then add the matching length for the corresponding 
> field. 
>  (Take this times 1000 fields...)
> * Processing the same data sometimes in a character defined field, sometimes 
> in numeric defined fields (several different numeric formats for the same 
> data) without any reasonable explanation. 
> * Need to check four or five different result fields (depending on the 
> situation etc.) for eventual error from the CALL of another module. 
> 
> And other I have forgotten...
> 
> 
> 
> Regards
> Thomas Berg
> 
> Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)
> 
>> -Ursprungligt meddelande-
>> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> För Scott Ford
>> Skickat: den 16 februari 2013 21:26
>> Till: IBM-MAIN@LISTSERV.UA.EDU
>> Ämne: Re: SV: Article for the boss: COBOL will outlive us all
>> 
>> Thomas,
>> 
>> I don't follow, writing in several languages , what awkward to do in
>> cobol, supervisory stuff yes for sure.
>> 
>> Scott ford
>> www.identityforge.com
>> 
>> Tell me and I'll forget; show me and I may remember; involve me and
>> I'll understand. - Chinese Proverb
>> 
>> 
>> On Feb 16, 2013, at 2:53 PM, Thomas Berg 
>> wrote:
>> 
>>>> -Ursprungligt meddelande-
>>>> Från: IBM Mainframe Discussion List [mailto:IBM-
>> m...@listserv.ua.edu]
>>>> För John Gilmore
>>>> Skickat: den 16 februari 2013 20:25
>>>> Till: IBM-MAIN@LISTSERV.UA.EDU
>>>> Ämne: Re: Article for the boss: COBOL will outlive us all
>>>> 
>>>> Tony H wrote
>>>> 
>>>> | Now back to our regular COBOL, uh,  programming.
>>>> 
>>>> thus alluding to how many of us view of the language.
>>>> 
>>>> Over a now long career I never took COBOL seriously.  I was aware of
>>>> it, and I even learned to write it by helping COBOL programmers with
>>>> their problems.  It is a verbose but finally very simple language.
>>>> That said, I could not, and did not, think much of a language
>> without
>>>> real storage management, strings, pointers, booleans, etc., etc.  It
>>>> was move-oriented, compile-time bound, and synchronous, and I find
>>>> these characteristics despicable.
>>> 
>>> COBOL is certainly not a programmers language. It's very restricted
>> by its syntax and functionality and is often very clumsy to use.
>>> But that is also a feature: it's hard to obfuscate - which can be
>> seen as an asset from the point of maintenance and security.
>>> (Which do not mean that you can't make unintelligible programs - I
>> have seen many - but not at the lowest level.)
>>> It's also helpful when you need to understand the underlying data
>> structure the program is based on.
>>> 
>>> 
>>> 
>>> Regards
>>> Thomas Berg
>>> 
>>> Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)
>>> 
>>> -
>> -
>>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

SV: SV: Article for the boss: COBOL will outlive us all

[Thomas Berg]

Some suggestions: 

* GO TO's from in the middle of one SECTION into the middle of another.  And 
then GO TO back again depending on a "switch"...
* Programs with nested PERFORMS (*only* PERFORMS!) in maybe 7 levels ending in 
a CALL of another module.
* Field name (variable) in (e g) MOVE statement qualified resulting in more 
than 100 characters, then add the matching length for the corresponding field. 
  (Take this times 1000 fields...)
* Processing the same data sometimes in a character defined field, sometimes in 
numeric defined fields (several different numeric formats for the same data) 
without any reasonable explanation. 
* Need to check four or five different result fields (depending on the 
situation etc.) for eventual error from the CALL of another module. 

And other I have forgotten...



Regards
Thomas Berg

Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För Scott Ford
> Skickat: den 16 februari 2013 21:26
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: SV: Article for the boss: COBOL will outlive us all
> 
> Thomas,
> 
> I don't follow, writing in several languages , what awkward to do in
> cobol, supervisory stuff yes for sure.
> 
> Scott ford
> www.identityforge.com
> 
> Tell me and I'll forget; show me and I may remember; involve me and
> I'll understand. - Chinese Proverb
> 
> 
> On Feb 16, 2013, at 2:53 PM, Thomas Berg 
> wrote:
> 
> >> -Ursprungligt meddelande-
> >> Från: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> För John Gilmore
> >> Skickat: den 16 februari 2013 20:25
> >> Till: IBM-MAIN@LISTSERV.UA.EDU
> >> Ämne: Re: Article for the boss: COBOL will outlive us all
> >>
> >> Tony H wrote
> >>
> >> | Now back to our regular COBOL, uh,  programming.
> >>
> >> thus alluding to how many of us view of the language.
> >>
> >> Over a now long career I never took COBOL seriously.  I was aware of
> >> it, and I even learned to write it by helping COBOL programmers with
> >> their problems.  It is a verbose but finally very simple language.
> >> That said, I could not, and did not, think much of a language
> without
> >> real storage management, strings, pointers, booleans, etc., etc.  It
> >> was move-oriented, compile-time bound, and synchronous, and I find
> >> these characteristics despicable.
> >
> > COBOL is certainly not a programmers language. It's very restricted
> by its syntax and functionality and is often very clumsy to use.
> > But that is also a feature: it's hard to obfuscate - which can be
> seen as an asset from the point of maintenance and security.
> > (Which do not mean that you can't make unintelligible programs - I
> have seen many - but not at the lowest level.)
> > It's also helpful when you need to understand the underlying data
> structure the program is based on.
> >
> >
> >
> > Regards
> > Thomas Berg
> > 
> > Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: Article for the boss: COBOL will outlive us all

[zMan]

Can you do that for fields in an existing copybook?

On Sun, Feb 17, 2013 at 11:36 AM, David Andrews  wrote:

> On Sat, 2013-02-16 at 16:14 -0500, zMan wrote:
> > If this was supposed to be asking "What is it that's awkward to do in
> > COBOL?", try calculating the offset between two data elements.
>
> It's possible.  Not pretty, but IMO beats resorting to an assembly
> language subroutine.
>
> 01  POINTER-ARITHMETIC.
> 05  FIELD1-ADDRESS  POINTER.
> 05  FIELD1-ADDRESSD REDEFINES FIELD1-ADDRESS
> PIC 9(8) COMP-5.
> 05  FIELD2-ADDRESS  POINTER.
> 05  FIELD2-ADDRESSD REDEFINES FIELD2-ADDRESS
> PIC 9(8) COMP-5.
>
> SET FIELD1-ADDRESS TO ADDRESS OF FIELD1.
> SET FIELD2-ADDRESS TO ADDRESS OF FIELD2.
> COMPUTE FIELD-OFFSET = FIELD2-ADDRESSD - FIELD1-ADDRESSD.
>
> --
> David Andrews
> A. Duda & Sons, Inc.
> david.andr...@duda.com
>
> --
> 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: SV: Article for the boss: COBOL will outlive us all

[David Andrews]

On Sat, 2013-02-16 at 16:14 -0500, zMan wrote:
> If this was supposed to be asking "What is it that's awkward to do in
> COBOL?", try calculating the offset between two data elements.

It's possible.  Not pretty, but IMO beats resorting to an assembly
language subroutine.

01  POINTER-ARITHMETIC. 
05  FIELD1-ADDRESS  POINTER. 
05  FIELD1-ADDRESSD REDEFINES FIELD1-ADDRESS 
PIC 9(8) COMP-5. 
05  FIELD2-ADDRESS  POINTER. 
05  FIELD2-ADDRESSD REDEFINES FIELD2-ADDRESS 
PIC 9(8) COMP-5. 

SET FIELD1-ADDRESS TO ADDRESS OF FIELD1. 
SET FIELD2-ADDRESS TO ADDRESS OF FIELD2. 
COMPUTE FIELD-OFFSET = FIELD2-ADDRESSD - FIELD1-ADDRESSD.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

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

Re: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

Ed and John,

Sometimes because of circumstances programmers get locked into their positions 
because no 
opportunities inside the Company or because they are too good at what they do. 
I was in operations and that happened.  

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 10:45 AM, Ed Gould  wrote:

> John:
> 
> Well we are both right. COBOL types are essentially slaves. As we all know 
> there are two (maybe three) kind of slaves.
> 1. Just coders. 2. Coders with a want to learn 3. Coders who have an 
> imagination.
> 
> Ed
> 
> 
> On Feb 17, 2013, at 7:47 AM, John Gilmore wrote:
> 
>> Ed Gould wrote:
>> 
>> 
>> I suspect COBOL programmers want to lean how to basically code COBOL
>> programs and how to debug them PERIOD
>> 
>> 
>> I instead suspect that EG has described what the managers of these
>> COBOL programmers want them to learn.
>> 
>> G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
>> things work, 2) craftsmanship, the need to do the  best job one knows
>> how to do, and 3) a desire for recognition, even fame, are sine quibus
>> non for success at any intellectual task.
>> 
>> Managers who employ programmers who lack these three characteristics
>> get the mediocrity they deserve.
>> 
>> It is already clear that in the near-term future almost all real
>> programming will be done by hardware vendors, ISVs, and hobbyists; and
>> this is as well.
>> 
>> Mediocrity as a desideratum is a very curious notion.  When, long ago,
>> my wife and I sought an obstetrician to deliver our children we did
>> not set out to find a minimally adequate one.  Or again, when recently
>> I needed legal advice I did not seek out a lawyer who was not
>> overqualified.
>> 
>> It is hard to resist the conclusion that these managers, who are not
>> themselves programmers, have, with no understanding of the 'skill set'
>> that programmers need, taken refuge yet again in crackpot realism.
>> Production lines, particularly those that are highly automated, can be
>> managed.  Programming projects must be led.
>> 
>> John Gilmore, Ashland, MA 01721 - USA
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: Article for the boss: COBOL will outlive us all

[Ed Gould]

John:

Well we are both right. COBOL types are essentially slaves. As we all  
know there are two (maybe three) kind of slaves.
1. Just coders. 2. Coders with a want to learn 3. Coders who have an  
imagination.


Ed


On Feb 17, 2013, at 7:47 AM, John Gilmore wrote:


Ed Gould wrote:


I suspect COBOL programmers want to lean how to basically code COBOL
programs and how to debug them PERIOD


I instead suspect that EG has described what the managers of these
COBOL programmers want them to learn.

G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
things work, 2) craftsmanship, the need to do the  best job one knows
how to do, and 3) a desire for recognition, even fame, are sine quibus
non for success at any intellectual task.

Managers who employ programmers who lack these three characteristics
get the mediocrity they deserve.

It is already clear that in the near-term future almost all real
programming will be done by hardware vendors, ISVs, and hobbyists; and
this is as well.

Mediocrity as a desideratum is a very curious notion.  When, long ago,
my wife and I sought an obstetrician to deliver our children we did
not set out to find a minimally adequate one.  Or again, when recently
I needed legal advice I did not seek out a lawyer who was not
overqualified.

It is hard to resist the conclusion that these managers, who are not
themselves programmers, have, with no understanding of the 'skill set'
that programmers need, taken refuge yet again in crackpot realism.
Production lines, particularly those that are highly automated, can be
managed.  Programming projects must be led.

John Gilmore, Ashland, MA 01721 - USA

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


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

Re: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

This was handed down from my father to, craftsmanship, quality, understanding ..

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 9:15 AM, Scott Ford  wrote:

> John,
> 
> 
> 
> G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
> things work, 2) craftsmanship, the need to do the  best job one knows
> how to do, and 3) a desire for recognition, even fame, are sine quibus
> non for success at any intellectual task.
> 
> 
> 
> This is exactly how i feel ..amazing
> 
> 
> 
> Scott ford
> www.identityforge.com
> 
> Tell me and I'll forget; show me and I may remember; involve me and I'll 
> understand. - Chinese Proverb
> 
> 
> On Feb 17, 2013, at 8:47 AM, John Gilmore  wrote:
> 
>> G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
>> things work, 2) craftsmanship, the need to do the  best job one knows
>> how to do, and 3) a desire for recognition, even fame, are sine quibus
>> non for success at any intellectual task.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

John,



G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
things work, 2) craftsmanship, the need to do the  best job one knows
how to do, and 3) a desire for recognition, even fame, are sine quibus
non for success at any intellectual task.



This is exactly how i feel ..amazing



Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 17, 2013, at 8:47 AM, John Gilmore  wrote:

> G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
> things work, 2) craftsmanship, the need to do the  best job one knows
> how to do, and 3) a desire for recognition, even fame, are sine quibus
> non for success at any intellectual task.

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

Re: SV: Article for the boss: COBOL will outlive us all

[John Gilmore]

Ed Gould wrote:


I suspect COBOL programmers want to lean how to basically code COBOL
programs and how to debug them PERIOD


I instead suspect that EG has described what the managers of these
COBOL programmers want them to learn.

G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
things work, 2) craftsmanship, the need to do the  best job one knows
how to do, and 3) a desire for recognition, even fame, are sine quibus
non for success at any intellectual task.

Managers who employ programmers who lack these three characteristics
get the mediocrity they deserve.

It is already clear that in the near-term future almost all real
programming will be done by hardware vendors, ISVs, and hobbyists; and
this is as well.

Mediocrity as a desideratum is a very curious notion.  When, long ago,
my wife and I sought an obstetrician to deliver our children we did
not set out to find a minimally adequate one.  Or again, when recently
I needed legal advice I did not seek out a lawyer who was not
overqualified.

It is hard to resist the conclusion that these managers, who are not
themselves programmers, have, with no understanding of the 'skill set'
that programmers need, taken refuge yet again in crackpot realism.
Production lines, particularly those that are highly automated, can be
managed.  Programming projects must be led.

John Gilmore, Ashland, MA 01721 - USA

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

Re: SV: Article for the boss: COBOL will outlive us all

[Bernd Oppolzer]

Same goes for COBOL, PL/1 and even C.

My Managers tell me, that everything has to be converted to Java,
because - for example - PL/1 people are far too expensive.
They don't count, that the new applications written in Java have a
inferior quality compared with the existing PL/1-ASS-C application
and they don't meet our business needs (response time, scalability etc.).
Anyway, they continue to go this path, very aggressively. The costs for
the migration explode, but that doesn't matter, because management
is not able to see (and to admit) that the migration path leads nowhere.

Kind regards

Bernd



Am 16.02.2013 22:43, schrieb Scott Ford:

zMan,

But there are manglers , aka managers who say Assembler ode is hard to maintain 
because of te skillset required.

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 16, 2013, at 4:35 PM, Scott Ford  wrote:


Ba zing ...ok zMan, I agree I write Assembler, C ...on the MF ..I agree 
..multi-tasking is a bit rough

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb





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

Re: Article for the boss: COBOL will outlive us all

[Scott Ford]

Ed,

That's an excellent suggestion ...

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 16, 2013, at 7:41 PM, Ed Gould  wrote:

> On Feb 16, 2013, at 2:15 PM, John Gilmore wrote:
>> ---SNIP--
>> The culture of most COBOL shops is so complacent that disruptive
>> technology is very hard to teach in them.  It is not, I am sure,
>> impossible; but it is almost certainly uneconomic.
>> .
> 
> John (and Steve),
> 
> I suspect COBOL programmers want to lean how to basically code COBOL programs 
> and how to debug them PERIOD.
> 
> I would suggest that any advanced facilities be taught in a separate class 
> only for programmers that want to be adventerous.
> 
> COBOL programmers are under the gun to be (if you must) work horses and 
> nothing else.
> 
> Ed
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Article for the boss: COBOL will outlive us all

[Ed Gould]

On Feb 16, 2013, at 2:15 PM, John Gilmore wrote:
--- 
SNIP--

The culture of most COBOL shops is so complacent that disruptive
technology is very hard to teach in them.  It is not, I am sure,
impossible; but it is almost certainly uneconomic.
.


John (and Steve),

I suspect COBOL programmers want to lean how to basically code COBOL  
programs and how to debug them PERIOD.


I would suggest that any advanced facilities be taught in a separate  
class only for programmers that want to be adventerous.


COBOL programmers are under the gun to be (if you must) work horses  
and nothing else.


Ed

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

Re: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

zMan,

But there are manglers , aka managers who say Assembler ode is hard to maintain 
because of te skillset required.

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 16, 2013, at 4:35 PM, Scott Ford  wrote:

> Ba zing ...ok zMan, I agree I write Assembler, C ...on the MF ..I agree 
> ..multi-tasking is a bit rough
> 
> Scott ford
> www.identityforge.com
> 
> Tell me and I'll forget; show me and I may remember; involve me and I'll 
> understand. - Chinese Proverb
> 
> 
> On Feb 16, 2013, at 4:14 PM, zMan  wrote:
> 
>> On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford  wrote:
>> 
>>> Thomas,
>>> 
>>> I don't follow, writing in several languages , what awkward to do in
>>> cobol, supervisory stuff yes for sure.
>> 
>> Yoda? Is that you? :-)
>> 
>> If this was supposed to be asking "What is it that's awkward to do in
>> COBOL?", try calculating the offset between two data elements. For one. I
>> know that every time I go to write something in it, I run up against "You
>> just can't do that in this language" and my response is "Seriously? Wow."
>> (OK, or I write an assembler function to enable what I need...)
>> 
>> Admittedly, COBOL isn't as bad as I'd been led to believe by three decades
>> of avoiding it -- but as the saying goes, "You can write your program in
>> , or you can write a story about your program in COBOL".
>> -- 
>> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

Ba zing ...ok zMan, I agree I write Assembler, C ...on the MF ..I agree 
..multi-tasking is a bit rough

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 16, 2013, at 4:14 PM, zMan  wrote:

> On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford  wrote:
> 
>> Thomas,
>> 
>> I don't follow, writing in several languages , what awkward to do in
>> cobol, supervisory stuff yes for sure.
>> 
> 
> Yoda? Is that you? :-)
> 
> If this was supposed to be asking "What is it that's awkward to do in
> COBOL?", try calculating the offset between two data elements. For one. I
> know that every time I go to write something in it, I run up against "You
> just can't do that in this language" and my response is "Seriously? Wow."
> (OK, or I write an assembler function to enable what I need...)
> 
> Admittedly, COBOL isn't as bad as I'd been led to believe by three decades
> of avoiding it -- but as the saying goes, "You can write your program in
> , or you can write a story about your program in COBOL".
> -- 
> 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

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

Re: SV: Article for the boss: COBOL will outlive us all

[zMan]

On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford  wrote:

> Thomas,
>
> I don't follow, writing in several languages , what awkward to do in
> cobol, supervisory stuff yes for sure.
>

Yoda? Is that you? :-)

If this was supposed to be asking "What is it that's awkward to do in
COBOL?", try calculating the offset between two data elements. For one. I
know that every time I go to write something in it, I run up against "You
just can't do that in this language" and my response is "Seriously? Wow."
(OK, or I write an assembler function to enable what I need...)

Admittedly, COBOL isn't as bad as I'd been led to believe by three decades
of avoiding it -- but as the saying goes, "You can write your program in
, or you can write a story about your program in COBOL".
-- 
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: SV: Article for the boss: COBOL will outlive us all

[Scott Ford]

Thomas,

I don't follow, writing in several languages , what awkward to do in cobol, 
supervisory stuff yes for sure. 

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 16, 2013, at 2:53 PM, Thomas Berg  wrote:

>> -Ursprungligt meddelande-
>> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> För John Gilmore
>> Skickat: den 16 februari 2013 20:25
>> Till: IBM-MAIN@LISTSERV.UA.EDU
>> Ämne: Re: Article for the boss: COBOL will outlive us all
>> 
>> Tony H wrote
>> 
>> | Now back to our regular COBOL, uh,  programming.
>> 
>> thus alluding to how many of us view of the language.
>> 
>> Over a now long career I never took COBOL seriously.  I was aware of
>> it, and I even learned to write it by helping COBOL programmers with
>> their problems.  It is a verbose but finally very simple language.
>> That said, I could not, and did not, think much of a language without
>> real storage management, strings, pointers, booleans, etc., etc.  It
>> was move-oriented, compile-time bound, and synchronous, and I find
>> these characteristics despicable.
> 
> COBOL is certainly not a programmers language. It's very restricted by its 
> syntax and functionality and is often very clumsy to use. 
> But that is also a feature: it's hard to obfuscate - which can be seen as an 
> asset from the point of maintenance and security. 
> (Which do not mean that you can't make unintelligible programs - I have seen 
> many - but not at the lowest level.) 
> It's also helpful when you need to understand the underlying data structure 
> the program is based on.  
> 
> 
> 
> Regards
> Thomas Berg
> 
> Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Article for the boss: COBOL will outlive us all

[John Gilmore]

Steve,

I too have taught courses in 'modern COBOL' in client shops.  I have
stopped doing so.  What I accomplished was to turn the brightest
younger programmers into disaffected employees because their managers
were unsupportive.  Some of them were, I suspect, already disaffected;
but I was blamed for their departures when they sought more
interesting employment.

The approach I suggested is, I think, a better one.  Teach COBOL to
some established, competent C  or assembly-language programmers.  This
can be done in three weeks iff, to use a wonderful word I recently
encountered, they are properly 'incentivated'.

It does need a different approach.  With such programmers, one need
only provide answers to the classic three questions:

o What are the data types?

o What operations can be performed on  them?

o How is the path of control among these operations specified?

emphasizing branch tables, iteration, and recursion, all of which are
now possible in COBOL, in answering this last question.

Then one provides a lot of competitive, ruthlessly criticized practice
in writing COBOL subroutines for which you have test bed/drivers in
place.

The culture of most COBOL shops is so complacent that disruptive
technology is very hard to teach in them.  It is not, I am sure,
impossible; but it is almost certainly uneconomic.
.

John Gilmore, Ashland, MA 01721 - USA

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

SV: Article for the boss: COBOL will outlive us all

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För John Gilmore
> Skickat: den 16 februari 2013 20:25
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: Article for the boss: COBOL will outlive us all
> 
> Tony H wrote
> 
> | Now back to our regular COBOL, uh,  programming.
> 
> thus alluding to how many of us view of the language.
> 
> Over a now long career I never took COBOL seriously.  I was aware of
> it, and I even learned to write it by helping COBOL programmers with
> their problems.  It is a verbose but finally very simple language.
> That said, I could not, and did not, think much of a language without
> real storage management, strings, pointers, booleans, etc., etc.  It
> was move-oriented, compile-time bound, and synchronous, and I find
> these characteristics despicable.

COBOL is certainly not a programmers language. It's very restricted by its 
syntax and functionality and is often very clumsy to use. 
But that is also a feature: it's hard to obfuscate - which can be seen as an 
asset from the point of maintenance and security. 
(Which do not mean that you can't make unintelligible programs - I have seen 
many - but not at the lowest level.) 
It's also helpful when you need to understand the underlying data structure the 
program is based on.  



Regards
Thomas Berg

Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)

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

Re: Article for the boss: COBOL will outlive us all

[Steve Comstock]

On 2/16/2013 12:25 PM, John Gilmore wrote:

Tony H wrote

| Now back to our regular COBOL, uh,  programming.

thus alluding to how many of us view of the language.

Over a now long career I never took COBOL seriously.  I was aware of
it, and I even learned to write it by helping COBOL programmers with
their problems.  It is a verbose but finally very simple language.
That said, I could not, and did not, think much of a language without
real storage management, strings, pointers, booleans, etc., etc.  It
was move-oriented, compile-time bound, and synchronous, and I find
these characteristics despicable.

Recently, however, it has been greatly improved, making, for example,
usable pointers and LIFO, local, i.e., 'automatic', storage available.
   It is now often possible to write something the way one wishes to
write it in COBOL.

These new facilities are not yet much used.   Some shops indeed
interdict their use as 'unnecessary'.  Their availability does
nonetheless make it possible to update a COBOL application using
appropriate, adult technology; and this is important because many
COBOL applications are so large that jettisoning them is, at least in
the short term, economically impractical.

Able but naif people often radically underestimate the resources and
time that will be required to convert a COBOL application to, say,
C/C++; and in the upshot they fail in their attempts to do so.   I
know of shops in which there have been four (sic) such failed
attempts.  New CIOs often launch a new one, the smartest of them going
on to greener pastures before its failure too becomes obvious.

It is, however, possible to refurbish and extend COBOL systems in
COBOL.  The trick in doing so is to use able programmers trained in a
different tradition whom you bribe to learn COBOL, avoiding [most]
experienced COBOL programmers as plague carriers or, better, using the
best of them only as consultants about how an application currently
works.

John Gilmore, Ashland, MA 01721 - USA



John,

We have been fighting that battle for, oh, twelve years
or more. We have courses that teach COBOL programmers
how to use the latest facilities in general and then
courses that teach specifics (especially handling XML,
working with Unicode, using LE services where appropriate,
coding and using DLLs, coding and running using z/OS UNIX
services, coding CGIs in COBOL, and more). But we don't
see much interest or enlightenment. Very frustrating.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Article for the boss: COBOL will outlive us all

[John Gilmore]

Tony H wrote

| Now back to our regular COBOL, uh,  programming.

thus alluding to how many of us view of the language.

Over a now long career I never took COBOL seriously.  I was aware of
it, and I even learned to write it by helping COBOL programmers with
their problems.  It is a verbose but finally very simple language.
That said, I could not, and did not, think much of a language without
real storage management, strings, pointers, booleans, etc., etc.  It
was move-oriented, compile-time bound, and synchronous, and I find
these characteristics despicable.

Recently, however, it has been greatly improved, making, for example,
usable pointers and LIFO, local, i.e., 'automatic', storage available.
  It is now often possible to write something the way one wishes to
write it in COBOL.

These new facilities are not yet much used.   Some shops indeed
interdict their use as 'unnecessary'.  Their availability does
nonetheless make it possible to update a COBOL application using
appropriate, adult technology; and this is important because many
COBOL applications are so large that jettisoning them is, at least in
the short term, economically impractical.

Able but naif people often radically underestimate the resources and
time that will be required to convert a COBOL application to, say,
C/C++; and in the upshot they fail in their attempts to do so.   I
know of shops in which there have been four (sic) such failed
attempts.  New CIOs often launch a new one, the smartest of them going
on to greener pastures before its failure too becomes obvious.

It is, however, possible to refurbish and extend COBOL systems in
COBOL.  The trick in doing so is to use able programmers trained in a
different tradition whom you bribe to learn COBOL, avoiding [most]
experienced COBOL programmers as plague carriers or, better, using the
best of them only as consultants about how an application currently
works.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Article for the boss: COBOL will outlive us all

[Tony Harminc]

On 16 February 2013 07:55, Timothy Sipples  wrote:

> For comparison -- and far worse when you think about it -- most automobiles
> have at least two ways of checking the oil level. One way is a binary
> readout, located on the dashboard. If the light is not illuminated, you
> have enough oil. If the light is illuminated, you don't. (I'm ignoring
> possible instrument failures.) The other way is to pull the hood (bonnet)
> release lever usually located inside the car, go to the front of the car
> (for front engine vehicles), pull the external hood release bar (which I
> can never remember how to do), lift the hood, unscrew the oil cap, remove
> the dipstick, clean the dipstick, insert the dipstick, remove the dipstick,
> and read the oil level

That oil light (or gauge, if you have an old or very upscale new car)
is measuring/displaying oil *pressure*, not level. They are related,
to be sure, but not in a simple way. Interestingly, each can be
reliably measured only under conditions where the other can't. And of
course neither is what you really want to know about; both are proxies
for something of actual importance.

Now back to our regular COBOL, uh,  programming.

Tony H.

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

Re: Article for the boss: COBOL will outlive us all

[Timothy Sipples]

Dana Mitchell writes:
>That's the rub, there isn't a readily accessable command line
>available,  a real 5250 emulator session is still required.

OK, if that's a concern stick the 5250 interface in a Host On-Demand
session (for example) and plop that in your Web "portal." Or don't even do
that. We have these things called PCs (and Macs) with user interfaces that
support at least two windows, and Alt-Tab (or Command-Tab) is one way among
many to toggle between them. Copy/paste seems to work, too.

If an administrator has to run down the hall, past the water cooler, up six
flights of stairs, across the factory floor, over a bridge, then down a
rope ladder to get to the command line, then reverse the process to get to
the Web/graphical user interface, that might be a problem, although it
would promote physical fitness. I'm not aware of any operating systems
which require that degree of effort or anything like it.

Yes, I'm being facetious. More seriously, tell the vendor (IBM in this
case) -- through the appropriate channels -- what functions are missing in
the Web/graphical user interface that you'd like to see added. Quite often
the vendor will add the functions so you don't have to Alt-Tab.

For comparison -- and far worse when you think about it -- most automobiles
have at least two ways of checking the oil level. One way is a binary
readout, located on the dashboard. If the light is not illuminated, you
have enough oil. If the light is illuminated, you don't. (I'm ignoring
possible instrument failures.) The other way is to pull the hood (bonnet)
release lever usually located inside the car, go to the front of the car
(for front engine vehicles), pull the external hood release bar (which I
can never remember how to do), lift the hood, unscrew the oil cap, remove
the dipstick, clean the dipstick, insert the dipstick, remove the dipstick,
and read the oil level Oh, sod it, I forgot my flashlight, and this
synthetic stuff is the same color as the dipstick anyway. Add oil if
required. Reinsert the dipstick, screw the oil cap, close the hood, and
drive off, perhaps with miscellaneous engine parts falling behind you like
breadcrumbs.

The analog dipstick, if readable, is more precise than the dashboard
indicator, but it's very hard to use the underhood user interface while the
car is in motion. And you can't Alt-Tab or copy/paste between these two
user interfaces on the same automobile. They also tell somewhat different
stories. The indicator light may indicate problems getting oil into the
engine in addition to oil level problems. It's a user interface design
catastrophe, I tell you!

Of course most drivers ignore the indicator light and wouldn't know how to
check the oil level via the underhood interface, so it really doesn't
matter. :-)


Timothy Sipples
Consulting Enterprise IT Architect (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Article for the boss: COBOL will outlive us all

[Shane Ginnane]

On Wed, 13 Feb 2013 10:44:26 -0600, Dana Mitchell wrote:

>I've been reading the same theory as it applied to us Systems Programmers the 
>last few years.  Mass retirement making the remaining sysprogs highly sought 
>after and compensated.   Well, I've personally seen lots of retirements,  but 
>due to the combination of outsourcing,  business acquisitions, 
>do-more-with-less etc,  I haven't seen demand locally rising sharply yet.

Indeed. In this part of the world the whole business has gone to hell in a 
hand-basket.
It seems the prophesy (for us) become self-defeating; no-one who has a sysprog 
job is game to make noises about moving. Nowhere else to go, so sit tight till 
they are prised out. Hopefully with a package to ease the angst.

Shane ...

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

Re: Article for the boss: COBOL will outlive us all

[Anne & Lynn Wheeler]

jlturr...@centurytel.net (Leslie Turriff) writes:
>   Not so much a mistake as short-sightedness; before 3270s were 
> available, 
> keypunches could only do upper-case (without jumping through hoops), so 
> mixed-case names were probably considered unneccessary.
>   I also remember when, in CICS, one wanted to use mixed-case or 
> alternate 
> code-pages, additional reads of the data stream were required because CICS, 
> in its wisdom, folded everything to upper-case before presenting it to the 
> application.

re:
http://www.garlic.com/~lynn/2013b.html#43 Article for the boss: COBOL will 
outlive us all
http://www.garlic.com/~lynn/2013b.html#45 Article for the boss: COBOL will 
outlive us all
http://www.garlic.com/~lynn/2013b.html#51 Article for the boss: COBOL will 
outlive us all

7094/ctss, cp40/cms, cp67/cms, etc were online, interactive system with
1052s, 2741s terminals (not card/keypunch batch systems) ... which were
upper/lower case selectric typewriters with computer interface.
http://www.multicians.org/thvv/7094.html

from above:

By 1963, CTSS provided remote terminal service to dial-up terminals
connected by modem to a specialized telecommunications computer, the IBM
7750. Model 35 Teletypes were used at first, followed by IBM 1050
terminals and IBM 2741s. The 7750 and the IBM Selectric terminals were
designed for other uses, such as stock trading and airline reservations,
and CTSS adapted to the design of these devices. CTSS did specify that
certain RPQs had to be added to the 2741, so that its keyboard would not
lock up after every line, and also required that remote terminals on
CTSS have a "terminal ID" that would be sent at dialup time. CTSS users
would look at the output of Noel Morris's who command to see where their
friends and colleagues were connecting to the system from. Terminal
access for Teletype terminals was at 110 baud. The 1050 and 2741
terminals could support 134.5 baud. All of these devices were supported
over dial-up modems, accessed via a private phone exchange at MIT. 

... snip ...

i had 2741 terminal at home from mar1970 to summer 1977 ... when i
switch to 300baud cdi miniterm.

cp67/cms delivered to univ. jan1968 had 1052 & 2741 terminal
support. univ. had some tty terminals ... and i added the tty terminal
support.
http://www.multicians.org/thvv/360-67.html

i had done hack with one byte arithmetic line-length limited to less
than 256. above mentions Tom changing configuration to specify (i think
ascii plotter device down at harvard) max line length of 1200 chars
... but didn't fix the instructions using one byte

cms script (done mid-60s port of ctss runoff) was documentation
preparation ... was extensive upper/lower case. one of the early major
ibm documents moved to cms script was principles of operation.  The full
documentation was the architecture "redbook" (for distribution in red
3ring binders). cms script command line operation would produce the full
redbook or the principles of operation subset (i.e. full redbook had
lots of extra detail in each section and every instruction description).

then gml was invented at the science center 1969 (g, m, & l chosen for
the first letters of the last names of the inventors) ... and gml tag
processing added to cms script. some past posts
http://www.garlic.com/~lynn/submain.html#sgml

decade later, gml morphs into iso standard sgml.

another decade, sgml morphs into html at cern ...
http://infomesh.net/html/history/early

coming full circle ... first webserver in us (outside europe) was
on the vm370/cms system at slac
http://www.slac.stanford.edu/history/earlyweb/history.shtml

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

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

Re: Article for the boss: COBOL will outlive us all

[Leslie Turriff]

On Wednesday 13 February 2013 16:17:28 Phil Smith wrote:
> R.S. wrote:
> > BTW: My argument against Unix behavior: I cannot distinguish MyFiLE and
> > MYfiLe during phone call. Even spelling is simpler for M-y-f-I-L-e than
> > for "Upper M - Upper Y...".
>
> Indeed. I'd put it more strongly: Case sensitivity for *IX filesystems
> offers NO benefit that anyone has ever been able to articulate to me. If
> you ask a *IX person, they act like it's just "obviously" A Good Thing, but
> can never express why. And if you ask them if they've ever created
> /something/abc and /something/Abc or any of the other possible values, they
> say "No".
>
> I think Windows got this one right. And a decade of asking for a
> counter-argument has failed to produce anything useful.
Not just Windows; my old AmigaOS machines, the TI99/4 and (I think) 
Atari and 
Apple machines all allowed creation of mixed-case names and treated them as 
case-insensitive afterwards.  It seems that only the *nix wannabes insist on 
case-sensitive names.
The distinction is occasionally useful, mostly for files that are not 
intended to be accessed directly by users.
>
> (Oddly, the one quasi-counter-argument is CMS, where you have to work at it
> to create/use a file with lowercase in the fileid-but that's a different
> kettle of hamsters, since it's more a byproduct of an historical mistake
> than a deliberate feature, and not the same at all as *IX.) --
Not so much a mistake as short-sightedness; before 3270s were 
available, 
keypunches could only do upper-case (without jumping through hoops), so 
mixed-case names were probably considered unneccessary.
I also remember when, in CICS, one wanted to use mixed-case or 
alternate 
code-pages, additional reads of the data stream were required because CICS, 
in its wisdom, folded everything to upper-case before presenting it to the 
application.

Leslie

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

Re: Article for the boss: COBOL will outlive us all

[Anne & Lynn Wheeler]

p...@voltage.com (Phil Smith) writes:
> Indeed. I'd put it more strongly: Case sensitivity for *IX filesystems
> offers NO benefit that anyone has ever been able to articulate to
> me. If you ask a *IX person, they act like it's just "obviously" A
> Good Thing, but can never express why. And if you ask them if they've
> ever created /something/abc and /something/Abc or any of the other
> possible values, they say "No".
>
> I think Windows got this one right. And a decade of asking for a
> counter-argument has failed to produce anything useful.
>
> (Oddly, the one quasi-counter-argument is CMS, where you have to work
> at it to create/use a file with lowercase in the fileid-but that's a
> different kettle of hamsters, since it's more a byproduct of an
> historical mistake than a deliberate feature, and not the same at all
> as *IX.)
> --

re:
http://www.garlic.com/~lynn/2013b.html#43 Article for the boss: COBOL will 
outlive us all
http://www.garlic.com/~lynn/2013b.html#45 Article for the boss: COBOL will 
outlive us all

note that some of the people from 7094/CTSS went to the science center
on the 4th flr and did virtual machines ... initially cp40/cms on a
360/40 that had special hardware changes that implemented virtual memory
... it later morphs into cp67/cms ... when 360/67 with virtual memory
standard comes available ... later morphs into vm370/cms.
http://en.wikipedia.org/wiki/CP/CMS

other from 7094/CTSS go to the 5th flr and do MULTICS. Lore is some of
the AT&T people that had gone to work on MULTICS ... return and do
simplified version as UNIX.
http://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
and
http://en.wikipedia.org/wiki/MULTICS

from above:

The design and features of Multics greatly influenced the Unix operating
system, which was originally written by two ex-programmers from the
older project, Ken Thompson and Dennis Ritchie. Superficial influence of
Multics on Unix is evident in many areas, including the naming of
commands (such as "ls" to "list segments" or files). But the internal
design philosophy was quite different, focusing on keeping the system
small and simple, and so correcting some deficiencies of Multics because
of its high resource demands on the limited computer hardware of the
time.

The name Unix (originally Unics) is itself a pun on Multics. The U in
Unix is rumored to stand for uniplexed as opposed to the multiplexed of
Multics, further underscoring the designers' rejections of Multics'
complexity in favor of a more straightforward and workable approach for
smaller computers. (Garfinkel and Abelson [10] cite an alternative
origin: Peter Neumann at Bell Labs, watching a demonstration of the
prototype, suggested the name/pun UNICS (pronounced "Eunuchs"), as a
"castrated Multics".)

... snip ... 

I world periodically kid around with people on the 5th flr about the
total number multics installations versus vm370/cms. i said that it
wasn't fair to compare with the total number of vm370/cms installations
or even the total number of internal corporate vm370/cms installations
... but one of my hobbies was producing production systems for internal
datacenters ... and would just compare the number of vm370/cms systems I
supported as larger than the total number of Multics systems.

and as for ms/dos
http://en.wikipedia.org/wiki/MS-DOS
before ms/dos there was seattle computer
http://en.wikipedia.org/wiki/Seattle_Computer_Products
and before seattle computer there was cp/m
http://en.wikipedia.org/wiki/CP/M
and before cp/m, kildall worked on cp67/cms at npg school
(gone 404 but lives on at wayback machine)
http://web.archive.org/web/20071011100440/http://www.khet.net/gmc/docs/museum/en_cpmName.html
npg reference
http://en.wikipedia.org/wiki/Naval_Postgraduate_School

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

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

Re: Article for the boss: COBOL will outlive us all

[Lloyd Fuller]

This is also a great way to hide files from casual users:  make the name 
unprintable characters and they do not see the file.

Or make it read only on a writable disk:  use lower case or unprintable 
characters in the name.  Without a program it is difficult to overwrite, read, 
or delete the file.  Been bit more than once.  :-)

Lloyd



- Original Message 
From: Phil Smith 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, February 13, 2013 5:17:35 PM
Subject: Re: Article for the boss: COBOL will outlive us all


(Oddly, the one quasi-counter-argument is CMS, where you have to work at it to 
create/use a file with lowercase in the fileid-but that's a different kettle of 
hamsters, since it's more a byproduct of an historical mistake than a 
deliberate 
feature, and not the same at all as *IX.)
--
...phsiii

Phil Smith III


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

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

Re: Article for the boss: COBOL will outlive us all

[Dana Mitchell]

On Fri, 15 Feb 2013 14:24:35 +0800, Timothy Sipples  wrote:
>
>That said, if the command line is readily accessible from the graphical/Web
>interface, I don't see the problem. 

That's the rub, there isn't a readily accessable command line available,  a 
real 5250 emulator session is still required.

Dana

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

Re: Article for the boss: COBOL will outlive us all

[Timothy Sipples]

Dana Mitchell writes:
>The trouble is that not *all* functions can be performed from a 5250
>session.  Conversely not all functions can be executed from any one of
>the gui's either.  This creates a dog's dinner of interfaces required
>to perform all the duties needed to be an admin on an i system.

With the exception of the classic Mac OS (which didn't have a command line
per se and wasn't really a server operating system), I'm hard pressed to
think of any server operating system that doesn't have the same split. The
ratios and overlap may vary and evolve, but there are always times when the
command line is essential and times when the graphical/Web interface is
essential for administration. Even in Mac OS X (Step 1: Open Terminal, Step
2: ).

That said, if the command line is readily accessible from the graphical/Web
interface, I don't see the problem. Routine/common tasks are point and
click, and the more arcane/infrequent stuff is available through commands.


Timothy Sipples
Consulting Enterprise IT Architect (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Article for the boss: COBOL will outlive us all

[Anne & Lynn Wheeler]

donb...@gmail.com (Don Williams) writes:
> 18,000 companies w/MFs world-wide? Seems low. 

re:
http://www.garlic.com/~lynn/2013b.html#43 Article for the boss: COBOL will 
outlive us all

estimate that there are 10k world-wide at 4k to 5k customers
http://articles.economictimes.indiatimes.com/2010-08-10/news/27620495_1_mainframe-ibm-big-challenge

this claims 15,000 installations
http://www.forbes.com/2010/01/18/mainframe-security-enterprise-technology-cio-network-woods.html

given mainframe processor revenue ... IBM has been selling approx.
equivalent of 180 z196/yr (max configured, 80 processor, @$28M)

2002 the claim was 38,000 systems.

with growth in processing power/system, installations could have done
quite a bit of system consolidation over the last decade.

z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012

a little over decade ago, I did some performance work on 450k statement
cobol application that ran every night on over 40 max configured
mainframe systems (@$30M, number of systems needed to finish during 3rd
shift window; made big deal that no system was over 18m old); getting
approx. 14% throughput improvement

workload hasn't increased significantly since then, but max. configured
mainframe performance has increased by factor of over 20 times.

recent post in similar thread about article in a.f.c.
http://www.garlic.com/~lynn/2013b.html#42 COBOL will outlive us all

misc. past posts mentioning work on 450k statement cobol app:
http://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in 
Mainframe?
http://www.garlic.com/~lynn/2007l.html#20 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007u.html#21 Distributed Computing
http://www.garlic.com/~lynn/2008c.html#24 Job ad for z/OS systems programmer 
trainee
http://www.garlic.com/~lynn/2008d.html#73 Price of CPU seconds
http://www.garlic.com/~lynn/2008l.html#81 Intel: an expensive many-core future 
is ahead of us
http://www.garlic.com/~lynn/2009d.html#5 Why do IBMers think disks are 'Direct 
Access'?
http://www.garlic.com/~lynn/2009e.html#76 Architectural Diversity
http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting
http://www.garlic.com/~lynn/2009g.html#20 IBM forecasts 'new world order' for 
financial services
http://www.garlic.com/~lynn/2011c.html#35 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011f.html#32 At least two decades back, some gurus 
predicted that mainframes would disappear
http://www.garlic.com/~lynn/2012i.html#25 Can anybody give me a clear idea 
about Cloud Computing in MAINFRAME ?

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

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

Re: Article for the boss: COBOL will outlive us all

[zMan]

On Thu, Feb 14, 2013 at 3:29 PM, Don Williams  wrote:

> 18,000 companies w/MFs world-wide? Seems low.


No it doesn't...seems high from what I hear. Of course there are no
official numbers, but *at their peak* ISTR 7K MVS, 20K VM, 5K VSE. And that
was a long time ago, like 1989, pre-x86 servers; even just with mergers
etc., those would be a lot smaller.

My SWAG is 3K for each nowadays, plus ~100 TPF; essentially no additional
Linux for System z, since the real shops running Linux on z are also
running z/VM.
-- 
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: Article for the boss: COBOL will outlive us all

[Don Williams]

The following is a simplistic wild guess.

Accord to SHARE: "SHARE serves more than 20,000 individuals representing
over 2,000 of IBM's top enterprise computing customers."
What percent of the SHARE members have IBM mainframes? 90%? That would be
1,800 share members w/MFs.
What percent of the world's companies with IBM mainframes are SHARE members?
10%? That would be 18,000 companies w/MFs world-wide.

On average, 10 individuals per company.
What percent of those individuals are mainframe systems programmers? 50%?
That would be 90,000 sysprogs world-wide.
What percent are z/OS? 25% That would be 22,500 z/OS sysprogs
world-wide.
What percent are z/VM? 25% That would be 22,500 z/VM sysprogs
world-wide.
What percent are z/Linux? 25% That would be 22,500 z/Linux sysprogs
world-wide.
etc.

18,000 companies w/MFs world-wide? Seems low. 

Don

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Joel C. Ewing
> Sent: Wednesday, February 13, 2013 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Article for the boss: COBOL will outlive us all
> 
> The referenced wikidot URL calling itself a "List of all companies"
> with
> mainframes is highly wishful thinking, as it appears to rely on
> voluntary contributions to its list  I notice there is only one company
> listed for all of AR (in Little Rock).  With my incomplete knowledge, I
> can easily think of four just in the NW quadrant of AR that aren't
> listed, so at this point the list is clearly very "partial" and hardly
> close to "all".
>  JC Ewing
> 
> On 02/13/2013 11:26 AM, Ken Porowski wrote:
> > One of the comments on that article left this link
> > http://mainframes.wikidot.com/ which claims to be a partial listing
> of
> > all Mainframe shops in the world.
> >
> > Ken
> >
> > ...
> >
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of John McKown
> > Sent: Wednesday, February 13, 2013 9:02 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [IBM-MAIN] Article for the boss: COBOL will outlive us all
> >
> > http://www.itworld.com/career/341879/cobol-will-outlive-us-all
> > 
> > ...
> >
> > The reason that I'm telling you about COBOL is that I predict that
> over
> > the next few years, new COBOL programmers are going to be in high
> demand
> > and very possibly paid a premium for their efforts. Generally
> speaking,
> > the COBOL programming skill set resides in baby boomers that have
> been
> > programming in COBOL their entire career. The issue is that these
> baby
> > boomers have begun retiring in enormous numbers. Additionally, new
> > college recruits have neither the skill set nor the interest in
> > replacing them. The problem for companies employing these COBOL
> > programmers is that if the software stops, so does the company.
> >
> > 
> >
> > --
> > This is a test of the Emergency Broadcast System. If this had been an
> > actual emergency, do you really think we'd stick around to tell you?
> >
> > Maranatha! <><
> > John McKown
> >
> > ...
> 
> 
> --
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Article for the boss: COBOL will outlive us all

[Ian]

Don,

I will work on adding a field for that.



On Thu, Feb 14, 2013 at 12:47 PM, Don Williams  wrote:

> It would be interesting to have a list shops by operating systems:
>
> 1. z/OS
> 2. z/VM
> 3. z/VSE
> 4. z/TPF
> 5. z/Linux
> etc.
>
> Don
>
>


-- 
Ian
http://www.cicsworld.com

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

Re: Article for the boss: COBOL will outlive us all

[Don Williams]

It would be interesting to have a list shops by operating systems:

1. z/OS
2. z/VM
3. z/VSE
4. z/TPF
5. z/Linux
etc.

Don

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Leslie Turriff
> Sent: Wednesday, February 13, 2013 12:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Article for the boss: COBOL will outlive us all
> 
> On Wednesday 13 February 2013 11:26:03 Ken Porowski wrote:
> > One of the comments on that article left this link
> > http://mainframes.wikidot.com/ which claims to be a partial listing
> of
> > all Mainframe shops in the world.
> >
> > Ken
> >
>   I sure wish there was a similar list of companies that run z/VM.
> :-)
> 
> Leslie
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Article for the boss: COBOL will outlive us all

[Don Williams]

When the rate of retirement, death, career change, etc. exceeds the influx of 
new talent, what happens when the pool of qualified employees shrinks below the 
minimum number needed to get the job done?

Seems like a company needs to insure that either 
1. More people are being trained to replenish the pool, or 
2. Switch to new technology that already has a sufficient supply. 

As previous posted, good old supply and demand means that as a pool of experts 
gets smaller, their value increases.
Each company will decide if and when the risk of switching to the new 
technology is cheaper than sticking with the old experts.

Don

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Dana Mitchell
> Sent: Wednesday, February 13, 2013 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Article for the boss: COBOL will outlive us all
> 
> I've been reading the same theory as it applied to us Systems
> Programmers the last few years.  Mass retirement making the remaining
> sysprogs highly sought after and compensated.   Well, I've personally
> seen lots of retirements,  but due to the combination of outsourcing,
> business acquisitions, do-more-with-less etc,  I haven't seen demand
> locally rising sharply yet.
> 
> Dana
> 
> On Wed, 13 Feb 2013 08:01:31 -0600, John McKown
>  wrote:
> 
> >http://www.itworld.com/career/341879/cobol-will-outlive-us-all
> >
> >...
> >
> >The reason that I�m telling you about COBOL is that I predict that
> over the
> >next few years, new COBOL programmers are going to be in high demand
> and
> >very possibly paid a premium for their efforts. Generally speaking,
> the
> >COBOL programming skill set resides in baby boomers that have been
> >programming in COBOL their entire career. The issue is that these baby
> >boomers have begun retiring in enormous numbers. Additionally, new
> college
> >recruits have neither the skill set nor the interest in replacing
> them. The
> >problem for companies employing these COBOL programmers is that if the
> >software stops, so does the company.
> >
> >
> >
> >--
> >This is a test of the Emergency Broadcast System. If this had been an
> >actual emergency, do you really think we'd stick around to tell you?
> >
> >Maranatha! <><
> >John McKown
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Misc Carping, Date Discussion, etc. [WAS Re: Article for the boss: COBOL will outlive us all]

[Steve Thompson]

From:   Paul Gilmartin 
Date:   02/14/2013 09:23 AM


On Thu, 14 Feb 2013 13:26:02 +, Pew, Curtis G wrote:

>On Feb 14, 2013, at 2:11 AM, Martin Packer  
wrote:
>
>> Not saying you're wrong but OSX is based on Unix.
>
>OS X is Unix, but the HFS+ file system it uses comes from the old Mac OS 
and is case insensitive but case preserving.
> 
For those who haven't been paying attention, recent releases of
OS X allow formatting an HFS + filesystem as case sensitive.  I
believe this is required for UNIX compliance.
--

Concurrency for subject change anyone?

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

Re: Article for the boss: COBOL will outlive us all

[Ian]

Here is another Partial list and map of z/Shops:
http://cicsworld.com/map/node

I totally rely on members adding shops to the list.


On Wed, Feb 13, 2013 at 12:22 PM, Itschak Mugzach wrote:

> It is *very* partial list. There are about 25 mainframe shops in israel,
> only one is listed.
>
> ITschak
>
>
> On Wed, Feb 13, 2013 at 7:26 PM, Ken Porowski 
> wrote:
>
> > One of the comments on that article left this link
> > http://mainframes.wikidot.com/ which claims to be a partial listing of
> > all Mainframe shops in the world.
> >
> > Ken
> >
> >
> >
> --
> > This email message and any accompanying materials may contain
> proprietary,
> > privileged and confidential information of CIT Group Inc. or its
> > subsidiaries or affiliates (collectively, "CIT"), and are intended solely
> > for the recipient(s) named above. If you are not the intended recipient
> of
> > this communication, any use, disclosure, printing, copying or
> distribution,
> > or reliance on the contents, of this communication is strictly
> > prohibited. CIT disclaims any liability for the review, retransmission,
> > dissemination or other use of, or the taking of any action in reliance
> > upon, this communication by persons other than the intended
> > recipient(s). If you have received this communication in error, please
> > reply to the sender advising of the error in transmission, and
> immediately
> > delete and destroy the communication and any accompanying materials. To
> the
> > extent permitted by applicable law, CIT and others may inspect, review,
> > monitor, analyze, copy, record and retain any communications sent from or
> > received at this email address.
> >
> --
> >
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of John McKown
> > Sent: Wednesday, February 13, 2013 9:02 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [IBM-MAIN] Article for the boss: COBOL will outlive us all
> >
> > http://www.itworld.com/career/341879/cobol-will-outlive-us-all
> > 
> > ...
> >
> > The reason that I'm telling you about COBOL is that I predict that over
> > the next few years, new COBOL programmers are going to be in high demand
> > and very possibly paid a premium for their efforts. Generally speaking,
> > the COBOL programming skill set resides in baby boomers that have been
> > programming in COBOL their entire career. The issue is that these baby
> > boomers have begun retiring in enormous numbers. Additionally, new
> > college recruits have neither the skill set nor the interest in
> > replacing them. The problem for companies employing these COBOL
> > programmers is that if the software stops, so does the company.
> >
> > 
> >
> > --
> > This is a test of the Emergency Broadcast System. If this had been an
> > actual emergency, do you really think we'd stick around to tell you?
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Ian
http://www.cicsworld.com

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

Re: Article for the boss: COBOL will outlive us all

[Dana Mitchell]

On Thu, 14 Feb 2013 11:07:49 -0500, Phil Smith III  wrote:

>a triumph of bad naming in the Internet era
>
>.phsiii
>

Phil,

Well said!!   Exactly

Dana

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

Re: Article for the boss: COBOL will outlive us all

[Phil Smith III]

Tom Marchant wrote, re:

>>On an i system (don't get me started on that choice of a name for an
operating system)

 

>Ok, I'll stir the pot.  What's wrong with iSeries or System i?

 

Nothing, except that those names are long dead. The System Formerly Known As
AS/400 is called "IBM i" nowadays - a triumph of bad naming in the Internet
era, since it's almost impossible to search on (you get lots of pages saying
"when I worked for IBM I used to." and the like). Just as "zSeries",
"pSeries", and "xSeries" are dead (since 2005!), the System i folks for some
reason decided that "System i" wasn't workable, and must have received a
papal dispensation to deviate from the corporate naming scheme. I find it
quite baffling.

 

.phsiii


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

Re: Article for the boss: COBOL will outlive us all

[Tom Marchant]

On Thu, 14 Feb 2013 06:50:46 -0600, Dana Mitchell wrote:

>On an i system (don't get me started on that choice of a name for an operating 
>system)

Ok, I'll stir the pot.  What's wrong with iSeries or System i?

-- 
Tom Marchant

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

Re: Article for the boss: COBOL will outlive us all

[Paul Gilmartin]

On Thu, 14 Feb 2013 13:26:02 +, Pew, Curtis G wrote:

>On Feb 14, 2013, at 2:11 AM, Martin Packer  wrote:
>
>> Not saying you're wrong but OSX is based on Unix.
>
>OS X is Unix, but the HFS+ file system it uses comes from the old Mac OS and 
>is case insensitive but case preserving.
>  
For those who haven't been paying attention, recent releases of
OS X allow formatting an HFS + filesystem as case sensitive.  I
believe this is required for UNIX compliance.

-- gil

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

Re: Article for the boss: COBOL will outlive us all

[Scott Ford]

Dana,

Thank you, my thoughts exactly. When I learned VM/SP and CMS had a manager make 
me learn the basic commands first then write Execs. 

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll 
understand. - Chinese Proverb


On Feb 14, 2013, at 7:50 AM, Dana Mitchell  wrote:

> On Wed, 13 Feb 2013 17:10:06 -0600, Ed Gould  wrote:
> 
>> Dana:
>> 
>> About 15 years ago I was in a IBM class (all sysprogs). The  
>> instructor came out and said it is IBM's hope to get rid of system  
>> programmers. That tells you a lot from IBM's POV. I have distrusted  
>> IBM ever since.
>> 
>> Ed
> 
> IBM's plans as far as expensive sysprogs is concerned is very obvious.   Look 
> at the inordinate effort ($$)  they are putting into zOSMF in order to make 
> basic systems tasks more palletable to less experienced sysprogs.  I hope 
> they keep the gui facilities completely optional, and can be used if/when 
> needed, instead of falling into the trap they have created with managing IBM 
> i systems.  On an i system (don't get me started on that choice of a name for 
> an operating system) there is available 5250 emulation (green screen)  
> and at least 2 flavors of gui's for performing management tasks.The 
> trouble is that not *all* functions can be performed from a 5250 session.  
> Conversely not all functions can be executed from any one of the gui's 
> either.  This creates a dog's dinner of interfaces required to perform all 
> the duties needed to be an admin on an i system.
> 
> Dana
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Article for the boss: COBOL will outlive us all

[Anne & Lynn Wheeler]

martin_pac...@uk.ibm.com (Martin Packer) writes:
> Not saying you're wrong but OSX is based on Unix.

even some IBM content ... in the early 80s, IBM was getting back into
support for educational institutions (some gov. restrictions expiring)
including forming ACIS starting out with $300M for univ.

IBM funded much of univ bitnet network (EARN in europe) ... this
mailing list originated on bitnet
http://www.garlic.com/~lynn/subnetwork.html#bitnet

that used technology similar to that used for internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

IBM & DEC both provided $25M each for MIT's Project Athena which
resulted in number of things ... including Kerberos. Circa 2000, there
was small company that was selling Kerberos related services, support,
etc, CEO was former IBM senior VP of mainframe group. They had contract
to port Kerberos to windows what became windows authentication
infrastruction.

The Unix wars (SUN&AT&T threatening to severely restrict access
to Unix)
http://www.softpanorama.org/People/Torvalds/Finland_period/unix_wars_and_posix.shtml
and
http://en.wikipedia.org/wiki/Open_Software_Foundation

There was also univ. doing unix work-alikes, UCLA did Locus and CMU
doing Mach (besides UCB's BSD). IBM uses Locus for AIX/370 & AIX/386
... sort of super-SAA in the unix world (supported things like dynamic
process migration between distributed systems, even between dissimilar
architectures)

IBM provided CMU $50M for Andrew stuff .. Camelot (transaction system),
MACH (unix work-alike), Andrew Filesystem, Andrew widgets, etc. 

IBM provides seed funding for Camelot spin-off Transarc ... and then
buys Transarc outright.
http://www.zois.co.uk/tpm/encina.html

MACH unix work-alike ... number of companies start using MACH
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html

when Jobs was "fired" from Apple ... he goes off and does NeXTSTEP
which uses MACH as base
http://en.wikipedia.org/wiki/NeXTSTEP

when Jobs is brought back to Apple ... he brings MACH/NeXSTEP technology
back with him (basis for OS X and iOS).

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

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

Re: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In <511c0f1a.4030...@bremultibank.com.pl>, on 02/13/2013
   at 11:09 PM, "R.S."  said:

>Windows behavior is older than ...Windows. Reaaly - Windows 
>followed after OS/2.

No.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Article for the boss: COBOL will outlive us all

[Shmuel Metz (Seymour J.)]

In , on 02/13/2013
   at 04:07 PM, Scott Ford  said:

>Not following your thought, folders or file names can be any
>combination of upper or lower case...at least on Windoze 7

Yes, but can a single directory contain two distinct files, one named
foo and the other Foo?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Article for the boss: COBOL will outlive us all

[Pew, Curtis G]

On Feb 14, 2013, at 2:11 AM, Martin Packer  wrote:

> Not saying you're wrong but OSX is based on Unix.

OS X is Unix, but the HFS+ file system it uses comes from the old Mac OS and is 
case insensitive but case preserving.

-- 
Curtis Pew (c@its.utexas.edu)
ITS Systems Core
The University of Texas at Austin

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

Re: Article for the boss: COBOL will outlive us all

[Dana Mitchell]

On Wed, 13 Feb 2013 17:10:06 -0600, Ed Gould  wrote:

>Dana:
>
>About 15 years ago I was in a IBM class (all sysprogs). The  
>instructor came out and said it is IBM's hope to get rid of system  
>programmers. That tells you a lot from IBM's POV. I have distrusted  
>IBM ever since.
>
>Ed
>

IBM's plans as far as expensive sysprogs is concerned is very obvious.   Look 
at the inordinate effort ($$)  they are putting into zOSMF in order to make 
basic systems tasks more palletable to less experienced sysprogs.  I hope they 
keep the gui facilities completely optional, and can be used if/when needed, 
instead of falling into the trap they have created with managing IBM i systems. 
 On an i system (don't get me started on that choice of a name for an operating 
system) there is available 5250 emulation (green screen)  and at least 2 
flavors of gui's for performing management tasks.The trouble is that not 
*all* functions can be performed from a 5250 session.  Conversely not all 
functions can be executed from any one of the gui's either.  This creates a 
dog's dinner of interfaces required to perform all the duties needed to be an 
admin on an i system.

Dana

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

Re: Article for the boss: COBOL will outlive us all

[Martin Packer]

Not saying you're wrong but OSX is based on Unix.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   John McKown 
To: IBM-MAIN@listserv.ua.edu, 
Date:   02/13/2013 09:10 PM
Subject:    Re: Article for the boss: COBOL will outlive us all
Sent by:IBM Mainframe Discussion List 



Don't know about Windows 7, but on Windows XP Pro, the directory
c:\JohnMcKown is identically the same as c:\johnMckOWn. That is, WinXP is
case preserving, but not case sensitive. Linux is both case preserving and
case sensitive. E.g. file ~/MyFile is not the same as ~/myFile as it is in
XP. I think MacOSX is like Windows in that respect, but I could be wrong.

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








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

Re: Article for the boss: COBOL will outlive us all

[Scott Ford]

here you go...right from windows 7 x64 command prompt
 
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\Scott ford>dir
 Volume in drive C is WIN7
 Volume Serial Number is BE57-8CB7
 Directory of C:\Users\Scott ford
02/07/2013  03:15 AM      .
02/07/2013  03:15 AM      ..
07/10/2012  10:54 AM   108 .asadminpass
07/10/2012  11:09 AM      .m2
12/20/2012  12:20 PM      .nbi
12/19/2012  09:20 AM      .netbeans
11/29/2012  08:57 PM      .VirtualBox
01/18/2012  03:07 PM      AppData
07/11/2012  06:45 AM      Contacts
02/13/2013  07:03 PM      Desktop
02/13/2013  06:53 PM      Documents
03/30/2012  02:47 PM    27 dotnetfolder.txt
02/06/2013  11:24 PM      Downloads
03/30/2012  02:47 PM    21,368 en_res.dll
03/30/2012  02:47 PM    21,368 es_res.dll
02/12/2013  05:57 PM      Favorites
03/30/2012  02:47 PM    21,880 fr_res.dll
07/30/2012  01:02 PM    60,304 g2mdlhlpx.exe
03/30/2012  02:47 PM    21,880 grm_res.dll
07/20/2012  02:50 PM 1,135,491 IMG_0406.JPG
07/20/2012  02:50 PM 1,108,223 IMG_0407.JPG
03/30/2012  02:47 PM    21,368 it_res.dll
03/30/2012  02:47 PM    20,344 jp_res.dll
10/25/2012  12:22 AM      Links
03/30/2012  02:47 PM 1,079,808 mfc80u.dll
03/30/2012  02:47 PM   522 Microsoft.VC80.CRT.manifest
03/30/2012  02:47 PM   550 Microsoft.VC80.MFC.manifest
03/30/2012  02:47 PM   626,688 msvcr80.dll
01/31/2013  05:39 PM      Music
02/13/2013  10:14 PM    18,087,936 ntuser.dat
02/07/2013  03:10 AM    18,350,080 ntuser.dat.rmbak
02/12/2013  08:09 PM      Pictures
03/30/2012  02:47 PM    21,368 pt_res.dll
03/30/2012  02:47 PM    18,808 ResourceReader.dll
03/30/2012  02:47 PM    20,856 ru_res.dll
07/11/2012  06:45 AM      Saved Games
12/27/2012  01:10 AM 0 SciTE.recent
12/27/2012  01:10 AM    21 SciTE.session
12/13/2012  11:04 PM      Searches
12/21/2011  06:25 PM      SyncMe
07/16/2012  08:41 PM    77 test.go
12/16/2011  08:23 PM      Tracing
10/25/2012  12:22 AM      Videos
09/05/2012  06:38 PM      VirtualBox VMs
03/30/2012  02:47 PM    19,832 zh_res.dll
  24 File(s) 40,658,907 bytes
  21 Dir(s)  132,323,966,976 bytes free
C:\Users\Scott ford>

Scott J Ford
Software Engineer
http://www.identityforge.com/
 
 


 From: Don Poitras 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 13, 2013 5:30 PM
Subject: Re: Article for the boss: COBOL will outlive us all
  
In article <2933915686680628.wa.paulgboulderaim@listserv.ua.edu> you wrote:
> On Wed, 13 Feb 2013 16:07:08 -0500, Scott Ford wrote:
> >
> >Not following your thought, folders or file names can be any combination of 
> >upper or lower case...at least on Windoze 7
> > 
> So, show me, please, a single folder containing two files whose names
> differ only in the case of some of their characters.

D72358> touch case
D72358> touch CASE
D72358> l case
-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 case
D72358> l CASE
-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 CASE
D72358> echo lower > case
D72358> echo UPPER > CASE
D72358> cat case
lower
D72358> cat CASE
UPPER
D72358> uname -a
Interix d72358 6.1 10.0.6030.0 genuineintel 
Intel64_Family_6_Model_23_Stepping_10


> On Wed, 13 Feb 2013 15:10:39 -0600, John McKown wrote:
> >
> >XP. I think MacOSX is like Windows in that respect, but I could be wrong.
> > 
> You have your choice: a filesystem may be formatted as either
> case-sensitive or not.  No finer granularity; can't change an
> existing filesystem; can't specify directory-by-directory.  I assume
> stat(), etc., accommodate the fs type.

> Samba is schizophrenic (but it may be Sun-peculiar).  I can mount via Samba
> on Windows a Solaris-served filesystem having a directory with two files
> whose names differ only in case of characters.  Exploder shows both.
> When I click on one, it's unpredictable (perhaps repeatable) which one
> actually opens.  They could have done better.

> UTF-8 is very much becoming the mode; even on Windows.  What is the
> semantic of case-insensitivity among files named, e.g. in Cyrillic UTF-8?
> It's pretty well defined, but is it implemented correctly?

> -- gil

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com           (919) 531-5637                Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lis

Re: Article for the boss: COBOL will outlive us all

[Clark Morris]

On 13 Feb 2013 11:53:05 -0800, in bit.listserv.ibm-main you wrote:

>On Wed, 13 Feb 2013, Scott Ford wrote:
>
>> Lol, probably Linux...
>
>I think they used Linux at least as one of their web servers, some time 
>ago. Other than this, some of their OSes were quite usable - one just 
>needs to pay attention and buy "pro" version or something similar. The 
>whole "home" section is a little too stinking for my nose. "Pro" (and 
>"Server") is rough equivalent of Linux - of course I'm judging things 
>sitting at Linux box right now. Back in time, I was positively surprised 
>by W2k Pro, and nowadays, I am rather positive towards XP (... Pro, I 
>believe). So I guess they use just their own stuff?
>
>Of course if Win8 proves as unusable as I read it is, they will have to 
>switch to something else, MacOS, maybe?

Win 8 is annoying but usable enough that I didn't feel that my wife
had to run out and buy a Win 7 laptop to replace her XP laptop.  We
are using it on our netbook (2 gigabyte ACER A)722 with Win 8 Pro was
Windows 7 Home Premium).

Clark Morris
>
>Regards,
>Tomasz Rola

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

Re: Article for the boss: COBOL will outlive us all

[Don Poitras]

In article <6131889061731908.wa.paulgboulderaim@listserv.ua.edu> you wrote:
> On Wed, 13 Feb 2013 17:30:02 -0500, Don Poitras  wrote:

> >In article <2933915686680628.wa.paulgboulderaim@listserv.ua.edu> you 
> >wrote:
> >> On Wed, 13 Feb 2013 16:07:08 -0500, Scott Ford wrote:
> >> >
> >> >Not following your thought, folders or file names can be any combination 
> >> >of upper or lower case...at least on Windoze 7
> >> >
> >> So, show me, please, a single folder containing two files whose names
> >> differ only in the case of some of their characters.
> >
> >D72358> touch case
> >D72358> touch CASE
> >D72358> l case
> >-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 case
> >D72358> l CASE
> >-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 CASE
> >D72358> echo lower > case
> >D72358> echo UPPER > CASE
> >D72358> cat case
> >lower
> >D72358> cat CASE
> >UPPER
> >D72358> uname -a
> >Interix d72358 6.1 10.0.6030.0 genuineintel 
> >Intel64_Family_6_Model_23_Stepping_10
> >
> And is this in fact on Windo[ws] 7, as Scott stated?

Yes. Although to use the case-sensitive files, you must have installed SUA
with case-sensitivity turned on. Normal DOS access won't see them, or will
produce confusing results.

---
C:\WINNT\Profiles\sasdtp>dir case
 Volume in drive C is Win7x64
 Volume Serial Number is 2CCB-C26C

 Directory of C:\WINNT\Profiles\sasdtp

02/13/13  05:27 PM 6 CASE
02/13/13  05:27 PM 6 case
   2 File(s) 12 bytes
   0 Dir(s)  136,831,578,112 bytes free

C:\WINNT\Profiles\sasdtp>type CASE
UPPER
UPPER

C:\WINNT\Profiles\sasdtp>type case
UPPER
UPPER
---


-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Article for the boss: COBOL will outlive us all

[Ed Gould]

Dana:

About 15 years ago I was in a IBM class (all sysprogs). The  
instructor came out and said it is IBM's hope to get rid of system  
programmers. That tells you a lot from IBM's POV. I have distrusted  
IBM ever since.


Ed

On Feb 13, 2013, at 10:44 AM, Dana Mitchell wrote:

I've been reading the same theory as it applied to us Systems  
Programmers the last few years.  Mass retirement making the  
remaining sysprogs highly sought after and compensated.   Well,  
I've personally seen lots of retirements,  but due to the  
combination of outsourcing,  business acquisitions, do-more-with- 
less etc,  I haven't seen demand locally rising sharply yet.


Dana

On Wed, 13 Feb 2013 08:01:31 -0600, John McKown  
 wrote:



http://www.itworld.com/career/341879/cobol-will-outlive-us-all

...

The reason that I�m telling you about COBOL is that I predict  
that over the
next few years, new COBOL programmers are going to be in high  
demand and
very possibly paid a premium for their efforts. Generally  
speaking, the

COBOL programming skill set resides in baby boomers that have been
programming in COBOL their entire career. The issue is that these  
baby
boomers have begun retiring in enormous numbers. Additionally, new  
college
recruits have neither the skill set nor the interest in replacing  
them. The
problem for companies employing these COBOL programmers is that if  
the

software stops, so does the company.



--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

- 
-

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


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


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

Re: Article for the boss: COBOL will outlive us all

[Paul Gilmartin]

On Wed, 13 Feb 2013 17:30:02 -0500, Don Poitras  wrote:

>In article <2933915686680628.wa.paulgboulderaim@listserv.ua.edu> you wrote:
>> On Wed, 13 Feb 2013 16:07:08 -0500, Scott Ford wrote:
>> >
>> >Not following your thought, folders or file names can be any combination of 
>> >upper or lower case...at least on Windoze 7
>> >
>> So, show me, please, a single folder containing two files whose names
>> differ only in the case of some of their characters.
>
>D72358> touch case
>D72358> touch CASE
>D72358> l case
>-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 case
>D72358> l CASE
>-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 CASE
>D72358> echo lower > case
>D72358> echo UPPER > CASE
>D72358> cat case
>lower
>D72358> cat CASE
>UPPER
>D72358> uname -a
>Interix d72358 6.1 10.0.6030.0 genuineintel 
>Intel64_Family_6_Model_23_Stepping_10
>
And is this in fact on Windo[ws] 7, as Scott stated?

-- gil

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

Re: Article for the boss: COBOL will outlive us all

[Don Poitras]

In article <2933915686680628.wa.paulgboulderaim@listserv.ua.edu> you wrote:
> On Wed, 13 Feb 2013 16:07:08 -0500, Scott Ford wrote:
> >
> >Not following your thought, folders or file names can be any combination of 
> >upper or lower case...at least on Windoze 7
> > 
> So, show me, please, a single folder containing two files whose names
> differ only in the case of some of their characters.

D72358> touch case
D72358> touch CASE
D72358> l case
-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 case
D72358> l CASE
-rw---  1 sasdtp  Domain Users  0 Feb 13 17:26 CASE
D72358> echo lower > case
D72358> echo UPPER > CASE
D72358> cat case
lower
D72358> cat CASE
UPPER
D72358> uname -a
Interix d72358 6.1 10.0.6030.0 genuineintel 
Intel64_Family_6_Model_23_Stepping_10


> On Wed, 13 Feb 2013 15:10:39 -0600, John McKown wrote:
> >
> >XP. I think MacOSX is like Windows in that respect, but I could be wrong.
> > 
> You have your choice: a filesystem may be formatted as either
> case-sensitive or not.  No finer granularity; can't change an
> existing filesystem; can't specify directory-by-directory.  I assume
> stat(), etc., accommodate the fs type.

> Samba is schizophrenic (but it may be Sun-peculiar).  I can mount via Samba
> on Windows a Solaris-served filesystem having a directory with two files
> whose names differ only in case of characters.  Exploder shows both.
> When I click on one, it's unpredictable (perhaps repeatable) which one
> actually opens.  They could have done better.

> UTF-8 is very much becoming the mode; even on Windows.  What is the
> semantic of case-insensitivity among files named, e.g. in Cyrillic UTF-8?
> It's pretty well defined, but is it implemented correctly?

> -- gil

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Article for the boss: COBOL will outlive us all

[Phil Smith]

R.S. wrote:
> BTW: My argument against Unix behavior: I cannot distinguish MyFiLE and 
> MYfiLe during phone call. Even spelling is simpler for M-y-f-I-L-e than for 
> "Upper M - Upper Y...".

Indeed. I'd put it more strongly: Case sensitivity for *IX filesystems offers 
NO benefit that anyone has ever been able to articulate to me. If you ask a *IX 
person, they act like it's just "obviously" A Good Thing, but can never express 
why. And if you ask them if they've ever created /something/abc and 
/something/Abc or any of the other possible values, they say "No".

I think Windows got this one right. And a decade of asking for a 
counter-argument has failed to produce anything useful.

(Oddly, the one quasi-counter-argument is CMS, where you have to work at it to 
create/use a file with lowercase in the fileid-but that's a different kettle of 
hamsters, since it's more a byproduct of an historical mistake than a 
deliberate feature, and not the same at all as *IX.)
--
...phsiii

Phil Smith III


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

Re: Article for the boss: COBOL will outlive us all

[R.S.]

W dniu 2013-02-13 22:10, John McKown pisze:

Don't know about Windows 7, but on Windows XP Pro, the directory
c:\JohnMcKown is identically the same as c:\johnMckOWn. That is, WinXP is
case preserving, but not case sensitive. Linux is both case preserving and
case sensitive. E.g. file ~/MyFile is not the same as ~/myFile as it is in
XP. I think MacOSX is like Windows in that respect, but I could be wrong.


Windows behavior is older than ...Windows. Reaaly - Windows followed 
after OS/2. Note: in the very old days there were "graphical 
environment", DOS overlay - MS Windows (naming convention 8.3 as in DOS) 
and OS/2. OS/2 on HPFS volumes allowed longer names and case 
preservation. Then Windows NT arrived... and a little bit later Win95...




BTW: My argument against Unix behavior: I cannot distinguish MyFiLE and 
MYfiLe during phone call. Even spelling is simpler for M-y-f-I-L-e than 
for "Upper M - Upper Y...".



BTW: I liked VMS system filenames - it was FILE.EXTENSION;VERSION mask 
for "all files" is *.*;*
or [...]*.*;*   - all files in this directory and all subdirectories 
recursively.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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