Client - Server environment using TLS 1.2

[Donald Likens]

We have a TCP/IP z/OS client using "USS ASSEMBLER Callable Services" 
communicating with a java server (running on any environment). We have a 
requirement to use TLS 1.2 for this communications. Can someone give me a clue 
as to where to look on how to do this upgrade?

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

Re: C++ default parameter question

[David Crayford]

Compiles just fine

extern "OS" {
  int asmprog( int n, int y = 1 );
}

int main( int argc, char *argv[] )
{
asmprog(1);
return 0;
}


On 27/05/2016 6:05 AM, Charles Mills wrote:

I'm pretty sure I know the answer to this question but wondered if someone
knew for sure.

If I declare a function void FOO(int x = 1); and call it with FOO() then the
construction and passing of an integer parameter with a value of 1 is
entirely handled by the calling module, correct?

The reason I am asking ... suppose FOO is a function implemented in
assembler, not in C++. The declaration of the default parameter and the
invocation with the parameter omitted will still work, right?

Charles

--
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: C++ default parameter question

[Bernd Oppolzer]

Thinking about this once again:

I could imagine that one of the different FOO functions could
indeed be implemented in ASSEMBLER (without name mangling),
if the others stay C++ functions, and then the default mechanism
could work for this function, too.

But only one of them, otherwise there would be duplicate external names.

Only wild guess ...

Kind regard

Bernd


Am 27.05.2016 um 03:04 schrieb Bernd Oppolzer:

Isn't it a problem that with true C++ functions it is possible that 
functions

can exist with the same name but different parameters, for example

void FOO (int x);
void FOO (double x);
void FOO (char *x);

and C++ chooses the right one depending on the parameter used on the 
function call?


This is done by a mechanism known as "name mangling" (that is,
a designation of the parameter type is appended to the function name,
giving the true "technical" function name).

So, if this is true, how would you implement such a C++ function in 
ASSEMBLER,

if you don't declare it as extern "C" or extern "ASSEMBLER"?

This being said: I don't think, the default mechanism will work in 
this case,

but I may be wrong with this.

Kind regards

Bernd



Am 27.05.2016 um 00:05 schrieb Charles Mills:
I'm pretty sure I know the answer to this question but wondered if 
someone

knew for sure.

If I declare a function void FOO(int x = 1); and call it with FOO() 
then the

construction and passing of an integer parameter with a value of 1 is
entirely handled by the calling module, correct?

The reason I am asking ... suppose FOO is a function implemented in
assembler, not in C++. The declaration of the default parameter and the
invocation with the parameter omitted will still work, right?

Charles

--
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: C++ default parameter question

[Bernd Oppolzer]

Isn't it a problem that with true C++ functions it is possible that 
functions

can exist with the same name but different parameters, for example

void FOO (int x);
void FOO (double x);
void FOO (char *x);

and C++ chooses the right one depending on the parameter used on the 
function call?


This is done by a mechanism known as "name mangling" (that is,
a designation of the parameter type is appended to the function name,
giving the true "technical" function name).

So, if this is true, how would you implement such a C++ function in 
ASSEMBLER,

if you don't declare it as extern "C" or extern "ASSEMBLER"?

This being said: I don't think, the default mechanism will work in this 
case,

but I may be wrong with this.

Kind regards

Bernd



Am 27.05.2016 um 00:05 schrieb Charles Mills:

I'm pretty sure I know the answer to this question but wondered if someone
knew for sure.

If I declare a function void FOO(int x = 1); and call it with FOO() then the
construction and passing of an integer parameter with a value of 1 is
entirely handled by the calling module, correct?

The reason I am asking ... suppose FOO is a function implemented in
assembler, not in C++. The declaration of the default parameter and the
invocation with the parameter omitted will still work, right?

Charles

--
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: C++ default parameter question

[Charles Mills]

Thanks. I was pretty sure that was the case. I just wanted to make sure I
was not missing something. It is documented as "C++ only." But it's really
"the caller only has to be C++." I guess the called function could be C; you
would just have to have a different header declaration -- not unheard of,
e.g.

