Re: Where are the device codes (returned by LOCATE) defined?

[Stephen Mednick]

 

> 
> Another point to note is that ABR sets the high-order bit on 
> in the DSCB CCHHR field of the catalog entry when the data 
> set is archived and the original volume serial is retained.
> 

No quite correct. ABR records in the field DSCBTTR a pointer
to the entry in ABR's Archive Control File. This helps to avoid
lengthy searches thru the ACF.


> I do not know if this bit setting occurs or not when the 
> volume serial of MIGRAT is used.

The entry is used to support ABR's Auto-Recall via the
ABR Locate Exit. ABR requires the use of the volser MIGRAT
when migrating datasets off SMS Managed volumes.


> 
> I believe that the usual restriction of "VTOCs must be in the 
> first 64K cylinders of a volume" must therefore become "VTOCs 
> must be in the first 32K cylinders of a volume" when ABR 
> (without MIGRAT at least) is used to archive data sets.
> 
> I would guess that all volumes had less than one thousand 
> cylinders when this logic was devised.
> 

No such restriction exists!!!



Stephen Mednick
Computer Supervisory Services
Sydney, Australia
 
Asia/Pacific representatives for
Innovation Data Processing, Inc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Power Capacity Planning (was Slightly off topic power limits)

[Steele, Phil]

Getting back to the comment about the proliferation of ( usually wintel)
single application servers. In my experience, this occurred because
different business units liked having and controlling their own
server(s), and individually each little server was not very power hungry
anyway. Not like that great big  9672 (!!!). 
All of a sudden we have no mainframe and 250+ wintel servers... ( and,
indeed!  no business unit beholding to any other).
Sounds a bit like all of the other centralised vs de-centralised
support/cost issues. 

I remember when we went CMOS, then RAMAC and Magstar, our power
consumption went through the floor.  But now look at us !!! Our data
centre is hotter and greedier than it has ever been. (by far!) (and our
cpu utilisation is about 5% if it's lucky.).

VMWARE , I suspect, *might* reduce things to being only 10 times worse,
as distinct from the 20 times as bad we are now.   


Philip Steele  ( die before I said I miss z/VM)



***
The information in this e-mail message and any files transmitted with it are 
intended to be confidential and for the use of only the individual or entity to 
whom they are addressed. The message and files may be protected by legal 
professional privilege, or other legal rules. The confidentiality of and 
privilege applying to this message and files is not waived if this message or 
files has been sent to you by mistake. If the reader of this message or files 
is not the intended recipient, you are notified that retention, distribution or 
copying of this message and files are strictly prohibited.  If you receive this 
message or files in error, please notify us immediately by telephone or return 
e-mail and delete all copies from your computer system. It is the recipient's 
responsibility to check this message and files for viruses.
Thank you.
***

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

AUTO: Andrew Bates is away from the Shanghai office on business travel - details in mail (returning 04/05/2009)

[Andrew Bates]

I am out of the office until 04/05/2009.

I am travelling on business until 4th May.  I will try to respond to mails
dureing breaks on in evenings.


Note: This is an automated response to your message IBM-MAIN Digest - 26
Apr 2009 to 27 Apr 2009 (#2009-117) sent on 4/28/09 12:00:03.
This is the only notification you will receive while this person is away.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Greg Price]

Tom Marchant wrote:
> On Mon, 27 Apr 2009 09:59:51 +0300, Binyamin Dissen wrote:
>> Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?
> 
> FDR does.  Actually, it's ABR.  ISTR that this behavior is optional, but I
> don't recall what is in the VOLSER if the option is not selected.  The
> original VOLSER perhaps.
> 

Another point to note is that ABR sets the high-order bit on in the
DSCB CCHHR field of the catalog entry when the data set is archived
and the original volume serial is retained.

I do not know if this bit setting occurs or not when the volume serial
of MIGRAT is used.

I believe that the usual restriction of "VTOCs must be in the first 64K
cylinders of a volume" must therefore become "VTOCs must be in the
first 32K cylinders of a volume" when ABR (without MIGRAT at least)
is used to archive data sets.

I would guess that all volumes had less than one thousand cylinders
when this logic was devised.

Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Tony B.]

No and no.  Protecting ADRDSSSU is nonsense.
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Monday, April 27, 2009 7:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Using FTP to send loadlib

On Mon, 27 Apr 2009 23:56:34 +, Ted MacNEIL wrote:
>
>I've never worked at a shop where IEBCOPY is protected, nor would I
understand the reason why.
>
>ADRDSSU at least makes sense.
>
How?

Does ADRDSSU allow a programmer to dump data sets lacking READ access, or to
dump a volume containing data sets to which the programmer lacks read
access?

If so, ADRDSSU sorely needs repair, perhaps by restricting the volume dump
function and by preforming SAF checks for data set dumps.  But a blanket
restriction of all ADRDSSU function makes no sense.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.12.4/2082 - Release Date: 04/27/09
06:19:00

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCOMM 5.x Question

[Field, Alan C.]

Answering my own question:

I edited my .WS file and changed packet size from 32760 to 65536 and I
was able to successfully transfer the file. Thanks Roger Bolan for the
ideas.

[Transfer]
DefaultDirectory=C:\TEMP
PacketSize=65536
PCCodePage=1252 


>I can receive (to the PC) OK, but since changing the screen size sends
>are failing e.g.
>
>C:\temp>send show719.xmi show719.xmit recfm(f) lrecl(80)
> 
> The file transfer request is being processed.
> Number of bytes transferred :   32743
> TRANS13   Error writing file to host: file transfer canceled

 


 

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Paul Gilmartin]

On Mon, 27 Apr 2009 23:56:34 +, Ted MacNEIL wrote:
>
>I've never worked at a shop where IEBCOPY is protected, nor would I understand 
>the reason why.
>
>ADRDSSU at least makes sense.
>
How?

Does ADRDSSU allow a programmer to dump data sets lacking
READ access, or to dump a volume containing data sets to
which the programmer lacks read access?

If so, ADRDSSU sorely needs repair, perhaps by restricting
the volume dump function and by preforming SAF checks for
data set dumps.  But a blanket restriction of all ADRDSSU
function makes no sense.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Power Capacity Planning (was Slightly off topic power limits)

[Paul Gilmartin]

On Tue, 28 Apr 2009 00:01:21 +, Ted MacNEIL wrote:

>>If it comes down to not being able to use a small amount more of power, that 
>>shows poor planning.
>
>Yes, but you're talking ideal world.
>
>> Either because the power company didn't build more capacity, or because the 
>> groups regulating new power plants make it impossible.  I don't think 
>> business should be limited because of artificial limits.
>
>Okay. You don't think it's right.
>But, what do you do now that it's real?
>
>>Business should be encouraged to do everything possible to limit power 
>>growth.  Just raising electricity rates goes a long way to accomplishing that.
>
>Yes, but?
>
Note that the same concerns apply to water as to power,
and have applied for a longer time.

See: "Tragedy of the Commons".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Power Capacity Planning (was Slightly off topic power limits)

[Ted MacNEIL]

>If it comes down to not being able to use a small amount more of power, that 
>shows poor planning.

Yes, but you're talking ideal world.

> Either because the power company didn't build more capacity, or because the 
> groups regulating new power plants make it impossible.  I don't think 
> business should be limited because of artificial limits.

Okay. You don't think it's right.
But, what do you do now that it's real?



>Business should be encouraged to do everything possible to limit power growth. 
> Just raising electricity rates goes a long way to 
accomplishing that.

Yes, but?


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Ted MacNEIL]

>IEBCOPY may be protected as easily as ADRDSSU and it makes about as much sense.

I've never worked at a shop where IEBCOPY is protected, nor would I understand 
the reason why.

ADRDSSU at least makes sense.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MAXBACKUPTASKS(1) using 2 drives

[Vinson Lee]

The query shows there is only 1 active backup task.  We think we've figured 
out what is happening.  We have INUSE(RETRY(Y) DELAY(0) SERIALIZATION
(PREFERRED) coded so HSM was allocating a second drive to back up datasets 
that were in use after the initial backup task completed.

The other problem we've discovered is the second tape is not marked full.  
Only the first tape is marked full.

Thanks for everyone's input.

Vince

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

[Paul Gilmartin]

On Mon, 27 Apr 2009 18:10:42 -0400, Farley, Peter x23353 wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of Schwarz, Barry A
>>
>> IEBCOPY may be protected as easily as ADRDSSU and it makes about as much
>> sense.
>
>Agreed, but in many places it still is "protected" from "normal" people
>like application programmers, for whatever historical or political
>reason(s) there may be or may have been, and it is what it is.  You
>learn to do without because there are more important battles to be
>waged.
>
What I find onerous is that ADRDSSU requires that when extracting
and renaming a data set the programmer must have read access to
the original data set name.  This considerably degrades the
usefulness of ADRDSSU as an interchange vehicle.  I believe I
understand the reason for the restriction, but it could have been
done in a better way.  Particularly, I'd reframe the restriction
as "the programmer must have read access to either the original
data set name or to the archive data set."  The stricter rule
provides little additional protection, insofar as a determined
hacker with read access to the archive could copy the archive
and change the the names in the copy in order to circumvent the
protection.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Power Capacity Planning (was Slightly off topic power limits)

[Eric Bielefeld]

If it comes down to not being able to use a small amount more of power, that 
shows poor planning.  Either because the power company didn't build more 
capacity, or because the groups regulating new power plants make it 
impossible.  I don't think business should be limited because of artificial 
limits.  Business should be encouraged to do everything possible to limit 
power growth.  Just raising electricity rates goes a long way to 
accomplishing that.


Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Ted MacNEIL" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, April 27, 2009 2:55 PM
Subject: Re: Power Capacity Planning (was Slightly off topic power limits)


What happens if the government/power company doesn't 'cap' power 
consumption, the data centre uses 'too much' and the grid blows?

At least, this way, you can manage it without going belly-up.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

ADRDSSU protection [was:RE: Using FTP to send loadlib]

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Schwarz, Barry A
> Sent: Monday, April 27, 2009 5:49 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Using FTP to send loadlib
> 
> IEBCOPY may be protected as easily as ADRDSSU and it makes about as
much
> sense.

Agreed, but in many places it still is "protected" from "normal" people
like application programmers, for whatever historical or political
reason(s) there may be or may have been, and it is what it is.  You
learn to do without because there are more important battles to be
waged.

Peter


This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: APPN Connection z/os - AHHC / LLC2.

[Norbert Alfred Müller]

Chris,

There is no Netview installed. Is only two smalls z/OS 1.5 for testing, running 
under VM.
MAXDATA is not showed in subarea connections, nor in ANNC. 
I install Token Ring adapters in my IBM 7060. And, of course, works!
Maxdata was 4442. 
Then, I IPL the system in a 2096. In the z/9, we have of course OSA Adapters, no
this Emulated I/O from the 7060. MAXDATA was..1516, not 1498 !
And again, the same results as with 1498. Dead. 

So, the problem is: 
APPN, only ETHERNET, only Switched connection.
Subarea, ANNC, Token Ring, works.

I tested also with VM, but I have an old VM VTAM and I have the problem (solved 
in APAR VM63436) , " PROBLEM DESCRIPTION: XCA connection INOPs when using 
Ethernet connection"
mmm... very similar to our problem in z/OS.  Look at :
http://www-01.ibm.com/support/docview.wss?uid=swg1VM63436 or in the related 
z/OS APAR info.
In VM/VTAM, the session after a fullscreen data  does not
hang, it disconnect with an INOP. I will install the PTF tomorrow.

My question is: how calculates VTAM the MAXDATA ? why this 18 Bytes difference 
between the 
7060 and the OSA Adapter ?
Well, It make no sense playing around the z/OS 1.5 for testing. I will test in 
the 
operating environment planned: z/OS 1.10 connected with VSE 4.2. And then will 
see of the problem
occurs or is solved ! I keep you informed. 
For me is very important to confirm that the configuration was ok!I guess is it 
? :-)
Many thanks for your support !
Norbert.


