Re: Moving from NJE over ESCON CTC to IP

[Alan(GMAIL)Watthey]

Dave,

There must be a reason why are you using the hipersocket IP address and not
just the default TCPIP stack IP address and perhaps this is where your
problem lies.  Could this just be a simple TCPIP routing issue?  It sounds
like you know you have a route from this z/OS system to 192.169.1.3 (using
the hipersocket).

However, when NJE starts a session it gives the packet an origin IP address.
The value of this is completely controlled by you (or your network guy).  It
could be the default for this TCPIP stack or it could be something you have
specified on a SRCIP statement or in a BIND parameter.

Is this origin IP address routable from the other z/OS?  When sending a
response to your signon request it will send it back to this origin IP
address so it must have a route to it.  If not the packet will go who knows
where.  Maybe the default route out the OSA where it hits a firewall.

If you are planning on using 192.168.1.x for all NJE communication then
maybe you need to specify each z/OS system's hipersocket IP address as the
origin.  Alternatively, don't use SOURCEVIPA at all for the hipersocket
interface.

Of course if this is your problem the solution depends completely upon your
network design and where packets might route during interface outages.

Regards,
Alan.


-Original Message-
From: Gibney, Dave [mailto:gib...@wsu.edu] 
Sent: 01 November 2017 10:51 pm
Subject: Moving from NJE over ESCON CTC to IP

I think I've done an equivalent set of JESPARMS, but I get this
  $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
 Port: 175 Initiated
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
 Port: 175 Successful
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
 srcpos02.ad.wsu.edu
Port: 175 ended due to failure of NJETCP Signon to complete within
allotted time

For all connection. The 192.168.1 network is over Hipersocket

Undoubtably, I am missing something simple in the TFM

Dave Gibney
Information Technology Services
Washington State University


--
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: Odd HCD/IODF issue with "space"

[Steve Beaver]

Are you out of extents?

Sent from my iPhone

Sorry for any grammar problems 

> On Nov 1, 2017, at 20:52, Feller, Paul  wrote:
> 
> No there is lots of room on the DASD volume.  The volume is only 35% used.
> 
> Thanks..
> 
> Paul Feller
> AGT Mainframe Technical Support
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Nims,Alva John (Al)
> Sent: Wednesday, November 01, 2017 16:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Odd HCD/IODF issue with "space"
> 
> Did you check the DASD volume that SYS0.IODF60.WORK is on?  Maybe the DASD 
> volume is out of space.
> 
> Al Nims
> Systems Admin/Programmer 3
> UFIT
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Feller, Paul
> Sent: Tuesday, October 31, 2017 6:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Odd HCD/IODF issue with "space"
> 
> I have not run across this issue before when using HCD.  This is a z/OS 2.2 
> system.  The IODF has two z13 boxes and a z13s (CF) box.  There are 27 lpars 
> across the three boxes, that's counting the CFs.  I would say we are an 
> average size shop when it comes to the number of IO devices and channels.  We 
> don't try to be to creative when it comes to the IODF.
> 
> I was correcting some issues with esoterics that are missing some DASD 
> devices when I ran across this error.  The first time I did increase the size 
> of the work file from 1024 to 2048 blocks.  I had then cleaned up some 
> esoterics that had devices defined that didn't need them.  When I got the 
> error a second time I was surprised.  I saved what I was doing and got out of 
> HCD.  I went back in and was able to make more changes until I got the error 
> a third time.  I repeated the save/exit/enter process.  Again I was able to 
> make more changes.  I think I had to do this save/exit/enter process maybe 
> two more times.  The whole time the "size/usage" of the work file did not 
> change.
> 
> So back to my question, has anyone run across this type of issue?  Did you 
> have to do the same type of "process" to get things done?  Here is an odd 
> question.  Is there a way to reorg (reclaim space) an IODF file?
> 
> 
> CBDA563I Space exhausted in work IODF SYS0.IODF60.WORK.
> 
> Explanation:
> A definition record is being added to the work IODF, but there is  no space 
> left to complete the function.
> 
> This condition may not only occur during Add and Connect actions  but also 
> during Update, Disconnect and Delete actions when device  groups of a version 
> 5 IODF must be temporarily split to perform the  operation.
> 
> System Action:
> In Dialog mode, system waits for user action. In Migration mode,  processing 
> terminates. The IODF is not updated.
> 
> User Response:
> Extend the IODF (for example with the COPY IODF function) and rerun  the 
> action.
> - end -
> 
> 
> IODF name  . . . . . . : 'SYS0.IODF60.WORK'
> IODF type  . . . . . . : Work
> IODF version . . . . . : 5
> 
> Creation date  . . . . : 2017-10-31
> Last update  . . . . . : 2017-10-31  13:52
> 
> Volume serial number . : OSS001
> Allocated space  . . . : 2048(Number of 4K blocks)
> Used space . . . . . . : 2048(Number of 4K blocks)
>   thereof utilized (%)  33
> Activity logging . . . : Yes
> Multi-user access  . . : No
> Backup IODF name . . . :
> 
> Description  . . . . . : All DASD and some other devices have 31 bit
> UCBs -- IODF Version 5 format --
> 
> 
> 
> Processor ID . . . : SYSB IBM 2964-N30 (508)
> 
>  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3
> / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual
> _ 0   65280 23158   65535 453665535 0   65535 0
> 
> Processor ID . . . : SYSC IBM 2964-N30 (608)
> 
>  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3
> / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual
> _ 0   65280 23110   65535 453665535 0   65535 0
> 
> 
> 
> Thanks..
> 
> Paul Feller
> AGT Mainframe Technical Support
> 
> 
> 
> --
> 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 

Re: Odd HCD/IODF issue with "space"

[Feller, Paul]

No there is lots of room on the DASD volume.  The volume is only 35% used.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Wednesday, November 01, 2017 16:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd HCD/IODF issue with "space"

Did you check the DASD volume that SYS0.IODF60.WORK is on?  Maybe the DASD 
volume is out of space.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Feller, Paul
Sent: Tuesday, October 31, 2017 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Odd HCD/IODF issue with "space"

I have not run across this issue before when using HCD.  This is a z/OS 2.2 
system.  The IODF has two z13 boxes and a z13s (CF) box.  There are 27 lpars 
across the three boxes, that's counting the CFs.  I would say we are an average 
size shop when it comes to the number of IO devices and channels.  We don't try 
to be to creative when it comes to the IODF.

I was correcting some issues with esoterics that are missing some DASD devices 
when I ran across this error.  The first time I did increase the size of the 
work file from 1024 to 2048 blocks.  I had then cleaned up some esoterics that 
had devices defined that didn't need them.  When I got the error a second time 
I was surprised.  I saved what I was doing and got out of HCD.  I went back in 
and was able to make more changes until I got the error a third time.  I 
repeated the save/exit/enter process.  Again I was able to make more changes.  
I think I had to do this save/exit/enter process maybe two more times.  The 
whole time the "size/usage" of the work file did not change.

So back to my question, has anyone run across this type of issue?  Did you have 
to do the same type of "process" to get things done?  Here is an odd question.  
Is there a way to reorg (reclaim space) an IODF file?


CBDA563I Space exhausted in work IODF SYS0.IODF60.WORK.

Explanation:
 A definition record is being added to the work IODF, but there is  no space 
left to complete the function.

 This condition may not only occur during Add and Connect actions  but also 
during Update, Disconnect and Delete actions when device  groups of a version 5 
IODF must be temporarily split to perform the  operation.

System Action:
 In Dialog mode, system waits for user action. In Migration mode,  processing 
terminates. The IODF is not updated.

User Response:
 Extend the IODF (for example with the COPY IODF function) and rerun  the 
action.
- end -


IODF name  . . . . . . : 'SYS0.IODF60.WORK'
IODF type  . . . . . . : Work
IODF version . . . . . : 5

Creation date  . . . . : 2017-10-31
Last update  . . . . . : 2017-10-31  13:52

Volume serial number . : OSS001
Allocated space  . . . : 2048(Number of 4K blocks)
Used space . . . . . . : 2048(Number of 4K blocks)
   thereof utilized (%)  33
Activity logging . . . : Yes
Multi-user access  . . : No
Backup IODF name . . . :

Description  . . . . . : All DASD and some other devices have 31 bit
 UCBs -- IODF Version 5 format --



Processor ID . . . : SYSB IBM 2964-N30 (508)

  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3
/ ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual
_ 0   65280 23158   65535 453665535 0   65535 0

Processor ID . . . : SYSC IBM 2964-N30 (608)

  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3
/ ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual
_ 0   65280 23110   65535 453665535 0   65535 0



Thanks..

Paul Feller
AGT Mainframe Technical Support



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

What happened to IEBCPARM?

[Tony Harminc]

This macro is documented as mapping the argument list and exit parameters
for the various IEB utilities (well, at least IEBCOPY), and that doc is
referenced elsewhere, e.g. by AMATERSE in the Service Aids book. In
particular, it provides the only evident standard mapping for the order of
DDNAME overrides that are supported by lots of programs and documented
individually with each program.

But the macro itself is gone from SYS1.MACLIB in z/OS 2.2 and 2.3, and I
don't see it anywhere else obvious. I find  a 2013 APAR OA42488 that added
it to earlier z/OS versions, and IEBCPARM *is* present on a 2.1 system
here, but *poof*!

I have neither the time, need, or interest to re-APAR it, but maybe there
is some more interesting (or not) explanation of where it went.

Tony H.

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

Re: Help with a Unix process

[Andrew Rowley]

On 01/11/2017 07:44 PM, Pew, Curtis G wrote:

