Hillgang - Update

[Neale Ferguson]

The PDF uploaded is from March 2015. We are working to get the correct
agenda uploaded. I will send a message when it is done.

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

It's D-day today

[Tony Harminc]

TOD-clock D, that is. At 2015-12-15 13:24:57.238527 the clock rolled
over from CFFF to D000.

Those of us who look at a lot of dumps or traces may feel a slight
sense of disorientation for a while. But it will pass, as it did back
in January 2007 when strange C0 timestamps started appearing.

Tony H.

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

Re: DFdss does not release space

[John Eells]

Paul Gilmartin wrote:


So the designers committed the unforgivable blunder of failing to differentiate
between "0" and "unknown".  This has been a problem for me elsewhere, in
various DB interfaces, where I want to select all rows in which a certain column
is unset, and get, in addition, those in which it is 0, or "", or some other
default value.



I rather suspect that the original designers of F1DSCBs are long gone, 
but I think it's perfectly forgivable that in the development time 
leading up to 1964 their crystal balls might at times have been a bit 
hazy.  After all, the term "computer science" was only three years old 
in 1964.  I actually find it pretty amazing how durable many of these 
design decisions were.  The designers were literally making this stuff 
up as they went along and had little or no prior experience to guide them.


But, whether we happen to be impressed by their work or not, this 
particular design choice is what it is, as are many others on which our 
system's foundations are built.  That does not mean we cannot possibly 
address requirements like this one, however.  Perhaps it would be 
constructive to suggest that DFSMSdss could optionally use DS1CREDT to 
determine whether a data set with DS1LSTAR set to zero should have its 
space released.  Or, that an "unknown" flag be added to the F9DSCB.  Or...


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Anyone using Rocket Software Performance Essential

[John Clifford]

I used it for 30 years until I got laid off.  Yes, it started as VIOplus
from Softworks and then it went to EMC then Rocket. It saved incredible
amounts of time as we were a huge VSAM shop. I tested a few real  VSAM pigs
and ran jobs turning off VIOplus (perf Essential now) and jobs went from 1
hour 10 minutes to 18 hours.  Actual time. There was no way I could
possibly sit down and figure all the jcl changes to tune the VSAM file
access to get this kind of benefit. I haven't touched it since 2012 but I
would assume it still helps alot with VSAM and Qsam.

John Clifford
z/OS consultant

On Tue, Dec 15, 2015 at 10:28 AM, Porowski, Ken 
wrote:

> I've used it for years.  IIRC it was originally called VIOPlus from
> Softworks.  No real issues with it although there are a few cases where a
> job will gag on it but it is easy to bypass.  It is basically dynamic
> buffering for VSAM and Sequential datasets.  Nothing you can't do through
> JCL yourself if you have the (lots of) time to put into it.  I think it's
> worth it and it does dramatically improve I/O performance.
>
>
>
>
> CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1
> 973 740 5459 (tel) | ken.porow...@cit.com
>
>
>
>
> This email message and any accompanying materials may contain proprietary,
> privileged and confidential information of CIT Group Inc. or its
> subsidiaries or affiliates (collectively, “CIT”), and are intended solely
> for the recipient(s) named above.  If you are not the intended recipient of
> this communication, any use, disclosure, printing, copying or distribution,
> or reliance on the contents, of this communication is strictly prohibited.
> CIT disclaims any liability for the review, retransmission, dissemination
> or other use of, or the taking of any action in reliance upon, this
> communication by persons other than the intended recipient(s).  If you have
> received this communication in error, please reply to the sender advising
> of the error in transmission, and immediately delete and destroy the
> communication and any accompanying materials.  To the extent permitted by
> applicable law, CIT and others may inspect, review, monitor, analyze, copy,
> record and retain any communications sent from or received at this email
> address.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Mattson
> Sent: Monday, December 14, 2015 8:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Anyone using Rocket Software Performance Essential
>
> Rocket software has a "Performance Essential" product which they claim
> greatly improved VSAM and other I/O processing.  Does anyone have
> experience with it?  Basically does it significantly improve I/O and is it
> trouble free?
>
> --
> 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
>

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

Re: Hillgang - Update

[Neale Ferguson]

13 Jan 2016 Agenda - http://www.vm.ibm.com/events/HILL0116.PDF

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

Re: Anyone using Rocket Software Performance Essential

[Lester, Bob]

...anyone know how these products measure up against Innovation's IAM 
product?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of James Ward
Sent: Tuesday, December 15, 2015 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone using Rocket Software Performance Essential [ EXTERNAL ]

I have no experience with that Rocket product.  We currently use BMC's Batch 
Optimizer, but will be looking into Dino Software's dynamic buffering tool 
(Veloci-Raptor) as a replacement.  I believe it was built by the original 
authors of VIO/Performance Essential and surely worth investigating as an 
option for improving VSAM/xSAM batch performance. 

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: JES2 - originating jcl

[Sumi, Joseph J. (CMS/CTR) (CTR)]

Thanks, we will investigate TSO submitted jobs and also check with the Thruput 
Manager folks.


Rgrds, Joseph Sumi





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, December 15, 2015 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - originating jcl

We do so in TSO submitted jobs and so do some schedulers and applications 
submitting jobs. 
But the original question was: does JES2 know and then the answer is simply: NO.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 15 December, 2015 15:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - originating jcl

Oh, in the below, I forgot to mention that I once had an IKJEFF10 (TSO
SUBMIT) exit which modified the submitted JCL. But the modifications were 
generated from a data area created by the ISPF SUBMIT command (another exit). 
So, if you wanted to put in a JCL statement such as:

//*SUBMITTED FROM  BY  ON -mm-ddThh:mm:ssZ

