Re: Job submit using REXX

[Brian Westerman]

Sorry in advance for the product plug.

Our syzMPF/z console automation product (and SyzEMAIL/z if you want to get 
really fancy with the process) will do this and it's a lot cheaper than other 
automation software.

The script can key off the message ID (and fully parse the message) and can set 
variables so that you don't start the later job until all three of the datasets 
you are concerned about are received.  Using SyzMPF/z you can either just 
collect the data and tell the operator (or anyone via email or Cell phone text 
message), or you could simply have SyzMPF/z start the task the uses those 3 
FTP.DATA.** datasets.

Personally I would have SyzMPF/z start the job/task because you never know if 
the operators are going to get around to checking their email or text messages 
before you send another set of the datasets and you don't want to miss a set's 
processing because your operators were not paying attention. :)

You can also set it up so that if you don't receive all three of them by a 
certain time of day that you start sending email and/or text messages to people 
to tell them that they need to look into what happened to whichever one(s) 
are/is missing.  You could also send the people who sent the data a email or 
text message that you have received that particular part as each one is 
received, there are lots of options for how to approach the task at hand, and 
SyzMPF/z has many options to choose from when you are deciding what you want to 
do.

The script would be pretty simple to write, if your SVTM052I messages are one 
continuous multi-line message then you just collect the words of the message.

In the case of your first series, "E2PP.DW801P.WTALZUP.XM.G0520V00" is  
(word 7) and "FTP.DATA.ATRAIL.G0458V00" is  (word 10).  If they are 
individual SVTM052I messages then both datasets are  (word 3) of their 
respective messages.  So, while it doesn't do what you want yet by starting the 
task (because you only have one of the datasets), you could send an email right 
away and say (to whoever you want) that:

 was received at  as  at :: on //
which would be received as:

"E2PP.DW801P.WTALZUP.XM.G0520V00 was received at PRODA as 
FTP.DATA.ATRAIL.G0458V00 at 11:02:23 on 05/06/2018."

