Re: Subscribing to IBM-MAIN

2015-10-08 Thread Elardus Engelbrecht 
On Thu, 8 Oct 2015 20:49:43 +, J O Skip Robinson  
wrote:

>Two of my colleagues are trying to join IBM-MAIN. Neither one is successful. 
>Both have sent notes to LISTSERV trying to following the INFO directive:

>SUBSCRIBE IBM-MAIN  

>What's with the angle brackets? Required? Prohibited? Nothing seems to work.

'angle brackets' are notation. Drop them. 

... or was that SUBSCRIBE line in 'Subject' Field or in the 'Body' of your 
e-mail attempt? What is the receiver in the 'To' field?

Ed Finnell, Tom Brennan and Ted MacNEIL kindly helped you, but if you'r not 
successful, try this alternative.


Alternatively (granted, I used this method, not the e-mail method),

... go to this site: https://listserv.ua.edu/cgi-bin/wa?INDEX

(This is just to start all the way from the very beginning.)

In that page, you will see a list of all discussion lists hosted by that place.

Select (click on that link) IBM-MAIN (grown to 7002 members! wow!) and then on 
next page, select (click on that link) this field "Join or leave the list (or 
change settings)".

Then follow the instructions there. (and if you want to receive e-mails, there 
is a field where you can enable it.)

PS: you'll may have to accept cookies, otherwise you will have to enter e-mail 
address and password if you want to use the website. 

HTH!

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: File Placement Utility

2015-10-08 Thread Mike Schwab 
Calculate the number of total number of tracks.
Divide by number of volumes, result is how many tracks to use on each volume.
Init n-1 volumes with small VTOC, one with a larger VTOC for lots of
small files.
Sort by descending number of tracks.

Move largest remaining file to the volume with small VTOC and the most
free space.
When the n-1 volumes have exceeded the goal number of tracks to use on
each volume, stop.

Move the large number of remaining small files to the volume with the
larger VTOC.


On Thu, Oct 8, 2015 at 8:25 PM, Hardee, Chuck H.
 wrote:
> I have a need to juggle the locations of 1500+ files on 70 volumes.
> These packs are not SMS managed and will never be.
> There will be 4 sets of these files across 4 sets of 70 DASD volumes.
>
> Does anyone know of a utility, REXX, EXCEL, executable program, etc, that 
> would let me feed in the file names and sizes, dasd characteristics, etc, and 
> produce a list of what files should be allocated on what packs?
>
> The file sizes vary file to file, but they do not expand or contract once 
> allocated and won't change until the next time the files need to be adjusted, 
> which won't hopefully, change for a while.
>
> Thanks,
> Chuck
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  | 
> www.thermofisher.com
>
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of 
> this e-mail or the information herein by anyone other than the intended 
> recipient, or an employee or agent of a system responsible for delivering the 
> message to the intended recipient, is prohibited. If you are not the intended 
> recipient, please inform the sender and delete all copies.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: File Placement Utility

2015-10-08 Thread Chris Hoelscher 
Here is what I do (when copying prod to QA files) - there might be easier or 
better ways - but this is the best I came up with, with my limited mental 
resources . 

Get the name and size (# of tracks)  of each of the 1500+ files (we use CA-RSVP)
Sort by size (descending)
Then  write a process to read in each dataset name/size - assign to the volume 
with the most remaining space (you would need to keep track of how much is 
allocated for each volume) - sort the output by volume/#tracks

Then you could backup the datasets for each output volume in the sorted order 
(one backup per TARGET volume) - then restore each backup with any rename you 
need to the target volume

Why go to all this trouble? Even if you have enough volume space, if you don't 
restore the biggest files first, you might end up with enough free space for a 
large file, but not have enough spce on any ONE volume (perhaps not even a 
primary extent)


Chris hoelscher
Technology Architect 
Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 714-8615
(502) 476-2538


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, David Allen,Jr
Sent: Thursday, October 08, 2015 9:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] File Placement Utility

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Hardee, Chuck H.
> Sent: Thursday, October 08, 2015 6:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: File Placement Utility
> 
> I have a need to juggle the locations of 1500+ files on 70 volumes.
> These packs are not SMS managed and will never be.
> There will be 4 sets of these files across 4 sets of 70 DASD volumes.

Sorry, I missed the number of output volumes, and you will need to use the 
FILTERDD to spcify more than 255 datasets. Still, it should work. If you want 
copies, then don't use DELETE or CATALOG.

I suspect that in general is will just start writing and when each volume fills 
up, it will move on to the next one. Any more desire at a specific placement 
would probably be unique to your shop.