(replace trailing Z with appropriate local time indicator, such as: -06:00 for 
U.S. Central Standard.

This is not for the faint of heart. And I don't have the source any more.
That was 20+ years ago at a shop which no longer exists.

On Tue, Dec 15, 2015 at 8:52 AM, John McKown 
wrote:

> On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) < 
> joseph.s...@cms.hhs.gov> wrote:
>
>> Hello, is there a JES2 exit that will allow us to place the dataset 
>> and member name of the job that was submitted ? The originating 
>> dataset/member would be added as a comment to the JESLOG, MESSAGES, 
>> or JCL. I would assume
>> JES2 would know where the JCL came from but not sure.
>>
>
> ​No, it doesn't really. In most cases, the JCL is coming in from a 
> "reader" of some sort (local, NJE, RJE, ​or _most likely today_ the 
> internal reader: INTRDR).
>
> In all cases other than the INTRDR case, there is no DSN involved at all.
> And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for a 
> card reader attached to "remote 1". If anybody use RJE any more.
>
> In the INTRDR case, the JCL is simply written out like it would be to 
> a normal data set, most likely using QSAM or maybe BSAM. JES2 has no 
> idea where the program doing the writing is getting it from. There 
> might not even be a "data set", such as in the case of a CLIST doing a 
> SUBMIT * command (JCL is in-line). Also, keep in mind that if someone 
> is in ISPF EDIT and does a SUBMIT command, that command actually 
> writes the contents of the edit buffer to an ISPF "temporary" (.CNTL) 
> data sets, so even if
> JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER 
> which was actually submitted by the ISPF SUBMIT edit command.
>
>
>
>>
>> Rgrds, Joseph Sumi
>>
>>
> --
>
> Schrodinger's backup: The condition of any backup is unknown until a 
> restore is attempted.
>
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 

Re: It's D-day today

[Charles Mills]

Watch for Unicode Services problems ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Tuesday, December 15, 2015 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: It's D-day today

TOD-clock D, that is. At 2015-12-15 13:24:57.238527 the clock rolled over from 
CFFF to D000.

Those of us who look at a lot of dumps or traces may feel a slight sense of 
disorientation for a while. But it will pass, as it did back in January 2007 
when strange C0 timestamps started appearing.

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

Re: It's D-day today

[John McKown]

That's why I just reIPL'd my sandbox. Luckily for me, no problems without
the PTF. We don't really use Unicode services here. And we only have maybe
6 months left before decommissioning, so we don't want to be bothered with
maintenance.

On Tue, Dec 15, 2015 at 11:05 AM, Charles Mills  wrote:

> Watch for Unicode Services problems ...
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Harminc
> Sent: Tuesday, December 15, 2015 8:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: It's D-day today
>
> TOD-clock D, that is. At 2015-12-15 13:24:57.238527 the clock rolled over
> from CFFF to D000.
>
> Those of us who look at a lot of dumps or traces may feel a slight sense
> of disorientation for a while. But it will pass, as it did back in January
> 2007 when strange C0 timestamps started appearing.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Hillgang - 13 Jan 2016

[Neale Ferguson]

The next Hillgang (the DC/MD/VA z/VM & Linux User Group) meeting will be
held on Wednesday 13 January 2016 at the CA Offices in Herndon, VA.

- There's a z890 in my basement – Connor Krukovsky
- What's up Docker, Neale Ferguson, SNA
- What is OpenStack and why would I want it? -Emily Hugenbruch, IBM
- Introduction to the Open Mainframe Project, Len Santalucia, Vicom
Infinity
- I want OpenStack on the mainframe, can I have it? - Emily Hugenbruch, IBM


The full agenda and registration instructions may be found at:

http://www.vm.ibm.com/events/HILL0315.PDF

Neale

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

Re: Anyone using Rocket Software Performance Essential

[James Ward]

I have no experience with that Rocket product.  We currently use BMC's Batch 
Optimizer, but will be looking into Dino Software's dynamic buffering tool 
(Veloci-Raptor) as a replacement.  I believe it was built by the original 
authors of VIO/Performance Essential and surely worth investigating as an 
option for improving VSAM/xSAM batch performance.

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

Re: JES2 - originating jcl

[Shmuel Metz (Seymour J.)]

In <2A7B3ACA0EB0614E9CF02EF49021C9508796E254@pl-emsmb11>, on
12/15/2015
   at 02:41 PM, "Sumi, Joseph J. (CMS/CTR) (CTR)"
 said:

>Hello, is there a JES2 exit that will allow us to place the dataset
>and member name of the job that was submitted ?

Of course not; it's not JES2 reading the member.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: JES2 - originating jcl

[Lizette Koehler]

