Re: Remote Tape drives

[Ed Gould]

Bob,

I have been exposed to two different "channel extenders" over the  
years. Of the two each had its own weaknesses. I won't talk about  
brand names other than to say they were from different parts of the US.
The first (and second) seemed to drive IOS nuts and they were guilty  
of various errors which at least a few times brought the system down  
(these were attached to either a 4341 or a 168 (& 3033)). I had IBM  
ask me to strip out their logrec errors of the report as the number  
of errors at times amounted to several hundred a day.


Yes the damn things worked (sort of kind of) but the error recovery  
took its toll on MVS. The devices they had at the other end had  
response time issues which were hard to pin down as to where the  
issue was. The error recovery was part of issue of course but other  
items just kept on cropping up and (at times) it was a part time  
sysprog to baby sit the various issues.


In both cases when we got rid of the "devices" our issues  
disappeared. we replaced the box(s) with a 3745 and our reports made  
it to the end users in 30 minutes or less sometimes hours. Yes the  
3745 complicated life but we got everything to work in an extremely  
less intensive person/hour cost and the time that was sysprog took  
was at best minimal. It did cost human time but it was at a lower pay  
scale and he could actually help out operations doing thier job.


Just to clarify the 3745 did not support tape it was used what it was  
designed for.


Ed


 Dec 29, 2006, at 12:32 PM, Bob Shannon wrote:


CNT channel extender? Or do a Google search on "channel
extender"


I've used CNT at two companies. They're expensive but do
the job. At the first company the remote drives were about
1200 miles away.

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Using FTP on z/OS to get csv file from unix box running ipswitch ws_ftp.

[John S. Giltner, Jr.]

BillD wrote:

We're converting from VSE to z/OS.  I'm trying to upload a CSV file
that has worked on VSE but has problems with trunc/wrap, CRLF or
something else on Z/OS.

This is what works in VSE. The file dump below shows the second record
as part of the first then the third is part of the second, etc.

// EXEC BSTTFTPC,SIZE=BSTTFTPC   (Barnard Software)
ID 02
OPEN 
USER 
PASS 
CWD /ASN2MRP
OUTPUT SAM FTPU1 BLKSZ 16000 RECSZ 80 RECFM FB
TYPE A
pad on
padchar 64
RETR poeta.csv
QUIT

REC NO 1  119457,20060907,15360,008-0393-00,04,10854


FF66F6FFF66FF6FF6F44

119457B20060907B15360B00800393000B04B1085400

1...1020304050607080
REC NO 2  119447,20060907,7680,008-0347-00,04,10854


FF666FFF66FF6FF6F444

119447B20060907B7680B00800347000B04B10854000

1...1020304050607080
REC NO 3  119445,20060907,15360,008-0344-00,04,10854


FF66F6FFF66FF6FF6F44

119445B20060907B15360B00800344000B04B1085400

1...1020304050607080
REC NO 4  119453,20060907,7680,008-0390-00,04,10854


FF666FFF66FF6FF6F444

119453B20060907B7680B0080039B04B10854000

1...1020304050607080

FYI - these files aren't exactly the same.  One is on our VSE box, the
other on z/OS.
I started with this in z/OS but have tried numerous other options to no
avail.

//STEP0010 EXEC PROC=FTP
//FTPU1DD  DSN=&HLQ.PO.XF.FTPD.PU240.INPUT(+1),
// DISP=(NEW,CATLG,DELETE),
// LRECL=80,
// RECFM=FB
//SYSPRINT DD  SYSOUT=(X)
//SYSINDD  *
FS190
;CD /ASN2MRP
ASCII
site type i
get poeta.csv //DD:FTPU1
QUIT

Gives me this.
+...10+20+...30+...40+...50+...60+...70+...80
119447,20060907,7680,008-0347-00,04,10854
119447,20060907,15360,008-0347-00,04,
119447,20060907,15360,008-0347-00,04,10854
119445,20060907,15360,008-0344-00,04
119445,20060907,15360,008-0344-00,04,10854
119453,20060907,7680,008-0390-00,04,
119453,20060907,7680,008-0390-00,04,10854
119457,20060907,15360,008-0393-00,04,
119457,20060907,15360,008-0393-00,04,10854
119442,20060808,15360,008-0340-00,04
119442,20060808,15360,008-0340-00,04,10854

Should be this.
119447,20060907,7680,008-0347-00,04,10854
119447,20060907,15360,008-0347-00,04,10854
119445,20060907,15360,008-0344-00,04,10854
119453,20060907,7680,008-0390-00,04,10854
119457,20060907,15360,008-0393-00,04,10854
119442,20060808,15360,008-0340-00,04,10854