> Norbert
> 
> > ... also with 16384.
> 
> Testing with D NET,APING at sizes larger than 1920 doesn't show us anything 
> new regarding the *size* of data units since 1920 is the request unit size 
> imposed by the RUSIZES operand of the MODEENT macro used to generate 
> the #INTER mode table entry which is the default and, I assume, the one you 
> are using. It does, however, show us that sending more than one frame at a 
> time can be successful.
> 
> It looks like we need tracing. The cleanest way to "see" session traffic is 
> to 
> use NLDM with the CPIU option but, since you have not responded to my 
> suggestion you use this, I assume you have not installed NetView or, if you 
> have, you have not enabled Session Monitor.
> 
> You need to trace the traffic when the TSO session hangs so that we can see 
> the last data sent by TSO that does not get delivered. Wireshark could be 
> handy in showing what flows on the LAN I believe - I have never actually used 
> it. It may be useful, at the same time to use a VTAM buffer trace so that we 
> can see whether something that has passed over the VTAM API from TSO 
> actually appears as an Ethernet frame.
> 
> As a comparison, you could do the same, that is, a VTAM buffer trace and 
> running Wireshark, with D NET,APING,SIZE=1920,ITER=1. (ITER=1 for the least 
> amount of data to trace.)
> 
> Wireshark shows all the protocol headers (and trailers) I believe. I will be 
> interested to see how the 802.2 protocol fields are supported with a Basic 
> Transmission Unit size of 1498.
> 
> Have you had any success with looking for the "MAXDATA" value with other 
> types of "cross-domain" connections?
> 
> Chris Mason
> 
> On Mon, 27 Apr 2009 09:59:51 +0200, Norbert Alfred Müller 
>  wrote:
> 
> >Hi Chris!
> >
> >tests are ongoing  , but here some results:
> >
> >- I read in the manual about MAXDATA in a node 2.1. AND I tested, also. 
> Without results: MAXDATA is always 1498 :-(
> >- D NET,APING,  works with all sizes, also with 16384.
> >- If MAXDATA 1498 is an absolute NO, the question is: how is getting VTAM 
> this size ? from Network definition ? or is the size correct and the display 
> no ?
> >What do you thing about a trace with wireshark ?
> >
> >
> >Regards,
> >Norbert.
> >
> >
> >> Von: "Chris Mason" 
> >> Gesendet: 26.04.09 13:34:02
> >> An: IBM-MAIN@BAMA.UA.EDU
> >> Betreff: Re: APPN Connection z/os - AHHC / LLC2.
> >
> >
> >> Norbert
> >>
> >> Thanks for the information.
> >>
> >> I misunderstood what you meant by "before the whole screen comes". This
> >> implied that you session stopped for a while and then continued. Perhaps 
> you
> >> should have said "before the whole screen would have come, if it had
> >> continued working". So it really is a permanent "hang".
> >>
> >> The evidence is building up that the reported "MAXDATA" value is wrong so
> >> you were right to suspect it. With a BTU size of 1498, there's no room for 
> the
> >> 802.2 connection-oriented LLC header inside the old Ethernet limit of 
> >> 1500. 
> It
> >> then makes sense that the first large request unit is going to need 
> segmenting
> >> and that the segment worked out as a BTU size of 1498 will be dropped by 
> the
> >> Ethernet adapter resulting in a hang.
> >>
> >> When support for LANs was introduced for subarea connections, 
> segmenting
> >> was introduced also for subarea links - previously it had been used only 
> >> for
> >> peripheral links. Is there DISPLAY command output which shows a 
> MAXDATA
> >> value for th

Re: Using FTP to send loadlib

[Schwarz, Barry A]

IEBCOPY may be protected as easily as ADRDSSU and it makes about as much
sense.

-Original Message-
From: Ted MacNEIL [mailto:eamacn...@yahoo.ca] 
Sent: Monday, April 27, 2009 1:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Using FTP to send loadlib

>The challenge with XMIT/UNLOAD is that you have to run tso in batch to
reconstitute it.  I prefer in these situations to use IEBCOPY
unload/load.

A matter of taste.
TSO in Batch?
IEBCOPY in Batch?
Does it matter?

The issue is anybody can use these.

ADDRSSU may be protected.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCOMM 5.x Question

[Dave Salt]

> From: eamacn...@yahoo.ca
> Consider FTP.
> There are (too) many limitations to IND$FILE.

Also consider the ISPF workstation agent (WSA.EXE). IMO, it's much easier to 
use than both IND$FILE and FTP. 

Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
 

 
_
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Question

[Dave Salt]

>>To go to any function in ISPF you usually issue =2 or =3.4 and so forth.

> From: eamacn...@yahoo.ca
> But, there's a new function with 1.10, that makes it even easier.
> IE: You don't always have to remember the option numbers.

Do you mean the SWAPBAR? If so, you still have to remember the option numbers 
in order to originally get to the options you want. The SWAPBAR only makes it 
easier to swap back to them later during the session.


Dave Salt

SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
_
Internet Explorer 8 helps keep your personal info safe.
http://go.microsoft.com/?linkid=9655581

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCOMM 5.x Question

[Roger Bolan]

I have a similar problem.  I use PCOMM and when I upload/download with PCOMM
I normally have my host window on the ISPF option 6 screen.This works
with no problem as long as I'm using one of the standard sizes for my
terminal session.  If I use a custom size, then it fails from ISPF option 6
with the same error as you.  But if I leave ISPF, and do the transfer while
on the TSO READY prompt, then it works from any of my screen sizes.

I ran into this same problem years ago, and there was a fix for it.  I
talked to the MVS system programmer.  Unfortunately, I can't remember if the
fix back then was something he told me to do in my *.ws files, or if it was
something he changed on the host system (LOGMODE???).
I do *think* it was in the .ws files, but that was several workstations ago,
and whatever I changed has been lost.  So now I either do my transfers from
the TSO READY screen, or from ISPF option 6 using only a standard size
session.

--Roger

On Mon, Apr 27, 2009 at 2:03 PM, Field, Alan C.
wrote:

> After reading all the discussion on IBM-MAIN I finally configured my
> PCOMM screen to be 48 x 142.
>
>
>
> I like to use IND$FILE from a DOS/CMD prompt to send and receive data.
>
>
>
> I can receive (to the PC) OK, but since changing the screen size sends
> are failing e.g.
>
>
>
> C:\temp>send show719.xmi show719.xmit recfm(f) lrecl(80)
>
>
>
>  The file transfer request is being processed.
>
>  Number of bytes transferred :   32743
>
>  TRANS13   Error writing file to host: file transfer canceled
>
>
>
> They all stop at 32743. Smaller files transfer OK.
>
>
>
> I then curse and log on to a 24 x 80 session and send the file
> successfully.
>
>
>
> I suspect I need a tweak in the .WS file but so far I haven't found it.
>
>
>
>
> Alan
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCOMM 5.x Question

[Ted MacNEIL]

>I like to use IND$FILE from a DOS/CMD prompt to send and receive data. 


Consider FTP.
There are (too) many limitations to IND$FILE.
This includes a max file size.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The PUT FTP not working with large files

[Bob Rutledge]

This is actually PK65405.  We ran into it as well.

Bob


Coincidentally, I was chasing up exactly the same symptom just last week and
came up with APAR PK71695...could be relevant (and has a testable workaround):

  ERROR DESCRIPTION:
  The DATACTTIME for the FTP client is not being set properly
  for send processing.  The result is the timer is not set and
  thus will never expire.
 
  ADDTIONAL SYMPTOMS: FTP client session terminate

  abruptly after the first EZA1485I message is issued
  with the following message:
  EZA2590E send error from send_data - EDC5120I Interrupted
  function call. (errno2=0x76690291).
 
  FTP Client receives EZA2590E only when TRACE is enabled. When

  tracing is disabled, problem does not occur.
 
 
  LOCAL FIX:

  Set DATACTTIME to 0.  This disbles the data connection timer.
  or
  Set PROGRESS to 0.  This disables the progress message.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Ted MacNEIL]

>===> [tso] receive inda(dsn)

>(don't need the "tso" if your at ISPF 6; otherwise you do, while under ISPF)

You've missed the point.
The original intent was to do it under batch.
Interactive doesn't cut it!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Steve Comstock]

Lionel B Dyck wrote:
The challenge with XMIT/UNLOAD is that you have to run tso in batch to 
reconstitute it. 


Huh?

===> [tso] receive inda(dsn)

(don't need the "tso" if your at ISPF 6; otherwise you do,
while under ISPF)



 I prefer in these situations to use IEBCOPY unload/load.


Lionel B. Dyck, Consultant/Specialist 
?Never attribute to malice what can be caused by miscommunication.? 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 




From:
Ted MacNEIL 
To:
IBM-MAIN@bama.ua.edu
Date:
04/27/2009 12:53 PM
Subject:
Re: Using FTP to send loadlib
Sent by:
IBM Mainframe Discussion List 



there is a way to directly send individual loadlib members but to send a 

whole loadlib you really should dump it first using the  ADDRSSU utility.

1. ADDRSSU is protected at many sites.
2. XMIT/UNLOAD (OUTFILE) is easier.


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Check out the Trainer's Friend Store to purchase z/OS  <==
==> application developer toolkits. Sample code in four<==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==>   http://www.trainersfriend.com/TTFStore/index.html<==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Using FTP to send LOADLIB

[Kurt Eastwood]

All,
 
Thank you all for the suggestions, I have plenty of options to try now.
 
Kurt
 




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Ted MacNEIL]

