IBM announces new release of z/OS (OS/390) compiler 
Author Message
 IBM announces new release of z/OS (OS/390) compiler

See full announcement at:

  http://www.*-*-*.com/

"At a Glance
IBM Enterprise COBOL for z/OS and OS/390 V3R1 provides the following new
functions:

 - Java interoperability
 - WebSphere interoperation
 - Extensible Markup Language (XML) support
 - CICS? translator integration
 - Unicode support
 - Enhancements to z/OS and OS/390 UNIX? System Services support for thread
and asynchronous signal toleration"

"Planned Availability Dates
    November 30, 2001, Alternate Function Offering
    March 29, 2002, Full-Function Offering"

--
Bill Klein
 wmklein <at> ix.netcom.com



Sun, 16 May 2004 02:19:08 GMT  
 IBM announces new release of z/OS (OS/390) compiler
(Replying to myself)

  A few other things to note.

1) This is a NEW version (not just a new release).  In "IBM-ese" that means
you need to buy it "again" and not get it as a "maintenance" upgrade.

2) "Compatibility: The following summarizes the compatibility
characteristics of IBM Enterprise COBOL for z/OS and OS/390 V3. Full details
will be provided in the Migration Guide and the Licensed Programming
Specifications.

IBM Enterprise COBOL for z/OS and OS/390 V3 provides source code and object
code compatibility with its predecessor product, IBM COBOL for OS/390 & VM
Version 2, with the following exceptions:

 - The CMPR2 compiler option has been removed, so source programs still
using VS COBOL II R1 or 2 level syntax must be migrated to conform to
ANS/ISO COBOL 85 standard rules before they can be compiled with IBM
Enterprise COBOL V3.
 - SOM?-based object-oriented (OO) COBOL applications are no longer
supported. Object Oriented COBOL syntax is retargeted for Java?-based OO
programming. Further, the primary purpose of the OO syntax is not
stand-alone OO COBOL programming, rather the syntax is intended to
facilitate interoperation of COBOL and Java.
 - Support for the VM/CMS environment is not provided in this product.
 - New reserved words are defined.
 - In addition to CMPR2, the ANALYZE, FLAGMIG, IDLGEN, and TYPECHK compiler
options are removed.
 - The pseudo-assembly listing produced by the LIST compiler option is
slightly changed, which may impact development tools that process the
listing. IBM recommends that such tools use the ADATA compiler option to
obtain desired information about the compilation, rather than the listing."

--
Bill Klein
 wmklein <at> ix.netcom.com


Quote:
> See full announcement at:

>  http://www.ibmlink.ibm.com/usalets&parms=H_201-343

> "At a Glance
> IBM Enterprise COBOL for z/OS and OS/390 V3R1 provides the following new
> functions:

>  - Java interoperability
>  - WebSphere interoperation
>  - Extensible Markup Language (XML) support
>  - CICS? translator integration
>  - Unicode support
>  - Enhancements to z/OS and OS/390 UNIX? System Services support for
thread
> and asynchronous signal toleration"

> "Planned Availability Dates
>     November 30, 2001, Alternate Function Offering
>     March 29, 2002, Full-Function Offering"

> --
> Bill Klein
>  wmklein <at> ix.netcom.com



Sun, 16 May 2004 02:33:38 GMT  
 IBM announces new release of z/OS (OS/390) compiler


Quote:
> Further, the primary purpose of the OO syntax is not
> stand-alone OO COBOL programming, rather the syntax is intended to
> facilitate interoperation of COBOL and Java.

Interesting.  This is what I have been saying I saw as the future of OO on
the mainframe.  Apparently other customers have been saying the same thing.

Mainframe users don't like interdependency, with user maintained components
requiring massive testing whenever they change.  But we do like
connectivity.  Moving towards standard, powerful connectivity tools is very
important.   The ability to pick and choose tools is useful as well.

If I could see examples of successful implementation of OO business
environment on the mainframe, I could change my mind.  But apparently IBM
couldn't find such examples, and is adjusting.



Sun, 16 May 2004 03:05:44 GMT  
 IBM announces new release of z/OS (OS/390) compiler
Bill,

Do you have a feeling how this compiler will [or will not] satisfy requirements
for the almost-approved 2002 ANSI/ISO standard?

Kind regards,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Sun, 16 May 2004 04:11:10 GMT  
 IBM announces new release of z/OS (OS/390) compiler