> 
> Does anyone know of a utility, REXX, EXCEL, executable program, etc, 
> that would let me feed in the file names and sizes, dasd 
> characteristics, etc, and produce a list of what files should be allocated on 
> what packs?
> 
> The file sizes vary file to file, but they do not expand or contract 
> once allocated and won't change until the next time the files need to 
> be adjusted, which won't hopefully, change for a while.
> 
> Thanks,
> Chuck
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information 
> Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | 
> Mobile
> +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com >  | www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying 
> of this e-mail or the information herein by anyone other than the 
> intended recipient, or an employee or agent of a system responsible 
> for delivering the message to the intended recipient, is prohibited. 
> If you are not the intended recipient, please inform the sender and delete 
> all copies.
> 
> 
> --
> 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 transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

Re: File Placement Utility

2015-10-08 Thread Gibney, David Allen,Jr 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Hardee, Chuck H.
> Sent: Thursday, October 08, 2015 6:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: File Placement Utility
> 
> I have a need to juggle the locations of 1500+ files on 70 volumes.
> These packs are not SMS managed and will never be.
> There will be 4 sets of these files across 4 sets of 70 DASD volumes.

Sorry, I missed the number of output volumes, and you will need to use the 
FILTERDD to spcify more than 255 datasets. Still, it should work. If you want 
copies, then don't use DELETE or CATALOG.

I suspect that in general is will just start writing and when each volume fills 
up, it will move on to the next one. Any more desire at a specific placement 
would probably be unique to your shop.



> 
> Does anyone know of a utility, REXX, EXCEL, executable program, etc, that
> would let me feed in the file names and sizes, dasd characteristics, etc, and
> produce a list of what files should be allocated on what packs?
> 
> The file sizes vary file to file, but they do not expand or contract once
> allocated and won't change until the next time the files need to be adjusted,
> which won't hopefully, change for a while.
> 
> Thanks,
> Chuck
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information
> Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile
> +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com >  | www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying
> of this e-mail or the information herein by anyone other than the intended
> recipient, or an employee or agent of a system responsible for delivering the
> message to the intended recipient, is prohibited. If you are not the intended
> recipient, please inform the sender and delete all copies.
> 
> 
> --
> 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: File Placement Utility

2015-10-08 Thread Paul Gilmartin 
On Fri, 9 Oct 2015 01:25:00 +, Hardee, Chuck H. wrote:

>I have a need to juggle the locations of 1500+ files on 70 volumes.
>These packs are not SMS managed and will never be.
>There will be 4 sets of these files across 4 sets of 70 DASD volumes.
> 
Oooh!  The Knapsack Problem:
https://en.wikipedia.org/wiki/Knapsack_problem

-- gil

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

Re: File Placement Utility

2015-10-08 Thread Gibney, David Allen,Jr 
Why not just use ADRDSSU, something like
COPY DATASET( -
 INCLUDE( -
Your list of datasets - 
 ) -   
) -
OUTDY( -   
 (yourxx target fourxx volume) -
 )-
ALLEXCP  - 
NULLMGMTCLAS - 
NULLSTORCLAS - 
BYPASSACS(anydsn) -  
ALLDATA(*)   - 
ADMIN- 
CATALOG  - 
DELETE   - 
PROCESS(SYS1)- 
PURGE- 
SPHERE 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Hardee, Chuck H.
> Sent: Thursday, October 08, 2015 6:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: File Placement Utility
> 
> I have a need to juggle the locations of 1500+ files on 70 volumes.
> These packs are not SMS managed and will never be.
> There will be 4 sets of these files across 4 sets of 70 DASD volumes.
> 
> Does anyone know of a utility, REXX, EXCEL, executable program, etc, that
> would let me feed in the file names and sizes, dasd characteristics, etc, and
> produce a list of what files should be allocated on what packs?
> 
> The file sizes vary file to file, but they do not expand or contract once
> allocated and won't change until the next time the files need to be adjusted,
> which won't hopefully, change for a while.
> 
> Thanks,
> Chuck
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information
> Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile
> +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com >  | www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying
> of this e-mail or the information herein by anyone other than the intended
> recipient, or an employee or agent of a system responsible for delivering the
> message to the intended recipient, is prohibited. If you are not the intended
> recipient, please inform the sender and delete all copies.
> 
> 
> --
> 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

File Placement Utility

2015-10-08 Thread Hardee, Chuck H. 
I have a need to juggle the locations of 1500+ files on 70 volumes.
These packs are not SMS managed and will never be.
There will be 4 sets of these files across 4 sets of 70 DASD volumes.

