Home > Archive > Cobol > August 2004 > Copy Contents of Folder to Network Drive With Fujitsu PowerCOBOL
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Copy Contents of Folder to Network Drive With Fujitsu PowerCOBOL
|
|
| Denny Brouse 2004-08-05, 3:55 am |
| Good evening,
Once again, I have run into a little, shall we say, challenge with Windows
and Fujitsu PowerCobol. I have a project in which I need to copy an entire
folder and its' contents to another Windows 2000 server. Initially, I
figured "no big deal", since I think I have finally mastered using the
Fujitsu CBL_COPY_FILE routine for file copies and the Standard
"ShellExecuteA" Windows API for shelling out to other stuff. OK, I retract
the "mastered" part of the previous sentence and will state simply that
usually it works for me. <g>
The task is to:
"COPY <source drive letter>:\<some path name>\*.* TO <destination drive
letter>\<some path name>\*.*". Or even better, COPY <source drive
letter>:\<some path name> TO <destination drive letter>\<some path name> and
have the files underneath come along for the ride. There are no sub folders
under <some path name> so at least I don't have to deal with that.
However, much to my chagrin, I can't get wildcards to work with the
CBL_COPY_FILE routine, although it is entirely possible that I'm not passing
the correct information to the routine. Based on my DEBUG displays,
everything looks as it should and the routine copies a single file just
fine. When I replace the single file name with *.*, it doesn't give me an
error, but it also doesn't work. I'm using the CBL_CREATE_DIR routine to
create the folder on the Windows 2000 server if it doesn't exist, and that
works fine as well.
So me being the inquisitive guy that I am, I went to the Microsoft support
site looking for a way to copy a folder and it contents from one place to
another, perhaps without any wildcards and perhaps eliminating the
CBL_CREATE_DIR piece as well. I came up with two possibilities. I'm sure
there are more, but I stopped at these two for the moment.
1. A java script, but the only java I know anything about is the stuff that
goes into my coffee cup,
2. The other was a part of the normal Windows shell32.dll (and associated
lib "shell32.lib") named SHFileOperation. I think I have the C++ stuff
translated back to COBOL (references and values, etc.), but I'm getting an
"unresolved external reference" when I attempt to call "SHFileOperation".
Yes, I have shell32.lib in my link parameters. In fact I have a call to
"ShellExecuteA" in the same program and that works just fine.
I'd post the SHFileOperation code I'm trying to set up, but I'm home and my
work place no longer allows newsgroup access from our workplace. However,
I'll E-mail the code to myself tomorrow, so I can respond to the group
accordingly.
I even thought about executing the Windows 2000 cmd.exe with a "copy"
parameter, but I've never tried that either. I figure that I'm just doing
something stupid, as I frequently do when I talk to Windows via COBOL, but I
was hoping that one of you fine experts can point me in the right direction.
Thanks in advance!
Denny
| |
| Donald Tees 2004-08-05, 3:55 am |
| Denny Brouse wrote:
> Good evening,
>
> Once again, I have run into a little, shall we say, challenge with Windows
> and Fujitsu PowerCobol. I have a project in which I need to copy an entire
> folder and its' contents to another Windows 2000 server. Initially, I
> figured "no big deal", since I think I have finally mastered using the
> Fujitsu CBL_COPY_FILE routine for file copies and the Standard
> "ShellExecuteA" Windows API for shelling out to other stuff. OK, I retract
> the "mastered" part of the previous sentence and will state simply that
> usually it works for me. <g>
>
> The task is to:
>
> "COPY <source drive letter>:\<some path name>\*.* TO <destination drive
> letter>\<some path name>\*.*". Or even better, COPY <source drive
> letter>:\<some path name> TO <destination drive letter>\<some path name> and
> have the files underneath come along for the ride. There are no sub folders
> under <some path name> so at least I don't have to deal with that.
>
> However, much to my chagrin, I can't get wildcards to work with the
> CBL_COPY_FILE routine, although it is entirely possible that I'm not passing
> the correct information to the routine. Based on my DEBUG displays,
> everything looks as it should and the routine copies a single file just
> fine. When I replace the single file name with *.*, it doesn't give me an
> error, but it also doesn't work. I'm using the CBL_CREATE_DIR routine to
> create the folder on the Windows 2000 server if it doesn't exist, and that
> works fine as well.
>
> So me being the inquisitive guy that I am, I went to the Microsoft support
> site looking for a way to copy a folder and it contents from one place to
> another, perhaps without any wildcards and perhaps eliminating the
> CBL_CREATE_DIR piece as well. I came up with two possibilities. I'm sure
> there are more, but I stopped at these two for the moment.
>
> 1. A java script, but the only java I know anything about is the stuff that
> goes into my coffee cup,
>
> 2. The other was a part of the normal Windows shell32.dll (and associated
> lib "shell32.lib") named SHFileOperation. I think I have the C++ stuff
> translated back to COBOL (references and values, etc.), but I'm getting an
> "unresolved external reference" when I attempt to call "SHFileOperation".
> Yes, I have shell32.lib in my link parameters. In fact I have a call to
> "ShellExecuteA" in the same program and that works just fine.
>
> I'd post the SHFileOperation code I'm trying to set up, but I'm home and my
> work place no longer allows newsgroup access from our workplace. However,
> I'll E-mail the code to myself tomorrow, so I can respond to the group
> accordingly.
>
> I even thought about executing the Windows 2000 cmd.exe with a "copy"
> parameter, but I've never tried that either. I figure that I'm just doing
> something stupid, as I frequently do when I talk to Windows via COBOL, but I
> was hoping that one of you fine experts can point me in the right direction.
>
> Thanks in advance!
>
> Denny
>
>
The fast and dirty way is to shell to cmn using xcopy(your 2). You will
have to differentiate by platform. (command/cmd) The other is to take a
look at the findfirst and findnext cobol subroutines in the same
library, and code the copies using the output. Java script is
overcomplicating the issue IMO.
Donald
| |
| Russell Styles 2004-08-05, 3:55 am |
| I don't believe that CBL_COPY_FILE is intended to work with star names.
The Microfocus documentation (all I have) says
"This routine does not work with filenames containing wildcard characters".
If you want to copy more than one file, you will need to call it more
than once.
Or do what donald Tees suggests, and use a batch file.
"Denny Brouse" <denden@prodigy.net> wrote in message
news:chgQc.1473$Y94.1071@newssvr33.news.prodigy.com...
> Good evening,
>
> Once again, I have run into a little, shall we say, challenge with Windows
> and Fujitsu PowerCobol. I have a project in which I need to copy an
entire
> folder and its' contents to another Windows 2000 server. Initially, I
> figured "no big deal", since I think I have finally mastered using the
> Fujitsu CBL_COPY_FILE routine for file copies and the Standard
> "ShellExecuteA" Windows API for shelling out to other stuff. OK, I
retract
> the "mastered" part of the previous sentence and will state simply that
> usually it works for me. <g>
>
> The task is to:
>
> "COPY <source drive letter>:\<some path name>\*.* TO <destination drive
> letter>\<some path name>\*.*". Or even better, COPY <source drive
> letter>:\<some path name> TO <destination drive letter>\<some path name>
and
> have the files underneath come along for the ride. There are no sub
folders
> under <some path name> so at least I don't have to deal with that.
>
> However, much to my chagrin, I can't get wildcards to work with the
> CBL_COPY_FILE routine, although it is entirely possible that I'm not
passing
> the correct information to the routine. Based on my DEBUG displays,
> everything looks as it should and the routine copies a single file just
> fine. When I replace the single file name with *.*, it doesn't give me an
> error, but it also doesn't work. I'm using the CBL_CREATE_DIR routine to
> create the folder on the Windows 2000 server if it doesn't exist, and that
> works fine as well.
>
> So me being the inquisitive guy that I am, I went to the Microsoft support
> site looking for a way to copy a folder and it contents from one place to
> another, perhaps without any wildcards and perhaps eliminating the
> CBL_CREATE_DIR piece as well. I came up with two possibilities. I'm sure
> there are more, but I stopped at these two for the moment.
>
> 1. A java script, but the only java I know anything about is the stuff
that
> goes into my coffee cup,
>
> 2. The other was a part of the normal Windows shell32.dll (and associated
> lib "shell32.lib") named SHFileOperation. I think I have the C++ stuff
> translated back to COBOL (references and values, etc.), but I'm getting an
> "unresolved external reference" when I attempt to call "SHFileOperation".
> Yes, I have shell32.lib in my link parameters. In fact I have a call to
> "ShellExecuteA" in the same program and that works just fine.
>
> I'd post the SHFileOperation code I'm trying to set up, but I'm home and
my
> work place no longer allows newsgroup access from our workplace. However,
> I'll E-mail the code to myself tomorrow, so I can respond to the group
> accordingly.
>
> I even thought about executing the Windows 2000 cmd.exe with a "copy"
> parameter, but I've never tried that either. I figure that I'm just doing
> something stupid, as I frequently do when I talk to Windows via COBOL, but
I
> was hoping that one of you fine experts can point me in the right
direction.
>
> Thanks in advance!
>
> Denny
>
>
| |
| Denny Brouse 2004-08-05, 8:55 am |
| Donald,
I appreciate you re-enforcement of the shell to cmd.exe/command.com as one
method. I was very surprised that something as useful as a "CopyFolder"
command didn't exist in the API. In my work environment, the first thing I
try to do is "GetWindowsDirectoryA" to figure out what OS I'm running on,
so that's already pretty much handled. I wasn't aware that XCOPY still
existed on a W2K box, but then again, I haven't had the need until now to
look. <G>.
Thanks a bunch for your input.
Denny
"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:bShQc.29085$Jq2.1312138@news20.bellglobal.com...
> Denny Brouse wrote:
Windows[color=darkred]
entire[color=darkred]
retract[color=darkred]
and[color=darkred]
folders[color=darkred]
passing[color=darkred]
an[color=darkred]
to[color=darkred]
that[color=darkred]
support[color=darkred]
to[color=darkred]
sure[color=darkred]
that[color=darkred]
associated[color=darkred]
an[color=darkred]
"SHFileOperation".[color=darkred]
my[color=darkred]
However,[color=darkred]
doing[color=darkred]
but I[color=darkred]
direction.[color=darkred]
>
> The fast and dirty way is to shell to cmn using xcopy(your 2). You will
> have to differentiate by platform. (command/cmd) The other is to take a
> look at the findfirst and findnext cobol subroutines in the same
> library, and code the copies using the output. Java script is
> overcomplicating the issue IMO.
>
> Donald
>
| |
| Denny Brouse 2004-08-05, 8:55 am |
| Russell,
The Fujitsu doc says "file", non-plural, but doesn't specifically say
anything about wildcards as I recall. I guess I was just hoping to find an
"un-documented" feature.
I appreciate your feedback.
Thanks,
Denny
"Russell Styles" <rNwOsS0P2A0M2@comcast.net> wrote in message
news:5qGdnaOoL9YkJIzcRVn-rQ@giganews.com...
> I don't believe that CBL_COPY_FILE is intended to work with star names.
>
> The Microfocus documentation (all I have) says
>
> "This routine does not work with filenames containing wildcard
characters".
>
> If you want to copy more than one file, you will need to call it more
> than once.
>
> Or do what donald Tees suggests, and use a batch file.
>
>
>
> "Denny Brouse" <denden@prodigy.net> wrote in message
> news:chgQc.1473$Y94.1071@newssvr33.news.prodigy.com...
Windows[color=darkred]
> entire
> retract
> and
> folders
> passing
an[color=darkred]
to[color=darkred]
that[color=darkred]
support[color=darkred]
to[color=darkred]
sure[color=darkred]
> that
associated[color=darkred]
an[color=darkred]
"SHFileOperation".[color=darkred]
> my
However,[color=darkred]
doing[color=darkred]
but[color=darkred]
> I
> direction.
>
>
| |
| Michael Mattias 2004-08-05, 8:55 am |
| "Denny Brouse" <denden@prodigy.net> wrote in message
news:rloQc.465$Ha1.373@newssvr17.news.prodigy.com...
> In my work environment, the first thing I try to do is
"GetWindowsDirectoryA" to figure out what OS I'm running on..
I think GetVersionEx mght be a better choice for determining on what O/S you
are running. That call will let you discriminate down to the service pack
level on NT/2K/XP.
MCM
| |
| Donald Tees 2004-08-05, 3:55 pm |
| Denny Brouse wrote:
> Donald,
>
> I appreciate you re-enforcement of the shell to cmd.exe/command.com as one
> method. I was very surprised that something as useful as a "CopyFolder"
> command didn't exist in the API. In my work environment, the first thing I
> try to do is "GetWindowsDirectoryA" to figure out what OS I'm running on,
> so that's already pretty much handled. I wasn't aware that XCOPY still
> existed on a W2K box, but then again, I haven't had the need until now to
> look. <G>.
>
> Thanks a bunch for your input.
>
> Denny
>
I have an "execute" subroutine that will do the job for you pretty
quickly if you can string togeteher the appropriate command line for the
OS. Drop me a line if you'd like a copy.
Donald
| |
| JerryMouse 2004-08-05, 8:55 pm |
| Xref: kermit comp.lang.cobol:92885
Donald Tees wrote:
> Denny Brouse wrote:
>
> The fast and dirty way is to shell to cmn using xcopy(your 2). You
> will
> have to differentiate by platform. (command/cmd)
Psst!
On XP: Start/Run/command
Prepare to be amazed.
> The other is to take
> a
> look at the findfirst and findnext cobol subroutines in the same
> library, and code the copies using the output. Java script is
> overcomplicating the issue IMO.
>
> Donald
| |
| JerryMouse 2004-08-05, 8:55 pm |
| Denny Brouse wrote:
> Good evening,
>
> Once again, I have run into a little, shall we say, challenge with
> Windows and Fujitsu PowerCobol. I have a project in which I need to
> copy an entire folder and its' contents to another Windows 2000
> server. Initially, I figured "no big deal", since I think I have
> finally mastered using the Fujitsu CBL_COPY_FILE routine for file
> copies and the Standard "ShellExecuteA" Windows API for shelling out
> to other stuff. OK, I retract the "mastered" part of the previous
> sentence and will state simply that usually it works for me. <g>
>
> The task is to:
>
> "COPY <source drive letter>:\<some path name>\*.* TO <destination
> drive letter>\<some path name>\*.*". Or even better, COPY <source
> drive letter>:\<some path name> TO <destination drive letter>\<some
> path name> and have the files underneath come along for the ride.
> There are no sub folders under <some path name> so at least I don't
> have to deal with that.
>
> However, much to my chagrin, I can't get wildcards to work with the
> CBL_COPY_FILE routine, although it is entirely possible that I'm not
> passing the correct information to the routine. Based on my DEBUG
> displays, everything looks as it should and the routine copies a
> single file just fine. When I replace the single file name with *.*,
> it doesn't give me an error, but it also doesn't work. I'm using the
> CBL_CREATE_DIR routine to create the folder on the WIndows 2000
> server if it doesn't exist, and that works fine as well.
>
> So me being the inquisitive guy that I am, I went to the Microsoft
> support site looking for a way to copy a folder and it contents from
> one place to another, perhaps without any wildcards and perhaps
> eliminating the CBL_CREATE_DIR piece as well. I came up with two
> possibilities. I'm sure there are more, but I stopped at these two
> for the moment.
>
> 1. A java script, but the only java I know anything about is the
> stuff that goes into my coffee cup,
>
> 2. The other was a part of the normal Windows shell32.dll (and
> associated lib "shell32.lib") named SHFileOperation. I think I have
> the C++ stuff translated back to COBOL (references and values, etc.),
> but I'm getting an "unresolved external reference" when I attempt to
> call "SHFileOperation". Yes, I have shell32.lib in my link
> parameters. In fact I have a call to "ShellExecuteA" in the same
> program and that works just fine.
>
> I'd post the SHFileOperation code I'm trying to set up, but I'm home
> and my work place no longer allows newsgroup access from our
> workplace. However, I'll E-mail the code to myself tomorrow, so I
> can respond to the group accordingly.
>
> I even thought about executing the Windows 2000 cmd.exe with a "copy"
> parameter, but I've never tried that either. I figure that I'm just
> doing something stupid, as I frequently do when I talk to Windows via
> COBOL, but I was hoping that one of you fine experts can point me in
> the right direction.
I can send you a FJ COBOL routine that implements the GetNext API so you
could cycle through the source folder copying files individually to the
target, viz:
GetFirst
Perform until Return-code not = 0
fiddle with file names
copy source to target
GetNext
End-perform
Also, use "CBL_COPY_FILE2" instead of "...FILE" - this can handle imbedded
spaces in the filename.
| |
| Denny Brouse 2004-08-06, 8:55 am |
| Michael,
Thanks for the tip. I'm not familiar with that one. Being a Unisys
mainframe guy, I'm not much of a Windows guy as yet, but I'm sure trying to
learn.
Again, thanks!
Denny
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:DWpQc.680$r_1.264434@newssvr28.news.prodigy.com...
> "Denny Brouse" <denden@prodigy.net> wrote in message
> news:rloQc.465$Ha1.373@newssvr17.news.prodigy.com...
> "GetWindowsDirectoryA" to figure out what OS I'm running on..
>
> I think GetVersionEx mght be a better choice for determining on what O/S
you
> are running. That call will let you discriminate down to the service pack
> level on NT/2K/XP.
>
> MCM
>
>
>
>
>
>
| |
| Denny Brouse 2004-08-06, 8:55 am |
| Jerry,
While researching the project I saw a number of VB routines to use the
GetFirst, GetNext routines, but they seemed a little over my head. It
would be great if you would be willing to share your routine. I have a
shell to command/cmd almost working, but it sounds like your approach might
be better.
Thank you very much!
Denny
"JerryMouse" <nospam@bisusa.com> wrote in message
news:_rCdnfTD16p8O4_cRVn-hg@giganews.com...
> Denny Brouse wrote:
>
> I can send you a FJ COBOL routine that implements the GetNext API so you
> could cycle through the source folder copying files individually to the
> target, viz:
>
> GetFirst
> Perform until Return-code not = 0
> fiddle with file names
> copy source to target
> GetNext
> End-perform
>
>
>
> Also, use "CBL_COPY_FILE2" instead of "...FILE" - this can handle imbedded
> spaces in the filename.
>
>
|
|
|
|
|