For the TSO exit IKJEFF10 or IKJEFF53 there might be something in SYS1.SAMPLIB.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR)
> Sent: Tuesday, December 15, 2015 9:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - originating jcl
> 
> Thanks, we will investigate TSO submitted jobs and also check with the Thruput
> Manager folks.
> 
> 
> Rgrds, Joseph Sumi
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, CP (ITOPT1) - KLM
> Sent: Tuesday, December 15, 2015 10:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - originating jcl
> 
> We do so in TSO submitted jobs and so do some schedulers and applications
> submitting jobs.
> But the original question was: does JES2 know and then the answer is simply: 
> NO.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: 15 December, 2015 15:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - originating jcl
> 
> Oh, in the below, I forgot to mention that I once had an IKJEFF10 (TSO
> SUBMIT) exit which modified the submitted JCL. But the modifications were
> generated from a data area created by the ISPF SUBMIT command (another exit).
> So, if you wanted to put in a JCL statement such as:
> 
> //*SUBMITTED FROM  BY  ON -mm-ddThh:mm:ssZ
> 
> (replace trailing Z with appropriate local time indicator, such as: -06:00 
> for U.S.
> Central Standard.
> 
> This is not for the faint of heart. And I don't have the source any more.
> That was 20+ years ago at a shop which no longer exists.
> 
> On Tue, Dec 15, 2015 at 8:52 AM, John McKown 
> wrote:
> 
> > On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) <
> > joseph.s...@cms.hhs.gov> wrote:
> >
> >> Hello, is there a JES2 exit that will allow us to place the dataset
> >> and member name of the job that was submitted ? The originating
> >> dataset/member would be added as a comment to the JESLOG, MESSAGES,
> >> or JCL. I would assume
> >> JES2 would know where the JCL came from but not sure.
> >>
> >
> > ​No, it doesn't really. In most cases, the JCL is coming in from a
> > "reader" of some sort (local, NJE, RJE, ​or _most likely today_ the
> > internal reader: INTRDR).
> >
> > In all cases other than the INTRDR case, there is no DSN involved at all.
> > And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for a
> > card reader attached to "remote 1". If anybody use RJE any more.
> >
> > In the INTRDR case, the JCL is simply written out like it would be to
> > a normal data set, most likely using QSAM or maybe BSAM. JES2 has no
> > idea where the program doing the writing is getting it from. There
> > might not even be a "data set", such as in the case of a CLIST doing a
> > SUBMIT * command (JCL is in-line). Also, keep in mind that if someone
> > is in ISPF EDIT and does a SUBMIT command, that command actually
> > writes the contents of the edit buffer to an ISPF "temporary" (.CNTL)
> > data sets, so even if
> > JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER
> > which was actually submitted by the ISPF SUBMIT edit command.
> >
> >
> >
> >>
> >> Rgrds, Joseph Sumi
> >>
> >>
> > --
> >
> > Schrodinger's backup: The condition of any backup is unknown until a
> > restore is attempted.
> >
> > Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
> >
> > He's about as useful as a wax frying pan.
> >
> > 10 to the 12th power microphones = 1 Megaphone
> >
> > Maranatha! <><
> > John McKown
> >

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

Re: JES2 - originating jcl

[Paul Gilmartin]

On Tue, 15 Dec 2015 11:57:25 -0800, Skip Robinson wrote:

>Just want to emphasize a point already made. Unless the user actually issues 
>the command "SUB a.b.c(jcl-mem)" the submit exit will not know the original 
>data set. In fact, you can be ISPF-editing a job member, type SUB on the 
>command line, and exit without saving. In other words, there may never be a 
>physical file that contains the JCL as submitted. 
> 
And many editors, ISPF and XEDIT being conspicuous exceptions, allow a user to
begin an edit session without specifying a file name and defer that choice until
SAVE.  vi under z/OS UNIX is one example.  In such cases, the JCL exists only in
main storage, never as a persistent file.

I also submit many jobs via FTP; there's a file, but it's pretty far away.

>It's possible to substitute your own code for the ISPF submit command. Your 
>code could be a Rexx ...
>
I have such; I use it primarily to escape the dreadful Fixed-80 burden.
TSO SUBMIT ought to do likewise -- allocate INTRDR with attributes of
the data set submitted.

>that captures the currently edited data set name and inserts it as a comment. 
>Quite a bit of trouble to handle a subset of all job submittals. 
> 
But it doesn't do that.  However I keep a significant amount of JCL as 
here-documents
in shell scripts.  Self-tailoring -- allows incorporating current date and time 
in data set
names.

Lizette had a good idea; I'll go further.  Couple a code control system with a 
scheduler.
Most shops discourage submitting production jobs from uncontrolled data sets.

-- gil

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

Re: JES2 - originating jcl

[Skip Robinson]

Just want to emphasize a point already made. Unless the user actually issues 
the command "SUB a.b.c(jcl-mem)" the submit exit will not know the original 
data set. In fact, you can be ISPF-editing a job member, type SUB on the 
command line, and exit without saving. In other words, there may never be a 
physical file that contains the JCL as submitted. 

It's possible to substitute your own code for the ISPF submit command. Your 
code could be a Rexx that captures the currently edited data set name and 
inserts it as a comment. Quite a bit of trouble to handle a subset of all job 
submittals. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, December 15, 2015 09:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: JES2 - originating jcl

For the TSO exit IKJEFF10 or IKJEFF53 there might be something in SYS1.SAMPLIB.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR)
> Sent: Tuesday, December 15, 2015 9:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - originating jcl
> 
> Thanks, we will investigate TSO submitted jobs and also check with the 
> Thruput Manager folks.
> 
> 
> Rgrds, Joseph Sumi
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Vernooij, CP (ITOPT1) - KLM
> Sent: Tuesday, December 15, 2015 10:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - originating jcl
> 
> We do so in TSO submitted jobs and so do some schedulers and 
> applications submitting jobs.
> But the original question was: does JES2 know and then the answer is simply: 
> NO.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John McKown
> Sent: 15 December, 2015 15:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 - originating jcl
> 
> Oh, in the below, I forgot to mention that I once had an IKJEFF10 (TSO
> SUBMIT) exit which modified the submitted JCL. But the modifications 
> were generated from a data area created by the ISPF SUBMIT command (another 
> exit).
> So, if you wanted to put in a JCL statement such as:
> 
> //*SUBMITTED FROM  BY  ON -mm-ddThh:mm:ssZ
> 
> (replace trailing Z with appropriate local time indicator, such as: -06:00 
> for U.S.
> Central Standard.
> 
> This is not for the faint of heart. And I don't have the source any more.
> That was 20+ years ago at a shop which no longer exists.
> 
> On Tue, Dec 15, 2015 at 8:52 AM, John McKown 
> 
> wrote:
> 
> > On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) < 
> > joseph.s...@cms.hhs.gov> wrote:
> >
> >> Hello, is there a JES2 exit that will allow us to place the dataset 
> >> and member name of the job that was submitted ? The originating 
> >> dataset/member would be added as a comment to the JESLOG, MESSAGES, 
> >> or JCL. I would assume
> >> JES2 would know where the JCL came from but not sure.
> >>
> >
> > ​No, it doesn't really. In most cases, the JCL is coming in from a 
> > "reader" of some sort (local, NJE, RJE, ​or _most likely today_ the 
> > internal reader: INTRDR).
> >
> > In all cases other than the INTRDR case, there is no DSN involved at all.
> > And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for 
> > a card reader attached to "remote 1". If anybody use RJE any more.
> >
> > In the INTRDR case, the JCL is simply written out like it would be 
> > to a normal data set, most likely using QSAM or maybe BSAM. JES2 has 
> > no idea where the program doing the writing is getting it from. 
> > There might not even be a "data set", such as in the case of a CLIST 
> > doing a SUBMIT * command (JCL is in-line). Also, keep in mind that 
> > if someone is in ISPF EDIT and does a SUBMIT command, that command 
> > actually writes the contents of the edit buffer to an ISPF 
> > "temporary" (.CNTL) data sets, so even if
> > JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER 
> > which was actually submitted by the ISPF SUBMIT edit command.
> >
> >
> >
> >>
> >> Rgrds, Joseph Sumi
> > John McKown

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