What I'm looking for is a way to properly pad the output replacing the
CRLF with a string of blanks to make an 80 byte record.
Does anyone have an example of FTP subcommands required for a good
result under z/OS?
I also tried IND$FILE via Extra.  It created a VB file on z/OS that was
fine.  I couldn't get FTP to properly copy to a VB File.  This is a
tough one!



What OS is the FTP server on?

You have "ASCII" so that z/OS client thinks the file transfer will be 
ASCII.  However you also issue the command "SITE TYPE I" which should 
tell the server to do a binary tranfer.  This means that the server will 
not put CRLF on the end of the record.


You should be able to remove the "site type i" command and as long as 
the source records are less than 80 bytes you should get what you want, 
using FB.


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

Re: Catalog Question

[Imbriale, Donald (Exchange)]

Harold,

You say "usually IBM tends to rename the sys1 files, moves them to other
volsers, 
changes sizes of files which tend to force file to different volsers.
etc.".  I may not understand what you mean by this, but I have not
really encountered these issues.

Many of the data sets are on the sysres (or its extensions) and the
catalog entries can use indirect volsers or symbols.  If it's on the
sysres for 1.4, it will probably be on the sysres for 1.7.  So the 1.4
catalog entry with volser ** will still work for 1.7; when you IPL a
1.4 sysres, those will point to that volume; when you IPL a 1.7 sysres,
they will point to the 1.7 sysres.  Other data sets tend to stay in
place also, whether it be a volume for 

HFS/zFS data sets or operational data sets such as SYS1.PARMLIB; so
catalog entries for 1.4 will still work for 1.7.

With each new release, you can use ServerPac to identify what data sets
are new and where they are located.  You can add those entries to your
master catalog without impacting the running of your 1.4 system, but
still be ready to run 1.7.

If IBM 'tends to rename the sys1 files' (which I don't really think they
do), add the new name to the catalog.  When you've completed conversion
to 1.7, then delete the old unneeded entries.

Don Imbriale

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Harold Zbiegien
Sent: Friday, December 29, 2006 3:34 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Catalog Question

Uh, could you (or any one else) expound on this?,

usually IBM tends to rename the sys1 files, moves them to other volsers,

changes sizes of files which tend to force file to different volsers.
etc.

And in our case, (just getting ready to install 1.7 into production) we
went 
from mod3 to mod 9 volumes for our opsystem packs.

I don't see how you can easily get away with not building a new master 
catalog.

- Original Message - 
From: "Imbriale, Donald (Exchange)" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, December 29, 2006 10:50 AM
Subject: Re: Catalog Question



Second, you can avoid this issue in the future by abandoning the process
of building a new master catalog for each new release of the operating
system.






***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

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

Re: Use of Java "jar" files supplied by IBM with z/OS products.

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Phil Sidler
> Sent: Friday, December 29, 2006 3:00 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Use of Java "jar" files supplied by IBM with 
> z/OS products.
> 
> 
> On Wed, 27 Dec 2006 12:25:27 -0600, McKown, John
> <[EMAIL PROTECTED]> wrote:
> 
> >files. Finally, I get to my question. Is it OK for me to download the
> >"jar" files to my workstation? I have absolutely NO idea 
> where to look
> >to see what the license is that would address this issue.
> 
> For CICS, as an example, the Licensed Program Specifications document
> explains what is allowed.  "Customers with a license ... are 
> licensed to
> make and use as many copies of applicable jar files as they 
> require"
> But, be sure to read it for yourself.
> 
> HTH
> 

Phil,

Thanks. I'll see if we have that around.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Use of Java "jar" files supplied by IBM with z/OS products.

[Phil Sidler]

On Wed, 27 Dec 2006 12:25:27 -0600, McKown, John
<[EMAIL PROTECTED]> wrote:

>files. Finally, I get to my question. Is it OK for me to download the
>"jar" files to my workstation? I have absolutely NO idea where to look
>to see what the license is that would address this issue.

For CICS, as an example, the Licensed Program Specifications document
explains what is allowed.  "Customers with a license ... are licensed to
make and use as many copies of applicable jar files as they require"
But, be sure to read it for yourself.

HTH

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

Re: Catalog Question

[Harold Zbiegien]

Uh, could you (or any one else) expound on this?,

usually IBM tends to rename the sys1 files, moves them to other volsers, 
changes sizes of files which tend to force file to different volsers. etc.


And in our case, (just getting ready to install 1.7 into production) we went 
from mod3 to mod 9 volumes for our opsystem packs.


I don't see how you can easily get away with not building a new master 
catalog.


- Original Message - 
From: "Imbriale, Donald (Exchange)" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, December 29, 2006 10:50 AM
Subject: Re: Catalog Question



Second, you can avoid this issue in the future by abandoning the process
of building a new master catalog for each new release of the operating
system.



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