I would be surprised if anything you put together like this would perform any 
better than `find’. Searching large Unix directories is typically pretty slow 
no matter how you go about it. (If you’re still using HFS that’s probably 
particularly true; I understand that zFS directory searches are faster.)

Yes, I think any other method would suffer the same performance 
limitations as find. The advantage of find is that (from memoy) it is 
smart enough to tell you where it found each file, while something like 
ls -R ... | grep ... is liable to give you a list of filenames with no 
information about their actual location.


This question does illustrate why I dislike the IBM suggestion of 
individual automounted home directories so much - if your search 
includes automounted directories, every single one must be mounted. If 
you reckon directory seaches are slow, try HSM recalling filesystems one 
at a time...


--

Andrew Rowley

Black Hill Software

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

Re: call IKJEFT1B from an assembler program

[Mike Schwab]

That would be in your TSOx PROCLIB member.

On Wed, Nov 1, 2017 at 11:37 AM, PINION, RICHARD W.
 wrote:
> I've shifted gears and I am using IKJTSOEV, things are looking a little 
> better.
> However, I received " IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS 
> ALLOWED BY YOUR SESSION HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS".  
> In JCL I would use the DYNAMNBR,
> but for IKJTSOEV how would I set this?  I have debugging turned on
> in the REXX and can see the failure is on an ALLOC command.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John McKown
> Sent: Wednesday, November 01, 2017 11:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: call IKJEFT1B from an assembler program
>
> [External Email]
>
> On Wed, Nov 1, 2017 at 10:19 AM, PINION, RICHARD W. < 
> rpin...@firsttennessee.com> wrote:
>
>> Would someone be so kind as to give me an example of calling IKJEFT1B
>> from an assembler program.  The CALL macro I am using is passing
>> control to IKJEFT1B, but I receive "IKJ56600I UNRECOVERABLE COMMAND
>> SYSTEM ERROR".  I'm assuming the parameters I am passing are
>> incorrect.  And, no my need is not to invoke it directly from JCL via
>> //STEP010 EXEC PGM=IKJEFT1B.
>> FIRST TENNESSEE
>>
>>
> there has been some recent discussion about how IKJEFT01 and it's aliases 
> (IKJEFT1A & IKJEFT1B) should _not_ be invoked by anything other that EXEC 
> PGM= or via the "TMP session manager". Of course, you are free to do whatever 
> you need to do to "get the job done". I am curious if, instead, you could use 
> the "TSO Environment Services" (IKJTSOEV) as  documented at:
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb700/whenuse.htm
>
>
> Also, just because I'm curious, what are you trying to accomplish (at a high 
> level, details not needed).
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove it.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> FIRST TENNESSEE
>
> Confidentiality notice:
> This e-mail message, including any attachments, may contain legally 
> privileged and/or confidential information. If you are not the intended 
> recipient(s), or the employee or agent responsible for delivery of this 
> message to the intended recipient(s), you are hereby notified that any 
> dissemination, distribution, or copying of this e-mail message is strictly 
> prohibited. If you have received this message in error, please immediately 
> notify the sender and delete this e-mail message from your computer.
>
>
> --
> 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: Odd HCD/IODF issue with "space"

[Nims,Alva John (Al)]

Did you check the DASD volume that SYS0.IODF60.WORK is on?  Maybe the DASD 
volume is out of space.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Feller, Paul
Sent: Tuesday, October 31, 2017 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Odd HCD/IODF issue with "space"

I have not run across this issue before when using HCD.  This is a z/OS 2.2 
system.  The IODF has two z13 boxes and a z13s (CF) box.  There are 27 lpars 
across the three boxes, that's counting the CFs.  I would say we are an average 
size shop when it comes to the number of IO devices and channels.  We don't try 
to be to creative when it comes to the IODF.

I was correcting some issues with esoterics that are missing some DASD devices 
when I ran across this error.  The first time I did increase the size of the 
work file from 1024 to 2048 blocks.  I had then cleaned up some esoterics that 
had devices defined that didn't need them.  When I got the error a second time 
I was surprised.  I saved what I was doing and got out of HCD.  I went back in 
and was able to make more changes until I got the error a third time.  I 
repeated the save/exit/enter process.  Again I was able to make more changes.  
I think I had to do this save/exit/enter process maybe two more times.  The 
whole time the "size/usage" of the work file did not change.

So back to my question, has anyone run across this type of issue?  Did you have 
to do the same type of "process" to get things done?  Here is an odd question.  
Is there a way to reorg (reclaim space) an IODF file?


CBDA563I Space exhausted in work IODF SYS0.IODF60.WORK.

Explanation:
 A definition record is being added to the work IODF, but there is  no space 
left to complete the function.

 This condition may not only occur during Add and Connect actions  but also 
during Update, Disconnect and Delete actions when device  groups of a version 5 
IODF must be temporarily split to perform the  operation.

System Action:
 In Dialog mode, system waits for user action. In Migration mode,  processing 
terminates. The IODF is not updated.

User Response:
 Extend the IODF (for example with the COPY IODF function) and rerun  the 
action.
- end -


IODF name  . . . . . . : 'SYS0.IODF60.WORK'
IODF type  . . . . . . : Work
IODF version . . . . . : 5

Creation date  . . . . : 2017-10-31
Last update  . . . . . : 2017-10-31  13:52

Volume serial number . : OSS001
Allocated space  . . . : 2048(Number of 4K blocks)
Used space . . . . . . : 2048(Number of 4K blocks)
   thereof utilized (%)  33
Activity logging . . . : Yes
Multi-user access  . . : No
Backup IODF name . . . :

Description  . . . . . : All DASD and some other devices have 31 bit
 UCBs -- IODF Version 5 format --



Processor ID . . . : SYSB IBM 2964-N30 (508)

  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3
/ ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual
_ 0   65280 23158   65535 453665535 0   65535 0

Processor ID . . . : SYSC IBM 2964-N30 (608)

  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3
/ ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual
_ 0   65280 23110   65535 453665535 0   65535 0



Thanks..

Paul Feller
AGT Mainframe Technical Support



--
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: Help with a Unix process

[Lizette Koehler]

See how well I understand Unix?   ;-O

Yes - what you wrote - I have a directory with a huge bunch of directories under
it

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Don Poitras
> Sent: Wednesday, November 01, 2017 1:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Help with a Unix process
> 
> Probably a silly question, but are you really searching from the root, or
> doing something like:
> 
> find /The/Actual/Parent/Dir/I/Am/Looking/At/ -name '*.new'
> 
> In article <048f01d35337$b7b4c320$271e4960$@mindspring.com> you wrote:
> > So I am not very good with Unix, and now I need to find any file in a
> > large number of directories one directory has 130 directories with the
> > tail .new (yep clean up time) So in OMVS I know the find / -name
> > \*.new could work.  But with the number of directories I have to
> > search it is not performing I am thinking there could be a REXX in
> > Unix written to do this.  ls -al and then search through the output
> > Maybe even using a grep.
> > But with so many of you other there with really awesome UNIX skills,
> > what should I, a novice, look at to be good performing, could be run
> > in batch (Yep like that
> > option) or produce a report in a file I can find that will show me all
> > the files in all the directories that have the tail I am looking for.
> > Thanks
> > Lizette Koehler
> 
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
> 

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

Re: Moving from NJE over ESCON CTC to IP

[Cieri, Anthony]

The only other thing that I can think of is an entry in the 
/etc/services or equivalent!!!

vmnet   175/tcp # JES NJE over TCP/IP   



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Wednesday, November 01, 2017 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Moving from NJE over ESCON CTC to IP

All ove the internal Hipersocket inside the CEC network.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Cieri, Anthony
> Sent: Wednesday, November 01, 2017 1:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
>   Is the new IP path traversing any Firewalls???
> 
>   If so, Port 175 will need to be opened between the end points!
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gibney, Dave
> Sent: Wednesday, November 01, 2017 4:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
> Using EJES,
> LINES -- DELENN Line Status 
> --
> - Row 1 of
> Cmd Device   Status   Node Work-Selection   Line-Limit Page-Limit JobName
> JobIDOwnerCurLines TotLines ApplID   Unit
> sss /   ss ss 
>       
> LNE1 ACTIVE
> TCP
> LNE2 ACTIVE
> TCP
> LNE3 ACTIVE
> TCP
> LNE4 ACTIVE
> TCP
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Cieri, Anthony
> > Sent: Wednesday, November 01, 2017 1:15 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Moving from NJE over ESCON CTC to IP
> >
> > Dave,
> >
> > My first thought would be to check for some "available" UNIT=TCP
> > Jes2 lines.
> >
> > Hth
> > Tony
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > Sent: Wednesday, November 01, 2017 3:51 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Moving from NJE over ESCON CTC to IP
> >
> > I think I've done an equivalent set of JESPARMS, but I get this
> >   $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 
> > 192.168.1.3
> >  Port: 175 Initiated
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 
> > 192.168.1.3
> >  Port: 175 Successful
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
> >  srcpos02.ad.wsu.edu
> > Port: 175 ended due to failure of NJETCP Signon to complete within 
> > allotted time
> >
> > For all connection. The 192.168.1 network is over Hipersocket
> >
> > Undoubtably, I am missing something simple in the TFM
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >
> > 
> > -- 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: Moving from NJE over ESCON CTC to IP

[Gibney, Dave]

All ove the internal Hipersocket inside the CEC network.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Cieri, Anthony
> Sent: Wednesday, November 01, 2017 1:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
>   Is the new IP path traversing any Firewalls???
> 
>   If so, Port 175 will need to be opened between the end points!
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Wednesday, November 01, 2017 4:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
> Using EJES,
> LINES -- DELENN Line Status 
> --
> - Row 1 of
> Cmd Device   Status   Node Work-Selection   Line-Limit Page-Limit JobName
> JobIDOwnerCurLines TotLines ApplID   Unit
> sss /   ss ss 
>      
> LNE1 ACTIVE
> TCP
> LNE2 ACTIVE
> TCP
> LNE3 ACTIVE
> TCP
> LNE4 ACTIVE
> TCP
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Cieri, Anthony
> > Sent: Wednesday, November 01, 2017 1:15 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Moving from NJE over ESCON CTC to IP
> >
> > Dave,
> >
> > My first thought would be to check for some "available" UNIT=TCP
> > Jes2 lines.
> >
> > Hth
> > Tony
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Gibney, Dave
> > Sent: Wednesday, November 01, 2017 3:51 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Moving from NJE over ESCON CTC to IP
> >
> > I think I've done an equivalent set of JESPARMS, but I get this
> >   $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
> >  Port: 175 Initiated
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
> >  Port: 175 Successful
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
> >  srcpos02.ad.wsu.edu
> > Port: 175 ended due to failure of NJETCP Signon to complete within
> > allotted time
> >
> > For all connection. The 192.168.1 network is over Hipersocket
> >
> > Undoubtably, I am missing something simple in the TFM
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >
> > --
> > 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: Moving from NJE over ESCON CTC to IP

[Cieri, Anthony]

Is the new IP path traversing any Firewalls???

If so, Port 175 will need to be opened between the end points!



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Wednesday, November 01, 2017 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Moving from NJE over ESCON CTC to IP

Using EJES,
LINES -- DELENN Line Status 
---
 Row 1 of
Cmd Device   Status   Node Work-Selection   Line-Limit Page-Limit JobName  
JobIDOwnerCurLines TotLines ApplID   Unit
sss /   ss ss  
     
LNE1 ACTIVE 
TCP 
LNE2 ACTIVE 
TCP 
LNE3 ACTIVE 
TCP 
LNE4 ACTIVE 
TCP

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Cieri, Anthony
> Sent: Wednesday, November 01, 2017 1:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
>   Dave,
> 
>   My first thought would be to check for some "available" UNIT=TCP
> Jes2 lines.
> 
>   Hth
>   Tony
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gibney, Dave
> Sent: Wednesday, November 01, 2017 3:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Moving from NJE over ESCON CTC to IP
> 
> I think I've done an equivalent set of JESPARMS, but I get this
>   $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
>   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
>  Port: 175 Initiated
>   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
>  Port: 175 Successful
>   IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
>  srcpos02.ad.wsu.edu
> Port: 175 ended due to failure of NJETCP Signon to complete within 
> allotted time
> 
> For all connection. The 192.168.1 network is over Hipersocket
> 
> Undoubtably, I am missing something simple in the TFM
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
> --
> 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: Moving from NJE over ESCON CTC to IP

[Gibney, Dave]

It's clear to me that I am missing the "allow signon"  piece. The connections 
are being made, but some handhake is failing.
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.1 
 Port: 175 Successful  
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.2 
 Port: 175 Initiated   
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.2 
 Port: 175 Successful  
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.2 
 Port: 
1059 ended due to failure of NJETCP Signon to complete within  
allotted time  
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.1 
 Port: 
175 ended due to failure of NJETCP Signon to complete within allotted  
time   
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.2 
 Port: 
175 ended due to failure of NJETCP Signon to complete within allotted  
time   

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Wednesday, November 01, 2017 1:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
> Using EJES,
> LINES -- DELENN Line Status 
> --
> - Row 1 of
> Cmd Device   Status   Node Work-Selection   Line-Limit Page-Limit JobName
> JobIDOwnerCurLines TotLines ApplID   Unit
> sss /   ss ss 
>      
> LNE1 ACTIVE
> TCP
> LNE2 ACTIVE
> TCP
> LNE3 ACTIVE
> TCP
> LNE4 ACTIVE
> TCP
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Cieri, Anthony
> > Sent: Wednesday, November 01, 2017 1:15 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Moving from NJE over ESCON CTC to IP
> >
> > Dave,
> >
> > My first thought would be to check for some "available" UNIT=TCP
> > Jes2 lines.
> >
> > Hth
> > Tony
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Gibney, Dave
> > Sent: Wednesday, November 01, 2017 3:51 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Moving from NJE over ESCON CTC to IP
> >
> > I think I've done an equivalent set of JESPARMS, but I get this
> >   $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
> >  Port: 175 Initiated
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
> >  Port: 175 Successful
> >   IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
> >  srcpos02.ad.wsu.edu
> > Port: 175 ended due to failure of NJETCP Signon to complete within
> > allotted time
> >
> > For all connection. The 192.168.1 network is over Hipersocket
> >
> > Undoubtably, I am missing something simple in the TFM
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >
> > --
> > 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: Moving from NJE over ESCON CTC to IP

[Gibney, Dave]

Using EJES,
LINES -- DELENN Line Status 
---
 Row 1 of
Cmd Device   Status   Node Work-Selection   Line-Limit Page-Limit JobName  
JobIDOwnerCurLines TotLines ApplID   Unit
sss /   ss ss  
     
LNE1 ACTIVE 
TCP 
LNE2 ACTIVE 
TCP 
LNE3 ACTIVE 
TCP 
LNE4 ACTIVE 
TCP

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Cieri, Anthony
> Sent: Wednesday, November 01, 2017 1:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Moving from NJE over ESCON CTC to IP
> 
>   Dave,
> 
>   My first thought would be to check for some "available" UNIT=TCP
> Jes2 lines.
> 
>   Hth
>   Tony
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Wednesday, November 01, 2017 3:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Moving from NJE over ESCON CTC to IP
> 
> I think I've done an equivalent set of JESPARMS, but I get this
>   $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
>   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
>  Port: 175 Initiated
>   IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
>  Port: 175 Successful
>   IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
>  srcpos02.ad.wsu.edu
> Port: 175 ended due to failure of NJETCP Signon to complete within allotted
> time
> 
> For all connection. The 192.168.1 network is over Hipersocket
> 
> Undoubtably, I am missing something simple in the TFM
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
> --
> 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: Help with a Unix process

[Jack J. Woehr]

On 11/1/2017 11:34 AM, Lizette Koehler wrote:


So in OMVS I know the find / -name \*.new could work.


Do you always want to start the search from / ?

--

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: Help with a Unix process

[Roach, Dennis]

My favorite is to use IRRHFSU to produce a file of everything currently 
mounted. Process the file with OBROWSE or OEDIT an use the find command.

Dennis Roach, CISSP
AIG

Identity & Access Management | Technology Services

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-591-1059 (cell)

dennis.ro...@aig.com | www.aig.com 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, November 01, 2017 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with a Unix process

On Wed, 1 Nov 2017 19:44:35 +, Pew, Curtis G wrote:
>On Nov 1, 2017, at 12:34 PM, Lizette Koehler wrote:
>> 
>> So I am not very good with Unix, and now I need to find any file in a 
>> large number of directories one directory has 130 directories with 
>> the tail .new (yep clean up time)  ...
>
>I would be surprised if anything you put together like this would 
>perform any better than `find’. Searching large Unix directories is 
>typically pretty slow no matter how you go about it. (If you’re still 
>using HFS that’s probably particularly true; I understand that zFS 
>directory searches are faster.)
>
I agree.  But has anyone ported the GNU "locate" command to z/OS?
http://man7.org/linux/man-pages/man1/locate.1.html