#ifdef __cplusplus
   extern "OS" {
#else
  #pragma linkage(CSRSI_calltype,OS)
#endif

> fairly easy to test

For sure. And I am testing away. Just did not want to bother if someone
smarter than I said "no, silly, that cannot work because ..."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jack J. Woehr
Sent: Thursday, May 26, 2016 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C++ default parameter question

Charles Mills wrote:
> The reason I am asking ... suppose FOO is a function implemented in 
> assembler, not in C++. The declaration of the default parameter and 
> the invocation with the parameter omitted will still work, right?
Apparently so. Of course, fairly easy to test!

http://dewkumar.blogspot.com/2012/01/how-is-default-function-argument-to.htm
l
http://stackoverflow.com/questions/3170111/c-default-argument-value

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

Re: Questions on DPMOD

[Charles Mills]

Thanks. I said "jobstep task" -- I was thinking of a batch job.

Right, the ATTACH(X) doc is fairly clear on the relationship of subtasks to
the mother task.

So this is inherent in the guts of MVS -- not something in PROGxx or
somewhere like that?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Greg Dyck
Sent: Thursday, May 26, 2016 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions on DPMOD

On 5/26/2016 2:51 PM, Charles Mills wrote:
> 1. Where is the original dispatching and limit priority for the 
> jobstep task set? How do I determine (not with an API at runtime, but 
> in advance with a command or looking at a parm member) what it is
presumably going to be?
>

Sigh... the initial starting value varies by who attaches the jobstep task.
And then any subsequent attaches in the task tree effect the value for the
attached task.

The thing to remember is that the (task) minor priority is a tie-breaker
between work (tasks and preemptable SRBs) running within a single address
space.  Between the work for two different address spaces it is irrelevant.

It's been over 20 years since I had to deal with problems in this area
(MVS/ESA SP5.1), and I don't remember all the specifics.  I know that
jobsteps attached by the started task controller start with a minor priority
of 255.  I think the same is true of batch initiator jobs.  I believe the
TSO TMP attaches all commands with a minor priority of 250. 
And UNIX Systems Services did not exist at the time.

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

Re: C++ default parameter question

[Jack J. Woehr]

Charles Mills wrote:

The reason I am asking ... suppose FOO is a function implemented in
assembler, not in C++. The declaration of the default parameter and the
invocation with the parameter omitted will still work, right?

Apparently so. Of course, fairly easy to test!

http://dewkumar.blogspot.com/2012/01/how-is-default-function-argument-to.html
http://stackoverflow.com/questions/3170111/c-default-argument-value

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Questions on DPMOD

[Greg Dyck]

On 5/26/2016 2:51 PM, Charles Mills wrote:

1. Where is the original dispatching and limit priority for the jobstep task
set? How do I determine (not with an API at runtime, but in advance with a
command or looking at a parm member) what it is presumably going to be?



Sigh... the initial starting value varies by who attaches the jobstep 
task.  And then any subsequent attaches in the task tree effect the 
value for the attached task.


The thing to remember is that the (task) minor priority is a tie-breaker 
between work (tasks and preemptable SRBs) running within a single 
address space.  Between the work for two different address spaces it is 
irrelevant.


It's been over 20 years since I had to deal with problems in this area 
(MVS/ESA SP5.1), and I don't remember all the specifics.  I know that 
jobsteps attached by the started task controller start with a minor 
priority of 255.  I think the same is true of batch initiator jobs.  I 
believe the TSO TMP attaches all commands with a minor priority of 250. 
And UNIX Systems Services did not exist at the time.



2. There are several references to a dispatching priority of zero. Does zero
mean the subtask does not run at all, or just that it is last in line for a
CPU?


A minor dispatching priority of 0 means it is last in line, *within* 
it's own address space, for being dispatched.  It won't prevent it from 
running.


Greg

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

C++ default parameter question

[Charles Mills]

I'm pretty sure I know the answer to this question but wondered if someone
knew for sure.

If I declare a function void FOO(int x = 1); and call it with FOO() then the
construction and passing of an integer parameter with a value of 1 is
entirely handled by the calling module, correct? 

The reason I am asking ... suppose FOO is a function implemented in
assembler, not in C++. The declaration of the default parameter and the
invocation with the parameter omitted will still work, right?

Charles 

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

Re: CREATED date for migrated data sets?

[retired mainframer]

According to my DFSMShsm Data Areas manual, the Migration Control Data Set Data 
Set Record has the creation data at offset x'4c' in field MCDDLC.  There does 
not appear to be an HSM utility to extract these records in bulk.  You could 
write a little selection program to read them or use a utility to print them in 
hex and then scrape the output with a REXX to select the ones you want

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, May 26, 2016 12:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CREATED date for migrated data sets?
> 
> I would like to HRECALL all data sets matching a certain pattern
> and created since 2016-04-01.  Alas, ISPF DSLIST does not show
> created date for migrated data sets.
> 
> I suppose that if they were created after April 1, they could not
> have been migrated earlier, so I could use a HLIST.  Is there a
> better way?

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

Questions on DPMOD

[Charles Mills]

This seems like a pretty basic question but in all my years of coding I have
never messed with dispatching priority that I recall.

I have read the doc for ATTACH(X) DPMOD and LPMOD. I have read the relevant
sections in Chapter 3 of the Assembler Services Guide.

Questions:

1. Where is the original dispatching and limit priority for the jobstep task
set? How do I determine (not with an API at runtime, but in advance with a
command or looking at a parm member) what it is presumably going to be?

2. There are several references to a dispatching priority of zero. Does zero
mean the subtask does not run at all, or just that it is last in line for a
CPU?

Thanks,

Charles 

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

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[Ed Jaffe]

On 5/26/2016 10:29 AM, Jerry Callen wrote:

Here are the results:

Relative performance: total CPU
ECB   1.0
Pause/Resume  4.30
Transfer and Pause3.25
Transfer with separate Pause  4.55

Relative performance: elapsed
ECB   1.0
Pause/Resume  6.06
Transfer and Pause4.75
Transfer with separate Pause  6.28


Great benchmark! If you're ever looking for a job and we happen to have 
an opening... ;-)


We ran a similar benchmark back in 2007 and discovered -- in addition to 
the great info you've provided -- that suspending or pausing SRBs is 
slower than suspending or pausing TCBs. We guessed the extra overhead 
was due to the fact that SRBs, unlike TCBs, have no control block and 
therefore must acquire an SSRB from ECSA, populate it with data from 
LCCA, PSA or whatever before suspending, and return it upon waking up.


I agree the reference materials _imply_ that WAIT/POST are deprecated 
and that Pause/Release/Transfer should be used when possible. I believe 
that the issues surrounding ownership and management of the ECB storage 
played a larger role in those recommendation than raw performance did.


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

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

Re: CREATED date for migrated data sets?

[Walt Farrell]

On Thu, 26 May 2016 13:17:06 -0700, Lizette Koehler  
wrote:

>Probably HLIST is the best.  Unless you have Vantage with HSM Option or Tivoli 
>Storage Suite
>
>HLIST SELECT(AGE(x,y)) MCDS ODS('your.data.set.output')
>
>As far as I know, there is no  DATE qualification on HLIST.
>
>AGE(mindays maxdays) is an optional subparameter of SELECT that specifies a 
>list of those entries in the MCDS for only the data sets whose most recent 
>reference is within the specified range of days
>
>You may need to work with the subparms.  I may not remember this correctly.