Re: Remote Tape drives

[Ed Finnell]

 
In a message dated 12/29/2006 1:17:46 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

What  ever happened to those good old Mohawk data transfer  units



>>
Or the other ones? 37 somethings that took a 3420 and xMIT'd it over 9600  
bisynch...Look ma no hands

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

Re: Use of Java "jar" files supplied by IBM with z/OS products.

[Kirk Wolf]

Having Java .class files or jars on a NFS, Samba, or other remote file 
system can have negative impact on the application performance, 
especially application startup times.


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

Re: GRS alternatives

[Craddock, Chris]

> > It is entirely possible to share those resources in a
> > read-only manner across SYSPLEX boundaries. It is equally
> > certain that writing to a dataset (improperly) shared in that
> > manner will result in a broken dataset and grief to the
> > consumers on both sides. Ask me how I know

Dave said
> You either really know by looking at the "code" or you broke it on
> some occasion or other :)  Or both  and maybe on purpose http://bama.ua.edu/archives/ibm-main.html

Re: Use of Java "jar" files supplied by IBM with z/OS products.

[Kirk Wolf]

John,

I can say confidently that jar files produced on other platforms should 
work fine under z/OS.   We -always- produce our jars under Eclipse 
(using Ant and the "jar" task) using both Windows and Linux.We 
commonly download open source Java jars and upload them (in binary) for 
use on z/OS.  See the following for Java batch example Eclipse project 
which includes complete examples:


http://dovetail.com/downloads   (Java Batch XML sample project)

Notes:
- Java class files *according to the spec* contain UTF strings (for 
class names, etc)
- Java .properties resources, often bundled in a jar file, are 
*according to the spec* are ISO-8859-1.


The only possible problem is with *running* classes that have incorrect 
assumptions that all -Dfile.encoding will be "ascii", which might 
prevent the code from running properly if you run with say 
-Dfile.encoding=IBM-1047.   This has nothing to do with the jar though, 
just the naive programmer.The best way around this is simply to run 
the JVM with -Dfile.encoding=ISO8859-1  (or whatever ASCII-ish codepage 
that you like), but this can have other I/O implications.   This tends 
to occur less and less these days, but still happens in odd cases.   The 
latest Webphere AS for z/OS even runs JVMs with a default Ascii file 
encoding; I'm not sure about CICS or DB2.


Kirk Wolf
Dovetailed Technologies

PS. The "JZOS" batch Java functionality is now *included* in the latest 
service refreshes for z/OS SDK 1.4 and SDK 5.0.

See:  http://www-03.ibm.com/servers/eserver/zseries/software/java/

McKown, John wrote:

This question just occurred to me. If I am writing Java code that I want
to execute on z/OS, either batch or CICS, I want to use an desktop IDE
such as Netbeans or Eclipse. After all, why waste z/OS cycles doing Java
compiles? However, in order to easily use these IDEs, I need to be able
to access the appropriate "jar" files. I am running on a Windows XP Pro
system. There is no other option. I do not have an NFS client, so I
cannot NFS mount the z/OS UNIX subdirectories which contain the "jar"
files. Finally, I get to my question. Is it OK for me to download the
"jar" files to my workstation? I have absolutely NO idea where to look
to see what the license is that would address this issue.

This is more curiousity than anything else. The probability of this
company becoming interested in Java is very remote. But I can see some
uses for specialized applications. Too bad we're de-emphasizing the z
system environment.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

  


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

Re: Remote Tape drives

[R.S.]

Bruce Black wrote:

Also check out McData.com (also known as InRange) for channel 
extenders.  Like CNT, they have units that operate over IP


CNT is a part of McDATA for quite long time
Adva is part of CNT (which is a part...)
InRange is also part of McDATA

AFAIK, also McDATA was recently bought by Brocade...

So, we have Brocade, Cisco or niche players.
I don't like it. I like to have a choice. I like competition.

--
Radoslaw Skorupka
Lodz, Poland

P.S. Obviously all IBM-logo devices are OEM'ed.

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

Re: Remote Tape drives

[Crispin Hugo]

Thanks Bruce

Crispin Hugo
Systems Programmer, Macro 4





This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Remote Tape drives

[August Carideo]

What ever happened to those good old Mohawk data transfer units

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

Re: Remote Tape drives

[Bruce Black]

Also check out McData.com (also known as InRange) for channel 
extenders.  Like CNT, they have units that operate over IP


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

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

Re: Remote Tape drives

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Carol Srna
> Sent: Friday, December 29, 2006 1:04 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Remote Tape drives
> 
> 
> Oh No.  John said FlexES.  Please lets not get started on 
> lawsuits 
> again!!!hahahahahahahahaha...

