Re: Soft Capping

[Anthony Thompson]

CVT + x'25C' = address of RMCT (SRM control table)
RMCT + x'E4' = address of RCT (SRM resource control table)
RCT + x'C4' = RCTLACS (4 bytes, unsigned, long-term no. Of MSU's consumed by 
LPAR) 
RCT + x'1C' = RCTIMGW (4 bytes, unsigned, no. of MSU's available to LPAR)

If RCTLACS > RCTIMGWU, the LPAR is soft-capped (if they're equal, may be 
hard-capped, may be soft-capped, might just be busy).

SYSEVENT REQLPDAT returns the same information in fields LPDATAVGIMGSERVICE and 
LPDATIMGCAPACITY, as I think you've figured out. 

Ant.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, 29 June 2016 10:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks



--
This e-mail message has been scanned and cleared by Google Message Security and 
the UNICOM Global security systems. This message is for the named person's use 
only. If you receive this message in error, please delete it and notify the 
sender. 

--
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: Multithreaded output to stderr and stdout

[Paul Gilmartin]

On Wed, 29 Jun 2016 16:07:05 -0500, Kirk Wolf wrote:

>When using two Unix threads in the same z/OS Unix process, operations to
>sdout/stderr are serialized.
>
>Are you certain that these are two threads in the same process rather than
>threads in different processes (which would be at least separate LE
>enclaves, and perhaps different address spaces) ?
> 
This may also depend on settings such as:
if ( 1 )  { /* Try also with _IONBUF, _IOLBF, IOFBF  */
if ( setvbuf( stdout, NULL, _IOLBF, 4096 ) ) perror( "stdout" );

I know that _IOLBF was broken in Enhanced ASCII mode a while back.
I reported it and IBM apparently fixed it.

(Is AST still available on an IBM Support site?)

-- gil

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

Re: Multithreaded output to stderr and stdout

[Farley, Peter x23353]

According to the OP these are Java threads, so it is whatever the JVM is using 
to multiplex threads.  Possibly Unix threads, possibly something else?  It 
depends on the JVM implementation, right?

But I'm just fishing here, since I am anything but a JVM expert.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Wednesday, June 29, 2016 5:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multithreaded output to stderr and stdout

When using two Unix threads in the same z/OS Unix process, operations to
sdout/stderr are serialized.

Are you certain that these are two threads in the same process rather than
threads in different processes (which would be at least separate LE
enclaves, and perhaps different address spaces) ?

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Multithreaded output to stderr and stdout

[J R]

Agreed. I just reread the OP and it's not clear if he's tried DSN=  .   I 
originally assumed he had. 

Sent from my iPhone

> On Jun 29, 2016, at 17:13, Clark Morris  wrote:
> 
> [Default] On 29 Jun 2016 12:37:05 -0700, in bit.listserv.ibm-main
> t...@harminc.net (Tony Harminc) wrote:
> 
>>> On 29 June 2016 at 14:00, John McKown  wrote:
>>> 
>>> I may be blowing smoke here, if so I'm sure someone will point it out :-}.
>> 
>> I think you're on the right (write...?) track.
>> 
>> [...]
>>> A DD pointing to a sequential data set is _not_ designed to be
>>> written to by two different DCBs concurrently. What I do in this case is
>>> write to a UNIX file. Why? Because it works more like a JES2 sysout, which
>>> is subject of the next paragraph.
>>> 
>>> Now, with JES2 (or UNIX output), what happens? Well, it's more like a data
>>> base. You still have two DCBs, but the actual write sends the data to JES2
>>> and tells it to place it in the SPOOL file. So JES2 is accepting and
>>> interleaving the data for you. As JR said, this is like what would happen
>>> on a line printer.
>> 
>> I don't think this part is quite accurate... JES2 doesn't work like
>> HASP of old, where SYSOUT data was written to a virtual line printer,
>> line at a time.
> 
> I suspect that the problem is that STDOUT and STDERR are written to
> DSN=something at the customer site and that the poster would see the
> same result at his site, the difference being in how SYSOUT=something
> is handled as opposed DSN=something.
> 
> Clark Morris
>> 
>>> It would accept and print each line as it is generated
>>> and so would interleave the lines. This is also what happens with UNIX
>>> files. The data is not sent to the disk, but to the UNIX kernel which
>>> places it in a buffer and eventually writes it out. The UNIX kernel, like
>>> JES2, is maintaining a "unified buffer" architecture behind the scenes.
>> 
>> Well... When you use QSAM on a JES2 SYSOUT dataset, most of the
>> buffering is done locally in a so-called unprotected buffer. Only when
>> that buffer is filled does the access method PUT routine issue SVC 111
>> (or a more modern PC, iirc?) to copy the buffer to one owned by JES2,
>> which is eventaully written to disk. Those disk writes of blocks would
>> be centrally serialized, so that there would be no possibility of
>> overlaying already-written data. But it would mean that groups of
>> records would be interleaved rather than individual ones, and that
>> might or might not be easily discernible looking at the output.
>> 
>> What puzzles me in all this, though, is how it works fine at the
>> developer's site but not at the customer's. Could it be that there is
>> no blocking going on locally, but large(r) buffers are in use at the
>> customer site?
>> 
>> Tony H.
>> 
>> --
>> 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: Multithreaded output to stderr and stdout

[Clark Morris]

[Default] On 29 Jun 2016 12:37:05 -0700, in bit.listserv.ibm-main
t...@harminc.net (Tony Harminc) wrote:

>On 29 June 2016 at 14:00, John McKown  wrote:
>
>> I may be blowing smoke here, if so I'm sure someone will point it out :-}.
>
>I think you're on the right (write...?) track.
>
>[...]
>>  A DD pointing to a sequential data set is _not_ designed to be
>> written to by two different DCBs concurrently. What I do in this case is
>> write to a UNIX file. Why? Because it works more like a JES2 sysout, which
>> is subject of the next paragraph.
>>
>> Now, with JES2 (or UNIX output), what happens? Well, it's more like a data
>> base. You still have two DCBs, but the actual write sends the data to JES2
>> and tells it to place it in the SPOOL file. So JES2 is accepting and
>> interleaving the data for you. As JR said, this is like what would happen
>> on a line printer.
>
>I don't think this part is quite accurate... JES2 doesn't work like
>HASP of old, where SYSOUT data was written to a virtual line printer,
>line at a time.

I suspect that the problem is that STDOUT and STDERR are written to
DSN=something at the customer site and that the poster would see the
same result at his site, the difference being in how SYSOUT=something
is handled as opposed DSN=something.

Clark Morris
>
>> It would accept and print each line as it is generated
>> and so would interleave the lines. This is also what happens with UNIX
>> files. The data is not sent to the disk, but to the UNIX kernel which
>> places it in a buffer and eventually writes it out. The UNIX kernel, like
>> JES2, is maintaining a "unified buffer" architecture behind the scenes.
>
>Well... When you use QSAM on a JES2 SYSOUT dataset, most of the
>buffering is done locally in a so-called unprotected buffer. Only when
>that buffer is filled does the access method PUT routine issue SVC 111
>(or a more modern PC, iirc?) to copy the buffer to one owned by JES2,
>which is eventaully written to disk. Those disk writes of blocks would
>be centrally serialized, so that there would be no possibility of
>overlaying already-written data. But it would mean that groups of
>records would be interleaved rather than individual ones, and that
>might or might not be easily discernible looking at the output.
>
>What puzzles me in all this, though, is how it works fine at the
>developer's site but not at the customer's. Could it be that there is
>no blocking going on locally, but large(r) buffers are in use at the
>customer site?
>
>Tony H.
>
>--
>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: Multithreaded output to stderr and stdout

[Kirk Wolf]

When using two Unix threads in the same z/OS Unix process, operations to
sdout/stderr are serialized.

Are you certain that these are two threads in the same process rather than
threads in different processes (which would be at least separate LE
enclaves, and perhaps different address spaces) ?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


>

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

Re: Multithreaded output to stderr and stdout

[Tony Harminc]

On 29 June 2016 at 14:00, John McKown  wrote:

> I may be blowing smoke here, if so I'm sure someone will point it out :-}.

I think you're on the right (write...?) track.

[...]
>  A DD pointing to a sequential data set is _not_ designed to be
> written to by two different DCBs concurrently. What I do in this case is
> write to a UNIX file. Why? Because it works more like a JES2 sysout, which
> is subject of the next paragraph.
>
> Now, with JES2 (or UNIX output), what happens? Well, it's more like a data
> base. You still have two DCBs, but the actual write sends the data to JES2
> and tells it to place it in the SPOOL file. So JES2 is accepting and
> interleaving the data for you. As JR said, this is like what would happen
> on a line printer.

I don't think this part is quite accurate... JES2 doesn't work like
HASP of old, where SYSOUT data was written to a virtual line printer,
line at a time.

> It would accept and print each line as it is generated
> and so would interleave the lines. This is also what happens with UNIX
> files. The data is not sent to the disk, but to the UNIX kernel which
> places it in a buffer and eventually writes it out. The UNIX kernel, like
> JES2, is maintaining a "unified buffer" architecture behind the scenes.

Well... When you use QSAM on a JES2 SYSOUT dataset, most of the
buffering is done locally in a so-called unprotected buffer. Only when
that buffer is filled does the access method PUT routine issue SVC 111
(or a more modern PC, iirc?) to copy the buffer to one owned by JES2,
which is eventaully written to disk. Those disk writes of blocks would
be centrally serialized, so that there would be no possibility of
overlaying already-written data. But it would mean that groups of
records would be interleaved rather than individual ones, and that
might or might not be easily discernible looking at the output.

What puzzles me in all this, though, is how it works fine at the
developer's site but not at the customer's. Could it be that there is
no blocking going on locally, but large(r) buffers are in use at the
customer site?

Tony H.

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

Re: Multithreaded output to stderr and stdout

[Farley, Peter x23353]

In the C/C++ Programmers Guide under Input and Output there is this note:

"Avoiding Undesirable Results when Using I/O

File serialization is not provided for different tasks attempting to access the 
same file. When a C/C++ application is run on one task, and the same 
application or another C/C++ application is run on a different task, any 
attempts for both applications to access the same file is the responsibility of 
the application."

So the question then becomes whether or not the multiple Java threads are 
running on a single TCB or on multiple TCB's.  Not being a JVM expert I don't 
know the answer to that question.

I'm AssUMing that your "native C library" is a JNI application, so a second 
question would be whether JNI applications are allowed/disallowed from being 
used in multiple threads at the same time.  Which is something a Java guru 
would need to tell you.

I know I'm only asking more questions here, but I suspect that going down those 
roads may lead you to better answers.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Knigge
Sent: Wednesday, June 29, 2016 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Multithreaded output to stderr and stdout

All,

I have a multithreaded Java application that writes to stdout (and
stderr) thru a native C library using fputc and fwrite. Now, at our site 
everything is all right with output to stderr and stdout from multiple threads.

At a customer site only output from the main thread is written to the "file" if 
the DD STDOUT (or STDERR) points to a MVS Data Set. All output from the other 
threads is discarded.

If the DD points to SYSOUT=* (instead of a MVS Data Set) the output from the 
threads is written to the "file" as expected

Does anyone have an idea why? LE370 settings are equal to the settings 
at our site...  Maybe a special SMS Setting?? I have no idea (and no 
access to the customer site)

Thank you,

Michael
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Multithreaded output to stderr and stdout

[John McKown]

On Wed, Jun 29, 2016 at 12:29 PM, Michael Knigge 
wrote:

> All,
>
> I have a multithreaded Java application that writes to stdout (and stderr)
> thru a native C library using fputc and fwrite. Now, at our site everything
> is all right with output to stderr and stdout from multiple threads.
>
> At a customer site only output from the main thread is written to the
> "file" if the DD STDOUT (or STDERR) points to a MVS Data Set. All output
> from the other threads is discarded.
>
> If the DD points to SYSOUT=* (instead of a MVS Data Set) the output from
> the threads is written to the "file" as expected
>
> Does anyone have an idea why? LE370 settings are equal to the settings at
> our site...  Maybe a special SMS Setting?? I have no idea (and no access to
> the customer site)
>

​I may be blowing smoke here, if so I'm sure someone will point it out :-}.
When you write to a data set, each fopen() creates and uses a _separate_
DCB. This means separate buffers with no coordinated write, so depending on
exactly what happens when (STDOUT is normally buffered, STDERR is normally
unbuffered), you can end up with the result you see because each DCB has a
different idea of "where to write next" into the data set. For example.
Suppose you write the 1st record to STDOUT. STDOUT output goes into the
buffer and the data "waits" there. The "write pointer" for STDOUT is still
at the beginning of the data set. You now write the 1st record to STDERR,
which has its own "write pointer" pointing to the beginning of the data
set. STDERR is unbuffered and so get written to disk immediately (more or
less). The STDERR write pointer in the DCB is "advanced". You write enough
output to STDOUT to fill the buffer. So it get written at the current
"write pointer", which is still at the front of the data set, overlaying
the STDERR output. Depending on how things go, this could eliminate all
STDERR output or sometime have parts of STDOUT partially overwritten by
STDERR. A DD pointing to a sequential data set is _not_ designed to be
written to by two different DCBs concurrently. What I do in this case is
write to a UNIX file. Why? Because it works more like a JES2 sysout, which
is subject of the next paragraph.

Now, with JES2 (or UNIX output), what happens? Well, it's more like a data
base. You still have two DCBs, but the actual write sends the data to JES2
and tells it to place it in the SPOOL file. So JES2 is accepting and
interleaving the data for you. As JR said, this is like what would happen
on a line printer. It would accept and print each line as it is generated
and so would interleave the lines. This is also what happens with UNIX
files. The data is not sent to the disk, but to the UNIX kernel which
places it in a buffer and eventually writes it out. The UNIX kernel, like
JES2, is maintaining a "unified buffer" architecture behind the scenes.



>
> Thank you,
>
> Michael
>
>

-- 
"Pessimism is a admirable quality in an engineer. Pessimistic people check
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

>From "Star Nomad" by Lindsay Buroker:

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: Multithreaded output to stderr and stdout

[J R]

Possibly fundamental difference between JES (simulating unit record) and DASD 
(probably blocked).  

Sent from my iPhone

> On Jun 29, 2016, at 13:30, Michael Knigge  wrote:
> 
> All,
> 
> 
> I have a multithreaded Java application that writes to stdout (and stderr) 
> thru a native C library using fputc and fwrite. Now, at our site everything 
> is all right with output to stderr and stdout from multiple threads.
> 
> 
> At a customer site only output from the main thread is written to the "file" 
> if the DD STDOUT (or STDERR) points to a MVS Data Set. All output from the 
> other threads is discarded.
> 
> 
> If the DD points to SYSOUT=* (instead of a MVS Data Set) the output from the 
> threads is written to the "file" as expected
> 
> 
> Does anyone have an idea why? LE370 settings are equal to the settings at our 
> site...  Maybe a special SMS Setting?? I have no idea (and no access to the 
> customer site)
> 
> 
> Thank you,
> 
> Michael
> 
> --
> 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

Multithreaded output to stderr and stdout

[Michael Knigge]

All,


I have a multithreaded Java application that writes to stdout (and 
stderr) thru a native C library using fputc and fwrite. Now, at our site 
everything is all right with output to stderr and stdout from multiple 
threads.



At a customer site only output from the main thread is written to the 
"file" if the DD STDOUT (or STDERR) points to a MVS Data Set. All output 
from the other threads is discarded.



If the DD points to SYSOUT=* (instead of a MVS Data Set) the output from 
the threads is written to the "file" as expected



Does anyone have an idea why? LE370 settings are equal to the settings 
at our site...  Maybe a special SMS Setting?? I have no idea (and no 
access to the customer site)



Thank you,

Michael

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

Re: JOB cards, procs, and TIOTs, o my!

[Rob Scott]

Phil

Note that most system software products that show "SDSF DA" style information 
will most likely NOT be using the TIOT for anything related to address space 
identity.

Jobnames typically come from ASSBJBNS/JBNI or from the pointers in 
ASCBJBNS/JBNI or from whatever ERBSMFI returns for type 79-1 records.

Step and proc names tend to come from various CSCB fields depending on address 
space type.

Rob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Wednesday, June 29, 2016 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JOB cards, procs, and TIOTs, o my!

Noticed something odd-ish. If you put a JOB card in a proc, the TIOT is 
populated differently, yet what SDSF;DA isn't quite what I'd expect. The 
behavior below has been observed on 1.12 and 2.1, all JES2.

That is, given a PROC called MYPROC, with no JOB card and a label of EXECIT on 
the EXEC PGM= card, doing S MYPROC shows:
JOBNAME  StepName ProcStep
MYPROC   MYPROC   EXECIT

So far so good. TIOCNJOB is MYPROC, TIOCSTPN (aka TIOCPSTN) is MYPROC.

Now instead we start it with S MYPROC.:
JOBNAME  StepName ProcStep
MYPROC    EXECIT

Also as expected. TIOCNJOB is MYPROC, TIOCSTPN (aka TIOCPSTN) is .


Now insert a JOB card with a jobname of HAMSTER and issue S MYPROC:
JOBNAME  StepName ProcStep
HAMSTER  HAMSTER  EXECIT

Now TIOCNJOB is HAMSTER (as expected) but TIOCSTPN (aka TIOCPSTN) is EXECIT.
Yet SDSF;DA doesn't seem to reflect that--so clearly it's compensating for this 
weird case.


Finally, start the version with the JOB card as S MYPROC.:
JOBNAME  StepName ProcStep
HAMSTER   EXECIT

Again, TIOCNJOB is HAMSTER but TIOCSTPN (aka TIOCPSTN) is EXECIT, and SDSF;DA 
shows the StepName as expected based on the Start command, but not based on 
TIOCSTPN/TIOCPSTN.


In all cases, TIOCJSTN -- the comment for which describes it as "8-BYTE JOBSTEP 
NAME FOR PROCS" -- seems to be blank.

Clearly SDSF is populating its list from a different set of blocks, which makes 
sense.

So my real point here is to articulate how inconsistent this is, and to ask 
three questions of the assembled wisdom:
1) Anyone know why TIOCJSTN is always blank, or perhaps a case where it isn't?
2) Can I determine programmatically whether the job is running as a job, as a 
proc, or as a proc with a JOB card?
3) Where can I find doc on what the effects are of adding a JOB card to a proc? 
(A customer did this, and while obviously I can ask him his reasons, I'd like 
to understand all the ramifications)