I'm not sure that will work, Lizette. "most recent _reference_" does not sound 
like it refers to the creation date. In fact, the documentation goes on to say 
"minimum number of days since you referred to the data sets" not "since the 
data set was created."

-- 
Walt

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

Re: Product name by module

[Edward Finnell]

I checked listserv.ua.edu and this is your first post here.

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

Re: Product name by module

[Rob Barbour]

P-Tracker from UBSHainer is a product that identifies all programs used 
in either online or batch mainframe asset discovery as it is 
sometimes called.  P-Tracker also identifies call sequences which is 
helpful for applications folks to determine which modules from where are 
being used.   Product  is reasonably priced and can be found at 
www.MainframeTracker.com


P.S.  I tried posting this thru listserv site but didnt show up... so 
please excuse this if repeat.

--
Signature --
Best Regards,
Rob Barbour
Enterprise Systems Associates, Inc ("ESAi")
UCF Research Park
3259 Progress Drive
Orlando,  Florida 32826USA
Toll Free: 1-866-GO-4-ESAI (1-866-464-3724)
http://www.ESAIGroup.com/products

twitter.com/ESAiSoftware 

Thanks to all who visited us.


z Performance... Productivity for DB2... Services...
BCV4 -  DB2, SAP, PeopleSoft Clones/Refreshes in Minutes vs Days
BCV5/BCV6 -  Save 90% in CPU & Clock Time for DB2 Refresh / Migrate
XDM - Fast Automated Data Movement in/between DB2, LUW, Oracle, etc
ULT4DB2 - Faster, Better Value in DB2 Log Analyzers w/ PROP, & Audit
BPA4DB2 - Save $, Improve DB2 Performance with Buffer Pool Analyzer
XM4DB2 - Proactive Approach for DB2,Performance, & Dynamic SQL
SQLQC - Find, Analyze, Improve SQL Quality Control and Performance

zDYNACAP - Meet SLAs at Lowest MLC Cost with Capacity Balancing
INSPECT-CPU - Improve CICS Application Performance with ICPU






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

AW: CREATED date for migrated data sets?

[Peter Hunkeler]

> Alas, ISPF DSLIST does not show created date for migrated data sets.


Those dates are in the data set's DSCB. There is none for migrated ones. So for 
once, ISPF is not guilty.



--
Peter Hunkeler



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

Re: CREATED date for migrated data sets?

[Lizette Koehler]

Probably HLIST is the best.  Unless you have Vantage with HSM Option or Tivoli 
Storage Suite

HLIST SELECT(AGE(x,y)) MCDS ODS('your.data.set.output')

As far as I know, there is no  DATE qualification on HLIST.

AGE(mindays maxdays) is an optional subparameter of SELECT that specifies a 
list of those entries in the MCDS for only the data sets whose most recent 
reference is within the specified range of days

You may need to work with the subparms.  I may not remember this correctly.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, May 26, 2016 12:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CREATED date for migrated data sets?
> 
> I would like to HRECALL all data sets matching a certain pattern and created
> since 2016-04-01.  Alas, ISPF DSLIST does not show created date for migrated
> data sets.
> 
> I suppose that if they were created after April 1, they could not have been
> migrated earlier, so I could use a HLIST.  Is there a better way?
> 
> Thanks,
> gil
> 

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

Re: CREATED date for migrated data sets?

[Barry Merrill]

I think its worse than that.

Change 34.115  Variable DCDTIMEC, Data Set Create Time in DCOLDSET is
VMACDCOL   only populated if
May 11, 2016 - the dataset is on an EAV volume (more than 65K CYL)
 - the volume is the first volume for the dataset
   (DCDTIMEC is zero in the DSCB for other volumes)
 - for non-VSAM, EATTR=OPT must be specified (JCL or
   Data Class), because EATTR=NO is the default for
   non-VSAM, EATTR=OPT is the default for VSAM.
   The DCDTIMEC comes from the FORMAT 9 DSCB control block
   (in the VTOC), created for EAS-eligible datasets on EAV
   that have EATTR=OPT, except for datasets that do not have
   do not have FORMAT 8/9 DSCBs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, May 26, 2016 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CREATED date for migrated data sets?

I would like to HRECALL all data sets matching a certain pattern and created 
since 2016-04-01.  Alas, ISPF DSLIST does not show created date for migrated 
data sets.

I suppose that if they were created after April 1, they could not have been 
migrated earlier, so I could use a HLIST.  Is there a better way?

Thanks,
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

CREATED date for migrated data sets?

[Paul Gilmartin]

I would like to HRECALL all data sets matching a certain pattern
and created since 2016-04-01.  Alas, ISPF DSLIST does not show
created date for migrated data sets.

I suppose that if they were created after April 1, they could not
have been migrated earlier, so I could use a HLIST.  Is there a
better way?

Thanks,
gil

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

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[Jerry Callen]

Greg Dyck wrote:

> No one every said that Pause/Release was faster or consumed the same 
> amount of CPU as WAIT/POST, or that they should be used as a universal 
> replacement for WAIT/POST.  They should be used where they provide value.

The reason I wrote the test is that the documentation is unclear as to 
performance, and suggests that TRANSFER, in particular, might be faster than 
WAIT/POST. From the 2.2 Assembler Services Guide:

===
If you have, for example, an application that requires two or more tasks to 
trade control back and forth, these services provide efficient transfers of 
control.
[...]
The Transfer service can both release a paused task and pass control directly 
to the released task. The Transfer service can also pause the task that calls 
the service. Thus, Transfer enables quick dispatches, saving the overhead of 
work search. It also allows two tasks to trade control back and forth with 
minimal overhead.
===

