AW: Re: SLIP trap on High CPU usage

[Peter Hunkeler]

>But a GTF Trace probably can.  I would look at GTF TRACE or VSM Traces.


But this will monitor VSM calls, not CPU usage. I understand the 
GETMAIN/FREEMAIN are expected, but only every now and then, they go wild. I 
don't see how GTF can help here.


I don't know the details, but I know we have some automation in place to detect 
high CPU users (jobs). AFAIK, it is based on MainView z/OS detecting such a job 
and then writting (WTO) a message, which in turn triggers automation.


Do you have some tool like MainView or Omegamon?


--
Peter Hunkeler




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

Re: SLIP trap on High CPU usage

[Lizette Koehler]

I do not think a SLIP trap will work.

But a GTF Trace probably can.  I would look at GTF TRACE or VSM Traces.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieav100/gfs.htm

GFS trace is a diagnostic tool that collects information about the use of the 
GETMAIN, FREEMAIN, or STORAGE macro. You can use GFS trace to analyze the 
allocation of virtual storage and identify users of large amounts of virtual 
storage. You must use the generalized trace facility (GTF) to get the GFS trace 
data output.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Munif Sadek
> Sent: Wednesday, May 30, 2018 8:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SLIP trap on High CPU usage
> 
> Dear listers
> 
> Is there a way to slip trap on a module/STC if it starts consuming higher MSU
> in zOS 2.3.
> 
> My problem is a vendor product where a user exit is being repetitively
> called, issuing unnecessary GETMAIN/FREEMAIN. Vendor has asked us to dummy
> out user exit and fix will come in the next release.  This problem is
> intermittent,  generally happens once every couple of  hours during  online
> window.
> 
> Dummied out User exit has provided  relief, still management perceived notion
> that Mainframe is expansive and Vendor reluctance to disclose what process is
> initiating  call to this exit, is there a way I can set a slip trap whenever
> CPU usage is spiked so that I can go back to vendor with SVC DUMP/ Systrace
> (Mod names) of the exact problem.
> 
> We  do have Strobe but strobe can not automate this request without
> integration with iStrobe and BMC Caze.
> 
> Did look at SLIP documentation but can not find relevant information.
> 
> kind regards,
> Munif.
> 
> --
> 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

SLIP trap on High CPU usage

[Munif Sadek]

Dear listers

Is there a way to slip trap on a module/STC if it starts consuming higher MSU 
in zOS 2.3. 

My problem is a vendor product where a user exit is being repetitively called, 
issuing unnecessary GETMAIN/FREEMAIN. Vendor has asked us to dummy out user 
exit and fix will come in the next release.  This problem is intermittent,  
generally happens once every couple of  hours during  online window.

Dummied out User exit has provided  relief, still management perceived notion 
that Mainframe is expansive and Vendor reluctance to disclose what process is 
initiating  call to this exit, is there a way I can set a slip trap whenever 
CPU usage is spiked so that I can go back to vendor with SVC DUMP/ Systrace 
(Mod names) of the exact problem.

We  do have Strobe but strobe can not automate this request without integration 
with iStrobe and BMC Caze. 

Did look at SLIP documentation but can not find relevant information.

kind regards,
Munif.

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

Re: HWIBCPII

[Ed Jaffe]

On 5/30/2018 2:59 PM, Jesse 1 Robinson wrote:

HWIBCPII is one of those magical address spaces that is started by Abracadabra:

S IEESYSAS,PROG=HWIAMIN2


Or by:

S HWISTART (which essentially does the same)

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: HWIBCPII

[Steve Smith]

The trouble with Abracadabra is getting it to work reliably.

sas

On Wed, May 30, 2018 at 5:59 PM, Jesse 1 Robinson 
wrote:

> HWIBCPII is one of those magical address spaces that is started by
> Abracadabra:
>
>S IEESYSAS,PROG=HWIAMIN2
>

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

Re: HWIBCPII

[Jesse 1 Robinson]

HWIBCPII is one of those magical address spaces that is started by Abracadabra: 

   S IEESYSAS,PROG=HWIAMIN2

IBM supplied proc IEESYSAS is a weird animal with no real content. The actual 
STC name is determined by the startup program.

//IEESYSAS PROC PROG=IEFBR14  
//IEFPROC  EXEC PGM= 
//* THE IEESYSAS PROCEDURE IS SPECIFIED IN THE
//* PARAMETER LIST TO IEEMB881 BY MVS COMPONENTS  
//* STARTING FULL FUNCTION SYSTEM ADDRESS SPACES.

When the named STC starts up, it has nothing allocated other than what z/OS has 
chosen dynamically for that magical name. It runs SUB=MSTR, but you cannot 
specify SUB=MSTR. In our shop, HWIBCPII starts before (independent of) JES2, 
and continues running after JES2 shutdown.

Examples of other tasks started with IEESYSAS:

//SMSVSAM  EXEC IEESYSAS,PROG=IDAVSJST  
//IOSASEXEC IEESYSAS,PROG=IOSVROUT   
//CEA  EXEC IEESYSAS,PROG=CEAINIT  
//WLM  EXEC IEESYSAS,PROG=IWMINJST 

Despite the appearance of 'SYSOUT' in the original post, these tasks cannot use 
JES services to handle print output. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, May 30, 2018 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: HWIBCPII