You can make this (or something similar) the subject and/or the body of the 
email or text message.  At the time this data is being built there are more 
than 200 variables that are "known" about this process including the nodes, the 
users, the times, etc. (it's a long list).  The email or text message can be 
any length or contain any information you want and can go to (up to 255 
separate destinations/people) although I doubt you need to do that.

Where you to start to build JCL you could insert this particular DD into the 
JCL 

//ddname1 DD  DISP=SHR,DSN=
which builds
//ddname1 DD  DISP=SHR,DSN=FTP.DATA.ATRAIL.G0458V00

In any case, you could just save the message to either a variable (or series of 
variables) and then when it's time to use them you just recall the saved 
variables and either build the task dynamically, or use them as text within the 
email or text message depending on which one you decided to go with.  What this 
means is that  is only  which it's being processed within that 
particular script from that original message, you have to save it as a 
persistent variable if you want to "pass" it to some other task or script (in 
this case the script for the second and third datasets when they are processed, 
which might even be this same exact script), so you would just code a SETVAR 
within the script before you exit that processing.  You could call one ATRAIL, 
one AUDIT and the last one IAS (so that it's meaningful to the dataset name it 
points to)

 SETVARwould load the third dataset in your series of messages 
into the  variable.  

You could also just build the JCL up to the point of this dataset and then 
build it some more when the next one is received and finally when the 3rd 
dataset is there, just finish the JCL and submit it.

To make sure you don't do anything until you have all of the variables, you 
simply check to see which one(s) you have and which ones you are still waiting 
for.  That way it would not matter what order they arrived, you don't take 
action (of starting the job/task or email message until you have them all.  
Once you have all three, you build the job or start the task, clear the 
existing variables and let it wait for the process to start the next time.  

Not knowing the sequence involved, you could even set this up so that you could 
get any number of these and process them all at once at the end of the day if 
you wanted.  The possibilities are as endless as your imagination.

There are lots of ways to approach this process, I only covered one of the 
possibilities, but there are many ways to skin this cat.

Script-wise it's really simple, and almost any automation product can probably 
handle it.  The advantage we have is that SyzMPF/z is less than 

Re: GETMAIN LOC=32

[Jim Mulder]

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

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


> I'm wondering if there's a better way to word my
> RFE to avoid the apparent confusion.



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

[Steve Smith]

Before you (or anyone) writes an RFE telling IBM how to do something, you
might want to think about the problem, and investigate how it might be
solved.

As it happens, this proposal should be rejected because the capability
already exists.

sas

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

Re: z/VM Live Guest Relocation

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2018c.html#77 z/VM Live Guest Relocation
http://www.garlic.com/~lynn/2018c.html#78 z/VM Live Guest Relocation
http://www.garlic.com/~lynn/2018c.html#79 z/VM Live Guest Relocation
http://www.garlic.com/~lynn/2018c.html#80 z/VM Live Guest Relocation

some other trivia about the cp67 (precursor to vm370) commercial
spinoffs besides cluster, loosely-coupled, single-system-image, load
balancing and fall-over as well as live guest relocation.

other trivia: I recently posted scans of 1969 "First Financial Language"
manual to facebook. I got copy when one of the cp67 commercial spinoffs
(science center and MIT lincoln labs) was recruiting me ... and the
person primarily responsible for first financial language implementation
then makes some comments.  turns out that he had teamed up a decade
later with bricklin to form software arts and implement visicalc.
https://en.wikipedia.org/wiki/VisiCalc

the other cp67 commercial spinoff from the same period ... was also
heavily into 4th generation reporting language ... another science
center spin-off and moved up value chain with RAMIS from
Mathematica at NCSS
https://en.wikipedia.org/wiki/Ramis_software
and then NOMAD
https://en.wikipedia.org/wiki/Nomad_software
RAMIS followon, FOCUS
https://en.wikipedia.org/wiki/FOCUS
FOCUS also on another (virtual machine based) commercial online service
https://en.wikipedia.org/wiki/Tymshare

of course all these mainframe 4th generation languages were eventually
pretty much subsumed by SQL/RDBMS which was developed on VM370 system at
IBM San Jose Research, System/R ... some past posts
http://www.garlic.com/~lynn/submisc.html#systemr

and Tymshare trivia ... started providing its CMS-based online computer
conferencing (precursor to listserv on ibm sponsored bitnet in the 80s
and modern social media) free to SHARE ... as VMSHARE in Aug1976 (later
also added PCSHARE). vmshare archive
http://vm.marist.edu/~vmshare/

and vm/bitnet trivia (used technology similar to the IBM internal
network ... primarily VM-based)
https://en.wikipedia.org/wiki/BITNET
and vm/listserv reference
http://www.lsoft.com/products/listserv-history.asp

which is where this ibm-main group eventually originates

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

On Sun, 6 May 2018 16:11:57 -0700, Charles Mills  wrote:

> The effort would be on the part of "service" writers -- primarily IBM 
> developers.

Sure.

>This is a new sort of-AMODE. Storage that you can
> reference but cannot pass to the unwary, cannot
> use with standard MVS VL=1 linkage, cannot branch to, ...

The same consideration of not being able to
use VL applies if you write an AM64 64-bit program
too. Updating a 32-bit program to not use VL is a
lot easier than converting the entire program
to 64-bit AND not using VL.

>> So long as the top 32 bits of 64-bit registers remain as zero (a 32-bit
>> program is never going to change that), AM64 is just as good as an AM32
>
>Au contraire. 
>
>1.  A 31/32 bit program can do 64-bit arithmetic.

I consider that to be a 64-bit program. A 32-bit
program is one that only uses 32-bit registers.

I have no opinion about 64-bit programs.
You can run them in AM31 as today. I am
only interested in 32-bit programs.

> As a writer of mixed mode programs, I can tell
> you this is a real gotcha. In an AMODE 31
> program you can use some register for 64 bit
> arithmetic, and a little while later load a 31-bit
> address into it and use it as a pointer -- and
> that all works. In AMODE 64, suddenly those
> 64-bit high order leftovers byte you in the butt.

Sure.

>2. A 31/32-bit program cannot count on the high
> halves being zero in any event. There is no
> guarantee that you are entered with the high
> halves equal to zero,

The 32-bit program can clear all registers with
LMH if IBM can't guarantee high halves of 0.
It can do that once at startup and the rest of
the program doesn't need to change.

> and no guarantee they stay that way -- they
> theoretically should, but there are no guarantees,
> if you call some service.

A theoretical faulty service can trash the low
32-bits just as easily as the high 32-bits.

64-bit programs rely on non-faulty services.
So too 32-bit programs running in AM64
rely on it. There's no difference.

>I'm not going to be as blunt as @Tony but IMHO
> there is so little chance of this happening that I
> think this discussion is moot. Lord knows I have
> been wrong before.

I'm wondering if there's a better way to word my
RFE to avoid the apparent confusion.

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]

On Sun, 6 May 2018 18:07:02 -0500, Mike Schwab  wrote:

>So, you will have a load module marked AM32.

That doesn't exist as far as I know. The module
can either be marked AM64 or the program can
switch to AM64 at startup. My preference is for
the module to be marked AM64.

>All instructions use
>only the lower half of the registers, no grande or high portion
>instructions.

Yes, it's a 32-bit program so only uses the
bottom 32 bits of all registers.

> The program loader gets memory at x'  8
>' (or the next location not in use)

I'm not expecting the program to be loaded
above 2 GiB. Only data would come from
above that. That way you can still switch
to AM31 so that you can invoke the READ
macro etc. At a later date, when READ is
made AM64-capable, the module can
potentially be loaded into RM32 space.

In addition, my intention was that when
LOC=32 memory is allocated, it starts at
the 4 GiB location and works down, rather
than starting at the 2 GiB location and
working up. That way you can do a
GETMAIN for 3 GiB and it should work.

> and loads your program, sets
>AM64 and calls your entry point.  Any interrupts or calls save all 64
>bits and when your program is resumed all 64 bits until it exits.

Calls to subroutines would not save all
64-bits. They are 32-bit applications and
only have 72-byte save areas. The upper
32 bits of each register are 0 so there is
no need to save them.

>Should work just fine if the starting address is x' 0001 
>' or x' 0002  '

Those addresses are above 4 GiB, so that
is not part of the plan.

> since all calls should be in the 4GiB
>area.  Any instruction that loads an address into a register is
>controlled by the AMODE.

The loading of addresses are governed by
whether you use "L" or "LG", not the AMODE.

I am talking about 32-bit programs, so no
"LG" will ever be used, just a 32-bit "L".

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

[Charles Mills]

The effort would be on the part of "service" writers -- primarily IBM 
developers.

This is a new sort of-AMODE. Storage that you can reference but cannot pass to 
the unwary, cannot use with standard MVS VL=1 linkage, cannot branch to, ...

> So long as the top 32 bits of 64-bit registers remain as zero (a 32-bit
> program is never going to change that), AM64 is just as good as an AM32

Au contraire. 

1.  A 31/32 bit program can do 64-bit arithmetic. As a writer of mixed mode 
programs, I can tell you this is a real gotcha. In an AMODE 31 program you can 
use some register for 64 bit arithmetic, and a little while later load a 31-bit 
address into it and use it as a pointer -- and that all works. In AMODE 64, 
suddenly those 64-bit high order leftovers byte you in the butt.

2. A 31/32-bit program cannot count on the high halves being zero in any event. 
There is no guarantee that you are entered with the high halves equal to zero, 
and no guarantee they stay that way -- they theoretically should, but there are 
no guarantees, if you call some service.

I'm not going to be as blunt as @Tony but IMHO there is so little chance of 
this happening that I think this discussion is moot. Lord knows I have been 
wrong before.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Edwards
Sent: Sunday, May 6, 2018 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Sun, 6 May 2018 15:08:24 -0700, Charles Mills  wrote:

>What exactly would the benefit be?

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.

> Currently, if one wants to address more than
> 2GiB of memory one has to be a full AMODE 64
> program.

Executing in AMODE 64 is fine. Rewriting a
32-bit program to be 64-bit, using 64-bit
data pointers, is *not*.

> This would let a program address 4GiB while only
> using 32-bit registers and addresses in storage --
> is that the point?

Yes, this is the point. 

> Or am I confused? Is that the whole point?

The point is that 32-bit programs can access
4 GiB of memory as programmers would
normally hope is possible.

> If so, I see the benefit, but not the benefit to
> effort ratio.

What effort? Depending on how the existing
32-bit code is written, all you need to do is
change a LOC=31 to LOC=32.

> Or putting it differently, aren't three addressing
> modes enough for a system service to have to
> deal with?

3 is fine. I'm not asking for a new addressing
mode. AM64 is fine. So long as the top 32
bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64
is just as good as an AM32, so there's no need
to create an AM32, so there's very little effort
involved.

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

[Mike Schwab]

So, you will have a load module marked AM32.  All instructions use
only the lower half of the registers, no grande or high portion
instructions.  The program loader gets memory at x'  8
' (or the next location not in use) and loads your program, sets
AM64 and calls your entry point.  Any interrupts or calls save all 64
bits and when your program is resumed all 64 bits until it exits.
Should work just fine if the starting address is x' 0001 
' or x' 0002  ' since all calls should be in the 4GiB
area.  Any instruction that loads an address into a register is
controlled by the AMODE.

On Sun, May 6, 2018 at 5:15 PM, Paul Edwards  wrote:
> On Sun, 6 May 2018 15:08:24 -0700, Charles Mills  wrote:
>
>>What exactly would the benefit be?
>
> 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.
>
>> Currently, if one wants to address more than
>> 2GiB of memory one has to be a full AMODE 64
>> program.
>
> Executing in AMODE 64 is fine. Rewriting a
> 32-bit program to be 64-bit, using 64-bit
> data pointers, is *not*.
>
>> This would let a program address 4GiB while only
>> using 32-bit registers and addresses in storage --
>> is that the point?
>
> Yes, this is the point.
>
>> Or am I confused? Is that the whole point?
>
> The point is that 32-bit programs can access
> 4 GiB of memory as programmers would
> normally hope is possible.
>
>> If so, I see the benefit, but not the benefit to
>> effort ratio.
>
> What effort? Depending on how the existing
> 32-bit code is written, all you need to do is
> change a LOC=31 to LOC=32.
>
>> Or putting it differently, aren't three addressing
>> modes enough for a system service to have to
>> deal with?
>
> 3 is fine. I'm not asking for a new addressing
> mode. AM64 is fine. So long as the top 32
> bits of 64-bit registers remain as zero (a 32-bit
> program is never going to change that), AM64
> is just as good as an AM32, so there's no need
> to create an AM32, so there's very little effort
> involved.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: GETMAIN LOC=32

[Paul Edwards]

On Sun, 6 May 2018 15:08:24 -0700, Charles Mills  wrote:

>What exactly would the benefit be?

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.

> Currently, if one wants to address more than
> 2GiB of memory one has to be a full AMODE 64
> program.

Executing in AMODE 64 is fine. Rewriting a
32-bit program to be 64-bit, using 64-bit
data pointers, is *not*.

> This would let a program address 4GiB while only
> using 32-bit registers and addresses in storage --
> is that the point?

Yes, this is the point. 

> Or am I confused? Is that the whole point?

The point is that 32-bit programs can access
4 GiB of memory as programmers would
normally hope is possible.

> If so, I see the benefit, but not the benefit to
> effort ratio.

What effort? Depending on how the existing
32-bit code is written, all you need to do is
change a LOC=31 to LOC=32.

> Or putting it differently, aren't three addressing
> modes enough for a system service to have to
> deal with?

3 is fine. I'm not asking for a new addressing
mode. AM64 is fine. So long as the top 32
bits of 64-bit registers remain as zero (a 32-bit
program is never going to change that), AM64
is just as good as an AM32, so there's no need
to create an AM32, so there's very little effort
involved.

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]

