Copy Contents of Folder to Network Drive With Fujitsu PowerCOBOL

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 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 entir
e
> 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 retrac
t
> 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> a
nd
> have the files underneath come along for the ride.  There are no sub folde
rs
> 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 passi
ng
> 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 tha
t
> 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 m
y
> 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 directio
n.
>
> 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

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
>
>

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 
entire 
retract 
and 
folders 
passing 
an 
to 
that 
support 
to 
sure 
that 
associated 
an 
"SHFileOperation". 
my 
However, 
doing 
but I 
direction. 
>
> 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,

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 
> entire 
> retract 
> and 
> folders 
> passing 
an 
to 
that 
support 
to 
sure 
> that 
associated 
an 
"SHFileOperation". 
> my 
However, 
doing 
but
> I 
> direction. 
>
>

"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

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

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

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.

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
>
>
>
>
>
>