Re: EAV bug or feature?

[Lizette Koehler]

Could you share the error message(s) you get?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pinnacle
> Sent: Monday, May 09, 2016 10:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EAV bug or feature?
> 
> FYI,
> 
> I allocated a non-SMS EAV on my system with 111300 cylinders.  I try to run
> three jobs with SPACE=(CYL,(1,5000),RLSE),DSNTYPE=LARGE.  The first job
> runs, the other two fail with IEF257I SPACE REQUESTED NOT AVAILABLE, on the
> EAV when it has 9 CYLS avail.  The allocation message indicates that it
> attempted allocation on the EAV.  If I single thread the jobs, no problem.  Is
> this a bug or a feature?  And no, I can't submit a PMR.
> 
> Regards,
> Tom Conley
> 

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

EAV bug or feature?

[Pinnacle]

FYI,

I allocated a non-SMS EAV on my system with 111300 cylinders.  I try to 
run three jobs with SPACE=(CYL,(1,5000),RLSE),DSNTYPE=LARGE.  The 
first job runs, the other two fail with IEF257I SPACE REQUESTED NOT 
AVAILABLE, on the EAV when it has 9 CYLS avail.  The allocation 
message indicates that it attempted allocation on the EAV.  If I single 
thread the jobs, no problem.  Is this a bug or a feature?  And no, I 
can't submit a PMR.


Regards,
Tom Conley

--
 



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

Re: SMP/E Feature?

[Paul Gilmartin]

On Mon, 9 May 2016 19:23:20 -0500, Edward Gould wrote:

>I will take a contrary due here.
>I never did trust SMPE with DDDEFS I always coded the JCL and I always know 
>what libraries were being used/updated. Its too easy to make mistakes with 
>DDEF’s (IMO). JCL is easy and straight forward in my opinion. Especially when 
>you have too many fingers in the pipes (i.e. trainee’s but I have seen seniors 
>screw up as well.
> 
With DDEEFS there's one chance to screw up: when you define the zones.
With JCL there's a chance to screw up with every job you submit.

That said, there are some things such as SMPPTFIN that may better be left to
JCL than to DDDEFs.

-- gil

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

Re: Using TYPE=MEMORY (or VIO?)

[Ted MacNEIL]

SYS IO is, I believe, the original name shipped for VIO.
A lot of shops added the 'new' since that's what was in the instructional books.

-teD
  Original Message  
From: Jesse 1 Robinson
Sent: Friday, May 6, 2016 13:01
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Using TYPE=MEMORY (or VIO?)

After stating flatly that we do not support VIO, I ran a test and learned 
otherwise. For sure we do not support the esoteric name 'VIO'. In my previous 
shop IIRC it was implemented as 'SYSVIO'. I don't know why the name change, but 
I would guess it's to avoid canned jobs from gobbling up paging space, although 
nothing would prevent someone from changing 'VIO' to a supported name. 

I see this in my test job, which seems to indicate that the data set really 
went to VIO:

IGD101I SMS ALLOCATED TO DDNAME (ALLOCVIO) 
DSN (SYS16127.T095147.RA000.ALLOCVIO.R0108161 ) 
STORCLAS (STANDARD) MGMTCLAS ( ) DATACLAS (STANDARD) 
VOL SER NOS= VIO 



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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 06, 2016 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Using TYPE=MEMORY (or VIO?)

On 2016-05-06, at 09:35, Jesse 1 Robinson wrote:
> 
> ... , be aware that some customers (like us) did away with VIO a long time 
> ago.
> 
Did they tend to preserve their VIO esoteric name?

Could you even count on the same esoteric name's existing even in all shops 
supporting VIO?

I sometimes distribute JCL using a JCL symbol for VIO.

-- gil

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

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

Re: SMP/E Feature?

[Edward Gould]

I will take a contrary due here.
I never did trust SMPE with DDDEFS I always coded the JCL and I always know 
what libraries were being used/updated. Its too easy to make mistakes with 
DDEF’s (IMO). JCL is easy and straight forward in my opinion. Especially when 
you have too many fingers in the pipes (i.e. trainee’s but I have seen seniors 
screw up as well.

Ed

> On May 5, 2016, at 6:16 PM, Andrew Rowley  
> wrote:
> 
> On 6/05/2016 8:11, Mark Zelden wrote:
>> 1) There is a DDDEF called .  It points to a DSN defined with DISP=SHR 
>> (no volser / unit).
>> 2) The SYSLIB concatenation includes DDNAME  (last in the concatenation, 
>> I didn't
>>   test a different order).
>> 3) At execution time DD  is overridden in the JCL to point to a 
>> different VOLSER than
>> the cataloged version.
>> 4) The data set used in the SYSLIB concatenation is the cataloged version, 
>> not the override.
> 
> I think it is the behaviour I would expect.
> I think the SYSLIB concatenation includes DDDEFs which specify datasets, not 
> DDNAMEs.
> 
> Overriding SMP/E DDDEFs via JCL always seemed to me like it was a bad thing 
> to do... I always felt that the SMP/E zones should contain all the 
> definitions for the installation. Overriding DDs seemed like a recipe for an 
> inconsistent installation if e.g. some people did the override and others 
> didn't, or if some overrides became out of date.
> 
> -- 
> Andrew Rowley
> Black Hill Software
> +61 413 302 386
> 
> --
> 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: GDG creation tracking