My GUESS is that it has very LITTLE to do with the draft Standard.  I
wouldn't be surprised if the OO syntax is closer to what is in the draft
Standard, then the current IBM implementation, but I don't see much for
VALIDATE, common exception handling, standard arithmetic, etc.

It *DOES* say that it support Unicode - and my guess is that it PROBABLY
uses what is in the draft standard for that, but what IBM has in COBOL for
this-and-that V2R2 isn't TOO far off for that already.

--
Bill Klein
 wmklein <at> ix.netcom.com

Quote:
> Bill,

> Do you have a feeling how this compiler will [or will not] satisfy
requirements
> for the almost-approved 2002 ANSI/ISO standard?

> Kind regards,

> Steve Comstock
> Telephone: 303-393-8716
> www.trainersfriend.com

> 256-B S. Monaco Parkway
> Denver, CO 80224
> USA



Sun, 16 May 2004 05:03:51 GMT  
 IBM announces new release of z/OS (OS/390) compiler


Quote:
> (Replying to myself)

That's worse than talking to yourself, Bill...:-)

Quote:
>  - SOM?-based object-oriented (OO) COBOL applications are no longer
> supported. Object Oriented COBOL syntax is retargeted for JavaT-based OO
> programming. Further, the primary purpose of the OO syntax is not
> stand-alone OO COBOL programming, rather the syntax is intended to
> facilitate interoperation of COBOL and Java.

So IBM have blown OO COBOL out of the water.

(Probably for the best...most mainframers couldn't handle it anyway...<G>)

This will be in response to user reaction from people who THINK they know
about OO ("...it's just modular programming re-invented...")

So all those people who resisted it so strongly will now have to learn Java
instead, or watch all the good jobs evaporate to the guys who DO know OO and
Java... Or keep on maintaining Batch COBOL. There's a kind of irony there.

Fortunately, OO COBOL (with and without Java) is still alive and well in the
Client Server arena. It is still fulfilling the role of a BUSINESS oriented
OO language and I, for one, am using it on a daily basis for both Client
apps, and server side CGI code.

To endorse COBOL WITHOUT OO is folly when we look to the future.

This short sightedness from IBM (albeit in response to User feedback) is
really sad. Would it have hurt  so bad to maintain SOM? I hope it bites them
in the arse in a few years time...<G>

Pete.

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com



Sun, 16 May 2004 07:27:41 GMT  
 IBM announces new release of z/OS (OS/390) compiler

Quote:

> So IBM have blown OO COBOL out of the water.

You say they blew it. The customer base - which is what I presume IBM
will be aiming this release at must think otherwise.
Quote:
> (Probably for the best...most mainframers couldn't handle it anyway...<G>)

tch tch jealousy is a curse ;)
Quote:
> This will be in response to user reaction from people who THINK they know
> about OO ("...it's just modular programming re-invented...")

The thing is IT IS modular programming re-invented. There is absolutely
NOTHING that OO can do that can't be done with discipline and a good
library interface.
Quote:
> So all those people who resisted it so strongly will now have to learn Java
> instead, or watch all the good jobs evaporate to the guys who DO know OO and
> Java... Or keep on maintaining Batch COBOL. There's a kind of irony there.

Peter, people are not resisting it for technical reasons. They just
don't see any reason to change. To me, personally, I find that the
various OO flavours of COBOL take an already wordy language and clutter
it up with extra layers of fluff.
Quote:
> Fortunately, OO COBOL (with and without Java) is still alive and well in the
> Client Server arena. It is still fulfilling the role of a BUSINESS oriented
> OO language and I, for one, am using it on a daily basis for both Client
> apps, and server side CGI code.

> To endorse COBOL WITHOUT OO is folly when we look to the future.

Actually, I suspect that OO will slowly go the way of other languages
and techniques that have attempted to displace COBOL as the king of
transactional processing.

In case you missed it, the announcement shows that IBM has made
enhancements in all the right areas. CICS, JAVA, posix, Unicode. All
the areas designed to support vast online transaction systems.

Quote:
> This short sightedness from IBM (albeit in response to User feedback) is
> really sad. Would it have hurt  so bad to maintain SOM? I hope it bites them
> in the arse in a few years time...<G>

Well I guess history will show :)


Sun, 16 May 2004 21:51:46 GMT  
 IBM announces new release of z/OS (OS/390) compiler
Tried to look at the link and got the following output.
Hope this isn't a bad omen about its subject.
Anyone have a link that works?

----------------------------------------------------------------------------
----

Abnormal Program Termination