-- gil

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


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

Re: Help with a Unix process

[Don Poitras]

Probably a silly question, but are you really searching from the root, or
doing something like:

find /The/Actual/Parent/Dir/I/Am/Looking/At/ -name '*.new'

In article <048f01d35337$b7b4c320$271e4960$@mindspring.com> you wrote:
> So I am not very good with Unix, and now I need to find any file in a large
> number of directories one directory has 130 directories with the tail .new 
> (yep
> clean up time)
> So in OMVS I know the find / -name \*.new could work.  But with the number of
> directories I have to search it is not performing
> I am thinking there could be a REXX in Unix written to do this.  ls -al and 
> then
> search through the output
> Maybe even using a grep.
> But with so many of you other there with really awesome UNIX skills, what 
> should
> I, a novice, look at to be good performing, could be run in batch (Yep like 
> that
> option) or produce a report in a file I can find that will show me all the 
> files
> in all the directories that have the tail I am looking for.
> Thanks
> Lizette Koehler

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

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

Re: Moving from NJE over ESCON CTC to IP

[Cieri, Anthony]

Dave, 

My first thought would be to check for some "available" UNIT=TCP Jes2 
lines. 

Hth
Tony 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Wednesday, November 01, 2017 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Moving from NJE over ESCON CTC to IP

I think I've done an equivalent set of JESPARMS, but I get this
  $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
 Port: 175 Initiated
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
 Port: 175 Successful
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
 srcpos02.ad.wsu.edu
Port: 175 ended due to failure of NJETCP Signon to complete within allotted time

For all connection. The 192.168.1 network is over Hipersocket

Undoubtably, I am missing something simple in the TFM

Dave Gibney
Information Technology Services
Washington State University


--
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: Help with a Unix process

[Paul Gilmartin]

On Wed, 1 Nov 2017 19:44:35 +, Pew, Curtis G wrote:
>On Nov 1, 2017, at 12:34 PM, Lizette Koehler wrote:
>> 
>> So I am not very good with Unix, and now I need to find any file in a large
>> number of directories one directory has 130 directories with the tail .new 
>> (yep
>> clean up time)  ...
>
>I would be surprised if anything you put together like this would perform any 
>better than `find’. Searching large Unix directories is typically pretty slow 
>no matter how you go about it. (If you’re still using HFS that’s probably 
>particularly true; I understand that zFS directory searches are faster.)
>
I agree.  But has anyone ported the GNU "locate" command to z/OS?
http://man7.org/linux/man-pages/man1/locate.1.html

-- gil

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

Moving from NJE over ESCON CTC to IP

[Gibney, Dave]

I think I've done an equivalent set of JESPARMS, but I get this
  $HASP568 NODE=AISDEVL - AUTOMATIC CONNECT (SOCKET=AISDEVL)
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
 Port: 175 Initiated
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr: 192.168.1.3
 Port: 175 Successful
  IAZ0543I NETSRV4 TCP/IP connection with IP Addr:
 srcpos02.ad.wsu.edu
Port: 175 ended due to failure of NJETCP Signon to complete within
allotted time

For all connection. The 192.168.1 network is over Hipersocket

Undoubtably, I am missing something simple in the TFM

Dave Gibney
Information Technology Services
Washington State University


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

Re: Help with a Unix process

[Pew, Curtis G]

On Nov 1, 2017, at 12:34 PM, Lizette Koehler  wrote:
> 
> So I am not very good with Unix, and now I need to find any file in a large
> number of directories one directory has 130 directories with the tail .new 
> (yep
> clean up time)
> 
> So in OMVS I know the find / -name \*.new could work.  But with the number of
> directories I have to search it is not performing
> 
> I am thinking there could be a REXX in Unix written to do this.  ls -al and 
> then
> search through the output
> 
> Maybe even using a grep.
> 
> But with so many of you other there with really awesome UNIX skills, what 
> should
> I, a novice, look at to be good performing, could be run in batch (Yep like 
> that
> option) or produce a report in a file I can find that will show me all the 
> files
> in all the directories that have the tail I am looking for.

I would be surprised if anything you put together like this would perform any 
better than `find’. Searching large Unix directories is typically pretty slow 
no matter how you go about it. (If you’re still using HFS that’s probably 
particularly true; I understand that zFS directory searches are faster.)

-- 
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: Why not SYSSYM=ALLOW?

[Pew, Curtis G]

On Nov 1, 2017, at 1:22 PM, Jesse 1 Robinson  wrote:
> 
> In the big view, system symbols are over 20 years old. For many years, 
> symbols were honored for STC and TSU but not for batch. IBM was reluctant to 
> support batch for reasons mentioned by Lizette and others. I participated in 
> more than one open discussion at SHARE where different folks had very 
> convincing reasons for symbols to be substituted in various incompatible 
> ways. But symbols had to be managed in only one way, and there was forceful 
> disagreement.
> 
> So IBM left it up to the customer whether to honor symbols in batch. If it 
> works for you, turn it on. Otherwise don't. But you should move gradually. Be 
> prepared to back out. Since system symbols in batch are a (relatively) new 
> thing, you need to verify that in your environment you get the results you 
> expect. Caveat emptor.  


Thanks for all the responses. If you care about why I asked, I’ll add an 
explanation. Feel free to skip the rest of this if you don’t care.



Almost 20 years ago we wrote our own, in-house batch scheduling system. It 
doesn’t require analysts to write JCL; they enter the characteristics for their 
jobs, steps, and data definitions via forms and then the scheduling system 
generates the JCL at submission time. Today, there is very little hand-written 
JCL in our environment.

This is great, but our system doesn’t integrate very well with non-mainframe 
processes, and that sort of integration is becoming increasingly important. 
We’ve acquired a commercial job scheduling system (Stonebranch Universal 
Automation Controller, if it matters) which handles that kind of integration 
well but of course doesn’t generate JCL.

Our in-house system is able to include things like time stamps at certain 
places when it generates the JCL, but anything that uses UAC won’t have that, 
so I was investigating the possibility of using system symbols. Since we only 
have a single LPAR and so little user-written JCL, I think we should be able to 
do this without many problems.

Thanks again.

-- 
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: Db2! was: NODE.js for z/OS (21)

[Walt Farrell]

On Wed, 1 Nov 2017 17:17:16 +0800, Timothy Sipples  wrote:

>The b is lowercase, but the Z is now uppercase. Have a look:
>
>https://www.ibm.com/analytics/us/en/db2/db2-for-zos/
>
>https://www.ibm.com/systems/z/

The z is still lowercase in z/OS, though :)

-- 
Walt

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

Re: Help with a Unix process

[Cieri, Anthony]

Hi Lizette, 

I don't have a rexx handy, but you can simple use the ls and grep 
commands that you mentioned. For example:

ls -R | grep '.*.tar'  

this would list all file from the current directory (and 
subdirectories) that contain the characters 'tar' . The output would be 
presented on the screen. If you wanted a "report" ike option, you could pipe 
the output of the previous command to a file. For example:

ls -R | grep '.*.tar' > ./list.txt

Same results as the previous example, but the output would be in a file 
named list.txt in the current directory.

If am not sure about the performance of ls/grep versus find, but you 
could start in smaller subdirectories and work your way back to the top or stop 
when the performance become intolerable!!

Hth 
Tony 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, November 01, 2017 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help with a Unix process

So I am not very good with Unix, and now I need to find any file in a large 
number of directories one directory has 130 directories with the tail .new (yep 
clean up time)

So in OMVS I know the find / -name \*.new could work.  But with the number of 
directories I have to search it is not performing

I am thinking there could be a REXX in Unix written to do this.  ls -al and 
then search through the output

Maybe even using a grep.

But with so many of you other there with really awesome UNIX skills, what 
should I, a novice, look at to be good performing, could be run in batch (Yep 
like that
option) or produce a report in a file I can find that will show me all the 
files in all the directories that have the tail I am looking for.

Thanks




Lizette Koehler

--
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: Why not SYSSYM=ALLOW?

[Jesse 1 Robinson]

In the big view, system symbols are over 20 years old. For many years, symbols 
were honored for STC and TSU but not for batch. IBM was reluctant to support 
batch for reasons mentioned by Lizette and others. I participated in more than 
one open discussion at SHARE where different folks had very convincing reasons 
for symbols to be substituted in various incompatible ways. But symbols had to 
be managed in only one way, and there was forceful disagreement.

So IBM left it up to the customer whether to honor symbols in batch. If it 
works for you, turn it on. Otherwise don't. But you should move gradually. Be 
prepared to back out. Since system symbols in batch are a (relatively) new 
thing, you need to verify that in your environment you get the results you 
expect. Caveat emptor.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, November 01, 2017 7:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Why not SYSSYM=ALLOW?

So this may or may not apply

You have 3 LPARs in a plex.  They all share a JES2 MAS

Job A is submitted on LPAR1 but is converted on LPAR2. The symbols the job 
needs is only on LPAR1 - so the conversion on LPAR2 will either get wrong 
symbols or no symbols.

If your single LPAR, you probably do not need to worry as much.

If you more LPARs in a PLEX and the potential for symbols to be different on 
them, and jobs can convert anywhere, you might have some challenges.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pew, Curtis G
> Sent: Wednesday, November 01, 2017 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Why not SYSSYM=ALLOW?
> 
> On Oct 31, 2017, at 6:06 PM, Paul Gilmartin <000433f07816-dmarc- 
> requ...@listserv.ua.edu> wrote:
> >
> > Unintended substitution of symbols where programmers were too lazy 
> > to double ampersands where proper.
> 
> That makes sense, and shouldn’t be a problem for us.
> 
> Thanks.
> 
> --
> 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: DFHSM Migrate

[Bill Johnson]

Yeah, getting warm. Looks like we might not have any ML1 to migrate to. User 
(and me) unaware.


Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 1:50 PM, Lizette Koehler 
 wrote:

So what we did is to have an email sent when this message

  ARC0160I MIGRATION=LIMITED, AUTOMIGRATION=LIMITED, 
  ARC0560E MIGRATION LIMITED:



Find out when the migration limited message first appeared in the HSM JOB LOG 
or SYSLOG and see what resource caused the message.

LIMITED indicates that when DFSMShsm finds that the migration target device is 
not available, data set migration is limited to those data sets assigned to the 
available target devices. Data sets targeted to the unavailable device type 
will not be migrated.



Lizette


> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Bill Johnson
> > Sent: Wednesday, November 01, 2017 9:17 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: DFHSM Migrate
> >
> > Trying to migrate a dataset to ML1 and the request just sits waiting
> > in DFHSM. What do I need to turn on?
> > TIA
> >

--
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: DFHSM Migrate

[Bill Johnson]

The funny thing is it looks perfect on my laptop but formatted badly on phone.


Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 1:40 PM, Lizette Koehler 
 wrote:

So just a comment on formatting

When posting long lists like this, I find putting 3 spaces in front of each 
line retains the formatting.

