Apparently our friends as CMS forgot that we are all highly dependent on our computer networks and that we occasionally keep important stuff like MDS files on a network drive. So when we connect to MDS/OASIS using the VPN and try to upload our MDS's from a network drive thenetwork drive is unreachable and we cannot select and submit our files.
I did what any good tech does before pulling his hair out - I called tech support. The guy at CMS tech support was friendly and knowledgeable, and acknowledged that this is a problem. Furthermore, the tech assured me that this is by design. Apparently the rest of our network presents a threat to CMS's computers (I'm paraphrasing here), so the machines that connect to CMS are quarantined from their network.
The tech went on to explain that CMS expects users with networked computers to copy MDS's from the network to their computer prior to connecting to the MDS/OASIS site.
Instead of manually copying these files, I created a batch file to copy them automatically and then launch the AT&T Global Network Client once the copy has completed. Here's how you can make your own:
- Create a text file on your desktop and rename it to a batch file by changing its filename extension to .bat - I named mine MDS-OASIS.bat
xcopy m:\marktech\XFEROUT\*.mds c:\XFEROUT /d /v /y /i
"C:\Program Files\AT&T Global Network Client\netclient.exe"
exit
- There a LINE BREAK (in other words, press Return) at then end of each line if you're typing this.
- Save this file as a .txt file and rename it as a .bat file. If you don't know how to do this, consult a computing professional.
- When you run it, a DOS window will open, it will copy all .MDS files that you don't already have to the folder c:\XFEROUT, then invoke the AT&T Global Dialer.
- When you finish your transfer and close the dialer, the DOS window will disappear.
/d only replaces files that are newer than ones on the target drive
/v verifies that each file is copied correctly
/y suppresses prompting to overwrite files on the destination computer
/i causes xcopy to assume that c:\XFEROUT is a directory, not a file.