I have an issue when I use fgets to open a STDIN stream from an iSeries box. It works all fine and well - I get my data and do stuff with it. However! I want to create an error log via a flat file ie .txt but I am unable to create that file??

I'm most likely missing something but I think having that STDIN stream open is blocking me from creating a flat file. So, my thought was to use fclose to stop that stream after I receive my data.

Here is my code condensed :

//DEFINE STANDARD INPUT
if( !defined( "STDIN" ) ) {
  define( "STDIN", fopen( 'php://stdin', 'r' ) );
}

//GET STANDARD INPUT FROM AS/400
$input  = fgets(STDIN);

//BREAK DATA INTO AN ARRAY - SEPERATED BY ' ! ' 
$data   = explode('!', $input);

//SET ACCT NO VARIABLE
$acctNO = rtrim($data[0]);

//GET EMAIL TYPE - EITHER  1 OR 2
$emailType = rtrim($data[1]);

// GETTING DATA
// DOING STUFF
// ERROR CHECKING
// BLAH BLAH


if(isset($error) && $error == 'YES'){
  //setup error log and email alert

  //SENDING EMAIL NOTICE OF ERROR
  mail ($to, $subject, $msgErr, $mailheaders);

  // ATTEMPTING TO CLOSE STANDARD INPUT STREAM
  // ###### PROBLEM AREA ######
  fclose(STDIN); 
  fclose(STDOUT);
  fclose(STDERR);
  fclose($input);


  $date = date('Ymd');


  //#####################
  //#####################
  //
  //WRITE ERROR MSG TO ERROR LOG
  //
  //#####################
  //#####################
  $fileName = "error_".$date.".txt";
  $file = fopen($fileName, 'w');
  fwrite($file, "Business Name: ".$bname."\n");
  fwrite($file, "Acct No.: ".$acctNO."\n\n");
  fwrite($file, "-----------------------------\n\n");
  fwrite($file, "Error MSG: \n\n");

  foreach($errMsg as $em){
    fwrite($file,"".$em."\n");
  }
  fclose($file);


}
//NO ERRORS SEND EMAIL
else{

When I add the 'fclose' same outcome. Script runs fine but doesn't create the .txt file.

The other odd thing I think associated to this is... I cannot use 'includes' or 'requires', it will bomb out on the 400 side. Though, I can call the DB get data, mail info, etc.. but I cannot include or write to a .txt file. Not sure what is happening. Maybe Dr. Egon Spengler has something to do with this?

fyi.. This script is called via RPG & CL.

I appreciate any insight.

Happy ? day!

    jeepin81;10990997 wrote:

    I'm most likely missing something but I think having that STDIN stream open is blocking me from creating a flat file.

    I highly doubt it.

    jeepin81;10990997 wrote:

    So, my thought was to use fclose to stop that stream after I receive my data.

    shrug I doubt it's going to help solve any problems, but doing so shouldn't create new ones either.

    jeepin81;10990997 wrote:
    fclose($input);

    That line should be generating an error message since $input is not a file resource (unless you redefined it in the section(s) of code you've omitted above).

    jeepin81;10990997 wrote:

    Script runs fine but doesn't create the .txt file.

    .. well then it didn't run "fine" then, did it? That's like saying your script is problem-free other than the problems you're having with it.

    Speaking of problems/errors, do you have error_reporting set to E_ALL, log_errors set to On, display_errors set to Off, and error_log set to a sensible value? If no, why not?

    jeepin81;10990997 wrote:

    The other odd thing I think associated to this is... I cannot use 'includes' or 'requires', it will bomb out on the 400 side.

    Sounds like you weren't providing the correct file path to the include (or perhaps that include had some sort of errors on it) and PHP is configured to output errors over STDOUT (i.e. display_errors is set to On).

    Again, not only would this not even be an issue if you have the error reporting directives correctly configured (as I asked above), but the PHP error messages written to the error log would help you give us a more diagnostically-relevant description than "bomb out."

      .. well then it didn't run "fine" then, did it? That's like saying your script is problem-free other than the problems you're having with it.

      okay. It executed minus the .txt doc being created.

      Speaking of problems/errors, do you have error_reporting set to E_ALL, log_errors set to On, display_errors set to Off, and error_log set to a sensible value? If no, why not?

      I have not checked into this part yet. my mistake for asking the question before doing so. will do asap.

      Sounds like you weren't providing the correct file path to the include (or perhaps that include had some sort of errors on it) and PHP is configured to output errors over STDOUT (i.e. display_errors is set to On).

      If I remove the STDIN aspect of this script and replace it with static data and test via a browser window all of my includes work properly. If I remove the includes and add the exact same code from those includes into the script, it will execute w/ a STDIN stream - minus the .txt doc being created. From my memory(b/c I don't have a screen shot of the "bomb out") it was giving a 225 or 255 error on the green screen w/ the includes.

      In regard to you saying it is a path issue w/ the includes, would the path be different from the script being called via the CL opposed to me calling the script via a browser window? The path the CL uses to call the script is:

      /www/zendcore/htdocs/my_directory/my_php_script.php

      my includes are located

      /www/zendcore/htdocs/my_directory/my_includes/

      I will check my error logs shortly.

        jeepin81;10991004 wrote:

        The path the CL uses to call the script is:

        /www/zendcore/htdocs/my_directory/my_php_script.php

        my includes are located

        /www/zendcore/htdocs/my_directory/my_includes/

        Okay, but where is the script actually being called from? That is, what is the CWD (current working directory) at the time that the PHP parser is invoked to execute "my_php_script.php" ?

        Just because "my_php_script.php" is located at the path you gave above doesn't necessarily mean that "./my_includes/" is a valid path to get to the includes directory. You could be invoking PHP from an entirely different directory, and "./my_includes" (or any equivalent relative path to a file in that directory, e.g. "my_includes/foo.php") would be taken relative to that external directory, not the directory containing the PHP file you're passing in for execution.

        EDIT:

        jeepin81;10991004 wrote:

        I have not checked into this part yet.

        Make sure you check from the CLI, too, if at all possible; the settings obtained from phpinfo() (for example) through the use of a webserver (e.g. Apache) don't necessarily tell you anything about the settings PHP picks up when invoked directly from the CLI; the php.ini config files used in either scenario might not be the same.

        EDIT2: Also, note that you might consider using [man]ini_set/man to explicitly set the error-related directives I mentioned above. The benefit there is that there's no guesswork involved, plus it's more portable in the sense that even if you moved the code to a development server (e.g. where display_errors is set to On), you wouldn't have to worry about trying to debug different behavior from the AS/400 because it's suddenly receiving PHP error output.

          Thanks Brad... That was the issue w/ the includes and where the text file was being written/created. Also, the source of my includes issue.

          I'm not too familiar w/ the iSeries, so I hope my terminology come across okay. What is happening now - who ever runs the script from the green screen cmd line it will drop that text file into their personal folder on the iSeries IFS. Is there a way I can define the path so it's always starting at the root?? That way I can set up a proper path for my text file and for my includes.

          The reason I ask is b/c this is going to be ran by not only individual users but in a batch program w/ our nightly runs.

          I appreciate all the help.

            jeepin81;10991014 wrote:

            Is there a way I can define the path so it's always starting at the root??

            Start with '/' and build the path from there (much like you already did in your previous post) - a.k.a. using an absolute path rather than a relative path.

              Brad... I appreciate your help. The absolute path is what I needed.

              Thanks again... will marke as resolved.

                Write a Reply...