z/VSE Connector Client

[Jack J. Woehr]

Is there any IBM program or ISV providing free access for z/VSE development?

This veteran of JTOpen and other remote APIs has just discovered the existence 
of the z/VSE Connector Client!

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

IBM Knowledge Center

[Jack J. Woehr]

As much thrash as has been throshen about the IBM Knowledge Center, it's an 
amazing resource.

All those mountains of documentation at the fingertips of those of us who'd usually rather read up on IBM business 
systems than great world literature.


I find myself reading the Knowledge Center for hours every day.

People used to have to pay for this stuff. I paid $10 for the 390 POPS once!

Thanks, IBM.

--
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: Broadcom is buying Brocade

[Edward Finnell]

It came out early last week on Bloomberg as a floater but not finalized.  
Others were mentioned in same Tech trends.
 
 
In a message dated 11/4/2016 6:38:35 P.M. Central Daylight Time,  
jesse1.robin...@sce.com writes:

I did  not see this mentioned on IBM  Main.


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

Broadcom is buying Brocade

[Jesse 1 Robinson]

I did not see this mentioned on IBM Main.

https://techcrunch.com/2016/11/02/broadcom-acquires-brocade-in-5-9-billion-deal/

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


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

Re: Friday cartoon on The Old Days

[John McKown]

On Fri, Nov 4, 2016 at 1:55 PM, Jack J. Woehr  wrote:

> http://xkcd.com/1755/


​Oh, how I miss them. sometimes.​


>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
>

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Friday cartoon on The Old Days

[Jack J. Woehr]

http://xkcd.com/1755/

--
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: ASG Zeke and time change

[Skeldum, William]

We use Zeke and have TZ=MST7MDT coded in the ENVIRON file.  I agree with 
Charles, no need to change it for the time change.  We do not cycle Zeke, IPL, 
or anything.  At 2:00 AM MDT Sunday morning the clock will revert to 1:00 AM 
MST.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, November 04, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASG Zeke and time change

I know nada about Zeke but you should not have to change the TZ specification 
(generally -- again I know nada about Zeke specifically). CST6CDT says 
(simplifying the details here) that your winter offset is UTC-6 and your summer 
offset is UTC-5.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Friday, November 04, 2016 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASG Zeke and time change

In Zeke there is an ENVIRON file that contains.



* TZ:

*   Time zone.  See your IBM Language Environment Customization

*   documentation for more information on how to set your time zone.

*TZ=CST5CDT  *

* spring is 5; fall is 6

* TZ=CST5CDT



This customer is in the Central Time Zone.

So for the time change it needs to be updated to TZ=CST6CDT



My question is –

When can I update this file?  Can I do it now and it will be picked up on the 
next IPL?  Or does Zeke look at this file all the time and I would have to wait 
until Zeke is taken down before the IPL?



Thank you to anyone with Zeke experience.


--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy 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: ASG Zeke and time change

[Charles Mills]

I know nada about Zeke but you should not have to change the TZ specification 
(generally -- again I know nada about Zeke specifically). CST6CDT says 
(simplifying the details here) that your winter offset is UTC-6 and your summer 
offset is UTC-5.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Friday, November 04, 2016 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASG Zeke and time change

In Zeke there is an ENVIRON file that contains.



* TZ:

*   Time zone.  See your IBM Language Environment Customization

*   documentation for more information on how to set your time zone.

*TZ=CST5CDT  *

* spring is 5; fall is 6

* TZ=CST5CDT



This customer is in the Central Time Zone.

So for the time change it needs to be updated to TZ=CST6CDT



My question is –

When can I update this file?  Can I do it now and it will be picked up on the 
next IPL?  Or does Zeke look at this file all the time and I would have to wait 
until Zeke is taken down before the IPL?



Thank you to anyone with Zeke experience.


--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

ASG Zeke and time change

[Mark Pace]

In Zeke there is an ENVIRON file that contains.



* TZ:

*   Time zone.  See your IBM Language Environment Customization

*   documentation for more information on how to set your time zone.

*TZ=CST5CDT  *

* spring is 5; fall is 6

* TZ=CST5CDT



This customer is in the Central Time Zone.

So for the time change it needs to be updated to TZ=CST6CDT



My question is –