Aside from earlier comments here in IBM-MAIN, I had no particular 
preconceptions regarding the performance, which is why I wrote the tests. Both 
services are easy to use, so there was no compelling advantage to either on 
that score.

-- Jerry

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

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[Greg Dyck]

On 5/26/2016 10:29 AM, Jerry Callen wrote:

I wrote a simple test program to compare the performance of WAIT/POST and pause elements. 
The program has two tasks and simply ping-pongs back and forth between them (no 
overlapped execution). Each task has a synchronization gadget, either an ECB or a pause 
element. The tasks use each other's synchronization gadget to just transfer control back 
and forth between each other in a loop. This is a pretty unrealistic test (in terms of 
being like anything "real" code would do), but it does illustrate the relative 
performance of the two synchronization methods.


This is like comparing using a back-hoe to dig a hole to plant a flower 
vs using a trowel.


No one every said that Pause/Release was faster or consumed the same 
amount of CPU as WAIT/POST, or that they should be used as a universal 
replacement for WAIT/POST.  They should be used where they provide value.


Pause/Release can be used in environments where WAIT/POST can not be 
used.  They support being issued by SRBs.  They support being issued in 
cross-memory mode.  The processing does not have any special case paths 
for more simple cases.  As such, they are not light-weight services.


WAIT/POST within a single address space is much more limited.  Because 
of those limitations it is a light-weight service, and that is why you 
see the results that you see.


Greg

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

Re: Video that might give you a chuckle

[David L. Craig]

On 16May26:1154+, van der Grijn, Bart (B) wrote:

> It's an interesting observation as I always chuckle
> when my American coworkers say parmlibe,

Here lib does not rhyme with glib, but with tribe and
is understood to be short for library.  How do you
pronouce the full word?
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[TeD MacNEIL]

He said z13 & ‎z/OS2.2.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: michelbutz
Sent: Thursday, May 26, 2016 13:35
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower 
than both.

Can you tell us the following 

What type of processor 
The work load 
What version of z/OS these are relevant factors

Sent from my iPhone

> On May 26, 2016, at 1:29 PM, Jerry Callen  wrote:
> 
> (A very delayed follow-up on a thread from yesteryear...)
> 
> tl;dr: In unauthorized code, ECBs are much faster than pause elements.
> 
> I wrote a simple test program to compare the performance of WAIT/POST and 
> pause elements. The program has two tasks and simply ping-pongs back and 
> forth between them (no overlapped execution). Each task has a synchronization 
> gadget, either an ECB or a pause element. The tasks use each other's 
> synchronization gadget to just transfer control back and forth between each 
> other in a loop. This is a pretty unrealistic test (in terms of being like 
> anything "real" code would do), but it does illustrate the relative 
> performance of the two synchronization methods.
> 
> Note that this unauthorized code, and tasks, not SRBs This means that all of 
> the synchronization primitives used SVCs, not branch entry points. The code 
> is 64-bit C++ compiled with xlC using -q64 and thread_create() to create the 
> tasks. The code is running on a z13, native LPAR, z/OS 2.2.
> 
> The mechanisms I tested are:
> 
> * ECBs: each task just alternates between a WAIT on its own ECB and a POST of 
> the other task's ECB.
> * Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role 
> of WAIT and POST.
> * Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one 
> call to do both).
> * Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by 
> Pause (iea4pse).
> 
> Here are the results:
> 
> Relative performance: total CPU
> ECB 1.0
> Pause/Resume 4.30
> Transfer and Pause 3.25
> Transfer with separate Pause 4.55
> 
> Relative performance: elapsed
> ECB 1.0
> Pause/Resume 6.06
> Transfer and Pause 4.75
> Transfer with separate Pause 6.28
> 
> -- Jerry
> 
> --
> 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[michelbutz]

Can you tell us the following 

What type of processor 
 The work load 
  What version of z/OS these  are relevant factors

Sent from my iPhone

> On May 26, 2016, at 1:29 PM, Jerry Callen  wrote:
> 
> (A very delayed follow-up on a thread from yesteryear...)
> 
> tl;dr: In unauthorized code, ECBs are much faster than pause elements.
> 
> I wrote a simple test program to compare the performance of WAIT/POST and 
> pause elements. The program has two tasks and simply ping-pongs back and 
> forth between them (no overlapped execution). Each task has a synchronization 
> gadget, either an ECB or a pause element. The tasks use each other's 
> synchronization gadget to just transfer control back and forth between each 
> other in a loop. This is a pretty unrealistic test (in terms of being like 
> anything "real" code would do), but it does illustrate the relative 
> performance of the two synchronization methods.
> 
> Note that this unauthorized code, and tasks, not SRBs This means that all of 
> the synchronization primitives used SVCs, not branch entry points. The code 
> is 64-bit C++ compiled with xlC using -q64 and thread_create() to create the 
> tasks. The code is running on a z13, native LPAR, z/OS 2.2.
> 
> The mechanisms I tested are:
> 
> * ECBs: each task just alternates between a WAIT on its own ECB and a POST of 
> the other task's ECB.
> * Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role 
> of WAIT and POST.
> * Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one 
> call to do both).
> * Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by 
> Pause (iea4pse).
> 
> Here are the results:
> 
> Relative performance: total CPU
> ECB   1.0
> Pause/Resume  4.30
> Transfer and Pause3.25
> Transfer with separate Pause  4.55
> 
> Relative performance: elapsed
> ECB   1.0
> Pause/Resume  6.06
> Transfer and Pause4.75
> Transfer with separate Pause  6.28
> 
> -- Jerry
> 
> --
> 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[Jerry Callen]

(A very delayed follow-up on a thread from yesteryear...)

tl;dr: In unauthorized code, ECBs are much faster than pause elements.