Re: Advanced Assembler Language and MVS Interfaces

[Shane Ginnane]

On Tue, 15 Dec 2015 00:14:37 -0600, Brian Westerman wrote:

>I have both the original and the newer version.  One at work, the other at 
>home and I still refer to them both several times a year.

Thanks Brian, that is good to hear. Mine is the second edition - after I've had 
a quick read for old times sake, I'll send it off to a better home. Lucky it 
didn't get tossed out with all my other old stuff as I've had to purge my home 
office after some rain got into one of my bookcases.

Shane ...

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

DFdss does not release space

[Vernooij, CP (ITOPT1) - KLM]

Hello group,

I use DFdss to try to release space from a group of datasets. However, all that 
DFdss says is the normal start- and endmessages plus:
ADR470W (001)-RLSE0(02), NO DATA SETS SELECTED FOR PROCESSING

I have no idea why, all parameters like minsecqty and mintracksunused should 
allow release.
The only reason I can think of is that the datasets have allocated 5000 tracks, 
but use 0. But I found no explanation nor selection parameter for this.
How can I get DFdss to release this space?

Any ideas?

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Critique my Binder RCF?

[Paul Gilmartin]

I just submitted the RCF below.  But if I've misunderstood something
that should be "common knowledge", let me know and I'll send a retraction.
--
Hello, MHVRCFs,

In:
z/OS MVS Program Management: User's Guide and Reference
SA23-1393-00 
ORDER statement

   ...
   The syntax of the ORDER statement is:

   ORDER  section name[(P)]

... with a single section name as the argument.  But the examples in the
next section show a comma separated list of section names.  I believe
the syntax should show:

   ORDER  section name[(P)][,...]

... indicating that additional section names, separated by commas, may follow.

otherwise, I'm confused by:

   The ORDER statement indicates that the section is to be loaded on a page 
boundary. 

This seems to indicate that the mere occurrence of a name in an ORDER
statement causes the section to be page-aligned.  But:

   (P) Indicates the starting address of the control section or named common
   area is on a page boundary ...

seems to indicate the (P) modifier is needed to enforce page-alignment.  Perhaps
I don't understand the nuances of "section" versus "control section".  The 
diagram
in the next section seems to show that only (P) causes page alignment.

Thanks,
gil

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

Re: 3174 microcode diskettes ordering?

[Charles Mills]

You could call these folks: http://floppydisk.com/5point25.htm . (Not shown on 
Web page but hey! They are floppydisk.com!)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Tuesday, December 15, 2015 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3174 microcode diskettes ordering?

Those are all 3.5" diskettes.  I'm pretty sure the 2.4 MB diskettes were 5.25" 
diskettes.  I can quickly find some 1.2 MB preformatted 5.25"
diskettes on line but the 2.4MB variety, not so much
JC Ewing

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

3174 microcode diskettes ordering?

[Mike Ross]

Hi

Quickie: there is or was a dedicated IBM number to call to order 3174
microcode diskettes; they were a no-charge item IIRC. Does anyone have
the current number handy?

Or does anyone have a number where I can order *blank preformatted*
2.4mb 3174 diskettes so I can make backups? Needless to say standard
1.2mb diskettes don't work and a 3174 can't format diskettes; they
have to be factory-formated to 2.4mb...

Failing that does any kind person have a spare set floating around? I
have a friend who urgently needs a set of config 'C' version 6.4
diskettes!

Thanks

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

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

Re: 3174 microcode diskettes ordering?

[Charles Mills]

http://www.ebay.com/itm/like/321678927620?ul_noapp=true=ps=82 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Ross
Sent: Tuesday, December 15, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 3174 microcode diskettes ordering?

Hi

Quickie: there is or was a dedicated IBM number to call to order 3174 microcode 
diskettes; they were a no-charge item IIRC. Does anyone have the current number 
handy?

Or does anyone have a number where I can order *blank preformatted* 2.4mb 3174 
diskettes so I can make backups? Needless to say standard 1.2mb diskettes don't 
work and a 3174 can't format diskettes; they have to be factory-formated to 
2.4mb...

Failing that does any kind person have a spare set floating around? I have a 
friend who urgently needs a set of config 'C' version 6.4 diskettes!

Thanks

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

--
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: 3174 microcode diskettes ordering?

[Ed Finnell]

http://www.argecy.com/index.php?pfile=3174
 
http://www.ibm-fru-part.com/IBM-15.htm
 
Found these with relative ease.
 
I thought Config support was an MES available thru CE?
 
 
 
 
In a message dated 12/15/2015 5:44:54 P.M. Central Standard Time,  
jcew...@acm.org writes:

5.25"  diskettes.  I can quickly find some 1.2 MB preformatted  5.25"
diskettes on line but the 2.4MB variety, not so much
JC Ewing


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

Re: 3174 microcode diskettes ordering?

[Joel C. Ewing]

Those are all 3.5" diskettes.  I'm pretty sure the 2.4 MB diskettes were
5.25" diskettes.  I can quickly find some 1.2 MB preformatted 5.25"
diskettes on line but the 2.4MB variety, not so much
JC Ewing