Thanks.

...phsiii

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 877.328.2932 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Datasets usage question

[Duc]

Thank you all
I 've downloaded DAF from cbttape, have some errors to compile the assembler , 
but it should be ok

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

JOB cards, procs, and TIOTs, o my!

[Phil Smith III]

Noticed something odd-ish. If you put a JOB card in a proc, the TIOT is
populated differently, yet what SDSF;DA isn't quite what I'd expect. The
behavior below has been observed on 1.12 and 2.1, all JES2.

That is, given a PROC called MYPROC, with no JOB card and a label of EXECIT
on the EXEC PGM= card, doing S MYPROC shows:
JOBNAME  StepName ProcStep
MYPROC   MYPROC   EXECIT

So far so good. TIOCNJOB is MYPROC, TIOCSTPN (aka TIOCPSTN) is MYPROC.

Now instead we start it with S MYPROC.:
JOBNAME  StepName ProcStep
MYPROC    EXECIT

Also as expected. TIOCNJOB is MYPROC, TIOCSTPN (aka TIOCPSTN) is .


Now insert a JOB card with a jobname of HAMSTER and issue S MYPROC:
JOBNAME  StepName ProcStep
HAMSTER  HAMSTER  EXECIT

Now TIOCNJOB is HAMSTER (as expected) but TIOCSTPN (aka TIOCPSTN) is EXECIT.
Yet SDSF;DA doesn't seem to reflect that--so clearly it's compensating for
this weird case.


