date:20180507

venkat kulkarni wrote:

>We using Netview 6.2. Now problem has been resolved by one of the major node . 
>Now i am able to login to netview for use.

Are you saurabh khandelwal collaborating to resolve this Netview logon problem?

It would be great to see if the OP has his/her problem resolved or not.

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: Job submit using REXX

Lizette Koehler wrote:

>This process can be done by using a trap for a message on your system.
>MPF Exit might work
>CBTTAPE.ORG might have a process you can tailor
>Any Scheduling software will have a file trigger function
>This is more complicated without scheduling software.  You will need to find a 
>process that monitors for messages and then provides an action for that message

Those SVTM messages are shown inside the STC (Connect Direct), not in SYSLOG.

Will your suggestions work in that scenario?


venkat kulkarni wrote:

>> We have requirement of setting up process of handling  FTP and then submit 
>> Job with FTP dataset. The process goes like this,

Use automation for submission, checking/monitoring these actions and then 
submit another job using REXX to process your datasets.


>> SVTM052I STEP01   COPY FDDB4142(  95,456)
>> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
>> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
>> SVTM052I  COMPLETED  /SCPA000I

>> So, basically we want to capture these dataset names from this message 
>> SVTM052I and send message to operator that file has been received and then 
>> submit one batch Job by putting this file name.

Rather, have that transfer job send out a message or execute a REXX program 
using those file names.


>> Is there any way to automate this whole process. I am new to REXX, so if 
>> someone can guide me on this solution.We receive  these files 3-4 times in a 
>> day or even more.

Yes, with automation software or with one of those CBTTAPE utilities.

Or you can checkup Brian Westerman's reply to you and his products.

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: GETMAIN LOC=32

Jim Mulder wrote:

>  GETMAIN is not going to ever manage 32-bit storage. I would word you 
> requirement this way:

> " I would like to have a USE2GTO4G=NO|YES parameter on IARV64 GETSTOR, 
> similar to the already exisiting USE2GTO32G=NO|YES and USE2GTO64G=NO|YES.  
> And I would like to have a way to tell the system to reserve the 2GTO4G area 
> to be used only for USE2GTO4G=YES requests."

Perhaps, but no-one said something about FREEMAIN. If you get what you want 
with GETMAIN, how do you do the FREEMAIN or any other clean-up work properly? 
In what AMODE do you want to do the cleanup?

I believe those 31 bit limits are there for good reasons including backward 
compatibility and checking the registers during an ABEND.

I can ask more questions like this one: what about a chain of programs which 
call other programs and each of them have their own unique GETMAIN macros with 
varying AMODEs and parameters?

Why specific GETMAIN? What about STORAGE macro?

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

Knowledge Centre - (was Re: Rant)

Susan Shumway wrote:

>You're hired, Elardus!  ;-)

Thanks for your nice compliment, I am humbled by your comments. Ok, but I am 
way too expensive - starting at $1 million per second, can you afford that? ;-D

Ok, seriously.

>My own broken record statement is that we're constantly trying to improve how 
>the Knowledge Center handles the extensive z/OS library of content. We always 
>appreciate input, though. 

What about Carmen Vitullo comments? He said:

>>That sounds great Susan, and I have the KC server running on an LPAR here, 
>>(2.2) and using Softcopy Librarian V5 to load the contents, so where are all 
>>the 'other' books I'd like to load, DB2, MQ, IMS...to name a few? 
>>those KC books do not appear in any selection, .Boo or .PDF format for me to 
>>download. what am I missing? 

They are there (on the internet) and these books on the KC were also discussed 
some time ago. Just that it can take some serious searching (even with Google) 
to locate them...

But, it would indeed be great if they (DB2, MQ, etc.) are also located on the 
KC Server on z/OS system.

To Susan, What about a really "big-mother-of-all" URL where all and every 
collections (hardware, software, operating systems, hot topics, redbooks, 
database systems, Linux, LookAt, etc.) are listed? That URL's domain name 
should stays permanently while the various addresses (domain and IP addresses) 
can change anytime.

I would appreciate it that there is one page where you go in and then do you 
jump to your favourite subject. Something like that Wikipedia portal 'Ongoing' 
[events].

That type of setup can then also be ported to z/OS where you have your own copy 
of KC.

Just my few [de-valuated] cents...

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: DFSORT help

2018-05-07 Thread Massimo Biancucci

Hi,

here a sample:

//ST002EXEC  PGM=SORT
//SYSOUTDD   SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=MYDCOLLECT
//SORTOUT  DD SYSOUT=*
//SYSIN DD   *
 OPTION VLSCMP
 INCLUDE COND=(9,2,BI,EQ,C'D ',AND, ONLY TYPE 'D'
   74,1,BI,NE,B'..1.',AND,  NO TEMPORARY
   75,1,BI,NE,B'.1..')  NO ICF CATALOG
 INREC IFTHEN=(WHEN=INIT,
 BUILD=(1,4,RDW
29,44,  DSNAME
83,6,   DCDVOLSR
109,4,PD,EDIT=('TTT'), PACKED TO ZONED

171,30, STORAGE CLASS
235,30))STORAGE GROUP
 SORT FIELDS=(5,44,BI,A,49,2,BI,A),STOPAFT=1
 OUTFIL FNAMES=SORTOUT,VTOF,
  OUTREC=(5,44,
  49,6,
  55,7,Y4T,TOGREG=Y4T, JULIAN TO GREG
  62,30,
  92,30)