I don't know anything about this STC, but the first couple of messages imply 
you have SYSOUT files in the JCL.  Those require JES.  AFAIK, any STC waits for 
JES unless SUB=MSTR is specified, so don't do both.

sas


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

Re: Best Group for COBOL Question(s)

[Edward Gould]

> On May 30, 2018, at 9:43 AM, Steve Thompson  wrote:
> 
> 
> So anyone else see anything a bit silly about this?
> 
> 
> Regards,
> Steve Thompson

Steve,

IBM is in the business of making money and the more CPU you use the more 
computers they will sell.
Ed


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

Re: Best Group for COBOL Question(s)

[Lizette Koehler]

So  this is a good place to post compiler questions.  Yes COBOL Café on 
Developer works is also good.

If you have the ability to use Q on Service link, that might be best.

Tom Ross does look here occasionally.  But not guaranteed

Lizette

 

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Steve Thompson
> Sent: Wednesday, May 30, 2018 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best Group for COBOL Question(s)
> 
> Folks:
> 
> I've been searching and searching, and I know that at one time there was a
> COBOL List server, but I can't find it now.
> 
> My question is, what would be the best group to ask a compiler question
> (specific to COBOL) that Tom (forgot his last name), would probably see?
> 
> IBM's blogs, community, etc are not my idea of a good time -- already got out
> there and spent too much time battling through their interface.
> 
> And so you can enjoy this, my question is, why is it that OPT(0) overrides
> INITCHECK, but if I ask for Optimization (e.g, OPT(1)) it works?
> 
> Frankly, I do not want anyone using INITCHECK (IC) outside of
> OPT(0) which means NOOPT (except that you can't say that with COBOL 6.2).
> 
> Yes, INITCHECK is ONLY done by the Compiler during Parse/SCAN operations and
> not during code gen (as I read the manual).
> 
> But it takes more CPU for this to work, so why do that AND the CPU burn of
> Optimization for a compile where one is attempting to determine if fields are
> being referenced before they have had something put in them?
> 
> So anyone else see anything a bit silly about this?
> 
> 
> Regards,
> Steve Thompson
> 
> --
> 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: [External] Re: Comments in IDCAMS statements

[Pommier, Rex]

Hi Steve,

What I find interesting is that apparently the comment close string "*/" is 
optional.  If you don't include it, it defaults to "this is a comment until the 
end of the logical line".  Thus if you have a hyphen at the end of the line 
even though it is after a "/* IDCAMS recognizes it as a continuation character 
even though it is officially inside the comment, but if there's a hyphen with 
other characters following it, the hyphen is counted as part of the comment.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, May 30, 2018 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Comments in IDCAMS statements

 Ah... continuation character... that's what I forgot.

I'm not sure this scheme is entirely sensible, nor is it documented
correctly, but at least the mystery is resolved.

sas


On Wed, May 30, 2018 at 12:27 PM, Pommier, Rex 
wrote:

> You are correct.
>
> Simple job:
>
> //STEP1  EXEC  PGM=IDCAMS
> //SYSPRINT  DD  SYSOUT=*
> //SYSIN   DD  *
>   /*  THIS IS A COMMENT  */
>   /*  SO IS THIS */
> /*
> //STEP2  EXEC  PGM=IDCAMS
> //SYSPRINT  DD  SYSOUT=*
> //SYSIN   DD  *
>   /*  THIS IS A COMMENT  -
>   SO IS THIS */
> /*
>
> Output:
>
> IDCAMS  SYSTEM SERVICES
>
>   /*  THIS IS A COMMENT  */
>   /*  SO IS THIS */
> IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
> IDCAMS  SYSTEM SERVICES
>
>   /*  THIS IS A COMMENT  -
>   SO IS THIS */
> IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
>
> No complaints about a multi-line comment.
>
> Rex
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Wawiorko
> Sent: Wednesday, May 30, 2018 9:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Comments in IDCAMS statements
>
> Isn't this more lack of the IDCAMS continuation character ' - ' or does my
> memory fail me?
>
> Mike Wawiorko
>

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: empty KSDS behavior - why?

[Steve Smith]

ACB MACRF=RST forces a VSAM file into load mode.  It doesn't seem like it
would be so difficult or incompatible to add a new MACRF option to force
initialization into "loaded" mode (as opposed to failing the OPEN as it now
does).  MACRF=RST requires some DEFINE option as well, but I'm not sure
there's any logical need for it.

sas

On Wed, May 30, 2018 at 1:33 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Let's just say that I can't think of a case where I'd want that
> differentiation.
>
> Anyway, obviously IBM shouldn't change the default, but it seems to me
> they could provide a new option on DEFINE CLUSTER to have it "pre-loaded"
> (have the HURBA set to non-zero).  Or perhaps provide a new IDCAMS command
> (or maybe REPRO parameter) to do it.  I may open an RFE.  Can't hurt to try?

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

Re: HWIBCPII

[Steve Smith]

I don't know anything about this STC, but the first couple of messages
imply you have SYSOUT files in the JCL.  Those require JES.  AFAIK, any STC
waits for JES unless SUB=MSTR is specified, so don't do both.

sas

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

Re: Comments in IDCAMS statements

[Steve Smith]

 Ah... continuation character... that's what I forgot.

I'm not sure this scheme is entirely sensible, nor is it documented
correctly, but at least the mystery is resolved.

sas


On Wed, May 30, 2018 at 12:27 PM, Pommier, Rex 
wrote:

> You are correct.
>
> Simple job:
>
> //STEP1  EXEC  PGM=IDCAMS
> //SYSPRINT  DD  SYSOUT=*
> //SYSIN   DD  *
>   /*  THIS IS A COMMENT  */
>   /*  SO IS THIS */
> /*
> //STEP2  EXEC  PGM=IDCAMS
> //SYSPRINT  DD  SYSOUT=*
> //SYSIN   DD  *
>   /*  THIS IS A COMMENT  -
>   SO IS THIS */
> /*
>
> Output:
>
> IDCAMS  SYSTEM SERVICES
>
>   /*  THIS IS A COMMENT  */
>   /*  SO IS THIS */
> IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
> IDCAMS  SYSTEM SERVICES
>
>   /*  THIS IS A COMMENT  -
>   SO IS THIS */
> IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
>
> No complaints about a multi-line comment.
>
> Rex
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Wawiorko
> Sent: Wednesday, May 30, 2018 9:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Comments in IDCAMS statements
>
> Isn't this more lack of the IDCAMS continuation character ' - ' or does my
> memory fail me?
>
> Mike Wawiorko
>

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

Re: empty KSDS behavior - why?

[Seymour J Metz]

As opposed to the folly of testing at the top of the loop when that will give 
incorrect results? You've got to carve the bird at the joints, and no two birds 
are created equal. Blindly following dogmatic rules will cause errors in your 
code.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 29, 2018 3:42 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 19:12:32 +, Frank Swarbrick wrote:

>Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is 
>0):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
>IDC3300I  ERROR OPENING DVFJS.DUMMY1
>IDC3351I ** VSAM OPEN RETURN CODE IS 160
>IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
>
>Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record 
>(HI-U-RBA is now 829440):
>
> REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2)
>IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
>IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
>
>In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still 
>0).
>
And I suppose it still ABENDs if you attempt to read a record or to REPRO again
DUMMY2 to DUMMY3?  Ugh!

