Transfer Load modules From mainframe to PC

VIGNRSH · Posted: Fri Apr 03, 2009 9:09 pm

HI,

I want to transfer my load modules existing in my mainframe to local PC . I tried using the IEBCOPY first to unload the load modules in to a sinlge file and downloaded that flat file in to my PC. But when i upload the same content by using emulator s file transfer facility and again IEBOCPY to create the load module ,it is failing there, saying the dataset is not a proper format

Robert Sample · Posted: Fri Apr 03, 2009 10:32 pm

Do you want to transfer (per your first sentence) or back up (per your last question) your load modules? There's a huge difference!

As far as doing a transfer with an IEBCOPY unloaded dataset, you need to be aware of the Utilities manual statements:

VIGNRSH · Posted: Mon Apr 06, 2009 11:48 am

I need to take a backup of my load modules in my local PC and be able to restore them back in the maniframe environment when needed.

When copying via IEBCOPY and tranferring it to PC the records of Loadmodules are getting corrupted. To overcome this , I read in few websites, to use XMIT command to transfer the Load modules to your own id and Receive them in a PS file and then transfer it to the PC. Similarly , for restoring them,execute the RECEIVE command on the dataset transferred from PC .

SInce, in my environment, i am denied access only to XMIT command, is there any other way? like using the ADRDSSU to dump the Datasets to a Flat file and transfer it to the PC. While restoring , similarly , use RESTORE command of the ADRDSSu ? Will this work? meaning, will the record be preserved during the transfer from PC to mainframe and vice-versa???

Or Can some one provide the XMIT command's load module, so i can inovke it from my load library , in .XMI file format ??

I checked through the CBTTAPE.org site for exisitng utilities. But i could not find one amongst it.....

Can some one Provide Help??

enrico-sorichetti · Posted: Mon Apr 06, 2009 1:04 pm

a pc is the unsafest place to keep backups,

as Your storage support what is Your shop standard for backups

a DFDSS dump is safer and faster ( mainframe dasd are much more reliable than PC stuff )

enrico-sorichetti · Posted: Mon Apr 06, 2009 1:08 pm

Robert Sample · Posted: Mon Apr 06, 2009 5:10 pm

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

If you use ADRDSSU to dump the datasets and then terse the output, you can transfer the data between the mainframe and the PC without poblems

Bill Dennis · Posted: Mon Apr 06, 2009 7:15 pm

If you're not familiar with it, TERSE (aka TRSMAIN) is a free utility from IBM with "PACK" option for compressing and converting many data types into FB, 1024 records for easy transmit using standard utilities. You can terse the whole load library as one file.

Once back on the mainframe, run with "UNPACK" option to restore the file.

Search IBM for the TRSMAIN download instructions or find it included on the latest IBM z/OS versions.

dick scherrer · Posted: Mon Apr 06, 2009 9:55 pm

Hello,

expat · Posted: Tue Apr 07, 2009 11:33 am

Douglas Wilder · Posted: Tue Apr 07, 2009 8:07 pm

Two reason I have thought of for copying load modules to a PC and back are 1) An off site backup for a very very small shop (and/or system) or 2) Transferring them to a different mainframe.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

Robert Sample · Posted: Tue Apr 07, 2009 8:46 pm

nevilh: so what is the business reason for taking source and load modules from the mainframe to a PC? Your employer hires you to do a job and provides you the tools (emulator, TSO access, etc.) to do that job. Unless the employer provided Microfocus COBOL or another PC tool, the employer clearly is not wanting work to be done on the PC but on the mainframe. Since mainframes typically have complete backup and recovery facilities (often developed many years ago), there's no reason to back up source or load modules to a PC. What other business reason would there be to download your employer's intellectual property to a PC?

The reverse case is just as bad. If you're hired to create programs for an employer, and you upload programs from a PC to the mainframe (programs written specifically for another employer) to accomplish the required task, courts have ruled the prior employer is entitled to damages due to the loss of their intellectual property. Does the new employer really want to be put in that position? Almost certainly not (or if they do, there's an ethical issue with working for them.)

Until somebody comes up with a viable business reason to put mainframe source and load modules on a PC, the prima facie evidence is that some form of criminal (or at least underhanded) activity is underway in merely asking the question.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