Module: GenerateOutput
Function: see the "TRACEBACK Calls" section
Reason: Segmentation violation.
When: Wed Nov 28 08:11:54 2001
Elapse: 1.684 secs

----------------------------------------------------------------------------
----
Debug info:
TOTAL RESOURCE Usage

CPU (user/system) =   0.280 secs (0.090/0.190)
Priority          =      20
Resident Memory   =    2776 KB
Shared Memory     =   26267 KB
Unshared Memory   =  261644 KB
Minor Page Faults =    1209
Major Page Faults =       2
Swaps             =       0
Block Input       =       0
Block Ouput       =       0
Vol. Context Sw   =      88
Invol. Context Sw =      49
Master Stack Size =     272
CPU Time Limit    =      60 secs
Run Time Limit    =     300 secs

CONTENT OF Master Request Block

Client IP Address = 166.33.131.188
Client Name       = 166.33.131.188
Client Browser    = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0;
Q312461)
Request Method    = GET QUERY_STRING
Server Name       = www2.ibmlink.ibm.com
Secured Server    = N
Secured Path      = N
User Type         = G
Advantis Account  =
Advantis Userid   = GUEST
Link Userid       = GUEST
Host Userid       =
initial logon     = Wed Nov 28 08:11:52 2001
last logon        = Wed Nov 28 08:11:52 2001
request           = announcements
parms             = H_201-343
External handle   = pw7OxRowGshzIp1
Internal handle   = 24235
Namespace         = usa
Language          = english
Icon Location     = B
Icon Format       = T
Frame option      = N
Content Override  =
Pushed URL        =
Crawler Defense   = Y
Create Core File  = N

CONTENT OF entries[4]

xh                = logon
xu                = GUEST
request           = usa.announcements
parms             = H_201-343

TRACEBACK Calls (50 entries max)

Filename: ???  - ??? ??? ???
Function: rightmost

Filename: ???  - ??? ??? ???
Function: realloc

Filename: ???  - ??? ??? ???
Function: buildQueryString

Filename: ???  - ??? ??? ???
Function: HandleTOOL_BAR

Filename: ???  - ??? ??? ???
Function: handleTAG_HEADER

Filename: ???  - ??? ??? ???
Function: GenerateOutput

Filename: ???  - ??? ??? ???
Function: WWW_DS_Error

Filename: ???  - ??? ??? ???
Function: WWW_DSIF_DOCUMENT

Filename: ???  - ??? ??? ???
Function: masterControl

Filename: ???  - ??? ??? ???
Function: Execute

Filename: ???  - ??? ??? ???
Function: processRequest

Filename: ???  - ??? ??? ???
Function: main

Filename: ???  - ??? ??? ???
Function: __start

--------------------------------------------------------------------------



Quote:
> See full announcement at:

>  http://www.ibmlink.ibm.com/usalets&parms=H_201-343

> "At a Glance
> IBM Enterprise COBOL for z/OS and OS/390 V3R1 provides the following new
> functions:

>  - Java interoperability
>  - WebSphere interoperation
>  - Extensible Markup Language (XML) support
>  - CICS? translator integration
>  - Unicode support
>  - Enhancements to z/OS and OS/390 UNIX? System Services support for
thread
> and asynchronous signal toleration"

> "Planned Availability Dates
>     November 30, 2001, Alternate Function Offering
>     March 29, 2002, Full-Function Offering"

> --
> Bill Klein
>  wmklein <at> ix.netcom.com



Mon, 17 May 2004 00:17:12 GMT  
 IBM announces new release of z/OS (OS/390) compiler
I think too much is being read into what was said.

Their present syntax may be insufficient (it certainly was BEFORE with just
SOM!) for full COBOL OO Development.  If they implement the next standard, then
you should be able to do full OO COBOL programming on the IBM mainframe
platform.

Truth be told, others have better OO implementations.  When I looked at it on
the OS/390 (when I had one) it was simply too lean of an implementation to be
useful.  All they are saying is that is still the case.


Quote:



>> (Replying to myself)

>That's worse than talking to yourself, Bill...:-)

>>  - SOM?-based object-oriented (OO) COBOL applications are no longer
>> supported. Object Oriented COBOL syntax is retargeted for JavaT-based OO
>> programming. Further, the primary purpose of the OO syntax is not
>> stand-alone OO COBOL programming, rather the syntax is intended to
>> facilitate interoperation of COBOL and Java.

>So IBM have blown OO COBOL out of the water.