What lawsuit? There is no lawsuit currently ongoing about FlexES. And
FLEXCUB is just based on portions of the FlexES software. The part that
emulates devices, not the part that emulates the zArchitecture
instructions.

Move along, nothing to see here! 

However, if desired I can go on and on and on about another lawsuit that
IBM has going at present. But that one has nothing to do with System z,
so I will not. .

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Remote Tape drives

[Carol Srna]

Oh No.  John said FlexES.  Please lets not get started on lawsuits 
again!!!hahahahahahahahaha...



"McKown, John" <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
12/29/2006 01:54 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Remote Tape drives






> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Crispin Hugo
> Sent: Friday, December 29, 2006 12:27 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Remote Tape drives
> 
> 
> Cheers John,
> I thought channel extenders had a finite distance , like 
> about 250k. I think
> we are looking for something which would be IP based
> 
> 
> Crispin Hugo
> Systems Programmer, Macro 4

Hum, I think that you are correct. But that is all that I have heard of.
The problem, as best as I can see it, is the slowness of the response
from the tape due to the extreme slowness of the speed of light. 

Now, I know of a possible way to do it, but it would be VERY indirect
and not "real time". Funsoft (http://www.funsoft.com), the makers of
FlexES, have a system called the FLEXCUB. This is based on FlexES, sort
of. What it does is make an Escon connected control unit. On the "back
end" it can use the device emulation software from FlexES to control
SCSI tape drives, emulated tape drives (AWS or FakeTape(tm) formatted
volumes which "look like" tapes to the z/OS system) and disk volumes.
What would be possible, but a real PAIN, would be to connect such a
thing to your zSeries locally. Have the z/OS (or z/VSE or z/VM or
z/Linux) write their data to an FakeTape(tm) volume which is on the
local FlexCUB system. Have this FlexCUB system, which runs Linux, export
the filesystem containing the FakeTape(tm) volumes using NFS or some
other such software. Now, on the far end, have another PC running Linux
with a SCSI attached tape drive import that filesystem. You'd likely
need to VPN the two systems together over the Internet or a dedicated IP
line (your choice). On the remote PC, have a daemon (or cron scheduled
task) which can copy the FakeTape(tm) to an actual physical tape. There
is a utility to do this from Funsoft. This would assume that the
FakeTape(tm) on the FLEXCUB system would always be considered the
authoritative source for the data on the particular volume.



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

Re: Remote Tape drives

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Crispin Hugo
> Sent: Friday, December 29, 2006 12:27 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Remote Tape drives
> 
> 
> Cheers John,
> I thought channel extenders had a finite distance , like 
> about 250k. I think
> we are looking for something which would be IP based
> 
> 
> Crispin Hugo
> Systems Programmer, Macro 4

Hum, I think that you are correct. But that is all that I have heard of.
The problem, as best as I can see it, is the slowness of the response
from the tape due to the extreme slowness of the speed of light. 

Now, I know of a possible way to do it, but it would be VERY indirect
and not "real time". Funsoft (http://www.funsoft.com), the makers of
FlexES, have a system called the FLEXCUB. This is based on FlexES, sort
of. What it does is make an Escon connected control unit. On the "back
end" it can use the device emulation software from FlexES to control
SCSI tape drives, emulated tape drives (AWS or FakeTape(tm) formatted
volumes which "look like" tapes to the z/OS system) and disk volumes.
What would be possible, but a real PAIN, would be to connect such a
thing to your zSeries locally. Have the z/OS (or z/VSE or z/VM or
z/Linux) write their data to an FakeTape(tm) volume which is on the
local FlexCUB system. Have this FlexCUB system, which runs Linux, export
the filesystem containing the FakeTape(tm) volumes using NFS or some
other such software. Now, on the far end, have another PC running Linux
with a SCSI attached tape drive import that filesystem. You'd likely
need to VPN the two systems together over the Internet or a dedicated IP
line (your choice). On the remote PC, have a daemon (or cron scheduled
task) which can copy the FakeTape(tm) to an actual physical tape. There
is a utility to do this from Funsoft. This would assume that the
FakeTape(tm) on the FLEXCUB system would always be considered the
authoritative source for the data on the particular volume.

Instead of NFS, it might be possible to use some "file transfer"
function such as ftp, scp, sftp, etc., to copy the data from the FLEXCUB
system to the remote PC. Or, heaven forfend, encrypt it and email it
.

If you need to send the otherway, then just reverse the direction of the
copy (I think).

The main problem that I can see with this is how to know that the z/OS
system has completed writing all the information to the tape so that it
can be known that it is ready to be written to the physical tape. I.e.
how to know that the tape is "complete" in the case where it contains
multiple datasets, perhaps created over the course of even days. I have
not thought about this. Now, the FLEXCUB software knows when z/OS has
issued a "rewind and dismount" CCW. Perhaps there is a "hook" on the PC
side which could trigger a Linux function of some sort. I would suggest
talking with Funsoft about this possibility.

Another problem is how to reconcile the z/OS tape label with the
physical tape label. I mean the one on the outside of the tape, the
copying will replace the internal tape label. But if the internal
doesn't match the external, "you have problems" . This might be
handled by something on the remote end conversing with the operator to
mount a particular tape volser, then doing VOL1 verification on the
remote PC before doing the actual tape copying.

I do not offer this as a good solution. But it is all that I can think
of. And I'm a bit bored due to the "hands off" that we are in due to
year end processing. I hope you, and all others, don't mind.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Remote Tape drives

[Crispin Hugo]

Tim,
I would envisage that the 'remote' have access to the mainframe to run the
jobs they require. Mount the tape required etc. Long distance operators !
Machine would think tape is local

Crispin Hugo
Systems Programmer, Macro 4





This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Remote Tape drives

[Tim Hare]

You'll need people at both ends for a tape drive, too - tape drives end up 
with all sorts of issues requiring operator intervention.

Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209


> That would work but does require that we have people at both end 
available.
> There may be a need to use this system over greater distances which 
would
> cause problems with time differences

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

Re: Remote Tape drives

[Crispin Hugo]

I will investigate CNT. Many thanks

Crispin Hugo
Systems Programmer, Macro 4





This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Remote Tape drives

[Crispin Hugo]

Tim, 
That would work but does require that we have people at both end available.
There may be a need to use this system over greater distances which would
cause problems with time differences


Crispin Hugo
Systems Programmer, Macro 4





This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Remote Tape drives

[Crispin Hugo]

Again, I agree about CD but many of our customers want tape. We have to bow
to their wishes.

Crispin Hugo
Systems Programmer, Macro 4
<

_



This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Remote Tape drives

[Bob Shannon]

>CNT channel extender? Or do a Google search on "channel 
>extender"

I've used CNT at two companies. They're expensive but do 
the job. At the first company the remote drives were about 
1200 miles away.

Bob Shannon
Rocket Software

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

Re: Remote Tape drives

[Tim Hare]

There are 3490-compatible drives that attach to PCs (one example: 
http://tapedrives-3480to3590.com/134-04-11025) .  Get one, use it to read 
the tape file at the PC end, then FTP the resulting file to your 
mainframe.


Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209



Crispin Hugo <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
12/29/2006 01:27 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Remote Tape drives






Cheers John,
I thought channel extenders had a finite distance , like about 250k. I 
think
we are looking for something which would be IP based


Crispin Hugo
Systems Programmer, Macro 4




This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Remote Tape drives

[R.S.]

Crispin Hugo wrote:


Chaps,
Any suggestions on ways we could have a tape  drive 3490  in a remote
location attached to our mainframe. We are talking about 1 thousand of
miles. Speed is not important 


Use ftp instead ?
Transmitted files could be:
a) recorded on CD or DVD,
b) use "locally attached" mainframe to record tapes, even in friendly 
location, using those DVDs as a source.

c) use some software + PC attached 3490.
Otherwise use channel extenders - both link and devices will be expensive.