When can I update this file?  Can I do it now and it will be picked up on
the next IPL?  Or does Zeke look at this file all the time and I would have
to wait until Zeke is taken down before the IPL?



Thank you to anyone with Zeke experience.


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

3592 J70

[Richard Pinion]

Does anyone know what the login information is for 
the 3592 J70 controller?  I have an old laptop connected
to the serial port on the J70.  I'm using NetTerm to
connect.  I get the AIX 3592 J70 login screen, but
that's as far as I can get.

Also, attempting to connect the 3592 via FICON
to a IBM z10.  I know zero to nothing about FC
addressing.  The display panel show PORT0 00 ?? C9 4.
I can get to the Fiber options set hardware address
panel, but have no idea how or what to put in.
The fiber cable  is plugged into port 1 of the J70
with the other end plugged into port 0 of the 3592.

Sorry for being an idiot on this matter.



_
Netscape.  Just the Net You Need.

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

Re: SQLCODE=-904 during RUN

[Janet Graff]

>Dropping any table required by a package will invalidate that package. And 
>creating a new table, even if it has the same name, will not right your 
>>package, because that new table is a _different_ object.

>Why not simply TRUNCATE your tables if you want to empty them out before your 
>test run?

>Cheers,

>Jantje.

Jan!

Thanks!  Replacement the DROP/CREATE with the TRUNCATE statement has allowed 
the process to complete succesfully!

Thank you so much!
Janet

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

More Knowledge Centre frustration

[Tony Harminc]

(Or Knowledge Center, I suppose)

Can it really be the case that the zArch Principles of Operation is
not there? Certainly there are links to various apparently arbitrary
levels of the PDF, but the content itself doesn't seem to be in there.
Here's a case where I'd like to take advantage of one feature of KC
that actually sounds useful, and provide a URL to a specific paragraph
in the POO to someone else to explain what I'm talking about, rather
than say "find the PDF and then navigate to the section called "blah",
and look down two paragraphs. No such luck, it seems.

As well, when I do a "product" search, it seems that no variation on
"system z", "z systems" or "z arch" finds anything remotely related to
the POO. And a general (not product) search on KC for the string
"z/architecture principles of operation" (which is the exact title of
the book) says "Your search query did not match any documents. Try
modifying the search keywords or filters.".

Come on, folks!

Tony H.

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

Re: SQLCODE=-904 during RUN

[Janet Graff]

>HI Janet,
>I noticed that the bind is binding DALLASA.DB2ZP.ZPDB2
>but the error is for DB2ZP.ZPDB2.1A320A2A009C519E.

>It looks like a mis-match between local and remote versions of the package.

>Regards,
> Ron

I've been looking for a way to have both the BIND and the RUN statements agree 
on the location of the package.

The BIND statement has this syntax

BIND PACKAGE__(_ ___ _.collection-id)__ _ 
_> |
   | |_location-name_|  
|_OWNER(authorization-id)_|   |

where I could specify a location-name on the collection id.  But DALLASA is the 
correct location so I don't need to change the BIND statement.


The RUN STATEMENT doesn't even specify a collection-id and has no syntax to 
specify the location

 | >>__RUN__ _PROGRAM(program-name)__ _ _ __> |
   |  ||_PLAN(plan-name)_| ||
   |  |_CP__PLAN(plan-name)||
   ||
   | >__ ___ __ _ ___>< |
   ||_LIBRARY(library-name)_|  |_PARMS(parameter-string)_|  |

So how do I get the RUN statement to use the right package?

Janet

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

Re: Question on TZ and European time change

[Paul Gilmartin]

On Fri, 4 Nov 2016 08:35:19 -0500, John McKown wrote:

>On Fri, Nov 4, 2016 at 7:57 AM, Charles Mills wrote:
>>
>> @John, is that true? This is a "mainframe" behavior, not a UNIX behavior?
>
>Well, I'll be dipped in . I just tested this on Linux
>and it works the same way as on z/OS (incorrectly, IMO). But if, on Linux,
>you use the "Olson" format for TZ (z/OS doesn't support this), you get the
>correct answer.
> 
Linux, Solaris, OS X, ... implement the "Olson" format (I believe that's
ICANN TZDATA) as a compatible extension to POSIX.

And Olson gives correct results for USA prior to 2006; POSIX doesn't.

I once went to SR on the absurd behavior that if TZ is unset it results
in UTC rather than a configurable local time.  Rejected; otherwise
would be incompatible with AIX.

-- gil

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

Re: MQ (6.0) "transaction log"?

[John McKown]

On Fri, Nov 4, 2016 at 9:36 AM, Scott Barry  wrote:

> Investigate activating MQ ACCOUNTING CLASS 3 to identify MQ task/queue
> activity, which will cause SMF type 116 data (could be a data-volume
> consideration though).  I recall even with MQ 6, there are some
> IBM-supplied decoding / reporting routines (identified as IBM SupportPac
> MP1B).  And there is still an IBM Redbook available as WebSphere MQ V6
> Fundamentals.
>
> Scott Barry
> SBBWorks, Inc.
>
>
​Thanks for the pointer. I'll get on it.​



-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

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: MQ (6.0) "transaction log"?

[Scott Barry]

Investigate activating MQ ACCOUNTING CLASS 3 to identify MQ task/queue 
activity, which will cause SMF type 116 data (could be a data-volume 
consideration though).  I recall even with MQ 6, there are some IBM-supplied 
decoding / reporting routines (identified as IBM SupportPac MP1B).  And there 
is still an IBM Redbook available as WebSphere MQ V6 Fundamentals.

Scott Barry
SBBWorks, Inc.

On Fri, 4 Nov 2016 07:18:03 -0500, John McKown  
wrote:

>Yes, I'm going off to research this myself right now. But I thought I might
>be some help from those experienced too. We use MQ Series 6.0 to talk to
>CICS/TS 4.1 on z/OS 1.13. Basically, we did some work with this years ago.
>Then it was decide not to continue to use it for any new development, but
>keep using it for what we had. We basically have gotten rid of all the
>people who knew anything (& did not document it). Now, as part of the
>"getting off of z/OS", management wants to know things like "who is using
>this?"; "what are they doing with it?"; "how heavily is it being used?".
>None of which is known by those few of us left.
>
>So, is there something (SMF?) which would tell us any of this? Not that we
>have any software which could be used to make a report (other than HLASM)
>because that was gotten rid of long ago as too expensive. Yes, I am a bit
>bitter.
>
>--
>Heisenberg may have been here.
>
>Unicode: http://xkcd.com/1726/
>
>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: Question on TZ and European time change

[Pew, Curtis G]

On Nov 4, 2016, at 8:35 AM, John McKown  wrote:
> 
> [tsh009@it-johnmckown-linux junk]$ TZ='Europe/Amsterdam' date
> Fri Nov  4 14:27:52 CET 2016
> [tsh009@it-johnmckown-linux junk]$ TZ=CET-1CEST date
> Fri Nov  4 15:29:05 CEST 2016

I got similar results on my Mac:

~  TZ='Europe/Amsterdam' date
Fri Nov  4 14:54:59 CET 2016
~  TZ=CET-1CEST date
Fri Nov  4 15:55:16 CEST 2016

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: Question on TZ and European time change

[John McKown]

On Fri, Nov 4, 2016 at 7:57 AM, Charles Mills  wrote:

> @Peter, thanks, interesting. I have tried to wrap my head around the exact
> meaning to the system of "CET" and similar strings (as opposed to their
> meaning as civil abbreviations).
>
> @John, is that true? This is a "mainframe" behavior, not a UNIX behavior?
>

Well, I'll be dipped in . I just tested this on Linux
and it works the same way as on z/OS (incorrectly, IMO). But if, on Linux,
you use the "Olson" format for TZ (z/OS doesn't support this), you get the
correct answer.

[tsh009@it-johnmckown-linux junk]$ TZ='Europe/Amsterdam' date
Fri Nov  4 14:27:52 CET 2016
[tsh009@it-johnmckown-linux junk]$ TZ=CET-1CEST date
Fri Nov  4 15:29:05 CEST 2016

Olson Timezone: https://en.wikipedia.org/wiki/Tz_database
​Olson time zones
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones​



> Charles
>
>

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

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: Question on TZ and European time change

[Charles Mills]

@Peter, thanks, interesting. I have tried to wrap my head around the exact 
meaning to the system of "CET" and similar strings (as opposed to their meaning 
as civil abbreviations).

@John, is that true? This is a "mainframe" behavior, not a UNIX behavior?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, November 04, 2016 4:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on TZ and European time change

On Fri, Nov 4, 2016 at 2:30 AM, Peter Hunkeler  wrote:



> And from the same description you can see that the actual strings 
> being used to name the standard and the DST periods (CET and CEST in 
> the example
> above) have no meaning to the system. You can set them to anything you 
> want without influencing the behaviour.
>
>
> The strings are only meant to show something meaningful to users.
>
>
> The first string is mandatory. The second string, in addition to be 
> meant for the user, is also a flag to tell the system to apply DST 
> according to the standard rules (mentione above), or by the rules specified.
>
>
> So, with
>
>
> TZ=WINTER-1SUMMER,M3.5.0/2:00,M10.5.0/3:00
> date '%a %b %e %T %Z %Y'
>
>
> will display
> Fr Nov 4 08:26:17 WINTER 2016
> today, but had displayed
> Fr Oct 28 08:26:17 SUMMER 2016
> last week.
>
>
> --Peter Hunkeler
>

​Another indication that, at least at the time this was done, IBM was not 
overly concerned with making z/OS UNIX be acceptable to the "real" UNIX 
community. They just wanted to stamp "POSIX compliant" on z/OS for marketing 
purposes. ​Aside: I really appreciate what Mr. Schoen of IBM has done to help 
make z/OS UNIX more useful (bpxwunix & bpxwdyn come to mind).

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

MQ (6.0) "transaction log"?

[John McKown]

Yes, I'm going off to research this myself right now. But I thought I might
be some help from those experienced too. We use MQ Series 6.0 to talk to
CICS/TS 4.1 on z/OS 1.13. Basically, we did some work with this years ago.
Then it was decide not to continue to use it for any new development, but
keep using it for what we had. We basically have gotten rid of all the
people who knew anything (& did not document it). Now, as part of the
"getting off of z/OS", management wants to know things like "who is using
this?"; "what are they doing with it?"; "how heavily is it being used?".
None of which is known by those few of us left.

So, is there something (SMF?) which would tell us any of this? Not that we
have any software which could be used to make a report (other than HLASM)
because that was gotten rid of long ago as too expensive. Yes, I am a bit
bitter.

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

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: SMF RECORD TYPE : HELP

[Lizette Koehler]

If you have IBM DFSORT, you can probably use ICEOOL to read SMF Data and 
produce a report

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.iceg200/ice.htm

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/ice2ca_Example_127.htm


However, MXG or MICS will be able to provide easier reporting process on SMF 
Data.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Dawes
> Sent: Friday, November 04, 2016 4:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF RECORD TYPE : HELP
> 
> Daniel,
> 
> I would like to try out your suggestion.  Would you have an example of the
> FDRABR step?  Also, would it support SMF as an input file?
> 
> 
> On Thu, 3/11/16, Blake, Daniel J [CTR] <00f1be92566d-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
>  Subject: Re: SMF RECORD TYPE : HELP
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Thursday, 3 November, 2016, 9:20 AM
> 
>  OK, add an SDSF step
>  before your FDR dump step, then one after your FDR dump  step.  Rerun the
> job.
> 
>  //COMMAND1  EXEC PGM=ISFAFD
>  //ISFOUT  DD  SYSOUT=*
>  //ISFIN   DD  *
> 
>  /D ALLOC,,devaddr,1
>  /*
>  //*
>  //FDRABR step here
>  //FDR
>  //*
>  //COMMAND2  EXEC PGM=ISFAFD
>  //ISFOUT  DD  SYSOUT=*
>  //ISFIN   DD  *
> 
>  /D ALLOC,,devaddr,1
>  /*
> 
> 
> 
>  ;-D an
> 
>  -Original Message-
>  From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On
> Behalf Of John Dawes
>  Sent: Thursday,
>  November 03, 2016 8:23 AM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: Re: SMF RECORD TYPE : HELP
> 
>  Yes, I tried that.  However,
>  when I issued the command it was too late (3 minutes after  the job
> abend).  This is why I thought by  reading SMF  records would have some info
> on the volume.
> 
> 
>  
>  On Thu, 3/11/16, Blake, Daniel J [CTR] <00f1be92566d-dmarc-
> requ...@listserv.ua.edu>
>  wrote:
> 
>   Subject: Re: SMF
>  RECORD TYPE : HELP
>   To: IBM-MAIN@LISTSERV.UA.EDU
>   Received: Thursday, 3 November, 2016, 7:56  AM
> 
>   Have you tried the
>  alloc
>   command from the console or SDSF?
> 
>   D U,,ALLOC,devaddr,1
> 
>   Thank You
> 
> 
> 
>   ;-D an
> 
> 
> 
> 
> 
>  -Original Message-
>   From: IBM
>  Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On Behalf Of
> John Dawes
>   Sent: Thursday,
>   November 03, 2016 7:53 AM
>   To:
>  IBM-MAIN@LISTSERV.UA.EDU
>   Subject: SMF RECORD TYPE : HELP
> 
>   G'Day,
> 
> 
>   Could someone suggest how I could obtain  information about a certain DASD
> volume?  I am trying to  trouble shoot a problem of a job failure when
> attempting  to  copy a volume using the following parms.
> 
>   COPY INDYNAM(SYS012)
>  OUTDYNAM(BCD012)
>   CANCELERROR  -
> 
>  PURGE ALLEXCP
>  ALLDATA(*) OPT(4) ADMIN FCNOCOPY
>   -
> 
>   I get the following
>   message:
> 
> 
>  ADR306E
>   (043)-SBRTN(01), UNABLE TO COPY THE
>  VOLUME BECAUSE OUTPUT  VOLUME BCD012  IS IN USE. TASK IS  TERMINATED
> 
>   I am trying to
>  find out what
>   resource was using the volume
>  at that time.  I thought that  SMF would be a solution  however I don't see a
> SMF record  type for DASD.
> 
>   Any
> 
>  suggestions would be very welcome.
> 
>   Thanks.
> 

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

Re: SQLCODE=-904 during RUN

[Jantje.]

O, and BTW, there is an excellent body of knowledge and knowledgeable people at 
http://www.idug.org/p/fo/si/topic=19

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

Re: SQLCODE=-904 during RUN

[Jantje.]

On Wed, 2 Nov 2016 13:39:48 -0500, Janet Graff  wrote:


>Yes this is part of my test automation so to make sure the result sets are 
>clean I am dropping and recreating the tables every time through.
>
>Are you saying I need to sequence this?  So the Drop/Create is done and THEN 
>then BIND?
>

Yes.

Dropping any table required by a package will invalidate that package. And 
creating a new table, even if it has the same name, will not right your 
package, because that new table is a _different_ object.

Why not simply TRUNCATE your tables if you want to empty them out before your 
test run?

Cheers,

Jantje.

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

Re: Question on TZ and European time change

[John McKown]

On Fri, Nov 4, 2016 at 2:30 AM, Peter Hunkeler  wrote:

> >'TZ=CET-1CEST,M3.5.0/2:00,M10.5.0/3:00'
>  >
> >http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/
> com.ibm.zos.v2r1.cbcpx01/cbc1p2559.htm
> " If this daylight savings time rule is omitted altogether, the values in
> the rule default to the standard American daylight savings time rules
> starting at 02:00:00 the second Sunday in March and ending at 02:00:00 the
> first Sunday in November."
>
>
>
>
> And from the same description you can see that the actual strings being
> used to name the standard and the DST periods (CET and CEST in the example
> above) have no meaning to the system. You can set them to anything you want
> without influencing the behaviour.
>
>
> The strings are only meant to show something meaningful to users.
>
>
> The first string is mandatory. The second string, in addition to be meant
> for the user, is also a flag to tell the system to apply DST according to
> the standard rules (mentione above), or by the rules specified.
>
>
> So, with
>
>
> TZ=WINTER-1SUMMER,M3.5.0/2:00,M10.5.0/3:00
> date '%a %b %e %T %Z %Y'
>
>
> will display
> Fr Nov 4 08:26:17 WINTER 2016
> today, but had displayed
> Fr Oct 28 08:26:17 SUMMER 2016
> last week.
>
>
> --Peter Hunkeler
>

​Another indication that, at least at the time this was done, IBM was not
overly concerned with making z/OS UNIX be acceptable to the "real" UNIX
community. They just wanted to stamp "POSIX compliant" on z/OS for
marketing purposes. ​Aside: I really appreciate what Mr. Schoen of IBM has
done to help make z/OS UNIX more useful (bpxwunix & bpxwdyn come to mind).


-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

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: SMF RECORD TYPE : HELP

[Blake, Daniel J [CTR]]

That was my mistake.  I was in a hurry and read the message as coming from 
FDRABR, rather than ICKDSF.  Do you have FDRABR at your site?


You should be able to add those steps to your current dump job and get the same 
results.



Dan 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Dawes
Sent: Friday, November 04, 2016 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF RECORD TYPE : HELP

Daniel,

I would like to try out your suggestion.  Would you have an example of the 
FDRABR step?  Also, would it support SMF as an input file?


On Thu, 3/11/16, Blake, Daniel J [CTR] 
<00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote:

 Subject: Re: SMF RECORD TYPE : HELP
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, 3 November, 2016, 9:20 AM
 
 OK, add an SDSF step
 before your FDR dump step, then one after your FDR dump  step.  Rerun the job.
 
 //COMMAND1  EXEC PGM=ISFAFD
 //ISFOUT              DD  SYSOUT=*
 //ISFIN   DD  *
  
 /D ALLOC,,devaddr,1
 /*
 //*
 //FDRABR step here
 //FDR
 //*
 //COMMAND2  EXEC PGM=ISFAFD
 //ISFOUT              DD  SYSOUT=*
 //ISFIN   DD  *
  
 /D ALLOC,,devaddr,1
 /*
 
 
 
 ;-D an 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On 
Behalf Of John Dawes
 Sent: Thursday,
 November 03, 2016 8:23 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: SMF RECORD TYPE : HELP
 
 Yes, I tried that.  However,
 when I issued the command it was too late (3 minutes after  the job abend).  
This is why I thought by  reading SMF  records would have some info on the 
volume.
 
 
 
 On Thu, 3/11/16, Blake, Daniel J [CTR] 
<00f1be92566d-dmarc-requ...@listserv.ua.edu>
 wrote:
 
  Subject: Re: SMF
 RECORD TYPE : HELP
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Thursday, 3 November, 2016, 7:56  AM
  
  Have you tried the
 alloc
  command from the console or SDSF?
  
  D U,,ALLOC,devaddr,1
  
  Thank You
 
 
  
  ;-D an
 
 
  
   
 
 -Original Message-
  From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On Behalf Of John 
Dawes
  Sent: Thursday,
  November 03, 2016 7:53 AM
  To:
 IBM-MAIN@LISTSERV.UA.EDU
  Subject: SMF RECORD TYPE : HELP
  
  G'Day,
 
 
  Could someone suggest how I could obtain  information about a certain DASD 
volume?  I am trying to  trouble shoot a problem of a job failure when 
attempting  to  copy a volume using the following parms.
  
  COPY INDYNAM(SYS012)
 OUTDYNAM(BCD012)
  CANCELERROR      - 
   
     PURGE ALLEXCP
 ALLDATA(*) OPT(4) ADMIN FCNOCOPY
  -    
  
  I get the following
  message:
  
 
 ADR306E
  (043)-SBRTN(01), UNABLE TO COPY THE
 VOLUME BECAUSE OUTPUT  VOLUME BCD012  IS IN USE. TASK IS  TERMINATED
  
  I am trying to
 find out what
  resource was using the volume
 at that time.  I thought that  SMF would be a solution  however I don't see a 
SMF record  type for DASD.
  
  Any
 
 suggestions would be very welcome.
  
  Thanks.
  
 
 --
  For IBM-MAIN subscribe / signoff / archive  access instructions, send email 
to lists...@listserv.ua.edu  with the message: INFO IBM-MAIN
  
  
 
 --
  For IBM-MAIN subscribe / signoff / archive  access instructions,  send email 
to lists...@listserv.ua.edu  with the message: INFO IBM-MAIN
  
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions, send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

--
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: SMF RECORD TYPE : HELP

[John Dawes]

Daniel,

I would like to try out your suggestion.  Would you have an example of the 
FDRABR step?  Also, would it support SMF as an input file?


On Thu, 3/11/16, Blake, Daniel J [CTR] 
<00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote:

 Subject: Re: SMF RECORD TYPE : HELP
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, 3 November, 2016, 9:20 AM
 
 OK, add an SDSF step
 before your FDR dump step, then one after your FDR dump
 step.  Rerun the job.
 
 //COMMAND1  EXEC PGM=ISFAFD
 //ISFOUT              DD  SYSOUT=*
 //ISFIN   DD  *
  
 /D ALLOC,,devaddr,1
 /*
 //*
 //FDRABR step here
 //FDR 
 //*    
 //COMMAND2  EXEC PGM=ISFAFD
 //ISFOUT              DD  SYSOUT=*
 //ISFIN   DD  *
  
 /D ALLOC,,devaddr,1
 /*
 
 
 
 ;-D an 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of John Dawes
 Sent: Thursday,
 November 03, 2016 8:23 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: SMF RECORD TYPE : HELP
 
 Yes, I tried that.  However,
 when I issued the command it was too late (3 minutes after
 the job abend).  This is why I thought by  reading SMF
 records would have some info on the volume.
 
 
 
 On Thu, 3/11/16, Blake, Daniel J [CTR] 
<00f1be92566d-dmarc-requ...@listserv.ua.edu>
 wrote:
 
  Subject: Re: SMF
 RECORD TYPE : HELP
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Thursday, 3 November, 2016, 7:56
 AM
  
  Have you tried the
 alloc
  command from the console or SDSF?
  
  D U,,ALLOC,devaddr,1
  
  Thank You
 
 
  
  ;-D an
 
 
  
   
 
 -Original Message-
  From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On Behalf Of John Dawes
  Sent: Thursday,
  November 03, 2016 7:53 AM
  To:
 IBM-MAIN@LISTSERV.UA.EDU
  Subject: SMF RECORD TYPE : HELP
  
  G'Day,
 
 
  Could someone suggest how I could obtain 
 information about a certain DASD volume?  I am trying to 
 trouble shoot a problem of a job failure when attempting
 to  copy a volume using the following parms.
  
  COPY INDYNAM(SYS012)
 OUTDYNAM(BCD012)
  CANCELERROR      - 
   
     PURGE ALLEXCP
 ALLDATA(*) OPT(4) ADMIN FCNOCOPY
  -    
  
  I get the following
  message:
  
 
 ADR306E
  (043)-SBRTN(01), UNABLE TO COPY THE
 VOLUME BECAUSE OUTPUT  VOLUME BCD012  IS IN USE. TASK IS
 TERMINATED
  
  I am trying to
 find out what
  resource was using the volume
 at that time.  I thought that  SMF would be a solution
 however I don't see a SMF record  type for DASD.
  
  Any
 
 suggestions would be very welcome.
  
  Thanks.
  
 
 --
  For IBM-MAIN subscribe / signoff / archive 
 access instructions, send email to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN
  
  
 
 --
  For IBM-MAIN subscribe / signoff / archive 
 access instructions,  send email to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN
  
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions, send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: SMF RECORD TYPE : HELP

[John Dawes]

That was the first thing I tried.  However it was too late because I issued 3 
minutes later after the job abended.  The device showed that no resource had 
aan enque on it..

On Thu, 3/11/16, Ronald Hawkins  wrote:

 Subject: Re: SMF RECORD TYPE : HELP
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, 3 November, 2016, 7:51 PM
 
 John,
 Have you tried D U ... ALLOC COMMAND?
 Ron
 
 Sent from
 Yahoo Mail on Android 
  
  
 On Thu, Nov 3, 2016 at 4:52, John 
Dawes<00ff0e22811f-dmarc-requ...@listserv.ua.edu>
 wrote:   G'Day,
 
 Could someone suggest how I could obtain
 information about a certain DASD volume?  I am trying to
 trouble shoot a problem of a job failure when attempting to
 copy a volume using the following parms.
 
 COPY INDYNAM(SYS012) OUTDYNAM(BCD012)
 CANCELERROR      - 
     PURGE ALLEXCP
 ALLDATA(*) OPT(4) ADMIN FCNOCOPY -    
 
 I get the following message:
 
 ADR306E (043)-SBRTN(01),
 UNABLE TO COPY THE VOLUME BECAUSE OUTPUT VOLUME BCD012  IS
 IN USE. TASK IS TERMINATED
 
 I am trying to find out what resource was using
 the volume at that time.  I thought that SMF would be a
 solution however I don't see a SMF record type for
 DASD.
 
 Any suggestions would
 be very welcome.
 
 Thanks.
 
 --
 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: Question on TZ and European time change

[Peter Hunkeler]

>'TZ=CET-1CEST,M3.5.0/2:00,M10.5.0/3:00'
 >
>http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcpx01/cbc1p2559.htm
" If this daylight savings time rule is omitted altogether, the values in the 
rule default to the standard American daylight savings time rules starting at 
02:00:00 the second Sunday in March and ending at 02:00:00 the first Sunday in 
November."




And from the same description you can see that the actual strings being used to 
name the standard and the DST periods (CET and CEST in the example above) have 
no meaning to the system. You can set them to anything you want without 
influencing the behaviour.


The strings are only meant to show something meaningful to users.


The first string is mandatory. The second string, in addition to be meant for 
the user, is also a flag to tell the system to apply DST according to the 
standard rules (mentione above), or by the rules specified.


So, with


TZ=WINTER-1SUMMER,M3.5.0/2:00,M10.5.0/3:00
date '%a %b %e %T %Z %Y'


will display
Fr Nov 4 08:26:17 WINTER 2016
today, but had displayed
Fr Oct 28 08:26:17 SUMMER 2016
last week.


--Peter Hunkeler

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

Re: OLD Manual - any one aware of something more current VSE to z/os

[Timothy Sipples]

Michael O'Byrne wrote:
>When I was doing DOS to MVS conversions for IBM (30+ years ago) the
>recommendation would be to use IMS-DB to support DL/1 (hierarchical
>database mapped to hierarchical).   Today, I would recommend evaluating a
>conversion to DB2 or perhaps the use of a product which maps IMS DB to
>DB2.

Even if you decide to do that, you might prudently defer database
restructuring and data migration to Phase 2 (or Phase 3) of your overall
project, to keep your Phase 1 more concise and tractable.

Or Phase 1 could be the database only, and you leave some or all of the
applications in place at least during Phase 1. For example, you can license
the DB2 Client Edition separately on z/VSE, and then you can configure the
DB2 Client to store/retrieve data over in DB2 for z/OS. In this approach
you'd likely migrate the data to z/OS and make some comparatively small
code changes related to data access logic, but that would be the extent of
Phase 1. In Phase 2 you'd tackle other application-related work.

Another option is the z/VSE VSAM Redirector, to facilitate migration of
any/all VSAM data that z/VSE manages, typically to DB2 for z/OS. This
approach applies if you have z/VSE-based programs that access z/VSE-based
VSAM data. In Phase 1 you can move the data over into z/OS, but the
applications don't change and don't move. Then, in Phase 2, you start
moving some applications to z/OS if you wish, possibly with the aid of
IBM's CICS VSAM Transparency for z/OS.

There are also some interesting interoperability options between CICS
Transaction Server for z/VSE and CICS Transaction Server for z/OS that
could be quite useful. For example, you can use the z/VSE Connector Client
running on z/OS (with CICS Transaction Server for z/OS, most probably) so
that z/OS has real-time access to DL/I data over in z/VSE. In this approach
you could start moving some applications in Phase 1, gradually, but leave
the data (and any z/VSE-hosted applications that still need the data) in
place until Phase 2. If you plan and execute well (very possible), at some
point in Phase 2 your z/OS applications would start to store/retrieve
relocated data in z/OS instead of accessing z/VSE's DL/I data.

Anyway, there are a lot of interoperability options. If you decide you want
to move some applications and or data from z/VSE to z/OS, interoperability
is extremely helpful to smooth the path, to remove migration dependencies
(applications with data, data with applications), to reduce the migration
risks, and to provide the quickest delivery of whatever specific business
benefits you plan. (And if there are no real, achievable business benefits,
why bother? "Eyes on the prize.") I'm mentioning these interoperability
examples because they may be unfamiliar to many of you, and at least some
of them are newer and not mentioned in the older redbooks.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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