I believe this demonstrates the utter folly of testing at the bottom of a loop
rather than at the top.  A WHILE loop doesn't attempt to access a record when
there is none; an UNTIL loop attempts to process one record regardless.

I'm not very sympathetic to the argumemt of performance, that UNTIL
performs the test N times but WHILE performs it N+1.

Imagine "ls" or "dir" or "BLDL"'s ABENDing on an empty directory!  (Does
ISPF member list still report an error on an empty directory, or just show
an empty screen except for header lines?)

-- gil

--
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: empty KSDS behavior - why?

[Charles Mills]

I give up. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, May 30, 2018 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Wed, 30 May 2018 06:15:11 -0700, Charles Mills  wrote:

>Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
>their COBOL programs blowing up if they fail to do the right juju on their new 
>VSAM file?
>
Not COBOL, but from a recent ply:

On Tue, 29 May 2018 21:29:25 -0400, Roger W Suhr wrote:
>...
>I recently found out that some IBM utilities (IMS DBRC) actually expect a 
>cluster in "create mode", when switching to a new secondary RECON dataset.  If 
>you provide an initialize cluster, the DBRC utility ABENDS and says the 
>dataset had been used before and no valid header record could be found.
>So I doubt IBM will ever provide an option to do this in the DEFINE command.
> 

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

Re: empty KSDS behavior - why?

[Paul Gilmartin]

On Wed, 30 May 2018 06:15:11 -0700, Charles Mills  wrote:

>Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
>their COBOL programs blowing up if they fail to do the right juju on their new 
>VSAM file?
>
Not COBOL, but from a recent ply:

On Tue, 29 May 2018 21:29:25 -0400, Roger W Suhr wrote:
>...
>I recently found out that some IBM utilities (IMS DBRC) actually expect a 
>cluster in "create mode", when switching to a new secondary RECON dataset.  If 
>you provide an initialize cluster, the DBRC utility ABENDS and says the 
>dataset had been used before and no valid header record could be found.
>So I doubt IBM will ever provide an option to do this in the DEFINE command.
> 
Why do the VSAM faithful believe that if this were done it must be done wrong!?

I see "option" as the operant word here.  If an option were provided and the
historic behavior were the default, there'd be no adverse consequence.

My only use of DEFINE CLUSTER has been creating SMP/E CSIs.  Then
I (must?) REPRO GIMZPOOL to initialize the KSDS.  I don't know whether
this provides a header record.  I don't know whether a fits-all analogue
of GIMZPOOL could be provided in SAMPLIB.  I don't know whether this
necessarily creates a record with the risk of key conflict.  But for SMP/E
CSI it can be done in the same IDCAMS step, minimally burdensome.

>There are programs available on the CBT Tape (CBTTAPE.ORG) that will 
>initialize a new cluster (intelligently).  Personally, I like the INITKSDS 
>program. 
>
ISVs, at least, dislike introducing dependencies on fourth-party products,
particularly those that may be unsupported.

-- gil

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

Re: Comments in IDCAMS statements