On Sun, 6 May 2018 18:04:42 -0400, Tony Thigpen  wrote:

> Me thinks your logic is circular and not worth
> continuing this discussion.

I have no idea what you are talking about.
32-bit programs can suddenly access 4 GiB
of memory instead of being restricted to 2 GiB.
There's nothing circular about that, it's a
fantastic improvement and it's about time
that z/OS had the same capability as other
platforms with regard to 32-bit programming.

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

[Charles Mills]

What exactly would the benefit be? Currently, if one wants to address more than 
2GiB of memory one has to be a full AMODE 64 program. This would let a program 
address 4GiB while only using 32-bit registers and addresses in storage -- is 
that the point? Or am I confused? Is that the whole point?

If so, I see the benefit, but not the benefit to effort ratio. Or putting it 
differently, aren't three addressing modes enough for a system service to have 
to deal with?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Edwards
Sent: Sunday, May 6, 2018 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GETMAIN LOC=32

On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen  wrote:

>Well, if you have to be in 64bit mode anyway, what do you care that BAR
>is unusable? It's not like you are running out of 64bit storage.

I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.

With some minor changes, existing 32-bit
programs can be made to run in AM64 where
they can start accessing LOC=32 memory.

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

[Tony Thigpen]

Me thinks your logic is circular and not worth continuing this discussion.

