|
===> "e) You use RTVNETA to get the system name to use in a UNC path. This is incorrect." Then, I do not understand why is working perfectly if I try to use it for files with no spaces in between, like DIRECTDATA.txt, SAMPLEDATA.XLS or TEST_DATA.TXT?
I hate trying to explain this -- and this is now the 3rd time I find myself doing it on Midrange-L!
midrange.com
Consider this code, which is obviously incorrect code:
RTVUSRPRF USRPRF(*CURRENT) RTNUSRPRF(&SYSTEM)
PING RMTSYS(&SYSTEM)
How can it PING a user profile? Yet it works perfectly. Does this mean
that you can legally PING a user profile? No, of course not.
My user profile is KLEMSCOT. I happen to have a computer on the network who's name is also KLEMSCOT. Therefore, the PING happens to work -- that doesn't mean that when it's time to look up a computer name, the RTVUSRPRF command is the right command to use!
The same is true for RTVNETA. It returns the APPC/SNA name of your system. Can you use that name in Microsoft Networking? Sure, but it'll only be coincidence if it works. The guy who configured your system just happened to use the same name for the APPC system name as he did for the Windows Networking system name.
My name is Scott. If I call out "Scott, come here" the guy in the next office will walk over here. His name, just by coincidence, happens to also be Scott. That does not mean that calling out my own name is the right way to summon other people. It's only coincidence that his name happens to be the same as mine.
The same is true in your case. Your APPC system name coincidentally happens to be the same as your Windows Networking name. That doesn't mean that your code is correct. If someone changes your Windows Networking name and not your APPC name, the code will fail. If you run it on my system (where the names don't match) it'll fail.
You'd be better off hard-coding the name than using RTVNETA. At least then it'd be OBVIOUS to the next programmer that the code will only work on the current machine, instead of misleading him into thinking that it's written in a generic way that'll work anywhere.
===> "f) You assemble your UNC path into the &SYSPATH variable, which is 1000 chars long. This won't work..." Again, I am confused then when the other examples presented above can work.
It'll only work if the last 877 bytes of &SYSPATH are blanks. What's the point of making a variable 1000 long when it's impossible to use anything over 123 chars?
===> "g) The samples that you included in the e-mail involve a UNC path that points to TXT file. You then pass this UNC path to STRPCCMD -- which makes no sense..." Just for illustration of the issue, if I go to Windows Explorer and type in \\TT400\ROOT\TEST\Copy of DETAILDATA.txt it will automatically launch NOTEPAD.EXE but it will not work from my CLP; However, if I try to access the file\\TT400\ROOT\TEST\DETAILDATA123456abcdef.txt it will automatically launch NOTEPAD.EXE and it will do exactly the same thing if I run it using my CLP.
Windows has several different ways to run commands. There's the CreateProcess() API (which is what Microsoft recommends), the WinExec() API(from Win 3.1) the ShellExecute() API, and probably some others that I'm not aware of, since I'm not really a Windows guy.
When your 5250 emulation software was written, the programmer who wrote it had to use one of these APIs. One 5250 emulator may behave differently than the next 5250 emulator!
I tried your program from the open source TN5250 (Current developer's sources from CVS, from tn5250.sf.net) and it worked just fine with the way your command is quoted. With or without spaces, it doesn't matter. I happened to be the programmer who wrote the STRPCCMD support for that emulator, so I know how it works.
I also tried your command from NetManage's Rumba (version 7.3), and it worked just fine from there as well.
Then I tried it from Mochasoft, and it didn't work.If I change your code to specify "notepad" (the actual program name) instead of just sending the pathname (as follows) it works just fine in all 3 of the above emulators:
CHGVAR VAR(&SYSPATH) VALUE('notepad +
"\\' *CAT &SYSTEM *TCAT '\KLEMSCOT\' *CAT &OBJ *TCAT +
'"')
I don't have iSeries Access (our company doesn't own a license for it) so
I can't try that one, but I suggest that you specify the program name
instead of just the pathname, I think it'll work better. YMMV.
If I use the "start" command (as I previously suggested) it has problems with any filename that has a space in it, but specifying "notepad" instead doesn't seem to have that problem.
a) What is an UNC path?
UNC path is a Windows term. Normally a pathname in Windows consists of an (optional) drive letter, followed by (optionally) folders, and then the filename. For example:
C:\Documents\Programming\RPG Manual.pdf
The problem with this syntax was that in order to connect to different
devices, such as network drives, you had to map a drive letter to them.
On a big network you very quickly run out of available drive letters.
Later, Microsoft introduced UNC (Universal Naming Convention) in which you you can specify the comptuer name, share name, diretory name(s) and filenames all in one string. This was integrated into the operating system starting with (I think) Windows 95. In UNC, you use two slashes, followed by a comptuer name, a slash, the share name, a slash, folder names, and finally the document name. For example:
\\Computer\Share\dir1\dir2\file.txt
This gives Windows something similar to what a Unix machine would have
with a path like this:
computer:/dir1/dir2/file.txt
The computer name in UNC format can either be the Windows NetBIOS/SMB
name, or it can be a fully qualified domain name or IP address.(at least
in recent versions of Windows)
b) How can I add the quotes at the end of this parameter so the STRPCCMD command can work correctly?
You're already doing that correctly. When I run your code, I get the quotes as expected. All I can say is that you're probably getting a garbage character in the string somewhere. Take a look at the parameter in hex to see if there's something besides x'40'. It's not happening on my machine, but then I'm not calling the program the same way that you are.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
