KTomiak.biz Interactive Data Transfer File (IDTF) - Exposed V1R1 Effective Date: February 11, 2014 IMPORTANT: THE INFORMATION YOU ARE ABOUT TO VIEW IS, TO THE BEST OF MY KNOWLEDGE, TOTALLY ACCCURATE.
Front Matter This is here to force the next page to a new sheet of paper. If you are not using double sided printing then shame on you. IDTF-Exposed Page 2 of 30
Front Matter 1.1 Section - Front Matter 1.1.1 Copyright This document is protected under applicable copyright laws. It contains knowledge gained from licensed, proprietary information from the vendor manuals and macros. Give credit to vendors for what they own and to Kenneth for what Kenneth discovered. 1.1.2 Apologies This is a long overdue piece of documentation. It is, to the best of my knowledge, accurate. However, if you find something wrong then please do let me know and I will correct the mistake. I have deduced some of what I have documented based on what actually appears in files created on a z/os 1.13 system and on a z/vm 6.2 system. Older systems may have done other things. The oldest IDTF that I have was created in 2003. GOOGLE was a big help in parsing the directory entry user data fields. PROPRIETARY STATEMENT: This contains licensed, proprietary information from IBM Corporation manuals and macros. IDTF-Exposed Page 3 of 30
Front Matter 1.1.3 Table of Contents 1.1 Section - Front Matter... 3 1.1.1 Copyright... 3 1.1.2 Apologies... 3 1.1.3 Table of Contents... 4 1.1.4 Acknowledgements... 6 1.2 Preface... 7 1.2.1 Discussion - What purpose the IDTF-Exposed serves... 7 2. Section - Basics... 8 2.1 Chapter - General Information... 9 2.1.1 Discussion - Introduction... 9 2.1.2 Discussion - Media... 9 2.1.3 Discussion - Transport methods... 9 2.1.4 Discussion - Data formats... 9 4.1 Chapter - Create an IDTF... 10 4.1.1 Discussion - Why... 10 4.1.2 Discussion - What... 10 4.1.3 Discussion - How... 11 4.1.3.1 Discussion - what you need to start... 11 4.1.4 Discussion - What can you do... 11 4.2 Chapter - Download to your personal computer... 14 4.2.1 Discussion - file transfer as opposed to file transfer protocol... 14 4.2.2 Procedure - Windows command prompt FTP client... 14 4.2.2.1 Activity - Retrieve a data set... 14 4.2.2.2 Activity - Retrieve from the JES spool... 14 4.2.2.3 Action FTP session... 14 4.3 Chapter - What you will find in an IDTF... 16 4.3.1 Discussion - IDTF control records... 16 4.3.1.1 ITDF Control Records... 16 4.3.1.2 ITDF Control Record Text Unit Keys (TUK)... 17 5. Section - IDTFRDR... 19 5.1 Chapter - oorexx... 20 5.1.1 Discussion - Runtime environment expectations... 20 5.1.2 Discussion - DEBUG... 20 5.1.3 Discussion Executing IDTFRDR.rex... 20 5.1.3.1 Action Process one file... 21 5.1.3.2 Action Process a group of files... 22 5.2 Chapter - PowerShell... 23 5.2.1 Discussion - Runtime environment expectations... 23 6. Section - IDTFSEND... 24 6.1 Chapter - SEND PC files... 25 6.1.1 Discussion - Dreaming, I like dreaming... 25 6.1.2 Procedure - Build a DSORG=PO like structure... 25 6.1.2.1 Action What DCB(RECFM,BLKSIZE,LRECL) should be used... 25 7. Section - Appendixes... 26 7.1 Bibliography... 27 IDTF-Exposed Page 4 of 30
Front Matter 7.1.1 Discussion - Things you may want to reference yourself.... 27 7.2 Alphabetical Index... 28 8. Section - End of IDTF-Exposed... 29 8.1 End of Document... 30 IDTF-Exposed Page 5 of 30
Front Matter 1.1.4 Acknowledgements People have spent countless hours developing programs to extract data from an Interactive Data Transmission File. It all began with IBM Corporation coming up with the Interactive Data Transmission File specification for sharing files between systems. It transitioned to the personal computer environment when people started downloading the output from the TRANSMIT command to the PC and then wanted to see what was in it. This is not an exhaustive list, however it can grow if you know more than I am aware of. Name IBM Corporation David Alcock Patrick Allmond Tachyon Software, LLC Roland Scholz Enriqo Gerhard Kenneth Tomiak What they developed TSO TRANSMIT and RECEIVE CMS NETDATA and SENDFILE NETDATA XMIT Manager XMIT370, RECV370 unxmit PDS Magician is an incomplete Visual Basic program. Tachyon Assembler Workbench a commercial product. http://www.tachyonsoft.com/ RXRECEIVE.rexx, KETRECV.rex, IDTFRDR.REX, IDTFRDR.PS1, IDTFSEND.PS1* (Future) IDTF-Exposed Page 6 of 30
1.2 Preface 1.2.1 Discussion - What purpose the IDTF-Exposed serves Front Matter This document contains information about what is found in an IDTF created by one of the IBM programs. Plus where to find this information and my attempt to describe what to do with the information in the event anyone wants to create their own method of processing a file. It is also my place to document how existing IBM components and ISV products make use of the directory entry user data fields. I also show other ways to transfer data. IDTF-Exposed Page 7 of 30
2. Section - Basics Basics IDTF-Exposed Page 8 of 30
2.1 Chapter - General Information 2.1.1 Discussion - Introduction Basics This document will first cover the commands and programs that can be used to create an IDTF. Next comes how to download the file to a personal computer using any simple File Transfer Protocol (FTP) client. And last, what you will find in an IDTF. 2.1.2 Discussion - Media Disk, punched cards, physical tape, and printouts are the usual types of media you can use to hold data. Screen captures can be saved as text or graphic images. 2.1.3 Discussion - Transport methods Sneaker net came about when we started downloading files to our personal computer and used 5.25 inch floppy disks. We could then walk the floppy disk to another location. For greater distances and quicker speeds we then used vehicles. Computer networks are used to transfer from one system to another system and are useful up to a point. Search the internet for sneaker net and pigeon to learn more. I was trying to find a phrase for using a pick up truck, but only found sneakers and station wagons. 2.1.4 Discussion - Data formats What data format do you use? Encryption is not considered a format, it is a way to mangle the data to make it more difficult for a non-recipient to use. A data format might be: 1. Fixed length records you have to know the length. 2. CRLF delineated records special pair of characters used to recognize records. 3. Variable length records Record Descriptor Word (RDW) contains the length of the data that follows. 4. Stream no real record layout, may be just variable length fields. IDTF-Exposed Page 9 of 30
Basics 4.1 Chapter - Create an IDTF 4.1.1 Discussion - Why Transferring files between systems existed before TCP/IP (was mainstream). As did networking! IBM systems used both Network Job Entry (NJE) and Remote Job Entry (RJE) over System Network Architecture (SNA) communication lines. Key in that last statement is 'Job Entry'. This was a Job Entry Subsystem (JES) feature for routing submitted jobs between systems and the return of the job output. The Interactive Data Transmission File specification is the file format structure for the sending program and receiving program to share data without running a job. The TSO/E Interactive Data Transmission Facility TRANSMIT command allows you to send data sets or messages to persons on your own system or on other systems. The TSO/E Interactive Data Transmission Facility RECEIVE command allows you to see the message or store the data set on your system. But wait! There is more than MVS that may play in this arena. Remote Spooling Communications Subsystem (RSCS) is a VM networking program. It provides data file transfer and print services to, from, and through the VM system on which it runs using both its own and TCP/IP networks. It extends the scope of a single system to an entire network of computers and devices. RSCS transfers data (as spool files) between its local system and remote devices and printers or other systems. It also acts as a print server for remote printers attached to other VM systems or a TCP/IP network. Through RSCS, users can send and receive messages, files, commands, and print and system jobs within their network. The CMS NETDATA command is used to QUERY if an IDTF is available on the SPOOL, to SEND an IDTF, or to READ an IDTF. The CMS SENDFILE command may also be used with the NETDATA parameter to create an IDTF. PRofessional OFfice System (PROFS), later renamed to OfficeVision/VM, was initially made available in 1981. Before that it was a PRPQ (Programming Request for Price Quotation), an IBM administrative term for "not quite supported" software. PROFS was originally developed by IBM in Dallas, in conjunction with Amoco. It can process message type IDTFs. The Simple Mail Tranport Protocol (SMTP) task on z/os can receive email in message as IDTF. Providing your non-mainframe mail servers will forward it. Most do not. 4.1.2 Discussion - What First off, only messages and disk data sets may be sent. The optional message will always be utility file number one and is treated as if it were terminal input. The optional data set may be utility file number one or two. One if there is no message and two if there is. Excluded are: tape data sets, ISAM, VSAM data sets, keyed data sets, data sets with user labels (I think that implies tape which is already excluded), and VB/VBS with a LRECL greater than 65,535. You will have enough trouble working with a LRECL greater than 32,760. Work-around: extract the source data into an acceptable format and be prepared to reconstitute it on the other end. And IDCAMS REPRO works for VSAM. Program AMATERSE (also known as TRSMAIN) IDTF-Exposed Page 10 of 30
Basics will attempt to compress the data set's contents. Program IEBGENER can be used to copy a tape data set to a disk data set. You might even try program GIMZIP to reduce the size of the file. 4.1.3 Discussion - How Your first decision is whether you want repeatable results or would rather battle the syntax more than once. I prefer repeatable results so I created my own REXX code and batch jobs. Next, from what operating system are you doing this? z/os (MVS) allows me the opportunity to build a job and save the JCL and control card stream for reuse and/or use my REXX code. I have rarely worked on a VM system and have never created an ITDF from CMS. I therefore use my limited knowledge to declare you would write your own EXEC or XEDIT macro for repeatable results. 4.1.3.1 Discussion - what you need to start You need to know what it is you are sending, if a data set then will you also send a message, and who are you sending it to. Based on who you are sending it to you may need to know what system they are on. VM does not support DSORG=PO, so sending a full or partial PDS will do them no good. As an alternative you might create your own IEBUPDTE like control card stream and send that as a DSORG=PS file. Or send multiple IDTFs with single members having specified SEQ. Are you really sending the IDTF or just packaging it? If really sending it, do you want notification sent back to you with a result of the recipient's attempt to receive the file? Somewhat last, but in possible conjunction with a &sysuid..names.text file, come parameter options that may lead to a message being included and influencing part of what is in that message. 4.1.4 Discussion - What can you do Data is a series of characters that have meaning when you know the layout. Transporting data from one data set style to another requires you have an idea what the underlying structure is. Taking a fixed length record (blocked or unblocked) from z/os and getting it onto a non-z/os system, perhaps Windows, means a change in the underlying structure. The VTOC, VTOCIX, and VVDS on z/os know what the record format is and access methods will use those attributes to present data to a program. Linux, UNIX, and Windows have nothing comparable to that. Instead, you either know the record length, have your own RDW field to tell you how long a record is, or use either the CR or CRLF convention to designate the end of a record. Now ask yourself, 'Self, should transporting data from z/os and/or z/vm modify the data set style in any way?' Your answer may not match my answer. If it does, our answer may not match what somebody else answered. What you do affects how you access the data afterwards. IDTF is a method of putting data into a container so that you have one standard data set style for transporting data whose own data set style can vary by data set or by person. IDTF-Exposed Page 11 of 30
Starting with a 'simple' scenario, you might use the TRANSMIT/NETDATA command to send just a message between systems, ala PROFS and SMTP email. A message is data. Basics Now if you want the content of the message to be hidden from prying eyes, you must encrypt it. You have just added a level of complexity on both ends. Before you can transmit your message you must encrypt it, transmit the encrypted text, share the encryption key, the recipient must receive it, and then decrypt it. The ITDF specification includes verbiage about using IDCAMS to encrypt data, however that might only be a never implemented feature. TRANSMIT will only use its internal INMCOPY and DFSMSdfp IEBCOPY utilities for sequential and partitioned data sets. That is correct, VSAM is your problem. If you write an EXIT to handle VSAM then the recipient also needs something to handle it. This is where things can add another level of complexity. You can use REPRO to convert the contents of a VSAM file to a sequential data set and then TRANSMIT that data set. You could also use the EXPORT command of IDCAMS, use DFSMSdss to DUMP the data set. Again, the recipient may need the corresponding method to undo what you did to it. Want to get more complex? How about compression? A zip utility of your choice can be used to attempt making the file smaller. Sometimes compressing a file can make it larger. It is a cheap form of encryption as the recipient would want to know how to uncompress it. Sure, they can hack away until they find something. AMATERSE and GIMZIP are two native IBM compression utility programs. IEWTPORT is another method of containerizing data. You could then encrypt a file (somehow), compress it using all of the above, containerize and then TRANSMIT it. The recipient needs to know how to do the reverse. You could even put it into ASWTAPE format and then compress, encrypt, and TRANSMIT it. I have long preferred running thru a PDS and creating a sequential data set in IEBUPDTE format and downloading that from EBCDIC to ASCII. Recently I used the MGET sub-command of FTP to just pull down each member as a separate PC file in a directory (folder) with a name based on the z/os data set name. The reverse would be to use MPUT to go from ASCII to EBCDIC. With using Windows based FTP you can also do character set translation using something similar to: quote site sbdataconn(ibm-037,iso8859-1) IDTF-Exposed Page 12 of 30
Basics IBM-037 is normal EBCDIC, ISO8859-1 is often used for English web pages. It might be your only way to preserve the "not sign", x'5f'. Preserving data integrity is one reason to use IDTF, transferred as a binary format, and then uploaded the same way. Attempts to translate from an EBCDIC to a non-ebcdic system can introduce errors. I have some COBOL code where I used the actual hex value and translation to ASCII with the addition of CRLF always cause problems. Eventually I found the COBOL way to have x'0d0a'. How complex you want to make transporting data is up to you. IDTF-Exposed Page 13 of 30
4.2 Chapter - Download to your personal computer 4.2.1 Discussion - file transfer as opposed to file transfer protocol Basics The phrases file transfer and ftp have mixed meanings in real life use. I think of file transfer as a verb, the act of transferring (copying/cloning) the data in a file from one location to another location. I think of ftp as the acronym for file transfer protocol, a specification of how a client and server can communicate to transfer (copy/clone) the data in a file from one location to another location and as the acronym for file transfer program, which can be both a server and a client. Download is analagous to GET, where the file comes from the server and goes to the client. The opposite is Upload, analgous to PUT, where the file comes from the client and goes to the server. IDTF is a "mainframe" concept. In the earliest days we first downloaded these files onto our personal computers by having an emulation card and a level of TSO on MVS, CICS/VS (on VSE), or VM/CMS with program IND$FILE, distributed in 1983. Nowadays any decent green screen emulator can mimic the screen scraping via IND$FILE. We even learned to get out of ISPF and be at the TSO READY prompt. The introduction of TCP/IP on the "mainframe" begat both client and server programs, but few personal computers were running an FTP server. If you have the knowledge, you may also use SMTP (think email) and send yourself the IDTF as an attachment. 4.2.2 Procedure - Windows command prompt FTP client It is often convenient to open a Command Prompt window and navigate to where you want to store the file. Then use the ftp command to open a connection with your virtual system (The system running in the LPAR). Login and get your data set(s). 4.2.2.1 Activity - Retrieve a data set From Windows, open a Command Prompt window. Navigate to the drive and directory where you want to store the data set as a file. Launch the ftp client program. While the transfer session may already default to the correct mode, issue the bin sub-command to ensure you will download in the raw EBCDIC format. Do not trust you will get binary, issue the command and be certain. Issue the get sub-command, specifying the MVS data set name. If you have several data sets with a common high level pattern then you can disable prompting by issuing the prompt sub-command once, and only once. This is a toggle sub-command, so you can issue prompt again to enable prompting. Navigate to the high level pattern. Issue the mget command to retrieve all files matching the high level pattern. Issue the quit sub-command to terminate the ftp client program. Issue the DOS exit command to close the Command Prompt window. 4.2.2.2 Activity - Retrieve from the JES spool Start as if you were going to receive a MVS data set. Then issue the quote site jes2please sub-command. Now get by job name/job number. 4.2.2.3 Action FTP session Who You IDTF-Exposed Page 14 of 30
Get something. Basics IDTF-Exposed Page 15 of 30
4.3 Chapter - What you will find in an IDTF Basics 4.3.1 Discussion - IDTF control records There are three types of IDTF data sets. The simplest would be notification, not something you should ever run across in a disk data set. Assuming you have not pumped up for the sake of pumping up, a message only data set would come next. Followed by a data set, or data set and message, transmission. First the ITDF control records. Then the Utility control records. And finally the data records. IBM manuals show static and optional fields. During the course of writing the PowerShell version of IDTFRDR and then enhancing an older oorexx version of a program I found errors or confusing/conflicting statements in IBM manuals. I have sent suggestions to have several manuals corrected. I suspect the manuals are like the RFC specifications, documented what they thought might get used and then reality did its own thing. And in some cases just a confused mind in how the alphabet works or lack of updating manuals when changes to code took place. 4.3.1.1 ITDF Control Records These are not in chronological sequence, since INMR07 must be before the INMR06. This is the short record description. The next item will show the text unit key fields and then I will follow with the fields that really appear in ITDF control records. Take note that there is no INMR05 record and I was never able to produce the INMR04 record using parameters on the TRANSMIT command. 4.3.1.1.1 INMR01 Start of ITDF file. Describes the attributes of who sent the ITDF to whom. 4.3.1.1.2 INMR02 Utility Control Records: INMCOPY or IEBCOPY followed by INMCOPY. INMCOPY will describe the attributes of the message and true data set. IEBCOPY will describe the attributes of the sequential output data set from IEBCOPY. 4.3.1.1.3 INMR03 Begin of data. Data can be a message, a sequential data set's contents, or a sequential IEBCOPY output data set of a partitioned data set. NETDATA (z/vm-cms) can only work with message and sequential data sets. The sequential output from IEBCOPY will contain its own control records that further describe what the partitioned data set might have looked like. Might? PDSE gets remapped to a fictitious device type. 4.3.1.1.4 INMR04 IDTF-Exposed Page 16 of 30
Basics I have never found one of these in an ITDF file. The data this record claims to contain is what I have found as optional data in the INMR01 record. 4.3.1.1.5 INMR06 End of ITDF data. The last record of the file will be padded out to a multiple of 80 bytes with binary zeros. Stop processing when you reach this control record. 4.3.1.1.6 INMR07 Notification information: was it received or deleted. Received does not infer looked at. Looked at does not infer read. Read does not infer understood. Notification is nothing more than confirmation the IDTF reached its destination and was processed by the RECEIVE command. 4.3.1.2 ITDF Control Record Text Unit Keys (TUK) These are documented in the manual. They may or may not exist. Items in red have never been found in any ITDF data set that I was able to produce or received from someone else. Also take notice that I was never able to produce the INMR04 record using parameters on the TRANSMIT command. Text Unit Key (Hex) BaseA (Decimal) Name Present in INMRxx Description What it could look like 0001 1 INMDDNAM DDNAME for the SYSUT1 1 to 8 bytes file 0002 2 INMDSNAM 02 07 Name of the file KTOMIAK USER REXX up to qty 22 from 1 to 8 bytes each 0003 3 INMMEMBR 02 Member name list 0002 xxxx l1 d1 l2 d2 xxxx = flags (not defined) 000B 11 INMSECND Secondary space 0000000A blocks 10 quantity 000C 12 INMDIR 02 Number of 00000F PDS directory blocks 15 directory blocks 0022 34 INMEXPDT 02 Expiration date yyyymmdd 0028 40 INMTERM 02 07 Data transmitted 0000 means message file as a message 0030 48 INMBLKSZ 02 Block size 00008000 block size 32768 003C 60 INMDSORG 02 03 File organization 0008 VSAM 0200 PO 4000 PS 0000 U 2000 DA 8000 ISAM 0042 66 INMLRECL 01 02 03 Logical record 50 length of logical record 80 length 0049 73 INMRECFM 02 03 Record format 0001 SVBS 0002 missing BDW/RDW C000 U 4000 V 8000 F 1000 B 2000 T 0800 S 0200 M 0400 A 1001 4097 INMTNODE 01 Target node name or node number POKSYS1 to node (JES2 or VM equivalent) 1002 4098 INMTUID 01 Target user ID SALLY to userid 1011 4113 INMFNODE 01 Origin node name or node number KTOMIAK from nodename (JES2 or VM equivalent) 1012 4114 INMFUID 01 Origin user ID USRJES3 from userid 1020 4128 INMLREF 02 Date last yyyymmdd referenced 1021 4129 INMLCHG 02 Date last yyyymmddhhmmss changed 1022 4130 INMCREAT 02 Creation date yyyymmdd 1023 4131 INMFVERS 01 Origin version number of the 00000001 version number 1 IDTF-Exposed Page 17 of 30
Text Unit Key (Hex) BaseA (Decimal) Name Present in INMRxx Description What it could look like data format 1024 4132 INMFTIME 01 07 Origin timestamp yyyymmddhhmmss 1025 4133 INMTTIME Destination yyyymmddhhmmss time received timestamp 1026 4134 INMFACK 01 07 Originator requested notification 00 to notify the sender or 04 FRED length plus who to notify RECEIVED or "DELETED" Basics 1027 4135 INMERRCD 07 RECEIVE command error code 1028 4136 INMUTILN 02 Name of utility INMCOPY ps IEBCOPY PO AMSCIPHR program encrypted 1029 4137 INMUSERP 01 02 07 User parameter user provided data from 1 to 251 string bytes 102A 4138 INMRECCT Transmitted 81 = number of records 129 record count 102C 4140 INMSIZE 02 03 File size in 000F4240 PDS size 1,000,000 bytes bytes 102D 4141 INMFFM 02 07 Filemode number F0 CMS filemode (drive) 0 102F 4143 INMNUMF 01 Number of files 0 in ACK or # of files (message transmitted file plus actual file) 8012 32786 INMTYPE 02 Data set type 80 Data Library 40 program library 04 extended ps 01 large format ps 8018 32792 INMLSIZE Data set size in megabytes 00F4240 PDS size 1,000,000 MB (*1024*1024 for bytes) 8028 32808 INMEATTR Extended attribute status 00 Unspecified 01 NoOPT 02 OPT IDTF-Exposed Page 18 of 30
5.Section - IDTFRDR IDTFRDR IDTF-Exposed Page 19 of 30
5.1 Chapter - oorexx 5.1.1 Discussion - Runtime environment expectations IDTFRDR My first foray into a PC based REXX program used IBM's PC-DOS 7 and that had REXX language programming support bundled in with it. The comment I have shows that was started back on 2001-10- 04. It was 2007-06-16 when I switched to Open Object Rexx. Likely getting a copy from: http://rexxla.org/ Those early versions were only intended to handle DSORG=PO RECFM=FB, with or without an embedded message. Then on 2013-12-31 an effort began to write the PowerShell version, complete with a windows-like user interface. And on 2014-02-02, while evaluating a number that looks related to track capacity size, I discovered the value I listed in KETRECV was off by 1,000. Nine days later I have, hopefully, finished a round of changes and enhancements to the renamed IDTFRDR version of oorexx code. Wishful thinking on my part that it was working. It is now 2014-03-07 and having 189 test files to work with I have found not all work as desired. I continue to hack away on IDTFRDR.rex as the logic needs to work before I carry that back to PowerShell. Having incorporated some Open Object Rexx routines leads to my declaration you need at least REXXooRexx_4.1.1(MT) or higher. Visit http://www.oorexx.org/download.html to get that. I have been using 4.1.1 and beta 4.1.3 on Windows/XP and Windows 8.1 Pro (64 bit). 5.1.2 Discussion - DEBUG My code creates a file where the IDTF control record's text unit values are shown. Using a DEBUG flag will generate additional output in the $$$xmitfile.txt that at some point I found helpful while writing the code. As of 2014-02-11 the only reason I know of that would lead you to even look in this file is that I do some special output for a load library member. As of 2014-03-07 I will now claim for any partitioned data set I will attempt to show the user fields. In the world of IBM that means ISPF statistics or load module attributes. 5.1.3 Discussion Executing IDTFRDR.rex My expectation is that you will either setup a.bat file or be in a Command Prompt window. Launch oorexx in the manner appropriate for your computer. On one of the computers I am using I have a.bat named r.bat that does some setup and then launches oorexx to run my code passing the file name to process. The other computer has oorexx in the PATH and I use that. For testing I chose to create a pair of.bat files, one set processes a single file, the other set processes a list of files. IDTF-Exposed Page 20 of 30
5.1.3.1 Action Process one file IDTFRDR @echo off SET FILE=POFB SET LOC=XMITfiles\ @Echo. @Echo Begin %LOC%%FILE%. @Echo. call rexx IDTFRDR.REX %LOC%%FILE%.XMI DEBUG(EXTRACT) :rem call rexx IDTFRDR.REX %LOC%%FILE%.XMI DEBUG(CHAR,CONTROL,COPYR,CTR,DATA,DEB,DIR,DUMP,DVA,EXTENT,FILE,IEBCOPY,LL,LOC,MBR,SHOWMSG,TUK) dir %LOC%IDTF\%FILE%_XMI_$$$\*.* notepad %LOC%IDTF\%FILE%_XMI_$$$\$$$xmitfile.txt : :rem NOTHING = Nothing special. [ Default ] :rem CHAR = Character by character. :rem CONTROL = Show INMR Control Record information. :rem COPYR = IEBCOPY Control Record information. :rem CTR = INMR counter. :rem DATA = INMR data in ASCII and EBCDIC. :rem DEB = Data Set Extent Block. :rem DIR = DIR processing. :rem DUMP = Show big blocks of data. :rem DVA = Device Architecture information. :rem EXTENT = Extent information. :rem EXTRACT = Data being extracted :rem FILE = File names. :rem IEBCOPY = IEBCOPY unload. :rem LL = some low level detail? :rem LOC = charin_location and segment data. :rem MBR = Member data. :rem SHOWMSG = Show message when present. :rem TUK = Text Unit Key information. @Echo. @Echo Done. @Echo. IDTF-Exposed Page 21 of 30
5.1.3.2 Action Process a group of files IDTFRDR :rexx_xmitfiles.bat 20140307 KTomiak Using new named DEBUG features. :rexx_xmitfiles.bat 20140209 KTomiak Added more members. :rexx_xmitfiles.bat 20140205 KTomiak Original code. @echo off goto :dothese : : Sometimes I use TUK,DIR,DEB,MBR,EXTENT for debugging slightly. : goto :skippedthese :rem :rem The first is an incorrect ASCII download. :rem The second has been truncated. :rem call rexx IDTFRDR.REX XMITfiles\XMITfiles\ascii_bad_inmr07a.xmi DEBUG(NOTHING) call rexx IDTFRDR.REX XMITfiles\XMITfiles\bad_short_PSFB.XMI DEBUG(INMR) :rem :rem :skippedthese :rem echo Skipped some :rem :rem :dothese :rem echo Do these call rexx IDTFRDR.REX XMITfiles\hello_world_netdata.xmi DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\INMR07A.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\INMR07B.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\INMR07C.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\INMR07D.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\INMR07E.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\INMR07F.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEF.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEFA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEFB.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEFBA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEFBM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEFM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEU.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEV.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEVA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEVB.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEVBA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEVBM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POEVM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POF.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POFA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POFB.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POFBA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POFBM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POFM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POU.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POV.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POVA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POVB.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POVBA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POVBM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\POVM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSF.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSFA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSFB.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSFBA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSFBM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSFBS.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSFM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSV.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSVA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSVB.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSVBA.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSVBM.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSVBS.XMI DEBUG(EXTRACT,TUK) call rexx IDTFRDR.REX XMITfiles\PSVM.XMI DEBUG(EXTRACT,TUK) goto :alldone :rem :alldone :rem echo All Done pause IDTF-Exposed Page 22 of 30
5.2 Chapter - PowerShell 5.2.1 Discussion - Runtime environment expectations IDTFRDR PowerShell is a Microsoft scripting language on Windows. So, you need some level of Windows that has PowerShell. The user interface is dependent on the.net Framework. I do not write code for back leveled systems. Therefore, you may have poor results attempting to run on something I do not still own. I am developing on Windows 7 - PowerShell V2 with.net Framework 4 Extended and Windows 8.1 Pro - PowerShell V3 with.net Framework 4.5. When development is complete I will test with Windows/XP - PowerShell V1 with.net Framework 4 Extended. IDTF-Exposed Page 23 of 30
6.Section - IDTFSEND IDTFSEND IDTF-Exposed Page 24 of 30
6.1 Chapter - SEND PC files IDTFSEND 6.1.1 Discussion - Dreaming, I like dreaming So you want to send one or more PC files in an Interactive Data Transmission File format. Why? 6.1.2 Procedure - Build a DSORG=PO like structure If you have a single file then you are probably better off just using FTP to send that one file. Having more than one file means packaging all selected files into a partitioned data set format. No easy feat. 6.1.2.1 Action What DCB(RECFM,BLKSIZE,LRECL) should be used Who You Select the set of files you want to include. Who Me Show possible member level LRECL sizes. Guesstimate if the member has FIXED or VARIABLE lengths. Determine the highest common denominator. Who You Override the Windows side. I will not let you degrade record lengths below the maximum size found. You can increase it. For example; the longest record found is 68 bytes long, you can increase the LRECL to 80. This can, and should, be set at the data set level. IDTF-Exposed Page 25 of 30
Appendixes 7.Section - Appendixes IDTF-Exposed Page 26 of 30
Appendixes 7.1 Bibliography 7.1.1 Discussion - Things you may want to reference yourself. Reference Title SA22-7782-14 IBM z/os TSO/E Command Reference SC24-6073-03 IBM z/vm CMS Commands and Utilities Reference Version 5 Release 4 SA22-7783-12 SC24-6075-00 SC26-7414-08 SC26-7410-11 SC26-7400-14 SA22-7644-07 SC26-7408-10 SC34-4815-10 z/os 1.13 z/os 1.13 D00501-1E MAN10143748E Kenneth Tomiak IBM z/os TSO/E Customization IBM z/vm CMS Macros and Functions Reference IBM z/os DFSMSdfp Utilities IBM z/os DFSMS Using Data Sets IBM z/os DFSMSdfp Advanced Services IBM z/os MVS Program Management: Advanced Facilities IBM z/os DFSMS Macro Instructions for Data Sets Interactive System Productivity Facility (ISPF) Messages and Codes (z/os Version 1 Release 13) describing ISPF Statistics use of User Data Fields SYS1.MACLIB(IHADVA) SYS1.MODGEN(IHAPDS) partially describes a PDS directory entry whilst describing Linage Editor/Binder use of User Data Fields BrightStor CA- Getting Started 7.5 describing PDSMAN and Endevor use of User Data Fields describing Alchemist use of User Data Fields IDTF-Exposed Page 27 of 30
Appendixes 7.2 Alphabetical Index No index entries found. IDTF-Exposed Page 28 of 30
End 8.Section - End of IDTF-Exposed IDTF-Exposed Page 29 of 30
End 8.1 End of Document This is the last page of the document. IDTF-Exposed Page 30 of 30