Tony Thigpen

Paul Edwards wrote on 05/06/2018 06:01 PM:

On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen  wrote:


Well, if you have to be in 64bit mode anyway, what do you care that BAR
is unusable? It's not like you are running out of 64bit storage.


I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.

With some minor changes, existing 32-bit
programs can be made to run in AM64 where
they can start accessing LOC=32 memory.

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

[Paul Edwards]

On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen  wrote:

>Well, if you have to be in 64bit mode anyway, what do you care that BAR
>is unusable? It's not like you are running out of 64bit storage.

I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.

With some minor changes, existing 32-bit
programs can be made to run in AM64 where
they can start accessing LOC=32 memory.

BFN. Paul.

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

Re: DFSMSdss Release command

[Ron hawkins]

Gadi,

While this does not help to release the space on currently empty data sets,
you can mitigate the problem by having allocation assign a DSORG.

Set up your ACS rules to have datasets with an unspecified DSORG drop
through to a DATACLAS with DSORG=PS and the EOF is updated at allocation,
and release to 0 tracks will work on unopened datasets in the future.

Ron



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Gadi Ben-Avi
Sent: Tuesday, May 1, 2018 3:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] DFSMSdss Release command

Hi,
I am trying to create a job that will use the DFSMSdss RELEASE command to
release unused space from a list of datasets.
Can anyone help me?

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

Re: GETMAIN LOC=32

[Tony Thigpen]

Well, if you have to be in 64bit mode anyway, what do you care that BAR 
is unusable? It's not like you are running out of 64bit storage.


Tony Thigpen

Paul Edwards wrote on 05/06/2018 05:29 PM:

On Sun, 6 May 2018 17:10:34 -0400, Tony Thigpen  wrote:


Most of your comments can be addressed simply by:
"But, I do know the current addressing mode."


I'm sorry. I don't understand this comment.


So, unless you are going to add another addressing mode


No new addressing mode is required. AM64 is sufficient
for accessing the LOC=32 memory. I don't understand
why you think a new addressing mode (AM32 presumably)
would help address any of your concerns, even if it existed.

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

[Paul Edwards]

On Sun, 6 May 2018 17:10:34 -0400, Tony Thigpen  wrote:

> Most of your comments can be addressed simply by:
>"But, I do know the current addressing mode."

I'm sorry. I don't understand this comment.

>So, unless you are going to add another addressing mode

No new addressing mode is required. AM64 is sufficient
for accessing the LOC=32 memory. I don't understand
why you think a new addressing mode (AM32 presumably)
would help address any of your concerns, even if it existed.

BFN. Paul.

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

Re: unexpected tape issue with RETAIN

[Ron hawkins]

Tony,

I remember some behavior like this from the days of real tape.

Was the behavior that RETAIN would rewind but not dismount the tape, even at 
the end of the step, and it was AVR that found the tape if an ensuing step 
needed it.

If there was another mount request before the ensuing step went into allocation 
and no empty drives were available, an unallocated drive with tape on it is 
selected for the allocation. RETAIN does not retain the allocation, just the 
tape.

We got around this problem by using the Mount command to keep the tape mounted 
between jobs and jobs steps.

Ron



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Sunday, May 6, 2018 12:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] unexpected tape issue with RETAIN

Swaps?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: 04 May 2018 17:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: unexpected tape issue with RETAIN

I currently think it has to do with a combination of a faulty tape and a 
mis-configuration in the IODEF, and a testing environment.

Normally, this CPU has no powered-up real tape drives, just a VTL. For some 
testing of new back-up procedures, they wanted me to use a real
3590 so as to not add a bunch of data to the VTL that would then have to be 
replicated.

So, I powered-up and varied on some tape drives. The IODEF thinks they have 
auto-loaders, but they do not. So, I have get a configuration error when I run 
the job on just the first file.

And, since we don't have a lot of spare real 3590 tapes, I have been using the 
same two tapes repeatedly.

I have noticed that the errors only occur on one of the tapes. I think the 
recovery process wants to re-index the tape position but without the 
autoloader, it is failing then the operating system is switching to a new drive.

Tony Thigpen

