We had an issue with dataspace and aleentries, using aleserv-macros.
What was it?
Per default there are about 510 entries in the ale-list. Every ale-entry
must be deleted explicitly, as stated int the IBM-description.
Up to zOS 1.13 , when deleting a dataspace, the ale-entries were deleted
a
Why has ALTER always been bad? Because of the potential scope of things that
you can do with it, or because COBOL programmers will ignore or be unaware of
any "best practice" for using it, or something else? If either of the first
two, then away goes "EXIT PARAGRAPH/SECTION" into the bad-boys-bu
> —SNIP
> ALTER is bad because its not obvious when you look at a piece of code where
> it might actually branch to.
>
Alter has *ALWAYS* been bad.
Ed
--
For IBM-MAIN subscribe
On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger wrote:
> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
> unsuccessful."
That message is indeed specific, but it does not exactly scream out "... expect
operation exception to follow this message."
> Program outsid
In my opinion, CALLINTERFACE, while a great idea, was not implemented
correctly. There should have been a way to specify (in the "repository"?)
which programs should be called which ways; rather than having to wrap each
exception in a >>CALLINTERFACE.
That being said, I just wrote a COBOL DLL
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Wednesday, July 13, 2016 4:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Any Gotchas going from V1.13 to V2.2
>
> On 7/13/2016 3:06 PM, Gibney, Dave wrote:
>
On 7/13/2016 3:06 PM, Gibney, Dave wrote:
Any idea how it will perform in a zIIP/zAAPles hardcapped environment :)
Poorly. zIIP is recommended for any Java-based workload.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoft
"IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was
unsuccessful."
Program outside of TSO then gets an LE User Abend (U4038). No S0C1.
Sure, it is not ideal that under TSO there is a S0C1 instead, but its not that
we are so used to S0C1s from COBOL that we didn't notice
Hi there,
We bumped into an IDCAMS enhancement.
Under 1.13 a LISTCAT LEVEL of a GDG Base name which had no generations
defined, gave us a return code value of 4, which we could use either in the
IDCAMS control statement flow, or in the JOB Step flow.
Under 2.1, we receive a value of zero, whether o
On Wed, 13 Jul 2016 00:51:41 -0500, Bill Woodger wrote:
> The S0C1 with that exact set-up does not "normally" happen in COBOL (by which
> I mean,
> by COBOL running in batch).
>
> COBOL programs are not "normally" run under TSO.
You may consider it to not be normal, but there is no reason that
Depending on your use, BPX.DEFAULT.USER could be time consuming to address.
Otherwise skim the various documents like Migration from z/OS V2R1 and z/OS
V1R13 to z/OS V2R2 (GA32-0889-05), Migrating to z/OS 2.2 presentations (Marna
Walle) and Health Checker checks ZOSMIGV2*.
Regards,
Kevin
---
Any idea how it will perform in a zIIP/zAAPles hardcapped environment :)
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Wednesday, July 13, 2016 3:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Any G
There is definitely a migration process for z/OSMF, but it's totally worth the
trouble. We've had z/OSMF configured on sandbox since it was introduced many
releases ago but never considered it ready for prime time until now. If you've
run it in the past, you'll find it reborn in 2.1+.
.
.
.
J
I would add that if you are using Websrv, only the Appache based version is
available, the Domino version (PGM=IMWHTTPD) stopped being distributed with
z/OS 2.1.
Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298
-Original Message-
From: IBM Mainframe Discussi
http://publibz.boulder.ibm.com/epubs/pdf/e0z3m112.pdf
I think the biggest new item is the Jes2 and z/OS simultaneous upgrade.
z/OS 1.13 didn't require JES2 to upgrade at same time.
z/OSMF is now included instead of separate package.
On Wed, Jul 13, 2016 at 2:52 PM, Ward, Mike S wrote:
> Hello all
There is a new CALLINTERFACE compiler directive. At the moment it supports DLL,
STATIC and DYNAMIC, but it could be made available for other uses if that was
thought to be a useful thing.
However, there's another potential nightmare in the waiting. CALLINTERFACE
affects all CALLs which appear p
Frank, there are not often more than two of us at the COBOL Cafe. Sorry for
hijacking (didn't realise I was) but...
I have no problem in contributing to "best practice". Oh, I do, because I still
see no genuine need for them. I have no problem contributing to "2nd-best
practice".
I don't think
> We are migrating from cobol V4R2 to V5R1. Some of our test compilations ca=
>ncel with IGYLI5062-U and we must increase the default SIZE in COBOL option=
>s. We want to avoid change this option in the PARM sentence in JCL and set =
>in CEEPRMxx member in PARMLIB, but we can't find the parameter i
So, given that ALTER was (ab)used (it is really simple to use it in a
controlled manner, even to confirm in a dump where the paragraph is going, but
try telling that to people at parties, they just slowly move across the room
away from you), why would the assumption be that various forms of EXIT
Hello all, we will be migrating from V1.13 of z/OS to V2.2 in the next couple
of months. Is anyone aware of any gotchas that we need to look out for?
Thanks in advance.
==
This email, and any files transmitted with it, is confidential and intended
solely for the use of t
I would agree, since PDSE V2 member generations came along with V2.1, and while
maybe not widely used, has been in the wild for some time now.
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
I completely agree with Frank on the use of ALTER - it makes normal debugging
of programs VERY difficult especially when the programs in questions are
20,000+ line dinosaurs that have been modified many times over the decades by
many different programmers.
I also agree with use of GO TO, but
With the elimination of procedure division sections and PERFORM THRU, and
without the use of GO TO, there should be no reason to insert such a label.
The new EXIT statements allow us to do all (?) of this without the need for
doing those "more dangerous" (in my opinion) things.
ALTER is bad b
On Wed, 13 Jul 2016 10:54:05 -0500, John McKown wrote:
>On Wed, Jul 13, 2016 at 10:33 AM, Tom Marchant <
>000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Or COBOL. Or PL/I. (I think)
>>
>
>There's a 64 bit XPLINK COBOL compiler now?
Sorry about that. This was discussed here a few mon
On Wed, 13 Jul 2016 11:12:28 -0500, Lionel B Dyck wrote:
>
>1. Archive appears to work fine - no errors, no messages
>2. Restore appears to work fine - messages for each member being restored
>3. After Restore there are NO GENERATIONS and the PDSE V2 has NO MAXGEN so
>you now have lost all generati
If you are using PDSE V2 member generations and have CA-Disk managing your
storage be very aware that CA-Disk in its current incarnation does NOT
support member generations.
What happens is:
1. Archive appears to work fine - no errors, no messages
2. Restore appears to work fine - messages for ea
On Wed, Jul 13, 2016 at 10:33 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 13 Jul 2016 09:57:45 -0500, John McKown wrote:
>
> >Isn't it a really _nasty_ way to force the C compiler down people's
> >throat? In order to use AMODE 64 && LE, you __must__ write t
On Wed, 13 Jul 2016 09:57:45 -0500, John McKown wrote:
>Isn't it a really _nasty_ way to force the C compiler down people's
>throat? In order to use AMODE 64 && LE, you __must__ write the "main"
>routine in C. Even if all it does is call an assembler routine which does
>all the real work.
Or CO
On Wed, Jul 13, 2016 at 9:53 AM, Steve Austin
wrote:
> Thanks John I had not seen that.
>
Isn't it a really _nasty_ way to force the C compiler down people's
throat? In order to use AMODE 64 && LE, you __must__ write the "main"
routine in C. Even if all it does is call an assembler routine whic
Thanks John I had not seen that.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: 13 July 2016 15:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit XPLINK LE assembler program initialisation error U4093
reason X'21
No. You can't have a 64-bit main written in assembler. While the 31-bit
CEEENTRY macro has a MAIN=YES option, there isn't such a thing (as you've
seen) in CELQPRLG.
In article
you
wrote:
> Explanation
> Errors were detected during initialization.
> Reason code
> Explanation
> X'218' (536)
> La
Please excuse the top post. Have you seen this from
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/ceeam109.htm
:
Any AMODE 64 assembler routine that is used within the scope of a Language
Environment application must use 64-bit XPLINK save area conventions.
Explanation
Errors were detected during initialization.
Reason code
Explanation
X'218' (536)
Language Environment initialization was requested for an AMODE 64 application
that does not contain a main. Specifically, the CELQMAIN CSECT is not present
in the program object or the CELQMAIN CSECT doe
On Tue, 12 Jul 2016 14:19:26 -0700, Charles Mills wrote:
>
>
>The op code is ... just a binary byte in any event, not hex.
In some cases there are more bits than the first byte of an instruction that
are part of the opcode. Opcodes can be 8, 12, or 16 bits, depending on the
instruction. The fir
On Tue, Jul 12, 2016 at 11:56 PM, Edward Gould
wrote:
> Do you really want the operators involved in this?
They have enough work to do.
> Consider cancelling the job period.
>
> Ed
>
>
I agree. I've become curious about the reason for this request. I am
assuming that this is some sort of "produ
Please list from all those languages in which of them the logic flow changes by
adding a label.
There is nothing intrinsic with ALTER ... TO PROCEED TO ... or GO TO ...
DEPENDING ON ... or GO TO itself which makes it "bad", it is the way that they
were (ab)used.
"My program is 'Structured' bec
Thanks David,
I know you folks use it extensively, I'm trying work out what the wider
world demand is for training.
Would be good to incorporate a reference site or some case studies though
if the course eventuates.
I'll ping Alan..
On Wed, Jul 13, 2016 at 3:38 PM, David Crayford wrote:
> On
37 matches
Mail list logo