Does anyone know of a utility, REXX, EXCEL, executable program, etc, that would 
let me feed in the file names and sizes, dasd characteristics, etc, and produce 
a list of what files should be allocated on what packs?

The file sizes vary file to file, but they do not expand or contract once 
allocated and won't change until the next time the files need to be adjusted, 
which won't hopefully, change for a while.

Thanks,
Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | 
www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


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

Re: Subscribing to IBM-MAIN

2015-10-08 Thread Ed Finnell 
That is correct. If you provide a proper From: address nothing else is  
required.
 
 
In a message dated 10/8/2015 5:47:16 P.M. Central Daylight Time,  
t...@tombrennansoftware.com writes:

When I  subscribed last year I didn't code any firstname or lastname, but 
the  response email indicated my name which it must have grabbed from my 
"From"  address.  Here's the source of my request, if that helps at  all.


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

Re: Subscribing to IBM-MAIN

2015-10-08 Thread Ted MacNEIL 
Don't use the angle brackets.

It's just notation


-
-teD
-
  Original Message  
From: Ed Finnell
Sent: Thursday, October 8, 2015 18:20
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Subscribing to IBM-MAIN

Darren will probably respond when he gets off his day job. Guess the answer 
is required. If they're still having trouble might try the web page at 
listserv.ua.edu/archives/ibm-main.html where you can sign up and set options 
for sending and receiving.


In a message dated 10/8/2015 3:49:56 P.M. Central Daylight Time, 
jo.skip.robin...@sce.com writes:

What's with the angle brackets? Required? Prohibited? Nothing seems to 
work

--
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: Subscribing to IBM-MAIN

2015-10-08 Thread Tom Brennan 
When I subscribed last year I didn't code any firstname or lastname, but 
the response email indicated my name which it must have grabbed from my 
"From" address.  Here's the source of my request, if that helps at all.


From - Sat Sep 13 23:32:27 2014
X-Mozilla-Status: 0001
X-Mozilla-Status2: 0080
Message-ID: <54153678.4080...@tombrennansoftware.com>
Date: Sat, 13 Sep 2014 23:32:24 -0700
From: Tom Brennan 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  lists...@listserv.ua.edu
Subject: Does this work still?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

SUBSCRIBE IBM-MAIN

J O Skip Robinson wrote:

Two of my colleagues are trying to join IBM-MAIN. Neither one is successful. 
Both have sent notes to LISTSERV trying to following the INFO directive:

SUBSCRIBE IBM-MAIN  

What's with the angle brackets? Required? Prohibited? Nothing seems to work.



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


--
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: Subscribing to IBM-MAIN

2015-10-08 Thread Ed Finnell 
Darren will probably respond when he gets off his day job. Guess the answer 
 is required. If they're still having trouble might try the web page at  
listserv.ua.edu/archives/ibm-main.html where you can sign up and set options 
for  sending and receiving.
 
 
In a message dated 10/8/2015 3:49:56 P.M. Central Daylight Time,  
jo.skip.robin...@sce.com writes:

What's  with the angle brackets? Required? Prohibited? Nothing seems to  
work

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Shmuel Metz (Seymour J.) 
In
,
on 10/08/2015
   at 03:14 PM, Mike Schwab  said:

>I made this comment on the RFE.  Perhaps it should be a new RFE.

>For the MOUNT command and in SYS1.PARMLIB(BPXPRMxx), add a NOWAIT and
>/ or DEFER keywords.

That sounds as if you're describing an implementation rather than the
actual requirement. As I understand it, the actual requirement is to
provide a means to mirror ZFS to a remote site without delaying DR
switchover. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Subscribing to IBM-MAIN

2015-10-08 Thread J O Skip Robinson 
Two of my colleagues are trying to join IBM-MAIN. Neither one is successful. 
Both have sent notes to LISTSERV trying to following the INFO directive:

SUBSCRIBE IBM-MAIN  

What's with the angle brackets? Required? Prohibited? Nothing seems to work.



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


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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Mike Schwab 
I made this comment on the RFE.  Perhaps it should be a new RFE.

For the MOUNT command and in SYS1.PARMLIB(BPXPRMxx), add a NOWAIT and
/ or DEFER keywords.For a NOWAIT keyword begin the files system
check that could take 65 seconds.For a DEFER keyword wait until an
access of the file system is requested.In either case, z/OS should
process the next command.Any use of the file system would wait
until the check is complete.Use on a system file system (list them
in the manual (TEMP, ETC, ...)) would be highly discouraged because
the IPL will wait until the check is completed anyway.

For a local fix, could another member have a command to process these?
 Or have automations submit a batch job to run the mount commands?