>The challenge with XMIT/UNLOAD is that you have to run tso in batch to 
>reconstitute it.  I prefer in these situations to use IEBCOPY unload/load.

A matter of taste.
TSO in Batch?
IEBCOPY in Batch?
Does it matter?

The issue is anybody can use these.

ADDRSSU may be protected.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

PCOMM 5.x Question

[Field, Alan C.]

After reading all the discussion on IBM-MAIN I finally configured my
PCOMM screen to be 48 x 142.

 

I like to use IND$FILE from a DOS/CMD prompt to send and receive data. 

 

I can receive (to the PC) OK, but since changing the screen size sends
are failing e.g.

 

C:\temp>send show719.xmi show719.xmit recfm(f) lrecl(80)

 

 The file transfer request is being processed.

 Number of bytes transferred :   32743

 TRANS13   Error writing file to host: file transfer canceled

 

They all stop at 32743. Smaller files transfer OK.

 

I then curse and log on to a 24 x 80 session and send the file
successfully. 

 

I suspect I need a tweak in the .WS file but so far I haven't found it.


 

Alan

 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Lionel B Dyck]

The challenge with XMIT/UNLOAD is that you have to run tso in batch to 
reconstitute it.  I prefer in these situations to use IEBCOPY unload/load.

Lionel B. Dyck, Consultant/Specialist 
?Never attribute to malice what can be caused by miscommunication.? 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 



From:
Ted MacNEIL 
To:
IBM-MAIN@bama.ua.edu
Date:
04/27/2009 12:53 PM
Subject:
Re: Using FTP to send loadlib
Sent by:
IBM Mainframe Discussion List 



>there is a way to directly send individual loadlib members but to send a 
whole loadlib you really should dump it first using the  ADDRSSU utility.

1. ADDRSSU is protected at many sites.
2. XMIT/UNLOAD (OUTFILE) is easier.


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Power Capacity Planning (was Slightly off topic power limits)

[Ted MacNEIL]

>I agree with everything you say, but I still think that limiting a 
>datacenter's power capacity is anti business.
>When limits are set by government, or in this case the power company, business 
>tends to look at relocating their business to somewhere where those limits 
>don't exist, or the overall costs are lower.

That has always been an issue.
And, a solution.
But, I have a question for you.
What happens if the government/power company doesn't 'cap' power consumption, 
the data centre uses 'too much' and the grid blows?
At least, this way, you can manage it without going belly-up.

>Thats interesting that capacity planners now also consider power consumption.

Now?
I've been doing it since I worked for the Ontario Government in 1984.
There, it was critical, due to the limits of UPS and DR.

But, it was an issue at the first site I worked at (1981).
Thier MG-Set couldn't keep the whole site up, if needed.

Lately, it's been more of:
Have enough power -- check.

But, it has been an issue since 1981, in my experience.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: RECEIVE ORDER ERROR

[Brian Peterson]

Yet another problem I never saw because I always use CONTENT(ALL) instead of
CONTENT(RECOMMENDED) for RECEIVE ORDER.

http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0904&L=ibm-main&P=R14311

You too could see the light and choose to move to using CONTENT(ALL)..

Brian

On Sat, 25 Apr 2009 22:00:52 -0400, Edward Jaffe wrote:

>Been getting this all weekend trying RECEIVE ORDER with
>CONTENT(RECOMMENDED). Am I the only one?
>
>Error encountered during CCSS processing when
>requested fix co
>uld not be found..
>
>Edward E Jaffe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Lionel B Dyck]

If it works without the MOD B/TYPE E great.  I've just always done it 
because at one point it was required or you'd loose the load module 
directory information.

Lionel B. Dyck, Consultant/Specialist 
Kaiser Service Credo: "Our cause is health. Our passion is service. We?re 
here to make lives better.? 

?Never attribute to malice what can be caused by miscommunication.? 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 



From:
"Patrick O'Keefe" 
To:
IBM-MAIN@bama.ua.edu
Date:
04/27/2009 12:35 PM
Subject:
Re: Using FTP to send loadlib
Sent by:
IBM Mainframe Discussion List 



On Mon, 27 Apr 2009 11:31:00 -0700, Lionel B Dyck 
 wrote:
>...
>type e 
>mode b 
>cd LIONEL.LOAD 
>lcd LIONEL.LOAD 
>Put TESTMOD
>Close 
>Quit 
>/* 
>...

I know that the Type and Mode are necessary if you want to 
transfer ISPF stats, as in
   Type E 
   MODE B 
   LOCSITE ISPFStats 
   SITE ISPFStats 
but I don't think it is necessary for load module transfers. I've been
sucessful wothout them.

MPUT * works, too. 

In some old releases the FTP client and server used to invoke 
IEBCOPY under the cover but I don't see evedence of that any 
more.   In fact IEBCOPY used to be invoked separately for each
member when MPUT was used (making it a LOT faster to do the 
unloading and reloading outside of FTP).   If that is still being done,
it is done very quietly.

Pat O'Keefe 

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Patrick O'Keefe]

On Mon, 27 Apr 2009 11:31:00 -0700, Lionel B Dyck 
 wrote:
>...
>type e 
>mode b 
>cd LIONEL.LOAD 
>lcd LIONEL.LOAD 
>Put TESTMOD
>Close 
>Quit 
>/* 
>...

I know that the Type and Mode are necessary if you want to 
transfer ISPF stats, as in
   Type E  
   MODE B  
   LOCSITE ISPFStats   
   SITE ISPFStats  
but I don't think it is necessary for load module transfers. I've been
sucessful wothout them.

MPUT * works, too.  

In some old releases the FTP client and server used to invoke 
IEBCOPY under the cover but I don't see evedence of that any 
more.   In fact IEBCOPY used to be invoked separately for each
member when MPUT was used (making it a LOT faster to do the 
unloading and reloading outside of FTP).   If that is still being done,
it is done very quietly.

Pat O'Keefe 

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Dave Quinton]

This works:

//FTP EXEC PGM=FTP
//OUTPUT  DD   SYSOUT=*
//INPUT   DD   *
remote.host
userid
password
bin
prompt
cd 'remote.load.library.name'   <-- must already exist
lcd 'local.load.library.name'
mput *
quit
/*

=

Hello,
 
I have been digging through the OS/390 TCP/IP OE: User's Guide and have not
been able to get this to work.
 
Is it possible to send a loadlib from 1 mainframe to another mainframe using
FTP, either batch or interactive?
 
If so, would anyone be willing to share some batch jcl with me?
 
Thanks,
Kurt



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html>> HDT Original External RFC822 Hdrs Begin <<
X-Env-Sender: owner-ibm-m...@bama.ua.edu
X-Env-Recipient: david.quin...@nccourts.org
X-End-of-Envelope:
Received: from ??? ([199.120.166.242]) by nccourts.org (FISC HDT v1.3R SMTP 
gateway for Unix System Services)
with SMTP id emailscan.nccourts.org; Mon, 27 Apr 2009 12:44:01 -0400
Received: from emailscan.nccourts.org (emailscan [127.0.0.1])
by localhost.nccourts.org (Postfix) with ESMTP id 782F52AD827D
for ; Mon, 27 Apr 2009 12:43:49 -0400 (EDT)
Received: from bama.ua.edu (bama.ua.edu [130.160.4.114])by 
emailscan.nccourts.org (Postfix) with ESMTP id BD80E2AD826Afor 
; Mon, 27 Apr 2009 12:43:44 -0400 (EDT)
Received: from bama (localhost [127.0.0.1])by bama.ua.edu 
(8.13.8+Sun/8.13.8) with ESMTP id n3RGNSHF020969;Mon, 27 Apr 2009 
11:42:29 
-0500 (CDT)
Received: by BAMA.UA.EDU (LISTSERV-TCP/IP release 15.0) with spool id 60667 
for IBM-MAIN@BAMA.UA.EDU; Mon, 27 Apr 2009 10:40:41 -0500
Received: from mailapp-1.ua.edu (mailapp-1.ua.edu [130.160.4.236]) by   
  bama.ua.edu (8.13.8+Sun/8.13.8) with ESMTP id n3RFVeJA023092 for  
   
; Mon, 27 Apr 2009 10:31:46 -0500 (CDT)
X-RemoteIP: 76.13.13.66
X-Group: ACCEPTLIST
X-Policy: $ACCEPTED
X-MID: 43896072
X-SBRS: 4.7
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMCAFds9UlMDQ1Ck2dsb2JhbACCJC+UAwEBAQEJCQoJEQO
nWweBAY5EAQQCAYNxBYVpggI
X-IronPort-AV: E=Sophos;i="4.40,255,1238994000"; d="scan'208";a="43896072"
Received: from n3a.bullet.mail.ac4.yahoo.com ([76.13.13.66]) by 
mailapp-1.ua.edu with SMTP; 27 Apr 2009 10:31:44 -0500
Received: from [76.13.13.25] by n3.bullet.mail.ac4.yahoo.com with NNFMP; 27 
Apr 2009 15:31:42 -
Received: from [76.13.10.162] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 27
 Apr 2009 15:31:42 -
Received: from [127.0.0.1] by omp103.mail.ac4.yahoo.com with NNFMP; 27 Apr 
2009 15:31:41 -
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 990045.96573...@omp103.mail.ac4.yahoo.com
Received: (qmail 16760 invoked by uid 60001); 27 Apr 2009 15:31:41 -
X-YMail-OSG: hCxwzFAVM1kQBXdEFlX3c5EWz.3zu2IOWOAZHqnR5NIkyFmb5NDC5XgIqoYa3OG

PyMq54MGdv.hOzGproi3JHItQcHjeudCAV9ayufUS_6M7Ku_71uCNpo.lDWtJtNEIRkwOQSHhWk

8IbW.8ez4v.L4RuJDkoGnyj3GXu8_saPX0H9EZT6lLZ4L3dcwGnWbop0hwihn8nS9XXcNmU1rbL
8FCKzKVjDzveNI2JcaUz_zvR85SKIFp9C9JxFQZClY4IVHxVhCz_k0QccH4tkY-
Received: from [208.188.247.240] by web59712.mail.ac4.yahoo.com via HTTP; 
Mon, 27 Apr 2009 08:31:41 PDT
X-Mailer: YahooMailWebService/0.7.289.1
MIME-Version: 1.0
X-Antivirus: checked in 0.009sec at bama.ua.edu ([130.160.4.114]) by 
smf-clamdv1.2.1 - http://smfs.sf.net/
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <865557.13290...@web59712.mail.ac4.yahoo.com>
Newsgroups: bit.listserv.ibm-main
Date: Mon, 27 Apr 2009 08:31:41 -0700
Reply-To: IBM Mainframe Discussion List 
Sender: IBM Mainframe Discussion List 
From: Kurt Eastwood 
Subject: Using FTP to send loadlib
To: IBM-MAIN@bama.ua.edu
Precedence: list
List-Help: ,  

List-Unsubscribe: 
List-Subscribe: 
List-Owner: 
List-Archive: 
X-imss-version: 2.053
X-imss-result: Passed
X-imss-scores: Clean:58.99515 C:2 M:3 S:5 R:5
X-imss-settings: Baseline:4 C:4 M:4 S:3 R:3 (1. 1.)
X-HDT-HopCount: 1
>> HDT Original External RFC822 Hdrs End <<

Re: ISPF Question

[Ted MacNEIL]

>To go to any function in ISPF you usually issue =2  or =3.4  and so forth.

But, there's a new function with 1.10, that makes it even easier.
IE: You don't always have to remember the option numbers.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Question

[Field, Alan C.]

Thanks Steve and Dave. That's it.


SWAPBAR

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Lionel B Dyck]

Here is a sample of the generated jcl from my ftpbatch ispf dialog:

//FTPSTEP EXEC PGM=FTP,PARM='mvshost.kp.org (EXIT' 
//SYSPRINT DD SYSOUT=* 
//NETRCDD DISP=(OLD,DELETE,DELETE), 
//DSN=SYSLBD.FTP.NETRC.D090427.T1128402 
//INPUTDD * 
type e 
mode b 
cd LIONEL.LOAD 
lcd LIONEL.LOAD 
Put TESTMOD
Close 
Quit 
/* 

Notice that it just sets TYPE E (ebcdic) and MODE B (Block) and it is able 
to ftp successful a load module

the dialog creates a temp file (NETRC) with the userid and password

hope this helps

Lionel B. Dyck, Consultant/Specialist 
?Never attribute to malice what can be caused by miscommunication.? 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 



From:
"Barkow, Eileen" 
To:
IBM-MAIN@bama.ua.edu
Date:
04/27/2009 11:16 AM
Subject:
Re: Using FTP to send loadlib
Sent by:
IBM Mainframe Discussion List 



there is a way to directly send individual loadlib members but to send a 
whole loadlib you really should dump it first using the  ADDRSSU utility.
this is jcl that i use.
the userid and password are in the  FTPLPA  xcics.ftp.cardd file.

//DELLPA EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DELETE XCICS.SDFHLPA.UNLOAD NONVSAM PURGE
  SET MAXCC=0
/*
//DUMPLPA EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//SYSPRIN1 DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//TAPE1DD DISP=(NEW,CATLG,DELETE),
// DSN=XCICS.SDFHLPA.UNLOAD,SPACE=(CYL,(10,8),RLSE)
//SYSINDD *
  DUMP OUTDD(TAPE1) -
   DATASET(INCLUDE(XCICS.KX640T2.SDFHLPA)) -
   ALLDATA(*)
/*
//FTPLPA  EXEC PGM=FTP,PARM=('ip.address')
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD DSN=XCICS.FTP.CARDD,DISP=SHR
//  DD *
 DELETE 'XCICS.SDFHLPA.UNLOAD'
 EBCDIC
 BLOCK
 SITE BLKSIZE=27998
 SITE RECFM=U
 SITE LRECL=0
 SITE TRACKS
 SITE PRIMARY=90
 SITE SECONDARY=60
 SITE VOL=MISTG3
 STAT
 PUT 'XCICS.SDFHLPA.UNLOAD'
 QUIT

Then to reload the file on the remote system:

//RESTLPA EXEC  PGM=ADRDSSU COND=((0,NE),(0,EQ))
//*ESTEXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN'
//SYSPRINT  DD  SYSOUT=*
//IN  DD DSN=XCICS.SDFHLPA.UNLOAD,DISP=SHR
//OUT DD VOL=SER=MISTG2,DISP=SHR,UNIT=SYSDA
//*ENUNC(XCICS.*.*,POCWSS1.*.*) REPLACE
//SYSIN DD  *
  RESTORE INDD(IN) OUTDD(OUT) DATASET(INCLUDE(XCICS.KX640T2.SDFHLPA)) -
   REPLACE
,/*

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf Of Kurt Eastwood
Sent: Monday, April 27, 2009 11:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Using FTP to send loadlib

Hello,
 
I have been digging through the OS/390 TCP/IP OE: User's Guide and have 
not been able to get this to work.
 
Is it possible to send a loadlib from 1 mainframe to another mainframe 
using FTP, either batch or interactive?
 
If so, would anyone be willing to share some batch jcl with me?
 
Thanks,
Kurt


 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[David Betten]

I usually just terse with TRSMAIN, ftp the tersed file, then unterse with
TRSMAIN.

Have a nice day,
Dave Betten
DFSORT Development, Performance Lead
IBM Corporation
email:  bet...@us.ibm.com
DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/

IBM Mainframe Discussion List  wrote on 04/27/2009
01:32:25 PM:

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Kurt Eastwood
> Sent: Monday, April 27, 2009 10:32 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Using FTP to send loadlib
>
> Hello,
> =A0
> I have been digging through the OS/390 TCP/IP OE: User's Guide and have
> not=
>  been able to get this to work.
> =A0
> Is it possible to send a loadlib from 1 mainframe to another mainframe
> usin=
> g FTP, either batch or interactive?
> =A0
> If so, would anyone be willing to share some batch jcl with me?
> =A0
> Thanks,
> Kurt=0A=0A=0A
>
> 
>
> I think you will have to unload it using IEBCOPY to a flat file, then
> send that as BIN. After receiving it, use IEBCOPY to load the PDS.
>
> OR, you can use TSO XMIT to a file, FTP as BIN, then point TSO RECEIVE
> to the file...
>
> Regards,
> Steve Thompson
>
> -- Opinions expressed by this poster may not reflect those of poster's
> employer. --
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Ted MacNEIL]

>OR, you can use TSO XMIT to a file, FTP as BIN, then point TSO RECEIVE to the 
>file...

XMIT is easier, IMO.

But, I don't believe you have to use BIN, since both sites are z/OS.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Ted MacNEIL]

>there is a way to directly send individual loadlib members but to send a whole 
>loadlib you really should dump it first using the  ADDRSSU utility.

1. ADDRSSU is protected at many sites.
2. XMIT/UNLOAD (OUTFILE) is easier.


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Ted MacNEIL]

>LRECL=80,RECFM=PS .

PS does not exist as a RECFM.
It does as a DSORG.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Barkow, Eileen]

if you just want to ftp load modules, you can do so interactively.

ftp ip.addr
cd  'REMOTE.LOADLIB'
lcd 'LOCAL.LOADLIB'
put modname
quit

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Mark Zelden
Sent: Monday, April 27, 2009 1:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Using FTP to send loadlib

On Mon, 27 Apr 2009 12:09:50 -0500, Mark Zelden 
wrote:

>On Mon, 27 Apr 2009 08:31:41 -0700, Kurt Eastwood  wrote:
>
>>Hello,
>> 
>>I have been digging through the OS/390 TCP/IP OE: User's Guide and have not
>been able to get this to work.
>> 
>>Is it possible to send a loadlib from 1 mainframe to another mainframe
>using FTP, either batch or interactive?
>> 
>
>Yes, since for 10 releases (since OS/390 2.10).
>
>See IP User's Guide:
>
>Section 4.2.5 Load module transfer with FTP
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B970/4.2.5?SHELF=F1A1BK91&DT=20070530175427
>
>

So after reading other responses, I see I probably mistook "loadlib" for
"load module".
 

If you can FTP into an existing library, see what I wrote above, otherwise
you'll have to unload / backup the library first, FTP it, and then
reassemble it again on the other side as others have suggested.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Lionel B Dyck]

Take a look at my FTPBatch ISPF dialog - it will simplify this process for 
you significantly.

you can find it at http://www.lbdsoftware.com

enjoy

Lionel B. Dyck, Consultant/Specialist 
?Never attribute to malice what can be caused by miscommunication.? 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 



From:
Jim Phoenix 
To:
IBM-MAIN@bama.ua.edu
Date:
04/27/2009 11:12 AM
Subject:
Re: Using FTP to send loadlib
Sent by:
IBM Mainframe Discussion List 



Kurt,

You will need to XMIT the loadlib and FTP the XMIT file.  Sorry, I don't 
have any JCL to do that as I've always done this interactively.

Kurt Eastwood wrote:
> Hello,
> 
>  Is it possible to send a loadlib from 1 mainframe to another mainframe 
using FTP, either batch or interactive?
> 
>  Thanks,
> Kurt
>
>
>
> 

-- 
| Jim Phoenix  | Voice:   (310) 338-0400 x316   |
| Senior Software Developer| Fax: (310) 338-0801|
| Phoenix Software International   | Alt fax: (310) 337-2685|
| 5200 W. Century Blvd., Suite 800 | jimphoe...@phoenixsoftware.com |
| Los Angeles, CA 90045| http://www.phoenixsoftware.com |

Opinions expressed by this individual are not necessarily those of the 
Company.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Question

[Lizette Koehler]

To go to any function in ISPF you usually issue =2  or =3.4  and so forth.

Lizette



>
>I think it was on IBM-MAIN I saw this fairly recently. I have been in
>the archive and can't find the reference.
>
> 
>
>A command to put the screen names along the bottom of the screen so that
>you could position the cursor and jump directly to that screen.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Power Capacity Planning (was Slightly off topic power limits)

[Eric Bielefeld]

Tom,

I agree with everything you say, but I still think that limiting a 
datacenter's power capacity is anti business.  When limits are set by 
government, or in this case the power company, business tends to look at 
relocating their business to somewhere where those limits don't exist, or 
the overall costs are lower.


Thats interesting that capacity planners now also consider power 
consumption.  Considering that the price of electricity is generally going 
up, I'm sure that's a good thing.  I've gone to a lot of MCMG (Midwest 
Computer Measurement Group) meetins over the years, but I don't recall that 
every being a topic, although lately I haven't gone and it might have been a 
topic of discussion.


Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Kelman, Tom" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, April 27, 2009 10:33 AM
Subject: Power Capacity Planning (was Slightly off topic power limits)



Eric,

I think the point here is that for years data centers have proliferated
servers that are single application and low utilization.  This has
driven their power usage sky high.  I don't know if power companies in
other states have started to put caps on power usage like PG&E has, but
I have heard that it is happening in Europe where the power companies
are basically government owned.  I've been in the capacity planning
profession for about 20 years.  Traditionally that involves planning for
CPU consumption, memory, and storage.  Now, in many shops that
traditional capacity planner is adding power consumption to his/her list
of items to trend and control in some way.  This is another perfect
reason to virtualize.  Of course we all know that the mainframe is the
best, most mature virtual machine available.  Now, if we can just get
management to realize that.

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Joseph Butz]

In ABR, this is an option (MIGRAT) that is set in the FDR Global Options.  

By default, if ABR Archive recatalogs an archived dataset for automatic
recall, the catalog entry will retain the original volser unless MIGRAT=YES
is specified.  This option can be overridden at run time.  

The Innovation recommended setting is MIGRAT=YES unless the ABR LOCATE exit
is not being used.

Joseph Butz
jb...@fdrinnovation.com
Innovation Data Processing


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Monday, April 27, 2009 10:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

On Mon, 27 Apr 2009 09:59:51 +0300, Binyamin Dissen wrote:
>
>Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

FDR does.  Actually, it's ABR.  ISTR that this behavior is optional, but I
don't recall what is in the VOLSER if the option is not selected.  The
original VOLSER perhaps.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Question

[Hardee, Charles H]

Are you thinking of: SCRNAME screen name [PERM|ON|OFF]?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Field, Alan C.
Sent: Monday, April 27, 2009 11:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: ISPF Question

I think it was on IBM-MAIN I saw this fairly recently. I have been in
the archive and can't find the reference.

 

A command to put the screen names along the bottom of the screen so that
you could position the cursor and jump directly to that screen.

 

TIA,

 

Alan 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Question

[Steve Comstock]

Field, Alan C. wrote:

I think it was on IBM-MAIN I saw this fairly recently. I have been in
the archive and can't find the reference.

 


A command to put the screen names along the bottom of the screen so that
you could position the cursor and jump directly to that screen.

 


TIA,

 

Alan 


SWAPBAR


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Check out the Trainer's Friend Store to purchase z/OS  <==
==> application developer toolkits. Sample code in four<==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==>   http://www.trainersfriend.com/TTFStore/index.html<==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[John P Kalinich]

Kurt Eastwood of the IBM Mainframe Discussion List 
wrote on 04/27/2009 10:31:41 AM:

> I have been digging through the OS/390 TCP/IP OE: User's Guide and
> have not been able to get this to work.
>
> Is it possible to send a loadlib from 1 mainframe to another
> mainframe using FTP, either batch or interactive?
>
> If so, would anyone be willing to share some batch jcl with me?

You could issue TSO TRANSMIT DSN(loadlib) OUTDA(seq_dsname) and then binary
FTP the sequential output file.  On the other end you would issue the TSO
RECEIVE INDSN(seq_dsname) to reconstruct the load library.

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Question

[Dave Salt]

SWAPBAR - requires z/OS 1.10


Dave Salt

SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm







> Date: Mon, 27 Apr 2009 11:23:07 -0500
> From: alan.c.fi...@supervalu.com
> Subject: ISPF Question
> To: IBM-MAIN@bama.ua.edu
>
> I think it was on IBM-MAIN I saw this fairly recently. I have been in
> the archive and can't find the reference.
>
>
>
> A command to put the screen names along the bottom of the screen so that
> you could position the cursor and jump directly to that screen.
>
>
>
> TIA,
>
>
>
> Alan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
_
Create a cool, new character for your Windows Live™ Messenger.
http://go.microsoft.com/?linkid=9656621

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Kurt Eastwood
Sent: Monday, April 27, 2009 10:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Using FTP to send loadlib

Hello,
=A0
I have been digging through the OS/390 TCP/IP OE: User's Guide and have
not=
 been able to get this to work.
=A0
Is it possible to send a loadlib from 1 mainframe to another mainframe
usin=
g FTP, either batch or interactive?
=A0
If so, would anyone be willing to share some batch jcl with me?
=A0
Thanks,
Kurt=0A=0A=0A  



I think you will have to unload it using IEBCOPY to a flat file, then
send that as BIN. After receiving it, use IEBCOPY to load the PDS.

OR, you can use TSO XMIT to a file, FTP as BIN, then point TSO RECEIVE
to the file...

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those of poster's
employer. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Barkow, Eileen]

there is a way to directly send individual loadlib members but to send a whole 
loadlib you really should dump it first using the  ADDRSSU utility.
this is jcl that i use.
the userid and password are in the  FTPLPA  xcics.ftp.cardd file.

//DELLPA EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DELETE XCICS.SDFHLPA.UNLOAD NONVSAM PURGE
  SET MAXCC=0
/*
//DUMPLPA EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//SYSPRIN1 DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//TAPE1DD DISP=(NEW,CATLG,DELETE),
// DSN=XCICS.SDFHLPA.UNLOAD,SPACE=(CYL,(10,8),RLSE)
//SYSINDD *
  DUMP OUTDD(TAPE1) -
   DATASET(INCLUDE(XCICS.KX640T2.SDFHLPA)) -
   ALLDATA(*)
/*
//FTPLPA  EXEC PGM=FTP,PARM=('ip.address')
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD DSN=XCICS.FTP.CARDD,DISP=SHR
//  DD *
 DELETE 'XCICS.SDFHLPA.UNLOAD'
 EBCDIC
 BLOCK
 SITE BLKSIZE=27998
 SITE RECFM=U
 SITE LRECL=0
 SITE TRACKS
 SITE PRIMARY=90
 SITE SECONDARY=60
 SITE VOL=MISTG3
 STAT
 PUT 'XCICS.SDFHLPA.UNLOAD'
 QUIT

Then to reload the file on the remote system:

//RESTLPA EXEC  PGM=ADRDSSU COND=((0,NE),(0,EQ))
//*ESTEXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN'
//SYSPRINT  DD  SYSOUT=*
//IN  DD DSN=XCICS.SDFHLPA.UNLOAD,DISP=SHR
//OUT DD VOL=SER=MISTG2,DISP=SHR,UNIT=SYSDA
//*ENUNC(XCICS.*.*,POCWSS1.*.*) REPLACE
//SYSIN DD  *
  RESTORE INDD(IN) OUTDD(OUT) DATASET(INCLUDE(XCICS.KX640T2.SDFHLPA)) -
   REPLACE
,/*

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Kurt Eastwood
Sent: Monday, April 27, 2009 11:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Using FTP to send loadlib

Hello,
 
I have been digging through the OS/390 TCP/IP OE: User's Guide and have not 
been able to get this to work.
 
Is it possible to send a loadlib from 1 mainframe to another mainframe using 
FTP, either batch or interactive?
 
If so, would anyone be willing to share some batch jcl with me?
 
Thanks,
Kurt


  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Mark Zelden]

On Mon, 27 Apr 2009 12:09:50 -0500, Mark Zelden 
wrote:

>On Mon, 27 Apr 2009 08:31:41 -0700, Kurt Eastwood  wrote:
>
>>Hello,
>> 
>>I have been digging through the OS/390 TCP/IP OE: User's Guide and have not
>been able to get this to work.
>> 
>>Is it possible to send a loadlib from 1 mainframe to another mainframe
>using FTP, either batch or interactive?
>> 
>
>Yes, since for 10 releases (since OS/390 2.10).
>
>See IP User's Guide:
>
>Section 4.2.5 Load module transfer with FTP
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B970/4.2.5?SHELF=F1A1BK91&DT=20070530175427
>
>

So after reading other responses, I see I probably mistook "loadlib" for
"load module".
 

If you can FTP into an existing library, see what I wrote above, otherwise
you'll have to unload / backup the library first, FTP it, and then
reassemble it again on the other side as others have suggested.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Mark Zelden]

On Mon, 27 Apr 2009 08:31:41 -0700, Kurt Eastwood  wrote:

>Hello,
> 
>I have been digging through the OS/390 TCP/IP OE: User's Guide and have not
been able to get this to work.
> 
>Is it possible to send a loadlib from 1 mainframe to another mainframe
using FTP, either batch or interactive?
> 

Yes, since for 10 releases (since OS/390 2.10).

See IP User's Guide:

Section 4.2.5 Load module transfer with FTP
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B970/4.2.5?SHELF=F1A1BK91&DT=20070530175427


Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Frank Krueger]

Kurt
first you must create a sequentiell dataset - 
simply use XMIT (aka TRANSMIT) with the OUTDSN parameter in TSO or  Batch 
- 
this will create a new dataset with LRECL=80,RECFM=PS .
You may FTP this and then do a RECEIVE INDSN on the other system from this 
transferred dataset which restores the loadlib.
regards
Frank



Hello,
 
I have been digging through the OS/390 TCP/IP OE: User's Guide and have 
not been able to get this to work.
 
Is it possible to send a loadlib from 1 mainframe to another mainframe 
using FTP, either batch or interactive?
 
If so, would anyone be willing to share some batch jcl with me?
 
Thanks,
Kurt



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Jim Phoenix]

Kurt,

You will need to XMIT the loadlib and FTP the XMIT file.  Sorry, I don't 
have any JCL to do that as I've always done this interactively.


Kurt Eastwood wrote:

Hello,
 
 Is it possible to send a loadlib from 1 mainframe to another mainframe using FTP, either batch or interactive?
 
 Thanks,

Kurt



  


--
| Jim Phoenix  | Voice:   (310) 338-0400 x316   |
| Senior Software Developer| Fax: (310) 338-0801|
| Phoenix Software International   | Alt fax: (310) 337-2685|
| 5200 W. Century Blvd., Suite 800 | jimphoe...@phoenixsoftware.com |
| Los Angeles, CA 90045| http://www.phoenixsoftware.com |

Opinions expressed by this individual are not necessarily those of the 
Company.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP to send loadlib

[Rugen, Len]

Probably not...

The common trick is to use TSO TRANSMIT command to create a portable dataset, 
ftp that then use TSO Receive on the other side to reconstruct the dataset.  


Len Rugen
  


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Kurt Eastwood
Sent: Monday, April 27, 2009 10:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Using FTP to send loadlib

Hello,
 
I have been digging through the OS/390 TCP/IP OE: User's Guide and have not 
been able to get this to work.
 
Is it possible to send a loadlib from 1 mainframe to another mainframe using 
FTP, either batch or interactive?
 
If so, would anyone be willing to share some batch jcl with me?
 
Thanks,
Kurt


  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: NPIV on System z

[Alan Altmark]

On Monday, 04/27/2009 at 02:24 EDT, John Argall  wrote:
> When you say online to the host. Is this bringing the chpid online to 
the lpar,
> or the CP ATTACH in VM?

Neither.  It is a logical "vary" operation.  I'm being vague because you 
didn't say whether they were for CP's use (EDEVICEs) or Linux.  If these 
are CP-managed EDEVICEs, then when you VARY ON the subchannel (or if 
covered by Online_At_IPL in SYSTEM CONFIG), the virtual WWPN will light 
up.  If they are Linux's use, then they come online when you do the Linux 
equivalent of a "vary".

Alan Altmark
z/VM Development
IBM Endicott

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

ISPF Question

[Field, Alan C.]

I think it was on IBM-MAIN I saw this fairly recently. I have been in
the archive and can't find the reference.

 

A command to put the screen names along the bottom of the screen so that
you could position the cursor and jump directly to that screen.

 

TIA,

 

Alan 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Jes2 default sysout

[Pommier, Rex R.]

Peter,

You're right, my bad.  The OP was talking about MSGCLASS, not MSGLEVEL.
What my brain told my fingers to write was that you cannot use MSGCLASS
on the JOBCLASS statement, but my fingers typed MSGLEVEL.  

Thanks for correcting my post.

Rex



>Unfortunately (at least as of z/OS 1.7), JOBCLASS doesn't allow 
>MSGLEVEL to be defined, only STC and TSU.  At least that's what 
>the INIT reference manual says...

What makes you think so? 

JOBCLASS(A) MSGLEVEL(2,1)   is a valid init statement.

--
Peter Hunkeler
Credit Suisse



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Using FTP to send loadlib

[Kurt Eastwood]

Hello,
 
I have been digging through the OS/390 TCP/IP OE: User's Guide and have not 
been able to get this to work.
 
Is it possible to send a loadlib from 1 mainframe to another mainframe using 
FTP, either batch or interactive?
 
If so, would anyone be willing to share some batch jcl with me?
 
Thanks,
Kurt




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Power Capacity Planning (was Slightly off topic power limits)

[Kelman, Tom]

Eric,

I think the point here is that for years data centers have proliferated
servers that are single application and low utilization.  This has
driven their power usage sky high.  I don't know if power companies in
other states have started to put caps on power usage like PG&E has, but
I have heard that it is happening in Europe where the power companies
are basically government owned.  I've been in the capacity planning
profession for about 20 years.  Traditionally that involves planning for
CPU consumption, memory, and storage.  Now, in many shops that
traditional capacity planner is adding power consumption to his/her list
of items to trend and control in some way.  This is another perfect
reason to virtualize.  Of course we all know that the mainframe is the
best, most mature virtual machine available.  Now, if we can just get
management to realize that.   

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Eric Bielefeld
> Sent: Saturday, April 25, 2009 8:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Slightly off topic power limits
> 
> I was just thinking how anti business the power limits imposed by PG&E
> are.
> I'm not sure if the limits are being imposed because of being on a
fault
> line, or just because they don't have enough power generation in that
> area.
> If you were a large business with sites in multiple states, where
would
> you
> build your new datacenter.  In California, where your power would be
> limited, or in some state where they wouldn't limit your power.  I
know
> Wisconsin has had a lot of battles about building a new power plant to
> serve
> the Milwaukee area.  Fortuneatly, we are building a new plant now.
> 
> Eric
> 
> Eric Bielefeld
> Sr. Systems Programmer
> Milwaukee, Wisconsin
> 414-475-7434
> 
> 
> - Original Message -
> From: "Ed Gould" 
> Newsgroups: bit.listserv.ibm-main
> To: 
> Sent: Friday, April 24, 2009 10:40 PM
> Subject: Slightly off topic power limits
> 
> 
> > 
> > I dialed in recently to an online technology discussion sponsored by
> > Wikibon.org, a community of technology professionals. Speaking was
Rich
> > Avila, director of server and network operations at California
State,
> who
> > said saving power wasn't a fuzzy, feel good goal for him. It was a
> > necessity.
> >
> > Avila is the director of server and network operations at California
> State
> > University, East Bay, and he was responsible for 250 servers at the
> > Hayward, Calif., institution. The school's data center had ramped up
> > quickly and by late 2007, his utility was telling him he was drawing
67
> > kilowatt hours of power while the maximum available to him was going
to
> be
> > capped at 75 kilowatt hours. Pacific Gas & Electric said in no
uncertain
> > terms there'd be no additional power available when he reached that
> limit,
> > a date that appeared about six months off, Avila said.
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Slightly off topic power limits

[R.S.]

Slightly on topic:
I had an occasion to compare two "z" machines: old z9 and new z10. Very 
similar in MIPS, channels, memory configuration.


Power consumption as shown by HMC
Old blue z9: 4kW
New green z10: 6 kW.
So, replacing old equipment with new "green" one resulted in increase of 
power consumpion by 50%.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Jes2 default sysout

[Pommier, Rex R.]

Peter,

You're right, my bad.  The OP was talking about MSGCLASS, not MSGLEVEL.
What my brain told my fingers to write was that you cannot use MSGCLASS
on the JOBCLASS statement, but my fingers typed MSGLEVEL.  

Thanks for correcting my post.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hunkeler Peter (KIUK 3)
Sent: Monday, April 27, 2009 1:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Jes2 default sysout

>Unfortunately (at least as of z/OS 1.7), JOBCLASS doesn't allow 
>MSGLEVEL to be defined, only STC and TSU.  At least that's what 
>the INIT reference manual says...

What makes you think so? 

JOBCLASS(A) MSGLEVEL(2,1)   is a valid init statement.

--
Peter Hunkeler
Credit Suisse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Xrc a reasonable solution between two databases created separately(in DB2)?

[Ron Hawkins]

Sanaz,

It was mentioned in an earlier mail that XRC operates on the volume level.
It knows nothing about VTOCs, VVDS, or datasets. You don't create anything
on the secondary volume because XRC is designed to copy the Primary volume
over the secondary volume.

When you first create an XRC pair all of the contents of the Primary volume
are copied to the Secondary volume. If there is anything on the secondary
volume before you do the copy it is toast. If you updated anything on the
secondary volume, the updates are toast. What you have is an exact replica
of the Primary volume.

I don't think XRC is the right copy product for what you are trying to do. 

Ron



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Sanaz Pourdarab
> Sent: Monday, April 27, 2009 4:49 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Is Xrc a reasonable solution between two databases
> created separately(in DB2)?
> 
> I have a problem with XRC now .It seems we should create all the contents
of
> primary volume on the secondary one before starting XRC.
> I faced with the problem when I did'nt create one of the cluster files of
> primary volume on secondary one  and started the XRC . It has been created
> via XRC, but other clusters on that secondary volume faced with the
catalog
> problem in  Listcat command.
> 
> 
> I need to do this for clusters which have extents on source side.I created
the
> base cluster on secondary volume like primary one but Its extent on a
> different  source volume will be copied on another secondary volume
(having
> xrc with that)  via XRC and makes problem of catalog issue for all the
> contents of that volume.
> 
> Does anybody know whether there is  a solution or we have to create all
the
> contents of primary volume on secondary before starting XRC?
> Regards
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Richards, Robert B.]

Originally, they did not. Nowadays, I am not sure.

IIRC, ARCIVE was DMS/OS now CA_DISK

-
Robert B. Richards(Bob)   
US Office of Personnel Management
1900 E Street NW Room: BH04L   
Washington, D.C.  20415  
Phone: (202) 606-1195  
Email: robert.richa...@opm.gov 
-

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Gerhard Postpischil
Sent: Monday, April 27, 2009 9:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

Binyamin Dissen wrote:
> I was hoping that there was some bit combination that would indicate a
> migrated dataset.

Not to my knowledge. For HSM, a migrated data set has serial of 
MIGRAT, then third byte of x'20' for level 1, and 'x80' for 
level 2. IIRC, similar information is available from IDCAMS 
DCOLLECT.

> Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

I'd love to find out also, but have only had the annoyance of 
HSM 

Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Tom Marchant]

On Mon, 27 Apr 2009 09:59:51 +0300, Binyamin Dissen wrote:
>
>Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

FDR does.  Actually, it's ABR.  ISTR that this behavior is optional, but I
don't recall what is in the VOLSER if the option is not selected.  The
original VOLSER perhaps.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Bill Fairchild]

As Gerhard pointed out in an earlier post, the 3rd byte of the 4 bytes of 
device type info are documented in the UCB macro in the field UCBTBYT3, where 
X'80' denotes a tape device (which corresponds to HSM level 2) and X'20' 
denotes a direct access device (which corresponds to HSM level 1).

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Gerhard Postpischil
Sent: Monday, April 27, 2009 8:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

Binyamin Dissen wrote:
> I was hoping that there was some bit combination that would indicate a
> migrated dataset.

Not to my knowledge. For HSM, a migrated data set has serial of 
MIGRAT, then third byte of x'20' for level 1, and 'x80' for 
level 2. IIRC, similar information is available from IDCAMS 
DCOLLECT.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Scott T. Harder]

Hi Guys and Gals,

I'm back.

Bin...  The only other HSM-like product I have experience with is CA-DISK
(back before it was CA-DISK... can't even remember the name now offhand).
But - at least at the time - used a volser of ARCIVE.  I think it is still
the same.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Gerhard Postpischil
Sent: Monday, April 27, 2009 9:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

Binyamin Dissen wrote:
> I was hoping that there was some bit combination that would indicate a
> migrated dataset.

Not to my knowledge. For HSM, a migrated data set has serial of
MIGRAT, then third byte of x'20' for level 1, and 'x80' for
level 2. IIRC, similar information is available from IDCAMS
DCOLLECT.

> Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

I'd love to find out also, but have only had the annoyance of
HSM 

Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Prices, software, charts & analysis.  Click here to open your online FX trading 
account.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYV6oJGSrQm7cOG7ph2CcnHUjfzC72rMjzzkLSGAmtM6VlzCqSbHkk/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Vernooy, C.P. - SPLXM]

"Gerhard Postpischil"  wrote in message
news:<49f5b25d.8040...@valley.net>...
> Binyamin Dissen wrote:
> 
> > Do all products (HSM, FDR, etc.) use the string MIGRAT as the
VOLSER?
> 
> I'd love to find out also, but have only had the annoyance of 
> HSM 
> 

Yes and no. CA-DISK uses ARCIVE as volume in the catalog, but in the
catalog locate intercept it returns MIGRAT to the requestor to satisfy
those applications, that know and react on HSM migrated datasets.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Gerhard Postpischil]

Binyamin Dissen wrote:

I was hoping that there was some bit combination that would indicate a
migrated dataset.


Not to my knowledge. For HSM, a migrated data set has serial of 
MIGRAT, then third byte of x'20' for level 1, and 'x80' for 
level 2. IIRC, similar information is available from IDCAMS 
DCOLLECT.



Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?


I'd love to find out also, but have only had the annoyance of 
HSM 


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Binyamin Dissen]

On Mon, 27 Apr 2009 07:51:41 -0400 Bill Fairchild  wrote:

:>One could always force a data set to be migrated and then look at what was 
stored in this metadata field.

Unfortunately I do not have access to all products that do migration.

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
Of Binyamin Dissen
:>Sent: Monday, April 27, 2009 2:00 AM
:>To: IBM-MAIN@bama.ua.edu
:>Subject: Re: Where are the device codes (returned by LOCATE) defined?

:>I was hoping that there was some bit combination that would indicate a
:>migrated dataset.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Vernooy, C.P. - SPLXM]

I am pretty sure there is no migration indication in the devicetype
field, only the catalogued volser MIGRAT tells you (and others).
In CA-DISK I have the option to leave the devicetype of the archived
(migrated) dataset to the devicetype of the original volume or to set it
to zeros.

Kees.

"Bill Fairchild"  wrote in message
news:<94c476c03bff5e42ac3518fdac9643c4d046bf4...@hqmail.rocketsoftware.c
om>...
> One could always force a data set to be migrated and then look at what
was stored in this metadata field.
> 
> Bill Fairchild
> 
> Software Developer 
> Rocket Software
> 275 Grove Street * Newton, MA 02466-2272 * USA
> Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
> Email: bi...@mainstar.com 
> Web: www.rocketsoftware.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Binyamin Dissen
> Sent: Monday, April 27, 2009 2:00 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Where are the device codes (returned by LOCATE) defined?
> 
> I was hoping that there was some bit combination that would indicate a
> migrated dataset.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Bill Fairchild]

One could always force a data set to be migrated and then look at what was 
stored in this metadata field.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: Monday, April 27, 2009 2:00 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

I was hoping that there was some bit combination that would indicate a
migrated dataset.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Xrc a reasonable solution between two databases created separately(in DB2)?

[Sanaz Pourdarab]

I have a problem with XRC now .It seems we should create all the contents of 
primary volume on the secondary one before starting XRC.
I faced with the problem when I did'nt create one of the cluster files of 
primary volume on secondary one  and started the XRC . It has been created 
via XRC, but other clusters on that secondary volume faced with the catalog 
problem in  Listcat command.


I need to do this for clusters which have extents on source side.I created the 
base cluster on secondary volume like primary one but Its extent on a 
different  source volume will be copied on another secondary volume (having 
xrc with that)  via XRC and makes problem of catalog issue for all the 
contents of that volume.  

Does anybody know whether there is  a solution or we have to create all the 
contents of primary volume on secondary before starting XRC?
Regards
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Rob Scott]

Binyamin,

My current list of volser values that indicate migrated datasets are :

MIGRAT
ARCIVE
ARCHIV

As far as I am aware, there is nothing in the catalog entry to indicate if a 
dataset is migrated or not - I was under the impression that the HSM_U_Like 
product gets control for "dataset not found" situations when the catalog entry 
is accessed.

One handy thing (for HSM anyway - not sure about others) is that the device 
type in the catalog entry does hint at the migratation level (ie if cat entry 
device type = DASD and volser=MIGRAT then dataset is on ML1). 


Rob Scott
Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305 
Email: rsc...@rs.com 
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: 27 April 2009 08:00
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

On Sun, 26 Apr 2009 20:30:46 -0400 Gerhard Postpischil 
wrote:

:>Binyamin Dissen wrote:
:>> X'3010200E' = 3380 DISK DEVICE CODE
 
:>> Where is the table defined?

:>There is no one table. The basic information is similar, but not :>identical 
to, fields UCBTBYT1-UCBTBYT4 in macro IEFUCBOB.

:>UCBTBYT3 (the x'20' above) is the device category, DASD in this :>case. These 
are defined in the UCB macro.

:>UCBTBYT4 (x'0E') is the device type, 3380 in this case.

:>The leading two bytes are device dependent, and may describe :>device 
characteristics and optional features (e.g., shared :>DASD). Some are in the 
UCB macro, most are not. They're :>scattered in documentation all over the 
place, usually hardware :>manuals or application notes.

I was hoping that there was some bit combination that would indicate a migrated 
dataset.

Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

--
Binyamin Dissen  http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me, you should 
preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems, especially those 
from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: APPN Connection z/os - AHHC / LLC2.

[Chris Mason]

Norbert

> ... also with 16384.

Testing with D NET,APING at sizes larger than 1920 doesn't show us anything 
new regarding the *size* of data units since 1920 is the request unit size 
imposed by the RUSIZES operand of the MODEENT macro used to generate 
the #INTER mode table entry which is the default and, I assume, the one you 
are using. It does, however, show us that sending more than one frame at a 
time can be successful.

It looks like we need tracing. The cleanest way to "see" session traffic is to 
use NLDM with the CPIU option but, since you have not responded to my 
suggestion you use this, I assume you have not installed NetView or, if you 
have, you have not enabled Session Monitor.

You need to trace the traffic when the TSO session hangs so that we can see 
the last data sent by TSO that does not get delivered. Wireshark could be 
handy in showing what flows on the LAN I believe - I have never actually used 
it. It may be useful, at the same time to use a VTAM buffer trace so that we 
can see whether something that has passed over the VTAM API from TSO 
actually appears as an Ethernet frame.

As a comparison, you could do the same, that is, a VTAM buffer trace and 
running Wireshark, with D NET,APING,SIZE=1920,ITER=1. (ITER=1 for the least 
amount of data to trace.)

Wireshark shows all the protocol headers (and trailers) I believe. I will be 
interested to see how the 802.2 protocol fields are supported with a Basic 
Transmission Unit size of 1498.

Have you had any success with looking for the "MAXDATA" value with other 
types of "cross-domain" connections?

Chris Mason

On Mon, 27 Apr 2009 09:59:51 +0200, Norbert Alfred Müller 
 wrote:

>Hi Chris!
>
>tests are ongoing  , but here some results:
>
>- I read in the manual about MAXDATA in a node 2.1. AND I tested, also. 
Without results: MAXDATA is always 1498 :-(
>- D NET,APING,  works with all sizes, also with 16384.
>- If MAXDATA 1498 is an absolute NO, the question is: how is getting VTAM 
this size ? from Network definition ? or is the size correct and the display no 
?
>What do you thing about a trace with wireshark ?
>
>
>Regards,
>Norbert.
>
>
>> Von: "Chris Mason" 
>> Gesendet: 26.04.09 13:34:02
>> An: IBM-MAIN@BAMA.UA.EDU
>> Betreff: Re: APPN Connection z/os - AHHC / LLC2.
>
>
>> Norbert
>>
>> Thanks for the information.
>>
>> I misunderstood what you meant by "before the whole screen comes". This
>> implied that you session stopped for a while and then continued. Perhaps 
you
>> should have said "before the whole screen would have come, if it had
>> continued working". So it really is a permanent "hang".
>>
>> The evidence is building up that the reported "MAXDATA" value is wrong so
>> you were right to suspect it. With a BTU size of 1498, there's no room for 
the
>> 802.2 connection-oriented LLC header inside the old Ethernet limit of 1500. 
It
>> then makes sense that the first large request unit is going to need 
segmenting
>> and that the segment worked out as a BTU size of 1498 will be dropped by 
the
>> Ethernet adapter resulting in a hang.
>>
>> When support for LANs was introduced for subarea connections, 
segmenting
>> was introduced also for subarea links - previously it had been used only for
>> peripheral links. Is there DISPLAY command output which shows a 
MAXDATA
>> value for the case where you use subarea connections with XCA major 
nodes?
>> Perhaps you could show that value.
>>
>> Also, the ANNC link is a type 2.1 connection. Is there DISPLAY command
>> output which shows a MAXDATA value for this type of connection?
>>
>> I would suggest trying to limit the request unit size used over the type 2.1
>> node connection. I expect you are using non/pre-SNA 3270, that is, defined
>> with LOCAL statements, so using the RUSIZES operand of the mode table
>> entry definition will not be effective. You could use TN3270 as a test 
perhaps
>> with a mode table entry which specifies, say, RUSIZES=X'8787' for a 
request
>> unit size in both directions of 1024.
>>
>> According to APPN architecture, you should be able to impose a maximum
>> request unit size by means of a mode table entry associated with the 
CDRSC
>> definition in the "other" VTAM node where that CDRSC definition represents
>> the secondary LU in the session. I have never tried this but you might like 
to
>> try it. The point is that segmenting is supposed to apply session stage by
>> session stage between Intermediate Session Routing (ISR) staging points. 
You
>> are avoiding using High Performance Routing (HPR) - and rapid Transport
>> Protocol (RTP) - but actually this doesn't change this principle since the 
RTP
>> end-points incorporate ISR architecture.
>>
>> Incidentally, I asked for DISPLAY NET,BFRUSE output only because there 
was
>> an outside chance that your "performance" problem was related to VTAM
>> buffers. Since it really is a "hang" rather than an excessive delay, that is 
not
>> so relevant. In fact, I can see you are hardly touching defa

Re: NPIV on System z

[Mark Post]

>>> On 4/27/2009 at  2:24 AM, John Argall  wrote: 
> Hi Alan,
> 
> Thanks for repsonding. 
> 
> When you say online to the host. Is this bringing the chpid online to the 
> lpar, 
> or the CP ATTACH in VM?

Neither.  It is when the guest OS activates the FCP device to try and start 
using it.


Mark Post

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The PUT FTP not working with large files

[z/OS scheduler]

2009/4/22 Alvaro Quintupray Burgos 

> Hi.
>
>We have getting  the following response when exec a  PUT  FTP with big
> files from  Host Z/OS  1.8   to  Host  Z/OS  1.8
>
> EZA2590E send error from send_data - EDC5120I Interrupted function call.
> (errno2=0x76690291)
>
>
> If we send  a  little file  the FTP  work  O.K.
>
>
> What are we doing wrong?
>
> Thanks.
>
> Alvaro.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: APPN Connection z/os - AHHC / LLC2.

[Norbert Alfred Müller]

Hi Chris!

tests are ongoing  , but here some results:

- I read in the manual about MAXDATA in a node 2.1. AND I tested, also. Without 
results: MAXDATA is always 1498 :-(
- D NET,APING,  works with all sizes, also with 16384.
- If MAXDATA 1498 is an absolute NO, the question is: how is getting VTAM this 
size ? from Network definition ? or is the size correct and the display no ?
What do you thing about a trace with wireshark ?


Regards,
Norbert.


> Von: "Chris Mason" 
> Gesendet: 26.04.09 13:34:02
> An: IBM-MAIN@BAMA.UA.EDU
> Betreff: Re: APPN Connection z/os - AHHC / LLC2.


> Norbert
> 
> Thanks for the information.
> 
> I misunderstood what you meant by "before the whole screen comes". This 
> implied that you session stopped for a while and then continued. Perhaps you 
> should have said "before the whole screen would have come, if it had 
> continued working". So it really is a permanent "hang".
> 
> The evidence is building up that the reported "MAXDATA" value is wrong so 
> you were right to suspect it. With a BTU size of 1498, there's no room for 
> the 
> 802.2 connection-oriented LLC header inside the old Ethernet limit of 1500. 
> It 
> then makes sense that the first large request unit is going to need 
> segmenting 
> and that the segment worked out as a BTU size of 1498 will be dropped by the 
> Ethernet adapter resulting in a hang.
> 
> When support for LANs was introduced for subarea connections, segmenting 
> was introduced also for subarea links - previously it had been used only for 
> peripheral links. Is there DISPLAY command output which shows a MAXDATA 
> value for the case where you use subarea connections with XCA major nodes? 
> Perhaps you could show that value.
> 
> Also, the ANNC link is a type 2.1 connection. Is there DISPLAY command 
> output which shows a MAXDATA value for this type of connection?
> 
> I would suggest trying to limit the request unit size used over the type 2.1 
> node connection. I expect you are using non/pre-SNA 3270, that is, defined 
> with LOCAL statements, so using the RUSIZES operand of the mode table 
> entry definition will not be effective. You could use TN3270 as a test 
> perhaps 
> with a mode table entry which specifies, say, RUSIZES=X'8787' for a request 
> unit size in both directions of 1024.
> 
> According to APPN architecture, you should be able to impose a maximum 
> request unit size by means of a mode table entry associated with the CDRSC 
> definition in the "other" VTAM node where that CDRSC definition represents 
> the secondary LU in the session. I have never tried this but you might like 
> to 
> try it. The point is that segmenting is supposed to apply session stage by 
> session stage between Intermediate Session Routing (ISR) staging points. You 
> are avoiding using High Performance Routing (HPR) - and rapid Transport 
> Protocol (RTP) - but actually this doesn't change this principle since the 
> RTP 
> end-points incorporate ISR architecture.
> 
> Incidentally, I asked for DISPLAY NET,BFRUSE output only because there was 
> an outside chance that your "performance" problem was related to VTAM 
> buffers. Since it really is a "hang" rather than an excessive delay, that is 
> not 
> so relevant. In fact, I can see you are hardly touching default basic buffer 
> allocations.
> 
> A way of testing the idea that it is when a request unit needs to be passed 
> over the connection which requires segmenting, we can try using DISPLAY 
> APING in order to send different request unit sizes. You should perform 
> a "binary search" starting with, since we may as well use the default mode 
> name #INTER which has RUSIZES=X'F7F7' which maps to a request unit size of 
> 1920 in both directions, SIZE=1920[1] and then 960 and so on. If all the 
> theory is correct, 1920 should fail. If it doesn't fail that's the end of the 
> test 
> and it's back to the "drawing board".
> 
> Incidentally, if you happen to have NetView Session Monitor, aka NLDM, 
> active, you can report what a primary trace with CPIU specified shows. In the 
> past, it was axiomatic that all SNA installations would have NLDM active and 
> NLDM was used immediately there was any suspicion of a problem with a 
> session - as here. Sadly this appears no longer to be the case, so problem 
> solving requires the so tedious use of GTF and VTAM buffer traces. Ideally I 
> would like to see what the request unit that gets sent by TSO but does not 
> arrive looks like, especially its size.
> 
> Getting back to the MAXDATA value: I invariably encourage not specifying the 
> MAXDATA operand when defining a PU statement for an adjacent link station 
> in a type 2.1 node since the adjacent link station logic will supply a value. 
> However it is always possible that the logic supporting the resource 
> representing the adjacent link station could respond to the MAXDATA value in 
> the control vector prepared by VTAM in a standard way from the PU 
> statement operand values. If t

Re: The PUT FTP not working with large files

[Andrew Armstrong]

Coincidentally, I was chasing up exactly the same symptom just last week and
came up with APAR PK71695...could be relevant (and has a testable workaround):

  ERROR DESCRIPTION:
  The DATACTTIME for the FTP client is not being set properly
  for send processing.  The result is the timer is not set and
  thus will never expire.
 
  ADDTIONAL SYMPTOMS: FTP client session terminate
  abruptly after the first EZA1485I message is issued
  with the following message:
  EZA2590E send error from send_data - EDC5120I Interrupted
  function call. (errno2=0x76690291).
 
  FTP Client receives EZA2590E only when TRACE is enabled. When
  tracing is disabled, problem does not occur.
 
 
  LOCAL FIX:
  Set DATACTTIME to 0.  This disbles the data connection timer.
  or
  Set PROGRESS to 0.  This disables the progress message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is ECS Safe?

[Vernooy, C.P. - SPLXM]

This ptf resolves shortcommings and is not Hiper.
So I assume it is safe now? 
How many sites are using it?

Kees.

"Staller, Allan"  wrote in message
news:<6cd8dd927eba514e9db1e36304be38d7117ad...@hou-mail.kbm1.loc>...
> Check out OA25219.
> 
> 
> Back in 2007 there was a problem with either ECS or Catalog Autotuning
> or both causing catalog corruption.  My recollection is that
Autotuning
> was the primary culprit.  I've done some searching and it looks like
> OA22246 is the end of the apar list.
> 
> Is ECS safe for use again?
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SMS temporary dataset question

[Vernooy, C.P. - SPLXM]

"phoggy"  wrote in message
news:<57dfa310-928f-4d32-8169-df60fb534...@y10g2000prc.googlegroups.com>
...
> Greetings,
> 
> I'm having an "issue" on my production system concerning SMS managed
> temporary datasets.
> 
> Temporary SMS managed datasets with a final disposition of old are
> being retained instead of deleted, e.g.:
> 
> //STEP000 EXEC PGM=IEFBR14
> //SYSPRINT  DD SYSOUT=*
> //DD01  DD DSN=&&TEMP,
> // DISP=(NEW,PASS),
> // DCB=(LRECL=80,BLKSIZE=32720,DSORG=PO,RECFM=FB),
> // UNIT=SYSDA,SPACE=(TRK,(50,10,45))
> //SYSIN   DD *
> //STEP001 EXEC PGM=IEBCOPY
> //SYSPRINT  DD SYSOUT=*
> //SYSUT1DD DISP=SHR,d...@cacsm5.jcl.cntl
> //SYSUT2DD DSN=&&TEMP,DISP=OLD
> //SYSINDD *
> 
> 
> results in :
> 
> .
> .
> .
> 
> IEF648I INVALID DISP FIELD- PASS SUBSTITUTED
> .
> .
> .
> IGD101I SMS ALLOCATED TO DDNAME (DD01)
> DSN (SYS09114.T112149.RA000.CA51289A.TEMP.H01)
> STORCLAS (TEST) MGMTCLAS () DATACLAS ()
> VOL SER NOS= CCAP08
> 
> .
> .
> .
> IGD104I SYS09114.T112149.RA000.CA51289A.TEMP.H01 RETAINED,
> DDNAME=SYSUT2
> 
> 
> This (seems) to only happen on my production LPAR and only with
> DISP=OLD coded. On the other LPARs, SMS managed temporary datasets are
> deleted at job/step termination. And jobs coded DISP=(,KEEP) etc have
> PASS substituted and their temporary datasets deleted.
> 
> The storage folks assure me all the LPARS use the same ACS routines
> and I'm pretty sure I've got the same maintenence applied, at least on
> my production and development LPARs.
> 
> So I figure its got to be a parameter somewhere but I'm out of places
> to look.
> 
> 
> Any thoughts from anybody?
> 
> 
> Cheers,
> 
> Steve McDonald

Steve,

The default second disposition is KEEP, so you indeed request it to be
retained in the last step.

Note: this newsgroup is a mirror of a list-server, where the vast
majority of the IBM-MAIN population resides and they will never read the
newsgroup posts. See the info attached automagically at the bottom.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where are the device codes (returned by LOCATE) defined?

[Binyamin Dissen]

On Sun, 26 Apr 2009 20:30:46 -0400 Gerhard Postpischil 
wrote:

:>Binyamin Dissen wrote:
:>> X’3010200E’ = 3380 DISK DEVICE CODE
 
:>> Where is the table defined?

:>There is no one table. The basic information is similar, but not 
:>identical to, fields UCBTBYT1-UCBTBYT4 in macro IEFUCBOB.

:>UCBTBYT3 (the x'20' above) is the device category, DASD in this 
:>case. These are defined in the UCB macro.

:>UCBTBYT4 (x'0E') is the device type, 3380 in this case.

:>The leading two bytes are device dependent, and may describe 
:>device characteristics and optional features (e.g., shared 
:>DASD). Some are in the UCB macro, most are not. They're 
:>scattered in documentation all over the place, usually hardware 
:>manuals or application notes.

I was hoping that there was some bit combination that would indicate a
migrated dataset.

Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html