>(Probably for the best...most mainframers couldn't handle it anyway...<G>)

>This will be in response to user reaction from people who THINK they know
>about OO ("...it's just modular programming re-invented...")

>So all those people who resisted it so strongly will now have to learn Java
>instead, or watch all the good jobs evaporate to the guys who DO know OO and
>Java... Or keep on maintaining Batch COBOL. There's a kind of irony there.

>Fortunately, OO COBOL (with and without Java) is still alive and well in the
>Client Server arena. It is still fulfilling the role of a BUSINESS oriented
>OO language and I, for one, am using it on a daily basis for both Client
>apps, and server side CGI code.

>To endorse COBOL WITHOUT OO is folly when we look to the future.

>This short sightedness from IBM (albeit in response to User feedback) is
>really sad. Would it have hurt  so bad to maintain SOM? I hope it bites them
>in the arse in a few years time...<G>

>Pete.

> Posted Via Usenet.com Premium Usenet Newsgroup Services
>----------------------------------------------------------
>    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
>----------------------------------------------------------        
>                http://www.usenet.com



Mon, 17 May 2004 01:38:34 GMT  
 IBM announces new release of z/OS (OS/390) compiler
It looks like your browser crashed.
Have you tried a different browser (I mean other than MS IE 6.0) ?
Or checked Microsoft support?
Quote:

> Tried to look at the link and got the following output.
> Hope this isn't a bad omen about its subject.
> Anyone have a link that works?

> ----------------------------------------------------------------------------
> ----

> Abnormal Program Termination

> Module: GenerateOutput
> Function: see the "TRACEBACK Calls" section
> Reason: Segmentation violation.
> When: Wed Nov 28 08:11:54 2001
> Elapse: 1.684 secs

> ----------------------------------------------------------------------------
> ----
> Debug info:
> TOTAL RESOURCE Usage

> CPU (user/system) =   0.280 secs (0.090/0.190)
> Priority          =      20
> Resident Memory   =    2776 KB
> Shared Memory     =   26267 KB
> Unshared Memory   =  261644 KB
> Minor Page Faults =    1209
> Major Page Faults =       2
> Swaps             =       0
> Block Input       =       0
> Block Ouput       =       0
> Vol. Context Sw   =      88
> Invol. Context Sw =      49
> Master Stack Size =     272
> CPU Time Limit    =      60 secs
> Run Time Limit    =     300 secs

> CONTENT OF Master Request Block

> Client IP Address = 166.33.131.188
> Client Name       = 166.33.131.188
> Client Browser    = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0;
> Q312461)
> Request Method    = GET QUERY_STRING
> Server Name       = www2.ibmlink.ibm.com
> Secured Server    = N
> Secured Path      = N
> User Type         = G
> Advantis Account  =
> Advantis Userid   = GUEST
> Link Userid       = GUEST
> Host Userid       =
> initial logon     = Wed Nov 28 08:11:52 2001
> last logon        = Wed Nov 28 08:11:52 2001
> request           = announcements
> parms             = H_201-343
> External handle   = pw7OxRowGshzIp1
> Internal handle   = 24235
> Namespace         = usa
> Language          = english
> Icon Location     = B
> Icon Format       = T
> Frame option      = N
> Content Override  =
> Pushed URL        =
> Crawler Defense   = Y
> Create Core File  = N

> CONTENT OF entries[4]

> xh                = logon
> xu                = GUEST
> request           = usa.announcements
> parms             = H_201-343

> TRACEBACK Calls (50 entries max)

> Filename: ???  - ??? ??? ???
> Function: rightmost

> Filename: ???  - ??? ??? ???
> Function: realloc

> Filename: ???  - ??? ??? ???
> Function: buildQueryString

> Filename: ???  - ??? ??? ???
> Function: HandleTOOL_BAR

> Filename: ???  - ??? ??? ???
> Function: handleTAG_HEADER

> Filename: ???  - ??? ??? ???
> Function: GenerateOutput

> Filename: ???  - ??? ??? ???
> Function: WWW_DS_Error

> Filename: ???  - ??? ??? ???
> Function: WWW_DSIF_DOCUMENT

> Filename: ???  - ??? ??? ???
> Function: masterControl

> Filename: ???  - ??? ??? ???
> Function: Execute

> Filename: ???  - ??? ??? ???
> Function: processRequest

> Filename: ???  - ??? ??? ???
> Function: main

> Filename: ???  - ??? ??? ???
> Function: __start

> --------------------------------------------------------------------------



> > See full announcement at:

> >  http://www.ibmlink.ibm.com/usalets&parms=H_201-343