On Thu, Oct 8, 2015 at 11:13 AM, van der Grijn, Bart (B)
 wrote:
> We have the same issue (more than 2 hours). I've asked IBM about this in the 
> past and didn't get much of an answer besides WAD.
> I've considered taking the application specific mounts out of BPXPRMxx and 
> mount them after the system is up. Maybe make it part of the application 
> startup in System Automation. Haven't yet pursued it, but with our DR test 
> next month it's back on the radar.
> The only good thing is that based on the timing of our DR tests this always 
> gives us a good lunch break.
>
> Bart
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Dave Butts
> Sent: Thursday, October 08, 2015 11:40
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IOEZ00807I when OMVS initializes at Disaster Recovery site
>
> Searched the archives and saw others had this issue, but never saw a good 
> answer.
>
> We recently implemented ZFS file sharing for the first time here.
> We run GDPS/XRC to replicate our dasd from HQ to DR site and then often 
> "flash" the farm to a set we can IPL our recovery system from.
>
> Because the of replication, our ZFS files are obviously never closed properly 
> before being used when we IPL the recovery LPAR.
> The nature of our 24/7 environment and GDPS/XRC means that the flash of the 
> dasd farm will ALWAYS be "fuzzy".  The contents of block 0 in each ZFS file 
> will always contain data
>
> So we experience the dreaded IOEZ00807I message and a 65 second delay per 
> mount.  We have so many ZFS files in use that this takes almost 2 hours to 
> complete a successful IPL of the recovery system.
>
> What do other shops do about this?  I would hate to have to IPL a minimal 
> system just to mount/unmount the files properly before IPLing the recovery 
> PROD system.  Is there a parm anywhere to tell ZFS to ignore integrity 
> checking at IPL?
>
> Thanks,
> Dave
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Jousma, David 
We converted to sysplex shared filesystems, and this issue went away.  We 
recover our DR system almost weekly, and that 65 second delay is a real PITA.   

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Butts
Sent: Thursday, October 08, 2015 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

Thanks, Bart.

In my pmr with IBM, they confirmed that ensuring those match are not enough to 
guarantee it will avoid the wait.
Here is what IBM told us:
--
Just finished discussing this with my defect folks and unfortunately
using the same SYSNAME and SYSPLEX name on the DR system does not   
guarantee the 65 zFS check at mount/ipl time will be bypassed.  
There are other variables involved that are not within admin control that 
would come into play that would still trigger the 65 second check. 
.   
This is an issue that has been raised with development and I would 
recommend that you open an RFE for this functionality to help bring this to 
developments attention (and to emphasis the need from the DR point of
view).  
You can do this at: 
https://www.ibm.com/developerworks/rfe  
There is a similar RFE that discusses this same issue. You can  
either search for IOEZ00807I or the RFE id 58654.
--

Maybe if we all open an RFE they will finally fix this.

Thanks for all the info and suggestions!
Dave

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Richard Pinion 
I submitted my vote for the RFE.



--- dbutt...@gmail.com wrote:

From: Dave Butts 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IOEZ00807I when OMVS initializes at Disaster Recovery site
Date: Thu, 8 Oct 2015 14:12:57 -0500

Thanks, Bart.

In my pmr with IBM, they confirmed that ensuring those match are not enough to 
guarantee it will avoid the wait.
Here is what IBM told us:
--
Just finished discussing this with my defect folks and unfortunately
using the same SYSNAME and SYSPLEX name on the DR system does not   
guarantee the 65 zFS check at mount/ipl time will be bypassed.  
There are other variables involved that are not within admin control
that would come into play that would still trigger the 65 second check. 
.   
This is an issue that has been raised with development and I would  
recommend that you open an RFE for this functionality to help bring this
to developments attention (and to emphasis the need from the DR point of
view).  
You can do this at: 
https://www.ibm.com/developerworks/rfe  
There is a similar RFE that discusses this same issue. You can  
either search for IOEZ00807I or the RFE id 58654.
--

Maybe if we all open an RFE they will finally fix this.

Thanks for all the info and suggestions!
Dave

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




_
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: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Dave Butts 
Thanks, Bart.

In my pmr with IBM, they confirmed that ensuring those match are not enough to 
guarantee it will avoid the wait.
Here is what IBM told us:
--
Just finished discussing this with my defect folks and unfortunately
using the same SYSNAME and SYSPLEX name on the DR system does not   
guarantee the 65 zFS check at mount/ipl time will be bypassed.  
There are other variables involved that are not within admin control
that would come into play that would still trigger the 65 second check. 
.   
This is an issue that has been raised with development and I would  
recommend that you open an RFE for this functionality to help bring this
to developments attention (and to emphasis the need from the DR point of
view).  
You can do this at: 
https://www.ibm.com/developerworks/rfe  
There is a similar RFE that discusses this same issue. You can  
either search for IOEZ00807I or the RFE id 58654.
--

