Re: Considering Enterprise COBOL 5.2 "exit" enhancements

> —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

Re: Error in a simple COBOL program

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: Any Gotchas going from V1.13 to V2.2

> -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:

Re: Any Gotchas going from V1.13 to V2.2

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

Error in a simple COBOL program

"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

Re: Any Gotchas going from V1.13 to V2.2

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

Re: Error in a simple COBOL program

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

Re: Any Gotchas going from V1.13 to V2.2

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

Re: Any Gotchas going from V1.13 to V2.2

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

Re: Any Gotchas going from V1.13 to V2.2

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+. . . .

Re: Any Gotchas going from V1.13 to V2.2

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

Re: Any Gotchas going from V1.13 to V2.2

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

64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Considering Enterprise COBOL 5.2 "exit" enhancements

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

Size default in CEEPRMxx V5R1

> 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

Considering Enterprise COBOL 5.2 "exit" enhancements

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

Any Gotchas going from V1.13 to V2.2

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

Re: CA-Disk and PDSE V2 Member Generations Warning

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

Re: Considering Enterprise COBOL 5.2 "exit" enhancements

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

Re: Considering Enterprise COBOL 5.2 "exit" enhancements

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: CA-Disk and PDSE V2 Member Generations Warning

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

CA-Disk and PDSE V2 Member Generations Warning

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: 64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

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

Re: Error in a simple COBOL program

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

Re: issue WTOR if surrogat ID submits a job

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

Considering Enterprise COBOL 5.2 "exit" enhancements

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'

Re: Mainframe Testing

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