On 12/15/2015 05:03 PM, Charles Mills wrote:
> http://www.ebay.com/itm/like/321678927620?ul_noapp=true=ps=82 
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mike Ross
> Sent: Tuesday, December 15, 2015 2:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 3174 microcode diskettes ordering?
>
> Hi
>
> Quickie: there is or was a dedicated IBM number to call to order 3174 
> microcode diskettes; they were a no-charge item IIRC. Does anyone have the 
> current number handy?
>
> Or does anyone have a number where I can order *blank preformatted* 2.4mb 
> 3174 diskettes so I can make backups? Needless to say standard 1.2mb 
> diskettes don't work and a 3174 can't format diskettes; they have to be 
> factory-formated to 2.4mb...
>
> Failing that does any kind person have a spare set floating around? I have a 
> friend who urgently needs a set of config 'C' version 6.4 diskettes!
>
> Thanks
>
> Mike
>
> http://www.corestore.org
> 'No greater love hath a man than he lay down his life for his brother.
> Not for millions, not for glory, not for fame.
> For one person, in the dark, where no one will ever know or see.'
>
> --
> 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
>   


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

AW: DFdss does not release space

[Peter Hunkeler]

>The only reason I can think of is that the datasets have allocated 5000 
>tracks, but use 0. But I found no explanation nor selection parameter for this.


>From the DSS Guide:
Chapter 9. Managing space with DFSMSdss
Releasing unused space in data sets
...
Exclude data sets whose last block pointer in the data set VTOC entry is not 
maintained in the VTOC by using the EXCLUDE keyword. This can occur if you use 
an access method other than BSAM, QSAM, BPAM, or VSAM. DFSMSdss does not 
release space for data sets whose last block pointer in the data set entry is 0.


There does not seem to be an option to override this restriction.




--
Peter Hunkeler






--
Peter Hunkeler

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

Windows: Basic, uncorrectable, flaw in Windows security.

[John McKown]

According to Vulture Central

http://www.theregister.co.uk/2015/12/15/devastating_flaw_in_windows_authentication/



The flaw cannot be fixed and the only solution is to introduce and use
Microsoft's Credential Guard program to prevent passwords from being stored
in memory, according to his extensive blog post.

The flaw results from how the third-party authentication system creates
secret keys: by using the password associated with a disabled username
(krbtgt). That password is rarely changed, making it possible to bypass the
authentication system altogether and allow an attacker to grant themselves
admin privileges, as well as create secret passwords for existing users and
new users that don't exist.

Although some of the entry points are time-limited – the system will seek
to validate accounts after 20 minutes – because it is possible to create
fake users without limit, it is possible to access a system incessantly.


...


--

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: DFdss does not release space

[Vernooij, CP (ITOPT1) - KLM]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: 15 December, 2015 13:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFdss does not release space

W dniu 2015-12-15 o 11:18, Vernooij, CP (ITOPT1) - KLM pisze:
> Hello group,
>
> I use DFdss to try to release space from a group of datasets. However, all 
> that DFdss says is the normal start- and endmessages plus:
> ADR470W (001)-RLSE0(02), NO DATA SETS SELECTED FOR PROCESSING
>
> I have no idea why, all parameters like minsecqty and mintracksunused should 
> allow release.
> The only reason I can think of is that the datasets have allocated 5000 
> tracks, but use 0. But I found no explanation nor selection parameter for 
> this.
> How can I get DFdss to release this space?
>
> Any ideas?
What kind of datasets are covered?
Can you provide whole SYSIN statement?


-- 

They are PS datasets, single volume, 5000 tracks allocated, 0 tracks used, have 
secondary space and CA-DISK releases the space without problems.
SYSIN:
RELEASE  FILTERDD(FILTERDD) 
With normal FILTERDD input, from which the other datasets are normally released.

Kees.



For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: DFdss does not release space

[Vernooij, CP (ITOPT1) - KLM]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: 15 December, 2015 13:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: DFdss does not release space

>The only reason I can think of is that the datasets have allocated 5000 
>tracks, but use 0. But I found no explanation nor selection parameter for 
>this. 


>From the DSS Guide:
Chapter 9. Managing space with DFSMSdss
Releasing unused space in data sets
...
Exclude data sets whose last block pointer in the data set VTOC entry is not 
maintained in the VTOC by using the EXCLUDE keyword. This can occur if you use 
an access method other than BSAM, QSAM, BPAM, or VSAM. DFSMSdss does not 
release space for data sets whose last block pointer in the data set entry is 0.


There does not seem to be an option to override this restriction.




--

Thanks,
that seems the explanation, as I guessed.
Still I wonder why these are not released, they have secondary space and 
CA-DISK has no problem releasing them. Since they are SMS managed, they have a 
decent EOF and there should be no danger of freeing space with valid data in it 
because of an incorrect last block pointer.

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: DFdss does not release space

[R.S.]

W dniu 2015-12-15 o 11:18, Vernooij, CP (ITOPT1) - KLM pisze:

Hello group,

I use DFdss to try to release space from a group of datasets. However, all that 
DFdss says is the normal start- and endmessages plus:
ADR470W (001)-RLSE0(02), NO DATA SETS SELECTED FOR PROCESSING

I have no idea why, all parameters like minsecqty and mintracksunused should 
allow release.
The only reason I can think of is that the datasets have allocated 5000 tracks, 
but use 0. But I found no explanation nor selection parameter for this.
How can I get DFdss to release this space?

Any ideas?

What kind of datasets are covered?
Can you provide whole SYSIN statement?


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc 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.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.840.228 zotych.


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

Re: JES2 - originating jcl

[John McKown]

Oh, in the below, I forgot to mention that I once had an IKJEFF10 (TSO
SUBMIT) exit which modified the submitted JCL. But the modifications were
generated from a data area created by the ISPF SUBMIT command (another
exit). So, if you wanted to put in a JCL statement such as:

//*SUBMITTED FROM  BY  ON -mm-ddThh:mm:ssZ