Robert Sample · Posted: Tue Apr 07, 2009 9:31 pm

Mainframe load modules won't work on a PC. I could see the possibility of debugging if source were transferred, and the employer made a PC package available for debugging, but sorry -- load modules are mainframe only and there's no reason to put one on a PC for debugging. And if there are tools like STROBE, Abend Aid, File Aid, File Manager, Xpediter on the mainframe already then the debugging argument won't wash -- the employer has the tools on the mainframe so again there's a presumption the PC is not to be used for debugging.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

I will be more specific I download the required material from the mainframe to my PC so that I can upload the material to another mainframe where I have the required tools/aids to help with the debugging.Load modules are taken if required, not to run them but to make sure they have not been modified .

Robert Sample · Posted: Tue Apr 07, 2009 10:47 pm

Both mainframes belong to your employer? Why not just FTP directly from one mainframe to the other -- I do that between LPARs all the time here and it is quick, efficient, and handles load modules just fine. Plus it doesn't require a PC in the middle so no conversion issues (variable length records AND code page differences), no tersing and untersing the data, no security concerns .... etc, etc, etc.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

Both mainframes belong to the same Parent company but the subsidiaries are separate entities. Traffic is one way only I can send data from machine A to B but not from B to A. Options are download to a PC or create a tape and spend the next half a day filling out forms in order to move the tape from one silo to another

dick scherrer · Posted: Wed Apr 08, 2009 12:04 am

Hello,

If the 2 subsidiaries have different software agreements with vendors, seems like a license agreement violation to use tools licensed for only companyA to do companyB work. . .

Terry Heinze · Posted: Wed Apr 08, 2009 1:54 am

We understand your plight, Nevilh, but as Dick mentioned, I think you're entering a very sticky legal area.

Robert Sample · Posted: Wed Apr 08, 2009 3:22 am

I sympathize with your need to get the debugging done, but let's look at the situation. Parent company P owns companies A and B. You work for company A. B has a license from software vendor V to use a product which you want to use for debugging. You are downloading source, load modules, and presumably data (hard to debug without data) from A to your PC and then transferring this material to B, using V's product to debug your program. A has strict rules on transfers to B and B won't allow transfers to A. IANAL, but I do know enough about IT to point out:

The best possible case: P has an enterprise license for V's software, A and B are U.S. companies not located in California (or other notification state), and the data does not reference any sensitive (HIPAA, etc) data -- and you created the test file yourself randomly. In this case all you've done is violate company A and B policies on data transfers, and possibly left yourself unable to replicate your test results should access to B be cut off. Of course, I've known people terminated for violating data transfer policies like this.

The worst possible case: no enterprise license, A or B is a U.S. California company, the other is based in Europe, the data is HIPAA (or similarly sensitive), and you copied the production file for testing. In this case, company V could retroactively charge company A several hundred thousand (maybe a million plus) -- dollars or euros -- for their product, you violated state, U. S. Federal, and European data transfer laws which I believe include criminal and civil penalties, and managers of company A (at least) could be facing fines and jail time. Not to mention you have exposed data that was in a secure environment to an unsecured environment, raising the risk of exposure.

In any case, as Dick and Terry said, you're personally putting yourself in a very unsafe position -- and possibly much more than yourself.

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

Robert Sample · Posted: Wed Apr 08, 2009 4:39 pm

nevilh · Active User Joined: 01 Sep 2006 Posts: 262

Officially the same software is installed and delivered to all. Which invalidates your argument Not really just because the software is installed does not mean it can be used . Some third party software is delivered but cannot be used because activation keys are not available , some products are RACF protected so that they cannot be used others have the APF authorisation removed so that they cannot be used and others simply do not have the required environmental datasets to function .
However we are digressing from the original point, in my opinion just because the OP makes a somewhat unusual request I feel they should be given the benefit of the doubt and we should assume they have a valid reason for asking the question not automatically assume they are trying to do something deceitful/illegal.

Terry Heinze · Posted: Wed Apr 08, 2009 8:46 pm

I don't think we are assuming anything; just calling attention to possible legal implications that might not have been considered.