> > "At a Glance
> > IBM Enterprise COBOL for z/OS and OS/390 V3R1 provides the following new
> > functions:

> >  - Java interoperability
> >  - WebSphere interoperation
> >  - Extensible Markup Language (XML) support
> >  - CICS? translator integration
> >  - Unicode support
> >  - Enhancements to z/OS and OS/390 UNIX? System Services support for
> thread
> > and asynchronous signal toleration"

> > "Planned Availability Dates
> >     November 30, 2001, Alternate Function Offering
> >     March 29, 2002, Full-Function Offering"

> > --
> > Bill Klein
> >  wmklein <at> ix.netcom.com



Mon, 17 May 2004 07:44:32 GMT  
 IBM announces new release of z/OS (OS/390) compiler

Quote:



> > So IBM have blown OO COBOL out of the water.

> You say they blew it. The customer base - which is what I presume IBM
> will be aiming this release at must think otherwise.

Which is of course the argument used by other vendors not to do anything about
OO.  I can only speculate, but I seriously doubt that OO was introduced to COBOL
at "user requests". Bill, please put thinking cap on - originally how did OO get
onto the J4 agenda - motivation from one or two vendors ?.

Quote:

> > (Probably for the best...most mainframers couldn't handle it anyway...<G>)

> tch tch jealousy is a curse ;)
> > This will be in response to user reaction from people who THINK they know
> > about OO ("...it's just modular programming re-invented...")

> The thing is IT IS modular programming re-invented. There is absolutely
> NOTHING that OO can do that can't be done with discipline and a good
> library interface.

Yes in a sense it is a revamped set of modular techniques, but with its own
particular twists and turns. "NOTHING that OO can do that can't be done with
discipline and a good library interface". That's a pretty broad statement and
exactly what do you mean by a good library interface - C++, Java or whatever ?

We could flog this one to death, but there's no point, because the majority are
just not going to switch. So on the basis non-OO can parallel OO, how would you do
the following. No cheating now - entry points are not and will not be a part of
the COBOL standard. :-

*>-------------------caller1.cbl -------------------------------
Program-id.        Caller1.
Class-Control.     Caller2          is class "caller2".
Working-storage section.
01 n                                pic 9(03).
01 charx                            pic x.
01 ws-Counter                       pic 9(03) value 0.
01 ws-Number                        pic 9(03).
Object-Storage section.
01 os-Program  occurs 4             object reference.
01 ws-Object                        object reference.
Procedure Division.
 perform varying n from 1 by 1 until n > 4
   Evaluate true
     when n = 1 move "A" to charx
     when n = 2 move "B" to charx
     when n = 3 move "C" to charx
     when n = 4 move "D" to charx
   End-evaluate
   invoke Caller2 "new" using charx returning os-Program(n)
 End-perform
 move 6 to ws-Counter
 perform varying n from 1 by 1 until n > 10
   Evaluate true
     when n = 1 or 5  set ws-Object to os-Program(1)
     when n = 2 or 6  set ws-Object to os-Program(2)
     when n = 3 or 7  set ws-Object to os-Program(3)
     when other       set ws-Object to os-Program(4)
   End-evaluate
  add n to ws-counter
  invoke ws-object "getDisplay" using ws-counter
 End-perform
 STOP RUN.
*>--------------------------------------------------------------
*>-------------------caller2-------------------------------
Class-id.          Caller2
                   inherits from Base.
Class-Control.     Caller2                is class "caller2".
*>--------------------------------------------------------------
FACTORY.
*>--------------------------------------------------------------
Method-id. "new".
*>--------------------------------------------------------------
Linkage section.
01 lnk-charx                    pic x.
01 lnk-self                     object reference.
Procedure Division  using lnk-charx returning lnk-self.
 invoke super "new" returning lnk-self
 invoke lnk-self "setProgramName" using lnk-charx
End Method "new".
*>--------------------------------------------------------------
END FACTORY.
*>--------------------------------------------------------------
OBJECT.
*>--------------------------------------------------------------
OBJECT-STORAGE SECTION.
01 ThisInstanceName        pic x(08).
01 ThisCounter             pic 9(03) value 0.
*>--------------------------------------------------------------
Method-id. "getDisplay".
*>--------------------------------------------------------------
Linkage section.
01 lnk-counter                  pic 9(03).
Procedure Division using lnk-Counter.
  add lnk-counter to ThisCounter
  display ThisInstanceName, " Counter : " ThisCounter