I am not sure why the ListServer tends to flow the lines when there is no space 
or two in the first position

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Wednesday, November 01, 2017 8:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migrate
> 
> F dfhsm,Q SETSYS
> F DFSMSHSM,Q SETSYSARC0101I QUERY SETSYS COMMAND STARTING ON HOST=1ARC0147I
> BUDENSITY=*, BUUNIT=3490, BU RECYCLE 948ARC0147I (CONT.) PERCENTAGE=020%,
> MOUNT WAIT TIME=010 MINUTE(S),ARC0147I (CONT.) TAPESPANSIZE(0100)ARC0419I
> SELECTVOLUME=SPECIFIC FOR MIGRATION, SCRATCH 949ARC0419I (CONT.) FOR BACKUP,
> DUMP, TAPEDELETION=SCRATCHTAPE,ARC0419I (CONT.) PARTIALTAPE=REUSE,
> DISASTERMODE=NOARC0259I TAPEDATASETORDER=PRIORITYARC0408I INPUT TAPE
> ALLOCATION=NOWAIT, OUTPUT TAPE 951ARC0408I (CONT.) ALLOCATION=NOWAIT, RECYCLE
> TAPE ALLOCATION=NOWAIT,ARC0408I (CONT.) TAPEFORMAT=SINGLEFILEARC0417I TAPE
> INPUT PROMPT FOR BACKUPTAPES=YESARC0417I TAPE INPUT PROMPT FOR
> DUMPTAPES=YESARC0417I TAPE INPUT PROMPT FOR MIGRATIONTAPES=YESARC0442I TAPE
> OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 955ARC0442I (CONT.) BACKUP TAPES=NO,
> DUPLEX MIGRATION TAPES=NOARC0410I TAPEMIGRATION=ML2TAPE(TAPE(ANY)),
> 956ARC0410I (CONT.) MIGDENSITY=*, MIGUNIT=3590-1, ML2 RECYCLEARC0410I (CONT.)
> PERCENTAGE=020%, TAPEMAXRECALLTASKS=01, ML2 PARTIALSARC0410I (CONT.) NOT
> ASSOCIATED GOAL=010, RECONNECT(NONE)ARC0411I TAPESECURITY=PASSWORD,
> DEFERMOUNTARC0412I RECYCLEOUTPUT BACKUP=**NONE**, 958ARC0412I (CONT.)
> MIGRATION=**NONE**, RECYCLETAKEAWAYRETRY=(NO,ARC0412I (CONT.)
> MAXRETRYATTEMPTS=12, DELAY=0300)ARC0840I MAXRECYCLETASKS=02, RECYCLE INPUT
> 959ARC0840I (CONT.) DEALLOCATION FREQUENCY BACKUP=000 MIGRATION=000ARC0149I
> MONITOR STARTUP NOSPACE NOVOLUME, MCDS(080), 960ARC0149I (CONT.) BCDS(080),
> OCDS(080), JOURNAL(080)ARC0150I JOURNAL=RECOVERY, LOG=YES, TRACE=NO,
> 961ARC0150I (CONT.) SMFID=0240, DEBUG=NO, EMERG=NO, JES=2,
> SYS1DUMP=YES,ARC0150I (CONT.) RACFIND=NO, ERASEONSCRATCH=NO, PDA=ON,ARC0150I
> (CONT.) DSSXMMODE=(BACKUP=NO, CDSBACKUP=NO, DUMP=NO,ARC0150I (CONT.)
> MIGRATION=NO, RECOVERY=NO)ARC0151I DAYS=010, ML1DAYS=045, 962ARC0151I (CONT.)
> PRIMARYSPMGMTSTART=( NONE),ARC0151I (CONT.) MAXMIGRATIONTASKS=0003,
> INTERVALMIGRATION=YES,ARC0151I (CONT.) MIGRATIONCLEANUPDAYS(0010 0030 0003),
> SDSP=NONE,ARC0151I (CONT.) MIGRATION PREFIX=DFSMS, SCRATCH EXPIRED DATA
> SETS=NO,ARC0151I (CONT.) SECONDARYSPMGMTSTART=( NONE)ARC0267I
> MIGRATIONSUBTASKS=NO, ADDITIONALMIGSUBTASKS=**ARC0272I PRIMARY SPACE MGMT
> CYCLE LENGTH=07 DAYS, 964ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0,
> CYCLE STARTARC0272I (CONT.) DATE=98/03/02ARC0272I SECONDARY SPACE MGMT CYCLE
> LENGTH=07 DAYS, 965ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0, CYCLE
> STARTARC0272I (CONT.) DATE=98/03/02,
> ML1OVERFLOW(DATASETSIZE=00200K,ARC0272I (CONT.) THRESHOLD=080)ARC0139I
> MAXINTERVALTASKS=03, ONDEMANDMIGRATION=NO, 966ARC0139I (CONT.)
> ODMNOTIFICATIONLIMIT=00100,ARC0139I (CONT.) MAXSSMTASKS(TAPEMOVEMENT=01,
> CLEANUP=02)ARC0374I ACCEPTPSCBUSERID=NOARC0152I MAXRECALLTASKS=08,
> RECALL=PRIVATEVOLUME(LIKE), 968ARC0152I (CONT.) MAXEXTENTS=10, CONVERSION=NO,
> VOLCOUNT=*NONE*,ARC0152I (CONT.) TAPERECALLLIMITS(TASK=00015,
> TAPE=00020)ARC0153I SCRATCHFREQ=0007, SYSOUT(CLASS=A, COPIES=01, 969ARC0153I
> (CONT.) SPECIAL FORMS=NONE), SWAP=NO, PERMISSION=NO,ARC0153I (CONT.)
> EXITS=NONE, UNLOAD=NO, DATASETSERIALIZATION=DFHSM,ARC0153I (CONT.)
> USECMS=NOARC0418I TAPEUTILIZATION PERCENT=0097, LIBRARYMIGRATIONARC0418I
> TAPEUTILIZATION PERCENT=0097, LIBRARYBACKUPARC0418I TAPEUTILIZATION
> PERCENT=0097, UNIT=3480 972ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I
> TAPEUTILIZATION PERCENT=0097, UNIT=3480X 973ARC0418I (CONT.)
> CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3490
> 974ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION
> PERCENT=0097, UNIT=3590-1 975ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0638I
> MAXDUMPTASKS=03, ADSTART=(  ), 976ARC0638I (CONT.) DUMPIO=(3,2),
> VOLUMEDUMP=(STANDARD),ARC0638I (CONT.) MAXDUMPRECOVERTASKS=01ARC0274I
> BACKUP=YES(ANY), SPILL=YES(ANY), 977ARC0274I (CONT.) MAXDSRECOVERTASKS=03,
> MAXDSTAPERECOVERTASKS=03ARC0154I MAXBACKUPTASKS=03, ABSTART= ( 
> ), 978ARC0154I (CONT.) VERSIONS=001, FREQUENCY=000, SKIPABPRIMARY=NO,
> BACKUPARC0154I (CONT.) PREFIX=DFSMS, INCREMENTALBACKUP=ORIGINAL,ARC0154I
> (CONT.) PROFILEBACKUP=YES, INUSE=(RETRY=NO, DELAY=015,ARC0154I (CONT.)
> SERIALIZATION=REQUIRED)ARC0269I DS DASD BACKUP TASKS=02, DS TAPE BACKUP
> 979ARC0269I (CONT.) TASKS=02, 

Help with a Unix process

[Lizette Koehler]

So I am not very good with Unix, and now I need to find any file in a large
number of directories one directory has 130 directories with the tail .new (yep
clean up time)

So in OMVS I know the find / -name \*.new could work.  But with the number of
directories I have to search it is not performing

I am thinking there could be a REXX in Unix written to do this.  ls -al and then
search through the output

Maybe even using a grep.

But with so many of you other there with really awesome UNIX skills, what should
I, a novice, look at to be good performing, could be run in batch (Yep like that
option) or produce a report in a file I can find that will show me all the files
in all the directories that have the tail I am looking for.

Thanks




Lizette Koehler

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

Re: DFHSM Migrate

[Allan Staller]

Generally indicates a lack of space on ML1/ML2. Provide more space by any 
available method.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 1, 2017 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migrate

Not exactly sure what Migration is Limited means? Do I need to RELEASE 
migration?

  From: Richard Marchant 
 To: IBM-MAIN@LISTSERV.UA.EDU
 Sent: Wednesday, November 1, 2017 11:51 AM
 Subject: Re: DFHSM Migrate
   
Migration is LIMITED

On Wed, 01 Nov 2017 at 17:19, Bill Johnson < 
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> F dfhsm,Q SETSYS
> F DFSMSHSM,Q SETSYSARC0101I QUERY SETSYS COMMAND STARTING ON 
> HOST=1ARC0147I BUDENSITY=*, BUUNIT=3490, BU RECYCLE 948ARC0147I 
> (CONT.) PERCENTAGE=020%, MOUNT WAIT TIME=010 MINUTE(S),ARC0147I 
> (CONT.) TAPESPANSIZE(0100)ARC0419I SELECTVOLUME=SPECIFIC FOR 
> MIGRATION, SCRATCH 949ARC0419I (CONT.) FOR BACKUP, DUMP, 
> TAPEDELETION=SCRATCHTAPE,ARC0419I
> (CONT.) PARTIALTAPE=REUSE, DISASTERMODE=NOARC0259I 
> TAPEDATASETORDER=PRIORITYARC0408I INPUT TAPE ALLOCATION=NOWAIT, OUTPUT 
> TAPE 951ARC0408I (CONT.) ALLOCATION=NOWAIT, RECYCLE TAPE 
> ALLOCATION=NOWAIT,ARC0408I (CONT.) TAPEFORMAT=SINGLEFILEARC0417I TAPE 
> INPUT PROMPT FOR BACKUPTAPES=YESARC0417I TAPE INPUT PROMPT FOR 
> DUMPTAPES=YESARC0417I TAPE INPUT PROMPT FOR MIGRATIONTAPES=YESARC0442I 
> TAPE OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 955ARC0442I (CONT.) BACKUP 
> TAPES=NO, DUPLEX MIGRATION TAPES=NOARC0410I 
> TAPEMIGRATION=ML2TAPE(TAPE(ANY)), 956ARC0410I (CONT.) MIGDENSITY=*, 
> MIGUNIT=3590-1, ML2 RECYCLEARC0410I
> (CONT.) PERCENTAGE=020%, TAPEMAXRECALLTASKS=01, ML2 PARTIALSARC0410I
> (CONT.) NOT ASSOCIATED GOAL=010, RECONNECT(NONE)ARC0411I 
> TAPESECURITY=PASSWORD, DEFERMOUNTARC0412I RECYCLEOUTPUT 
> BACKUP=**NONE**, 958ARC0412I (CONT.) MIGRATION=**NONE**, 
> RECYCLETAKEAWAYRETRY=(NO,ARC0412I
> (CONT.) MAXRETRYATTEMPTS=12, DELAY=0300)ARC0840I MAXRECYCLETASKS=02, 
> RECYCLE INPUT 959ARC0840I (CONT.) DEALLOCATION FREQUENCY BACKUP=000 
> MIGRATION=000ARC0149I MONITOR STARTUP NOSPACE NOVOLUME, MCDS(080), 
> 960ARC0149I (CONT.) BCDS(080), OCDS(080), JOURNAL(080)ARC0150I 
> JOURNAL=RECOVERY, LOG=YES, TRACE=NO, 961ARC0150I (CONT.) SMFID=0240, 
> DEBUG=NO, EMERG=NO, JES=2, SYS1DUMP=YES,ARC0150I (CONT.) RACFIND=NO, 
> ERASEONSCRATCH=NO, PDA=ON,ARC0150I (CONT.) DSSXMMODE=(BACKUP=NO, 
> CDSBACKUP=NO, DUMP=NO,ARC0150I (CONT.) MIGRATION=NO, 
> RECOVERY=NO)ARC0151I DAYS=010, ML1DAYS=045, 962ARC0151I (CONT.) 
> PRIMARYSPMGMTSTART=( NONE),ARC0151I (CONT.) 
> MAXMIGRATIONTASKS=0003, INTERVALMIGRATION=YES,ARC0151I (CONT.) 
> MIGRATIONCLEANUPDAYS(0010 0030 0003), SDSP=NONE,ARC0151I (CONT.) 
> MIGRATION PREFIX=DFSMS, SCRATCH EXPIRED DATA SETS=NO,ARC0151I (CONT.) 
> SECONDARYSPMGMTSTART=( NONE)ARC0267I MIGRATIONSUBTASKS=NO, 
> ADDITIONALMIGSUBTASKS=**ARC0272I PRIMARY SPACE MGMT CYCLE LENGTH=07 
> DAYS, 964ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0, CYCLE 
> STARTARC0272I (CONT.) DATE=98/03/02ARC0272I SECONDARY SPACE MGMT CYCLE 
> LENGTH=07 DAYS, 965ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0, 
> CYCLE STARTARC0272I (CONT.) DATE=98/03/02, 
> ML1OVERFLOW(DATASETSIZE=00200K,ARC0272I (CONT.) 
> THRESHOLD=080)ARC0139I MAXINTERVALTASKS=03, ONDEMANDMIGRATION=NO, 
> 966ARC0139I (CONT.) ODMNOTIFICATIONLIMIT=00100,ARC0139I (CONT.) 
> MAXSSMTASKS(TAPEMOVEMENT=01, CLEANUP=02)ARC0374I 
> ACCEPTPSCBUSERID=NOARC0152I MAXRECALLTASKS=08, 
> RECALL=PRIVATEVOLUME(LIKE), 968ARC0152I (CONT.) MAXEXTENTS=10, 
> CONVERSION=NO, VOLCOUNT=*NONE*,ARC0152I (CONT.) 
> TAPERECALLLIMITS(TASK=00015, TAPE=00020)ARC0153I SCRATCHFREQ=0007, 
> SYSOUT(CLASS=A, COPIES=01, 969ARC0153I (CONT.) SPECIAL FORMS=NONE), 
> SWAP=NO, PERMISSION=NO,ARC0153I (CONT.) EXITS=NONE, UNLOAD=NO, 
> DATASETSERIALIZATION=DFHSM,ARC0153I (CONT.) USECMS=NOARC0418I 
> TAPEUTILIZATION PERCENT=0097, LIBRARYMIGRATIONARC0418I TAPEUTILIZATION 
> PERCENT=0097, LIBRARYBACKUPARC0418I TAPEUTILIZATION PERCENT=0097, 
> UNIT=3480 972ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I 
> TAPEUTILIZATION PERCENT=0097, UNIT=3480X 973ARC0418I (CONT.) 
> CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3490 
> 974ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION 
> PERCENT=0097, UNIT=3590-1 975ARC0418I (CONT.) 
> CAPACITYMODE=**NONE**ARC0638I MAXDUMPTASKS=03,
> ADSTART=(  ), 976ARC0638I (CONT.) DUMPIO=(3,2), 
> VOLUMEDUMP=(STANDARD),ARC0638I (CONT.) MAXDUMPRECOVERTASKS=01ARC0274I 
> BACKUP=YES(ANY), SPILL=YES(ANY), 977ARC0274I (CONT.) 
> MAXDSRECOVERTASKS=03, MAXDSTAPERECOVERTASKS=03ARC0154I 
> MAXBACKUPTASKS=03, ABSTART= (  ), 978ARC0154I (CONT.) 
> VERSIONS=001, FREQUENCY=000, SKIPABPRIMARY=NO, BACKUPARC0154I (CONT.) 
> PREFIX=DFSMS, INCREMENTALBACKUP=ORIGINAL,ARC0154I
> (CONT.) PROFILEBACKUP=YES, INUSE=(RETRY=NO, DELAY=015,ARC0154I (CONT.) 
> SERIALIZATION=REQUIRED)ARC0269I DS DASD 