(replace trailing Z with appropriate local time indicator, such as: -06:00
for U.S. Central Standard.

This is not for the faint of heart. And I don't have the source any more.
That was 20+ years ago at a shop which no longer exists.

On Tue, Dec 15, 2015 at 8:52 AM, John McKown 
wrote:

> On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) <
> joseph.s...@cms.hhs.gov> wrote:
>
>> Hello, is there a JES2 exit that will allow us to place the dataset and
>> member name of the job that was submitted ? The originating dataset/member
>> would be added as a comment to the JESLOG, MESSAGES, or JCL. I would assume
>> JES2 would know where the JCL came from but not sure.
>>
>
> ​No, it doesn't really. In most cases, the JCL is coming in from a
> "reader" of some sort (local, NJE, RJE, ​or _most likely today_ the
> internal reader: INTRDR).
>
> In all cases other than the INTRDR case, there is no DSN involved at all.
> And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for a card
> reader attached to "remote 1". If anybody use RJE any more.
>
> In the INTRDR case, the JCL is simply written out like it would be to a
> normal data set, most likely using QSAM or maybe BSAM. JES2 has no idea
> where the program doing the writing is getting it from. There might not
> even be a "data set", such as in the case of a CLIST doing a SUBMIT *
> command (JCL is in-line). Also, keep in mind that if someone is in ISPF
> EDIT and does a SUBMIT command, that command actually writes the contents
> of the edit buffer to an ISPF "temporary" (.CNTL) data sets, so even if
> JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER which
> was actually submitted by the ISPF SUBMIT edit command.
>
>
>
>>
>> Rgrds, Joseph Sumi
>>
>>
> --
>
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
>
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: JES2 - originating jcl

[Binyamin Dissen]

On Tue, 15 Dec 2015 14:41:32 + "Sumi, Joseph J. (CMS/CTR) (CTR)"
 wrote:

:>Hello, is there a JES2 exit that will allow us to place the dataset and 
member name of the job that was submitted ? The originating dataset/member 
would be added as a comment to the JESLOG, MESSAGES, or JCL. I would assume 
JES2 would know where the JCL came from but not sure.

Exit 30 could collect the info, but there is no requirement that the JCL comes
from a dataset.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

JES2 - originating jcl

[Sumi, Joseph J. (CMS/CTR) (CTR)]

Hello, is there a JES2 exit that will allow us to place the dataset and member 
name of the job that was submitted ? The originating dataset/member would be 
added as a comment to the JESLOG, MESSAGES, or JCL. I would assume JES2 would 
know where the JCL came from but not sure.

Rgrds, Joseph Sumi

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

Re: JES2 - originating jcl

[Staller, Allan]

Short answer... NO!


Hello, is there a JES2 exit that will allow us to place the dataset and member 
name of the job that was submitted ? The originating dataset/member would be 
added as a comment to the JESLOG, MESSAGES, or JCL. I would assume JES2 would 
know where the JCL came from but not sure.


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

Re: DFdss does not release space

[Vernooij, CP (ITOPT1) - KLM]

There is something to say in their advantage: it would/could be unsafe if the 
dataset were non SMS managed. But for SMS managed datasets, I see no reason to 
not interpret the 0 other than what it says: empty dataset. Probably the 30 
year old code was never adopted for SMS.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 15 December, 2015 15:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFdss does not release space

On Tue, 15 Dec 2015 13:00:31 +, Vernooij, CP (ITOPT1) - KLM wrote:

>-Original Message-
>From: Peter Hunkeler
>Sent: 15 December, 2015 13:53
>
>From the DSS Guide:
>Chapter 9. Managing space with DFSMSdss
>Releasing unused space in data sets
>...
>Exclude data sets whose last block pointer in the data set VTOC entry is not 
>maintained in the VTOC by using the EXCLUDE keyword. This can occur if you use 
>an access method other than BSAM, QSAM, BPAM, or VSAM. DFSMSdss does not 
>release space for data sets whose last block pointer in the data set entry is 
>0.
> 
So the designers committed the unforgivable blunder of failing to differentiate
between "0" and "unknown".  This has been a problem for me elsewhere, in
various DB interfaces, where I want to select all rows in which a certain column
is unset, and get, in addition, those in which it is 0, or "", or some other
default value.

Rexx does it right: the SYMBOL function distinguishes a DROPped symbol from
any possible explicitly assigned value.

>There does not seem to be an option to override this restriction.
>
>--
>
>Thanks,
>that seems the explanation, as I guessed.
>Still I wonder why these are not released, they have secondary space and 
>CA-DISK has no problem releasing them. Since they are SMS managed, they have a 
>decent EOF and there should be no danger of freeing space with valid data in 
>it because of an incorrect last block pointer.
> 
The logic would need to modulate to distinguish an SMS-managed data set from
non-SMS with a residual EOF not overwritten by BDAM updates.  The likelihood
of a wrong guess is small; the consequences devastating.

And there's apt to be a user, somewhere, who deliberately (irresponsibly?) 
exploits
the behavior and sets DS1LSTAR to 0 to suppress RELEASE.

ISTR that at its advent HSM wouldn't migrate empty data sets, nor PDEes with
no members.  Perhaps a similar motivation.

-- gil

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




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

Re: JES2 - originating jcl

[John McKown]

On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) <
joseph.s...@cms.hhs.gov> wrote:

> Hello, is there a JES2 exit that will allow us to place the dataset and
> member name of the job that was submitted ? The originating dataset/member
> would be added as a comment to the JESLOG, MESSAGES, or JCL. I would assume
> JES2 would know where the JCL came from but not sure.
>

​No, it doesn't really. In most cases, the JCL is coming in from a "reader"
of some sort (local, NJE, RJE, ​or _most likely today_ the internal reader:
INTRDR).

In all cases other than the INTRDR case, there is no DSN involved at all.
And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for a card
reader attached to "remote 1". If anybody use RJE any more.

