Re: QSH find to print

On 22 May 2013 21:07, Vernon Hamberg wrote:

How about just a redirect like this -

qsh cmd('find . -name "*.c" > /qsys.lib/qprint.file')

If your user profile has the authority to create into QSYS [e.g. has *ALLOBJ special authority], then if the above quoted request was actually issued for a test, then be sure to verify that the creation of a device file [possibly with the attribute SAVF] named QPRINT in QSYS was not effected when that request was issued. Such a file, if created, could be problematic for jobs referring to QPRINT without an explicit library-qualification of QGPL; i.e. requests to /print/ using the printer device file named *LIBL/QPRINT would start to fail for attempting to write non-save-records to the save file with that name. Read further for an anomaly [¿apparent defect?] which existed in v5r3 [and may persist], to understand why I suggest checking for that outcome.

Not sure if that'd work, but something like it should. Maybe chain
an OVRPRTF command in the QShell command string.

In my experience, the use of the shell's "system" utility to effect an override is worthless because the "Run CL command" work is done in a different job from the Find activity; the effects of the override would not be visible. Even use of the -i /interactive/ option to have each CL request run "in the current job" seems not to assist; both that there are no effects from a job-scoped override on the later command requests, nor is the override visible in the job when the next request is to DLYJOB thus giving time to review. If the request to run is to activate a CLP or similar, wherein the override and other work are done within one request of the /system/ invocation, then an override applies to the work it performs just as expected.

Anyhow...

The redirection seems not to like a printer device file; at least on v5r3. So even if the specified name were corrected, e.g. to instead have named /QSYS.LIB/QSYSPRT.FILE as the target, then the request still fails with the same error 001-0055 "Error found creating file /qsys.lib/qsysprt.file. The value specified for the argument is not correct." The redirect apparently either wants to /create/ a /file/ into a directory or to clear\replace the data in an _existing_ "file". In /QSYS.LIB terms, that would mean replacing data in a ".MBR"; e.g. a target such as /qsys.lib/mylib.lib/myfile.file/thembr.mbr

Only the database *FILE object [i.e. none of the other variants of the same *FILE object type] serves as a /directory/ into which /files/ can be created [into which the data can be written]; again, with naming "membername.MBR". Thus the request could instead refer to a database file member. However that would not be helpful to effect spooling, unless the database file implements something like a TRIGGER which redirects the output as a side effect of the inserted data. In a native program coded to write to a database member, an output request that had been overridden to write to a printer file might fail merely because there is no /clear/ method supported. But mimicking such an override whereby the /qsys.lib/qsysprt.file/bogus.mbr is specified as the target, the secondary text for the 001-0055 error suggests that the cause is now, that the device file is "Not a directory"; which of course is accurate, albeit not helpful, if the hope were that the member name would just be ignored by the open of the named file.

Oddly, even disturbingly IMO, on v5r3 in a test, if the named file does not exist when using /QSYS.LIB IFS naming, then a file with that name is created as a Save File; i.e. a device file of the attribute SAVF is created as target for the redirection to a ".FILE". That is hardly a predictable or even a logical effect, because any data other than binary /save file/ records can not be written, and the Save File is clearly not a directory for .MBR "files". The /disturbing/ part is not just the choice of a device\save file as an apparent directory, but also that the same generic error is issued, yet that the named file actually gets created is counter-intuitive. The following request for example, will create a save file named MYLIB/NOTASAVF, even though the error suggests that the request failed; of course, by replacing MYLIB with a library other than QTEMP that is owned or authorized to your user profile:
qsh cmd('ls *.daft > /qsys.lib/MYLIB.lib/notasavf.file')

The above request will "fail" with "qsh: 001-0055 Error found creating file /qsys.lib/mylib.lib/notasavf.file. Operation not supported." but WRKF MYLIB/NOTASAVF issued afterward will show a save file in the list of one file, and 4=Delete will be necessary to cleanup that conspicuously undesirable effect\defect [which may or may not exist on newer releases than v5r3, on which I encountered the effect].