[Elardus Engelbrecht]

Steve Smith wrote:

>I thoguht I understood how to run AMS.  Either I don't, or something strange 
>is going on:

[ ... snipped ... ]

Please post the full IDCANS statements as well the JCL you used. Then the 
IBM-MAIN members can then see what you're trying to use.

Groete / Greetings
Elardus Engelbrecht

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

Re: Comments in IDCAMS statements

[Pommier, Rex]

You are correct.

Simple job:

//STEP1  EXEC  PGM=IDCAMS  
//SYSPRINT  DD  SYSOUT=*   
//SYSIN   DD  *
  /*  THIS IS A COMMENT  */
  /*  SO IS THIS */
/* 
//STEP2  EXEC  PGM=IDCAMS  
//SYSPRINT  DD  SYSOUT=*   
//SYSIN   DD  *
  /*  THIS IS A COMMENT  - 
  SO IS THIS */
/* 

Output:

IDCAMS  SYSTEM SERVICES   
   
  /*  THIS IS A COMMENT  */
  /*  SO IS THIS */
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0  
IDCAMS  SYSTEM SERVICES   
   
  /*  THIS IS A COMMENT  - 
  SO IS THIS */
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0  

No complaints about a multi-line comment.

Rex



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Wawiorko
Sent: Wednesday, May 30, 2018 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Comments in IDCAMS statements

Isn't this more lack of the IDCAMS continuation character ' - ' or does my 
memory fail me?

Mike Wawiorko  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: 30 May 2018 15:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comments in IDCAMS statements


This mail originated from outside our organisation - 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu

From the book:

Commands can begin at, or to the right of, the left margin. For batch 
processing jobs, the default margins are 2 and 72.
Commands are separated from their parameters by one or more separators 
(blanks,commas, or comments). For some parameters, parentheses are used as 
separators.
Comments are strings of characters surrounded by /* and */. Comments can 
contain any characters except */.

I haven’t tested, but it looks like multi-line comments are not supported with 
only 1 opening and closing /* */?
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, May 30, 2018 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Comments in IDCAMS statements

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I thoguht I understood how to run AMS.  Either I don't, or something strange is 
going on:

 /* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
   BELOW TO ALLOCATE THERE.
11090078
IDC3219I VERB NAME 'BELOW'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


   ALTERNATIVE IS TO DELETE THE VOL(EAVNS0) LINES .
11100078
IDC3219I VERB NAME 'ALTERNATIVE'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


 */
0078
IDC3219I VERB NAME '*/'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12

Even more baffling, this worked:

/* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
/*BELOW TO ALLOCATE THERE.
11090079

11100079
/*OTHERWISE DELETE THE VOL(EAVNS0) LINES.
0079

11120079

Did they start using the TSO CLIST parser?


--
sas

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

This 

Re: Best Group for COBOL Question(s)

[Steve Thompson]

Thank you.

That does make sense to me. I would have done it in the "passes" 
for "parse/scan". But what you say makes sense to do in the 
"prep" for Code Gen.


Of course, compiler development has changed tremendously since I 
was working with it back in the '70s (NOT COBOL and NOT IBM 
architecture stuff).


Regards,
Steve Thompson

On 05/30/2018 11:12 AM, Allan Kielstra wrote:

This list is followed pretty closely by the team so you can ask questions about 
COBOL here.  You can also go to the COBOL Cafe (Discussion forum section) and 
ask questions there.

There is an RFE on this topic and it has been accepted.  There is no target date for that 
RFE.   The issue is this:  we implemented INITCHECK in the optimizer (not parse/scan.)  
That's because it has to do optimizer like things such as "Use/Def" tracking 
and it has to use aliases.  So a word of warning:  we plan to enable INITCHECK at OPT(0) 
but when when INITCHECK is running we still need to do some of these compute intensive 
operations so the OPT(0) compile will take longer.  (Not as long as OPT(1) or OPT(2) but 
longer than OPT(0)

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

[Ed Jaffe]

On 5/30/2018 2:28 AM, Barbara Nitz wrote:

Why is this thing even coming up when it relies on JES2? Why doesn't it wait 
for JES2?!?


BCPii relies on JES2? That's news to me...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Best Group for COBOL Question(s)

[Allan Kielstra]

This list is followed pretty closely by the team so you can ask questions about 
COBOL here.  You can also go to the COBOL Cafe (Discussion forum section) and 
ask questions there.

There is an RFE on this topic and it has been accepted.  There is no target 
date for that RFE.   The issue is this:  we implemented INITCHECK in the 
optimizer (not parse/scan.)  That's because it has to do optimizer like things 
such as "Use/Def" tracking and it has to use aliases.  So a word of warning:  
we plan to enable INITCHECK at OPT(0) but when when INITCHECK is running we 
still need to do some of these compute intensive operations so the OPT(0) 
compile will take longer.  (Not as long as OPT(1) or OPT(2) but longer than 
OPT(0)

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

Re: Comments in IDCAMS statements

[Mike Wawiorko]

Isn't this more lack of the IDCAMS continuation character ' - ' or does my 
memory fail me?

Mike Wawiorko  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: 30 May 2018 15:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comments in IDCAMS statements


This mail originated from outside our organisation - 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu

From the book:

Commands can begin at, or to the right of, the left margin. For batch 
processing jobs, the default margins are 2 and 72.
Commands are separated from their parameters by one or more separators 
(blanks,commas, or comments). For some parameters, parentheses are used as 
separators.
Comments are strings of characters surrounded by /* and */. Comments can 
contain any characters except */.