In the INTRDR case, the JCL is simply written out like it would be to a
normal data set, most likely using QSAM or maybe BSAM. JES2 has no idea
where the program doing the writing is getting it from. There might not
even be a "data set", such as in the case of a CLIST doing a SUBMIT *
command (JCL is in-line). Also, keep in mind that if someone is in ISPF
EDIT and does a SUBMIT command, that command actually writes the contents
of the edit buffer to an ISPF "temporary" (.CNTL) data sets, so even if
JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER which
was actually submitted by the ISPF SUBMIT edit command.



>
> Rgrds, Joseph Sumi
>
>
-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: JES2 - originating jcl

[Vernooij, CP (ITOPT1) - KLM]

A little longer: JES got the JCL from INTRDR. Whoever sent it to INTRDR only 
knows where it came from.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: 15 December, 2015 15:44
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - originating jcl

Short answer... NO!


Hello, is there a JES2 exit that will allow us to place the dataset and member 
name of the job that was submitted ? The originating dataset/member would be 
added as a comment to the JESLOG, MESSAGES, or JCL. I would assume JES2 would 
know where the JCL came from but not sure.


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: JES2 - originating jcl

[Lizette Koehler]

I am not sure, but if this is restricted to TSO Submitted jobs, then perhaps
IKJEFF53 exit might help.  This will not help on Intrdr submitted JCL.

If you have a Scheduling package, you could see if that could help.
If you have a change management package like Changeman or Endevor, then you
might be able to do inserts on releases.

Maybe there are other options, if you could explain the problem you are trying
to solve, there might be other answers.

Also SMF record 42 has some information on PDS level information.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR)
> Sent: Tuesday, December 15, 2015 7:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES2 - originating jcl
> 
> Hello, is there a JES2 exit that will allow us to place the dataset and member
name of
> the job that was submitted ? The originating dataset/member would be added as
a
> comment to the JESLOG, MESSAGES, or JCL. I would assume JES2 would know where
> the JCL came from but not sure.
> 
> Rgrds, Joseph Sumi

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

Re: DFdss does not release space

[Paul Gilmartin]

On Tue, 15 Dec 2015 13:00:31 +, Vernooij, CP (ITOPT1) - KLM wrote:

>-Original Message-
>From: Peter Hunkeler
>Sent: 15 December, 2015 13:53
>
>From the DSS Guide:
>Chapter 9. Managing space with DFSMSdss
>Releasing unused space in data sets
>...
>Exclude data sets whose last block pointer in the data set VTOC entry is not 
>maintained in the VTOC by using the EXCLUDE keyword. This can occur if you use 
>an access method other than BSAM, QSAM, BPAM, or VSAM. DFSMSdss does not 
>release space for data sets whose last block pointer in the data set entry is 
>0.
> 
So the designers committed the unforgivable blunder of failing to differentiate
between "0" and "unknown".  This has been a problem for me elsewhere, in
various DB interfaces, where I want to select all rows in which a certain column
is unset, and get, in addition, those in which it is 0, or "", or some other
default value.

Rexx does it right: the SYMBOL function distinguishes a DROPped symbol from
any possible explicitly assigned value.

>There does not seem to be an option to override this restriction.
>
>--
>
>Thanks,
>that seems the explanation, as I guessed.
>Still I wonder why these are not released, they have secondary space and 
>CA-DISK has no problem releasing them. Since they are SMS managed, they have a 
>decent EOF and there should be no danger of freeing space with valid data in 
>it because of an incorrect last block pointer.
> 
The logic would need to modulate to distinguish an SMS-managed data set from
non-SMS with a residual EOF not overwritten by BDAM updates.  The likelihood
of a wrong guess is small; the consequences devastating.

And there's apt to be a user, somewhere, who deliberately (irresponsibly?) 
exploits
the behavior and sets DS1LSTAR to 0 to suppress RELEASE.

ISTR that at its advent HSM wouldn't migrate empty data sets, nor PDEes with
no members.  Perhaps a similar motivation.

-- gil

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

Re: JES2 - originating jcl

[Vernooij, CP (ITOPT1) - KLM]

We do so in TSO submitted jobs and so do some schedulers and applications 
submitting jobs. 
But the original question was: does JES2 know and then the answer is simply: NO.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 15 December, 2015 15:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - originating jcl

Oh, in the below, I forgot to mention that I once had an IKJEFF10 (TSO
SUBMIT) exit which modified the submitted JCL. But the modifications were
generated from a data area created by the ISPF SUBMIT command (another
exit). So, if you wanted to put in a JCL statement such as:

//*SUBMITTED FROM  BY  ON -mm-ddThh:mm:ssZ

(replace trailing Z with appropriate local time indicator, such as: -06:00
for U.S. Central Standard.

This is not for the faint of heart. And I don't have the source any more.
That was 20+ years ago at a shop which no longer exists.

On Tue, Dec 15, 2015 at 8:52 AM, John McKown 
wrote:

> On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) <
> joseph.s...@cms.hhs.gov> wrote:
>
>> Hello, is there a JES2 exit that will allow us to place the dataset and
>> member name of the job that was submitted ? The originating dataset/member
>> would be added as a comment to the JESLOG, MESSAGES, or JCL. I would assume
>> JES2 would know where the JCL came from but not sure.
>>
>
> ​No, it doesn't really. In most cases, the JCL is coming in from a
> "reader" of some sort (local, NJE, RJE, ​or _most likely today_ the
> internal reader: INTRDR).
>
> In all cases other than the INTRDR case, there is no DSN involved at all.
> And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for a card
> reader attached to "remote 1". If anybody use RJE any more.
>
> In the INTRDR case, the JCL is simply written out like it would be to a
> normal data set, most likely using QSAM or maybe BSAM. JES2 has no idea
> where the program doing the writing is getting it from. There might not
> even be a "data set", such as in the case of a CLIST doing a SUBMIT *
> command (JCL is in-line). Also, keep in mind that if someone is in ISPF
> EDIT and does a SUBMIT command, that command actually writes the contents
> of the edit buffer to an ISPF "temporary" (.CNTL) data sets, so even if
> JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER which
> was actually submitted by the ISPF SUBMIT edit command.
>
>
>
>>
>> Rgrds, Joseph Sumi
>>
>>
> --
>
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
>
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




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