Lizette Koehler wrote on 05/04/2018 06:12 PM:
> I am not sure if this was covered,
>
> But would the combination of
>
> VOL=REF=*  and DISP=(,PASS) not work at keeping the tape up?
>
> Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Tony Thigpen
>> Sent: Friday, May 04, 2018 1:32 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: unexpected tape issue with RETAIN
>>
>> No go. Unit=Aff is only applicable within the same job step.
>>
>> Tony Thigpen
>>
>> Chris Hoelscher wrote on 05/04/2018 04:05 PM:
>>> Unit=aff=step.ddname  ???
>>>
>>> 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 Tony Thigpen
>>> Sent: Friday, May 4, 2018 3:35 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: [IBM-MAIN] unexpected tape issue with RETAIN
>>>
>>> I have a 50+ step backup job (using real 3590s) that has steps like:
>>>
>>> //STEP049 EXEC PGM=ADRDSSU
>>> //SYSPRINT DD  SYSOUT=*
>>> //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
>>> //BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
>>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
>>> // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
>>> //SYSINDD  *
>>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>>> /*
>>> //*
>>> //STEP050 EXEC PGM=ADRDSSU
>>> //SYSPRINT DD  SYSOUT=*
>>> //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
>>> //BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
>>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
>>> // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
>>> //SYSINDD  *
>>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>>> /*
>>>
>>> This job always worked on OS/390 2.10, but under z/OS 1.13, 
>>> randomly, when
>> going to a new step, it wants the current tape mounted on a different 3590.
>> Additionally, it does not unload the tape from the first drive.
>>>
>>> Also: If I have only one drive online, it runs to completion. If I 
>>> have two
>> drives, but the other one is busy, it runs to completion.
>>>
>>> Info: This system is using RMM as a tape manager, but the files 
>>> being
>> created on the tape are not defined in any storage group or RMM.
>>>
>>> It is driving me batty. I have to be 'not seeing' something.
>>>
>>>
>>> --
>>> Tony Thigpen
>>>
>
> --
> 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 

Re: GETMAIN LOC=32

[Tony Thigpen]

Most of your comments can be addressed simply by:
"But, I do know the current addressing mode."

So, unless you are going to add another addressing mode

Tony Thigpen

Paul Edwards wrote on 05/06/2018 04:00 PM:

On Sun, 6 May 2018 15:45:31 -0400, Tony Thigpen  wrote:


Just for starters.

1) I am looking at the registers at abend. Is it a 31 bit address with
the high-bit on, or is it a 32 bit address?


If you don't want to debug 32-bit programs
that have 4 GiB of memory available to them,
then simply don't code it. There's no reason
to stop other people from using the full 4 GiB.

You also can't tell whether an address is 31-bit
or a 24-bit address with crud in the top 8 bits.
That's no reason for the 24-bit bar from being
there for eternity.


2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an
address that is in that area to a subprogram that is not 32bit. Oops.


Same as calling an AM24 subroutine from an
AM31 caller. No reason to stick with AM24
for eternity.


3) I am looking at a parameter list with 4 parms. The 2nd and the 4th
have the high-bit on. Is the 2nd parm the last parm or is not but
instead it is a 32 bit address and the 4th parm the last parm?


If you don't want to be confused by parameter
lists then simply never use LOC=32 addresses
in the parameter lists. Use LOC=32 memory
for internal use only.


I am a vendor that writes system software that is called by application
programmers. I am not sure how I would validate that a 32 bit address
was 32 bit and not 31 bit. Or, the reverse.


You can't differentiate between an AM24 or AM31
address either. It is up to the caller to provide
data in the expected AMODE.


IBM has the same problem when somebody calls their services. That is why
the BAR exists.


IBM services that can't accept an AM64 caller
are already documented as such.

As far as I can tell, the BAR exists for the same
reasons that 16 MiB LINE exists - historical
curiosity. 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.

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

[Paul Edwards]

On Sun, 6 May 2018 15:45:31 -0400, Tony Thigpen  wrote:

>Just for starters.
>
>1) I am looking at the registers at abend. Is it a 31 bit address with
>the high-bit on, or is it a 32 bit address?

If you don't want to debug 32-bit programs
that have 4 GiB of memory available to them,
then simply don't code it. There's no reason
to stop other people from using the full 4 GiB.

You also can't tell whether an address is 31-bit
or a 24-bit address with crud in the top 8 bits.
That's no reason for the 24-bit bar from being
there for eternity.

>2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an
>address that is in that area to a subprogram that is not 32bit. Oops.

Same as calling an AM24 subroutine from an
AM31 caller. No reason to stick with AM24
for eternity.

>3) I am looking at a parameter list with 4 parms. The 2nd and the 4th
>have the high-bit on. Is the 2nd parm the last parm or is not but
>instead it is a 32 bit address and the 4th parm the last parm?

If you don't want to be confused by parameter
lists then simply never use LOC=32 addresses
in the parameter lists. Use LOC=32 memory
for internal use only.

>I am a vendor that writes system software that is called by application
>programmers. I am not sure how I would validate that a 32 bit address
>was 32 bit and not 31 bit. Or, the reverse.

You can't differentiate between an AM24 or AM31
address either. It is up to the caller to provide
data in the expected AMODE.

>IBM has the same problem when somebody calls their services. That is why
>the BAR exists.

IBM services that can't accept an AM64 caller
are already documented as such.

As far as I can tell, the BAR exists for the same
reasons that 16 MiB LINE exists - historical
curiosity. 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.

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

[Tony Thigpen]

Just for starters.

1) I am looking at the registers at abend. Is it a 31 bit address with 
the high-bit on, or is it a 32 bit address?
2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an 
address that is in that area to a subprogram that is not 32bit. Oops.
3) I am looking at a parameter list with 4 parms. The 2nd and the 4th 
have the high-bit on. Is the 2nd parm the last parm or is not but 
instead it is a 32 bit address and the 4th parm the last parm?


I am a vendor that writes system software that is called by application 
programmers. I am not sure how I would validate that a 32 bit address 
was 32 bit and not 31 bit. Or, the reverse.


IBM has the same problem when somebody calls their services. That is why 
the BAR exists.


Tony Thigpen

Paul Edwards wrote on 05/06/2018 03:30 PM:

Who is disadvantaged by making memory above
2 GiB available to anyone who specifically requests it?

BFN. Paul.




On Sun, 6 May 2018 15:23:38 -0400, Tony Thigpen  wrote:


Bad idea. The 31bit bar is there for a very, very good reason.

Tony Thigpen

Paul Edwards wrote on 05/06/2018 02:51 PM:

Hi. I would like to submit an RFE to IBM to
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. IBM can use 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

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.

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.

After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?

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


--
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: IEFA107I when pointing to dataset alias

[Seymour J Metz]

That may have been cool long ago in a galaxy far away, but after the advent of 
static system symbols it became unnecessary complexity. Not worth getting rid 
of if you're already doing it, but it's not the way to go for a new data center.


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


From: IBM Mainframe Discussion List  on behalf of Dan 
D 
Sent: Saturday, May 5, 2018 11:01 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: IEFA107I when pointing to dataset alias

A very long time ago (over 30 years ago) I worked for a service bureau.\
They had specific naming standards for their libraries when products were 
installed (ie. SYSx.product.V01R03.LOADLIB).

We couldn't have our customers continually changing JCL unless they wanted a 
different version than what was installed so we created a system tool called 
"Virtual Dataset Names".

This worked very similar to how ALIAS names works although there was no "must 
be in the same catalog" restriction.

When the system was IPL'd (or later via a special operator command) a table was 
loaded into CSA that contained the REAL dataset name, the VIRTUAL name and the 
various versions that were available.  One of the versions was marked as the 
default.
We used the IGG026DU catalog front-end exit (which I believe is now used by 
DFSMSHSM) to intercept catalog lookups and replace the REAL name that is being 
located with the VIRTUAL name.  It would scan SWA and check if an ACCT= was 
specified on the EXEC statement.  If so, the 1st operand was used to overriding 
VERION for all datasets within that step.
Example:
 //step50 exec pgm=iefbr15,ACCT=V5R3
 //DD1dd  dsn=sys1.sortlib,disp=shr
If SYS1.SORTLIB is in the table and it's virtual name is PROD.?.SORTLIB and it 
had a list of versions, V1R0 being the alias, DD1 would be translated to 
PROD.V5R3.SORTLIB as ACCT=V5R3 was specified.  If it wasn't DD1 would be 
PROD.V1R0.SORTLIB.

Our customers loved this as they could test NEW versions of products before 
they became the default.

If someone has the time, maybe they could take on this project and re-write 
this cool tool ;-)

Dan

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

[Paul Edwards]

Who is disadvantaged by making memory above
2 GiB available to anyone who specifically requests it?

BFN. Paul.




On Sun, 6 May 2018 15:23:38 -0400, Tony Thigpen  wrote:

>Bad idea. The 31bit bar is there for a very, very good reason.
>
>Tony Thigpen
>
>Paul Edwards wrote on 05/06/2018 02:51 PM:
>> Hi. I would like to submit an RFE to IBM to
>> 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. IBM can use 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
>>
>> 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.
>>
>> 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.
>>
>> After I submit the RFE it would be good if people
>> could upvote it. What is the best wording I can
>> use so that IBM understands what I am asking
>> for and doesn't reject it?
>>
>> 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

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

[Tony Thigpen]

Bad idea. The 31bit bar is there for a very, very good reason.

Tony Thigpen

Paul Edwards wrote on 05/06/2018 02:51 PM:

Hi. I would like to submit an RFE to IBM to
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. IBM can use 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

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.

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.

After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?

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

GETMAIN LOC=32

[Paul Edwards]

Hi. I would like to submit an RFE to IBM to
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. IBM can use 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

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.

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.

After I submit the RFE it would be good if people
could upvote it. What is the best wording I can
use so that IBM understands what I am asking
for and doesn't reject it?

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

[Lizette Koehler]

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


What options are there?

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

Do you have any automation software like CA OPS/MVS or IBM TIVOLI?  Basically 
you will be building and maintaining a process that many vendor software has 
already done.

For example on the CBTTAPE.ORG you could search for MES (short for message) and 
find file 597

IST123I,USEREXIT(MPFCMDS)   

When message IST123I occurs, standard MVS MPF processing will invoke the 
MPFCMDS exit. MPFCMDS extracts the message id from the first 8 bytes of the 
message text and then executes the procedure MPFCMDS with the parameter 
MEMBER=IST123I. This procedure executes COMMAND (found at CBT file 088) and 
uses as input the member IST123I from YOUR.CMDS.PDS.  Having found this member, 
COMMAND reads each line and, if it is not a comment (an asterisk in column 1), 
issues the command as supplied.  

LIMITATIONS 

Message numbers are restricted to a maximum of 8 bytes (length of a PDS member 
name).  No code has been implemented to handle longer messages.  The commands 
than can be used in the input member is limited by the program "COMMAND". For 
details, have a look at member $COMMAND.  This program could also be 
substituted with another command-processor.  (Just update procedure MPFCMDS for 
this).


This will provide a basic MPF exit where you can trap the message, then perform 
some function.  I do not think this is trivial.

You could also look at SYSTEM REXX for a possible solution.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> venkat kulkarni
> Sent: Sunday, May 06, 2018 4:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Job submit using REXX
> 
> Hello Group,
> 
> 
> We have requirement of setting up process of handling  FTP and then submit
> Job with FTP dataset. The process goes like this,
> 
> 
> 
> a) We use DCON for communication purpose and receive files in our local z/OS
> system in GDG format from remote site
> 
> b) once we receive this file, operator put this file name in our Job and
> process it further.
> 
> 
> 
> 
> 
> As per  below messages, FTP.DATA.** are the files, which are saved in our
> system and these files are placed into JCL for further process by operator.
> 
> 
> 
> 
> 
> i)
> 
> SVTM052I STEP01   COPY FDDB4142(  95,456)
> 
> SVTM052I  FROM E2PP.DW801P.WTALZUP.XM.G0520V00
> 
> SVTM052I  TO   FTP.DATA.ATRAIL.G0458V00
> 
> SVTM052I  COMPLETED  /SCPA000I
> 
> 
> 
> 
> 
> ii)
> 
> SVTM052I STEP01   COPY FDDB4099(  95,458)
> 
> SVTM052I  FROM G12P.DW801P.XTALZUP.XM.G1557V00
> 
> SVTM052I  TO   FTP.DATA.AUDIT.TRAIL.G1568V00
> 
> SVTM052I  COMPLETED  /SCPA000I
> 
> 
> 
> iii)
> 
> SVTM052I STEP01   COPY FDDB4052(  95,516)
> 
> SVTM052I  FROM G12P.IBD003.X2BSN1.XM.G2904V00
> 
> SVTM052I  TO   FTP.DATA.IAS.G3486V00
> 
> 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.
> 
> 
> 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.

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

[venkat kulkarni]

Hello Lizette,

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.

On Sat, May 5, 2018 at 8:14 PM, Lizette Koehler 
wrote:

> First,  the manuals should tell you how to set up Netview and log on
>
> What have you done so far.  What steps have you executed in setting up
> Netview?
>
> What version of Netview are you installing?  What version of z/OS?
>
>
> Post any error messages you are receiving when you attempt to logon?
>
> Do you have the started task running?  Are there any error messages in the
> STC?
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > saurabh khandelwal
> > Sent: Saturday, May 05, 2018 6:53 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Netview Login issue
> >
> > Hello Group,
> >
> > We recently installed netview but i am unable to login. Can you please
> help
> > in setting up vtam, so that i can login to netview.
> >
>
> --
> 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: unexpected tape issue with RETAIN

[Allan Staller]

Swaps?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: 04 May 2018 17:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: unexpected tape issue with RETAIN

I currently think it has to do with a combination of a faulty tape and a 
mis-configuration in the IODEF, and a testing environment.

Normally, this CPU has no powered-up real tape drives, just a VTL. For some 
testing of new back-up procedures, they wanted me to use a real
3590 so as to not add a bunch of data to the VTL that would then have to be 
replicated.

So, I powered-up and varied on some tape drives. The IODEF thinks they have 
auto-loaders, but they do not. So, I have get a configuration error when I run 
the job on just the first file.

And, since we don't have a lot of spare real 3590 tapes, I have been using the 
same two tapes repeatedly.

I have noticed that the errors only occur on one of the tapes. I think the 
recovery process wants to re-index the tape position but without the 
autoloader, it is failing then the operating system is switching to a new drive.

Tony Thigpen

Lizette Koehler wrote on 05/04/2018 06:12 PM:
> I am not sure if this was covered,
>
> But would the combination of
>
> VOL=REF=*  and DISP=(,PASS) not work at keeping the tape up?
>
> Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Tony Thigpen
>> Sent: Friday, May 04, 2018 1:32 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: unexpected tape issue with RETAIN
>>
>> No go. Unit=Aff is only applicable within the same job step.
>>
>> Tony Thigpen
>>
>> Chris Hoelscher wrote on 05/04/2018 04:05 PM:
>>> Unit=aff=step.ddname  ???
>>>
>>> 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 Tony Thigpen
>>> Sent: Friday, May 4, 2018 3:35 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: [IBM-MAIN] unexpected tape issue with RETAIN
>>>
>>> I have a 50+ step backup job (using real 3590s) that has steps like:
>>>
>>> //STEP049 EXEC PGM=ADRDSSU
>>> //SYSPRINT DD  SYSOUT=*
>>> //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
>>> //BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
>>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
>>> // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
>>> //SYSINDD  *
>>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>>> /*
>>> //*
>>> //STEP050 EXEC PGM=ADRDSSU
>>> //SYSPRINT DD  SYSOUT=*
>>> //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
>>> //BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
>>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
>>> // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
>>> //SYSINDD  *
>>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>>> /*
>>>
>>> This job always worked on OS/390 2.10, but under z/OS 1.13,
>>> randomly, when
>> going to a new step, it wants the current tape mounted on a different 3590.
>> Additionally, it does not unload the tape from the first drive.
>>>
>>> Also: If I have only one drive online, it runs to completion. If I
>>> have two
>> drives, but the other one is busy, it runs to completion.
>>>
>>> Info: This system is using RMM as a tape manager, but the files
>>> being
>> created on the tape are not defined in any storage group or RMM.
>>>
>>> It is driving me batty. I have to be 'not seeing' something.
>>>
>>>
>>> --
>>> Tony Thigpen
>>>
>
> --
> 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::
--
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