End Method "getDisplay".
*>--------------------------------------------------------------
Method-id. "setProgramName".
*>--------------------------------------------------------------
Linkage section.
01 lnk-charx                     pic x.
Procedure Division using lnk-charx.
  string "Program"      delimited by size
         lnk-charx      delimited by size
         into ThisInstanceName
  End-string
End Method "setProgramName".
*>--------------------------------------------------------------
End OBJECT.
End CLASS Caller2.

Quote:
>---------------------------------------------------------------

The result of the above displays :-

    ProgramA    Counter        7
    ProgramB    Counter        9
    ProgramC    Counter        12
    ProgramD    Counter        16
    ProgramA    Counter        28
    ProgramB    Counter        36
    ProgramC    Counter        46
    ProgramD    Counter        58
    ProgramD    Counter        109
    ProgramD    Counter        170

The above looks pretty dumb doesn't it ? And yet it's the above technique that I
use to have only ONE Class(Program) to access a virtually UNLIMITED choice of
ISAM/Relative/Sequential/Line Sequential  files. (Clarify that - there are a total
of four classes - one per file type). Pity - wont work with SQL where the DB
package calls the shots.

Jimmy, Calgary AB



Mon, 17 May 2004 10:56:33 GMT  
 IBM announces new release of z/OS (OS/390) compiler


Quote:
> The above looks pretty dumb doesn't it ? And yet it's the above technique
> that I
> use to have only ONE Class(Program) to access a virtually UNLIMITED choice
> of ISAM/Relative/Sequential/Line Sequential  files. (Clarify that - there
> are
> a total of four classes - one per file type). Pity - wont work with SQL
> where the
> DB package calls the shots.

There are things OO can do well.  But most of these things are not things
that I want done in a mainframe environment.

I have to admit that I don't know OO CoBOL well enough to tell exactly what
you're doing here, but I HAVE worked in environments where we use called
programs for I/O.   The reasons for these called programs are some of the
same reasons given for using OO, but in actual practice I find that they
obscure errors, and make it much, much more difficult to test when this
called program gets changed.

So what is the advantage in having that "ONE Class(Program)", that overcomes
these two big costs?  (costs being that the method is hidden - making
debugging hard, and that everybody uses it - making acceptance testing real,
real hard)



Mon, 17 May 2004 22:51:40 GMT  
 IBM announces new release of z/OS (OS/390) compiler

Quote:

> There are things OO can do well.  But most of these things are not things
> that I want done in a mainframe environment.

> I have to admit that I don't know OO CoBOL well enough to tell exactly
what
> you're doing here, but I HAVE worked in environments where we use called
> programs for I/O.   The reasons for these called programs are some of the
> same reasons given for using OO, but in actual practice I find that they
> obscure errors, and make it much, much more difficult to test when this
> called program gets changed.

> So what is the advantage in having that "ONE Class(Program)", that
overcomes
> these two big costs?  (costs being that the method is hidden - making
> debugging hard, and that everybody uses it - making acceptance testing
real,
> real hard)

Well, one of the things it does is FORCE compliance to the rules.  Perhaps
an example.

What i want is to have absolutely standardized I/O.  Using the traditional
method, I create three copybooks ... select clause, fd, and procedures. I
then make it a standard that all I/O has to be done using performs in the
procedure division copy. In theory, I can change the three copies to
anything I want, and the rest of the code is unchanged.

In fact, after a few years, I start to find patches ... programs that do
actual I/O rather than use the standard.  Those might be simple one-ups,
things like file conversion between versions, but each and everyone of them
"breaks" the standard.  I also have to recompile everything that uses the
copybook(s) if there are any changes.  The fact remains, though, that
something like a new index changes every program that uses the routines.

If I do the same thing with OOP, I get a much simpler situation.  The only
thing that now has to be consistant is the record layout of the master file.
The indices are now burried in one program that handles all the I/O for that
class of objects.  No program cares about indices, or about methods of
updating that are not used by it.  The only thing the application level does
is get and store records. Stuff like file-locking, record sharing, etc., are
totally imbeded.  I execute things like
"INCREMENT-CUSTOMER-TRANSACTION-TOTAL" with a total disregard as to the
methodology involved ... it can change from a simple one user procedure that
reads, adds, and writes to a multi-user procedure that reads and locks,
increments, then writes and unlocks without the application having a clue
that it even happened.  None of the apps have to even be re-compiled, even
if I change the indexing methods, and the complete organization.

Sure, you can accomplish the same thing by judicious use of copybooks,
standards, etc. This is simply a different tool that happens to do it
better, along with lots of other benefits at the same time.