I wrote a simple test program to compare the performance of WAIT/POST and pause 
elements. The program has two tasks and simply ping-pongs back and forth 
between them (no overlapped execution). Each task has a synchronization gadget, 
either an ECB or a pause element. The tasks use each other's synchronization 
gadget to just transfer control back and forth between each other in a loop. 
This is a pretty unrealistic test (in terms of being like anything "real" code 
would do), but it does illustrate the relative performance of the two 
synchronization methods.

Note that this unauthorized code, and tasks, not SRBs This means that all of 
the synchronization primitives used SVCs, not branch entry points. The code is 
64-bit C++ compiled with xlC using -q64 and thread_create() to create the 
tasks. The code is running on a z13, native LPAR, z/OS 2.2.

The mechanisms I tested are:

* ECBs: each task just alternates between a WAIT on its own ECB and a POST of 
the other task's ECB.
* Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role of 
WAIT and POST.
* Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one 
call to do both).
* Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by 
Pause (iea4pse).

Here are the results:

Relative performance: total CPU
ECB   1.0
Pause/Resume  4.30
Transfer and Pause3.25
Transfer with separate Pause  4.55

Relative performance: elapsed
ECB   1.0
Pause/Resume  6.06
Transfer and Pause4.75
Transfer with separate Pause  6.28

-- Jerry

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

Re: Space Calculation on z/OS sytems

[Neil Duffee]

Caveat:  daily digestion leads to response delays...

Didn't someone else, not long ago, have a problem with ISMF that turned out to 
be insufficient REGION= on the TSO session?  mainframe1960 might want to make a 
quick side-trip for validation.

>  signature = 8 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004
"Schrodinger's backup: The condition of any backup is unknown until a restore 
is attempted."  John McKown 2015


-Original Message-
From: Edward Finnell [mailto:ef...@aol...com] 
Sent: May 25, 2016 04:42
Subject: Re: Space Calculation on z/OS sytems

Your ISPF session is failing. Guess to debug start with ... [snip] 
 
In a message dated 5/25/2016 3:14:36 A.M. Central Daylight Time,  
mai...@gma...com writes:

But In  my case, I am getting blank in JCL report library, system not
producing any  JCL, which I can submit to get required  report.

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

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Barry Merrill]

I added support in 2014 but have not had a motivation to create 999 and see 
what happens!

  -VMACCTLG and VMAC6156 were updated Nov 27, 2014.
   Support for GDGE, GDG Extended GDGLIMIT=999 in z/OS 2.2.
   New variable GATEXTND='E' flags the extended mode, new
   variables GATLIMTE/GATCNTE are INPUT but also kept in the
   existing GATLIMIT/GATCNT to preserve existing reports.
   Some overlooked flag variables in the 05 Catalog Segment
   are now decoded and kept in datasets TYPE6156 (from SMF
   (type 61, 65, 66) and TYPECTLG (from the IDCAMS EXPORT
   CATALOG flat file).  These are all the 05 fields now:
 GATALLOC='GATALLOC*FIFO OR*LIFO?'
 GATCNT  ='GDG*COUNT'
 GATDELET='DELETE*WHEN*LIMIT*EXCEEDED*0=OLD*1=ALL?'
 GATEXTND='GATEXTND*EXTENDED*OR CLASSIC?'
 GATEXTNO='GATEXTNO'
 GATGEN  ='GATGEN  '
 GATLIMIT='MAXIMUM*GDS*ENTRIES*IN GDG*BASE'
 GATLIMTE='EXTENDED*GAT*GATLIMIT'
 GATPURGE='GATPURGE*YES OR*NO?'
 GATSCRTH='SCRATCH*FORMAT 1*DSCB*0=NO*1=YES?'
 GATVER  ='GATVER  '
 GATWRAP ='GATWRAP '
 GDGATTR ='GDGATTR'
  -BUILD005 protects for TYPETASK='JOBG' in JCTJOBID;

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, May 26, 2016 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

Barry,

I have heard that the number of GDGs may be allowed to go beyond 255 
generations. Do you have any insight on this?  I am wondering how this 
enhancement may impact the GDG Wrap condition.



I have seen in the z/OS V2.2 manuals:

Extended format for generation data groups (GDGs):

z/OS V2R2 introduces a new extended format for generation data groups (GDGs). 
Extended format GDGs can contain up to 999 generation data sets (GDSes). The 
previous GDS limit was 255 GDSes per GDG. New GDGs can be defined with this new 
extended format. For existing GDGs, the previous GDS limit still applies.

To support this enhancement, the IDCAMS DEFINE GDG command includes a new 
optional parameter (EXTENDED) that you can specify to enable a new GDG to 
contain up to 999 GDSes. If you do not specify that parameter, the default 
value (NOEXTENDED) takes effect, setting a limit of 255 GDSes for the GDG.

A new GDGEXTENDED parmlib variable lets you specify whether to allow the 
EXTENDED value to be used on DEFINE of a GDG. If GDGEXTENDED(NO) (the default) 
is specified, then the DEFINE of a GDG with the EXTENDED parameter is not 
allowed. If GDGEXTENDED(YES) is specified, then the DEFINE of a GDG with the 
EXTENDED parameter is allowed. For more information, see the description of 
IGGCATxx in z/OS MVS Initialization and Tuning Reference.

The LIMIT parameter on the IDCAMS DEFINE GDG command is changed to accept a 
maximum value of 999 for extended GDGs. The previous maximum LIMIT value of 255 
still applies to GDGs which are not defined as EXTENDED.

For extended GDGs, the IDCAMS ALTER LIMIT command is also enhanced to let you 
set a new GDS limit of up to 999 for the GDG. The z/OS Generic Tracking 
Facility has also been used to help determine if any calls to Catalog 
Management are only requesting the classic GDG limit, and not the extended GDG 
limit.

For more details about these enhancements, see the descriptions of the ALTER 
command and the DEFINE GENERATIONDATAGROUP command in z/OS DFSMS Access Method 
Services Commands.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Barry Merrill
> Sent: Thursday, May 26, 2016 7:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative 
> reference
> 
> An old change in MXG Software:
> 
> 
> Change 23.219  The ICF Catalog 05 record variable GATGEN should have
> VMAC6156   been input as , instead of one byte, and variable
> VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
> Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
>generation number has exceeded .  If GATWRAP is on,
>GATGEN=GATGEN-32768 to contain the correct Gen number.
>This discovery was precipitated by IGD07001I ABENDs in
>production, which occurred when a GDG that had GATWRAP
>on for some members, and GATWRAP off for others, when
>that GDG generation number goes from 999 to 1000.
>  Normally, when all members of a GDG have wrapped, the
>  next catalog action turns off the wrap bit in all of
>  the catalog records.  For a "normal" GDG, that 

Re: RFE's to consider

[Tom Marchant]

On Wed, 25 May 2016 11:26:29 -0500, Dyck, Lionel B. (TRA) wrote:

>After asking for votes for 2 RFE's (TSO Pipes and StreamIO) I want to share 
>another RFE that could use your support.
>
>This RFE is asking IBM to provide full ISPF support for PDSE V2 Generations.  
>The link is:
>
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=88479

I've been using PDSE V2 member generations for well over a year and I find them 
quite useful. I find it easy enough to find previous generations, and I can use 
COMPare * to see what is different. If I want to revert to a previous 
generation, I can then save it. And I often use SAVE NOGEN to save a minor 
change without creating a new generation.

All of that works well enough, but what I'd like to be able to do is to edit or 
view the current generation of a member and compare it to a previous 
generation. Then I could use MD and D line commands to selectively undo the 
changes, and possibly SAVE NOGEN.

-- 
Tom Marchant

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

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Lizette Koehler]