IMHO CD is better than 3490. Every shop has at least one PC with CD 
drive, while not every one has such model of tape drives.


My $0.02.

Regards
--
Radoslaw Skorupka
Lodz, Poland

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

Re: Remote Tape drives

[Crispin Hugo]

Cheers John,
I thought channel extenders had a finite distance , like about 250k. I think
we are looking for something which would be IP based


Crispin Hugo
Systems Programmer, Macro 4




This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

IBM VTS Stacking Cartridges

[Campbell Jay]

If anyone has an well loaded, active VTS and you plan on replacing 
J type cartridges with K types on the back end...
DO NOT order the same VOLSER range.
It will ruin your day.

Enjoy.

j  

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

Re: Remote Tape drives

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Crispin Hugo
> Sent: Friday, December 29, 2006 12:16 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Remote Tape drives
> 
> 
> Chaps,
> Any suggestions on ways we could have a tape  drive 3490  in a remote
> location attached to our mainframe. We are talking about 1 thousand of
> miles. Speed is not important 
>  
> Crispin Hugo

CNT channel extender? Or do a Google search on "channel extender"

http://www.bealltech.com/beallexl.htm

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Remote Tape drives

[Crispin Hugo]

Chaps,
Any suggestions on ways we could have a tape  drive 3490  in a remote
location attached to our mainframe. We are talking about 1 thousand of
miles. Speed is not important 
 
Crispin Hugo
Systems Programmer, Macro 4
 >
