× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott

Nice - I'll use that sometimes - up to now I've usually wanted only the file name, so ls has worked just right.

Is find recursive by default? Haven't looked at the docs for awhile on it.

Also, I find that the redirection operator is perhaps more flexible than the override - can point either to an IFS file or to a physical file using path naming.

Thanks
Vern

Scott Klement wrote:
Personally, I prefer to use 'find' instead of 'ls' -- that way you get the path information as well as the filename.

Did you wind up with a solution like this? (This is off the top of my head, untested...)

PGM

DCL VAR(&EOF) TYPE(*LGL) VALUE('0')
DCLF FILE(FILELIST)

/* Create a file in QTEMP to receive the directory listing */

DLTF FILE(QTEMP/FILELIST)
MONMSG CPF2105
CRTPF FILE(QTEMP/FILELIST) RCDLEN(1000)


/* List IFS files to QTEMP/FILELIST */
/* change "/home/klemscot" to the IFS dir in question */

OVRDBF FILE(STDOUT) TOFILE(QTEMP/FILELIST)
STRQSH CMD('find /home/klemscot')
DLTOVR FILE(STDOUT)


/* Read list of files from QTEMP/FILELIST and run CPYFRMIMPF */

DOWHILE (&EOF *EQ '0')

RCVF
MONMSG CPF0864 EXEC(CHGVAR VAR(&EOF) VALUE('1'))

IF (&EOF *EQ '0') DO
CPYFRMIMPF FROMSTMF(&FILELIST) TOFILE(MYLIB/MYFILE) +
RCDDLM(*ALL)
ENDDO

ENDDO

ENDPGM




Dan Rasch wrote:
Yes, the ls command was easier and probably alot more stable.

Already running . . . .
To: midrange-l@xxxxxxxxxxxx
Subject: Re: multiple object links from the CPYFRMIMPF command
From: rob@xxxxxxxxx
Date: Mon, 9 Mar 2009 16:11:08 -0400

Ow do I hurt! Thanks Scott for the thorough explanation.
Yes, I recommend the IFS api's or the ls to the database file and process those rows with something more "traditional".

All this fun and I've opened up 5 new pmr's today and updated a couple.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
03/09/2009 03:07 PM
Subject:
Re: multiple object links from the CPYFRMIMPF command
Sent by:
midrange-l-bounces@xxxxxxxxxxxx





rob@xxxxxxxxx wrote:
I suppose if you get really good at this you can figure out how to do something like
ls '/home/drasch' || system CPYFRMIMPF ...
and pipe the output directly into CPYFRMIMPF but I only know enough to send you on a wild goose chase.
To pipe the output somewhere, you'd have to use a single pipe.

ls '/home/drasch' | system CPYFRMIMPF ...

the double-pipe you used would only run the "system" command if the "ls" command ended in error. :) (I know that's not what you were going for)

The big problem with this scenario is that CPYFRMIMPF isn't a Unix command and doesn't read STDIN looking for a list of filenames... You have to specify the filename in the FROMSTMF parameter, not pipe it to STDIN...

If you really wanted a (poor performing) way of doing the whole shebang from QShell, you could use the "find" utility. "find" has the capability of running a command for every file that matches a given pattern. For example (this should be all one line -- though I'm sure the e-mail software will wrap it):

find /home/klemscot -name '*.csv' -exec system "cpyfrmimpf fromstmf('{}') tofile(mylib/myfile) rcddlm(*all)" \;

This tells the 'find' utility to search the /home/klemscot folder of the IFS. It will find all files that match the pattern *.csv (make sure that's in quotes, as I have it above, otherwise QShell will treat the * as a special character and you'll have anarchy). The -exec parameter tells it to execute a command for every file that it finds.

in this case, it executes the QShell "system" command, which runs a CL command. The \; signals the end of the command you want the -exec switch to run.

The {} characters in the middle of the command string will be replaced with the filename that the "find" utility finds. It will submit a new job for each file that it finds, so if there are many that match the wildcard, this will perform poorly. If you only expect one or two that match, this is probably okay.

Personally, I wouldn't do it this way because of the performance. Another problem with this approach is error handling... it's hard to do a good job of handling errors that might occur on the CPYFRMIMPF command.

Then, there's the fact that you'll have to understand Unix shell scripting well enough to write/maintain the code... Let's use Rob's example (since I don't think Rob will be offended if I pick on him)

This was his first example:

system dspf /rob/duh.txt

This is perfectly valid as far as Qshell is concerned. But it leaves you with "dspf /rob/duh.txt" being passed to the native command-line. You can't have a / character in a native command line unless it's put in quotes... quotes is where the headaches will start.

Rob's second example:

system dspf '/rob/duh.txt'

Qshell will assume those quotes are meant for Qshell, not to be passed to the native command. The single quotes are "strong quotes" and mean that the contents inside them are not to be taken as special characters. So QShell will pass /rob/duh.txt directly to the native command interpreter without trying to interpret them further -- which is okay, except that Qshell will strip the single quotes off of the command first -- so we're right back to the first error. This is what gets passed to QCMD: dspf /rob/duh.txt

Back to square one, / being in the command without quotes surrounding it. Whenever you go through multiple command interpreters (both QShell and QCMD in this case) things get ugly like this.

Rob's next example:

system DSPF STMF('/rob/duh.txt')

Both the single quotes, and the parenthesis here will be interpreted as special characters by QShell. The parenthesis aren't in a valid place for QShell to use them, so you get the "token not expected". If they had been in the right place for Qshell, you'd have the same problem as before... the quotes would be stripped before sending it to QCMD.

The solution is easy, just put double quotes around the whole thing. Then QShell won't try to do any special interpretation of the single quotes or the parenthesis...

system "DSPF STMF('/rob/duh.txt')"

This is now syntactically legal... but now you have a new problem! DSPF is an interactive 5250 command, and QShell submits a background job (BCI job) to run the command. So it'll fail with "DSPF not allowed in this setting" since you can't run DSPF in a batch job.

However, if you used CPYFRMIMPF or another command that's allowed in batch, this syntax would work... If you followed all of that, you'll see why I used the syntax that I did in the "find" example. But the next person to maintain your code may not understand all of this.

So that, plus performance, etc, etc, is why I'd recommend using the IFS APIs or having QShell output to a file, then read the file from CL. It's just easier...

this is getting too long, so I'll stop here.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

_________________________________________________________________
Windows Live™ Groups: Create an online spot for your favorite groups to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.