Barry,

I have heard that the number of GDGs may be allowed to go beyond 255 
generations. Do you have any insight on this?  I am wondering how this 
enhancement may impact the GDG Wrap condition.



I have seen in the z/OS V2.2 manuals:

Extended format for generation data groups (GDGs):

z/OS V2R2 introduces a new extended format for generation data groups (GDGs). 
Extended format GDGs can contain up to 999 generation data sets (GDSes). The 
previous GDS limit was 255 GDSes per GDG. New GDGs can be defined with this new 
extended format. For existing GDGs, the previous GDS limit still applies.

To support this enhancement, the IDCAMS DEFINE GDG command includes a new 
optional parameter (EXTENDED) that you can specify to enable a new GDG to 
contain up to 999 GDSes. If you do not specify that parameter, the default 
value (NOEXTENDED) takes effect, setting a limit of 255 GDSes for the GDG.

A new GDGEXTENDED parmlib variable lets you specify whether to allow the 
EXTENDED value to be used on DEFINE of a GDG. If GDGEXTENDED(NO) (the default) 
is specified, then the DEFINE of a GDG with the EXTENDED parameter is not 
allowed. If GDGEXTENDED(YES) is specified, then the DEFINE of a GDG with the 
EXTENDED parameter is allowed. For more information, see the description of 
IGGCATxx in z/OS MVS Initialization and Tuning Reference.

The LIMIT parameter on the IDCAMS DEFINE GDG command is changed to accept a 
maximum value of 999 for extended GDGs. The previous maximum LIMIT value of 255 
still applies to GDGs which are not defined as EXTENDED.

For extended GDGs, the IDCAMS ALTER LIMIT command is also enhanced to let you 
set a new GDS limit of up to 999 for the GDG. The z/OS Generic Tracking 
Facility has also been used to help determine if any calls to Catalog 
Management are only requesting the classic GDG limit, and not the extended GDG 
limit.

For more details about these enhancements, see the descriptions of the ALTER 
command and the DEFINE GENERATIONDATAGROUP command in z/OS DFSMS Access Method 
Services Commands.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barry Merrill
> Sent: Thursday, May 26, 2016 7:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference
> 
> An old change in MXG Software:
> 
> 
> Change 23.219  The ICF Catalog 05 record variable GATGEN should have
> VMAC6156   been input as , instead of one byte, and variable
> VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
> Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
>generation number has exceeded .  If GATWRAP is on,
>GATGEN=GATGEN-32768 to contain the correct Gen number.
>This discovery was precipitated by IGD07001I ABENDs in
>production, which occurred when a GDG that had GATWRAP
>on for some members, and GATWRAP off for others, when
>that GDG generation number goes from 999 to 1000.
>  Normally, when all members of a GDG have wrapped, the
>  next catalog action turns off the wrap bit in all of
>  the catalog records.  For a "normal" GDG, that should
>  happen when the +256th gen is created after wrap, as
>  only 255 members can exist in the catalog.  But this
>  site had had a very old application that originally
>  created +1 thru +5 each day, and then deleted +1 thru
>  +4, leaving only +5 in the catalog.  However, back when
>  Clinton was President, an application change was made
>  that created only +1 thru +3 and deleted only +1 & +2,
>  so there were 2 old GVoo's left in the catalog.
>  When the GDG wrapped, and when the create of +1 would
>  have created G1000V00, those old GVoo's still had
>  their wrap bit off, and the production job failed:
>IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
>  Return Code 140:
>Inconsistent or conflicting arguments were provided.
>  Reason Code 122:
>Catalog G1000Vxx will cause the GDG to exceed the
>limit of 10,999.
>  Programmer Response:
>Clean up the GDG in error then catalog G1000Vxx.
>The site found Information APAR II07276, which explained
>how wrap works, but it says to 'see the "Z" page for
>internal details of the wrap bit interface'.
> 
>So the site asked IBM Support: "We need to identify other
>GDGs that have the same exposure to causing ABENDs.  Can
>I look at the 'Z' page?  Does the 'wrap bit' appear in
>

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Barry Merrill]