Re: Anyone using Rocket Software Performance Essential

[David Mingee]

 I used IAM, Rocket's Product and BMC Batch Optimizer.  All of them provide 
great benefit in reduced run time by reducing I/O.  My favorite isBat/Opt 
Standard Edition.  Why, because it is FREE and easiest to use.  Also, it 
provides stat reports that identify files that are read one recordper open(bad 
program code) even with proper buffering.


David Mingee
Mainframe Consulting
9206 Aintree Drive
Indianapolis, IN  46250
317 288-9588  Home317 903-9455  Cell

  From: John Clifford 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Tuesday, December 15, 2015 11:14 AM
 Subject: Re: Anyone using Rocket Software Performance Essential
   
I used it for 30 years until I got laid off.  Yes, it started as VIOplus
from Softworks and then it went to EMC then Rocket. It saved incredible
amounts of time as we were a huge VSAM shop. I tested a few real  VSAM pigs
and ran jobs turning off VIOplus (perf Essential now) and jobs went from 1
hour 10 minutes to 18 hours.  Actual time. There was no way I could
possibly sit down and figure all the jcl changes to tune the VSAM file
access to get this kind of benefit. I haven't touched it since 2012 but I
would assume it still helps alot with VSAM and Qsam.

John Clifford
z/OS consultant

On Tue, Dec 15, 2015 at 10:28 AM, Porowski, Ken 
wrote:

> I've used it for years.  IIRC it was originally called VIOPlus from
> Softworks.  No real issues with it although there are a few cases where a
> job will gag on it but it is easy to bypass.  It is basically dynamic
> buffering for VSAM and Sequential datasets.  Nothing you can't do through
> JCL yourself if you have the (lots of) time to put into it.  I think it's
> worth it and it does dramatically improve I/O performance.
>
>
>
>
> CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1
> 973 740 5459 (tel) | ken.porow...@cit.com
>
>
>
>
> This email message and any accompanying materials may contain proprietary,
> privileged and confidential information of CIT Group Inc. or its
> subsidiaries or affiliates (collectively, “CIT”), and are intended solely
> for the recipient(s) named above.  If you are not the intended recipient of
> this communication, any use, disclosure, printing, copying or distribution,
> or reliance on the contents, of this communication is strictly prohibited.
> CIT disclaims any liability for the review, retransmission, dissemination
> or other use of, or the taking of any action in reliance upon, this
> communication by persons other than the intended recipient(s).  If you have
> received this communication in error, please reply to the sender advising
> of the error in transmission, and immediately delete and destroy the
> communication and any accompanying materials.  To the extent permitted by
> applicable law, CIT and others may inspect, review, monitor, analyze, copy,
> record and retain any communications sent from or received at this email
> address.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Mattson
> Sent: Monday, December 14, 2015 8:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Anyone using Rocket Software Performance Essential
>
> Rocket software has a "Performance Essential" product which they claim
> greatly improved VSAM and other I/O processing.  Does anyone have
> experience with it?  Basically does it significantly improve I/O and is it
> trouble free?
>
> --
> 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
>

--
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: DFdss does not release space

[Charles Mills]

DB2 and other RDBMS distinguish NULL from any possible actual value such as 
zero or a zero-length string.

Not sure of the size and signage of the field in question but -1 might have 
been a good indicator for "not set."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 15, 2015 6:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFdss does not release space

On Tue, 15 Dec 2015 13:00:31 +, Vernooij, CP (ITOPT1) - KLM wrote:

>-Original Message-
>From: Peter Hunkeler
>Sent: 15 December, 2015 13:53
>
>From the DSS Guide:
>Chapter 9. Managing space with DFSMSdss Releasing unused space in data 
>sets ...
>Exclude data sets whose last block pointer in the data set VTOC entry is not 
>maintained in the VTOC by using the EXCLUDE keyword. This can occur if you use 
>an access method other than BSAM, QSAM, BPAM, or VSAM. DFSMSdss does not 
>release space for data sets whose last block pointer in the data set entry is 
>0.
> 
So the designers committed the unforgivable blunder of failing to differentiate 
between "0" and "unknown".  This has been a problem for me elsewhere, in 
various DB interfaces, where I want to select all rows in which a certain 
column is unset, and get, in addition, those in which it is 0, or "", or some 
other default value.

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

Re: Anyone using Rocket Software Performance Essential

[Porowski, Ken]

I've used it for years.  IIRC it was originally called VIOPlus from Softworks.  
No real issues with it although there are a few cases where a job will gag on 
it but it is easy to bypass.  It is basically dynamic buffering for VSAM and 
Sequential datasets.  Nothing you can't do through JCL yourself if you have the 
(lots of) time to put into it.  I think it's worth it and it does dramatically 
improve I/O performance.




CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com




This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Mattson
Sent: Monday, December 14, 2015 8:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Anyone using Rocket Software Performance Essential

Rocket software has a "Performance Essential" product which they claim greatly 
improved VSAM and other I/O processing.  Does anyone have experience with it?  
Basically does it significantly improve I/O and is it trouble free?

--
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: JES2 - originating jcl

[Charles Mills]

Sure would be useful. I sometimes put a comment in the JCL, but of course 
sometimes I forget, sometimes I clone JCL and fail to change the comment, 
sometimes datasets and members get renamed, ...

Not arguing with your answer and yes, I understand the "impossibility." Just 
sayin'.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, December 15, 2015 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 - originating jcl

We do so in TSO submitted jobs and so do some schedulers and applications 
submitting jobs. 
But the original question was: does JES2 know and then the answer is simply: NO.

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