Macro 4 plc, The Orangery, Turners Hill Road, Worth, Crawley, RH10 4SS
Direct Line: +44 (0)1293 872121 Switchboard: +44 (0) 1293 872000
Fax: +44 (0) 1293 872001
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This message is
provided for informational purposes and should not be construed as a
solicitation, offer or acceptance of any offer.
 



This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Catalog Question

[Rick Fochtman]

---
In the LPALST, the syntax is:

dsn(volser)

Thanks, John

Rick

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

Re: Using FTP on z/OS to get csv file from unix box running ipswitch ws_ftp.

[Roger Bolan]

When I use FTP on z/OS to retrieve files, I use the LOCSITE command to set 
the DCB attributes for the target files.
For example, if I want to retrieve a large tersed file, I first issue the 
BIN command to be in binary mode and then I issue 
locsite recfm=fb lrecl=1024 blksize=0 cylinders primary=100 secondary=100 

This is when I'm using FTP from the z/OS end.   If I were doing a put from 
the other end, I think the same options would apply, but the command to 
set them might be SITE instead of LOCSITE. 

Regards,
Roger Bolan

IBM Printing Systems Division 
Visit our Web site at http://www.ibm.com/printers.

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

Re: Catalog Question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman
> Sent: Friday, December 29, 2006 10:15 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Catalog Question
> 
> 
> I have to agree with Don. If something needs to be in the linklist or 
> LPA list, I try to find another way. For instance, in the 
> LINKLIST, I'll 
> refer to the dataset with a vol-ser reference. I don't recall ever 
> having something that needed to be in the LPALIST, so I'm 
> unsure how to 
> handle that situation. I try to avoid anything that might 
> require MCAT 
> updates, such as re-installing a OEM product. ANY update to a 
> catalog, 
> no matter how trivial it seems, poses a risk of damage and 
> the MCAT is 
> the "Sacred Cow" of your system. Damage might mean a 
> disastrous outage.
> 
> Rick

In the LPALST, the syntax is:

dsn(volser)

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Catalog Question

[Rick Fochtman]

I have to agree with Don. If something needs to be in the linklist or 
LPA list, I try to find another way. For instance, in the LINKLIST, I'll 
refer to the dataset with a vol-ser reference. I don't recall ever 
having something that needed to be in the LPALIST, so I'm unsure how to 
handle that situation. I try to avoid anything that might require MCAT 
updates, such as re-installing a OEM product. ANY update to a catalog, 
no matter how trivial it seems, poses a risk of damage and the MCAT is 
the "Sacred Cow" of your system. Damage might mean a disastrous outage.


Rick
-
Imbriale, Donald (Exchange) wrote:


First, I don't usually put OEM stuff in the master catalog unless it
absolutely positively has to be there.  OEM stuff is better of in a
usercat.  Doing so makes it easier to get to those products from other
systems with other mastercats.

Second, you can avoid this issue in the future by abandoning the process
of building a new master catalog for each new release of the operating
system.

To handle your situation now you could just DEFINE entries in the 1.7
mastercat for the data sets that you need.  This would work only for
non-VSAM entries.  For VSAM data sets, you can do a DEFINE RECATALOG,
but only if the high-level qualifier is SYS1.

To help build new entries for the 1.7 mastercat, you could check out
Alistair Gray's REXX-based RCNVTCAT (or is it RCATCNVT?) on the CBT
'tape'.

Don Imbriale
 



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

Re: unsubscribe

[Bruce Black]

---

Marcin, you can't get off the list by sending a message to the list 
itself.

See the notes at the bottom of EVERY email on the list for unsubscribe
instructions.

Or go to this link to unsubscribe:
http://bama.ua.edu/cgi-bin/wa?SUBED1=ibm-main&A=1

--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

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

Re: Catalog Question

[Imbriale, Donald (Exchange)]

First, I don't usually put OEM stuff in the master catalog unless it
absolutely positively has to be there.  OEM stuff is better of in a
usercat.  Doing so makes it easier to get to those products from other
systems with other mastercats.

Second, you can avoid this issue in the future by abandoning the process
of building a new master catalog for each new release of the operating
system.

To handle your situation now you could just DEFINE entries in the 1.7
mastercat for the data sets that you need.  This would work only for
non-VSAM entries.  For VSAM data sets, you can do a DEFINE RECATALOG,
but only if the high-level qualifier is SYS1.

To help build new entries for the 1.7 mastercat, you could check out
Alistair Gray's REXX-based RCNVTCAT (or is it RCATCNVT?) on the CBT
'tape'.

Don Imbriale

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Daniel McLaughlin
Sent: Friday, December 29, 2006 8:50 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Catalog Question

I've been digging in the archives, haven't hit this yet.

We're starting to test 1.7, have 1.4 in production and on our sandbox. I