An old change in MXG Software:


Change 23.219  The ICF Catalog 05 record variable GATGEN should have
VMAC6156   been input as , instead of one byte, and variable
VMACCTLG   GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its
   generation number has exceeded .  If GATWRAP is on,
   GATGEN=GATGEN-32768 to contain the correct Gen number.
   This discovery was precipitated by IGD07001I ABENDs in
   production, which occurred when a GDG that had GATWRAP
   on for some members, and GATWRAP off for others, when
   that GDG generation number goes from 999 to 1000.
 Normally, when all members of a GDG have wrapped, the
 next catalog action turns off the wrap bit in all of
 the catalog records.  For a "normal" GDG, that should
 happen when the +256th gen is created after wrap, as
 only 255 members can exist in the catalog.  But this
 site had had a very old application that originally
 created +1 thru +5 each day, and then deleted +1 thru
 +4, leaving only +5 in the catalog.  However, back when
 Clinton was President, an application change was made
 that created only +1 thru +3 and deleted only +1 & +2,
 so there were 2 old GVoo's left in the catalog.
 When the GDG wrapped, and when the create of +1 would
 have created G1000V00, those old GVoo's still had
 their wrap bit off, and the production job failed:
   IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
 Return Code 140:
   Inconsistent or conflicting arguments were provided.
 Reason Code 122:
   Catalog G1000Vxx will cause the GDG to exceed the
   limit of 10,999.
 Programmer Response:
   Clean up the GDG in error then catalog G1000Vxx.
   The site found Information APAR II07276, which explained
   how wrap works, but it says to 'see the "Z" page for
   internal details of the wrap bit interface'.

   So the site asked IBM Support: "We need to identify other
   GDGs that have the same exposure to causing ABENDs.  Can
   I look at the 'Z' page?  Does the 'wrap bit' appear in
   SMF 61, 65, 66 ICF Catalog records?"

   IBM Level 2 Catalog Support refused to answer the quite
   valid question, with this answer:
 "Unfortunately, the 'Z' page in our info APARs refer to
 information meant for IBM eyes only, for helping us get
 to problem determination quicker.  We are not at
 liberty to discuss any control block internals that are
 not provided in our published manuals.  As for
 information in SMF records relating to this, this info
 would be included in the updated record portion
 of the SMF record, however we cannot discuss offsets
 for those either.  I am sorry I cannot be more helpful.
 Please let me know if there are any other questions
 that I can answer for you."

   Even escalation to my IBM Poughkeepsie z/OS support did
   not convince IBM Level 2 Catalog Support to identify
   which bit is the "GATWRAP" bit.  The ICF Support and
   Developers hid behind "OCO", Object Code Only, as the
   reason they could not provide catalog record
   documentation (but DSECTS are NOT CODE!).

   So I suggested the site could create a GDG and force it
   to wrap, and by examining SMF records, we concluded that
   first bit of GATGEN was the GATWRAP bit.

   Then, I remembered I still had lots of archaic printed
   manuals, and located the very old "MVS/XA Catalog
   Diagnosis Reference for DFP Release 1.2", which confirmed
   that the GATWRAP bit was indeed the first bit of the
   GATGEN field in the 05 Catalog Record!

Barry Merrill



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, May 26, 2016 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be a GVxx 
> but maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a 
> little differently.  

Re: Getting timely dump out of LE

[Bill Hitefield]

Have you tried the TRAP(OFF) parameter on the step? That usually works for me. 
You lose the LE formatted dump, but you do get the "standard" dump.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Wednesday, May 25, 2016 11:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

I was wondering if you looked in LOGREC to see if that recorded the first S0C4.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Don Poitras
Sent: Wednesday, 25 May 2016 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

I wouldn't think that more than one of the 0C4's in the system trace would 
match the PSW in the MCH control block. You can display time in the system 
trace by doing 'ip systrace time(local)'. For the wrapping issue... some 
version of z/OS allowed the system trace table size to be set much higher. I 
recently asked our guys to bump up to 12M and that seems to be working for now.

In article <2013103444541247.wa.ronmacraehotmail.co...@listserv.ua.edu> you 
wrote:
> Lizette,
>I can get the registers and PSW no problem.  The problem I have is 
> getting the TIME of the S0C4 so I can see which one is first.  So much 
> happens before LE gets round to taking a system dump that the z/OS trace has 
> wrapped and I can't tell which of the 6 S0C4 abends, on different TCBs, was 
> first. I don't think I can assume that the first to produce a CEE dump or the 
> first to produce a SYSMDUMP was the first as they seem to preempt each other.

> Anyway I got round the problem by slipping on the instruction that sets us up 
> to fail by setting a control block pointer to zero before any of the TCBs 
> S0C4ed.

> However it would have been nice to be able to tell the time of the S0C4s.

> Ron.

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Nims,Alva John (Al)]

I do not know if this will help, but at CBTTAPE.ORG FILE 929 has a REXX 
function that could be of use.

gds = REALNAME(the.gdg.name(+1))

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Thursday, May 26, 2016 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

catsearch just prints output in the order received from IGGCSI00.

I have confirmed that LOCATE resolves existing relative GDG references 
correctly.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, May 26, 2016 at 8:18 AM, John McKown 
wrote:

> On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
> 
> wrote:
>
> > John,
> >
> > Would this code account for a V01 - V99 ending in the GDG?
> > And would it handle the fact that the next GDG might not be a 
> > GVxx
> but
> > maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a 
> > little differently.  A -1 might not be what you think it might be.
> >
> > I think, there is some ambiguity regarding the correct chronological
> order
> > in the GVxx numbers over 9000.
> >
> > Lizette
> >
>
> ​Very good points. I don't know how catsearch works internally, so I 
> don't know how the output is ordered. My code assumes that the entries 
> are ordered correctly in that the "newest" is at the bottom (last 
> emitted), the "oldest" is at the top (first emitted), and each 
> generation is "in the proper order". The egrep stage could be changed 
> to accept other than V00 at the end by doing:​
>
> egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'
>
> ​I didn't think of that because in 35 years, I have _never_ seen 
> anything other than V00 at the end.​
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our 
> certitude.
>
> 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 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: Proper way to resolve existing GDG GnnnVnnn by relative reference

[J R]

"​I didn't think of that because in 35 years, I have _never_ seen anything
other than V00 at the end.​"

I looked into this a while back and, as far as I recall, only a single entry 
per generation can be cataloged within the GDG at any one time.  IE., if you 
catalog G1234V01, then G1234V00 is no longer a part of the GDG.  I becomes 
cataloged as a non-GDG dataset.  



From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Thursday, May 26, 2016 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be a GVxx but
> maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little
> differently.  A -1 might not be what you think it might be.
>
> I think, there is some ambiguity regarding the correct chronological order
> in the GVxx numbers over 9000.
>
> Lizette
>

​Very good points. I don't know how catsearch works internally, so I don't
know how the output is ordered. My code assumes that the entries are
ordered correctly in that the "newest" is at the bottom (last emitted), the
"oldest" is at the top (first emitted), and each generation is "in the
proper order". The egrep stage could be changed to accept other than V00 at
the end by doing:​

egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'

​I didn't think of that because in 35 years, I have _never_ seen anything
other than V00 at the end.​


--
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Kirk Wolf]

catsearch just prints output in the order received from IGGCSI00.

I have confirmed that LOCATE resolves existing relative GDG references
correctly.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, May 26, 2016 at 8:18 AM, John McKown 
wrote:

> On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
> wrote:
>
> > John,
> >
> > Would this code account for a V01 - V99 ending in the GDG?
> > And would it handle the fact that the next GDG might not be a GVxx
> but
> > maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little
> > differently.  A -1 might not be what you think it might be.
> >
> > I think, there is some ambiguity regarding the correct chronological
> order
> > in the GVxx numbers over 9000.
> >
> > Lizette
> >
>
> ​Very good points. I don't know how catsearch works internally, so I don't
> know how the output is ordered. My code assumes that the entries are
> ordered correctly in that the "newest" is at the bottom (last emitted), the
> "oldest" is at the top (first emitted), and each generation is "in the
> proper order". The egrep stage could be changed to accept other than V00 at
> the end by doing:​
>
> egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'
>
> ​I didn't think of that because in 35 years, I have _never_ seen anything
> other than V00 at the end.​
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
>
> 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[John McKown]

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be a GVxx but
> maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little
> differently.  A -1 might not be what you think it might be.
>
> I think, there is some ambiguity regarding the correct chronological order
> in the GVxx numbers over 9000.
>
> Lizette
>

​Very good points. I don't know how catsearch works internally, so I don't
know how the output is ordered. My code assumes that the entries are
ordered correctly in that the "newest" is at the bottom (last emitted), the
"oldest" is at the top (first emitted), and each generation is "in the
proper order". The egrep stage could be changed to accept other than V00 at
the end by doing:​

egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'

​I didn't think of that because in 35 years, I have _never_ seen anything
other than V00 at the end.​


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

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

How to Calculate %USED for PDSE?

[David S.]

[Also posted to the Linked-In "Mainframe Assembler Professionals" group at
http://linkd.in/1VjEST7 ]
I wrote a program to create a report of DASD usage by scanning the UCB
Table, then reading all the DSCBs from all the DASD Volumes for usage data
and summing by DSN. The output is essentially the same as a TSO
LMDINIT/LMDLIST sequence on each VOLSER, but runs a *lot* faster and is
*much* easier to manage. One of the items I calculate is %USED based on
DS1LSTAR as a percentage of the sum of all the extent values from all the
extents on all the allocated volumes. And for everything but PDSE, my
results are the same as LMDLIST, which I understand, since PDSEs don't use
DS1LSTAR.
Looking around the web, I see others coming up against this problem for at
least the last 10 years, but none have any proposed low-level coding
solution. There obviously *is* one, since facilities like ISPF 3.4 and
FDREPORT do it.

My best idea so far (which so far also isn't working) is to call LISTDSI...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a3a0/4.4.2 ...
using the IRXEXEC API:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/H1981605/APPENDIX1.F.1.2
 which the manuals suggest has some usage data for PDSEs I can then use to
do the calculation.
►z/OS 2.1 and up even returns SYSUSEDPERCENT:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/ldsi.htm
Any better suggestions??
http://www.fdr.com/pdf/itsf.pdf - Innovation Data Processing has been doing
it since at least 1992!
David Staudacher
co-mgr Mainframe Assembler Professionals group

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

Re: Video that might give you a chuckle

[van der Grijn, Bart (B)]

It's an interesting observation as I always chuckle when my American coworkers 
say parmlibe, or zee-OS iso zed-OS, ... The list goes on. 
Somehow we all know what we mean.
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Thursday, May 26, 2016 12:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Video that might give you a chuckle

There is a rebooks (?!) at 
http://www.redbooks.ibm.com/redpapers/abstracts/redp5358.html?Open
Watch the video and you might get a chuckle (IBM didn’t catch it???) 
The voice says parmlib not parmLIB .

Its interesting and should have been done ages ago with all the new suds 
enhancements. IBM you are a follow late on these enhancements.

Ed

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