Re: DFHSM Migrate

[Bill Johnson]

Not exactly sure what Migration is Limited means? Do I need to RELEASE 
migration?

  From: Richard Marchant 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Wednesday, November 1, 2017 11:51 AM
 Subject: Re: DFHSM Migrate
   
Migration is LIMITED

On Wed, 01 Nov 2017 at 17:19, Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> F dfhsm,Q SETSYS
> F DFSMSHSM,Q SETSYSARC0101I QUERY SETSYS COMMAND STARTING ON
> HOST=1ARC0147I BUDENSITY=*, BUUNIT=3490, BU RECYCLE 948ARC0147I (CONT.)
> PERCENTAGE=020%, MOUNT WAIT TIME=010 MINUTE(S),ARC0147I (CONT.)
> TAPESPANSIZE(0100)ARC0419I SELECTVOLUME=SPECIFIC FOR MIGRATION, SCRATCH
> 949ARC0419I (CONT.) FOR BACKUP, DUMP, TAPEDELETION=SCRATCHTAPE,ARC0419I
> (CONT.) PARTIALTAPE=REUSE, DISASTERMODE=NOARC0259I
> TAPEDATASETORDER=PRIORITYARC0408I INPUT TAPE ALLOCATION=NOWAIT, OUTPUT TAPE
> 951ARC0408I (CONT.) ALLOCATION=NOWAIT, RECYCLE TAPE
> ALLOCATION=NOWAIT,ARC0408I (CONT.) TAPEFORMAT=SINGLEFILEARC0417I TAPE INPUT
> PROMPT FOR BACKUPTAPES=YESARC0417I TAPE INPUT PROMPT FOR
> DUMPTAPES=YESARC0417I TAPE INPUT PROMPT FOR MIGRATIONTAPES=YESARC0442I TAPE
> OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 955ARC0442I (CONT.) BACKUP TAPES=NO,
> DUPLEX MIGRATION TAPES=NOARC0410I TAPEMIGRATION=ML2TAPE(TAPE(ANY)),
> 956ARC0410I (CONT.) MIGDENSITY=*, MIGUNIT=3590-1, ML2 RECYCLEARC0410I
> (CONT.) PERCENTAGE=020%, TAPEMAXRECALLTASKS=01, ML2 PARTIALSARC0410I
> (CONT.) NOT ASSOCIATED GOAL=010, RECONNECT(NONE)ARC0411I
> TAPESECURITY=PASSWORD, DEFERMOUNTARC0412I RECYCLEOUTPUT BACKUP=**NONE**,
> 958ARC0412I (CONT.) MIGRATION=**NONE**, RECYCLETAKEAWAYRETRY=(NO,ARC0412I
> (CONT.) MAXRETRYATTEMPTS=12, DELAY=0300)ARC0840I MAXRECYCLETASKS=02,
> RECYCLE INPUT 959ARC0840I (CONT.) DEALLOCATION FREQUENCY BACKUP=000
> MIGRATION=000ARC0149I MONITOR STARTUP NOSPACE NOVOLUME, MCDS(080),
> 960ARC0149I (CONT.) BCDS(080), OCDS(080), JOURNAL(080)ARC0150I
> JOURNAL=RECOVERY, LOG=YES, TRACE=NO, 961ARC0150I (CONT.) SMFID=0240,
> DEBUG=NO, EMERG=NO, JES=2, SYS1DUMP=YES,ARC0150I (CONT.) RACFIND=NO,
> ERASEONSCRATCH=NO, PDA=ON,ARC0150I (CONT.) DSSXMMODE=(BACKUP=NO,
> CDSBACKUP=NO, DUMP=NO,ARC0150I (CONT.) MIGRATION=NO, RECOVERY=NO)ARC0151I
> DAYS=010, ML1DAYS=045, 962ARC0151I (CONT.) PRIMARYSPMGMTSTART=(
> NONE),ARC0151I (CONT.) MAXMIGRATIONTASKS=0003,
> INTERVALMIGRATION=YES,ARC0151I (CONT.) MIGRATIONCLEANUPDAYS(0010 0030
> 0003), SDSP=NONE,ARC0151I (CONT.) MIGRATION PREFIX=DFSMS, SCRATCH EXPIRED
> DATA SETS=NO,ARC0151I (CONT.) SECONDARYSPMGMTSTART=( NONE)ARC0267I
> MIGRATIONSUBTASKS=NO, ADDITIONALMIGSUBTASKS=**ARC0272I PRIMARY SPACE MGMT
> CYCLE LENGTH=07 DAYS, 964ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0,
> CYCLE STARTARC0272I (CONT.) DATE=98/03/02ARC0272I SECONDARY SPACE MGMT
> CYCLE LENGTH=07 DAYS, 965ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0,
> CYCLE STARTARC0272I (CONT.) DATE=98/03/02,
> ML1OVERFLOW(DATASETSIZE=00200K,ARC0272I (CONT.) THRESHOLD=080)ARC0139I
> MAXINTERVALTASKS=03, ONDEMANDMIGRATION=NO, 966ARC0139I (CONT.)
> ODMNOTIFICATIONLIMIT=00100,ARC0139I (CONT.) MAXSSMTASKS(TAPEMOVEMENT=01,
> CLEANUP=02)ARC0374I ACCEPTPSCBUSERID=NOARC0152I MAXRECALLTASKS=08,
> RECALL=PRIVATEVOLUME(LIKE), 968ARC0152I (CONT.) MAXEXTENTS=10,
> CONVERSION=NO, VOLCOUNT=*NONE*,ARC0152I (CONT.)
> TAPERECALLLIMITS(TASK=00015, TAPE=00020)ARC0153I SCRATCHFREQ=0007,
> SYSOUT(CLASS=A, COPIES=01, 969ARC0153I (CONT.) SPECIAL FORMS=NONE),
> SWAP=NO, PERMISSION=NO,ARC0153I (CONT.) EXITS=NONE, UNLOAD=NO,
> DATASETSERIALIZATION=DFHSM,ARC0153I (CONT.) USECMS=NOARC0418I
> TAPEUTILIZATION PERCENT=0097, LIBRARYMIGRATIONARC0418I TAPEUTILIZATION
> PERCENT=0097, LIBRARYBACKUPARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3480
> 972ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION
> PERCENT=0097, UNIT=3480X 973ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I
> TAPEUTILIZATION PERCENT=0097, UNIT=3490 974ARC0418I (CONT.)
> CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3590-1
> 975ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0638I MAXDUMPTASKS=03,
> ADSTART=(  ), 976ARC0638I (CONT.) DUMPIO=(3,2),
> VOLUMEDUMP=(STANDARD),ARC0638I (CONT.) MAXDUMPRECOVERTASKS=01ARC0274I
> BACKUP=YES(ANY), SPILL=YES(ANY), 977ARC0274I (CONT.) MAXDSRECOVERTASKS=03,
> MAXDSTAPERECOVERTASKS=03ARC0154I MAXBACKUPTASKS=03, ABSTART= ( 
> ), 978ARC0154I (CONT.) VERSIONS=001, FREQUENCY=000, SKIPABPRIMARY=NO,
> BACKUPARC0154I (CONT.) PREFIX=DFSMS, INCREMENTALBACKUP=ORIGINAL,ARC0154I
> (CONT.) PROFILEBACKUP=YES, INUSE=(RETRY=NO, DELAY=015,ARC0154I (CONT.)
> SERIALIZATION=REQUIRED)ARC0269I DS DASD BACKUP TASKS=02, DS TAPE BACKUP
> 979ARC0269I (CONT.) TASKS=02, DEMOUNTDELAY=0060, MAXIDLETASKS=00,
> DSARC0269I (CONT.) BACKUP MAX DASD SIZE=03000, DS BACKUP STD
> DASDARC0269I (CONT.) SIZE=03000, SWITCHTAPES TIME=,ARC0269I (CONT.)
> PARTIALTAPE=MARKFULL, GENVSAMCOMPNAMES=YESARC1823I MAXCOPYPOOL (FRBACKUP
> TASKS=0015, FRRECOV 980ARC1823I (CONT.) TASKS=0015, DSS
> 

Re: call IKJEFT1B from an assembler program

[Paul Gilmartin]

On Wed, 1 Nov 2017 16:37:31 +, PINION, RICHARD W. wrote:

>I've shifted gears and I am using IKJTSOEV, things are looking a little better.
>However, I received " IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS ALLOWED 
>BY YOUR SESSION HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS".  In JCL I 
>would use the DYNAMNBR,
>but for IKJTSOEV how would I set this?  I have debugging turned on
>in the REXX and can see the failure is on an ALLOC command.
> 
Instead of ALLOCATE, try BPXWDYN, which ignores DYNAMNBR.

-- gil

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

Re: call IKJEFT1B from an assembler program

[PINION, RICHARD W.]

I've shifted gears and I am using IKJTSOEV, things are looking a little better.
However, I received " IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS ALLOWED 
BY YOUR SESSION HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS".  In JCL I 
would use the DYNAMNBR,
but for IKJTSOEV how would I set this?  I have debugging turned on
in the REXX and can see the failure is on an ALLOC command.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, November 01, 2017 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: call IKJEFT1B from an assembler program

[External Email]

On Wed, Nov 1, 2017 at 10:19 AM, PINION, RICHARD W. < 
rpin...@firsttennessee.com> wrote:

> Would someone be so kind as to give me an example of calling IKJEFT1B 
> from an assembler program.  The CALL macro I am using is passing 
> control to IKJEFT1B, but I receive "IKJ56600I UNRECOVERABLE COMMAND 
> SYSTEM ERROR".  I'm assuming the parameters I am passing are 
> incorrect.  And, no my need is not to invoke it directly from JCL via 
> //STEP010 EXEC PGM=IKJEFT1B.
> FIRST TENNESSEE
>
>
​there has been some recent discussion about how IKJEFT01 and it's aliases 
(IKJEFT1A & IKJEFT1B) should _not_ be invoked by anything other that EXEC PGM= 
or via the "TMP session manager". Of course, you are free to do whatever you 
need to do to "get the job done". I am curious if, instead, you could use the 
"TSO Environment Services" (IKJTSOEV) as  documented at:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb700/whenuse.htm
​

Also, just because I'm curious, what are you trying to accomplish (at a high 
level, details not needed).


--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: call IKJEFT1B from an assembler program

[PINION, RICHARD W.]

Based on the replies, I'm returning to invoking IKJTSOEV instead.
If I have additional questions, I'll post again.  Thanks for the replies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, November 01, 2017 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: call IKJEFT1B from an assembler program

[External Email]

On Wed, Nov 1, 2017 at 10:19 AM, PINION, RICHARD W. < 
rpin...@firsttennessee.com> wrote:

> Would someone be so kind as to give me an example of calling IKJEFT1B 
> from an assembler program.  The CALL macro I am using is passing 
> control to IKJEFT1B, but I receive "IKJ56600I UNRECOVERABLE COMMAND 
> SYSTEM ERROR".  I'm assuming the parameters I am passing are 
> incorrect.  And, no my need is not to invoke it directly from JCL via 
> //STEP010 EXEC PGM=IKJEFT1B.
> FIRST TENNESSEE
>
>
​there has been some recent discussion about how IKJEFT01 and it's aliases 
(IKJEFT1A & IKJEFT1B) should _not_ be invoked by anything other that EXEC PGM= 
or via the "TMP session manager". Of course, you are free to do whatever you 
need to do to "get the job done". I am curious if, instead, you could use the 
"TSO Environment Services" (IKJTSOEV) as  documented at:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb700/whenuse.htm
​