Finally, start the version with the JOB card as S MYPROC.:
JOBNAME  StepName ProcStep
HAMSTER   EXECIT

Again, TIOCNJOB is HAMSTER but TIOCSTPN (aka TIOCPSTN) is EXECIT, and
SDSF;DA shows the StepName as expected based on the Start command, but not
based on TIOCSTPN/TIOCPSTN.


In all cases, TIOCJSTN -- the comment for which describes it as "8-BYTE
JOBSTEP NAME FOR PROCS" -- seems to be blank.

Clearly SDSF is populating its list from a different set of blocks, which
makes sense.

So my real point here is to articulate how inconsistent this is, and to ask
three questions of the assembled wisdom:
1) Anyone know why TIOCJSTN is always blank, or perhaps a case where it
isn't?
2) Can I determine programmatically whether the job is running as a job, as
a proc, or as a proc with a JOB card?
3) Where can I find doc on what the effects are of adding a JOB card to a
proc? (A customer did this, and while obviously I can ask him his reasons,
I'd like to understand all the ramifications)

Thanks.

...phsiii

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

FW: HMC automation

[Neil Duffee]

ooops... forgot to include the group in the reply.

Small update from yesterday's digest reading:  you *can* reduce the individual 
CP MSUs when adding processors. The restriction, as others have indicated, is 
the reduction cannot be less than the purchased BASE ie. for our z12BC, 
K02->G04 (or some such mythical setting).  

>  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: Neil Duffee 
Sent: June 28, 2016 11:33
To: 'McElhaney, Robert'
Subject: RE: HMC automation

Caveat:  during daily digestion, responses are implicitly delayed.

Robert: OOCoD might not achieve what you'd like.  For us, OOCoD is charged in 1 
day increments.  In your case, you'd pay for the whole day even tho' you only 
turn OOCoD on overnight/during the day. 

Your contract may vary...

-Original Message-
From: McElhaney, Robert [mailto:rob...mc...@ato...net]
Sent: June 27, 2016 14:50
Subject: Re: HMC automation

Yes you are right. We will need OOCoD. Not been there. Not done that. I will 
look into it. Thanks!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Lowe
Sent: Monday, June 27, 2016 12:59 PM
Subject: Re: HMC automation

Are you sure you are wanting CBU and not OOCoD? CBU is usually valid for 10 day 
test periods at a time for D/R tests before it becomes 'real'. For OOCoD, we 
make use of Capacity Provisioning Manager (which is part of zOS base) and then 
use our automation product to issue Capacity Provisioning Manager commands to 
change up/down our capacity markers. By using a combination of automation and 
CPM, you could accomplish what you want without much difficulty.

On Mon, 27 Jun 2016 10:45:24 -0500, Robert McElhaney  
wrote:

>I want to investigate CBU turn up for 2964-502 to 2964-407. I may want to do 
>this nightly. [snip] not for disaster recovery exercise. This would be a 
>steady state activity.


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

Re: Request for confirmation of an RCF

[Van Eck, James: Absa]

 


Regards,
James van Eck | Vc4u | Centre of Excellence for Managed Services | Technology 
Enablement | Africa Technology 
Tel: +27 (0)11 444 3935 | Email: jame...@absa.co.za

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, June 27, 2016 2:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for confirmation of an RCF

 IARV64 REQUEST=DETACH,+
   MEMOBJSTART=AV_RArea64, +
   V64COMMON=YES,  +
   COND=YES,   +
   MF=(E,IARV64L,COMPLETE)  
 8, "AFFINITY=" DOES NOT ALLOW THE USE OF THE FOLLOWING KEY(S) "V64X01-IARV6
   COMMON".

I now of course know that omitting AFFINITY=SYSTEM was an error on my part,
but the quoted documentation "64-Bit Common memory objects are not affected
by AFFINITY=LOCAL" led me to believe that AFFINITY=LOCAL, the default, was
irrelevant. (That's the point of my proposed RFC.)

(I might also add that the phrasing of the MNOTE is less than a model of
clarity.)

It's a common memory object -- does that answer the question?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, June 26, 2016 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for confirmation of an RCF

>I just got an MNOTE on a nIARV64 macro assembly. I

It would have been helpful to have seen the actual invocation and the actual
MNOTE, as well as information about what kind of memory object you were
actually trying to detach.

None of the following invocations gets an MNOTE:
 iarv64 request=DETACH,memobjstart=(2) 
 iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL 
 iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL,owner=NO 
 iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL,owner=YES 
 iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL,owner=YES*
   ,ttoken=(4) 
 iarv64 request=DETACH,memobjstart=(2),affinity=SYSTEM,*
   v64common=NO 
 iarv64 request=DETACH,memobjstart=(2),affinity=SYSTEM,*
   v64common=YES 

Nor did anything else that I tried with syntactically correct use of the
other operands of request=DETACH.

In general, I'm quite sure that your suggested update is wrong. You do not
syntactically always need to specify AFFINITY=SYSTEM on REQUEST=DETACH.
I would not be surprised if semantically there are such cases (but those
would be represented by return/reason codes or abend/abendreason codes from
the service, not by MNOTEs from the macro).

So perhaps you could start over with what went wrong?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Important Notice:
Absa is an Authorised Financial Services Provider and Registered Credit 
Provider, 
registration number: NCRCP7. This e-mail and any files transmitted with it may 
contain information that is confidential, privileged or otherwise protected 
from 
disclosure. If you are not an intended recipient of this e-mail, do not 
duplicate 
or redistribute it by any means. Please delete it and any attachments and 
notify 
the sender that you have received it in error. Unless specifically indicated, 
this 
e-mail is not an offer to buy or sell or a solicitation to buy or sell any 
securities, 
investment products or other financial product or service, an official 
confirmation of 
any transaction, or an official statement of Absa. Any views or opinions 
presented 
are solely those of the author and do not necessarily represent those of Absa. 
This e-mail is subject to terms available at the following link: 
http://www.absa.co.za/disclaimer. 
The Disclaimer forms part of the content of this email. If you are unable to 
access 
the Disclaimer, send a blank e-mail to disclai...@absa.co.za and we will send 
you a 
copy of the Disclaimer. By messaging with Absa you consent to the foregoing. 
By emailing Absa you consent to the terms herein. This email may relate to or 
be sent 
from other members of the Absa Group.

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

Re: Soft Capping

[Steve Austin]

Thanks "SYSEVENT REQLPDAT" looks promising.

Steve


Steve Austin
Product Architect
Macro 4 Limited
d: +44 1293 872261 | t: +44 1293 872000 | www.macro4.com

     

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Craig Pace
Sent: 29 June 2016 15:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

Look at your rolling 4-hour average vs your MSUs used.  If Softcap is in place, 
you can see spikes that go above the 4-hour average for the true MSUs used if 
you are hitting capacity.  If you have a hardcap, then you will never go over 
your configured capacity.  Of course, this is post processing and only after 
you have hit the capacity limit.  I'm not aware of a way to tell up front.

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

Thanks, I've taken a look and IPLINFO appears to be able to infer when a soft 
cap is in effect. However I did not phrase my question very well. What I'd 
really like to determine is whether the image capacity figure is from a soft 
cap or a hard cap, regardless of whether a cap is in effect.

Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: 29 June 2016 14:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

I think Mark Zelden's IPLINFO has that capability, but my system doesn't use 
capping so I cannot see it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

--
This e-mail message has been scanned and cleared by Google Message Security and 
the UNICOM Global security systems. This message is for the named person's use 
only. If you receive this message in error, please delete it and notify the 
sender.

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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

---

Re: Soft Capping

[Craig Pace]

Look at your rolling 4-hour average vs your MSUs used.  If Softcap is in place, 
you can see spikes that go above the 4-hour average for the true MSUs used if 
you are hitting capacity.  If you have a hardcap, then you will never go over 
your configured capacity.  Of course, this is post processing and only after 
you have hit the capacity limit.  I'm not aware of a way to tell up front.

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

Thanks, I've taken a look and IPLINFO appears to be able to infer when a soft 
cap is in effect. However I did not phrase my question very well. What I'd 
really like to determine is whether the image capacity figure is from a soft 
cap or a hard cap, regardless of whether a cap is in effect.

Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: 29 June 2016 14:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

I think Mark Zelden's IPLINFO has that capability, but my system doesn't use 
capping so I cannot see it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

--
This e-mail message has been scanned and cleared by Google Message Security and 
the UNICOM Global security systems. This message is for the named person's use 
only. If you receive this message in error, please delete it and notify the 
sender.

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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

Re: Soft Capping

[Richards, Robert B.]

For Group Capacity, RMF III will show you the name of the group and the limit 
being enforced.

Select 1-OVERVIEW, then 3-CPC. Look for the following (ignore values, they are 
made up):

Partition:   LPTEST  Model 999
CPC Capacity: 999   Weight % of Max:    4h Avg:   90   Group: GROUPT
Image Capacity:   800   WLM Capping %:0.0   4h Max:   99   Limit:   777
MT Mode IIP:  N/A   Prod % IIP:   N/A

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

Thanks, I've taken a look and IPLINFO appears to be able to infer when a soft 
cap is in effect. However I did not phrase my question very well. What I'd 
really like to determine is whether the image capacity figure is from a soft 
cap or a hard cap, regardless of whether a cap is in effect.

Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: 29 June 2016 14:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

I think Mark Zelden's IPLINFO has that capability, but my system doesn't use 
capping so I cannot see it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

--
This e-mail message has been scanned and cleared by Google Message Security and 
the UNICOM Global security systems. This message is for the named person's use 
only. If you receive this message in error, please delete it and notify the 
sender.

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

[Steve Austin]

Thanks, I've taken a look and IPLINFO appears to be able to infer when a soft 
cap is in effect. However I did not phrase my question very well. What I'd 
really like to determine is whether the image capacity figure is from a soft 
cap or a hard cap, regardless of whether a cap is in effect. 

Steve


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: 29 June 2016 14:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Soft Capping

I think Mark Zelden's IPLINFO has that capability, but my system doesn't use 
capping so I cannot see it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: Soft Capping

[Farley, Peter x23353]

I think Mark Zelden's IPLINFO has that capability, but my system doesn't use 
capping so I cannot see it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, June 29, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Soft Capping

[Steve Austin]

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks



-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: Possible RFE: OMVS PDS-member serialization?

[Kirk Wolf]

I agree!   I would definitely vote for this RFE.

I believe that an RFE that I created last year does overlap or possibly
address this.
Please take a look and vote for it if you agree that we need better PDS /
PDSE support in the IBM C Library:

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=80811

===
The z/OS C library has poor support for PDS and PDS/E.

Specifically, when using fopen() to read or write members, there are no
facilities to:

1) obtain existing user directory entry info (read and write)
2) update user directory info (write)
3) support for DISP=SHR plus ISPF Enqueue serialization

