Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Looking for a little advice/assistance VTAPE

45 views
Skip to first unread message

Mike Robertson

unread,
Dec 29, 2016, 2:30:25 PM12/29/16
to
Hi all....
 
We are prepping for a move from a z114 to a z13s in a couple of months.     We will lose our ESCON connected VTA appliance (they don't have a ficon version).    We don't do a lot of tape, average night 4 backups and 2 restores, that's it, except for a 3 or 4 weekly backups.
 
So our plan is to use VTAPE with a Linux (on z114/z13s IFL) tape server pointing at our V7000.   Then backup that data to our disk to disk to cloud (via NFS) appliance.
 
Anyway something consistently weird.  I built a Rexx program to keep track of volumes and generate then file name for each VTAPE.   Kinda of a simple catalog.   It saves data to a LIBR member and generates // SETPARM statements used by the VTAPE statement to create the filename.   All I/O (outside of card and LIBR) is done in JCL.
 
If I don't use the Rexx program and hand key the SETPARM statements, everything works fine, but if I use my  Rexx program, I get I/O errors when I initialize and use the VTAPE.   I have keep simplifying my program, but it is consistent, Rexx bad, hand keyed good.
 
Errors I get, from INTTP
 
1YM4I  TAPE DATA HANDLER INITIALIZATION COMPLETED             
1YM6I  TAPE DATA HANDLER ACCESSED SPECIFIED FILE SUCCESSFULLY 
// ASSGN SYS000,593                                           
// EXEC INTTP                                                 
PASS 01 OF TAPES ASSIGNED                                     
SYS000                                                        
VOL11111110                              RRWRD                
                                                              
END OF JOB                                                    
0P13I P  END OF VOL SYSCTL=593                                
CCSW=4300103E4802000001 CCB=00103E30                          
SNS= 104C2038 00000220 00000000 00000198 00C80088 04430703    
     1F0100F0 000033FF                                        
0P96I  BUFFERED DATA FOR UNIT=593 HAS BEEN LOST               
/. STEP2                                                      
*                    
 
Any thoughts on a line of reasoning to use on this?  
 
Thanks
Mike                                         

------- DISCLAIMER -----------------------------------------------------------------------------------------------------------------------

This message and any attachments are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. If you are not one of the addressees you may not copy, forward, disclose or use any part of the message or its attachments. If you have received this message in error, please notify the sender immediately by return e-mail and delete it from your system. The sender does not accept liability for any errors or omissions in the context of this message that arise as a result of Internet transmission. Sender accepts no liability for any damages caused by any virus transmitted by this email. Any opinions contained in this message are those of the author and are not given or endorsed by the Rock River Water Reclamation District (RRWRD) unless otherwise clearly indicated in this message and the authority of the author to so bind the RRWRD referred to is duly verified.

------- DISCLAIMER --------------------------------------------------------------------------------------------------------------------------

Stuart, David

unread,
Dec 29, 2016, 2:40:35 PM12/29/16
to

Mike,

 

How are you setting the parameters from your REXX proc? My first thoughts would be related to mismatched single or double quotes, or not ‘escaping’ a single quote in the proper manner when you need a single quote as part of your ‘data’ stream.

 

 

Dave

Kevin Corkery

unread,
Dec 29, 2016, 2:48:24 PM12/29/16
to

Did something like this back in my VSAM VTAPE configuration but I did it all in JCL.  The tapes internal volume numbers where basically unimportant and were generally a constant.  However, the file names were all unique based on the date (or cycle) of the run.  This was formulated and stored in a LIBR member that was SLIed into the job stream.  My understanding is that REXX is like a proc in that symbols are not passed back to the level above automatically.  This could be key to your problem.  In any case, I love the VTA but the z114 is our last soldier so we’ll live with ESCON to the bitter end.  We handle the VTA much the same way in that all out files are a unique name on the VSE label so it tracks really well by the DOS file name.

From: VSE-L [mailto:vse-l-bounces+kcorkery=live...@lists.lehigh.edu] On Behalf Of Mike Robertson
Sent: Thursday, December 29, 2016 2:30 PM
To: List VSE
Subject: Looking for a little advice/assistance VTAPE

 

Hi all....

Jeffrey Barnard

unread,
Dec 29, 2016, 3:00:43 PM12/29/16
to
Have you tried using DITTO to initialize the tape?

VTAPE START,UNIT=590,LOC=10.1.1.1,FILE='tapes/file.name.aws'
// ASSGN SYS005,590
// MTC REW,SYS005
* STEP 1, DITTO INT
// UPSI 1
// EXEC DITTO,SIZE=256K
$$DITTO INT OUTPUT=SYS005,VOLSER=000004
$$DITTO REW OUTPUT=SYS005
/*
// UPSI 0
// RESET SYS005
/*
...
...
...


Perhaps if you post the REXX you are using we could help more.

Regards,
Jeff

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l

Mike Robertson

unread,
Dec 29, 2016, 3:01:49 PM12/29/16
to
Yep, same results....   M

Martin Truebner

unread,
Dec 30, 2016, 2:48:12 AM12/30/16
to
Mike,

I have not realy mastered what you do- however Davids post points IMHO
in the right direction.

The problem is that REXX (procs) do only expose the value of
changed/created variables to the higher level if these variables were
exposed/passed to them.

as an alternative you might want to include the JCL which uses them
also into the REXX-proc.

so this is one way

// EXEC REXX=SETMYV,MYVAR,U
VTAPE &MYVARV
// ASSGN SYS000,&U
// ExEC INTTAP

this is the other

// EXEC REXX=PREPTP
// EXEC INTTAP

Martin

indust...@winwholesale.com

unread,
Dec 30, 2016, 10:45:40 AM12/30/16
to
"VSE-L" <vse-l-bounces+industrynews=winwhole...@lists.lehigh.edu> wrote on 12/29/2016 02:30:03 PM:
> Anyway something consistently weird.  I built a Rexx program to keep
> track of volumes and generate then file name for each VTAPE.   Kinda
> of a simple catalog.   It saves data to a LIBR member and generates
> // SETPARM statements used by the VTAPE statement to create the
> filename.   All I/O (outside of card and LIBR) is done in JCL.

>  
> If I don't use the Rexx program and hand key the SETPARM statements,
> everything works fine, but if I use my  Rexx program, I get I/O
> errors when I initialize and use the VTAPE.


        Yes, sounds like a problem of execution levels.  REXX executes one level down (up) from your native JCL level jsut like PROCs do.  You have to SETPARM the symbol at the native JCL level, first, and then pass that symbol down (up) to the REXX level so that when REXX changes it the value will bubble up to the native JCL level when the REXX procedure ends.  FAIK, using ADDRESS JCL in your REXX proc to execute SETPARM statements goes down yet another level.  Experimentation would prove that out.  In my case, I wrote my own REXX function in assembler so that I can both retrieve and set symbolic parameters at the REXX level.  But, these still have to be passed both down to the REXX execution level and then back up to the native JCL level.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331




*********************************************************************************************
This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission.
*********************************************************************************************
0 new messages