want to be able to use some HLQs that are in the 1.4 mastercat so I can 
get to my OEM stuff on 1.7. I'm not ready for the mergecat step just
yet, 
at least I don't think so. Should I just import/connect the 1.4 master
to 
the 1.7 master, do my testing, then unhook the 1.4 master and do the 
mergecat prior to cutover?

It may seem like a rookie question, but in the past I was not the lead
on 
this type of project and my mentors were not apt to divulge this type of

process, for whatever reason.




***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

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

Re: Catalog Question

[Tom Marchant]

On Fri, 29 Dec 2006 07:50:10 -0600, Daniel McLaughlin wrote:

>We're starting to test 1.7, have 1.4 in production and on our sandbox. I
>want to be able to use some HLQs that are in the 1.4 mastercat so I can
>get to my OEM stuff on 1.7. I'm not ready for the mergecat step just yet,
>at least I don't think so. Should I just import/connect the 1.4 master to
>the 1.7 master, do my testing, then unhook the 1.4 master and do the
>mergecat prior to cutover?
>

It depends.  First of all, I'm not sure why you have different
master catalogs.  And I'm not sure you want to do a REPRO MERGECAT
at all.  That will remove the entries from your source catalog.

That said, you can certainly IMPORT CONNECT yout other master
catalog and define aliases for those HLQs.  Of course, this won't
help if you need the data sets in the master catalog, e.g. because
they are in LNKLST or LPALST.

You can also use DEFINE NONVSAM to catalog them in your new catalog.

-- 
Tom Marchant

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

Re: Using FTP on z/OS to get csv file from unix box running ipswitch ws_ftp.

[Gilbert Saint-Flour]

Bill,

I have converted thousands VSE FTP (BSI and CSI) steps to z/OS 
but can't remember experiencing the symptoms you describe.

I'd like to help, but can you send me a copy of the Unix file to run some 
tests?  Go to the Support page of the GSF-Soft Web site and contact me 
off-line.  

Happy new year to all !!

-- 
 Gilbert Saint-Flour
 GSF Software
 http://gsf-soft.com/


On Thursday 28 December 2006 14:49, BillD wrote:

> We're converting from VSE to z/OS.  I'm trying to upload a CSV file
> that has worked on VSE but has problems with trunc/wrap, CRLF or
> something else on Z/OS.
> 
> This is what works in VSE. The file dump below shows the second record
> as part of the first then the third is part of the second, etc.
> 
> // EXEC BSTTFTPC,SIZE=BSTTFTPC   (Barnard Software)
> ID 02
> OPEN 
> USER 
> PASS 
> CWD /ASN2MRP
> OUTPUT SAM FTPU1 BLKSZ 16000 RECSZ 80 RECFM FB
> TYPE A
> pad on
> padchar 64
> RETR poeta.csv
> QUIT
> 
> REC NO 1  119457,20060907,15360,008-0393-00,04,10854
FF66F6FFF66FF6FF6F44
119457B20060907B15360B00800393000B04B1085400
1...1020304050607080
>
> REC NO 2  119447,20060907,7680,008-0347-00,04,10854
FF666FFF66FF6FF6F444
119447B20060907B7680B00800347000B04B10854000
1...1020304050607080
>
> REC NO 3  119445,20060907,15360,008-0344-00,04,10854
FF66F6FFF66FF6FF6F44
119445B20060907B15360B00800344000B04B1085400
1...1020304050607080
>
> REC NO 4  119453,20060907,7680,008-0390-00,04,10854
FF666FFF66FF6FF6F444
119453B20060907B7680B0080039B04B10854000
1...1020304050607080
> 
> FYI - these files aren't exactly the same.  One is on our VSE box, the
> other on z/OS.  I started with this in z/OS but have tried numerous other
> options to no avail.
> 
> //STEP0010 EXEC PROC=FTP
> //FTPU1DD  DSN=&HLQ.PO.XF.FTPD.PU240.INPUT(+1),
> // DISP=(NEW,CATLG,DELETE),
> // LRECL=80,
> // RECFM=FB
> //SYSPRINT DD  SYSOUT=(X)
> //SYSINDD  *
> FS190
> ;CD /ASN2MRP
> ASCII
> site type i
> get poeta.csv //DD:FTPU1
> QUIT
> 
> Gives me this.
> +...10+20+...30+...40+...50+...60+...70
+...80
> 119447,20060907,7680,008-0347-00,04,10854
> 119447,20060907,15360,008-0347-00,04,
> 119447,20060907,15360,008-0347-00,04,10854
> 119445,20060907,15360,008-0344-00,04
> 119445,20060907,15360,008-0344-00,04,10854
> 119453,20060907,7680,008-0390-00,04,
> 119453,20060907,7680,008-0390-00,04,10854
> 119457,20060907,15360,008-0393-00,04,
> 119457,20060907,15360,008-0393-00,04,10854
> 119442,20060808,15360,008-0340-00,04
> 119442,20060808,15360,008-0340-00,04,10854
> 
> Should be this.
> 119447,20060907,7680,008-0347-00,04,10854
> 119447,20060907,15360,008-0347-00,04,10854
> 119445,20060907,15360,008-0344-00,04,10854
> 119453,20060907,7680,008-0390-00,04,10854
> 119457,20060907,15360,008-0393-00,04,10854
> 119442,20060808,15360,008-0340-00,04,10854
> 
> What I'm looking for is a way to properly pad the output replacing the
> CRLF with a string of blanks to make an 80 byte record.
> Does anyone have an example of FTP subcommands required for a good
> result under z/OS?
> I also tried IND$FILE via Extra.  It created a VB file on z/OS that was
> fine.  I couldn't get FTP to properly copy to a VB File.  
> This is a tough one!  

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