Also, just because I'm curious, what are you trying to accomplish (at a high 
level, details not needed).


--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: DFHSM Migrate

[Richard Marchant]

Migration is LIMITED

On Wed, 01 Nov 2017 at 17:19, Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> F dfhsm,Q SETSYS
> F DFSMSHSM,Q SETSYSARC0101I QUERY SETSYS COMMAND STARTING ON
> HOST=1ARC0147I BUDENSITY=*, BUUNIT=3490, BU RECYCLE 948ARC0147I (CONT.)
> PERCENTAGE=020%, MOUNT WAIT TIME=010 MINUTE(S),ARC0147I (CONT.)
> TAPESPANSIZE(0100)ARC0419I SELECTVOLUME=SPECIFIC FOR MIGRATION, SCRATCH
> 949ARC0419I (CONT.) FOR BACKUP, DUMP, TAPEDELETION=SCRATCHTAPE,ARC0419I
> (CONT.) PARTIALTAPE=REUSE, DISASTERMODE=NOARC0259I
> TAPEDATASETORDER=PRIORITYARC0408I INPUT TAPE ALLOCATION=NOWAIT, OUTPUT TAPE
> 951ARC0408I (CONT.) ALLOCATION=NOWAIT, RECYCLE TAPE
> ALLOCATION=NOWAIT,ARC0408I (CONT.) TAPEFORMAT=SINGLEFILEARC0417I TAPE INPUT
> PROMPT FOR BACKUPTAPES=YESARC0417I TAPE INPUT PROMPT FOR
> DUMPTAPES=YESARC0417I TAPE INPUT PROMPT FOR MIGRATIONTAPES=YESARC0442I TAPE
> OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 955ARC0442I (CONT.) BACKUP TAPES=NO,
> DUPLEX MIGRATION TAPES=NOARC0410I TAPEMIGRATION=ML2TAPE(TAPE(ANY)),
> 956ARC0410I (CONT.) MIGDENSITY=*, MIGUNIT=3590-1, ML2 RECYCLEARC0410I
> (CONT.) PERCENTAGE=020%, TAPEMAXRECALLTASKS=01, ML2 PARTIALSARC0410I
> (CONT.) NOT ASSOCIATED GOAL=010, RECONNECT(NONE)ARC0411I
> TAPESECURITY=PASSWORD, DEFERMOUNTARC0412I RECYCLEOUTPUT BACKUP=**NONE**,
> 958ARC0412I (CONT.) MIGRATION=**NONE**, RECYCLETAKEAWAYRETRY=(NO,ARC0412I
> (CONT.) MAXRETRYATTEMPTS=12, DELAY=0300)ARC0840I MAXRECYCLETASKS=02,
> RECYCLE INPUT 959ARC0840I (CONT.) DEALLOCATION FREQUENCY BACKUP=000
> MIGRATION=000ARC0149I MONITOR STARTUP NOSPACE NOVOLUME, MCDS(080),
> 960ARC0149I (CONT.) BCDS(080), OCDS(080), JOURNAL(080)ARC0150I
> JOURNAL=RECOVERY, LOG=YES, TRACE=NO, 961ARC0150I (CONT.) SMFID=0240,
> DEBUG=NO, EMERG=NO, JES=2, SYS1DUMP=YES,ARC0150I (CONT.) RACFIND=NO,
> ERASEONSCRATCH=NO, PDA=ON,ARC0150I (CONT.) DSSXMMODE=(BACKUP=NO,
> CDSBACKUP=NO, DUMP=NO,ARC0150I (CONT.) MIGRATION=NO, RECOVERY=NO)ARC0151I
> DAYS=010, ML1DAYS=045, 962ARC0151I (CONT.) PRIMARYSPMGMTSTART=(
> NONE),ARC0151I (CONT.) MAXMIGRATIONTASKS=0003,
> INTERVALMIGRATION=YES,ARC0151I (CONT.) MIGRATIONCLEANUPDAYS(0010 0030
> 0003), SDSP=NONE,ARC0151I (CONT.) MIGRATION PREFIX=DFSMS, SCRATCH EXPIRED
> DATA SETS=NO,ARC0151I (CONT.) SECONDARYSPMGMTSTART=( NONE)ARC0267I
> MIGRATIONSUBTASKS=NO, ADDITIONALMIGSUBTASKS=**ARC0272I PRIMARY SPACE MGMT
> CYCLE LENGTH=07 DAYS, 964ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0,
> CYCLE STARTARC0272I (CONT.) DATE=98/03/02ARC0272I SECONDARY SPACE MGMT
> CYCLE LENGTH=07 DAYS, 965ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0,
> CYCLE STARTARC0272I (CONT.) DATE=98/03/02,
> ML1OVERFLOW(DATASETSIZE=00200K,ARC0272I (CONT.) THRESHOLD=080)ARC0139I
> MAXINTERVALTASKS=03, ONDEMANDMIGRATION=NO, 966ARC0139I (CONT.)
> ODMNOTIFICATIONLIMIT=00100,ARC0139I (CONT.) MAXSSMTASKS(TAPEMOVEMENT=01,
> CLEANUP=02)ARC0374I ACCEPTPSCBUSERID=NOARC0152I MAXRECALLTASKS=08,
> RECALL=PRIVATEVOLUME(LIKE), 968ARC0152I (CONT.) MAXEXTENTS=10,
> CONVERSION=NO, VOLCOUNT=*NONE*,ARC0152I (CONT.)
> TAPERECALLLIMITS(TASK=00015, TAPE=00020)ARC0153I SCRATCHFREQ=0007,
> SYSOUT(CLASS=A, COPIES=01, 969ARC0153I (CONT.) SPECIAL FORMS=NONE),
> SWAP=NO, PERMISSION=NO,ARC0153I (CONT.) EXITS=NONE, UNLOAD=NO,
> DATASETSERIALIZATION=DFHSM,ARC0153I (CONT.) USECMS=NOARC0418I
> TAPEUTILIZATION PERCENT=0097, LIBRARYMIGRATIONARC0418I TAPEUTILIZATION
> PERCENT=0097, LIBRARYBACKUPARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3480
> 972ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION
> PERCENT=0097, UNIT=3480X 973ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I
> TAPEUTILIZATION PERCENT=0097, UNIT=3490 974ARC0418I (CONT.)
> CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3590-1
> 975ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0638I MAXDUMPTASKS=03,
> ADSTART=(  ), 976ARC0638I (CONT.) DUMPIO=(3,2),
> VOLUMEDUMP=(STANDARD),ARC0638I (CONT.) MAXDUMPRECOVERTASKS=01ARC0274I
> BACKUP=YES(ANY), SPILL=YES(ANY), 977ARC0274I (CONT.) MAXDSRECOVERTASKS=03,
> MAXDSTAPERECOVERTASKS=03ARC0154I MAXBACKUPTASKS=03, ABSTART= ( 
> ), 978ARC0154I (CONT.) VERSIONS=001, FREQUENCY=000, SKIPABPRIMARY=NO,
> BACKUPARC0154I (CONT.) PREFIX=DFSMS, INCREMENTALBACKUP=ORIGINAL,ARC0154I
> (CONT.) PROFILEBACKUP=YES, INUSE=(RETRY=NO, DELAY=015,ARC0154I (CONT.)
> SERIALIZATION=REQUIRED)ARC0269I DS DASD BACKUP TASKS=02, DS TAPE BACKUP
> 979ARC0269I (CONT.) TASKS=02, DEMOUNTDELAY=0060, MAXIDLETASKS=00,
> DSARC0269I (CONT.) BACKUP MAX DASD SIZE=03000, DS BACKUP STD
> DASDARC0269I (CONT.) SIZE=03000, SWITCHTAPES TIME=,ARC0269I (CONT.)
> PARTIALTAPE=MARKFULL, GENVSAMCOMPNAMES=YESARC1823I MAXCOPYPOOL (FRBACKUP
> TASKS=0015, FRRECOV 980ARC1823I (CONT.) TASKS=0015, DSS
> TASKS=0024),ARC1823I (CONT.) FASTREPLICATION(DATASETRECOVERY=NONEARC1823I
> (CONT.) FCRELATION=EXTENT VOLUMEPAIRMESSAGES=NOARC1823I (CONT.)
> MESSAGEDATASET(NO HLQ=HSMMSG))ARC0375I CDSVERSIONBACKUP, 981ARC0375I
> (CONT.) 

Re: call IKJEFT1B from an assembler program

[John McKown]

On Wed, Nov 1, 2017 at 10:19 AM, PINION, RICHARD W. <
rpin...@firsttennessee.com> wrote:

> Would someone be so kind as to give me an example of calling IKJEFT1B
> from an assembler program.  The CALL macro I am using is passing control
> to IKJEFT1B, but I receive "IKJ56600I UNRECOVERABLE COMMAND SYSTEM
> ERROR".  I'm assuming the parameters I am passing are incorrect.  And, no
> my need is not to invoke it directly from JCL via //STEP010 EXEC
> PGM=IKJEFT1B.
> FIRST TENNESSEE
>
>
​there has been some recent discussion about how IKJEFT01 and it's aliases
(IKJEFT1A & IKJEFT1B) should _not_ be invoked by anything other that EXEC
PGM= or via the "TMP session manager". Of course, you are free to do
whatever you need to do to "get the job done". I am curious if, instead,
you could use the "TSO Environment Services" (IKJTSOEV) as  documented at:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb700/whenuse.htm
​

Also, just because I'm curious, what are you trying to accomplish (at a
high level, details not needed).


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: call IKJEFT1B from an assembler program

[Steve Smith]

I'm not sure that the recent discussion on ATTACHing the TMP is
directly relevant.  CALL doesn't change the TCB or PRB used.

Irregardless, there's no good reason to CALL the TMP.  Just say no.

sas

On Wed, Nov 1, 2017 at 11:31 AM, Wayne Driscoll
 wrote:
> See Jim Mulder's recent post about the design of IKJEFTxx expecting to be 
> executed as a job step TCB (ie it's own TCBJSTCB field points to itself, as 
> well as other internal details), and you will see that this isn't supported 
> for reasons of MVS integrity.
>
> Wayne Driscoll
> Rocket Software
> Note - All opinions are strictly my own.
>

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

Re: call IKJEFT1B from an assembler program

[Paul Gilmartin]

On Wed, 1 Nov 2017 15:19:30 +, PINION, RICHARD W. wrote:

>Would someone be so kind as to give me an example of calling IKJEFT1B
>from an assembler program.  The CALL macro I am using is passing control
>to IKJEFT1B, but I receive "IKJ56600I UNRECOVERABLE COMMAND SYSTEM
>ERROR".  I'm assuming the parameters I am passing are incorrect.  And, no
>my need is not to invoke it directly from JCL via //STEP010 EXEC PGM=IKJEFT1B.
>FIRST TENNESSEE
>
See the discussions here 2 and 3 days ago which assert that the IKJEFTxx are
designed to be invoked only as "job step" tasks.

What's your requirement?  I could imagine using BPX1SPN to start a Rexx EXEC
which could issue the UNIX variant of ADDRESS TSO, or using BPX1EXM.  I haven't 
tried those.

Is your assembler program APF-authorized?  But use caution.

-- gil

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

Re: call IKJEFT1B from an assembler program

[Wayne Driscoll]

See Jim Mulder's recent post about the design of IKJEFTxx expecting to be 
executed as a job step TCB (ie it's own TCBJSTCB field points to itself, as 
well as other internal details), and you will see that this isn't supported for 
reasons of MVS integrity.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of PINION, RICHARD W.
Sent: Wednesday, November 1, 2017 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: call IKJEFT1B from an assembler program

Would someone be so kind as to give me an example of calling IKJEFT1B from an 
assembler program.  The CALL macro I am using is passing control to IKJEFT1B, 
but I receive "IKJ56600I UNRECOVERABLE COMMAND SYSTEM ERROR".  I'm assuming the 
parameters I am passing are incorrect.  And, no my need is not to invoke it 
directly from JCL via //STEP010 EXEC PGM=IKJEFT1B.
FIRST TENNESSEE

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


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

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

call IKJEFT1B from an assembler program

[PINION, RICHARD W.]

Would someone be so kind as to give me an example of calling IKJEFT1B
from an assembler program.  The CALL macro I am using is passing control
to IKJEFT1B, but I receive "IKJ56600I UNRECOVERABLE COMMAND SYSTEM
ERROR".  I'm assuming the parameters I am passing are incorrect.  And, no
my need is not to invoke it directly from JCL via //STEP010 EXEC PGM=IKJEFT1B.
FIRST TENNESSEE

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: DFHSM Migrate

[Bill Johnson]