[Lizette Koehler]

If you know the GDGs you want to track, you can do this:

Using cbttape.org DAF utility.  You can read SMF data and get a report.

Once that is available you can write a process to just extract what you need.

I wrote a SAS pgm to do this and I have a cross reference for 
creation/read/delete of GDGs

Possibly MXG or MICS may have something available.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Monday, May 09, 2016 3:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: GDG creation tracking
> 
> Hello Group,
> 
> Is it possible to track the GDG creation, like which Job creates it , then to
> know the Jobs which the created GDG as inputs ?
> 
> Is there any third party tool that can help to accomplish the above task ?
> 
> Any suggestion that can help me on my research.
> 
> Jake

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

Re: Create a dynamic USSTAB with calls to REXX programs

[Elardus Engelbrecht]

Elardus Engelbrecht wrote:

>... because the 'suspended' applications need to be told NOT to try work with 
>that LU.

I should have added this little note, since I also mentioned Netview Access 
Services.

Netview Access Services will keep all active LUs in memory and refresh your 
emulators screen when you bring your application in the front.

But I would like if there is something like 'dynamic USSTAB with calls to REXX 
programs'. [1]

Groete / Greetings
Elardus Engelbrecht

[1] - In ancient years it was my job to maintain those TAF (Terminal Assume 
Facility) things in Netview (Not Netview Access Services) and Netview also 
drives a nice version of REXX for 1001 things. Cumbersome, but it worked.

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

Re: Create a dynamic USSTAB with calls to REXX programs

[Elardus Engelbrecht]

Diego Fdez. Garcia wrote:

>Q.1) I need create an USSTAB where you can move the screen forward and screen 
>backward. For example, using the Function Keys: PFK8 and PFK7. 

Within the same application? Or do you need to swap your LU from one 
application to another?

If so for second question, I see problems with the application (not with VTAM 
and USSTAB), because the 'suspended' applications need to be told NOT to try 
work with that LU.


>It would be possible create this type of dynamic USSTAB...?

That would be nice, but to overcome that limit, we use several screens (Each 
with their own LU) in an emulator.

Dana Mitchell mentioned a single product, which, AFAIK, is similar to Netview 
Access Services.

But Netview Access maintains a different LU for each application in its menu.

Groete / Greetings
Elardus Engelbrecht

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

Re: Create a dynamic USSTAB with calls to REXX programs

[Dana Mitchell]

On Sun, 8 May 2016 17:20:17 +0200, Diego Fdez. Garcia 
 wrote:

>Hi, all
>
>It would be possible create a dynamic USSTAB...?
>I'm try explain the motive of this question:
>
>Q.1) I need create an USSTAB where you can move the screen forward and
>screen backward. For example, using the Function Keys: PFK8 and PFK7.
>It would be possible create this type of dynamic USSTAB...?
>
>Q.2) It would be possible to run/execute a REXX or System Command when an
>user select one of the options of this 'new' dynamic USSTAB...?
>

I'm quite sure native USSTAB processing wouldn't have any way to do that.  One 
solution we've use in the (very distant) past was a vtam application that it's 
only purpose was to present a configurable menu,  the old !Candle product 
called Cl/Menu.I don't know if IBM still markets this as part of the 
Cl/Supersession product line that was acquired by IBM from Candle.

Dana

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

Re: GDG creation tracking

[Mitch Mccluhan]

 The Docet and J-Man tools from RES (www.res-it.com) can do this quite easily.

Regards,

 

Mitch McCluhan
mitc...@aol.com

 

 

-Original Message-
From: Jake Anderson 
To: IBM-MAIN 
Sent: Mon, May 9, 2016 5:29 am
Subject: GDG creation tracking

Hello Group,

Is it possible to track the GDG creation, like which Job creates it , then
to know the Jobs which the created GDG as inputs ?

Is there any third party tool that can help to accomplish the above task ?

Any suggestion that can help me on my research.

Jake

--
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: Connectivity problem...

[Rob Schramm]

There are additional diagnostic codes available with telnet.  SSH can also
produce more diagnostic with -v or -vv.  But with both of them
disconnecting, the VPN config is looking pretty good as a culprit.  Most
VPN clients have the ability to enable tracing / logging.  Even the Cisco
client that downloads, has a settings config.

Rob Schramm

On Mon, May 9, 2016, 7:41 AM Robin Atwood  wrote:

> Is the ServerAlive parameter set in the SSH server or PuTTY? It should be
> > 0, otherwise you get inactivity timeouts.
>
> Robin
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sean Gleann
> Sent: 09 May 2016 17:07
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Connectivity problem...
>
> A wide-open subject line, but networking is not my strong point,
> unfortunately.
>
> I'm looking for some help regarding an intermittent communication failure
> on our z/OS 1.13 system.
>
> We use PuTTY to create a tunnelled connection to TN3270, and PCOMM to
> provide the 3270 emulation.
> When using, say, TSO, on the PCOMM panel, everything appears to be going
> well, until it simply... dies.
> I get to the point of hitting ENTER or PFnn for whatever reason, and I am
> presented  with a the 'X clock' symbols in the status area, followed by a
> disconnect some short while (< 1  minute) later.
>
> At the time of that disconnect, the PuTTY connection fails also (which
> would be the reason for the PCOMM failure). PuTTY throws up a message box
> saying "Network error: Software caused connection abort" which means
> precisely nothing to me.
> From there, it is possible to use PuTTY's 'Restart Session' option, and
> then PCOMM's 'Connect' option to get things moving again, until the time of
> the next failure.
>
> There's nothing showing up on the SYSLOG, and I can't think of anywhere
> else I might look for more/better info.
> There doesn't seem to be any pattern to the failure events in terms of
> time-of-day or system loading. It just ... stops.
>
> For what it's worth, z/OS system is hosted by the Dallas Innovation
> Center, and we've recently tried to put the system on a VPN - which is when
> all this trouble started.
> I'm trying to get SNMP working in the hope that I can get more info, but
> *that* is probably going to be the subject of an upcoming thread...
>
> Can anyone point me in the direction of further diagnostics at all, please?
> Any help would be much appreciated.
>
> Sean
>
> --
> 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
>
-- 

Rob Schramm
The Art of Mainframe, Inc

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

Re: Connectivity problem...

[Robin Atwood]

Is the ServerAlive parameter set in the SSH server or PuTTY? It should be > 0, 
otherwise you get inactivity timeouts.

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sean Gleann
Sent: 09 May 2016 17:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Connectivity problem...

A wide-open subject line, but networking is not my strong point, unfortunately.