The first two of these cannot be easily worked around by user code without
completely abandoning the use of the C-library for I/O.

==

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, Jun 29, 2016 at 7:33 AM, John McKown 
wrote:

> Gil,
>
> IMO, that is a wonderful idea. I especially endorse the latter idea of
> enhancing the C runtime fopen() as a generalized way to introduce this
> ability to _any_ C language code which uses fopen(). Just thinking about
> it, I think this code be done most compatibly by introducing a new keyword
> parameter for the "mode". Perhaps something like:
> "enq=shr|old|rispf|wispf". Hopefully the first two are obvious. The "rispf"
> says use DISP=SHR to allocate and issue a ISPF  compatible ENQ "shared" on
> the data set plus member (if specified in the filename parameter)  whereas
> "wispf" says use DISP=SHR to allocate and issue an ISPF compatible write
> enq on the data set + member (if specified).
>
> It might even be nice to have a C runtime configuration parameter which
> indicate what this default fopen() enque is.
>
> On Tue, Jun 28, 2016 at 5:27 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Would there be much support for an RFE like this?  (Would
> > it be a duplicate -- the idea seems obvious?)  Any
> > suggested changes or paraphrases or clearer terminology?
> >
> > Enhance OMVS "cp" and other utilities to employ ISPF-like
> > member-level serialization.  This would allow OMVS to update
> > PDS libraries that are othewise allocated SHR.  For example:
> >
> > I'm editing CLIST(FOO) with z/OS ISPF Edit.  From a Solaris NFS
> > client, I try:
> >
> > user@SunOS.5.11: cd clist
> > user@SunOS.5.11: date >foo
> > ksh: foo: cannot create [Permission denied]
> >
> > ( ... which really means "data set in use".)  So I CANcel my
> > Edit session, then:
> >
> > user@SunOS.5.11: date >foo  # Succeeds!
> >
> > NFS appears to be using ISPF serialization with member granularity.
> > In my experience, FTP Server does likewise.
> >
> > Now, from z/OS UNIX System services:
> >
> > user@OS/390.25.00: date | cp /dev/fd/0 "//CLIST(foo)"
> > cp: FSUM6259 target file "//CLIST(foo)": EDC5061I An error occurred
> > when attempting to define a file to the system.
> >
> > ... CLIST is allocated; member is not in use, but "cp" doesn't know any
> > better.
> > I log off TSO, then:
> >
> > user@OS/390.25.00: date | cp /dev/fd/0 "//CLIST(foo)"  # Succeeds!
> >
> > It's an undue burden to need to log off in order to update with OMVS
> > data sets that are allocated in TSO LOGON PROC.  OMVS should use
> > the techniques that NFS and FTP use.
> >
> > If the restriction is intrinsic to the "C" Runtime, consider this
> > an RFE on "C".  So much the better to have a broader solution.
> >
> > Thanks,
> > gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> "Pessimism is a admirable quality in an engineer. Pessimistic people check
> their work three times, because they're sure that something won't be right.
> Optimistic people check once, trust in Solis-de to keep the ship safe, then
> blow everyone up."
> "I think you're mistaking the word optimistic for inept."
> "They've got a similar ring to my ear."
>
> From "Star Nomad" by Lindsay Buroker:
>
> 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: Possible RFE: OMVS PDS-member serialization?

