I’m not entirely sure this is something that would work. The system I’m on is where the file is, so i can’t very well FTP to the same system.This is in the IFS and I get to the file using the WRKLNK ‘/’ command. One of the directories holds a .CSV file and i’m just trying to retrieve the name of the .CSV file. The only option i can think of is to do a DSPLNK and mark the output as *PRINT, then copy the spooled file to a physical flat file and read that. Since there’s only going to be 1 file in there at a time per day, this might be one of the few workarounds without having to use API’s, which, i’m not entirely opposed to. It just seems that there should be an easier way to deal with the IFS.

…so i can’t very well FTP to the same system.
 
Why not? Is it restricted?
 
FTP to/from same system might be the easiest way to do it. It’s certainly possible to read directory entries, but it’s a little more complicated.
 
Tom

If you prefer an actual programmed solution, Qshell isn’t necessary. ILE CL can read directories directly:

pgm    ( +
         &DirName     +
       )

   dcl   &DirName     *char  128


   dcl   &FName       *char  640

   dcl   &x00         *char    1     value( x’00′ )

   dcl   &rc          *int
   dcl   &subrc       *int

   dcl   &Dir         *char  128
   dcl   &Link        *char  640

   dcl   &BUF         *char 4096
   dcl   &mtime       *int           stg( *defined ) defvar( &BUF    29 )
   dcl   &oType       *char   10     stg( *defined ) defvar( &BUF    49 )

   dcl   &pCTime      *ptr
   dcl   &CTime       *char   24     +
                         stg( *BASED )  +
                         basptr( &pCTime )

   dcl   &pDir        *ptr
   dcl   &DirDS       *char    1     +
                         stg( *BASED )  +
                         basptr( &pDir )

 /* Directory entry DS */
   dcl   &pDirEnt     *ptr
   dcl   &DirEnt      *char 1024     +
                         stg( *BASED )  +
                         basptr( &pDirEnt )
   dcl   &res1        *char   16     stg( *defined ) defvar( &DirEnt  1 )
   dcl   &sgenid      *uint          stg( *defined ) defvar( &DirEnt 17 )
   dcl   &sfileno     *int           stg( *defined ) defvar( &DirEnt 21 )
   dcl   &sreclen     *uint          stg( *defined ) defvar( &DirEnt 25 )
   dcl   &res2        *int           stg( *defined ) defvar( &DirEnt 29 )
   dcl   &res3        *char    8     stg( *defined ) defvar( &DirEnt 33 )
   dcl   &snlsinf     *char   12     stg( *defined ) defvar( &DirEnt 41 )
   dcl   &snamlen     *uint          stg( *defined ) defvar( &DirEnt 53 )
   dcl   &sfname      *char  640     stg( *defined ) defvar( &DirEnt 57 )

   dcl   &nullptr     *ptr


   monmsg    ( cpf0000 mch0000 cpf9999 ) exec( goto StdErr )


   chgvar            &Dir         ( &DirName *tcat &x00 )

   callprc     ‘opendir’          ( &Dir ) rtnval( &pDir )
   if ( &pDir *eq &nullptr )  +
      goto  Close_Dir

   dountil  ( &pDirEnt *eq &nullptr )

      callprc     ‘readdir’       ( &DirDS ) rtnval( &pDirEnt )
      if ( &pDirEnt *ne &nullptr )  +
         callsubr    OutEntry     rtnval( &subrc )

   enddo

   goto  Close_Dir

StdErr:

   dmpclpgm
   monmsg (cpf0000 cpf9999 mch0000)

Close_Dir:

   callprc     ‘closedir’         ( &DirDS ) rtnval( &rc )
   monmsg (cpf0000 cpf9999 cee0000 mch0000)

   return

subr     OutEntry

   if ( &snamlen *gt 0 )  do
      chgvar        &FName    %sst( &sfname 1 &snamlen )
      chgvar        &Link         ( +
                                    &DirName *tcat ‘/’ *cat +
                                    &FName   *tcat +
                                    &x00  +
                                  )
      callprc     ‘stat’          ( &Link &BUF ) rtnval( &rc )

      if ( &rc *eq 0 )  do
         callprc  ‘ctime’         ( &mtime ) rtnval( &pCTime )
         sndpgmmsg   msgid( CPF9898 ) msgf( QCPFMSG ) +
                       msgdta( +
                               ‘Object Found’   *bcat +
                               &CTime           *bcat +
                               &FName           *bcat +
                               &oType                 +
                             ) +
                       msgtype( *INFO )
      enddo
      else  +
         rtnsubr rtnval( -1 )
   enddo

   endsubr

endpgm

The program accepts a 128-char directory and lists its contents via messages. Note that the directory name parm value must be padded with blanks if it’s shorter than 128 characters.
 
Compile as a *MODULE. Then use CRTPGM to create the program from the *MODULE and specify BNDDIR(QC2LE) to pull in the APIs.
 
Modify it to cut out the stuff for sending the messages. It’s just an example program, so it can simply return a file name as an output parm. Use this version just to see how opendir(), readdir() and closedir() work.
 
Note that all directories include the [.] and [..] entries. Simple IF-tests can skip those.
 
Tom

oh, I thought the files were still on the other system when you had to determine the dynamic name.  Although as Tom mentioned, you can FTP back to yourself and it shouldn’t be restricted, as the data is already being FTP’d to you.

BigKat, agreed. My mistake. Company is sending us the file, i just have to retrieve it and don’t know the name. But i found the code that completely helps.Tom, thanks. I think the resolution i posed with the clle code is an actual programmed solutions. I’m using code within a source member to retrieve information. i can make it a dynamic process for other programs to use, but i didn’t because this isn’t a common issue.I appreciate the help from both though!

Re BigKat’s FTP: Essentially all network functions can be routed right back to the originating server. It’s a very useful testing technique to remember for the future. Testing can be done even when you only have a single server simply by using appropriate host names (or IP addresses or even APPN control point names).
 
Re “programmed solution”: Yes, Scott Klement’s method is indeed. To clarify, I was referring to FTP and supplying an alternative to that. Other members following the thread might not allow FTP to be active on their server. Your acceptance of Scott’s work indicated that you were wanting direct programming rather than something of a workaround (i.e., FTP). So, I was showing the basics that was even more direct and that didn’t require an optional OS component. I use Qshell regularly on my own systems just as you’re using it.
 
But because I also work on many other systems, I know that lots of members need alternatives. Qshell won’t be available for some others, and PTF issues might cause trouble for some in production environments.
 
Qshell interaction with QSYS.LIB features does get a little twisted from time to time. If direct access to /root via APIs is understood, or at least working examples are available, some members will get use out of it.
 
Tom