Donald.



Mon, 17 May 2004 23:32:54 GMT  
 IBM announces new release of z/OS (OS/390) compiler


Quote:
> > So what is the advantage in having that "ONE Class(Program)", that
> overcomes
> > these two big costs?  (costs being that the method is hidden - making
> > debugging hard, and that everybody uses it - making acceptance testing
> real,
> > real hard)

> Well, one of the things it does is FORCE compliance to the rules.  Perhaps
> an example.

> What i want is to have absolutely standardized I/O.  Using the traditional
> method, I create three copybooks ... select clause, fd, and procedures. I
> then make it a standard that all I/O has to be done using performs in the
> procedure division copy. In theory, I can change the three copies to
> anything I want, and the rest of the code is unchanged.

If you have these in copybooks or objects you had better not change them.
Changing code that is in a thousand programs means you have to user
acceptance test a thousand programs.

Quote:
> In fact, after a few years, I start to find patches ... programs that do
> actual I/O rather than use the standard.  Those might be simple one-ups,
> things like file conversion between versions, but each and everyone of
> them
> "breaks" the standard.  I also have to recompile everything that uses the
> copybook(s) if there are any changes.  The fact remains, though, that
> something like a new index changes every program that uses the routines.

I don't care about the compiling them nearly as much as the testing -
especially user acceptance testing.

Quote:
> If I do the same thing with OOP, I get a much simpler situation.  The only
> thing that now has to be consistant is the record layout of the master
> file.
> The indices are now burried in one program that handles all the I/O for
> that class of objects.  No program cares about indices, or about methods
> of
> updating that are not used by it.  The only thing the application level
> does is get and store records. Stuff like file-locking, record sharing,
> etc.,
> are totally imbeded.  I execute things like
> "INCREMENT-CUSTOMER-TRANSACTION-TOTAL" with a total disregard as to the
> methodology involved ... it can change from a simple one user procedure
> that reads, adds, and writes to a multi-user procedure that reads and
> locks,
> increments, then writes and unlocks without the application having a clue
> that it even happened.  None of the apps have to even be re-compiled, even
> if I change the indexing methods, and the complete organization.

Fine, as long as everything works fine and your method never needs to be
changed.

Quote:
> Sure, you can accomplish the same thing by judicious use of copybooks,
> standards, etc. This is simply a different tool that happens to do it
> better, along with lots of other benefits at the same time.

Agreed.  But the problem appears to be just as big with copybooks and called
programs.

We have a program that does KSDS I/O.  I have no idea why - it is harder to
access that program than it is to do things directly.   But it has a couple
of problems:
1.  It doesn't pass the VSAM status code to the calling program when there
is an error - it simply passes on an error code signifying failure.
2.  It doesn't know that VSAM status code 97 is a good status.  When this
happens, it tells the calling program the command failed, and the calling
program aborts.   We don't know why it aborts though - if we run it again
and it works, we might assume a code 97 was the initial cause, but that's
just a guess.

OK, so the called program needs to be fixed.   But if we change this called
program, we have to test, system test, and user acceptance test every single
program that calls this routine.   Costs too much.   It is cheaper to call
programmers in periodically to try to guess what caused the program than to
go through all of this.

Fortunately, we are phasing out VSAM, so the problem will go away.

Let's replace this called program with an OO object.   Will that make it not
need maintenance?  No.  Will that maintenance require extensive testing,
systems testing, and user acceptance testing on every application that
accesses that object?   Yes.

Which is easier - coding or user acceptance testing?   Which is more
expensive?   Which is likely to become even more expensive in the future?

We need some integration - but interdependencies are costly when they have
to be maintained.

That's not to say that there isn't a place for OO in the mainframe world.  
But one of its highly touted advantages is also a big disadvantage in
environments where I have worked.



Tue, 18 May 2004 00:18:22 GMT  
 IBM announces new release of z/OS (OS/390) compiler
Let's take Howards example and his legitimate concern about user acceptance.
Say we have to change something fairly basic in an OO class that is used
systemically, but we don't have time or inclination to go through the user
acceptance on the thousands of programs that utilize that class.  The solution
is to either create an Interface that utilizes that class or to create a new
class that inherits from the old.  The programs get the benefit of the tired and
true class but don't have the cost of the global user acceptance testing.


Quote:


>> > So what is the advantage in having that "ONE Class(Program)", that
>> overcomes
>> > these two big costs?  (costs being that the method is hidden - making
>> > debugging hard, and that everybody uses it - making acceptance testing
>> real,
>> > real hard)