Maybe if we all open an RFE they will finally fix this.

Thanks for all the info and suggestions!
Dave

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Dave Butts 
Agreed.  We will be pursuing opening a request to IBM for sure.

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Dana Mitchell 
On Thu, 8 Oct 2015 11:21:09 -0500, Dave Butts  wrote:

>Seems like they should be able to create a BPX parm to tell OMVS to ignore the 
>check.
>Very frustrating.
>We may need to pursue mounting just what we need to IPL to a base level, and 
>mount the rest after as you suggest.
>
>Thanks,
>Dave

Sounds like you have too many zFS's for it to be practical to quiese them 
before making the snap copy.

We run this:

//ZFSADM1  EXEC PGM=IOEAGSLV,REGION=0M,   
//  PARM=('-aggregate OMVS.TE01.ROOT.Z13RES -recoveronly')

after cloning zfs's. Perhaps you could run that against them from a small 
one-pack floor system, or your main system with them taken out of bpxprm?  Does 
that step run quicker than the delay at mount time?

Dana

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread van der Grijn, Bart (B) 
Dave, I looked back through the PMR I opened on this and one comment IBM made 
was that you will not incur the 65 second wait penalty if the system and plex 
names at recovery time are the same as what's in block zero. I've never tested 
this since we can't predict/determine what system owned the file systems at the 
time of the flash copy.

FWIW,
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Butts
Sent: Thursday, October 08, 2015 12:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

Seems like they should be able to create a BPX parm to tell OMVS to ignore the 
check.
Very frustrating.
We may need to pursue mounting just what we need to IPL to a base level, and 
mount the rest after as you suggest.

Thanks,
Dave

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Andrew Metcalfe 
We use the following setup to circumvent this to some degree:

We start OMVS with parms of (TH,FS,ZS)

BPXPRMTH contains the Threshold values etc.
BPXPRMFS contains the FileSystem definitions - ZFS, CINET etc.
BPXPRMZS contains the mounts for those ZFS datasets supplied as part of z/OS - 
no application data

When TCPIP has initialised, Automation issues a SET OMVS=(PD,ss) to drive 
mounts for the rest of the ZFS estate. 

BPXPRMPD contains mounts for "products" that are not considered part of core 
z/OS.
BPXPRMss contains mounts for the remaining application ZFS datasets.

The idea behind this was to get TCPIP up (and hence the rest of the system 
infrastructure) as soon as we could without waiting for ZFS recovery to 
complete. OMVS is initialised once it has processed the 3 BPXPRMxx members 
defined at IPL.

Works for us - may work for you!

Andrew


This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Dave Butts 
Seems like they should be able to create a BPX parm to tell OMVS to ignore the 
check.
Very frustrating.
We may need to pursue mounting just what we need to IPL to a base level, and 
mount the rest after as you suggest.

Thanks,
Dave

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Lizette Koehler 
Maybe you could go to DeveloperWorks and explain to IBM via an RFE the benefits 
of a process to ignore integrity at DR.  Or provide a way at DR to tell zFS to 
do something else.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dave Butts
> Sent: Thursday, October 08, 2015 8:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IOEZ00807I when OMVS initializes at Disaster Recovery site
> 
> Searched the archives and saw others had this issue, but never saw a good 
> answer.
> 
> We recently implemented ZFS file sharing for the first time here.
> We run GDPS/XRC to replicate our dasd from HQ to DR site and then often 
> "flash"
> the farm to a set we can IPL our recovery system from.
> 
> Because the of replication, our ZFS files are obviously never closed properly 
> before
> being used when we IPL the recovery LPAR.
> The nature of our 24/7 environment and GDPS/XRC means that the flash of the 
> dasd
> farm will ALWAYS be "fuzzy".  The contents of block 0 in each ZFS file will 
> always
> contain data
> 
> So we experience the dreaded IOEZ00807I message and a 65 second delay per
> mount.  We have so many ZFS files in use that this takes almost 2 hours to 
> complete
> a successful IPL of the recovery system.
> 
> What do other shops do about this?  I would hate to have to IPL a minimal 
> system
> just to mount/unmount the files properly before IPLing the recovery PROD 
> system.
> Is there a parm anywhere to tell ZFS to ignore integrity checking at IPL?
> 
> Thanks,
> Dave

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread van der Grijn, Bart (B) 
We have the same issue (more than 2 hours). I've asked IBM about this in the 
past and didn't get much of an answer besides WAD. 
I've considered taking the application specific mounts out of BPXPRMxx and 
mount them after the system is up. Maybe make it part of the application 
startup in System Automation. Haven't yet pursued it, but with our DR test next 
month it's back on the radar. 
The only good thing is that based on the timing of our DR tests this always 
gives us a good lunch break.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Butts
Sent: Thursday, October 08, 2015 11:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IOEZ00807I when OMVS initializes at Disaster Recovery site