/*

best regards.
Max

2018-05-01 13:04 GMT+02:00 Gadi Ben-Avi :

> Thanks
> The examples are also in the SICESAMP library, but there is nothing there
> that helps me.
>
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David Betten
> Sent: Tuesday, May 1, 2018 1:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT help
>
> This might help.  On the DFSORT web site there's a file that includes
> examples for using ICETOOL to analyze DFHSM, DFSMSrmm and DCOLLECT.
>
> http://www-01.ibm.com/support/docview.wss?rs=114&uid=isg3T797#ex
>
>
> Have a nice day,
> Dave Betten
> z/OS Performance Specialist
> Cloud and Systems Performance
> IBM Corporation
> email:  bet...@us.ibm.com
>
> IBM Mainframe Discussion List  wrote on
> 05/01/2018 05:16:57 AM:
>
> > From: Gadi Ben-Avi 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 05/01/2018 05:17 AM
> > Subject: DFSORT help
> > Sent by: IBM Mainframe Discussion List 
> >
> >
> > I use the free version of Spam Reader to get rid of spam. The
> > Professional version doesn't have this disclaimer in outgoing emails.
> > Try Spam Reader for free now!
> > Hi,
> > I am new to DFSORT.
> > I would like to create an OUTREC statement that will take the output
> > from DCOLLCT type D records and give me the following fields:
> > DSN, VOLSER, STORAGE Class or Storage Group and create date in a
> > readable format (ddmm) Can anyone help with this?
> >
> > Thanks
> >
> > Gadi
> > הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת
> > סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד
> > וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת
> > בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע
> > כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון.
> >
> > --
> > 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: GETMAIN LOC=32

On Mon, 7 May 2018 02:58:38 -0500, Elardus Engelbrecht 
 wrote:

>>  GETMAIN is not going to ever manage 32-bit
>> storage. I would word you requirement this way:

> Why specific GETMAIN? What about STORAGE macro?

For an existing 32-bit program, being able to
change LOC=31 or LOC=ANY to LOC=32 is
the simplest change, and on an old system
it will still work, just obtaining LOC=31 memory
instead of LOC=32 memory, better than nothing.

>> " I would like to have a USE2GTO4G=NO|YES
>> parameter on IARV64 GETSTOR,

However, *as well as* GETMAIN having the
capability I have no problem with other
facilities such as IARV64 being able to do
the same thing. I see no reason to hold
back GETMAIN. And note that if a program
using the IARV64 macro with the new
parameter is run on an older system, what
do you get then? Memory above 4 GiB?
GETMAIN won't have that problem, as it
reverts to LOC=31 memory.

> Perhaps, but no-one said something about FREEMAIN.
> If you get what you want with GETMAIN, how do you
> do the FREEMAIN or any other clean-up work properly?
> In what AMODE do you want to do the cleanup?

I would expect the FREEMAIN to also be done in
AM64. What happens currently if a GETMAIN is
done in AM31 and later the FREEMAIN is done
in AM24?

> I believe those 31 bit limits are there for good
> reasons including backward compatibility

For backward compatibility I have asked for
the LOC=31 bits to be used as well as using
a reserved bit. I see no other issue. LOC=32
doesn't mean that you *must* get memory
above 2 GiB. It just needs to be anywhere
in the 4 GiB space, so programs will happily
accept getting lower memory when they do
a LOC=32 request.

> and checking the registers during an ABEND.

I believe an ABEND will have the same problem
in AM31, not knowing whether a register is
actually AM24.

> I can ask more questions like this one: what
> about a chain of programs which call other
> programs and each of them have their own
> unique GETMAIN macros with varying AMODEs
> and parameters?

I don't see any issue with this, just the same
as there is no issue with a chain of programs
that use a mixture of LOC=24 and LOC=31
GETMAINs and mixture of AM24/31 AMODEs.

BFN. Paul.

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

Re: GETMAIN LOC=32

Paul Edwards wrote:

>However, *as well as* GETMAIN having the capability I have no problem with 
>other facilities such as IARV64 being able to do
the same thing. I see no reason to hold back GETMAIN. And note that if a 
program using the IARV64 macro with the new parameter is run on an older 
system, what do you get then? Memory above 4 GiB?  GETMAIN won't have that 
problem, as it
reverts to LOC=31 memory.

Hmmm, interestin what you said. Perhaps you should include IARV64 (as per Jim's 
suggestion) in your request and then you'll have to wait and see whether it is 
accepted or not.

Good luck!

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: GETMAIN LOC=32

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder  wrote:

>>  GETMAIN is not going to ever manage 32-bit storage.
>> I would word you requirement this way:
>
> " I would like to have a USE2GTO4G=NO|YES 
> parameter on IARV64 GETSTOR,

Hi Jim. Thanks for the interesting suggestion, but
by separating the 2 GiB - 4 GiB region it means
that an application can't do a GETMAIN for 3 GiB
of memory. If GETMAIN is modified as I requested,
the 16 MiB to 4 GiB region will be a continuous
region and a GETMAIN of 3 GiB will work so long
as there hasn't been fragmentation. ie a 32-bit
program can allocate a single 3 GiB chunk.

BFN. Paul.

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

Re: GETMAIN LOC=32

2018-05-07 Thread Denis

Hi,

on behalf of a customer we discussed the idea of something like transparent 
64bit to 31bit mirroring. Such that IARV64 has an option like MAP31BIT=YES 
which gives you an address back that allows existing 31bit programs to address 
this area without copying. Every access off that returned address is mapped by 
hardware/z/os into that storage. Ideally also for already allocated areas and 
the possibility to deregister the 31bit addressing without freeing the 
allocated 64bit areas. Also the requirement to be able to mirror just parts of 
the 64bit area.
For now we have not pursued it. The business case was to be able to pass a 
31bit address to unchanged existing 31bit programs and be able to access 
storage beyond the 2G range without modifying those and without modifying the 
interfaces which only have roon for 31bit pointers.
I am wondering if there is interest from other customers for something like 
this?

Thanks, Denis.

-Original Message-
From: Paul Edwards 
To: IBM-MAIN 
Sent: Mon, May 7, 2018 12:32 PM
Subject: Re: GETMAIN LOC=32

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder d10j...@us.ibm.com> wrote:

>>  GETMAIN is not going to ever manage 32-bit storage.
>> I would word you requirement this way:
>
> " I would like to have a USE2GTO4G=NO|YES 
> parameter on IARV64 GETSTOR,

Hi Jim. Thanks for the interesting suggestion, but
by separating the 2 GiB - 4 GiB region it means
that an application can't do a GETMAIN for 3 GiB
of memory. If GETMAIN is modified as I requested,
the 16 MiB to 4 GiB region will be a continuous
region and a GETMAIN of 3 GiB will work so long
as there hasn't been fragmentation. ie a 32-bit
program can allocate a single 3 GiB chunk.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to mailto:lists...@listserv.ua.edu";>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: GETMAIN LOC=32

On Mon, 7 May 2018 05:32:16 -0500, Paul Edwards wrote:

>If GETMAIN is modified as I requested,
>the 16 MiB to 4 GiB region will be a continuous
>region and a GETMAIN of 3 GiB will work so long
>as there hasn't been fragmentation. ie a 32-bit
>program can allocate a single 3 GiB chunk.

No, it couldn't. The top op the 2 GB address space is ELSQA, ECSA, and EPLPA. 
You keep talking about a "32-bit program" as if that is a thing. It isn't.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:05:19 -0500, Tom Marchant  
wrote:

>>If GETMAIN is modified as I requested,
>>the 16 MiB to 4 GiB region will be a continuous
>>region and a GETMAIN of 3 GiB will work so long
>>as there hasn't been fragmentation. ie a 32-bit
>>program can allocate a single 3 GiB chunk.
>
>No, it couldn't. The top op the 2 GB address space is ELSQA, ECSA, and EPLPA.

Is there anything preventing those areas being relocated
closer to the 16 MiB line?

>You keep talking about a "32-bit program" as if that is a thing. It isn't.

What terminology do you suggest using for a
program that only uses the 32-bit registers
as found in S/370, but may be running in any
AMODE including AM64?

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 04:15:50 -0500, Paul Edwards wrote:

>For an existing 32-bit program, being able to
>change LOC=31 or LOC=ANY to LOC=32 is
>the simplest change, and on an old system
>it will still work, just obtaining LOC=31 memory
>instead of LOC=32 memory, better than nothing.

You want to change an AMODE(31) program to AMODE(64) and you 
think that all you have to change is the GETMAIN?

You haven't given it nearly enough thought

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

2018-05-07 Thread Peter Relson

The term "32-bit program" has been repeated in this thread. It appears 
that the OP means by this that the program can be AMODE 31 or AMODE 64 but 
never directly touches bits 0-31 of a GR. 

It appears that the OP is interested in expanding the program to 
accommodate twice as much storage as it has access today (which in general 
is a very limited increase and one might call it short-sighted since how 
often is "twice as much" enough, except as a temporary measure?), while 
still having to deal with being in AMODE 64 when using the storage that 
happens to be within the bar, but not wanting to use 8-byte data pointers 
and not wanting to use the available instructions that set 8-byte 
registers. 

The OP wrote:
>Any 32-bit program currently coming up against the 2 GiB barrier can have 

>its life extended by bumping the limit up to 4 GiB.
"Extending life" is not going to be thought to be sufficient rationale for 
what would be a very large effort.  Since the program would already need 
to be changed, having it deal fully with 64-bit addresses is often not a 
big deal. 

Anyone is welcome to submit an RFE for just about anything that they want. 
An RFE requesting this function will almost certainly be declined. I say 
that only to set realistic expectations. 

Perhaps some are not aware that the area 2G-32G is already defined for use 
by Java and other language runtimes, in very specific implementations.

Peter Relson
z/OS Core Technology Design

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

Re: Job submit using REXX

If it is only in the STC Job log, or other DD statement, then no.

The request would then require something like ISFEXEC (SDSF REXX) and it would 
not be real time.  It would then have to be run at a frequency that makes sense.

Anything not presented to the SYSLOG/OPERLOG would not be seen by the MPF exit.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Elardus Engelbrecht
> Sent: Monday, May 07, 2018 12:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job submit using REXX
> 
> Lizette Koehler wrote:
> 
> >This process can be done by using a trap for a message on your system.
> >MPF Exit might work
> >CBTTAPE.ORG might have a process you can tailor Any Scheduling software
> >will have a file trigger function This is more complicated without
> >scheduling software.  You will need to find a process that monitors for
> >messages and then provides an action for that message
> 
> Those SVTM messages are shown inside the STC (Connect Direct), not in SYSLOG.
> 
> Will your suggestions work in that scenario?
> 
> 
> venkat kulkarni wrote:
> 
> >> We have requirement of setting up process of handling  FTP and then
> >> submit Job with FTP dataset. The process goes like this,
> 
> Use automation for submission, checking/monitoring these actions and then
> submit another job using REXX to process your datasets.
> 
> 
> >> SVTM052I STEP01   COPY FDDB4142(  95,456)
> >> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> >> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
> >> SVTM052I  COMPLETED  /SCPA000I
> 
> >> So, basically we want to capture these dataset names from this message
> SVTM052I and send message to operator that file has been received and then
> submit one batch Job by putting this file name.
> 
> Rather, have that transfer job send out a message or execute a REXX program
> using those file names.
> 
> 
> >> Is there any way to automate this whole process. I am new to REXX, so if
> someone can guide me on this solution.We receive  these files 3-4 times in a
> day or even more.
> 
> Yes, with automation software or with one of those CBTTAPE utilities.
> 
> Or you can checkup Brian Westerman's reply to you and his products.
> 
> 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: GETMAIN LOC=32

On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote:

>As far as I can tell, the BAR exists for the same
>reasons that 16 MiB LINE exists - historical
>curiosity. 

Right. And compatibility

>No reason to be stuck with that forever.
>Most other 32-bit programming environments
>allow access to the full 4 GiB and z/Arch is
>capable of delivering the same functionality
>to z/OS users.

You can argue over the wisdom of IBM going to 31-bit addressing with 
370/Extended Architecture in 1982. You can also argue about the wisdom 
of their decisions around managing the nearly 8 PB above the bar 
differently than the 2 GB below it. These are decisions that were made
long ago. Jim has offered you a suggestion that will give you what you 
are asking for - a way to allocate storage in the range from 2 GB to 4 GB. 

The notion that you want z/Architecture to behave like it supports 32-bit 
addressing is silly.

That's my opinion, and there is no way I will support your RFE.

-- 
Tom Marchant

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

Re: Job submit using REXX

If this is only for one dataset and the message is in SYSLOG, then the MPF list 
would work.

If there are multiple datasets that need to be available before proceeding, 
then it is getting to be a bit trickier.

Several Scheduling software have Dataset Triggers.  And they sometimes will 
monitor for the creation of an SMF Record (Type 30 I think). Then take action 
as described to their process.

Humans can see that datasets are there and then submit jobs.  But that requires 
a human to be vigilant and submit the job when all requirements are met.

Also, the human has to review the message and ensure the return code is 0 
before proceeding.


So to provide the function for the OP without purchasing a product, will be a 
challenge I think.

   1)  Monitor for dataset creation via SVT messages.
   a) If more than one file has to be sent, then monitor for additional 
creations before proceeding
   2)  Ensure message shows 0 return code.  Anything else needs to be reviewed
   3)  Ensure all files are available before the next job is submitted

Unless the OP has other requirements, I think the three listed are what are 
needed.

Lizette




> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Lizette Koehler
> Sent: Monday, May 07, 2018 5:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job submit using REXX
> 
> If it is only in the STC Job log, or other DD statement, then no.
> 
> The request would then require something like ISFEXEC (SDSF REXX) and it
> would not be real time.  It would then have to be run at a frequency that
> makes sense.
> 
> Anything not presented to the SYSLOG/OPERLOG would not be seen by the MPF
> exit.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Elardus Engelbrecht
> > Sent: Monday, May 07, 2018 12:43 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Job submit using REXX
> >
> > Lizette Koehler wrote:
> >
> > >This process can be done by using a trap for a message on your system.
> > >MPF Exit might work
> > >CBTTAPE.ORG might have a process you can tailor Any Scheduling
> > >software will have a file trigger function This is more complicated
> > >without scheduling software.  You will need to find a process that
> > >monitors for messages and then provides an action for that message
> >
> > Those SVTM messages are shown inside the STC (Connect Direct), not in
> SYSLOG.
> >
> > Will your suggestions work in that scenario?
> >
> >
> > venkat kulkarni wrote:
> >
> > >> We have requirement of setting up process of handling  FTP and then
> > >> submit Job with FTP dataset. The process goes like this,
> >
> > Use automation for submission, checking/monitoring these actions and
> > then submit another job using REXX to process your datasets.
> >
> >
> > >> SVTM052I STEP01   COPY FDDB4142(  95,456)
> > >> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> > >> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
> > >> SVTM052I  COMPLETED  /SCPA000I
> >
> > >> So, basically we want to capture these dataset names from this
> > >> message
> > SVTM052I and send message to operator that file has been received and
> > then submit one batch Job by putting this file name.
> >
> > Rather, have that transfer job send out a message or execute a REXX
> > program using those file names.
> >
> >
> > >> Is there any way to automate this whole process. I am new to REXX,
> > >> so if
> > someone can guide me on this solution.We receive  these files 3-4
> > times in a day or even more.
> >
> > Yes, with automation software or with one of those CBTTAPE utilities.
> >
> > Or you can checkup Brian Westerman's reply to you and his products.
> >
> > 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: GETMAIN LOC=32

On Mon, 7 May 2018 07:15:23 -0500, Tom Marchant  
wrote:

>>For an existing 32-bit program, being able to
>>change LOC=31 or LOC=ANY to LOC=32 is
>>the simplest change, and on an old system
>>it will still work, just obtaining LOC=31 memory
>>instead of LOC=32 memory, better than nothing.
>
>You want to change an AMODE(31) program to AMODE(64) and you 
>think that all you have to change is the GETMAIN?

That's the best case scenario, yes. It
depends on the application. As an
example I recently asked the author
of REVIEW what would be required to
make his AM31/RM24 program work as
AM64/RM24 and he didn't list much.
REVIEW is a large assembler application
that has been written over decades.

Also, the things that need to change would
also need to change if it was converted to a
64-bit application. It's a much less onerous
task to keep it as a 32-bit application.

>You haven't given it nearly enough thought

Maybe we can list the situations:

If any 31-bit addresses exist with a flag
in the top bit, it can't be cleared with LA.
You will need to do an N with X'7FFF'
to clear it before it can be used at all.

On program entry, R15 will not contain the
entry point so you need to do a BALR R15,R0.

You can't use a negative index and expect
wrapping at 32 bits.

GETMAIN R needs to change to GETMAIN RU,LOC=24

These are fairly minor things. Did I miss
something?

Oh - I'm also assuming that IBM will update
the operating system so that READ etc can
be executed in AM64. Just like they updated
READ from AM24-only to bimodal in late
MVS/ESA. But from the application side, there's
not much, and we can start making those
application changes now in anticipation of
being able to run as AM64 in the future.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:09:40 -0500, Paul Edwards wrote:

>What terminology do you suggest using for a
>program that only uses the 32-bit registers
>as found in S/370, but may be running in any
>AMODE including AM64?

"Short-sighted."

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

2018-05-07 Thread Allan Staller

AM64 is very different than what you are have been asking for in this thread.

z/OS currently supports 3 addressing modes;
AM24, AM31 and AM64. What you are asking for is a major re-architecting of z/OS 
to create AM32.

As (IIRC) Peter Relson pointed out that JAVA is able to use this storage.
As Jim Mulder pointed out, this is also a subset of AM64.

I do not believe specific request is very likely to happen.

My $USD 0.02 worth.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Edwards
Sent: Monday, May 7, 2018 7:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:15:23 -0500, Tom Marchant  
wrote:

>>For an existing 32-bit program, being able to change LOC=31 or LOC=ANY
>>to LOC=32 is the simplest change, and on an old system it will still
>>work, just obtaining LOC=31 memory instead of LOC=32 memory, better
>>than nothing.
>
>You want to change an AMODE(31) program to AMODE(64) and you think that
>all you have to change is the GETMAIN?

That's the best case scenario, yes. It
depends on the application. As an
example I recently asked the author
of REVIEW what would be required to
make his AM31/RM24 program work as
AM64/RM24 and he didn't list much.
REVIEW is a large assembler application
that has been written over decades.

Also, the things that need to change would also need to change if it was 
converted to a 64-bit application. It's a much less onerous task to keep it as 
a 32-bit application.

>You haven't given it nearly enough thought

Maybe we can list the situations:

If any 31-bit addresses exist with a flag in the top bit, it can't be cleared 
with LA.
You will need to do an N with X'7FFF'
to clear it before it can be used at all.

On program entry, R15 will not contain the entry point so you need to do a BALR 
R15,R0.

You can't use a negative index and expect wrapping at 32 bits.

GETMAIN R needs to change to GETMAIN RU,LOC=24

These are fairly minor things. Did I miss something?

Oh - I'm also assuming that IBM will update the operating system so that READ 
etc can be executed in AM64. Just like they updated READ from AM24-only to 
bimodal in late MVS/ESA. But from the application side, there's not much, and 
we can start making those application changes now in anticipation of being able 
to run as AM64 in the future.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:49:31 +, Allan Staller  wrote:

>AM64 is very different than what you are have been asking for in this thread.
>
>z/OS currently supports 3 addressing modes;
>AM24, AM31 and AM64. What you are asking for is a major re-architecting of 
>z/OS to create AM32.

In a way you can say that it is a form of AM32.
But I am not asking for a formal AM32, I am
happy to run as AM64.

In fact one day I hope that all z/OS shops
execute entirely in AM64 - regardless of
whether it is a 32-bit or a 64-bit program
that is being executed. And that the hardware
has an option to enforce that.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote:

>Oh - I'm also assuming that IBM will update
>the operating system so that READ etc can
>be executed in AM64.

ROFL! You didn't ask for that. I think that you are assuming that is is trivial.

Are you also assuming that they will accept an address above the bar for 
parameters?

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:15:45 -0400, Peter Relson  wrote:

>The term "32-bit program" has been repeated in this thread. It appears 
>that the OP means by this that the program can be AMODE 31 or AMODE 64 but 
>never directly touches bits 0-31 of a GR. 

Thanks for providing that clarification. You are
totally correct.

>It appears that the OP is interested in expanding the program to 
>accommodate twice as much storage as it has access today (which in general 
>is a very limited increase and one might call it short-sighted since how 
>often is "twice as much" enough, except as a temporary measure?), while 
>still having to deal with being in AMODE 64 when using the storage that 
>happens to be within the bar, but not wanting to use 8-byte data pointers 
>and not wanting to use the available instructions that set 8-byte 
>registers. 

Yes, this is correct.

Based on your clarifications, I have updated my RFE.
Basically just the last paragraph below. Can you tell
me if any further clarification or rewording is required
so that IBM at least fully understands my request, even
if they reject it as too much work?

Thanks. Paul.

I would like GETMAIN to support a LOC=32
parameter, giving 32-bit programs access
to a full 4 GiB instead of the current
2 GiB provided by LOC=31. The LOC=31 bits
plus the top bit of the option byte seen here:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieav200/svc120.htm

can be used to signal a LOC=32 request.

When the GETMAIN is executed in AM64,
memory above 2 GiB is potentially returned.
When executed in AM31, normal LOC=31
memory is obtained instead. This way the
application will still work on older systems
that aren't LOC=32 aware.

When obtaining LOC=32 memory, the GETMAIN
routine should search *down* the free memory
chain to find a free area, to preserve the LOC=31
space, and if there is no fragmentation, allow
a request for a single 3 GiB of memory to be
satisfied (as a single block spanning the 2 GiB
boundary).

It is up to the application program to ensure that
when manipulating the LOC=32 memory it is in
AM64 and while in AM64 it does not attempt to
use the top bit of any 32-bit register as a flag.

Note that by "32-bit program" I mean a program that
can be running in AM24 or AM31 or AM64, but never
directly touches bits 0-31 of a general register.
ie data pointers are always 4-bytes and no
instruction that touches an 8-byte register is
ever executed. This allows compact 32-bit programs
to continue to be written instead of having the
overhead of switching everything to 64-bit. A
program would only need to be rewritten or
rebuilt with a different compiler option if it
started to exceed the 4 GiB limit rather than
exceeding a 2 GiB limit.

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

IZUGUTSE ?

I have been reading the new z/OSMF Redbook and found in section 4.5 info about 
IZUGUTSE (gutsy) that appears to generate XML for use with establishing z/OSMF 
security regardless of the ESM.

BUT I've not found any information about it in the z/OS 2.3 internet library, 
knowledge center, etc.

I was hoping it would simplify the establishment of granular security for the 
various elements of z/OSMF when using CA Top Secret.

Thanks for any suggestions.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer - RavenTek Solution Partners


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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:29:23 -0500, Tom Marchant  
wrote:

>>Oh - I'm also assuming that IBM will update
>>the operating system so that READ etc can
>>be executed in AM64.
>
>ROFL! You didn't ask for that.

I didn't ask for it yet because the first step is to
just have RM32 memory available. If I can at
least have RM32 memory I can still switch to
AM31 prior to executing READ.

> I think that you are assuming that is is trivial.

Yes, all I want them to do for READ is to test
the current AMODE, and if it is 64, to do a
BSM to AM31, and run the rest of READ as
AM31 and then restore AM64 on return.
Maybe 10 lines of code that disadvantages
no-one.

> Are you also assuming that they will accept an
> address above the bar for parameters?

No, I am expecting all data to have been
allocated with RM24 or RM31 as currently
documented by READ etc. I have no interest
in putting OS-related data above the 2 GiB
bar, and I have limited interest in putting the
load module above the 2 GiB bar. I'm only
interested in putting *application data*
above the 2 GiB bar.

BFN. Paul.

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

Re: GETMAIN LOC=32

2018-05-07 Thread Joel C. Ewing

On 05/07/2018 07:39 AM, Tom Marchant wrote:
> On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote:
>
>> As far as I can tell, the BAR exists for the same
>> reasons that 16 MiB LINE exists - historical
>> curiosity. 
> Right. And compatibility
>
>> No reason to be stuck with that forever.
>> Most other 32-bit programming environments
>> allow access to the full 4 GiB and z/Arch is
>> capable of delivering the same functionality
>> to z/OS users.
> You can argue over the wisdom of IBM going to 31-bit addressing with 
> 370/Extended Architecture in 1982. You can also argue about the wisdom 
> of their decisions around managing the nearly 8 PB above the bar 
> differently than the 2 GB below it. These are decisions that were made
> long ago. Jim has offered you a suggestion that will give you what you 
> are asking for - a way to allocate storage in the range from 2 GB to 4 GB. 
>
> The notion that you want z/Architecture to behave like it supports 32-bit 
> addressing is silly.
>
> That's my opinion, and there is no way I will support your RFE.
>
One of the big advantages of IBM mainframes (since S/360) has been
upward compatibility for application code.  Unlike other platforms, you
don't have to redesign application assembly code or re-compile all
application programs just because of an operating system upgrade or an
architecture upgrade.   Documented application code interfaces continue
to be compatible.

>From the early days of S/360 the high-order bit of a full-word address
pointer has a documented function in standard subroutine linkage of
indicating the last parameter address for subroutines that accept a
variable number of parameters, so even if the architecture might not
restrict using that bit for memory addressing, long-standing software
standards for AMODE24 and AMODE31 do.

Changing the documented conventions for using the high-order bit of a
32-bit address word to create a new "AMODE32" would potentially
adversely effect too many things for minimal benefit.  Not going to
happen, since there are already much less disruptive alternatives
available for large in-memory code (AMODE64) and large in-memory data
(Dataspaces); and there are ways to mix both of those approaches with
AMODE31 code if you don't want to go the full AMODE64 route.

Most of the peculiarities in z/OS aren't preserved for their historical
curiosity value, but to avoid breaking functional application code. 
That is a design philosophy that large corporations with thousands of
existing programs with functional application code tend to appreciate.

    Joel C. Ewing

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

RMM tape init question

We have recently converted to RMM. I need to init a bunch of used tapes 
that already have a volid. I have hit several problems and it just seems 
that the only way to do what I need is to process the tapes twice.


Using EDGINERS, it appears that you can only change a volid if the 
existing volid is already in the RMM catalog. These tapes are not in the 
catalog.


So, it looks like I need to relabel the tapes using other tools, such as 
IEHINITT, then run EDGINERS against the tape.


Did I miss something that would make this a much simpler process?

--
Tony Thigpen

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing  wrote:

>From the early days of S/360 the high-order bit of a full-word address
>pointer has a documented function in standard subroutine linkage of
>indicating the last parameter address for subroutines that accept a
>variable number of parameters, so even if the architecture might not
>restrict using that bit for memory addressing, long-standing software
>standards for AMODE24 and AMODE31 do.
>
>Changing the documented conventions for using the high-order bit of a
>32-bit address word

This convention *already* has to change for
anyone considering moving to AM64 and
using 64-bit pointers. There's no reason why
it should be mandatory for a full 64-bit
application, but disallowed for a 32-bit program.

Updating 32-bit programs to conform to
AM64 requirements is far less onerous
than the massive changes required to
create a 64-bit application.

> to create a new "AMODE32" would potentially
>adversely effect too many things for minimal benefit.

Nobody is affected, and the benefit of going from
a 2 GiB address space to a 4 GiB address space
is a great improvement.

BFN. Paul.

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

Re: GETMAIN LOC=32

2018-05-07 Thread John McKown

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote:
>
> >Oh - I'm also assuming that IBM will update
> >the operating system so that READ etc can
> >be executed in AM64.
>
> ROFL! You didn't ask for that. I think that you are assuming that is is
> trivial.
>

What I thought about, but haven't ever throw out here for discussion, is
the idea that IBM should create a new "subsystem" accessable via the
SUBSYS= on the DD which would allow accessing PS type data sets via an ACB.
What I envision would be that when the subsystem DS was OPEN'd, the
subsystem would load an I/O routine into RMODE(24) storage and dynamically
create a DCB & new DD statement with the same DSN. Then a GET or PUT via
the ACB would invoke the I/O module appropriately which would switch to
AMODE(24) and the the actual QSAM/BSAM I/O. This would allow at least the
majority of the uses people have for PS type datasets to use this interface
from AMODE(31) or AMODE(64) routine in a consistent GUPI manner which
everybody in the industry doing it the same way, rather than "ad hoc".

>
> Are you also assuming that they will accept an address above the bar for
> parameters?
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

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: GETMAIN LOC=32


Paul,

I thing you are just 'digging your heels in' at this point and not 
listening to what people are trying to tell you. I suggest you re-read 
some of the responses with a more open mind.


Tony Thigpen

Paul Edwards wrote on 05/07/2018 09:51 AM:

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing  wrote:


From the early days of S/360 the high-order bit of a full-word address
pointer has a documented function in standard subroutine linkage of
indicating the last parameter address for subroutines that accept a
variable number of parameters, so even if the architecture might not
restrict using that bit for memory addressing, long-standing software
standards for AMODE24 and AMODE31 do.

Changing the documented conventions for using the high-order bit of a
32-bit address word


This convention *already* has to change for
anyone considering moving to AM64 and
using 64-bit pointers. There's no reason why
it should be mandatory for a full 64-bit
application, but disallowed for a 32-bit program.

Updating 32-bit programs to conform to
AM64 requirements is far less onerous
than the massive changes required to
create a 64-bit application.


to create a new "AMODE32" would potentially
adversely effect too many things for minimal benefit.


Nobody is affected, and the benefit of going from
a 2 GiB address space to a 4 GiB address space
is a great improvement.

BFN. Paul.

--
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: GETMAIN LOC=32

On Mon, 7 May 2018 08:51:05 -0500, Paul Edwards wrote:

>Updating 32-bit programs to conform to
>AM64 requirements is far less onerous
>than the massive changes required to
>create a 64-bit application.

No, it isn't. Why do you think it is?

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 09:54:34 -0400, Tony Thigpen  wrote:

>I thing you are just 'digging your heels in' at this point and not
>listening to what people are trying to tell you. I suggest you re-read
>some of the responses with a more open mind.

Almost everything I have talked about here is
*already* working fine in MVS/380, and I am
happily able to run 32-bit GCCMVS programs
as AM64. I just want z/OS to match MVS/380,
and there is nothing technically preventing
that from happening.

BFN. Paul.

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

Re: RMM tape init question

2018-05-07 Thread John McKown

On Mon, May 7, 2018 at 8:48 AM, Tony Thigpen  wrote:

> We have recently converted to RMM. I need to init a bunch of used tapes
> that already have a volid. I have hit several problems and it just seems
> that the only way to do what I need is to process the tapes twice.
>
> Using EDGINERS, it appears that you can only change a volid if the
> existing volid is already in the RMM catalog. These tapes are not in the
> catalog.
>
> So, it looks like I need to relabel the tapes using other tools, such as
> IEHINITT, then run EDGINERS against the tape.
>
> Did I miss something that would make this a much simpler process?
>
> --
> Tony Thigpen
>
>
So you have a volume which is, for example, already initialized as 10
which is not registered with RMM. You want to initialize it as 20 and
register it with RMM at the same time. I don't know RMM. But looking at
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idarc00/excinr.htm

I would think that you could use the WRONGLABEL(IGNORE) to do what you
want. You might need LABEL=(1,BLP) to do this, I don't know. And I'm
totally ignoring the question of the external bar coded volser on the tape
which is used by the robot. I guess I'm also assuming an automated tape
library. In the case of an ATL, I would physically relabel the old tape
with the new volser; then insert it into the robot. The JCL would then
refer to the new volser so that the robot gets the proper tape. That's why
I'd use the LABEL=(1,BLP) so that z/OS doesn't get "huffy" about things.

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

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: GETMAIN LOC=32

On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant  
wrote:

>>Updating 32-bit programs to conform to
>>AM64 requirements is far less onerous
>>than the massive changes required to
>>create a 64-bit application.
>
>No, it isn't. Why do you think it is?

All references to "L" to load an address need
to be changed to "LG". All A() constants need
to be changed to AD(). Well, there is a way
around that. You can instead do a SGR and
then continue to use L. All save areas need
to be changed to cope with the larger
requirements.

But even if it was easy, most applications
don't need more than 4 GiB of memory, so
it's best to keep them 32-bit as that is more
compact.

Would it help if I ask the author of REVIEW how
much effort it would take him to produce a
64-bit version of his product so that datasets
more than 4 GiB in size can be edited? That
would certainly be nice.

BFN. Paul.

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

Re: GETMAIN LOC=32

2018-05-07 Thread Steve Smith

It seems you want IBM to do a lot of work to save you a little.  Not very
likely, I think.

Java manages to address 32GB with 32-bit pointers.  4GB would be simpler.


-- 
sas

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

Re: RMM tape init question

Thanks.

I was looking at the SYSIN parms for EDGINERS and never noticed that
there were additional options as a parm on the EXEC card. I will try
this later today.

These tapes have had their external labels removed to facilitate putting
new robot labels that are within our normal volid range. We have done
this using CA1 in the past, but now we are running RMM. So, I don't know
what the current internal label is.

Tony Thigpen

John McKown wrote on 05/07/2018 10:05 AM:

On Mon, May 7, 2018 at 8:48 AM, Tony Thigpen wrote:

We have recently converted to RMM. I need to init a bunch of used tapes
that already have a volid. I have hit several problems and it just seems
that the only way to do what I need is to process the tapes twice.

Using EDGINERS, it appears that you can only change a volid if the
existing volid is already in the RMM catalog. These tapes are not in the
catalog.

So, it looks like I need to relabel the tapes using other tools, such as
IEHINITT, then run EDGINERS against the tape.

Did I miss something that would make this a much simpler process?

--
Tony Thigpen

So you have a volume which is, for example, already initialized as 10
which is not registered with RMM. You want to initialize it as 20 and
register it with RMM at the same time. I don't know RMM. But looking at
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idarc00/excinr.htm

I would think that you could use the WRONGLABEL(IGNORE) to do what you
want. You might need LABEL=(1,BLP) to do this, I don't know. And I'm
totally ignoring the question of the external bar coded volser on the tape
which is used by the robot. I guess I'm also assuming an automated tape
library. In the case of an ATL, I would physically relabel the old tape
with the new volser; then insert it into the robot. The JCL would then
refer to the new volser so that the robot gets the proper tape. That's why
I'd use the LABEL=(1,BLP) so that z/OS doesn't get "huffy" about things.

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

Re: GETMAIN LOC=32

2018-05-07 Thread Don Poitras

In article <3154560307111841.wa.mutazilahgmail@listserv.ua.edu> you wrote:
> On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant  
> wrote:

> >>Updating 32-bit programs to conform to
> >>AM64 requirements is far less onerous
> >>than the massive changes required to
> >>create a 64-bit application.
> >
> >No, it isn't. Why do you think it is?

> All references to "L" to load an address need
> to be changed to "LG".

Not necessarily. When we implemented large heap support for SAS/C, we
used a scheme where we could avoid re-writing large parts of the
assembler source by limitting ourselves to 2G "Continents" (a term I
coined). By calling IARV64 and requesting 4G, we are guaranteed that
at least 2G can be addressed via L and ST and so on in AMODE64 as long
as the high half of the 64-bit register has been set. Testing the high
half of the register in AMODE31 should be as easy as testing bit 32
to determine if you need to switch to AMODE64 or not. As long as you
don't cross the 2G boundary, you can safely use L, ST, LA and whatever
other non-grand instructions you desire and still be using memory above
the bar. This falls down when you just want to look at some pointer
in a control block to determine if you need to go AMODE64, but you could
handle that by bumping your starting point from 0 in the low half of
the continent to x'8000'. You'd have almost what you're proposing
with the additional overhead of ensuring the high half of your register
contains your continent when you recognize the bit and switch to AMODE64.

> All A() constants need
> to be changed to AD().

Not unless you're also trying to support RMODE64

> Well, there is a way
> around that. You can instead do a SGR and
> then continue to use L. All save areas need
> to be changed to cope with the larger
> requirements.

> But even if it was easy, most applications
> don't need more than 4 GiB of memory, so
> it's best to keep them 32-bit as that is more
> compact.

> Would it help if I ask the author of REVIEW how
> much effort it would take him to produce a
> 64-bit version of his product so that datasets
> more than 4 GiB in size can be edited? That
> would certainly be nice.

> BFN. Paul.

-- 
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: RMM tape init question

2018-05-07 Thread Tom Conley


On 5/7/2018 10:43 AM, Tony Thigpen wrote:

Thanks.

I was looking at the SYSIN parms for EDGINERS and never noticed that 
there were additional options as a parm on the EXEC card. I will try 
this later today.


These tapes have had their external labels removed to facilitate putting 
new robot labels that are within our normal volid range. We have done 
this using CA1 in the past, but now we are running RMM. So, I don't know 
what the current internal label is.


Tony Thigpen

John McKown wrote on 05/07/2018 10:05 AM:

On Mon, May 7, 2018 at 8:48 AM, Tony Thigpen  wrote:


We have recently converted to RMM. I need to init a bunch of used tapes
that already have a volid. I have hit several problems and it just seems
that the only way to do what I need is to process the tapes twice.

Using EDGINERS, it appears that you can only change a volid if the
existing volid is already in the RMM catalog. These tapes are not in the
catalog.

So, it looks like I need to relabel the tapes using other tools, such as
IEHINITT, then run EDGINERS against the tape.

Did I miss something that would make this a much simpler process?

--
Tony Thigpen



Tony,

You have to ADDVOL the tapes first, they should show up in INIT status. 
Then run EDGINERS to INIT them.  There are various options to bypass all 
the WTOR's you'll get saying ARE YOU SURE YOU WANT TO RELABEL this tape. 
 Been a while for me, I don't remember the options, even though it was 
my requirement that added them.  You'll get there eventually.


Regards,
Tom Conley

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

Re: GETMAIN LOC=32

2018-05-07 Thread Chris Hoelscher

In other words - you make sure all your programs are ... in-continent ??

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Don Poitras
Sent: Monday, May 7, 2018 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GETMAIN LOC=32

In article <3154560307111841.wa.mutazilahgmail@listserv.ua.edu> you wrote:
> On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant  
> wrote:

> >>Updating 32-bit programs to conform to
> >>AM64 requirements is far less onerous than the massive changes 
> >>required to create a 64-bit application.
> >
> >No, it isn't. Why do you think it is?

> All references to "L" to load an address need to be changed to "LG".

Not necessarily. When we implemented large heap support for SAS/C, we used a 
scheme where we could avoid re-writing large parts of the assembler source by 
limitting ourselves to 2G "Continents" (a term I coined). By calling IARV64 and 
requesting 4G, we are guaranteed that at least 2G can be addressed via L and ST 
and so on in AMODE64 as long as the high half of the 64-bit register has been 
set. Testing the high half of the register in AMODE31 should be as easy as 
testing bit 32 to determine if you need to switch to AMODE64 or not. As long as 
you don't cross the 2G boundary, you can safely use L, ST, LA and whatever 
other non-grand instructions you desire and still be using memory above the 
bar. This falls down when you just want to look at some pointer in a control 
block to determine if you need to go AMODE64, but you could handle that by 
bumping your starting point from 0 in the low half of the continent to 
x'8000'. You'd have almost what you're proposing with the additional 
overhead of ensuring the high half of your register contains your continent 
when you recognize the bit and switch to AMODE64.

> All A() constants need
> to be changed to AD().

Not unless you're also trying to support RMODE64

> Well, there is a way
> around that. You can instead do a SGR and then continue to use L. All 
> save areas need to be changed to cope with the larger requirements.

> But even if it was easy, most applications don't need more than 4 GiB 
> of memory, so it's best to keep them 32-bit as that is more compact.

> Would it help if I ask the author of REVIEW how much effort it would 
> take him to produce a 64-bit version of his product so that datasets 
> more than 4 GiB in size can be edited? That would certainly be nice.

> BFN. Paul.

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

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

Re: IZUGUTSE ?

But did you use Google?

When I did I came up with a few more hits including

IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/

4.4 Authorizing a user to use z/OSMF . 4.4.1 Using RACF commands to authorize a
user ID to use z/OSMF . 4.5 Creating SAF security commands with IZUGUTSE utility
. Part 3 Usage . Chapter 5. Getting help in IBM z/OS Management Facility . 5.1
Overview of help options in z/OSMF . 5.2 Page-level help . 5.3 Message help ...


Lizette



> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Dyck, Lionel B. (TRA)
> Sent: Monday, May 07, 2018 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IZUGUTSE ?
> 
> I have been reading the new z/OSMF Redbook and found in section 4.5 info
> about IZUGUTSE (gutsy) that appears to generate XML for use with establishing
> z/OSMF security regardless of the ESM.
> 
> BUT I've not found any information about it in the z/OS 2.3 internet library,
> knowledge center, etc.
> 
> I was hoping it would simplify the establishment of granular security for the
> various elements of z/OSMF when using CA Top Secret.
> 
> Thanks for any suggestions.
> 
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer - RavenTek Solution Partners
> 
> 
> --
> 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: [EXTERNAL] Re: IZUGUTSE ?

Found those which reference the redbook where I learned about gutsy. :-)

Thanks - now to figure out how to use it as there is zero doc that I can find.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer - RavenTek Solution Partners

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, May 07, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IZUGUTSE ?

But did you use Google?

When I did I came up with a few more hits including

IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/

4.4 Authorizing a user to use z/OSMF . 4.4.1 Using RACF commands to authorize a
user ID to use z/OSMF . 4.5 Creating SAF security commands with IZUGUTSE utility
. Part 3 Usage . Chapter 5. Getting help in IBM z/OS Management Facility . 5.1
Overview of help options in z/OSMF . 5.2 Page-level help . 5.3 Message help ...


Lizette



> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Dyck, Lionel B. (TRA)
> Sent: Monday, May 07, 2018 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IZUGUTSE ?
> 
> I have been reading the new z/OSMF Redbook and found in section 4.5 info
> about IZUGUTSE (gutsy) that appears to generate XML for use with establishing
> z/OSMF security regardless of the ESM.
> 
> BUT I've not found any information about it in the z/OS 2.3 internet library,
> knowledge center, etc.
> 
> I was hoping it would simplify the establishment of granular security for the
> various elements of z/OSMF when using CA Top Secret.
> 
> Thanks for any suggestions.
> 
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer - RavenTek Solution Partners
> 
> 
> --
> 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: GETMAIN LOC=32

2018-05-07 Thread Walt Farrell

On Mon, 7 May 2018 09:00:37 -0500, Paul Edwards  wrote:

>I just want z/OS to match MVS/380,
>and there is nothing technically preventing
>that from happening.

Nothing, except all the z/OS changes that you haven't considered, and all the 
application changes they might imply for existing applications that really 
don't care about 32-bit capability.

One problem was mentioned earlier in this thread: ELSQA, EPVT, ECSA, ELPA, and 
ENUC will prevent you getting the 3GiB that you want, because they're sitting 
in the way today. So, in addition to the "simple" changes you want, z/OS would 
also have to change its storage layout. I can't predict what parts of the 
system that would affect and how complex it would be, or what applications it 
might affect.

I'm sure there are more.

-- 
Walt

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

Re: GETMAIN LOC=32

2018-05-07 Thread Seymour J Metz

Congratulations; you've invented OS/VS1. I'd also like to see that for 
DSORG=PO, with ACB-based equivalents to BLDL, FIND and STOW.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Monday, May 7, 2018 9:52 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

On Mon, May 7, 2018 at 8:29 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 7 May 2018 07:44:19 -0500, Paul Edwards wrote:
>
> >Oh - I'm also assuming that IBM will update
> >the operating system so that READ etc can
> >be executed in AM64.
>
> ROFL! You didn't ask for that. I think that you are assuming that is is
> trivial.
>

What I thought about, but haven't ever throw out here for discussion, is
the idea that IBM should create a new "subsystem" accessable via the
SUBSYS= on the DD which would allow accessing PS type data sets via an ACB.
What I envision would be that when the subsystem DS was OPEN'd, the
subsystem would load an I/O routine into RMODE(24) storage and dynamically
create a DCB & new DD statement with the same DSN. Then a GET or PUT via
the ACB would invoke the I/O module appropriately which would switch to
AMODE(24) and the the actual QSAM/BSAM I/O. This would allow at least the
majority of the uses people have for PS type datasets to use this interface
from AMODE(31) or AMODE(64) routine in a consistent GUPI manner which
everybody in the industry doing it the same way, rather than "ad hoc".

>
> Are you also assuming that they will accept an address above the bar for
> parameters?
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

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

Re: GETMAIN LOC=32

2018-05-07 Thread Wayne Driscoll

Yes, the high bit convention has to change for interfaces that accept 64 bit 
addresses. The issue is that in order to change the convention for 32 bit 
programs, either 1 -  an additional AMODE would need to be supported by the 
hardware, or 2 - EVERY existing program would have to be redesigned and 
retested in order to follow a new convention. The limited benefit of allowing 
for an extra 2GiB of virtual storage to an address space that can, using 64 bit 
addressing, already support 16 exabytes - 2GiB seems like a massive waste of 
resources.

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 Paul Edwards
Sent: Monday, May 7, 2018 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing  wrote:

>From the early days of S/360 the high-order bit of a full-word address
>pointer has a documented function in standard subroutine linkage of
>indicating the last parameter address for subroutines that accept a
>variable number of parameters, so even if the architecture might not
>restrict using that bit for memory addressing, long-standing software
>standards for AMODE24 and AMODE31 do.
>
>Changing the documented conventions for using the high-order bit of a
>32-bit address word

This convention *already* has to change for anyone considering moving to AM64 
and using 64-bit pointers. There's no reason why it should be mandatory for a 
full 64-bit application, but disallowed for a 32-bit program.

Updating 32-bit programs to conform to
AM64 requirements is far less onerous
than the massive changes required to
create a 64-bit application.

> to create a new "AMODE32" would potentially adversely effect too many
>things for minimal benefit.

Nobody is affected, and the benefit of going from a 2 GiB address space to a 4 
GiB address space is a great improvement.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:02:28 -0400, Don Poitras  wrote:

>> All references to "L" to load an address need
>> to be changed to "LG".
>
>Not necessarily. When we implemented large heap support for SAS/C, we
>used a scheme where we could avoid re-writing large parts of the
>assembler source by limitting ourselves to 2G "Continents" (a term I
>coined). By calling IARV64 and requesting 4G, we are guaranteed that
>at least 2G can be addressed via L and ST and so on in AMODE64 as long
>as the high half of the 64-bit register has been set.

That's a good idea, and we could get a compiler
to generate such code, but it prevents the
32-bit application from being moved to cheaper
32-bit hardware in the future, as a possibility.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll 
 wrote:

> Yes, the high bit convention has to change for
> interfaces that accept 64 bit addresses. The issue
> is that in order to change the convention for 32
> bit programs, either 1 -  an additional AMODE
> would need to be supported by the hardware,

I don't know why you think an additional AMODE
would help at all.

> or 2 - EVERY existing program would have to be
> redesigned and retested in order to follow a new
> convention.

Yes, I believe we should START this process by
allowing for 32-bit addressing. With a goal of
only having software that runs AM64 - regardless
of whether it is a 32-bit or 64-bit program.

> The limited benefit of allowing for an extra 2GiB
> of virtual storage to an address space that can,
> using 64 bit addressing, already support 16
> exabytes - 2GiB seems like a massive waste of
> resources.

If high-level language compilers start following
the 32-bit addressing rules, they will naturally
start supporting 4 GiB with no additional
effort by the programmer.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 15:54:01 +, Wayne Driscoll 
 wrote:

>>>Changing the documented conventions for using the high-order bit of a
>>>32-bit address word

>>This convention *already* has to change for anyone considering moving to AM64 
>>and using 64-bit pointers.

>Yes, the high bit convention has to change for
>interfaces that accept 64 bit addresses.

Actually, the convention doesn't need to change.
You just need to ensure that the memory where
the parameter list is stored needs to be in
LOC=31 memory rather than LOC=32 or
LOC=64.

In addition, the called routine needs to strip
the high bit with an N to x'7FFF' instead
of either ignoring it or using an LA to remove it.

Ideally we should start coding in that manner
even if IBM never supports LOC=32 memory
and eventually all our software will be AM64
clean.

BFN. Paul.

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

Re: Netview Login issue

Hello Elardus,

Yes, we both together putting effort to solve this issue.. Thank you so
much once again.



On Mon, May 7, 2018 at 10:30 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> venkat kulkarni wrote:
>
> >We using Netview 6.2. Now problem has been resolved by one of the major
> node . Now i am able to login to netview for use.
>
> Are you saurabh khandelwal collaborating to resolve this Netview logon
> problem?
>
> It would be great to see if the OP has his/her problem resolved or not.
>
> 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: Job submit using REXX

2018-05-07 Thread Phil Carlyle

Check with your Netview automation team, this process is easily handled there 
if this is a critical process it would be the best place to put anyway.
Using the right message traps and establishing the proper variables, it would 
not matter how many data sets are in the process and the return codes could be 
checked as well to ensure the processing is done at the appropriate time.  Most 
likely a good PIPES guy could do this very quickly.

PHIL CARLYLE
Information Security | IAM RACF directory services
M: 480-235-2837 | phil.carl...@aexp.com
TEKSystems

“The Universe is made up of Protons, Neutrons, Electrons & Morons!”

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, May 7, 2018 5:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Job submit using REXX

If this is only for one dataset and the message is in SYSLOG, then the MPF list 
would work.

If there are multiple datasets that need to be available before proceeding, 
then it is getting to be a bit trickier.

Several Scheduling software have Dataset Triggers.  And they sometimes will 
monitor for the creation of an SMF Record (Type 30 I think). Then take action 
as described to their process.

Humans can see that datasets are there and then submit jobs.  But that requires 
a human to be vigilant and submit the job when all requirements are met.

Also, the human has to review the message and ensure the return code is 0 
before proceeding.

So to provide the function for the OP without purchasing a product, will be a 
challenge I think.

   1)  Monitor for dataset creation via SVT messages.
   a) If more than one file has to be sent, then monitor for additional 
creations before proceeding
   2)  Ensure message shows 0 return code.  Anything else needs to be reviewed
   3)  Ensure all files are available before the next job is submitted

Unless the OP has other requirements, I think the three listed are what are 
needed.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of
> Lizette Koehler
> Sent: Monday, May 07, 2018 5:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job submit using REXX
>
> If it is only in the STC Job log, or other DD statement, then no.
>
> The request would then require something like ISFEXEC (SDSF REXX) and it
> would not be real time.  It would then have to be run at a frequency that
> makes sense.
>
> Anything not presented to the SYSLOG/OPERLOG would not be seen by the MPF
> exit.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > mailto:IBM-MAIN@LISTSERV.UA.EDU>> On
> > Behalf Of Elardus Engelbrecht
> > Sent: Monday, May 07, 2018 12:43 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Job submit using REXX
> >
> > Lizette Koehler wrote:
> >
> > >This process can be done by using a trap for a message on your system.
> > >MPF Exit might work
> > >CBTTAPE.ORG
> > > might have a process you can tailor Any Scheduling
> > >software will have a file trigger function This is more complicated
> > >without scheduling software.  You will need to find a process that
> > >monitors for messages and then provides an action for that message
> >
> > Those SVTM messages are shown inside the STC (Connect Direct), not in
> SYSLOG.
> >
> > Will your suggestions work in that scenario?
> >
> >
> > venkat kulkarni wrote:
> >
> > >> We have requirement of setting up process of handling  FTP and then
> > >> submit Job with FTP dataset. The process goes like this,
> >
> > Use automation for submission, checking/monitoring these actions and
> > then submit another job using REXX to process your datasets.
> >
> >
> > >> SVTM052I STEP01   COPY FDDB4142(  95,456)
> > >> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> > >> SVTM052I  TO   
> > >> FTP.DATA.ATRAIL.G0458V00
> > >> SVTM052I  COMPLETED  /SCPA000I
> >
> > >> So, basically we want to capture these dataset names from this
> > >> message
> > SVTM052I and send message to operator that file has been received and
> > then submit one batch Job by putting this file name.
> >
> > Rather, have that transfer job send out a message or execute a REXX
> > program using those file names.
> >
> >
> > >> Is there any way to automate this whole process. I am new to REXX,
> > >> so if
> > someone can guide me on this solution.We receive  these files 3-4
> > times in a day or even more.
> >
> > Yes, with automation software or with one of those CBTTAPE utilities.
> >
> > Or you can checkup Brian Westerman's reply to you and his products.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive

Re: IZUGUTSE ?

Lizette Koehler wrote:

>IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
>https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/

Thanks, but Safari and that Red-hot spanner on the front page of that RedBook 
is blocking/burning me to read it... ;-)

Try this link to see the same bookie. (21 MB, 584 pages)

http://www.redbooks.ibm.com/abstracts/sg247851.html?Open

ISBN-13: 9780738443096
IBM Form #: SG24-7851-02

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: GETMAIN LOC=32


Paul,

You keep saying 32-bit applications. There is *NO SUCH THING*. There are 
only 24-bit, 31-bit and 64-bit applications.


Tony Thigpen

Paul Edwards wrote on 05/07/2018 11:56 AM:

On Mon, 7 May 2018 11:02:28 -0400, Don Poitras  wrote:


All references to "L" to load an address need
to be changed to "LG".


Not necessarily. When we implemented large heap support for SAS/C, we
used a scheme where we could avoid re-writing large parts of the
assembler source by limitting ourselves to 2G "Continents" (a term I
coined). By calling IARV64 and requesting 4G, we are guaranteed that
at least 2G can be addressed via L and ST and so on in AMODE64 as long
as the high half of the 64-bit register has been set.


That's a good idea, and we could get a compiler
to generate such code, but it prevents the
32-bit application from being moved to cheaper
32-bit hardware in the future, as a possibility.

BFN. Paul.

--
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: GETMAIN LOC=32

On Mon, 7 May 2018 12:38:58 -0400, Tony Thigpen  wrote:

>You keep saying 32-bit applications. There is *NO SUCH THING*. There are
>only 24-bit, 31-bit and 64-bit applications.

How do you distinguish between applications
that only use the S/370 32-bit registers and
applications that use the z/Arch 64-bit
registers, when both of them are running in
AM64 or maybe in the future AM128 or
AM256?

Note that the 32-bit applications that I am
producing, that run as AM64, also run on
MVS 3.8j. They are trimodal. 64-bit
applications have no chance of running on
MVS 3.8j on S/370 hardware.

BFN. Paul.

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

Re: Job submit using REXX

On Sun, 6 May 2018 14:45:24 +0300, venkat kulkarni  wrote:
>
>We have requirement of setting up process of handling  FTP and then submit
>Job with FTP dataset. ...
> 
FTP has the ability to submit jobs directly with the command:
QUOTE SITE FILETYPE=JES

Would this meet your reaquirement?

-- gil

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

Re: GETMAIN LOC=32

2018-05-07 Thread Steve Partlow

To the original requirement of "support a LOC=32 parameter to GETMAIN, giving 
32-bit programs access to a full 4 GiB instead of the current 2 GiB provided by 
LOC=31."

Why not write your own routine to issue an IARV64 GETSTOR with USE2GTO32G=YES 
and then GETMAIN if that fails to find storage? The free could easily check the 
address being freed to decide which service to use on release.

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

Re: Job submit using REXX

Hello Group,

Thanks for all response. We have Netview, which can be used for automation.
My idea is to create REXX, which extracted data from DCON address space
into one dataset.

Then i need help to write REXX to extract   FTP.DATA.** dataset from this
ps dataset and put these dataset name into other ps dataset.

SVTM052I STEP01   COPY FDDB4142(  95,456)

SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00

SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00

SVTM052I  COMPLETED  /SCPA000I





SVTM052I STEP01   COPY FDDB4099(  95,458)

SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00

SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00

SVTM052I  COMPLETED  /SCPA000I



SVTM052I STEP01   COPY FDDB4052(  95,516)

SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00

SVTM052I  TO   FTP.DATA.IAS.G3486V00

SVTM052I  COMPLETED  /SCPA000I

Once we have this output dataset having   FTP.DATA.** full name and i want
to write another REXX  to put this dataset name into JCL and submit batch
job.

Can anybody help me with sample REXX for extracting   FTP.DATA.** dataset
from my input dataset and put this dataset name into output file.

On Mon, May 7, 2018 at 3:41 PM, Lizette Koehler 
wrote:

> If this is only for one dataset and the message is in SYSLOG, then the MPF
> list would work.
>
> If there are multiple datasets that need to be available before
> proceeding, then it is getting to be a bit trickier.
>
> Several Scheduling software have Dataset Triggers.  And they sometimes
> will monitor for the creation of an SMF Record (Type 30 I think). Then take
> action as described to their process.
>
> Humans can see that datasets are there and then submit jobs.  But that
> requires a human to be vigilant and submit the job when all requirements
> are met.
>
> Also, the human has to review the message and ensure the return code is 0
> before proceeding.
>
>
> So to provide the function for the OP without purchasing a product, will
> be a challenge I think.
>
>1)  Monitor for dataset creation via SVT messages.
>a) If more than one file has to be sent, then monitor for
> additional creations before proceeding
>2)  Ensure message shows 0 return code.  Anything else needs to be
> reviewed
>3)  Ensure all files are available before the next job is submitted
>
> Unless the OP has other requirements, I think the three listed are what
> are needed.
>
> Lizette
>
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Lizette Koehler
> > Sent: Monday, May 07, 2018 5:25 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Job submit using REXX
> >
> > If it is only in the STC Job log, or other DD statement, then no.
> >
> > The request would then require something like ISFEXEC (SDSF REXX) and it
> > would not be real time.  It would then have to be run at a frequency that
> > makes sense.
> >
> > Anything not presented to the SYSLOG/OPERLOG would not be seen by the MPF
> > exit.
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Elardus Engelbrecht
> > > Sent: Monday, May 07, 2018 12:43 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Job submit using REXX
> > >
> > > Lizette Koehler wrote:
> > >
> > > >This process can be done by using a trap for a message on your system.
> > > >MPF Exit might work
> > > >CBTTAPE.ORG might have a process you can tailor Any Scheduling
> > > >software will have a file trigger function This is more complicated
> > > >without scheduling software.  You will need to find a process that
> > > >monitors for messages and then provides an action for that message
> > >
> > > Those SVTM messages are shown inside the STC (Connect Direct), not in
> > SYSLOG.
> > >
> > > Will your suggestions work in that scenario?
> > >
> > >
> > > venkat kulkarni wrote:
> > >
> > > >> We have requirement of setting up process of handling  FTP and then
> > > >> submit Job with FTP dataset. The process goes like this,
> > >
> > > Use automation for submission, checking/monitoring these actions and
> > > then submit another job using REXX to process your datasets.
> > >
> > >
> > > >> SVTM052I STEP01   COPY FDDB4142(  95,456)
> > > >> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> > > >> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
> > > >> SVTM052I  COMPLETED  /SCPA000I
> > >
> > > >> So, basically we want to capture these dataset names from this
> > > >> message
> > > SVTM052I and send message to operator that file has been received and
> > > then submit one batch Job by putting this file name.
> > >
> > > Rather, have that transfer job send out a message or execute a REXX
> > > program using those file names.
> > >
> > >
> > > >> Is there any way to automate this whole process. I am new to REXX,
> > > >> so if
> > > someone can guide me on this solution.We receive  these files 3-4
> > > times in a day or even more

Re: GETMAIN LOC=32

The IARV64 instruction probably will find
memory. But it will be a 64-bit address
requiring me to manipulate and save
64-bit registers. I wish to write 32-bit
programs, and I also want those 32-bit
programs to run on OS/390 as AM31
and on MVS 3.8j as AM24. Only on z/OS
and MVS/380 would my 32-bit applications
run as AM64 and obtain and use LOC=32
memory.

BFN. Paul.

On Mon, 7 May 2018 11:51:55 -0500, Steve Partlow  wrote:

>To the original requirement of "support a LOC=32 parameter to GETMAIN, giving 
>32-bit programs access to a full 4 GiB instead of the current 2 GiB provided 
>by LOC=31."
>
>Why not write your own routine to issue an IARV64 GETSTOR with USE2GTO32G=YES 
>and then GETMAIN if that fails to find storage? The free could easily check 
>the address being freed to decide which service to use on release.
>
>--
>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: GETMAIN LOC=32

2018-05-07 Thread Edward Gould

> On May 7, 2018, at 8:42 AM, Joel C. Ewing  wrote:
>> ——SNIP---
> One of the big advantages of IBM mainframes (since S/360) has been
> upward compatibility for application code.  Unlike other platforms, you
> don't have to redesign application assembly code or re-compile all
> application programs just because of an operating system upgrade or an
> architecture upgrade.   Documented application code interfaces continue
> to be compatible.
Well…. you should change the wording a bit. Except for COBOL and COBO-le 
issue(s)… and… Sorry.. I think COBOL should be listed as a unique entity and 
deserves to have its own hall of shame.
> 

SNMIP——



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

Re: Job submit using REXX

REXX i used to copy DCON address space message into ps file is

ADDRESS TSO
DO I=0 TO 4
"ALLOC F(ISFIN) TRACKS SPACE(1) REU"
"ALLOC F(ISFOUT) NEW DELETE REU ",
"TRACKS SPACE(100,100) LRECL(133) RECFM(F,B) DSORG(PS)"
"ALLOC F(TEMPPRT) DA('v12396.NEW.PS1') MOD REUSE"
QUEUE "PRE DCON"
QUEUE "ST"
QUEUE "DOWN" I
QUEUE "FIND 'JESJCL'"
QUEUE "++S"
QUEUE "PRINT FILE TEMPPRT"
QUEUE "PRINT"
QUEUE "PRINT CLOSE"
QUEUE "END"
QUEUE "EXIT"
"EXECIO" QUEUED()" DISKW ISFIN (FINIS"
ADDRESS ISPEXEC "SELECT PGM(ISFAFD) PARM('++32,255)"
END
EXIT


Now, I have all required log in  v12396.NEW.PS1 file  and i want to
extract  FTP.DATA.** dataset name from this file and copy it to another
file for further process.

v12396.NEW.PS1  contain many other message including below.


SVTM052I STEP01   COPY FDDB4142(  95,456)

SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00

SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00

SVTM052I  COMPLETED  /SCPA000I





SVTM052I STEP01   COPY FDDB4099(  95,458)

SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00

SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00

SVTM052I  COMPLETED  /SCPA000I



SVTM052I STEP01   COPY FDDB4052(  95,516)

SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00

SVTM052I  TO   FTP.DATA.IAS.G3486V00

SVTM052I  COMPLETED  /SCPA000I


On Mon, May 7, 2018 at 7:56 PM, venkat kulkarni 
wrote:

> Hello Group,
>
> Thanks for all response. We have Netview, which can be used for
> automation. My idea is to create REXX, which extracted data from DCON
> address space into one dataset.
>
> Then i need help to write REXX to extract   FTP.DATA.** dataset from this
> ps dataset and put these dataset name into other ps dataset.
>
> SVTM052I STEP01   COPY FDDB4142(  95,456)
>
> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
>
> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
>
>
>
>
> SVTM052I STEP01   COPY FDDB4099(  95,458)
>
> SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
>
> SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
>
>
> SVTM052I STEP01   COPY FDDB4052(  95,516)
>
> SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00
>
> SVTM052I  TO   FTP.DATA.IAS.G3486V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
> Once we have this output dataset having   FTP.DATA.** full name and i
> want to write another REXX  to put this dataset name into JCL and submit
> batch job.
>
> Can anybody help me with sample REXX for extracting   FTP.DATA.** dataset
> from my input dataset and put this dataset name into output file.
>
> On Mon, May 7, 2018 at 3:41 PM, Lizette Koehler 
> wrote:
>
>> If this is only for one dataset and the message is in SYSLOG, then the
>> MPF list would work.
>>
>> If there are multiple datasets that need to be available before
>> proceeding, then it is getting to be a bit trickier.
>>
>> Several Scheduling software have Dataset Triggers.  And they sometimes
>> will monitor for the creation of an SMF Record (Type 30 I think). Then take
>> action as described to their process.
>>
>> Humans can see that datasets are there and then submit jobs.  But that
>> requires a human to be vigilant and submit the job when all requirements
>> are met.
>>
>> Also, the human has to review the message and ensure the return code is 0
>> before proceeding.
>>
>>
>> So to provide the function for the OP without purchasing a product, will
>> be a challenge I think.
>>
>>1)  Monitor for dataset creation via SVT messages.
>>a) If more than one file has to be sent, then monitor for
>> additional creations before proceeding
>>2)  Ensure message shows 0 return code.  Anything else needs to be
>> reviewed
>>3)  Ensure all files are available before the next job is submitted
>>
>> Unless the OP has other requirements, I think the three listed are what
>> are needed.
>>
>> Lizette
>>
>>
>>
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> Behalf Of
>> > Lizette Koehler
>> > Sent: Monday, May 07, 2018 5:25 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Job submit using REXX
>> >
>> > If it is only in the STC Job log, or other DD statement, then no.
>> >
>> > The request would then require something like ISFEXEC (SDSF REXX) and it
>> > would not be real time.  It would then have to be run at a frequency
>> that
>> > makes sense.
>> >
>> > Anything not presented to the SYSLOG/OPERLOG would not be seen by the
>> MPF
>> > exit.
>> >
>> > Lizette
>> >
>> >
>> > > -Original Message-
>> > > From: IBM Mainframe Discussion List  On
>> > > Behalf Of Elardus Engelbrecht
>> > > Sent: Monday, May 07, 2018 12:43 AM
>> > > To: IBM-MAIN@LISTSERV.UA.EDU
>> > > Subject: Re: Job submit using REXX
>> > >
>> > > Lizette Koehler wrote:
>> > >
>> > > >This process can be done by using a trap for a message on your
>> system.
>> > > >MPF Exit might work
>> > > >CBTTAPE.OR

Re: IZUGUTSE ?

2018-05-07 Thread ITschak Mugzach

Lionel,

have you looked in sys1.samplib(*izu*)

ITschak

On Mon, May 7, 2018 at 7:36 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Lizette Koehler wrote:
>
> >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
> >https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/
>
> Thanks, but Safari and that Red-hot spanner on the front page of that
> RedBook is blocking/burning me to read it... ;-)
>
> Try this link to see the same bookie. (21 MB, 584 pages)
>
> http://www.redbooks.ibm.com/abstracts/sg247851.html?Open
>
> ISBN-13: 9780738443096
> IBM Form #: SG24-7851-02
>
> 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
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: GETMAIN LOC=32

2018-05-07 Thread Greg Price


[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points - 
some of which have been mentioned or alluded to by others - for your 
consideration:


- IMO, IBM will not perceive any ROI from your request sufficient to 
make them consider it.  I'm not an insider, but I expect them to have 
ideas which they think are far more lucrative than yours to pursue. 
Such ideas probably include some which, although they may not have the 
elegance of yours from an application programmer p-o-v, are being 
requested by companies which pay IBM many more dollars than the likes of 
you or me.


My conclusion: IBM will see the potential for incurring cost (at first 
from the initial development effort, and then on-going from the 
potential increase in PMRs where such a facility is used) without any 
obvious resultant potential increase in revenue.


- Virtual storage below the 2GB bar is generally managed down to a 
doubleword granularity.  Whether the macros used to make requests to get 
some of it or free some of it are called GETMAIN and FREEMAIN, or 
STORAGE, it is the same set on control blocks that are updated to keep 
account of it.  When managing storage at the doubleword level, it 
becomes possible for a significant fraction of total storage consumed to 
be used to track all the storage consumed.


- When scaling up storage to create the 64-bit address space size, 
managing storage at the doubleword atom size is just not a wise choice 
in terms of overhead.  For this reason, virtual storage above the 2GB 
bar is managed in chunks of 1MB.


My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN 
storage granularity natively in the 2GB-4GB address range.  You would 
have to add some intermediate storage administration layer - which may 
not even be that difficult to do, as long as your 32-bit program 
"compiler" generated code to call it for storage management calls.


- MVS private storage admin has "always" relied on user apps building 
storage usage from the bottom of the private area up (the "region"), 
while the system's use of private storage starts at the top and grows 
downward.  When the two meet, private storage is exhausted and the job 
crashes.  This process is occurring both below and above the 16MB line.


- For the ATL or extended private area, the "top" is the underside of 
the 2GB line where important control blocks reside, possibly including 
page and segment tables.  (This was true for XA, dunno if it is still 
true for z/OS, although what else is using all those megabytes reported 
by IEF032I (which used to be IEF374I) ?? )


My conclusion: Without a radical reengineering of the bottom-up-for-apps 
and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable, 
and so the prospective 32-bit application will never be able to acquire 
a single 3GB chunk of storage entirely below virtual address 4GB.


There were enough hassles flowing from latent bugs exposed by the VSM 
(GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?) 
without adding some sort of AM32 to the mix.  That is why I think the 
PMR count could rise quite a bit giving a potential risk which is easy 
to avoid - simply by not making such a change.  Lots of subtle 
assumptions about the nature of the behaviour of the OS lie lurking in 
application code that is numerous years old, I think.  Sure, the bugs 
shouldn't be there, but why risk exposing them?



Overall, while I too like elegant programming models, at the end of the 
day, IBM and other vendors have to support their customers, and on this 
platform an important part of that is compatibility.  I certainly 
sympathise with the idea that there's an extra 2GB of storage for 
"existing" programs there for the taking, but in practice, I don't think 
it really is there in a z/OS environment.


And this opinion is from a bloke who still thinks that if the System/360 
CCW designer had not thought that a spare halfword would actually prove 
more useful than two separate spare bytes, then the high byte of the 
address word would have been available for XA to provide immediate AM31 
support for I/O macros in DFP V2.


But compatibility is important for vendors.  I happen to know of an IBM 
product (not in the z/OS package but acquired from an ISV and runs on 
z/OS) which uses a routine with logic unchanged since 1967.



I think z/OS has diverged too far from its MVS/370 predecessor where you 
could, perhaps, successfully implement your idea.


And just to opine about another point, I will predict that we will not 
see AM64 support for QSAM/BSAM/BPAM I/O macros inside 10 years from now. 
 (Gee, now I hope a DFSMS team are not currently working in this for 
the next release...  :/  )



Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv

Re: [EXTERNAL] Re: IZUGUTSE ?

Nothing in samplib :(

This must be a very secure tool - security by obscurity.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Monday, May 07, 2018 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IZUGUTSE ?

Lionel,

have you looked in sys1.samplib(*izu*)

ITschak

On Mon, May 7, 2018 at 7:36 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Lizette Koehler wrote:
>
> >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
> >https://www.safaribooksonline.com/library/view/ibm-zos.../9780738443096/
>
> Thanks, but Safari and that Red-hot spanner on the front page of that
> RedBook is blocking/burning me to read it... ;-)
>
> Try this link to see the same bookie. (21 MB, 584 pages)
>
> http://www.redbooks.ibm.com/abstracts/sg247851.html?Open
>
> ISBN-13: 9780738443096
> IBM Form #: SG24-7851-02
>
> 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
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

--
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: GETMAIN LOC=32

2018-05-07 Thread Charles Mills

Another reason: Peter says it ain't gonna happen 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Price
Sent: Monday, May 7, 2018 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points - 
some of which have been mentioned or alluded to by others - for your 
consideration:

- IMO, IBM will not perceive any ROI from your request sufficient to 

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

Re: GETMAIN LOC=32

On Tue, 8 May 2018 03:32:03 +1000, Greg Price  
wrote:

>I think z/OS has diverged too far from its MVS/370 predecessor where you
>could, perhaps, successfully implement your idea.

Ok, well hopefully we are only about 100 lines of
code away from MVS/380 supporting allocating
3 GiB of memory in a single block below 4 GiB.

The code that needs to be modified is here:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/mvs380mn.jcl

starting at line 1418. It needs logic to search
down for a LOC=32 memory request.

>And just to opine about another point, I will predict that we will not
>see AM64 support for QSAM/BSAM/BPAM I/O macros inside 10 years from now.

Why do you think that? Surely the I/O routines
only require 10 lines of code at the beginning
of each to switch from AM64 to AM31, and
then the reverse on return? That's basically
what we did on MVS/380 to support AM31
REVIEW. Actually it supports AM64 too. I'm
just waiting on a new 32-bit module from you
that is AM64-compliant. You can see that code here:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019ba.jcl
(line 139)

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019bc.jcl
(line 117)

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019dk.jcl
(line 36)

While you're here, how much effort would it
take to make REVIEW support 64-bit addresses
so that datasets bigger than 4 GiB can be
edited?

Thanks. Paul.

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

Re: Where do I find a list of world timezones in z/OS USS notation?

On Thu, 26 Apr 2018 16:21:57 -0500, Juan Escamilla wrote:

>I had to change the Unix time zone values for several LPARS that run on 
>different timezones around the world.  I used the values from website 
>https://www.di-mgt.com.au/src/wclocktz.ini
> 
Thanks.  I bookmarked it.

Somewhat incomplete -- doesn't show Pyongyang, which has changed timezone
twice in the last three years:
http://mm.icann.org/pipermail/tz-announce/2018-May/50.html
https://en.wikipedia.org/wiki/Time_in_North_Korea
5 days advance notice!?

And a comment shows Beijing where ICANN shows Shanghai.

z/OS ought to adopt Olson time, like most other systems.

-- gil

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 12:01:42 -0500, Paul Edwards wrote:

>The IARV64 instruction probably will find
>memory. But it will be a 64-bit address
>requiring me to manipulate and save
>64-bit registers.

You chose to ignore Jim Mulder's reply.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:44:38 -0500, Paul Edwards wrote:

>How do you distinguish between applications
>that only use the S/370 32-bit registers and
>applications that use the z/Arch 64-bit
>registers, 

Are you suggesting that a 24-bit application, one that runs AMODE(24), 
only uses 24-bit registers? You are not making any sense.

>64-bit
>applications have no chance of running on
>MVS 3.8j on S/370 hardware.

Nor do 31-bit applications.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:18:38 -0500, Paul Edwards wrote:

>strip
>the high bit with an N to x'7FFF'

LLGT/LLGTR

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder  wrote:

>  GETMAIN is not going to ever manage 32-bit storage.
>I would word you requirement this way:
>
> " I would like to have a USE2GTO4G=NO|YES 
>parameter on IARV64 GETSTOR, similar to the already exisiting
>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES.
>And I would like to have a way to tell the system to reserve the
>2GTO4G area to be used only for USE2GTO4G=YES requests."

Why can't GETMAIN LOC=32 call IARV64 as above
under the covers so that the only change I need to
make to my application code is replace LOC=ANY
with LOC=32?

Note that IARV64 has a granularity of 1 MiB when
I would prefer GETMAIN granularity for 32-bit
memory.

Also note that the CVT offset that IARV64 uses to
do a PC call is not documented, so this is a
proprietary interface.

In addition I would like to produce a load module
that is trimodal which still runs on MVS 3.8j and
MVS/XA and OS/390. The SVC 120 exists on all
these systems (and LOC=32 will be hamless on
all of them), but not the IARV64 PC call. These
systems don't have the required hardware to do
PC calls either.

BFN. Paul.

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

Re: Job submit using REXX

2018-05-07 Thread Cieri, Anthony


Connect:Direct also has the ability to submit jobs via the RUNJOB verb.

Since the files appear to be received by Connect:Direct, wouldn't it be 
possible to change the receiving process to submit the job too.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 07, 2018 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Job submit using REXX

On Sun, 6 May 2018 14:45:24 +0300, venkat kulkarni  wrote:
>
>We have requirement of setting up process of handling  FTP and then 
>submit Job with FTP dataset. ...
> 
FTP has the ability to submit jobs directly with the command:
QUOTE SITE FILETYPE=JES

Would this meet your reaquirement?

-- 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: GETMAIN LOC=32

On Mon, 7 May 2018 13:18:51 -0500, Tom Marchant  
wrote:

>>The IARV64 instruction probably will find
>>memory. But it will be a 64-bit address
>>requiring me to manipulate and save
>>64-bit registers.

> You chose to ignore Jim Mulder's reply.

Replied now.

>>How do you distinguish between applications
>>that only use the S/370 32-bit registers and
>>applications that use the z/Arch 64-bit
>>registers, 
>
>Are you suggesting that a 24-bit application, one that runs AMODE(24), 
>only uses 24-bit registers? You are not making any sense.

No, what you are calling a 24-bit application is
actually a 32-bit application that runs on a
reduced addressing mode of 24.

>>64-bit
>>applications have no chance of running on
>>MVS 3.8j on S/370 hardware.
>
>Nor do 31-bit applications.

Yes they do if they are bimodal (ANY/ANY).
All I am doing is upping the stakes to trimodal.

>>strip
>>the high bit with an N to x'7FFF'

> LLGT/LLGTR

I want my programs to run on S/370 hardware
too, so the "N" is required.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards  wrote:

>> " I would like to have a USE2GTO4G=NO|YES 
>>parameter on IARV64 GETSTOR, similar to the already exisiting
>>USE2GTO32G=NO|YES and USE2GTO64G=NO|YES.
>>And I would like to have a way to tell the system to reserve the
>>2GTO4G area to be used only for USE2GTO4G=YES requests."

>Note that IARV64 has a granularity of 1 MiB when
>I would prefer GETMAIN granularity for 32-bit
>memory.

Also, this doesn't allow a single allocation of
3 GiB from a 32-bit program, which is something
I would like to do. Or at least pencil in as
something to do in the future. First step is to move
ECSA down to the 16 MiB line etc in preparation
for clearing the ATL memory all the way to 4 GiB
for 32-bit applications.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards wrote:

>Yes, I believe we should START this process by
>allowing for 32-bit addressing. With a goal of
>only having software that runs AM64 - regardless
>of whether it is a 32-bit or 64-bit program.

I'm certainly not going to put any effort into constraining 
AMODE(64) programs to use only 4 GB.

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

I just realized what is happening. Paul is involved with the rouge 
development of MVS/380 (and VSE/380) to run on Herc as 32bit, not 31bit.


Now that they have a non-conforming operating system, they want the real 
operating system people to support some of the stuff they did in the 
rouge operating system.


Paul, If you are going to create your own operating system, then you 
have to acknowledge that there will be differences and you can't expect 
the real operating system people to change a major item just to remove 
those differences.


This is a list about z/OS, OS/390 and MVS, not some rouge, non-IBM 
operating system. Now that I understand where you are coming from, I 
personally would like to see you banned for wasting our time.


Tony Thigpen

Paul Edwards wrote on 05/07/2018 01:57 PM:

On Tue, 8 May 2018 03:32:03 +1000, Greg Price  
wrote:


I think z/OS has diverged too far from its MVS/370 predecessor where you
could, perhaps, successfully implement your idea.


Ok, well hopefully we are only about 100 lines of
code away from MVS/380 supporting allocating
3 GiB of memory in a single block below 4 GiB.

The code that needs to be modified is here:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/mvs380mn.jcl

starting at line 1418. It needs logic to search
down for a LOC=32 memory request.


And just to opine about another point, I will predict that we will not
see AM64 support for QSAM/BSAM/BPAM I/O macros inside 10 years from now.


Why do you think that? Surely the I/O routines
only require 10 lines of code at the beginning
of each to switch from AM64 to AM31, and
then the reverse on return? That's basically
what we did on MVS/380 to support AM31
REVIEW. Actually it supports AM64 too. I'm
just waiting on a new 32-bit module from you
that is AM64-compliant. You can see that code here:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019ba.jcl
(line 139)

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019bc.jcl
(line 117)

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/main/igg019dk.jcl
(line 36)

While you're here, how much effort would it
take to make REVIEW support 64-bit addresses
so that datasets bigger than 4 GiB can be
edited?

Thanks. Paul.

--
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: GETMAIN LOC=32

On Mon, 7 May 2018 13:33:03 -0500, Tom Marchant  
wrote:

>>Yes, I believe we should START this process by
>>allowing for 32-bit addressing. With a goal of
>>only having software that runs AM64 - regardless
>>of whether it is a 32-bit or 64-bit program.
>
>I'm certainly not going to put any effort into constraining 
>AMODE(64) programs to use only 4 GB.

Nor am I wanting to constrain 64-bit applications
to 4 GiB. But you are happy to constrain
32-bit applications to 2 GiB when all you may
need is a LOC=32 parameter and you can go
all the way up to 4 GiB.

BFN. Paul.

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 11:06:22 -0500, Paul Edwards If high-level language compilers start following
>the 32-bit addressing rules, they will naturally
>start supporting 4 GiB with no additional
>effort by the programmer.

If high level language compilers (and run-time environments) start 
following 64-bit addressing rules, they will naturally start supporting 
16 EB, with no additional effort by the programmer.

What's your point?

-- 
Tom Marchant

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 10:56:48 -0500, Paul Edwards wrote:

>That's a good idea, and we could get a compiler
>to generate such code, but it prevents the
>32-bit application from being moved to cheaper
>32-bit hardware in the future, as a possibility.

OMFG! Is that what this is all about? Moving to 32-bit hardware?

-- 
Tom Marchant

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

Re: Job submit using REXX

2018-05-07 Thread Phil Carlyle

You forgot the QUEUE ‘’ to flush out the queue.

PHIL CARLYLE
Information Security | IAM RACF directory services
M: 480-235-2837 | phil.carl...@aexp.com
TEKSystems

“The Universe is made up of Protons, Neutrons, Electrons & Morons!”

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of venkat kulkarni
Sent: Monday, May 7, 2018 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Job submit using REXX

REXX i used to copy DCON address space message into ps file is

ADDRESS TSO
DO I=0 TO 4
"ALLOC F(ISFIN) TRACKS SPACE(1) REU"
"ALLOC F(ISFOUT) NEW DELETE REU ",
"TRACKS SPACE(100,100) LRECL(133) RECFM(F,B) DSORG(PS)"
"ALLOC F(TEMPPRT) DA('v12396.NEW.PS1') MOD REUSE"
QUEUE "PRE DCON"
QUEUE "ST"
QUEUE "DOWN" I
QUEUE "FIND 'JESJCL'"
QUEUE "++S"
QUEUE "PRINT FILE TEMPPRT"
QUEUE "PRINT"
QUEUE "PRINT CLOSE"
QUEUE "END"
QUEUE "EXIT"
"EXECIO" QUEUED()" DISKW ISFIN (FINIS"
ADDRESS ISPEXEC "SELECT PGM(ISFAFD) PARM('++32,255)"
END
EXIT


Now, I have all required log in  v12396.NEW.PS1 file  and i want to
extract  FTP.DATA.** dataset name from this file and copy it 
to another
file for further process.

v12396.NEW.PS1  contain many other message including below.


SVTM052I STEP01   COPY FDDB4142(  95,456)

SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00

SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00

SVTM052I  COMPLETED  /SCPA000I





SVTM052I STEP01   COPY FDDB4099(  95,458)

SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00

SVTM052I  TO   
FTP.DATA.AUDIT.TRAIL.G1568V00

SVTM052I  COMPLETED  /SCPA000I



SVTM052I STEP01   COPY FDDB4052(  95,516)

SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00

SVTM052I  TO   FTP.DATA.IAS.G3486V00

SVTM052I  COMPLETED  /SCPA000I


On Mon, May 7, 2018 at 7:56 PM, venkat kulkarni 
mailto:venkatkulkarn...@gmail.com>>
wrote:

> Hello Group,
>
> Thanks for all response. We have Netview, which can be used for
> automation. My idea is to create REXX, which extracted data from DCON
> address space into one dataset.
>
> Then i need help to write REXX to extract   FTP.DATA.** 
> dataset from this
> ps dataset and put these dataset name into other ps dataset.
>
> SVTM052I STEP01   COPY FDDB4142(  95,456)
>
> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
>
> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
>
>
>
>
> SVTM052I STEP01   COPY FDDB4099(  95,458)
>
> SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
>
> SVTM052I  TO   
> FTP.DATA.AUDIT.TRAIL.G1568V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
>
>
> SVTM052I STEP01   COPY FDDB4052(  95,516)
>
> SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00
>
> SVTM052I  TO   FTP.DATA.IAS.G3486V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
> Once we have this output dataset having   FTP.DATA.** full 
> name and i
> want to write another REXX  to put this dataset name into JCL and submit
> batch job.
>
> Can anybody help me with sample REXX for extracting   
> FTP.DATA.** dataset
> from my input dataset and put this dataset name into output file.
>
> On Mon, May 7, 2018 at 3:41 PM, Lizette Koehler 
> mailto:stars...@mindspring.com>>
> wrote:
>
>> If this is only for one dataset and the message is in SYSLOG, then the
>> MPF list would work.
>>
>> If there are multiple datasets that need to be available before
>> proceeding, then it is getting to be a bit trickier.
>>
>> Several Scheduling software have Dataset Triggers.  And they sometimes
>> will monitor for the creation of an SMF Record (Type 30 I think). Then take
>> action as described to their process.
>>
>> Humans can see that datasets are there and then submit jobs.  But that
>> requires a human to be vigilant and submit the job when all requirements
>> are met.
>>
>> Also, the human has to review the message and ensure the return code is 0
>> before proceeding.
>>
>>
>> So to provide the function for the OP without purchasing a product, will
>> be a challenge I think.
>>
>>1)  Monitor for dataset creation via SVT messages.
>>a) If more than one file has to be sent, then monitor for
>> additional creations before proceeding
>>2)  Ensure message shows 0 return code.  Anything else needs to be
>> reviewed
>>3)  Ensure all files are available before the next job is submitted
>>
>> Unless the OP has other requirements, I think the three listed are what
>> are needed.
>>
>> Lizette
>>
>>
>>
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List 
>> > mailto:IBM-MAIN@LISTSERV.UA.EDU>> On
>> Behalf Of
>> > Lizette Koehler
>> > Sent: Monday, May 07, 2018 5:25 AM
>> > To: I

Re: GETMAIN LOC=32

2018-05-07 Thread Charles Mills

Rouge operating systems make me see red!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 7, 2018 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

I just realized what is happening. Paul is involved with the rouge 
development of MVS/380 (and VSE/380) to run on Herc as 32bit, not 31bit.

Now that they have a non-conforming operating system, they want the real 
operating system people to support some of the stuff they did in the 
rouge operating system.

Paul, If you are going to create your own operating system, then you 
have to acknowledge that there will be differences and you can't expect 
the real operating system people to change a major item just to remove 
those differences.

This is a list about z/OS, OS/390 and MVS, not some rouge, non-IBM 
operating system. Now that I understand where you are coming from, I 
personally would like to see you banned for wasting our time.

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

Re: Job submit using REXX

Hello Phil,

Thanks for reply. As I am new to REXX, can you please help me in sample
rexx program for this task.


On Mon, May 7, 2018 at 9:46 PM, Phil Carlyle <
0190521b6517-dmarc-requ...@listserv.ua.edu> wrote:

> You forgot the QUEUE ‘’ to flush out the queue.
>
> PHIL CARLYLE
> Information Security | IAM RACF directory services
> M: 480-235-2837 | phil.carl...@aexp.com
> TEKSystems
>
> “The Universe is made up of Protons, Neutrons, Electrons & Morons!”
>
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of venkat kulkarni
> Sent: Monday, May 7, 2018 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job submit using REXX
>
> REXX i used to copy DCON address space message into ps file is
>
> ADDRESS TSO
> DO I=0 TO 4
> "ALLOC F(ISFIN) TRACKS SPACE(1) REU"
> "ALLOC F(ISFOUT) NEW DELETE REU ",
> "TRACKS SPACE(100,100) LRECL(133) RECFM(F,B) DSORG(PS)"
> "ALLOC F(TEMPPRT) DA('v12396.NEW.PS1') MOD REUSE"
> QUEUE "PRE DCON"
> QUEUE "ST"
> QUEUE "DOWN" I
> QUEUE "FIND 'JESJCL'"
> QUEUE "++S"
> QUEUE "PRINT FILE TEMPPRT"
> QUEUE "PRINT"
> QUEUE "PRINT CLOSE"
> QUEUE "END"
> QUEUE "EXIT"
> "EXECIO" QUEUED()" DISKW ISFIN (FINIS"
> ADDRESS ISPEXEC "SELECT PGM(ISFAFD) PARM('++32,255)"
> END
> EXIT
>
>
> Now, I have all required log in  v12396.NEW.PS1 file  and i want to
> extract  FTP.DATA.** dataset name from this file and
> copy it to another
> file for further process.
>
> v12396.NEW.PS1  contain many other message including below.
>
>
> SVTM052I STEP01   COPY FDDB4142(  95,456)
>
> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
>
> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00 >
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
>
>
>
> SVTM052I STEP01   COPY FDDB4099(  95,458)
>
> SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
>
> SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00<
> ftp://FTP.DATA.AUDIT.TRAIL.G1568V00>
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
>
> SVTM052I STEP01   COPY FDDB4052(  95,516)
>
> SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00
>
> SVTM052I  TO   FTP.DATA.IAS.G3486V00
>
> SVTM052I  COMPLETED  /SCPA000I
>
>
> On Mon, May 7, 2018 at 7:56 PM, venkat kulkarni <
> venkatkulkarn...@gmail.com>
> wrote:
>
> > Hello Group,
> >
> > Thanks for all response. We have Netview, which can be used for
> > automation. My idea is to create REXX, which extracted data from DCON
> > address space into one dataset.
> >
> > Then i need help to write REXX to extract   FTP.DATA.**
> dataset from this
> > ps dataset and put these dataset name into other ps dataset.
> >
> > SVTM052I STEP01   COPY FDDB4142(  95,456)
> >
> > SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> >
> > SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00 /FTP.DATA.ATRAIL.G0458V00>
> >
> > SVTM052I  COMPLETED  /SCPA000I
> >
> >
> >
> >
> >
> >
> > SVTM052I STEP01   COPY FDDB4099(  95,458)
> >
> > SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
> >
> > SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00<
> ftp://FTP.DATA.AUDIT.TRAIL.G1568V00>
> >
> > SVTM052I  COMPLETED  /SCPA000I
> >
> >
> >
> >
> > SVTM052I STEP01   COPY FDDB4052(  95,516)
> >
> > SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00
> >
> > SVTM052I  TO   FTP.DATA.IAS.G3486V00
> >
> > SVTM052I  COMPLETED  /SCPA000I
> >
> > Once we have this output dataset having   FTP.DATA.**
> full name and i
> > want to write another REXX  to put this dataset name into JCL and submit
> > batch job.
> >
> > Can anybody help me with sample REXX for extracting   FTP.DATA.**<
> ftp://FTP.DATA.**> dataset
> > from my input dataset and put this dataset name into output file.
> >
> > On Mon, May 7, 2018 at 3:41 PM, Lizette Koehler  >
> > wrote:
> >
> >> If this is only for one dataset and the message is in SYSLOG, then the
> >> MPF list would work.
> >>
> >> If there are multiple datasets that need to be available before
> >> proceeding, then it is getting to be a bit trickier.
> >>
> >> Several Scheduling software have Dataset Triggers.  And they sometimes
> >> will monitor for the creation of an SMF Record (Type 30 I think). Then
> take
> >> action as described to their process.
> >>
> >> Humans can see that datasets are there and then submit jobs.  But that
> >> requires a human to be vigilant and submit the job when all requirements
> >> are met.
> >>
> >> Also, the human has to review the message and ensure the return code is
> 0
> >> before proceeding.
> >>
> >>
> >> So to provide the function for the OP without purchasing a product, will
> >> be a challenge I think.
> >>
> >>1)  Monitor for dataset creation via SVT messages.
> >>a) If more than one file has to be sent, then monit

Re: Job submit using REXX


Phil,

Your statement confuses me. Please elaborate.
What you are stating does not match my knowledge of REXX, QUEUE, and EXECIO.
Tony Thigpen

Phil Carlyle wrote on 05/07/2018 02:46 PM:

You forgot the QUEUE ‘’ to flush out the queue.

PHIL CARLYLE
Information Security | IAM RACF directory services
M: 480-235-2837 | phil.carl...@aexp.com
TEKSystems

“The Universe is made up of Protons, Neutrons, Electrons & Morons!”

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of venkat kulkarni
Sent: Monday, May 7, 2018 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Job submit using REXX

REXX i used to copy DCON address space message into ps file is

ADDRESS TSO
DO I=0 TO 4
"ALLOC F(ISFIN) TRACKS SPACE(1) REU"
"ALLOC F(ISFOUT) NEW DELETE REU ",
"TRACKS SPACE(100,100) LRECL(133) RECFM(F,B) DSORG(PS)"
"ALLOC F(TEMPPRT) DA('v12396.NEW.PS1') MOD REUSE"
QUEUE "PRE DCON"
QUEUE "ST"
QUEUE "DOWN" I
QUEUE "FIND 'JESJCL'"
QUEUE "++S"
QUEUE "PRINT FILE TEMPPRT"
QUEUE "PRINT"
QUEUE "PRINT CLOSE"
QUEUE "END"
QUEUE "EXIT"
"EXECIO" QUEUED()" DISKW ISFIN (FINIS"
ADDRESS ISPEXEC "SELECT PGM(ISFAFD) PARM('++32,255)"
END
EXIT


Now, I have all required log in  v12396.NEW.PS1 file  and i want to
extract  FTP.DATA.** dataset name from this file and copy it 
to another
file for further process.

v12396.NEW.PS1  contain many other message including below.


SVTM052I STEP01   COPY FDDB4142(  95,456)

SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00

SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00

SVTM052I  COMPLETED  /SCPA000I





SVTM052I STEP01   COPY FDDB4099(  95,458)

SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00

SVTM052I  TO   
FTP.DATA.AUDIT.TRAIL.G1568V00

SVTM052I  COMPLETED  /SCPA000I



SVTM052I STEP01   COPY FDDB4052(  95,516)

SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00

SVTM052I  TO   FTP.DATA.IAS.G3486V00

SVTM052I  COMPLETED  /SCPA000I


On Mon, May 7, 2018 at 7:56 PM, venkat kulkarni 
mailto:venkatkulkarn...@gmail.com>>
wrote:


Hello Group,

Thanks for all response. We have Netview, which can be used for
automation. My idea is to create REXX, which extracted data from DCON
address space into one dataset.

Then i need help to write REXX to extract   FTP.DATA.** 
dataset from this
ps dataset and put these dataset name into other ps dataset.

SVTM052I STEP01   COPY FDDB4142(  95,456)

SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00

SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00

SVTM052I  COMPLETED  /SCPA000I






SVTM052I STEP01   COPY FDDB4099(  95,458)

SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00

SVTM052I  TO   
FTP.DATA.AUDIT.TRAIL.G1568V00

SVTM052I  COMPLETED  /SCPA000I




SVTM052I STEP01   COPY FDDB4052(  95,516)

SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00

SVTM052I  TO   FTP.DATA.IAS.G3486V00

SVTM052I  COMPLETED  /SCPA000I

Once we have this output dataset having   FTP.DATA.** full 
name and i
want to write another REXX  to put this dataset name into JCL and submit
batch job.

Can anybody help me with sample REXX for extracting   
FTP.DATA.** dataset
from my input dataset and put this dataset name into output file.

On Mon, May 7, 2018 at 3:41 PM, Lizette Koehler 
mailto:stars...@mindspring.com>>
wrote:


If this is only for one dataset and the message is in SYSLOG, then the
MPF list would work.

If there are multiple datasets that need to be available before
proceeding, then it is getting to be a bit trickier.

Several Scheduling software have Dataset Triggers.  And they sometimes
will monitor for the creation of an SMF Record (Type 30 I think). Then take
action as described to their process.

Humans can see that datasets are there and then submit jobs.  But that
requires a human to be vigilant and submit the job when all requirements
are met.

Also, the human has to review the message and ensure the return code is 0
before proceeding.


So to provide the function for the OP without purchasing a product, will
be a challenge I think.

1)  Monitor for dataset creation via SVT messages.
a) If more than one file has to be sent, then monitor for
additional creations before proceeding
2)  Ensure message shows 0 return code.  Anything else needs to be
reviewed
3)  Ensure all files are available before the next job is submitted

Unless the OP has other requirements, I think the three listed are what
are needed.

Lizette





-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On

Behalf Of

Lizette Koehler
Sent: Monday, May 07, 2018 5:25 AM
To: IBM-MAIN@LISTSERV

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:29:31 -0500, Paul Edwards wrote:

>No, what you are calling a 24-bit application is
>actually a 32-bit application that runs on a
>reduced addressing mode of 24.

You are making up your own terminology, using words similar to 
those of existing terminology.

>I want my programs to run on S/370 hardware

S/370? really? System/370 doesn't even support 31-bit.

-- 
Tom Marchant

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

Re: [EXTERNAL] Re: IZUGUTSE ?

2018-05-07 Thread ITschak Mugzach

here is the xml: IZU.AIZUFS(IZUGUTSA) and it looks like this:


http://www.ibm.com/systems/zos/saf";
xmlns:racf="htt
.
.
.
..APPL

..APPL

..APPL

.

.

.
.
..EJBROLE

..EJBROLE

..EJBROLE

.

.

.
.
..FACILITY

..FACILITY

..FACILITY

.

.

.
.
 .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .


Best,
ITschak

On Mon, May 7, 2018 at 8:31 PM, Dyck, Lionel B. (TRA) 
wrote:

> Nothing in samplib :(
>
> This must be a very secure tool - security by obscurity.
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ITschak Mugzach
> Sent: Monday, May 07, 2018 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: IZUGUTSE ?
>
> Lionel,
>
> have you looked in sys1.samplib(*izu*)
>
> ITschak
>
> On Mon, May 7, 2018 at 7:36 PM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > Lizette Koehler wrote:
> >
> > >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
> > >https://www.safaribooksonline.com/library/
> view/ibm-zos.../9780738443096/
> >
> > Thanks, but Safari and that Red-hot spanner on the front page of that
> > RedBook is blocking/burning me to read it... ;-)
> >
> > Try this link to see the same bookie. (21 MB, 584 pages)
> >
> > http://www.redbooks.ibm.com/abstracts/sg247851.html?Open
> >
> > ISBN-13: 9780738443096
> > IBM Form #: SG24-7851-02
> >
> > 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
> >
>
>
>
> --
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
> for Legacy **|  *
>
> --
> 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
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Job submit using REXX

On Mon, 7 May 2018 14:57:34 -0400, Tony Thigpen wrote:
>Phil,
>
>Your statement confuses me. Please elaborate.
>What you are stating does not match my knowledge of REXX, QUEUE, and EXECIO.
>Tony Thigpen
>
>Phil Carlyle wrote on 05/07/2018 02:46 PM:
>> You forgot the QUEUE ‘’ to flush out the queue.
>> 
Not needed, and perhaps undesirable, if you have an explicit count as the OP 
had:

>> "EXECIO" QUEUED()" DISKW ISFIN (FINIS"

-- gil

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:24:04 -0500, Paul Edwards wrote:

>Why can't GETMAIN LOC=32 call IARV64 as above
>under the covers so that the only change I need to
>make to my application code is replace LOC=ANY
>with LOC=32?

Because FREEMAIN wouldn't work with an address in that range.

You are asking to break lots of application code as well as system code so 
that you can run on a poorly implemented extension of MVS 3.8 on a PC 
under Hercules. Why don't you fix your implementation of MVS/380 instead?

-- 
Tom Marchant

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

Re: [EXTERNAL] Re: IZUGUTSE ?

But who, other than IBM, in their right mind would hand code XML? I got the 
impression, probably wrong, that the gutsy routine provided a more user 
friendly interface (at least that was my hope).

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Monday, May 07, 2018 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IZUGUTSE ?

here is the xml: IZU.AIZUFS(IZUGUTSA) and it looks like this:


http://www.ibm.com/systems/zos/saf";
xmlns:racf="htt
.
.
.
..APPL

..APPL

..APPL

.

.

.
.
..EJBROLE

..EJBROLE

..EJBROLE

.

.

.
.
..FACILITY

..FACILITY

..FACILITY

.

.

.
.
 .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .


Best,
ITschak

On Mon, May 7, 2018 at 8:31 PM, Dyck, Lionel B. (TRA) 
wrote:

> Nothing in samplib :(
>
> This must be a very secure tool - security by obscurity.
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ITschak Mugzach
> Sent: Monday, May 07, 2018 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: IZUGUTSE ?
>
> Lionel,
>
> have you looked in sys1.samplib(*izu*)
>
> ITschak
>
> On Mon, May 7, 2018 at 7:36 PM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > Lizette Koehler wrote:
> >
> > >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
> > >https://www.safaribooksonline.com/library/
> view/ibm-zos.../9780738443096/
> >
> > Thanks, but Safari and that Red-hot spanner on the front page of that
> > RedBook is blocking/burning me to read it... ;-)
> >
> > Try this link to see the same bookie. (21 MB, 584 pages)
> >
> > http://www.redbooks.ibm.com/abstracts/sg247851.html?Open
> >
> > ISBN-13: 9780738443096
> > IBM Form #: SG24-7851-02
> >
> > 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
> >
>
>
>
> --
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
> for Legacy **|  *
>
> --
> 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
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

DFSMSdss Question

2018-05-07 Thread Porowski, Kenneth

Is there any way to get a listing of datasets on a dss dump tape?





This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, "CIT"), and are intended solely for the 
recipient(s) named above. If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited. CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s). If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials. To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.





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

CICS and DB2

2018-05-07 Thread Porowski, Kenneth

Has anyone managed to configure a connection from CICSTS running on z/OS to a 
DB2 UDB running on Windows?
Specifically without having to have DB2 on z/OS.





This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, "CIT"), and are intended solely for the 
recipient(s) named above. If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited. CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s). If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials. To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.





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

Re: [EXTERNAL] Re: IZUGUTSE ?

2018-05-07 Thread Allan Staller

Lots of people use XML. It is handy for translating X to Y in a platform 
independent manner.
That being said, I would only use XML if forced to by business/applications 
constraints.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 7, 2018 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IZUGUTSE ?

But who, other than IBM, in their right mind would hand code XML? I got the 
impression, probably wrong, that the gutsy routine provided a more user 
friendly interface (at least that was my hope).

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Monday, May 07, 2018 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IZUGUTSE ?

here is the xml: IZU.AIZUFS(IZUGUTSA) and it looks like this:


https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ibm.com%2Fsystems%2Fzos%2Fsaf&data=02%7C01%7Callan.staller%40HCL.COM%7C41614400f44647b0be9808d5b44fd535%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636613177367754464&sdata=EeGgFA6C53wb1ZYLFLOuh8E9ZEm0Y6TwDXfh41ocjGw%3D&reserved=0";
xmlns:racf="htt
.
.
.
..APPL

..APPL

..APPL

.

.

.
.
..EJBROLE

..EJBROLE

..EJBROLE

.

.

.
.
..FACILITY

..FACILITY

..FACILITY

.

.

.
.
 .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .


Best,
ITschak

On Mon, May 7, 2018 at 8:31 PM, Dyck, Lionel B. (TRA) 
wrote:

> Nothing in samplib :(
>
> This must be a very secure tool - security by obscurity.
>
> --
> 
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer – RavenTek Solution Partners
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of ITschak Mugzach
> Sent: Monday, May 07, 2018 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: IZUGUTSE ?
>
> Lionel,
>
> have you looked in sys1.samplib(*izu*)
>
> ITschak
>
> On Mon, May 7, 2018 at 7:36 PM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > Lizette Koehler wrote:
> >
> > >IBM z/OS Management Facility V2R3 [Book] - Safari Books Online
> > >https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > >www.safaribooksonline.com%2Flibrary%2F&data=02%7C01%7Callan.staller
> > >%40HCL.COM%7C41614400f44647b0be9808d5b44fd535%7C189de737c93a4f5a8b6
> > >86f4ca9941912%7C0%7C0%7C636613177367754464&sdata=qxQtFHCnyqVLmIWM1%
> > >2F%2BBFXdl%2Fch99Ft15tBaDHHYzlw%3D&reserved=0
> view/ibm-zos.../9780738443096/
> >
> > Thanks, but Safari and that Red-hot spanner on the front page of
> > that RedBook is blocking/burning me to read it... ;-)
> >
> > Try this link to see the same bookie. (21 MB, 584 pages)
> >
> > https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> > w.redbooks.ibm.com%2Fabstracts%2Fsg247851.html%3FOpen&data=02%7C01%7
> > Callan.staller%40HCL.COM%7C41614400f44647b0be9808d5b44fd535%7C189de7
> > 37c93a4f5a8b686f4ca9941912%7C0%7C0%7C636613177367754464&sdata=IrGjdM
> > fqKiGQxf54M9WKjytENmMv3k6QLwAhtwjhX%2F8%3D&reserved=0
> >
> > ISBN-13: 9780738443096
> > IBM Form #: SG24-7851-02
> >
> > 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
> >
>
>
>
> --
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Contiguous
> Monitoring for Legacy **|  *
>
> --
> 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
>



--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

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

Re: GETMAIN LOC=32

2018-05-07 Thread Jim Mulder

  I am an insider with respect to the VSM and RSM components of z/OS, 
and the comments below are pretty accurate.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



> - IMO, IBM will not perceive any ROI from your request sufficient to 
> make them consider it.  I'm not an insider, but I expect them to have 
> ideas which they think are far more lucrative than yours to pursue. 
> Such ideas probably include some which, although they may not have the 
> elegance of yours from an application programmer p-o-v, are being 
> requested by companies which pay IBM many more dollars than the likes of 

> you or me.
> 
> My conclusion: IBM will see the potential for incurring cost (at first 
> from the initial development effort, and then on-going from the 
> potential increase in PMRs where such a facility is used) without any 
> obvious resultant potential increase in revenue.
> 
> - Virtual storage below the 2GB bar is generally managed down to a 
> doubleword granularity.  Whether the macros used to make requests to get 

> some of it or free some of it are called GETMAIN and FREEMAIN, or 
> STORAGE, it is the same set on control blocks that are updated to keep 
> account of it.  When managing storage at the doubleword level, it 
> becomes possible for a significant fraction of total storage consumed to 

> be used to track all the storage consumed.
> 
> - When scaling up storage to create the 64-bit address space size, 
> managing storage at the doubleword atom size is just not a wise choice 
> in terms of overhead.  For this reason, virtual storage above the 2GB 
> bar is managed in chunks of 1MB.
> 
> My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN 

> storage granularity natively in the 2GB-4GB address range.  You would 
> have to add some intermediate storage administration layer - which may 
> not even be that difficult to do, as long as your 32-bit program 
> "compiler" generated code to call it for storage management calls.
> 
> - MVS private storage admin has "always" relied on user apps building 
> storage usage from the bottom of the private area up (the "region"), 
> while the system's use of private storage starts at the top and grows 
> downward.  When the two meet, private storage is exhausted and the job 
> crashes.  This process is occurring both below and above the 16MB line.
> 
> - For the ATL or extended private area, the "top" is the underside of 
> the 2GB line where important control blocks reside, possibly including 
> page and segment tables.  (This was true for XA, dunno if it is still 
> true for z/OS, although what else is using all those megabytes reported 
> by IEF032I (which used to be IEF374I) ?? )
> 
> My conclusion: Without a radical reengineering of the bottom-up-for-apps 

> and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable, 
> and so the prospective 32-bit application will never be able to acquire 
> a single 3GB chunk of storage entirely below virtual address 4GB.
> 
> There were enough hassles flowing from latent bugs exposed by the VSM 
> (GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?) 
> without adding some sort of AM32 to the mix.  That is why I think the 
> PMR count could rise quite a bit giving a potential risk which is easy 
> to avoid - simply by not making such a change.  Lots of subtle 
> assumptions about the nature of the behaviour of the OS lie lurking in 
> application code that is numerous years old, I think.  Sure, the bugs 
> shouldn't be there, but why risk exposing them?
> 
> 
> Overall, while I too like elegant programming models, at the end of the 
> day, IBM and other vendors have to support their customers, and on this 
> platform an important part of that is compatibility.  I certainly 
> sympathise with the idea that there's an extra 2GB of storage for 
> "existing" programs there for the taking, but in practice, I don't think 

> it really is there in a z/OS environment.




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

Re: GETMAIN LOC=32

2018-05-07 Thread Seymour J Metz

I don't agree that supporting GETMAIN between 2GiB and 4GiB  would be elegant, 
although it might have some practical utility. I also suspect that it would 
cause more problems than it solved.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Greg Price 
Sent: Monday, May 7, 2018 1:32 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: GETMAIN LOC=32

[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points -
some of which have been mentioned or alluded to by others - for your
consideration:

- IMO, IBM will not perceive any ROI from your request sufficient to
make them consider it.  I'm not an insider, but I expect them to have
ideas which they think are far more lucrative than yours to pursue.
Such ideas probably include some which, although they may not have the
elegance of yours from an application programmer p-o-v, are being
requested by companies which pay IBM many more dollars than the likes of
you or me.

My conclusion: IBM will see the potential for incurring cost (at first
from the initial development effort, and then on-going from the
potential increase in PMRs where such a facility is used) without any
obvious resultant potential increase in revenue.

- Virtual storage below the 2GB bar is generally managed down to a
doubleword granularity.  Whether the macros used to make requests to get
some of it or free some of it are called GETMAIN and FREEMAIN, or
STORAGE, it is the same set on control blocks that are updated to keep
account of it.  When managing storage at the doubleword level, it
becomes possible for a significant fraction of total storage consumed to
be used to track all the storage consumed.

- When scaling up storage to create the 64-bit address space size,
managing storage at the doubleword atom size is just not a wise choice
in terms of overhead.  For this reason, virtual storage above the 2GB
bar is managed in chunks of 1MB.

My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN
storage granularity natively in the 2GB-4GB address range.  You would
have to add some intermediate storage administration layer - which may
not even be that difficult to do, as long as your 32-bit program
"compiler" generated code to call it for storage management calls.

- MVS private storage admin has "always" relied on user apps building
storage usage from the bottom of the private area up (the "region"),
while the system's use of private storage starts at the top and grows
downward.  When the two meet, private storage is exhausted and the job
crashes.  This process is occurring both below and above the 16MB line.

- For the ATL or extended private area, the "top" is the underside of
the 2GB line where important control blocks reside, possibly including
page and segment tables.  (This was true for XA, dunno if it is still
true for z/OS, although what else is using all those megabytes reported
by IEF032I (which used to be IEF374I) ?? )

My conclusion: Without a radical reengineering of the bottom-up-for-apps
and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable,
and so the prospective 32-bit application will never be able to acquire
a single 3GB chunk of storage entirely below virtual address 4GB.

There were enough hassles flowing from latent bugs exposed by the VSM
(GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?)
without adding some sort of AM32 to the mix.  That is why I think the
PMR count could rise quite a bit giving a potential risk which is easy
to avoid - simply by not making such a change.  Lots of subtle
assumptions about the nature of the behaviour of the OS lie lurking in
application code that is numerous years old, I think.  Sure, the bugs
shouldn't be there, but why risk exposing them?


Overall, while I too like elegant programming models, at the end of the
day, IBM and other vendors have to support their customers, and on this
platform an important part of that is compatibility.  I certainly
sympathise with the idea that there's an extra 2GB of storage for
"existing" programs there for the taking, but in practice, I don't think
it really is there in a z/OS environment.

And this opinion is from a bloke who still thinks that if the System/360
CCW designer had not thought that a spare halfword would actually prove
more useful than two separate spare bytes, then the high byte of the
address word would have been available for XA to provide immediate AM31
support for I/O macros in DFP V2.

But compatibility is important for vendors.  I happen to know of an IBM
product (not in the z/OS package but acquired from an ISV and runs on
z/OS) which uses a routine with logic unchanged since 1967.


I think z/OS has diverged too far from its MVS/370 predecessor where you
could, perhaps, successfully implement your idea.

And just to opine about another point, I will

Re: GETMAIN LOC=32

2018-05-07 Thread Jim Mulder

> Why can't GETMAIN LOC=32 call IARV64 as above
> under the covers so that the only change I need to
> make to my application code is replace LOC=ANY
> with LOC=32?

 Because there is not a sufficient financial 
benefit to IBM to spend the money to implement 
anything like that.

> Note that IARV64 has a granularity of 1 MiB when
> I would prefer GETMAIN granularity for 32-bit
> memory.

  The IARST64 and IARCP64 interfaces provide 
more granularity for managing 64-bit storage. 
 
> Also note that the CVT offset that IARV64 uses to
> do a PC call is not documented, so this is a
> proprietary interface.

  The IARV64 macro is the documented interface.

> In addition I would like to produce a load module
> that is trimodal which still runs on MVS 3.8j and
> MVS/XA and OS/390. The SVC 120 exists on all
> these systems (and LOC=32 will be hamless on
> all of them), but not the IARV64 PC call. These
> systems don't have the required hardware to do
> PC calls either.

  IBM has no interest in providing downward
compatibility with MVS 3.8j, MVS/XA, OS/390,
or with any architecture prior to zArchitecture. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


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

Re: GETMAIN LOC=32

2018-05-07 Thread Jim Mulder

  The current implementation of IARV64 GETSTOR with
USE2GTO32G=YES  is to do a first-fit search from low address to 
high address of the 2GBTO32GB area.  So if there is available space 
below 4GiB, that is what you will get.  Since that implementation detail
is not documented, it is not guaranteed to behave that way in the future.
But I know of no plans or reasons to change that.
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


> The IARV64 instruction probably will find
> memory. But it will be a 64-bit address
> requiring me to manipulate and save
> 64-bit registers. I wish to write 32-bit
> programs, and I also want those 32-bit
> programs to run on OS/390 as AM31
> and on MVS 3.8j as AM24. Only on z/OS
> and MVS/380 would my 32-bit applications
> run as AM64 and obtain and use LOC=32
> memory.

> On Mon, 7 May 2018 11:51:55 -0500, Steve Partlow  
wrote:
> 
> >To the original requirement of "support a LOC=32 parameter to 
> GETMAIN, giving 32-bit programs access to a full 4 GiB instead of 
> the current 2 GiB provided by LOC=31."
> >
> >Why not write your own routine to issue an IARV64 GETSTOR with 
> USE2GTO32G=YES and then GETMAIN if that fails to find storage? The 
> free could easily check the address being freed to decide which 
> service to use on release.
> >
> >--
> >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: DFSMSdss Question

2018-05-07 Thread John Clifford

run a restore of the tape with no run option ( I forget the spelling). it
will list what it would have restored and just end

On Mon, May 7, 2018 at 3:21 PM, Porowski, Kenneth 
wrote:

> Is there any way to get a listing of datasets on a dss dump tape?
>
>
>
> 
>
> This email message and any accompanying materials may contain proprietary,
> privileged and confidential information of CIT Group Inc. or its
> subsidiaries or affiliates (collectively, "CIT"), and are intended solely
> for the recipient(s) named above. If you are not the intended recipient of
> this communication, any use, disclosure, printing, copying or distribution,
> or reliance on the contents, of this communication is strictly prohibited.
> CIT disclaims any liability for the review, retransmission, dissemination
> or other use of, or the taking of any action in reliance upon, this
> communication by persons other than the intended recipient(s). If you have
> received this communication in error, please reply to the sender advising
> of the error in transmission, and immediately delete and destroy the
> communication and any accompanying materials. To the extent permitted by
> applicable law, CIT and others may inspect, review, monitor, analyze, copy,
> record and retain any communications sent from or received at this email
> address.
>
> 
>
>
>
> --
> 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: GETMAIN LOC=32

On Mon, 7 May 2018 14:19:24 -0500, Tom Marchant wrote:

>FREEMAIN wouldn't work with an address in that range.

I may have been mistaken about this.

-- 
Tom Marchant

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

Re: CICS and DB2

If you have not done so you might try posting on either the CICS or DB2 lists

To join, use these URLs

DB2 http://www.idug.org/

CICShttp://www.listserv.uga.edu/archives/cics-l.html

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Porowski, Kenneth
> Sent: Monday, May 07, 2018 12:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CICS and DB2
> 
> Has anyone managed to configure a connection from CICSTS running on z/OS to a
> DB2 UDB running on Windows?
> Specifically without having to have DB2 on z/OS.
> 
> 

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

Re: DFSMSdss Question

>From the DFSMSdss Storage Administration


TYPRUN=NORUN

For copy, dump, restore, compress, and release operations, only input data set
selection is done without actually processing data sets. Printed output for the
run indicates the data sets selected. For a defragmentation operation, the 
initial
volume statistics are printed without actually relocating any extents. For a
CONVERTV operation, a full report is produced, but no volumes or data sets
are actually converted. For CGCREATED operation, only control card syntax
checking is done. The task is not processed.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Porowski, Kenneth
> Sent: Monday, May 07, 2018 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFSMSdss Question
> 
> Is there any way to get a listing of datasets on a dss dump tape?
> 
> 
> 

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

Re: GETMAIN LOC=32

On Mon, 7 May 2018 13:34:58 -0500, Paul Edwards wrote:

>But you are happy to constrain
>32-bit applications to 2 GiB when all you may
>need is a LOC=32 parameter and you can go
>all the way up to 4 GiB.

No, you also have to run AMODE(64), which means that there are many 
system services that you cannot use without switching to AMODE 31.

Maybe you believe that if you keep repeating the phrase "32-bit applications", 
it will be accepted that there is such a thing on z/Architecture. There is not.

-- 
Tom Marchant

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

Re: Job submit using REXX

Venkat - what I think you should consider is hiring a consultant to help you 
with this.

I do not want to discourage from posting questions. That is how we all learn.  
But there are limits as to what an Internet list can assist with.



Using a consultant you will get 

Knowledge Transfer

Documentation

Support for the process.

This list is a discussion list - it is not a Service Desk or Consulting function

Any samples provided will probably lead to more questions from you.. This is 
not a bad thing, but over time, the list may not respond.  The people on this 
list have daily jobs and do not always have time to answer questions or create 
code.

You are trying to create a new process that will require knowledge of the tools 
you are going to use.  Since this has expanded from the question

How can I submit a job in REXX

To 

Netview Automation to submit a job from an FTP Process that is transferring a 
dataset to my system


This is not a simple process.  And will require a lot of knowledge of REXX, 
Netview, SDSF REXX and possibly other processes.



There are several people on this list that could provide you with consultation 
functions


Lizette




> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> venkat kulkarni
> Sent: Monday, May 07, 2018 11:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job submit using REXX
> 
> Hello Phil,
> 
> Thanks for reply. As I am new to REXX, can you please help me in sample rexx
> program for this task.
> 
> 
> On Mon, May 7, 2018 at 9:46 PM, Phil Carlyle < 0190521b6517-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
> > You forgot the QUEUE ‘’ to flush out the queue.
> >
> > PHIL CARLYLE
> > Information Security | IAM RACF directory services
> > M: 480-235-2837 | phil.carl...@aexp.com
> > TEKSystems
> >
> > “The Universe is made up of Protons, Neutrons, Electrons & Morons!”
> >
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of venkat kulkarni
> > Sent: Monday, May 7, 2018 10:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Job submit using REXX
> >
> > REXX i used to copy DCON address space message into ps file is
> >
> > ADDRESS TSO
> > DO I=0 TO 4
> > "ALLOC F(ISFIN) TRACKS SPACE(1) REU"
> > "ALLOC F(ISFOUT) NEW DELETE REU ",
> > "TRACKS SPACE(100,100) LRECL(133) RECFM(F,B) DSORG(PS)"
> > "ALLOC F(TEMPPRT) DA('v12396.NEW.PS1') MOD REUSE"
> > QUEUE "PRE DCON"
> > QUEUE "ST"
> > QUEUE "DOWN" I
> > QUEUE "FIND 'JESJCL'"
> > QUEUE "++S"
> > QUEUE "PRINT FILE TEMPPRT"
> > QUEUE "PRINT"
> > QUEUE "PRINT CLOSE"
> > QUEUE "END"
> > QUEUE "EXIT"
> > "EXECIO" QUEUED()" DISKW ISFIN (FINIS"
> > ADDRESS ISPEXEC "SELECT PGM(ISFAFD) PARM('++32,255)"
> > END
> > EXIT
> >
> >
> > Now, I have all required log in  v12396.NEW.PS1 file  and i want to
> > extract  FTP.DATA.** dataset name from this file
> > and copy it to another file for further process.
> >
> > v12396.NEW.PS1  contain many other message including below.
> >
> >
> > SVTM052I STEP01   COPY FDDB4142(  95,456)
> >
> > SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> >
> > SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00 > >
> >
> > SVTM052I  COMPLETED  /SCPA000I
> >
> >
> >
> >
> >
> > SVTM052I STEP01   COPY FDDB4099(  95,458)
> >
> > SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
> >
> > SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00<
> > ftp://FTP.DATA.AUDIT.TRAIL.G1568V00>
> >
> > SVTM052I  COMPLETED  /SCPA000I
> >
> >
> >
> > SVTM052I STEP01   COPY FDDB4052(  95,516)
> >
> > SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00
> >
> > SVTM052I  TO   FTP.DATA.IAS.G3486V00
> >
> > SVTM052I  COMPLETED  /SCPA000I
> >
> >
> > On Mon, May 7, 2018 at 7:56 PM, venkat kulkarni <
> > venkatkulkarn...@gmail.com>
> > wrote:
> >
> > > Hello Group,
> > >
> > > Thanks for all response. We have Netview, which can be used for
> > > automation. My idea is to create REXX, which extracted data from
> > > DCON address space into one dataset.
> > >
> > > Then i need help to write REXX to extract
> FTP.DATA.**
> > dataset from this
> > > ps dataset and put these dataset name into other ps dataset.
> > >
> > > SVTM052I STEP01   COPY FDDB4142(  95,456)
> > >
> > > SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> > >
> > > SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00 > /FTP.DATA.ATRAIL.G0458V00>
> > >
> > > SVTM052I  COMPLETED  /SCPA000I
> > >
> > >
> > >
> > >
> > >
> > >
> > > SVTM052I STEP01   COPY FDDB4099(  95,458)
> > >
> > > SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
> > >
> > > SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00<
> > ftp://FTP.DATA.AUDIT.TRAIL.G1568V00>
> > >
> > > SVTM052I  COMPLETED  /SCPA000I
> > >
> > >
> > >
> > >
> > > SVTM052I STEP01   COPY FDDB4

Re: Job submit using REXX

2018-05-07 Thread Phil Carlyle

When using QUEUE() for output the last record needs to be NULL in order to 
completely flush the buffers.

PHIL CARLYLE
Information Security | IAM RACF directory services
M: 480-235-2837 | phil.carl...@aexp.com
TEKSystems

“The Universe is made up of Protons, Neutrons, Electrons & Morons!”

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 7, 2018 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Job submit using REXX

On Mon, 7 May 2018 14:57:34 -0400, Tony Thigpen wrote:
>Phil,
>
>Your statement confuses me. Please elaborate.
>What you are stating does not match my knowledge of REXX, QUEUE, and EXECIO.
>Tony Thigpen
>
>Phil Carlyle wrote on 05/07/2018 02:46 PM:
>> You forgot the QUEUE ‘’ to flush out the queue.
>>
Not needed, and perhaps undesirable, if you have an explicit count as the OP 
had:

>> "EXECIO" QUEUED()" DISKW ISFIN (FINIS"

-- gil

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

American Express made the following annotations
**
"This message and any attachments are solely for the intended recipient and may 
contain confidential or privileged information. If you are not the intended 
recipient, any disclosure, copying, use, or distribution of the information 
included in this message and any attachments is prohibited. If you have 
received this communication in error, please notify us by reply e-mail and 
immediately and permanently delete this message and any attachments. Thank you."

American Express a ajouté le commentaire suivant le Ce courrier et toute pièce 
jointe qu'il contient sont réservés au seul destinataire indiqué et peuvent 
renfermer des 
renseignements confidentiels et privilégiés. Si vous n'êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courrier 
ou de toute pièce jointe est interdite. Si vous avez reçu cette communication 
par erreur, veuillez nous en aviser par courrier et détruire immédiatement le 
courrier et les pièces jointes. Merci.

**

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

Re: Job submit using REXX