I haven’t tested, but it looks like multi-line comments are not supported with 
only 1 opening and closing /* */?
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, May 30, 2018 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Comments in IDCAMS statements

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I thoguht I understood how to run AMS.  Either I don't, or something strange is 
going on:

 /* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
   BELOW TO ALLOCATE THERE.
11090078
IDC3219I VERB NAME 'BELOW'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


   ALTERNATIVE IS TO DELETE THE VOL(EAVNS0) LINES .
11100078
IDC3219I VERB NAME 'ALTERNATIVE'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


 */
0078
IDC3219I VERB NAME '*/'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12

Even more baffling, this worked:

/* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
/*BELOW TO ALLOCATE THERE.
11090079

11100079
/*OTHERWISE DELETE THE VOL(EAVNS0) LINES.
0079

11120079

Did they start using the TSO CLIST parser?


--
sas

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.
Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.
Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.
Barclays Services Limited provides support and administrative services across 
Barclays group. Barclays Services Limited is an appointed representative of 
Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services 
Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the 
Prudential Regulation Authority and regulated by the Financial Conduct 
Authority and the Prudential Regulation 

Re: Best Group for COBOL Question(s)

[Andrew Arentsen]

There's already an RFE out for this:
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=114659

Andrew Arentsen
Senior Mainframe Systems Engineer




From:   "Steve Thompson" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/30/2018 09:43 AM
Subject:Best Group for COBOL Question(s)
Sent by:"IBM Mainframe Discussion List" 



Folks:

I've been searching and searching, and I know that at one time 
there was a COBOL List server, but I can't find it now.

My question is, what would be the best group to ask a compiler 
question (specific to COBOL) that Tom (forgot his last name), 
would probably see?

IBM's blogs, community, etc are not my idea of a good time -- 
already got out there and spent too much time battling through 
their interface.

And so you can enjoy this, my question is, why is it that OPT(0) 
overrides INITCHECK, but if I ask for Optimization (e.g, OPT(1)) 
it works?

Frankly, I do not want anyone using INITCHECK (IC) outside of 
OPT(0) which means NOOPT (except that you can't say that with 
COBOL 6.2).

Yes, INITCHECK is ONLY done by the Compiler during Parse/SCAN 
operations and not during code gen (as I read the manual).

But it takes more CPU for this to work, so why do that AND the 
CPU burn of Optimization for a compile where one is attempting to 
determine if fields are being referenced before they have had 
something put in them?

So anyone else see anything a bit silly about this?


Regards,
Steve Thompson

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


**
This e-mail is confidential. If you are not the intended recipient, you must 
not disclose or use the information contained in it. If you have received this 
e-mail in error, please tell us immediately by return e-mail and delete the 
document.

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

Best Group for COBOL Question(s)

[Steve Thompson]

Folks:

I've been searching and searching, and I know that at one time 
there was a COBOL List server, but I can't find it now.


My question is, what would be the best group to ask a compiler 
question (specific to COBOL) that Tom (forgot his last name), 
would probably see?


IBM's blogs, community, etc are not my idea of a good time -- 
already got out there and spent too much time battling through 
their interface.


And so you can enjoy this, my question is, why is it that OPT(0) 
overrides INITCHECK, but if I ask for Optimization (e.g, OPT(1)) 
it works?


Frankly, I do not want anyone using INITCHECK (IC) outside of 
OPT(0) which means NOOPT (except that you can't say that with 
COBOL 6.2).


Yes, INITCHECK is ONLY done by the Compiler during Parse/SCAN 
operations and not during code gen (as I read the manual).


But it takes more CPU for this to work, so why do that AND the 
CPU burn of Optimization for a compile where one is attempting to 
determine if fields are being referenced before they have had 
something put in them?


So anyone else see anything a bit silly about this?


Regards,
Steve Thompson

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

Re: Comments in IDCAMS statements

[Tony Thigpen]

You are thinking REXX comments, which allow multi-line comments. IDCAMS 
only supports single line comments.


Tony Thigpen

Steve Smith wrote on 05/30/2018 10:24 AM:

I thoguht I understood how to run AMS.  Either I don't, or something
strange is going on:

  /* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
BELOW TO ALLOCATE THERE.
11090078
IDC3219I VERB NAME 'BELOW'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


ALTERNATIVE IS TO DELETE THE VOL(EAVNS0) LINES .
11100078
IDC3219I VERB NAME 'ALTERNATIVE'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


  */
0078
IDC3219I VERB NAME '*/'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12

Even more baffling, this worked:

/* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
/*BELOW TO ALLOCATE THERE.
11090079

11100079
/*OTHERWISE DELETE THE VOL(EAVNS0) LINES.
0079

11120079

Did they start using the TSO CLIST parser?




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

Re: Comments in IDCAMS statements

[Jousma, David]

From the book:

Commands can begin at, or to the right of, the left margin. For batch 
processing jobs, the default margins are 2 and 72.
Commands are separated from their parameters by one or more separators 
(blanks,commas, or comments). For some parameters, parentheses are used as 
separators.
Comments are strings of characters surrounded by /* and */. Comments can 
contain any characters except */.