F dfhsm,Q SETSYS
F DFSMSHSM,Q SETSYSARC0101I QUERY SETSYS COMMAND STARTING ON HOST=1ARC0147I 
BUDENSITY=*, BUUNIT=3490, BU RECYCLE 948ARC0147I (CONT.) PERCENTAGE=020%, MOUNT 
WAIT TIME=010 MINUTE(S),ARC0147I (CONT.) TAPESPANSIZE(0100)ARC0419I 
SELECTVOLUME=SPECIFIC FOR MIGRATION, SCRATCH 949ARC0419I (CONT.) FOR BACKUP, 
DUMP, TAPEDELETION=SCRATCHTAPE,ARC0419I (CONT.) PARTIALTAPE=REUSE, 
DISASTERMODE=NOARC0259I TAPEDATASETORDER=PRIORITYARC0408I INPUT TAPE 
ALLOCATION=NOWAIT, OUTPUT TAPE 951ARC0408I (CONT.) ALLOCATION=NOWAIT, RECYCLE 
TAPE ALLOCATION=NOWAIT,ARC0408I (CONT.) TAPEFORMAT=SINGLEFILEARC0417I TAPE 
INPUT PROMPT FOR BACKUPTAPES=YESARC0417I TAPE INPUT PROMPT FOR 
DUMPTAPES=YESARC0417I TAPE INPUT PROMPT FOR MIGRATIONTAPES=YESARC0442I TAPE 
OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 955ARC0442I (CONT.) BACKUP TAPES=NO, 
DUPLEX MIGRATION TAPES=NOARC0410I TAPEMIGRATION=ML2TAPE(TAPE(ANY)), 956ARC0410I 
(CONT.) MIGDENSITY=*, MIGUNIT=3590-1, ML2 RECYCLEARC0410I (CONT.) 
PERCENTAGE=020%, TAPEMAXRECALLTASKS=01, ML2 PARTIALSARC0410I (CONT.) NOT 
ASSOCIATED GOAL=010, RECONNECT(NONE)ARC0411I TAPESECURITY=PASSWORD, 
DEFERMOUNTARC0412I RECYCLEOUTPUT BACKUP=**NONE**, 958ARC0412I (CONT.) 
MIGRATION=**NONE**, RECYCLETAKEAWAYRETRY=(NO,ARC0412I (CONT.) 
MAXRETRYATTEMPTS=12, DELAY=0300)ARC0840I MAXRECYCLETASKS=02, RECYCLE INPUT 
959ARC0840I (CONT.) DEALLOCATION FREQUENCY BACKUP=000 MIGRATION=000ARC0149I 
MONITOR STARTUP NOSPACE NOVOLUME, MCDS(080), 960ARC0149I (CONT.) BCDS(080), 
OCDS(080), JOURNAL(080)ARC0150I JOURNAL=RECOVERY, LOG=YES, TRACE=NO, 
961ARC0150I (CONT.) SMFID=0240, DEBUG=NO, EMERG=NO, JES=2, 
SYS1DUMP=YES,ARC0150I (CONT.) RACFIND=NO, ERASEONSCRATCH=NO, PDA=ON,ARC0150I 
(CONT.) DSSXMMODE=(BACKUP=NO, CDSBACKUP=NO, DUMP=NO,ARC0150I (CONT.) 
MIGRATION=NO, RECOVERY=NO)ARC0151I DAYS=010, ML1DAYS=045, 962ARC0151I (CONT.) 
PRIMARYSPMGMTSTART=( NONE),ARC0151I (CONT.) MAXMIGRATIONTASKS=0003, 
INTERVALMIGRATION=YES,ARC0151I (CONT.) MIGRATIONCLEANUPDAYS(0010 0030 0003), 
SDSP=NONE,ARC0151I (CONT.) MIGRATION PREFIX=DFSMS, SCRATCH EXPIRED DATA 
SETS=NO,ARC0151I (CONT.) SECONDARYSPMGMTSTART=( NONE)ARC0267I 
MIGRATIONSUBTASKS=NO, ADDITIONALMIGSUBTASKS=**ARC0272I PRIMARY SPACE MGMT CYCLE 
LENGTH=07 DAYS, 964ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0, CYCLE 
STARTARC0272I (CONT.) DATE=98/03/02ARC0272I SECONDARY SPACE MGMT CYCLE 
LENGTH=07 DAYS, 965ARC0272I (CONT.) CYCLE=YYY, TODAY IS DAY=0, CYCLE 
STARTARC0272I (CONT.) DATE=98/03/02, 
ML1OVERFLOW(DATASETSIZE=00200K,ARC0272I (CONT.) THRESHOLD=080)ARC0139I 
MAXINTERVALTASKS=03, ONDEMANDMIGRATION=NO, 966ARC0139I (CONT.) 
ODMNOTIFICATIONLIMIT=00100,ARC0139I (CONT.) MAXSSMTASKS(TAPEMOVEMENT=01, 
CLEANUP=02)ARC0374I ACCEPTPSCBUSERID=NOARC0152I MAXRECALLTASKS=08, 
RECALL=PRIVATEVOLUME(LIKE), 968ARC0152I (CONT.) MAXEXTENTS=10, CONVERSION=NO, 
VOLCOUNT=*NONE*,ARC0152I (CONT.) TAPERECALLLIMITS(TASK=00015, 
TAPE=00020)ARC0153I SCRATCHFREQ=0007, SYSOUT(CLASS=A, COPIES=01, 969ARC0153I 
(CONT.) SPECIAL FORMS=NONE), SWAP=NO, PERMISSION=NO,ARC0153I (CONT.) 
EXITS=NONE, UNLOAD=NO, DATASETSERIALIZATION=DFHSM,ARC0153I (CONT.) 
USECMS=NOARC0418I TAPEUTILIZATION PERCENT=0097, LIBRARYMIGRATIONARC0418I 
TAPEUTILIZATION PERCENT=0097, LIBRARYBACKUPARC0418I TAPEUTILIZATION 
PERCENT=0097, UNIT=3480 972ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I 
TAPEUTILIZATION PERCENT=0097, UNIT=3480X 973ARC0418I (CONT.) 
CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3490 
974ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0418I TAPEUTILIZATION PERCENT=0097, 
UNIT=3590-1 975ARC0418I (CONT.) CAPACITYMODE=**NONE**ARC0638I MAXDUMPTASKS=03, 
ADSTART=(  ), 976ARC0638I (CONT.) DUMPIO=(3,2), 
VOLUMEDUMP=(STANDARD),ARC0638I (CONT.) MAXDUMPRECOVERTASKS=01ARC0274I 
BACKUP=YES(ANY), SPILL=YES(ANY), 977ARC0274I (CONT.) MAXDSRECOVERTASKS=03, 
MAXDSTAPERECOVERTASKS=03ARC0154I MAXBACKUPTASKS=03, ABSTART= (  ), 
978ARC0154I (CONT.) VERSIONS=001, FREQUENCY=000, SKIPABPRIMARY=NO, 
BACKUPARC0154I (CONT.) PREFIX=DFSMS, INCREMENTALBACKUP=ORIGINAL,ARC0154I 
(CONT.) PROFILEBACKUP=YES, INUSE=(RETRY=NO, DELAY=015,ARC0154I (CONT.) 
SERIALIZATION=REQUIRED)ARC0269I DS DASD BACKUP TASKS=02, DS TAPE BACKUP 
979ARC0269I (CONT.) TASKS=02, DEMOUNTDELAY=0060, MAXIDLETASKS=00, DSARC0269I 
(CONT.) BACKUP MAX DASD SIZE=03000, DS BACKUP STD DASDARC0269I (CONT.) 
SIZE=03000, SWITCHTAPES TIME=,ARC0269I (CONT.) PARTIALTAPE=MARKFULL, 
GENVSAMCOMPNAMES=YESARC1823I MAXCOPYPOOL (FRBACKUP TASKS=0015, FRRECOV 
980ARC1823I (CONT.) TASKS=0015, DSS TASKS=0024),ARC1823I (CONT.) 
FASTREPLICATION(DATASETRECOVERY=NONEARC1823I (CONT.) FCRELATION=EXTENT 
VOLUMEPAIRMESSAGES=NOARC1823I (CONT.) MESSAGEDATASET(NO HLQ=HSMMSG))ARC0375I 
CDSVERSIONBACKUP, 981ARC0375I (CONT.) 
MCDSBACKUPDSN=SYSTEM.DFHSM.MCDS.BACKUP,ARC0375I (CONT.) 
BCDSBACKUPDSN=SYSTEM.DFHSM.BCDS.BACKUP,ARC0375I (CONT.) 
OCDSBACKUPDSN=SYSTEM.DFHSM.OCDS.BACKUP,ARC0375I (CONT.) 
JRNLBACKUPDSN=SYSTEM.DFHSM.JRNL.BACKUPARC0376I BACKUPCOPIES=0004, 

Re: DFHSM Migrate

[Elardus Engelbrecht]

Richards, Robert B. wrote:

>What she said!  :-)

Careful fella, if she was your boss or if she was MY boss, both of us would be 
fired anyways in one nanosecond and sent away in chains to Siberia... ;-D

But seriously, her two questions about space are eye-openers!

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: SMF Dump Exit - IEFU29

[Edward Gould]

> On Nov 1, 2017, at 7:15 AM, Rodatz, William J 
>  wrote:
> 
> Hi Everyone,
> 
> We use the SMF dump exit, IEFU29, to initiate a started task to empty the SMF 
> dump datasets when needed.  It works well but there is one issue.  IEFU29 
> cannot issue a START command during an IPL because the SMF subsystem comes up 
> before JES2.  There is code in the exit that looks to see if JES2 is active.  
> If it is not, the exit terminates.
> 
> For those of you who use IEFU29, have you found a work-around for this 
> problem?

This was a bug that IBM sent out 20 years ago. Take a look at the new sample 
IBM sends out and it will fix it, at least it did  on my system.

Ed
> 
> Thank you.
> 
> Bill
> 
> --
> 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 Dump Exit - IEFU29

[Lizette Koehler]

Not sure what you are trying to solve at IPL time

However, 

Are you trying to do an ISMF at IPL time?

Or are you doing something else?


A potential solution would be to put an I SMF command in the JES2 init deck.
Look at the $VS command.  It would not execute until JES2 is up.  Or if you are
doing something else, you could put that in the JES2 INIT deck, S
Stcforsmfoffload

Do you have an automation tool?  If not, you might look at the cbttape.org and
see if there is an automation tool you could use.

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rodatz, William J
> Sent: Wednesday, November 01, 2017 5:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF Dump Exit - IEFU29
> 
> Hi Everyone,
> 
> We use the SMF dump exit, IEFU29, to initiate a started task to empty the SMF
> dump datasets when needed.  It works well but there is one issue.  IEFU29
> cannot issue a START command during an IPL because the SMF subsystem comes up
> before JES2.  There is code in the exit that looks to see if JES2 is active.
> If it is not, the exit terminates.
> 
> For those of you who use IEFU29, have you found a work-around for this
> problem?
> 
> Thank you.
> 
> Bill
> 
> --
> 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: DFHSM Migrate

[Richards, Robert B.]

What she said!  :-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, November 01, 2017 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migrate

Please post the complete results from the 

F dfhsm,Q SETSYS

And

F dfhsm,Q ACTIVE

Just because the work TAPE is used, does not mean it is really TAPE.  It is an 
esoteric


Second, are you the sysprog responsible for DFHSM support at your shop?

Third, have you done a list of the DFHSM Migration pool to see if it has 
sufficient space in it?

Forth, have you done a HLIST DSN(name goes here) BOTH  (Like getting all info 
not just MCDS or BCDS)

Fifth,  have you looked in the DFHSM Started task logs (running STC) and 
searched for this dataset name?  See if there are any associated ARC messages 
for it.  Look at the time you issued the migrate command for the dataset.

Sixth,  have you determined how much storage the current dataset on DASD uses?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bill Johnson
> Sent: Wednesday, November 01, 2017 6:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migrate
> 
> Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert.
> Result of QUERY ACTIVE.
> 
> ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT HELD, RECALL=NOT HELD,
> 
> 
> 
> ARC0160I (CONT.) TAPERECALL=TOTALLY HELD, DATA SET MIGRATION=ACTIVE, 
> VOLUME
> 
> 
> 
> ARC0160I (CONT.) MIGRATION=INACTIVE, DATA SET RECALL=INACTIVE
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Wednesday, November 1, 2017, 9:20 AM, Richards, Robert B.
>  wrote:
> 
> Issue the QUERY ACTIVE command look for what is HELD, then RELEASE as 
> appropriate
> 
> Bob
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bill Johnson
> Sent: Wednesday, November 01, 2017 9:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM Migrate
> 
> Trying to migrate a dataset to ML1 and the request just sits waiting 
> in DFHSM. What do I need to turn on?
> TIA
> 

--
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: Why not SYSSYM=ALLOW?

[Lizette Koehler]

So this may or may not apply

You have 3 LPARs in a plex.  They all share a JES2 MAS

Job A is submitted on LPAR1 but is converted on LPAR2. The symbols the job 
needs is only on LPAR1 - so the conversion on LPAR2 will either get wrong 
symbols or no symbols.

If your single LPAR, you probably do not need to worry as much.