Searched the archives and saw others had this issue, but never saw a good 
answer.

We recently implemented ZFS file sharing for the first time here.
We run GDPS/XRC to replicate our dasd from HQ to DR site and then often "flash" 
the farm to a set we can IPL our recovery system from.  

Because the of replication, our ZFS files are obviously never closed properly 
before being used when we IPL the recovery LPAR.
The nature of our 24/7 environment and GDPS/XRC means that the flash of the 
dasd farm will ALWAYS be "fuzzy".  The contents of block 0 in each ZFS file 
will always contain data

So we experience the dreaded IOEZ00807I message and a 65 second delay per 
mount.  We have so many ZFS files in use that this takes almost 2 hours to 
complete a successful IPL of the recovery system.

What do other shops do about this?  I would hate to have to IPL a minimal 
system just to mount/unmount the files properly before IPLing the recovery PROD 
system.  Is there a parm anywhere to tell ZFS to ignore integrity checking at 
IPL?

Thanks,
Dave

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

Re: IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread dbutts 
Most operating system files are r/o.
But it is impossible to do that at the live site with the majority of our
ZFS files.
And we have over 200 ZFS files.

Thanks,
Dave


On Thu, Oct 8, 2015 at 10:55 AM,  wrote:

> Hi Dave,
>
> Keep all your system ZFS r/o at the live site.
>
> Kind Regards,
>
> Rajesh
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dave Butts
> Sent: Thursday, October 08, 2015 11:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IOEZ00807I when OMVS initializes at Disaster Recovery site
>
> Searched the archives and saw others had this issue, but never saw a good
> answer.
>
> We recently implemented ZFS file sharing for the first time here.
> We run GDPS/XRC to replicate our dasd from HQ to DR site and then often
> "flash" the farm to a set we can IPL our recovery system from.
>
> Because the of replication, our ZFS files are obviously never closed
> properly before being used when we IPL the recovery LPAR.
> The nature of our 24/7 environment and GDPS/XRC means that the flash of
> the dasd farm will ALWAYS be "fuzzy".  The contents of block 0 in each ZFS
> file will always contain data
>
> So we experience the dreaded IOEZ00807I message and a 65 second delay per
> mount.  We have so many ZFS files in use that this takes almost 2 hours to
> complete a successful IPL of the recovery system.
>
> What do other shops do about this?  I would hate to have to IPL a minimal
> system just to mount/unmount the files properly before IPLing the recovery
> PROD system.  Is there a parm anywhere to tell ZFS to ignore integrity
> checking at IPL?
>
> Thanks,
> Dave
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please visit our website at
> http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
> for important disclosures and information about our e-mail
> policies. For your protection, please do not transmit orders
> or instructions by e-mail or include account numbers, Social
> Security numbers, credit card numbers, passwords, or other
> personal information.
>

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

IOEZ00807I when OMVS initializes at Disaster Recovery site

2015-10-08 Thread Dave Butts 
Searched the archives and saw others had this issue, but never saw a good 
answer.

We recently implemented ZFS file sharing for the first time here.
We run GDPS/XRC to replicate our dasd from HQ to DR site and then often "flash" 
the farm to a set we can IPL our recovery system from.  

Because the of replication, our ZFS files are obviously never closed properly 
before being used when we IPL the recovery LPAR.
The nature of our 24/7 environment and GDPS/XRC means that the flash of the 
dasd farm will ALWAYS be "fuzzy".  The contents of block 0 in each ZFS file 
will always contain data

So we experience the dreaded IOEZ00807I message and a 65 second delay per 
mount.  We have so many ZFS files in use that this takes almost 2 hours to 
complete a successful IPL of the recovery system.

What do other shops do about this?  I would hate to have to IPL a minimal 
system just to mount/unmount the files properly before IPLing the recovery PROD 
system.  Is there a parm anywhere to tell ZFS to ignore integrity checking at 
IPL?

Thanks,
Dave

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

Re: Unicode services Red alert

