Return Code from receive | coding a receive in Access

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Presently I am creating a text file with a .cmd. Inside is a I am using a
receive command to pull from the mainframe.
.....
Open gsPath & "SecureImport.cmd" For Output As #1 ' Open file.

Print #1, "Receive " & sTemp & " <my mainframe file name>"
......
I call the cmd file.
......
Shell(<path and cmd filename>, vbNormalFocus)
......
This all works fine. But I would like to put code in to make sure the
receive worked properly. I was told I could use a return code when using the
shell command. I get several different return values from the cmd whether it
ends properly or not.

Can I check some kind of value whether a return code or see some kind of a
return value from the Receive command?
****************************************************

If this is not possible. Some DOS commands work in VBA. Can I code say the
receive command with in the module or a get command?
 
The return value from Shell() is the Windows task ID of the process
that's created, not the exit code (errorlevel) from the commandline
that's executed, so I don't think there's a simple way of doing this.

Assuming that your "receive" command (which doesn't seem to be a
standard Windows internal or external command) uses meaningful exit
codes, one approach would be to include a line in the script to write
the exit code to disk, something like this air code:

receive blah blah
ECHO %ERRORLEVEL% > %TEMP%\receive_exit_code.$$$

Not all command-line programs do use exit codes. If "receive" prints its
return value in the command window, it's probably sending the value
either to STDOUT, in which case you can just redirect it to disk

receive blah blah > %TEMP%\receive_exit_code.$$$

or to STDERR, in which things are more complicated, and I think you'll
need to write your script for WSH (cscript.exe) rather than cmd.exe.
Also, using WSH gives access to STDIN and (I think) ERRORLEVEL without
having to use a temp file.

You may also need to take steps to ensure that your VBA code waits for
the script to finish before proceeding. WSH can help here too, or you
can use one of the many ShellAndWait() functions, such as Karl
Peterson's at http://vb.mvps.org/samples/project.asp?id=Shell32
 
So your saying VBA is not strong enough to do this? I have to use VB or VB
Script? Does any one have any code I can use or point me to specific
documentation on how to write it?
 
So your saying VBA is not strong enough to do this? I have to use VB or VB
Script? Does any one have any code I can use or point me to specific
documentation on how to write it?
Click to expand...

It's not that VBA isn't "strong enough", but that what you want to do
may require use of some things that aren't in the "basic" VBA repertoire
- but VBA *is* "strong" enough to control other Windows facilities.

But without knowing more information it's not really possible to do more
than what I've already done: point to the general lines of approach. If
you want more, please say:

-What sort of return codes does your "receive" command provide? "DOS"
exit codes, output to STDOUT, output to STDERR, or something else?

-Does your procedure need to stop and wait until the "receive" operation
completes or times out?
 
I dont know the answer to those questions. That is why I am here for advice.
Receive is a simple command to download data from the mainframe to a pc in
text format or binary format. I have no idea how to capture those return
codes so I am looking for some specific code or source of documentation that
will teach me how to do it.
I will talk to some of my Mainframe counter parts and see if I can get more
info on the receive command. It has been a while since I worked on the
mainframe.

I have seen stdout in C but I have not seen it in VB or VBA. I shall try
doing a search on it in Access and VB6.
 
As I said, "receive" is not a standard Windows command. I've just
scanned my computer and there's no "receive.exe" anywhere, which means
it's not part of a normal Windows/Office installation either. If you
find "receive.exe" on your computer, right-click on it and inspect its
properties, which should include version number and copyright notice. If
that doesn't provide anything useful, open a command prompt, navigate
to the right folder, and type these commands
receive /?
receive -h
receive --help
receive -v
receive --version
at least one of them should give some information about its origin. With
that, you can set about obtaining documentation on its exit codes,
return values, or whatever. Without the documentation you'll have to set
about systematically examining the program's behaviour in error
conditions in order to work them out for yourself.

STDOUT and STDERR are not directly accesssible from VBA. See my earlier
message for ways that you can capture them by redirection or by using
the facilities provided in WSH.
 
I know it is not a standard PC command. I am working with the Mainframe. I
just talked to some of the Mainframe Programmers and it is referred to as TSO
Send and Receive. It is normally done in a 3270 host window which is a PC
emulation for the PC. I do have to log onto it before Receiving but I am not
coding in that window. I am using the command prompt.

Your advice here with the receive /?
did work. It gave me some info and based what you and they said I am
guessing either that emulation or one of the others like hummingbird may be
allowing this command to work on the PC.

This may have done it. I just found through one of those options this info
Refer to 'File Transfer Command for PC/3270' section of "Personal
Communications AS/400 and 3270 Reference for details of each option.

I will let you know how it goes.
 
Back
Top