I'm looking for some help regarding an intermittent communication failure on 
our z/OS 1.13 system.

We use PuTTY to create a tunnelled connection to TN3270, and PCOMM to provide 
the 3270 emulation.
When using, say, TSO, on the PCOMM panel, everything appears to be going well, 
until it simply... dies.
I get to the point of hitting ENTER or PFnn for whatever reason, and I am 
presented  with a the 'X clock' symbols in the status area, followed by a 
disconnect some short while (< 1  minute) later.

At the time of that disconnect, the PuTTY connection fails also (which would be 
the reason for the PCOMM failure). PuTTY throws up a message box saying 
"Network error: Software caused connection abort" which means precisely nothing 
to me.
>From there, it is possible to use PuTTY's 'Restart Session' option, and then 
>PCOMM's 'Connect' option to get things moving again, until the time of the 
>next failure.

There's nothing showing up on the SYSLOG, and I can't think of anywhere else I 
might look for more/better info.
There doesn't seem to be any pattern to the failure events in terms of 
time-of-day or system loading. It just ... stops.

For what it's worth, z/OS system is hosted by the Dallas Innovation Center, and 
we've recently tried to put the system on a VPN - which is when all this 
trouble started.
I'm trying to get SNMP working in the hope that I can get more info, but
*that* is probably going to be the subject of an upcoming thread...

Can anyone point me in the direction of further diagnostics at all, please?
Any help would be much appreciated.

Sean

--
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: GDG creation tracking

[Elardus Engelbrecht]

Jake Anderson wrote:

>Is it possible to track the GDG creation, like which Job creates it , then to 
>know the Jobs which the created GDG as inputs ?

Yes. SMF records 60, 61, 80 for Define and Catalog events. (That is if you 
previously activated AUDIT(ALL(READ)) for that covering profile and you defined 
that profile properly.)

PS: There are possible other SMF records, but the above 3 should get you a 
start.


>Is there any third party tool that can help to accomplish the above task ?

There are many tools. Check IBM-MAIN archives. There is also a freebie 
available: DAF


>Any suggestion that can help me on my research.

Perhaps you can post your question on RACF-L.

Groete / Greetings
Elardus Engelbrecht

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

GDG creation tracking

[Jake Anderson]

Hello Group,

Is it possible to track the GDG creation, like which Job creates it , then
to know the Jobs which the created GDG as inputs ?

Is there any third party tool that can help to accomplish the above task ?

Any suggestion that can help me on my research.

Jake

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

Connectivity problem...

[Sean Gleann]

A wide-open subject line, but networking is not my strong point,
unfortunately.

I'm looking for some help regarding an intermittent communication failure
on our z/OS 1.13 system.

We use PuTTY to create a tunnelled connection to TN3270, and PCOMM to
provide the 3270 emulation.
When using, say, TSO, on the PCOMM panel, everything appears to be going
well, until it simply... dies.
I get to the point of hitting ENTER or PFnn for whatever reason, and I am
presented  with a the 'X clock' symbols in the status area, followed by a
disconnect some short while (< 1  minute) later.

At the time of that disconnect, the PuTTY connection fails also (which
would be the reason for the PCOMM failure). PuTTY throws up a message box
saying "Network error: Software caused connection abort" which means
precisely nothing to me.
>From there, it is possible to use PuTTY's 'Restart Session' option, and
then PCOMM's 'Connect' option to get things moving again, until the time of
the next failure.

There's nothing showing up on the SYSLOG, and I can't think of anywhere
else I might look for more/better info.
There doesn't seem to be any pattern to the failure events in terms of
time-of-day or system loading. It just ... stops.

For what it's worth, z/OS system is hosted by the Dallas Innovation Center,
and we've recently tried to put the system on a VPN - which is when all
this trouble started.
I'm trying to get SNMP working in the hope that I can get more info, but
*that* is probably going to be the subject of an upcoming thread...

Can anyone point me in the direction of further diagnostics at all, please?
Any help would be much appreciated.

Sean

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