I haven’t tested, but it looks like multi-line comments are not supported with 
only 1 opening and closing /* */?
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, May 30, 2018 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Comments in IDCAMS statements

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I thoguht I understood how to run AMS.  Either I don't, or something strange is 
going on:

 /* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
   BELOW TO ALLOCATE THERE.
11090078
IDC3219I VERB NAME 'BELOW'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


   ALTERNATIVE IS TO DELETE THE VOL(EAVNS0) LINES .
11100078
IDC3219I VERB NAME 'ALTERNATIVE'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


 */
0078
IDC3219I VERB NAME '*/'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12

Even more baffling, this worked:

/* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
/*BELOW TO ALLOCATE THERE.
11090079

11100079
/*OTHERWISE DELETE THE VOL(EAVNS0) LINES.
0079

11120079

Did they start using the TSO CLIST parser?


--
sas

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Comments in IDCAMS statements

[Steve Smith]

I thoguht I understood how to run AMS.  Either I don't, or something
strange is going on:

 /* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
   BELOW TO ALLOCATE THERE.
11090078
IDC3219I VERB NAME 'BELOW'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


   ALTERNATIVE IS TO DELETE THE VOL(EAVNS0) LINES .
11100078
IDC3219I VERB NAME 'ALTERNATIVE'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12


 */
0078
IDC3219I VERB NAME '*/'
UNKNOWN
IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS
12

Even more baffling, this worked:

/* N.B.:  EAVNS0 IS NON-VSAM, SO DELETE DATACLAS AND ACCOUNT
11080078
/*BELOW TO ALLOCATE THERE.
11090079

11100079
/*OTHERWISE DELETE THE VOL(EAVNS0) LINES.
0079

11120079

Did they start using the TSO CLIST parser?


-- 
sas

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

Re: empty KSDS behavior - why?

[R.S.]

W dniu 2018-05-29 o 20:25, Paul Gilmartin pisze:

On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote:


Why would IBM have to add a key? What is necessary is to create an empty KSDS 
that can be read; add and delete is one way to do it, and doesn't leave a key 
behind. I'd prefer that they just initialized it to have the same contents as 
adding and deleting.


Is the result identical whether the added/deleted record has key high-values, 
low-values, or something
in between?

And I'll repeat my question, what is the result of REPROing a properly 
initialized
but currently empty KSDS?

Let's assume REPRO IDS(PS.FILE.SORTED) ODS(VSAM.EMPTY.KSDS)
IMHO the result is the same as with VSAM not empty, but with no 
conflicting keys.


Of course initialized VSAM file precludes use of SPEED during load.

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: empty KSDS behavior - why?

[Charles Mills]

Humor me -- I'm not a VSAM guy. Are there really people who are counting on 
their COBOL programs blowing up if they fail to do the right juju on their new 
VSAM file?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Wednesday, May 30, 2018 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

Consistent behavior and backwards compatability does make it right!

You can question the original though process, but not maintaining consistency.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 29, 2018 7:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the law of 
the land for years.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
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: IEFA107I when pointing to dataset alias

[Michael Babcock]

I searched IBMLINK and found OA54626.  ISPF option 1 works but ISPF 3.4
does not.  So my alias definition works but there is a bug which prevents
3.4 from working.  So I’m good to go!

On Tue, May 29, 2018 at 7:08 PM Michael Babcock 
wrote:

> Also, if the symbol ends with an underscore, the value can be longer than
> the symbol.
>
> On Tue, May 29, 2018 at 7:05 PM Michael Babcock 
> wrote:
>
>> I’m at z/OS 2.2
>>
>> On Tue, May 29, 2018 at 4:46 PM Paul Gilmartin <
>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>> On Tue, 29 May 2018 23:30:22 +0200, Lucas Rosalen wrote:
>>>
>>> >The ALIAS must be in the same catalog as the actual dataset.
>>> >
>>> Not for SYMBOLICRELATE, but only in very recent z/OS.
>>>
>>> -- gil
>>>
>>> --
>>> 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: HWIBCPII

[Allan Staller]

Well thought out! And agreed.
Maybe John Eels can take it up with the appropriate development groups.

Atta Girl!



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: Wednesday, May 30, 2018 4:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HWIBCPII



We had the (admittedly not so) bright idea to accomate the request from 
application development to activate the HEAPCHK LE Option generally. We did 
this in conjunction with upgrading from 2.1 to 2.3.
As a result, the crappy design of HWIBCPII address space revealed itself. (It 
had been running without problems under 2.1 for quite a while.) During IPL (and 
*wy before* JES2 was active) we got these messages:

IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,CEEDUMP
IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,SYSOUT
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:   
BCPII.D146.T1123091.HWIBCPII

Why is this thing even coming up when it relies on JES2? Why doesn't it wait 
for JES2?!?

CEA0603I The z/OS Diagnostic Snapshot option failed.
z/OS component CEA is unavailable for processing this request.
Diagnostic data will be missing for the following incident with:
DUMP TITLE: JOBNAME HWIBCPII STEPNAME HWIBCPII  USER  4087
DATE AND TIME: 05/26/2018 11:23:09
DUMP DATA SET NAME: BCPII.D146.T1123091.HWIBCPII
REASON: The CEA address space is unavailable.

We do NOT run z/OSMF and we do NOT have CEA configured. Which component 
automatically calls CEA and then screams that it is not available?
*Then* insult gets added to injury:

ICH408I USER(BCPII   ) GROUP($STCGRP ) NAME(BCPII   )
  SYS1.MCAT.xx CL(DATASET ) VOL(AWECAT)
  INSUFFICIENT ACCESS AUTHORITY
  FROM SYS1.MCAT.xx (G)
  ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   )
IKJ56893I DATA SET BCPII.D146.T1123091.HWIBCPII NOT ALLOCATED+

Of course not! We do not allow access to the master cat for every Tom, Dick and 
Harry to pollute the master cat with non-defined HLQs. The HLQ BCPII (which is 
equal to the protected STC userid HWIBCPII runs under) does not have an alias 
and is not allowed to allocate data sets. *That's* why the LE Option DYNDUMP 
clearly specifies a general HLQ named TDUMP for each and every transaction dump 
to get allocated under. IBM in their infinite wisdom have choosen to override 
the installation-set DYNDUMP LE Default (that only makes sense for actual TSO 
users, but NOT for LE-enabled STCs, namely to use the userid as HLQ) to enforce 
the IBM default for HLQs. For security reasons, no protected STC is allowed to 
allocate data sets under it's own userid, hence HLQ TDUMP to actually *find* 
all of those transaction  dumps in one place.

IEA820I TRANSACTION DUMP REQUESTED BUT NOT TAKEN
AUTOMATIC ALLOCATION OF DUMP DATA SET FAILED
CEE3796I AN ATTEMPT TO DYNAMICALLY TAKE A DUMP WAS NOT SUCCESSFUL. 339
THE ERROR RETURN CODE WAS 0008 AND THE REASON CODE WAS 0026.
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0001 344
 WHILE RUNNING PROGRAM CEEBPCAL WHICH STARTS AT F600
 AT THE TIME OF INTERRUPT
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0002 355
 WHILE RUNNING PROGRAM CEEPIPI
 AT THE TIME OF INTERRUPT
HWI018I THE BCPII COMMUNICATION RECOVERY HAS DETECTED AN UNEXPECTED
ERROR. SYSOUT MAY CONTAIN DIAGNOSTICS FOR THIS PROBLEM.
HWI008I BCPII FAILED TO CONNECT TO THE LOCAL CENTRAL PROCESSOR 367 COMPLEX 
(CPC). RC = 0FFF, RSN = . BCPII INITIALIZATION
IS HALTED.

When we migrated to 2.3, we didn't have a clue what might be wrong with 
HWIBCPII, so after the system was up and running we just did a "start 
HWISTART". To our utter confusion, *now* it came up without a hitch.

We later found out why setting HEAPCK globally wasn't a good idea and have now 
turned it off again. When we reproduced this on our test system, we did an S 
HWISTART,SUB=MSTR on the assumption that the thing runs sub=mstr when it gets 
started. We got a dump (abend042 with a 'severe internal error' reason code) 
for our pains, so quite obviously it does not work under sub=mstr. Starting it 
under JES, *now* it waits for JES to initialize, probably because something 
global in the system recognizes that JES2 isn't there yet.

There are a number of things wrong here:
1. If HWIBCPII needs JES2 to function (and obviously it does), it just cannot 
do all the shenanigans detailed above and *has to* wait for JES2 to come up. If 
it cannot do that, then it MUST work under the master subsystem. The 
wishy-washy way it behaves now is not acceptable.
2. Since this is an LE-enabled application, it MUST be able to tolerate all and 
any LE options set in an installation. Given that it overrides a number of the 
installation-set LE Options, why doesn't it also override the HEAPCHK option to 
always be off?
3. No STC running with a protected user should ever be able to allocate data 
sets under its own userid (or so our auditors tell us). That 

Re: empty KSDS behavior - why?

[Allan Staller]

Consistent behavior and backwards compatability does make it right!

You can question the original though process, but not maintaining consistency.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 29, 2018 7:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: empty KSDS behavior - why?

On Tue, 29 May 2018 20:42:53 -0400, Doug Shupe wrote:

>LOADED vs UNLOADED.
>
>Read the VSAM DEMISTIFIED Redbooks.
>
>When you define a VSAM file it is in an UNLOADED state, REPRO will open for 
>output and work just fine.
>
>If you write a record and delete the record the VSAM file is now in a LOADED 
>state. You should be able to open I/O or REPRO with the REPLACE option.
>
>I surely might have missed what your trying to do but this is not rocket 
>science and has been this way for years..
>
Antiquity doesn't make something right.  The Fugitive Slave Act was the law of 
the land for years.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

GSE Large Systems Meeting

[Leanne Wilson]

I am pleased to invite you to a GSE Large Systems Working Group meeting, which 
will be held at RSM Partners in Bromsgrove on the 21st June 2018, address 
details are below:

RSM Partners Limited
RSM House
Isidore Road
Bromsgrove Technology Park
Bromsgrove
B60 3FQ

If you wish to attend the event, please follow the registration link 
HERE

Agenda details still to be announced and will follow shortly.

A taster of topics include (all subject to change) :

  *   Pervasive encryption
  *   z/OS updates
  *   Java & LE monitoring

This is yet another FOC event organised by your GSE team.

During the day you will be able to informally network with other IBM System z 
users to compare notes and to discuss current industry “Best practices”.



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

HWIBCPII

[Barbara Nitz]

We had the (admittedly not so) bright idea to accomate the request from 
application development to activate the HEAPCHK LE Option generally. We did 
this in conjunction with upgrading from 2.1 to 2.3.
As a result, the crappy design of HWIBCPII address space revealed itself. (It 
had been running without problems under 2.1 for quite a while.)
During IPL (and *wy before* JES2 was active) we got these messages:

IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,CEEDUMP
IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,SYSOUT 
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:   
BCPII.D146.T1123091.HWIBCPII 

Why is this thing even coming up when it relies on JES2? Why doesn't it wait 
for JES2?!?

CEA0603I The z/OS Diagnostic Snapshot option failed. 
z/OS component CEA is unavailable for processing this request. 
Diagnostic data will be missing for the following incident with:   
DUMP TITLE: JOBNAME HWIBCPII STEPNAME HWIBCPII  USER  4087 
DATE AND TIME: 05/26/2018 11:23:09 
DUMP DATA SET NAME: BCPII.D146.T1123091.HWIBCPII   
REASON: The CEA address space is unavailable.  

We do NOT run z/OSMF and we do NOT have CEA configured. Which component 
automatically calls CEA and then screams that it is not available?
*Then* insult gets added to injury:

ICH408I USER(BCPII   ) GROUP($STCGRP ) NAME(BCPII   )
  SYS1.MCAT.xx CL(DATASET ) VOL(AWECAT)  
  INSUFFICIENT ACCESS AUTHORITY  
  FROM SYS1.MCAT.xx (G)  
  ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   )
IKJ56893I DATA SET BCPII.D146.T1123091.HWIBCPII NOT ALLOCATED+   

Of course not! We do not allow access to the master cat for every Tom, Dick and 
Harry to pollute the master cat with non-defined HLQs. The HLQ BCPII (which is 
equal to the protected STC userid HWIBCPII runs under) does not have an alias 
and is not allowed to allocate data sets. *That's* why the LE Option DYNDUMP 
clearly specifies a general HLQ named TDUMP for each and every transaction dump 
to get allocated under. IBM in their infinite wisdom have choosen to override 
the installation-set DYNDUMP LE Default (that only makes sense for actual TSO 
users, but NOT for LE-enabled STCs, namely to use the userid as HLQ) to enforce 
the IBM default for HLQs. For security reasons, no protected STC is allowed to 
allocate data sets under it's own userid, hence HLQ TDUMP to actually *find* 
all of those transaction  dumps in one place.

IEA820I TRANSACTION DUMP REQUESTED BUT NOT TAKEN 
AUTOMATIC ALLOCATION OF DUMP DATA SET FAILED   
CEE3796I AN ATTEMPT TO DYNAMICALLY TAKE A DUMP WAS NOT SUCCESSFUL. 339 
THE ERROR RETURN CODE WAS 0008 AND THE REASON CODE WAS 0026.   
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0001 344
 WHILE RUNNING PROGRAM CEEBPCAL WHICH STARTS AT F600
 AT THE TIME OF INTERRUPT   
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0002 355
 WHILE RUNNING PROGRAM CEEPIPI  
 AT THE TIME OF INTERRUPT   
HWI018I THE BCPII COMMUNICATION RECOVERY HAS DETECTED AN UNEXPECTED 
ERROR. SYSOUT MAY CONTAIN DIAGNOSTICS FOR THIS PROBLEM. 
HWI008I BCPII FAILED TO CONNECT TO THE LOCAL CENTRAL PROCESSOR 367  
COMPLEX (CPC). RC = 0FFF, RSN = . BCPII INITIALIZATION  
IS HALTED.  

When we migrated to 2.3, we didn't have a clue what might be wrong with 
HWIBCPII, so after the system was up and running we just did a "start 
HWISTART". To our utter confusion, *now* it came up without a hitch.

We later found out why setting HEAPCK globally wasn't a good idea and have now 
turned it off again. When we reproduced this on our test system, we did an S 
HWISTART,SUB=MSTR on the assumption that the thing runs sub=mstr when it gets 
started. We got a dump (abend042 with a 'severe internal error' reason code) 
for our pains, so quite obviously it does not work under sub=mstr. Starting it 
under JES, *now* it waits for JES to initialize, probably because something 
global in the system recognizes that JES2 isn't there yet.

There are a number of things wrong here:
1. If HWIBCPII needs JES2 to function (and obviously it does), it just cannot 
do all the shenanigans detailed above and *has to* wait for JES2 to come up. If 
it cannot do that, then it MUST work under the master subsystem. The 
wishy-washy way it behaves now is not acceptable.
2. Since this is an LE-enabled application, it MUST be able to tolerate all and 
any LE options set in an installation. Given that it overrides a number of the 
installation-set LE Options, why doesn't it also override the HEAPCHK option to 
always be off?
3. No STC running with