[John McKown]

Gil,

IMO, that is a wonderful idea. I especially endorse the latter idea of
enhancing the C runtime fopen() as a generalized way to introduce this
ability to _any_ C language code which uses fopen(). Just thinking about
it, I think this code be done most compatibly by introducing a new keyword
parameter for the "mode". Perhaps something like:
"enq=shr|old|rispf|wispf". Hopefully the first two are obvious. The "rispf"
says use DISP=SHR to allocate and issue a ISPF  compatible ENQ "shared" on
the data set plus member (if specified in the filename parameter)  whereas
"wispf" says use DISP=SHR to allocate and issue an ISPF compatible write
enq on the data set + member (if specified).

It might even be nice to have a C runtime configuration parameter which
indicate what this default fopen() enque is.

On Tue, Jun 28, 2016 at 5:27 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> Would there be much support for an RFE like this?  (Would
> it be a duplicate -- the idea seems obvious?)  Any
> suggested changes or paraphrases or clearer terminology?
>
> Enhance OMVS "cp" and other utilities to employ ISPF-like
> member-level serialization.  This would allow OMVS to update
> PDS libraries that are othewise allocated SHR.  For example:
>
> I'm editing CLIST(FOO) with z/OS ISPF Edit.  From a Solaris NFS
> client, I try:
>
> user@SunOS.5.11: cd clist
> user@SunOS.5.11: date >foo
> ksh: foo: cannot create [Permission denied]
>
> ( ... which really means "data set in use".)  So I CANcel my
> Edit session, then:
>
> user@SunOS.5.11: date >foo  # Succeeds!
>
> NFS appears to be using ISPF serialization with member granularity.
> In my experience, FTP Server does likewise.
>
> Now, from z/OS UNIX System services:
>
> user@OS/390.25.00: date | cp /dev/fd/0 "//CLIST(foo)"
> cp: FSUM6259 target file "//CLIST(foo)": EDC5061I An error occurred
> when attempting to define a file to the system.
>
> ... CLIST is allocated; member is not in use, but "cp" doesn't know any
> better.
> I log off TSO, then:
>
> user@OS/390.25.00: date | cp /dev/fd/0 "//CLIST(foo)"  # Succeeds!
>
> It's an undue burden to need to log off in order to update with OMVS
> data sets that are allocated in TSO LOGON PROC.  OMVS should use
> the techniques that NFS and FTP use.
>
> If the restriction is intrinsic to the "C" Runtime, consider this
> an RFE on "C".  So much the better to have a broader solution.
>
> Thanks,
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Pessimism is a admirable quality in an engineer. Pessimistic people check
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