2015-10-08 Thread גדי בן אבי 
I was told, by our IBM person, that the official PTF we be made available on 
October 16th.
Gadi


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
Jake Anderson [justmainfra...@gmail.com]
Sent: 08 October 2015 17:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

So far we have the APAR, Any idea when we will be getting the GA PTF for
this ?

On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson  wrote:

> >What bugs me is that z/OS 1.13 systems are not exposed
> >to this defect yet IBM created an aparfix for 1.13.
>
> Any application, whether customer-owned, ISV-owned, or IBM-owned could be
> using this service (which has been in z/OS since z/OS 1.10).  IBM has no
> idea what might fit into those first two categories. Thus I would think it
> would be in everyone's best interest to get this PTF and apply it, if for
> no other reason than to avoid having to figure out if you truly care.
>
> The IBM use in LE apparently is new with z/OS 2.1.
>
> Peter Relson
> z/OS Core Technology Design
>
> --
> 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

לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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

Re: Issues while compiling SVC exit on Z1.10

2015-10-08 Thread Tony Harminc 
On 8 October 2015 at 00:47, Rakesh Kotha
<00cf1d6d10e9-dmarc-requ...@listserv.ua.edu> wrote:
> 10   0 11229+ L R15,C@$MSDDUMP-CADDR(R15,
> ** ASMA044E Undefined symbol - C@$MSDDUMP
> ** ASMA044E Undefined symbol - CADDR
> ** ASMA435I Record 1256 in SYS1.SHASMAC($HCCT) on volume: ZARES1

> i feel we need to use USING ($CADDRR) but not sure where.

A missing USING cannot provoke the ASMA044E message. Were the symbol
complained about defined, you would instead get one of several
possible messages relating to addressability or misuse of the symbol.

In JES2 code you should not be invoking JES2 mapping macros directly.
Rather, use the elegant infrastructure provided by the $MODULE macro.
It "knows" about the various dependencies among macros, including the
MVS ones as well as the JES2 set, and it will include corequisite
macros for you.

Tony H.

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

Re: Unicode services Red alert

2015-10-08 Thread Jake Anderson 
So far we have the APAR, Any idea when we will be getting the GA PTF for
this ?

On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson  wrote:

> >What bugs me is that z/OS 1.13 systems are not exposed
> >to this defect yet IBM created an aparfix for 1.13.
>
> Any application, whether customer-owned, ISV-owned, or IBM-owned could be
> using this service (which has been in z/OS since z/OS 1.10).  IBM has no
> idea what might fit into those first two categories. Thus I would think it
> would be in everyone's best interest to get this PTF and apply it, if for
> no other reason than to avoid having to figure out if you truly care.
>
> The IBM use in LE apparently is new with z/OS 2.1.
>
> Peter Relson
> z/OS Core Technology Design
>
> --
> 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: Unicode services Red alert

2015-10-08 Thread Peter Relson 
>What bugs me is that z/OS 1.13 systems are not exposed 
>to this defect yet IBM created an aparfix for 1.13.

Any application, whether customer-owned, ISV-owned, or IBM-owned could be 
using this service (which has been in z/OS since z/OS 1.10).  IBM has no 
idea what might fit into those first two categories. Thus I would think it 
would be in everyone's best interest to get this PTF and apply it, if for 
no other reason than to avoid having to figure out if you truly care.

The IBM use in LE apparently is new with z/OS 2.1.

Peter Relson
z/OS Core Technology Design

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

Re: Issues while compiling SVC exit on Z1.10

2015-10-08 Thread Staller, Allan 
From the JSE2 Macro Reference:

Table 8. JES2 DSECTIDs That Can Be Specified on $MODULE (continued)
DSECTID  MacrosDescription of Code Generated
$BFW  $BFW  3800 buffer work area DSECT
$BLDMSGL$BLDMBuild message parameter list DSECT
$BTG  $BTG  BADTRACK group element DSECT
$BUFFER  $BUFFEI/O buffer DSECT
$CADDR  $CADDR  Common storage address table DSECT
... remainder deleted

Specify $CADDR on the $MODULE macro that should be somewhere in your source 
code...

HTH,


I am trying to install a tool SOUTSYS(CBT358) but i am stuck at the JES SVC 
compilation.

The supplied code was for z1.4(very old one) but i am trying to install on 
z1.10. I tried contacting the Autohr but no luck. So, reaching out for help.

i ran into a problem in compiling a SVC (IGC0025B).

Here is my JCL.
//ASMSVC EXEC PGM=ASMA90,
// PARM='NODECK,OBJECT,XREF(SHORT),LIST' 
//SYSUT1 DD DSN=&&SYSUT1,SPACE=(4096,(120,120),,,ROUND),
// UNIT=SYSDA,DCB=BUFNO=1
//SYSLIN DD DUMMY HR,DSN=SOUTSYS.OBJLIB(IGC0025B) <=== //SYSLIB DD 
DSN=SOUTSYS.ASM,DISP=SHR,DCB=(BLKSIZE=9600)
// DD DSN=SOUTSYS.MACLIB,DISP=SHR,DCB=(BLKSIZE=27920)
// DD DISP=SHR,DSN=SYS1.SHASMAC
// DD DISP=SHR,DSN=SYS1.MACLIB
// DD DISP=SHR,DSN=SYS1.AMODGEN
//SYSPRINT DD SYSOUT=*
//SYSIN DD DSN=SOUTSYS.ASM(MVSGPSVC),DISP=SHR
//*
//LKEDSVC EXEC PGM=IEWL,REGION=2000K,COND=(4,LT,ASMSVC),
// PARM=(NCAL,LET,RENT,LIST,XREF)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=&&SYSUT1,UNIT=SYSDA,SPACE=(CYL,(20,20))
//OBJLIB DD DUMMY HR,DSN=SOUTSYS.OBJLIB <== //SYSLMOD DD 
DSN=SYS1.LPALIB,DISP=SHR //SYSLIN DD * NAME IGC0025B(R)
/*

fro syslib

SYS1.SHASMAC($HCCT)
000759 * LARL R11,HCCT Get HCCT address
000760 DC X'C0B0',AL4((HCCT-(CCTXMSRB+L'CCTXMSRB))/2)
000761 L R15,CCTCADDR-HCCT(R11,0) Get CADDR address
000762 L R15,C@XMXSRB-CADDR(R15,0) Get SRB address
000763 BR R15 and enter service
000764 SPACE 1


000456   0 10794+ L R15,C@XMXSRB-CADDR(R15,0)
** ASMA044E Undefined symbol - C@XMXSRB
** ASMA044E Undefined symbol - CADDR
** ASMA435I Record 763 in SYS1.SHASMAC($HCCT) on volume: ZARES1 00046A  
 0 10803+ L R15,C@XMXRMTR-CADDR(R15,0
** ASMA044E Undefined symbol - C@XMXRMTR
** ASMA044E Undefined symbol - CADDR
** ASMA435I Record 772 in SYS1.SHASMAC($HCCT) on volume: ZARES1
10   0 11229+ L R15,C@$MSDDUMP-CADDR(R15,
** ASMA044E Undefined symbol - C@$MSDDUMP
** ASMA044E Undefined symbol - CADDR
** ASMA435I Record 1256 in SYS1.SHASMAC($HCCT) on volume: ZARES1
28   0 11245+ L R15,C@$DYNLPA-CADDR(R15,0
-

i feel we need to use USING ($CADDRR) but not sure where.

Please help me.

Thanks in Advance

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

Creating AWS file from dataset on tape

2015-10-08 Thread גדי בן אבי 
Hi,

I would like to create AWS files from datasets on tape.

I found the AWSSL program on file 585 on the CBT.
This program can create AWS files, but cannot read files on tape.

There are also some program in file 533 that are named VTT2.

Can these files be used to read a tape file, by name, and create an AWS file?

The purpose of this exercise is the final step in a Mainframe migration 
project. The customer would like to save files on tape that might be needed in 
the future.

Gadi


לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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

Re: How the determine dataset is PDSE

2015-10-08 Thread Henn, Karl 
Like this, I'd say.

...
 MVC   ISITM_W(ISITM_L),ISITM_C
 ISITMGD DCB=DCB1,MF=(E,ISITM_W)
 USING ISM,R1
 STR15,ISIT_RC SAVE RETURN CODE
 STR0,ISIT_RSN SAVE REASON CODE
 LTR   R15,R15 ISTSMGD OK?
 BNZ   ... NO
 TMISMOFLG2,ISMPDSEPDSE?
 BNO   ... NO
...
ISITM_C  ISITMGD MF=L   
ISITM_L  EQU   *-ISITM_C
...
* 
ISITM_W  DSXL(ISITM_L)
... 
 IGWCISM ,
...

Regards

Karl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Savor, Thomas (Norcross)
Sent: Monday, October 05, 2015 9:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How the determine dataset is PDSE

>Looks like the ISITMGD macro/system service can ascertain if a dataset is a 
>PDSE.
Hummlooks very interesting.
Hate to admit it, but I never heard of this macro...but I'm going to try it out 
and see.

Thanks,
Tom

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