>> Well, one of the things it does is FORCE compliance to the rules.  Perhaps
>> an example.

>> What i want is to have absolutely standardized I/O.  Using the traditional
>> method, I create three copybooks ... select clause, fd, and procedures. I
>> then make it a standard that all I/O has to be done using performs in the
>> procedure division copy. In theory, I can change the three copies to
>> anything I want, and the rest of the code is unchanged.

>If you have these in copybooks or objects you had better not change them.
>Changing code that is in a thousand programs means you have to user
>acceptance test a thousand programs.

>> In fact, after a few years, I start to find patches ... programs that do
>> actual I/O rather than use the standard.  Those might be simple one-ups,
>> things like file conversion between versions, but each and everyone of
>> them
>> "breaks" the standard.  I also have to recompile everything that uses the
>> copybook(s) if there are any changes.  The fact remains, though, that
>> something like a new index changes every program that uses the routines.

>I don't care about the compiling them nearly as much as the testing -
>especially user acceptance testing.

>> If I do the same thing with OOP, I get a much simpler situation.  The only
>> thing that now has to be consistant is the record layout of the master
>> file.
>> The indices are now burried in one program that handles all the I/O for
>> that class of objects.  No program cares about indices, or about methods
>> of
>> updating that are not used by it.  The only thing the application level
>> does is get and store records. Stuff like file-locking, record sharing,
>> etc.,
>> are totally imbeded.  I execute things like
>> "INCREMENT-CUSTOMER-TRANSACTION-TOTAL" with a total disregard as to the
>> methodology involved ... it can change from a simple one user procedure
>> that reads, adds, and writes to a multi-user procedure that reads and
>> locks,
>> increments, then writes and unlocks without the application having a clue
>> that it even happened.  None of the apps have to even be re-compiled, even
>> if I change the indexing methods, and the complete organization.

>Fine, as long as everything works fine and your method never needs to be
>changed.

>> Sure, you can accomplish the same thing by judicious use of copybooks,
>> standards, etc. This is simply a different tool that happens to do it
>> better, along with lots of other benefits at the same time.

>Agreed.  But the problem appears to be just as big with copybooks and called
>programs.

>We have a program that does KSDS I/O.  I have no idea why - it is harder to
>access that program than it is to do things directly.   But it has a couple
>of problems:
>1.  It doesn't pass the VSAM status code to the calling program when there
>is an error - it simply passes on an error code signifying failure.
>2.  It doesn't know that VSAM status code 97 is a good status.  When this
>happens, it tells the calling program the command failed, and the calling
>program aborts.   We don't know why it aborts though - if we run it again
>and it works, we might assume a code 97 was the initial cause, but that's
>just a guess.

>OK, so the called program needs to be fixed.   But if we change this called
>program, we have to test, system test, and user acceptance test every single
>program that calls this routine.   Costs too much.   It is cheaper to call
>programmers in periodically to try to guess what caused the program than to
>go through all of this.

>Fortunately, we are phasing out VSAM, so the problem will go away.

>Let's replace this called program with an OO object.   Will that make it not
>need maintenance?  No.  Will that maintenance require extensive testing,
>systems testing, and user acceptance testing on every application that
>accesses that object?   Yes.

>Which is easier - coding or user acceptance testing?   Which is more
>expensive?   Which is likely to become even more expensive in the future?

>We need some integration - but interdependencies are costly when they have
>to be maintained.

>That's not to say that there isn't a place for OO in the mainframe world.  
>But one of its highly touted advantages is also a big disadvantage in
>environments where I have worked.



Tue, 18 May 2004 00:35:29 GMT  
 
 [ 38 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. IBM: Announces new OS/390 (and VM) compiler

2. OS/390 release test periods Re: default variable initialization under os/390 v2r8

3. Python for IBM OS/400 OS/390

4. Cobol OS/390 to C OS/390 V2R6

5. CobAnal for MVS, OS/390 and z/OS New version

6. New PL/I compiler for OS/390

7. USA CA Norwalk - IBM MVS-OS/390 Systems Programmer

8. USA CA Norwalk - IBM MVS-OS/390 Systems Programmer

9. USA CA Norwalk - IBM MVS-OS/390 Systems Programmer

10. Paragraph Recursion with IBM Cobol for OS/390?

11. USA CA Norwalk - IBM MVS-OS/390 Systems Programmer

12. IBM - "replacement" for OS/390

 

 
Powered by phpBB® Forum Software