Re: Catalog Question

[Jack Kelly]

I've found that the easiest and safest way is to stick to the alias', just 
like the servpac creates.

Jack Kelly
LA Systems @ US Courts
x 202-502-2390

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

Catalog Question

[Daniel McLaughlin]

I've been digging in the archives, haven't hit this yet.

We're starting to test 1.7, have 1.4 in production and on our sandbox. I 
want to be able to use some HLQs that are in the 1.4 mastercat so I can 
get to my OEM stuff on 1.7. I'm not ready for the mergecat step just yet, 
at least I don't think so. Should I just import/connect the 1.4 master to 
the 1.7 master, do my testing, then unhook the 1.4 master and do the 
mergecat prior to cutover?

It may seem like a rookie question, but in the past I was not the lead on 
this type of project and my mentors were not apt to divulge this type of 
process, for whatever reason.

Many thanks and Happy New Year!!

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

unsubscribe

[Dietri Dorsey]

--
E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: TLMS CopyCat Utility

[Robert Fake]

Hi Carlos,

CA CopyCat Link below.  Perfect for migrating to VTS.  To summarize:

BrightStor™ CA-Dynam®/TLMS Tape Management Copycat Utility provides advanced
software to assist the user with tape media conversions, media
consolidation/stacking and media replacement operations. BrightStor
CA-Dynam/TLMS Copycat Utility also helps in disaster recovery by
facilitating tape
backup and electronic vaulting. BrightStor CA-Dynam/TLMS Copycat is a
powerful utility designed to help the user copy data from tape to tape while
retaining the BrightStor CA-Dynam/TLMS Tape Management database attributes.

http://www3.ca.com/solutions/Overview.aspx?ID=1060
http://www3.ca.com/Files/DataSheets/brightstor_dynamtlms_copycatutility_pa.p
df

I hope this is helpful.

Bob
Robert B. Fake
InfoSec, Inc.
703-825-1202 (o)
571-241-5492 (c)
949-203-0406 (efax)
[EMAIL PROTECTED]
Visit us at www.infosecinc.com
-Original Message-




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Carlos Bodra
Sent: Thursday, December 21, 2006 2:45 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: TLMS CopyCat Utility

Some time ago I sent to IBM-Main list a question about migration of old
3480/90 physical cartridges to a VTS subsystem. Someone sends me an e-mail
telling about COPYCAT.

Carlos Bodra

zSeries System Programmer

São Paulo - SP - Brazil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

unsubscribe

[Marcin Blaszczyk]

--
MARCIN BLASZCZYK

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

Re: GRS alternatives

[Shane]

On Thu, 2006-12-28 at 23:33 -0800, Gibney, Dave wrote:

> ... or you broke it on some occasion or other :)
> Or both  and maybe on purpose http://bama.ua.edu/archives/ibm-main.html

Re: Use of Java "jar" files supplied by IBM with z/OS products.

[Jan MOEYERSONS]

>I do not have an NFS client, so I
>cannot NFS mount the z/OS UNIX subdirectories which contain the "jar"
But you could use dfsSMB to create a Windows-type share on your mainframe 
and map that to a drive letter on your PC. Requires a bit of set-up in 
order to get security right (and authentication transparent...) but then 
you do not have to download anything (nor upload for that matter). You just 
use the directories on the mapped drive to read the jar files and to write 
the ones you produce from your IDE.

>files. Finally, I get to my question. Is it OK for me to download the
>"jar" files to my workstation? I have absolutely NO idea where to look
>to see what the license is that would address this issue.
I would expect the licensing being dependent on the product. Shouldn't that 
be mentioned somewhere in the program directory of said product?

Cheers,

Jantje.

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