On Fri, 25 Apr 2014 18:52:50 -0400, Don Poitraspoit...@pobox.com wrote:
As for stack extensions, there isn't a lot of code that would go
deeper than one megabyte and that's the minimum allocation size for
64-bit.
Especially since the maximum allocation for a program is architected at 2K.
--
In 20140424213615.6004883.18431.8...@yahoo.ca, on 04/24/2014
at 05:36 PM, Ted MacNEIL eamacn...@yahoo.ca said:
Early compiler writers used the term for languages that used 'call by
name' sub-routines (such as FORTRAN) when something like an
expression was passed.
That's not call by name.
: Thursday, April 24, 2014 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL v5.1 and RDz v9.x
On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote:
PMFJI here, but it is my impression (please correct me if I am wrong)
that XPLINK is the z/OS analog of the calling mechanism
In
985915eee6984740ae93f8495c624c6c232c1e0...@jscpcwexmaa1.bsg.ad.adp.com,
on 04/25/2014
at 10:59 AM, Farley, Peter x23353 peter.far...@broadridge.com
said:
Seems wasteful of CPU cycles to me,
How often do you expect to hit the guard page? An explicit test for
stack overflow costs you at
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Marchant
Sent: Thursday, April 24, 2014 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL v5.1 and RDz v9.x
On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote:
PMFJI here, but it is my impression (please
On Fri, Apr 25, 2014 at 9:59 AM, Farley, Peter x23353
peter.far...@broadridge.com wrote:
I see the descriptions of the XPLINK and XPLINK-64 conventions in that
manual, but nothing about those conventions would prevent calls to programs
with other linkage conventions or address modes, IMHO
Here in this forum and elsewhere the notion that since the binder's
support for AMODE(SPLIT) had been little used it would not be
necessary or desirable to provide an analogous binder facility for
mixing AMODE(31) and AMODE(64) in the same executable was widely
reported. (I use the word
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Tuesday, April 22, 2014 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL v5.1 and RDz v9.x
On Mon, 21 Apr 2014 15:31:31 -0500, Paul Gilmartin wrote:
z/OS engenders enormous obstacles
On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote:
PMFJI here, but it is my impression (please correct me if I am wrong)
that XPLINK is the z/OS analog of the calling mechanism developed in
Germany for z/Linux from the kernel on up to user space.
I don't know about that. XPLINK
On Thu, 24 Apr 2014 12:32:32 +0800, Timothy Sipples wrote:
I remember a school of thought that thunking might not have been a good
idea because it encouraged developers to do what they do best: nothing. :-)
I never heard of thunking before. It sounds to me like a derogatory term
for calling
On 4/24/2014 4:50 PM, Tom Marchant wrote:
I never heard of thunking before. It sounds to me like a derogatory term
for calling routines that run in different addressing modes. Is that what is
intended?
I first heard the term in a book on the OS/2 system design and
implementation, and I'm sure
List
Subject: Re: Enterprise COBOL v5.1 and RDz v9.x
You're right about the term thunk, and that it was first used in
the call-by-name context, but
FORTRAN was always call-by-reference,
call-by-name was one of the ALGOL call mechanisms
(the other one was call-by-value)
http://en.wikipedia.org/wiki
I wrote:
I don't know if I'd agree with that school of thought
Tom Marchant replied:
I hope that you are not suggesting that z/OS should not have been
released until everything ran AMODE 64. We might still be waiting.
Setting aside that thunking services are not particularly related to
In 3186ca10-04ab-4743-b8da-d87a8e8a7...@comcast.net, on 04/21/2014
at 09:50 AM, Ed Gould edgould1...@comcast.net said:
On Apr 21, 2014, at 7:37 AM, Shmuel Metz (Seymour J.) wrote:
---SNIP
IDCAMS is just a utility that was included with
In 5960275020768726.wa.paulgboulderaim@listserv.ua.edu, on
04/21/2014
at 11:58 AM, Paul Gilmartin paulgboul...@aim.com said:
What do PDSE and the (obsolescent) HFS use?
I believe that while they are CI formatted and use the Media Manager,
they are not VSAM.
What about paging and JES? Do
I learned via PMR that Rational Developer for System z (RDz)
.v9.x (latest greatest) does not officially support
Enterprise COBOL v5.1.
SNIPPAGE
Ooops, sorry about that too. RDz development might not know that=20
we in COBOL are planning to add support to COBOL =E2=80=A6
SNIPPAGE
-
On Wed, 23 Apr 2014 13:33:12 +0800, Timothy Sipples wrote:
Tom Marchant writes:
The design of XPLINK and XPLINK-64 currently precludes the mixing of
the two.
Are you asking that LE support and facilitate 31-bit/64-bit thunking?
Have you raised that requirement yet?
I have not submitted a
Maybe IBM decided that XPLINK should be the only - or preferred -
linkage method in the future, because standard linkage is considered
too expensive esspecially for small functions and inlining is not always
possible?
And this is done to force the users to migrate to XPLINK
when switching to
As it happens (in my personal view) I agree with you, Tom. But I also agree
that IBM should focus first on what its current and prospective customers
want. In the fullest meaning of want. That is, I agree with the late
Steve Jobs that customers often don't know what they want in large part
because
Bernd Oppolzer wrote
the support for programmers there is non-existent ... if you need it, you
have to buy expensive compiler suites from M$
But in fact, since many years now M'$' give away their Visual Studio
development environment (with a few for most developers non-essential
Original Message
Subject:re: Enterprise COBOL v5.1 and RDz v9.x
Date:Mon, 21 Apr 2014 11:59:45 -0700
From:Tom Ross tmr...@stlvm20.vnet.ibm.com
mailto:tmr...@stlvm20.vnet.ibm.com
Subject: Enterprise COBOL v5.1 and RDz v9.x
I learned via PMR that Rational
You are right, of course,
I was not very precise and mixed up things a bit.
I started with development on little machines in the early 1980s,
that was even before IBM-PC, and the first systems were called
CP/M and later MS/DOS, and at that time the usage of different
compilers and linking stuff
On Mon, 21 Apr 2014 15:31:31 -0500, Paul Gilmartin wrote:
z/OS engenders enormous obstacles to migrating to an all 64-bit LE enabled
universe.
Yes. Not the least of which is that the LE direction is to support 64-bit code
only with XPLINK, and that there is no mechanism in LE for a non-XPLINK
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tom Ross
I should have done more research before opening my mouth...RDz does in fact
support generating COBOL
programs with XML PARSE in 2 different flavors. You can specify 'generate
for XMLPARSE(COMPAT)' or
Tom Marchant writes:
The design of XPLINK and XPLINK-64 currently precludes the mixing of
the two.
Are you asking that LE support and facilitate 31-bit/64-bit thunking?
Have you raised that requirement yet?
In
of35d04e20.c5643349-on48257cc1.0019cee7-48257cc1.001d0...@sg.ibm.com,
on 04/21/2014
at 01:14 PM, Timothy Sipples sipp...@sg.ibm.com said:
IBM first introduced VSAM (in a more basic form of course) back in
the 1970s for DOS/VS, OS/VS1, and OS/VS2 (Access Method Services).
IDCAMS is just a
I'm pretty sure the original motivation behind VSAM was to provide a
more efficient keyed-access alternative to an earlier ISAM (Indexed
Sequential Access Method) keyed-access method --ISAM had abysmal
performance when the number of inserts became large. But, just as a
clarification, while it is
On Apr 21, 2014, at 7:37 AM, Shmuel Metz (Seymour J.) wrote:
---SNIP
IDCAMS is just a utility that was included with VSAM. IBM initially
offered VSAM as an Incremental Change Release (ICR), but the ICF came
in with the program product DF/EF.
On 4/21/2014 7:59 AM, Joel C. Ewing wrote:
DB2 required greater flexibility and control to achieve its performance
and data consistency goals than was possible with VSAM keyed-access
support. A very cursory look at Experiences Installing Oracle
Database 10g on z/OS would suggest Oracle on z/OS
For whatever reason, such as insanity?, I have always viewed a VSAM LDS as
a private, permanent paging space. Similar in concept to using the UNIX
shmat() series of functions on a UNIX file to do I/O basically just using
paging operations. At times, I wish that using DIV windowing services were
On Mon, 21 Apr 2014 09:09:37 -0700, Ed Jaffe wrote:
On 4/21/2014 7:59 AM, Joel C. Ewing wrote:
DB2 required greater flexibility and control to achieve its performance
and data consistency goals than was possible with VSAM keyed-access
support. A very cursory look at Experiences Installing
I learned via PMR that Rational Developer for System z (RDz) v9.x (latest
greatest) does not officially support
Enterprise COBOL v5.1. The workaround suggested by RDz Support was to specify
COBOL v4.2 and XMLPARSE(XMLSS) in the RDz
wizard, because COBOL v5.1 does not support XMLPARSE(COMPAT).
On Mon, 21 Apr 2014 11:52:01 +0200, Bernd Oppolzer wrote:
The German Telefunken mainframe TR440's operating system BS3 also
had keyed file access services (different types) and a common run time
environment
Like LE is supposed to be?
for all languages (ALGOL, FORTRAN, PASCAL, PL/1, COBOL, BCPL,
I know that DB2 does not use VSAM KSDS - only for very limited purposes,
IIRC - some logfile directories or boot strap data sets, don't recall
the details.
The tablespace data sets are VSAM LDS - linear data sets.
Anyway: there are some improvements done to VSAM for DB2, AFAIK ...
I believe
VSAM Media Manager
On Mon, Apr 21, 2014 at 4:49 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:
I know that DB2 does not use VSAM KSDS - only for very limited purposes,
IIRC - some logfile directories or boot strap data sets, don't recall the
details.
The tablespace data sets are VSAM
I wonder if it would be possible to have an XMLPARSE(RUNTIME) compiler
option that defers the decision about which XML to use to runtime,
preferably with a choice of automatic decision (if zIIP then...) or
explicit operator specification at program invocation.
Yes, the two XML choices are
I should have done more research before opening my mouth...RDz does in fact
support
generating COBOL programs with XML PARSE in 2 different flavors. You can
specify
'generate for XMLPARSE(COMPAT)' or 'generate for XMLPARSE(XMLSS)'. Generating
for XMLPARSE(XMLSS) should have worked for COBOL V5.
I do not find Clark Morris's response persuasive. It is not even a
'responsive' one, as lawyers use that term.
He used Edward Jaffe's formulation of what constitutes responsible ISV
behavior to suggest rhetorically that IBM was not responsible; and
this debater's point is itself irresponsible.
On Sat, 19 Apr 2014 21:44:44 -0300, Clark Morris wrote:
On 19 Apr 2014 08:00:49 -0700, in bit.listserv.ibm-main you wrote:
No, IBM is not an ISV, as hopefully you know, Mr. Morris.
Lately, I seem to have been casting myself in the role of a defender
of IBM. That is not my wont, and IBM can
On Sun, 20 Apr 2014 07:58:13 -0400, John Gilmore wrote:
I do not find Clark Morris's response persuasive. It is not even a
'responsive' one, as lawyers use that term.
He used Edward Jaffe's formulation of what constitutes responsible ISV
behavior to suggest rhetorically that IBM was not
To neither, although the point was made by Clark. A debater's point
is a ding an sich, a point/issue that is [perhaps] rhetorically but
not substantively significant.
A little diction-specific anosmia this morning? You're ordinarily
very good at smelling these things out.
John Gilmore,
On 4/19/2014 7:42 AM, Clark Morris wrote:
In regard to COBOL and RDz, does this imply that IBM is not a
responsible vendor?
If you're asking if I believe there should be a double standard for
software development organizations, the answer is No.
--
Edward E Jaffe
Phoenix Software
On 19 Apr 2014 18:51:09 -0700, in bit.listserv.ibm-main you wrote:
IMO, programming language and file organizations are
complete different things and should be discussed seperately.
Furthermore, you have direct access on all platforms, including
Windows and Unix; this is not a matter of
Am 20.04.2014 23:27, schrieb Clark Morris:
On 19 Apr 2014 18:51:09 -0700, in bit.listserv.ibm-main you wrote:
IMO, programming language and file organizations are
complete different things and should be discussed seperately.
Furthermore, you have direct access on all platforms, including
Bernd Oppolzer asks:
BTW: is VSAM part of the operating system?
Yes. VSAM is certainly a standard, included, essential, no additional
charge feature within the base z/OS and z/VSE operating systems.
IBM first introduced VSAM (in a more basic form of course) back in the
1970s for DOS/VS, OS/VS1,
On 18 Apr 2014 19:42:01 -0700, in bit.listserv.ibm-main you wrote:
On 4/14/2014 8:26 AM, Paul Gilmartin wrote:
How many ISVs reading this list would decline to support their products under
z/OS 2.1 because they were purchased at 1.13? But I'd expect some latency
for development and testing
No, IBM is not an ISV, as hopefully you know, Mr. Morris.
Lately, I seem to have been casting myself in the role of a defender
of IBM. That is not my wont, and IBM can anyway defend itself. I
have, however, grown tired, very tired of cheap shots like this one.
Easy to dismiss out of hand, they
On 19 Apr 2014 08:00:49 -0700, in bit.listserv.ibm-main you wrote:
No, IBM is not an ISV, as hopefully you know, Mr. Morris.
Lately, I seem to have been casting myself in the role of a defender
of IBM. That is not my wont, and IBM can anyway defend itself. I
have, however, grown tired, very
IMO, programming language and file organizations are
complete different things and should be discussed seperately.
Furthermore, you have direct access on all platforms, including
Windows and Unix; this is not a matter of programming language at all.
And: you have keyed access, because it is easy
On 4/14/2014 8:26 AM, Paul Gilmartin wrote:
How many ISVs reading this list would decline to support their products under
z/OS 2.1 because they were purchased at 1.13? But I'd expect some latency
for development and testing and/or requirement of an upgrade to the current
level of the ISV
[...]
When an upgrade to zOS 2.1 is performed is one automatically at Cobol 5.1 as
well?
Well, IT DEPENDS.
AFAIK you cannot order downlevel COBOL. So, when you order z/OS 2.1 now
and you also order COBOL - you will get 5.1 version.
In general you can order only current versions of the
On Mon, 14 Apr 2014 12:24:05 +, Chase, John jch...@ussco.com wrote:
Hi All,
I learned via PMR that Rational Developer for System z (RDz) v9.x (latest
greatest) does not officially support Enterprise COBOL v5.1. The
workaround suggested by RDz Support was to specify COBOL v4.2 and
W dniu 2014-04-15 13:24, Govind Chettiar pisze:
[...]
When an upgrade to zOS 2.1 is performed is one automatically at Cobol 5.1 as
well?
Well, IT DEPENDS.
AFAIK you cannot order downlevel COBOL. So, when you order z/OS 2.1 now
and you also order COBOL - you will get 5.1 version.
In general
This is not true. I ordered a ServerPac for z/OS 2.1 a couple of months ago
and I had no problem ordering Enterprise COBOL 4.2 along with it - there was no
requirement to upgrade to 5.1. Anyway, we can't upgrade to 5.1 until we
migrate to a sysplex across our 3 LPARs.
W dniu 2014-04-15 13:52, Peter X. DeFabritus pisze:
This is not true. I ordered a ServerPac for z/OS 2.1 a couple of months ago
and I had no problem ordering Enterprise COBOL 4.2 along with it - there was no
requirement to upgrade to 5.1. Anyway, we can't upgrade to 5.1 until we
migrate to
On Mon, 14 Apr 2014 12:24:05 +, Chase, John wrote:
Hi All,
I learned via PMR that Rational Developer for System z (RDz) v9.x (latest
greatest) does not officially support Enterprise COBOL v5.1. The
workaround suggested by RDz Support was to specify COBOL v4.2 and
XMLPARSE(XMLSS) in the
56 matches
Mail list logo
