Thesaurus REXX - The Travelling Toolbox - Part 1
Over the course of the Thesaurus REXX blogs I intend helping build a tool kit of useful REXX programs to form part of your armoury for tackling the challenges your job throws at you. But before giving you a loose collection of programs, I think the best starting point is a box to put them in. The Travelling Toolbox.
Most folks start writing REXX programs in their own personal library, then maybe get their friendly Systems Programmer to help get them included in your TSO concatenation, and before you know it you are relying on these execs to help out in your day to day job.
But then there comes the day when you want to move them to pastures new, be that other LPARS in your existing systems, or other parts of your network, not so accessible, maybe newly acquired companies in your organisation. So there's often the problem then of getting these libraries included in the new environment so you can use them, you can't always find a friendly Sysprog in the early days. This can lead to hours of frustration trying to find a way to get them included in, what is to you, a new alien environment.
So we have two challenges here, porting the code, and getting it into the TSO concatenation. You can probably easily do both of these in your own environment, but somewhere new, can be a challenge. Over the next few Blogs I will show you how to move your toolbox around, get it included in your environment and finally some basic tools to make that process easy to do.
Porting the PDS within z/OS
Getting your toolbox from one system to another can be quite simple if your LPARS are connected in some way. The TSO TRANSMIT command allows you to transmit a z/OS PDS from one JES Node to another.
e.g. TSO TRANSMIT mynode.myuser DA('my.toolbox.rexx')
What this does is package up the PDS into a sequential transmit format and sends it to the named user on the named JES node. When it gets there, the recipient will get a TSO notify message, or when they next logon, and they can get it loaded onto their new system by using the TSO RECEIVE command.
e.g. TSO RECEIVE
Then you get something like this -
INMR901I Dataset MY.TOOLBOX.REXX from HISUSER on HISNODE
INMR154I The incoming data set is a 'DATA LIBRARY'.
INMR906A Enter restore parameters or 'DELETE' or 'END' +
To which you can reply with details of exactly what you want to call the library on your new system.
This will then unpack the transmitted creating the library you named.
Of course that might not be so easy to do, especially with new systems, as you may not know the JES node name to which you want to transmit. But it's easy to find out, if you happen to have a login ID to the destination system. You can simply logon to TSO, on the destination LPAR and enter the Dialog Test Variables function (PDF option 7.3) then scroll down until you see variable ZSYSNODE, which contains the information you need.
Menu Utilities Help
Variables - Application: ISR Row 73 to 84 of 531
Command ===> ____________________________________________ Scroll ===> PAGE
Add, delete, and change variables. Underscores need not be blanked.
Enter END command to finalize changes, CANCEL command to end without
Current scrollable width of variables is: 1163
Variable P A Value
____ ZSCTSRCH S N B
____ ZSDATA S H User ID . :.MYUSER Time. . . :.10:22 Terminal. :.32
____ ZSEQ S N 00225
____ ZSESS S N N
____ ZSPLIT S N NO
____ ZSSHDW S H ............. ............. .............
____ ZSTDYEAR S N 2014
____ ZSWIND S N 0065
____ ZSYSID S N MYNODE
____ ZSYSNODE S N MYNODE
____ ZSYSPLEX S N MYPLEX
____ ZSYSPROC S N IKJLOGON
So with that information to hand you can port your library across to any LPAR that is connected within the JES network.
Porting the PDS outside of z/OS
But what if you can't use the TRANSMIT command? Not all JES systems may be visible to the one where your toolbox currently lives, especially for newly acquired systems they may be in entirely separate networks, so you have to go outside of z/OS and JES to move them in that case.
There are a couple of problems with taking mainframe data outside of z/OS, one being the fact that z/OS using EBCDIC for it's character set, whereas the Windows/Unix/Linux world uses ASCII. Another being that the distributed world doesn't understand partitioned datasets in any real terms.
However, one of TRANSMIT's best kept secrets is that as well as transmitting to another user, you can transmit to a dataset. So you can do this -
TSO TRANSMIT mynode.myuser DA('my.toolbox.rexx') OUTDSN('my.toolbox.rexx.xmit')
What happens here is that the PDS is unloaded into sequential form as a fixed block dataset with a record length of 80. This dataset can then travel easily through the distributed world with few problems.
To move this you can send it to your PC using either your 3270 emulator's file transfer process, or start an FTP session between your PC and z/OS. The key thing is, whichever mechanism you use, you MUST transfer the file as a Binary transfer.
If you want to use FTP, but don't know the IP address of your mainframe, you can find out by issuing the following console command (assuming you have access) -
Which will give you a response something like this -
EZZ2500I NETSTAT CS V1R13 TCPIP 257
HOME ADDRESS LIST:
ADDRESS LINK FLG
192.168.1.109 ETH1 P
3 OF 3 RECORDS DISPLAYED
END OF THE REPORT
And you should be able to use at least one of those addresses to connect via FTP.
Once the file is on your PC, you can then transfer it to the destination LPAR by whatever method works to get files from one network to another. If the networks are entirely separate you might even be able to email the file as an attachment from your email ID in one network, to one in the other.
Once there you can send the file back up to the mainframe, again using either the emulator's file transfer process or FTP. The key points this time being you must send the file both as Binary AND as a Fixed file with a record length of 80.
Then the file can be received almost the same way as you would receive a JES transmission. Instead of just RECEIVE you need to also specify the dataset you want to receive from. Which you can do in one of two ways. As a TSO command you can issue -
TSO RECEIVE INDSN('my.toolbox.rexx.xmit')
Or, slightly easier, you can enter the RECEIVE command as a line command against the dataset in the dataset list from PDF option 3.4. Using / to represent the dataset name from the list.
Menu Options View Utilities Compilers Help
DSLIST - Data Sets Matching MY Row 1 of 3
Command ===> _________________________________________________ Scroll ===> CSR
Command - Enter "/" to select action Message Volume
receive indsn(/) OX.REXX.XMIT ZPDEV0
************************** End of Data Set list **************************
In both cases, from this point on, the process is exactly the same as receiving from a JES transmission, so you need to specify the dataset name into which you want to receive your toolkit.
So this helps to get your toolkit from one place to another, in the next blog we will look at how to get your library in a position where you can use it.