>From "Star Nomad" by Lindsay Buroker:

Maranatha! <><
John McKown

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

TSO TEST and SYSOUTTRAP/SYSOUTLINE

[Joseph Reichman]

Hi

Does any one know if capturing TEST output
Into CLIST variables is possible 


Thanks 

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

AW: Minimum Volume Sizes in the Wild

[Peter Hunkeler]

When I was with IBM Education, we used to run class labs on minimal z/OS 
(OS/390, MVS/...) systems as VM guests. The volumes were VM mini volumes just 
as large as needed. If VM is still the base for those labs, I'm pretty sure 
there still are volumes of various small sizes.

Not sure however if this matters for your query.

--Peter Hunkeler


>What is the *smallest* volume size everyone sees in general use?
 >
>For example, will we create any problems if we assume that "everyone"
>has or can define at least a 3390-9 size volume these days?  What if we
>chose 3390-27?



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

Re: Minimum Volume Sizes in the Wild

[R.S.]

W dniu 2016-06-28 o 18:19, John Eells pisze:

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if 
we chose 3390-27?



Application data volumes: mod27 or mod54 (no EAV yet)
System volumes: variety of models, including 3390-1, 3390-3, 3390-9. The 
smallest ones are used for JES2, checkpoints, sysplex CDSes, MCAT, and 
RACF db's.

SYSRES and DLIB volumes: mod27.


--
Radoslaw Skorupka
Lodz, Poland






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

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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


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