If you more LPARs in a PLEX and the potential for symbols to be different on 
them, and jobs can convert anywhere, you might have some challenges.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pew, Curtis G
> Sent: Wednesday, November 01, 2017 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Why not SYSSYM=ALLOW?
> 
> On Oct 31, 2017, at 6:06 PM, Paul Gilmartin <000433f07816-dmarc-
> requ...@listserv.ua.edu> wrote:
> >
> > Unintended substitution of symbols where programmers were too lazy to
> > double ampersands where proper.
> 
> That makes sense, and shouldn’t be a problem for us.
> 
> Thanks.
> 
> --
> 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: DFHSM Migrate

[Lizette Koehler]

Please post the complete results from the 

F dfhsm,Q SETSYS

And

F dfhsm,Q ACTIVE

Just because the work TAPE is used, does not mean it is really TAPE.  It is an 
esoteric


Second, are you the sysprog responsible for DFHSM support at your shop?

Third, have you done a list of the DFHSM Migration pool to see if it has 
sufficient space in it?

Forth, have you done a HLIST DSN(name goes here) BOTH  (Like getting all info 
not just MCDS or BCDS)

Fifth,  have you looked in the DFHSM Started task logs (running STC) and 
searched for this dataset name?  See if there are any associated ARC messages 
for it.  Look at the time you issued the migrate command for the dataset.

Sixth,  have you determined how much storage the current dataset on DASD uses?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Wednesday, November 01, 2017 6:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migrate
> 
> Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert.
> Result of QUERY ACTIVE.
> 
> ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT HELD, RECALL=NOT HELD,
> 
> 
> 
> ARC0160I (CONT.) TAPERECALL=TOTALLY HELD, DATA SET MIGRATION=ACTIVE, VOLUME
> 
> 
> 
> ARC0160I (CONT.) MIGRATION=INACTIVE, DATA SET RECALL=INACTIVE
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Wednesday, November 1, 2017, 9:20 AM, Richards, Robert B.
>  wrote:
> 
> Issue the QUERY ACTIVE command look for what is HELD, then RELEASE as
> appropriate
> 
> Bob
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Wednesday, November 01, 2017 9:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM Migrate
> 
> Trying to migrate a dataset to ML1 and the request just sits waiting in
> DFHSM. What do I need to turn on?
> TIA
> 

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

Re: DFHSM Migrate

[Bill Johnson]

I put tape recalls on hold yesterday because we were having an issue when older 
ML2 (on tape) datasets were trying to recall. We no longer have tape. 


Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 9:54 AM, Elardus Engelbrecht 
 wrote:

Bill Johnson wrote:

>Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert. Result 
>of QUERY ACTIVE.

>ARC0160I (CONT.) TAPERECALL=TOTALLY HELD,

TOTALLY HELD? This is smelling fishy to me. Look around if there is something 
holding, waiting or pending on your system and your tapes?

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



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

Re: DFHSM Migrate

[Elardus Engelbrecht]

Bill Johnson wrote:

>Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert. Result 
>of QUERY ACTIVE.

>ARC0160I (CONT.) TAPERECALL=TOTALLY HELD,

TOTALLY HELD? This is smelling fishy to me. Look around if there is something 
holding, waiting or pending on your system and your tapes?

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: DFHSM Migrate

[Bill Johnson]

Thanks, I did that also and there is just 1 requests waiting. The user. 
(Complaint to me)

ARC0101I QUERY REQUEST COMMAND STARTING ON HOST=1



ARC0162I MIGRATING DATA SET MFI01.COMMS.TEST.MIGRATED FOR USER CSIJY1, REQUEST



ARC0162I (CONT.) 0219 ON HOST 1



ARC0101I QUERY REQUEST COMMAND COMPLETED ON HOST=1



***




Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 9:42 AM, Richards, Robert B. 
 wrote:

Issue QUERY REQUEST and see if you are behind a lot of other activity.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 01, 2017 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migrate

Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert. Result 
of QUERY ACTIVE.

ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT HELD, RECALL=NOT HELD,



ARC0160I (CONT.) TAPERECALL=TOTALLY HELD, DATA SET MIGRATION=ACTIVE, VOLUME



ARC0160I (CONT.) MIGRATION=INACTIVE, DATA SET RECALL=INACTIVE


Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 9:20 AM, Richards, Robert B. 
 wrote:

Issue the QUERY ACTIVE command look for what is HELD, then RELEASE as 
appropriate

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 01, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM Migrate

Trying to migrate a dataset to ML1 and the request just sits waiting in DFHSM. 
What do I need to turn on?
TIA

--
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: DFHSM Migrate

[Richards, Robert B.]

Issue QUERY REQUEST and see if you are behind a lot of other activity.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 01, 2017 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migrate

Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert. Result 
of QUERY ACTIVE.

ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT HELD, RECALL=NOT HELD,



ARC0160I (CONT.) TAPERECALL=TOTALLY HELD, DATA SET MIGRATION=ACTIVE, VOLUME



ARC0160I (CONT.) MIGRATION=INACTIVE, DATA SET RECALL=INACTIVE


Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 9:20 AM, Richards, Robert B. 
 wrote:

Issue the QUERY ACTIVE command look for what is HELD, then RELEASE as 
appropriate

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 01, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM Migrate

Trying to migrate a dataset to ML1 and the request just sits waiting in DFHSM. 
What do I need to turn on?
TIA

--
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 Dump Exit - IEFU29

[Jackson, Rob]

My solution for the past ten years for all SMF dataset woes is the System 
Logger.  It has a number of benefits and no negatives that I have seen.  No 
more IEFU29, no more SMFDUMP, no more lost records because the daily dataset 
filled up.  One simple job every day to dump all records from the previous day, 
and it's a pleasure to have CICS, DB2, and especially SCRT records in separate 
logstreams.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Wednesday, November 01, 2017 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF Dump Exit - IEFU29

[External Email]

Hi Everyone,

We use the SMF dump exit, IEFU29, to initiate a started task to empty the SMF 
dump datasets when needed.  It works well but there is one issue.  IEFU29 
cannot issue a START command during an IPL because the SMF subsystem comes up 
before JES2.  There is code in the exit that looks to see if JES2 is active.  
If it is not, the exit terminates.

For those of you who use IEFU29, have you found a work-around for this problem?

Thank you.

Bill

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: DFHSM Migrate

[Bill Johnson]

Thanks. Did that already and it looks OK to me. I’m not a DFHSM expert. Result 
of QUERY ACTIVE.

ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT HELD, RECALL=NOT HELD,



ARC0160I (CONT.) TAPERECALL=TOTALLY HELD, DATA SET MIGRATION=ACTIVE, VOLUME



ARC0160I (CONT.) MIGRATION=INACTIVE, DATA SET RECALL=INACTIVE


Sent from Yahoo Mail for iPhone


On Wednesday, November 1, 2017, 9:20 AM, Richards, Robert B. 
 wrote:

Issue the QUERY ACTIVE command look for what is HELD, then RELEASE as 
appropriate

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 01, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM Migrate

Trying to migrate a dataset to ML1 and the request just sits waiting in DFHSM. 
What do I need to turn on?
TIA

--
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 Dump Exit - IEFU29

[Pew, Curtis G]

On Nov 1, 2017, at 7:15 AM, Rodatz, William J 
 wrote:
> 
> We use the SMF dump exit, IEFU29, to initiate a started task to empty the SMF 
> dump datasets when needed.  It works well but there is one issue.  IEFU29 
> cannot issue a START command during an IPL because the SMF subsystem comes up 
> before JES2.  There is code in the exit that looks to see if JES2 is active.  
> If it is not, the exit terminates.
> 
> For those of you who use IEFU29, have you found a work-around for this 
> problem?

I’m going to recommend that you switch to using logstreams for SMF. Then this 
problem goes away.

-- 
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: Why not SYSSYM=ALLOW?

[Pew, Curtis G]

On Oct 31, 2017, at 6:06 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Unintended substitution of symbols where programmers were too lazy to
> double ampersands where proper.

That makes sense, and shouldn’t be a problem for us.

Thanks.

-- 
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: DFHSM Migrate

[Richards, Robert B.]

Issue the QUERY ACTIVE command look for what is HELD, then RELEASE as 
appropriate

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Wednesday, November 01, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM Migrate

Trying to migrate a dataset to ML1 and the request just sits waiting in DFHSM. 
What do I need to turn on?
TIA

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

DFHSM Migrate

[Bill Johnson]

Trying to migrate a dataset to ML1 and the request just sits waiting in DFHSM. 
What do I need to turn on?
TIA

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

Re: SMF Dump Exit - IEFU29

[Carmen Vitullo]

I've been using different variation of that exit for years, first I have to 
ask; 
are your dumps going to tape? if so is your tape mgmt subsystem activate before 
the dumpsmf? 
I guess you could if there was a real need to dump SMF before anything else 
runs you could add a SUB=MSTR to the start command in the exit 
but our current process for dumping waits for 1) tape mgmt to be active, and 2) 
the OAM address space, (virtual tape servers) to be active, automation take 
care of any outstand WTOR's for allocation recovery if the dump runs before the 
tape drive are available 




Carmen 


- Original Message -

From: "William J Rodatz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, November 1, 2017 7:15:56 AM 
Subject: SMF Dump Exit - IEFU29 

Hi Everyone, 

We use the SMF dump exit, IEFU29, to initiate a started task to empty the SMF 
dump datasets when needed. It works well but there is one issue. IEFU29 cannot 
issue a START command during an IPL because the SMF subsystem comes up before 
JES2. There is code in the exit that looks to see if JES2 is active. If it is 
not, the exit terminates. 

For those of you who use IEFU29, have you found a work-around for this problem? 

Thank you. 

Bill 

-- 
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 Dump Exit - IEFU29

[Elardus Engelbrecht]

Rodatz, William J wrote:

>We use the SMF dump exit, IEFU29, to initiate a started task to empty the SMF 
>dump datasets when needed.  It works well but there is one issue.  IEFU29 
>cannot issue a START command during an IPL because the SMF subsystem comes up 
>before JES2.  There is code in the exit that looks to see if JES2 is active.  
>If it is not, the exit terminates.

>For those of you who use IEFU29, have you found a work-around for this problem?

Why worry? What are you trying to solve? Do you have a 'START PENDING' issue 
which can be a really PITA?

My workaround is - I simply schedule a 'I SMF' about 2-3 hours before a 
scheduled IPL. During IPL, I just wait out the IPL process and then have the 
automation software issue again a 'I SMF' a while after IPL.

I have two sets of SMF exits and jobs:

 - One to run the IEFU29 after a 'I SMF' command (at intervals by automation 
software or when as needed) which then start a STC to dump that MANx dataset 
where needed.

 - The usual SMFDUMP program which dumps all MANx datasets, do a I SMF and then 
dump whatever remains to be dumped.

In this way, all my SMF data are dumped without any intervention at all on all 
our LPARs.

Do you have any issues during IPL and SMF dumps?

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: DFSMShsm Copy Pools

[Richards, Robert B.]

Glenn,

> If so, can an end user use the standard ISMF DATASET panels to perform 
> HRECOVERs from them?   Or HRECOVER from 3.4?

So the answer to my question above is NO, for the reasons you specified  (only 
the FRBACKUP/FRRECOV/FRDELETE commands operate against copy pools). And I 
certainly have no desire to give an end user access to those commands from 
within the "P" selection, not to mention make them storage admins to even see 
that option.

We are using copy pools for DB2, or at least the DB2 sysprogs are testing the 
functionality. My question related to the second usage: recovering a dataset 
from an offline, full-volume copy *without* the involvement of a storage admin. 
Our end users are already familiar with the dataset panels and the 3.4 line 
command option.

Thanks for responding,

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Glenn Wilcock
Sent: Wednesday, November 01, 2017 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSMShsm Copy Pools

Hi,

There are many large clients who use DFSMShsm copy pools to backup their DB2 
systems.  Some also use it to create offline, full-volume copies of other 
volumes.  Only the FRBACKUP/FRRECOV/FRDELETE commands operate against copy 
pools.  FRRECOV does have a data set recovery option.  I recommend referring to 
the following Redbook: DFSMShsm Fast Replication Technical Guide.

Glenn Wilcock
DFSMShsm Architect

--
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: DFSMShsm Copy Pools

[Glenn Wilcock]

Hi,

There are many large clients who use DFSMShsm copy pools to backup their DB2 
systems.  Some also use it to create offline, full-volume copies of other 
volumes.  Only the FRBACKUP/FRRECOV/FRDELETE commands operate against copy 
pools.  FRRECOV does have a data set recovery option.  I recommend referring to 
the following Redbook: DFSMShsm Fast Replication Technical Guide.

Glenn Wilcock
DFSMShsm Architect

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

Re: Db2! was: NODE.js for z/OS (21)

[Timothy Sipples]

The b is lowercase, but the Z is now uppercase. Have a look:

https://www.ibm.com/analytics/us/en/db2/db2-for-zos/

https://www.ibm.com/systems/z/


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, 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