Re: Printing from ILE/C program running in QUSRWRK

Jevgeni Astanovski <[email protected]>
Newsgroups gmane.comp.lang.as400.c
Message-ID <CAJuVQr2TtbDR9jZiQw50LM1FQVdcXedwCoJmGR7F1x2G7i3HHw@mail.gmail.com>
Hi, Scott and Chuck
First of all I should say that I feel myself like that fool, who complains
that his favorite program on PC does not work forgetting to mention that
the display is black and probably the power cord is also not plugged into
the wall outlet.
I expected to get a spool file in an output queue as a result of output to
Log file.
I saw that it works fine in some of my programs and does not work in others.
There were 3 differences:
1. Working program was run in QBASE, while not working - in QUSRWRK.
2. Working program was compiled with ACTGRP(*NEW), while not working with
ACTGRP(*CALLER).
3. Working program was compiled with CRTBNDC, while not working - with
CRTBNDCPP.
In other words - working program was ILE/C, not working - ILE/C++.
Initially I thought that the first difference was important.
I was mistaken, I suppose.
So the results of my investigation are as follows:
The following C program compiled with CRTBNDC works fine:

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main (int argc, char *argv[])
{
  FILE *LogFile ;
  char szTemp[132] ;
  int ErrNum, i ;

  LogFile = fopen("*LIBL/EQRPT", "w") ;
  if (LogFile == NULL)
  {
    ErrNum = errno ;
    printf(" Error number %d is %s \n", ErrNum, strerror(ErrNum));
  }
  else
  {
    printf("Successfully opened print file\n") ;
    for (i = 0; i < 200; i++)
    {
      sprintf(szTemp, "This is row number %d\n", i) ;
      fwrite(szTemp, strlen(szTemp), 1, LogFile) ;
    }

    fclose(LogFile) ;
  }
  return(0) ;
}

That is I get no error and I get a spooled file.

As soon as I compile the same with CRTBNDCPP, I get 3025.
Whatever library name I put before slash,  assuming that EQRPT is there, I
get error message!

OK, *LIBL is excessive, as it anyhow looks in library for EQRPT, so if in
the C++ program I write
  LogFile = fopen("EQRPT", "w") ;
I do not get errors.
So the following C++ program (compiled with CRTBNDCPP) produces no errors
at all and "like works fine":

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>

int main (int argc, char *argv[])
{
  FILE *LogFile ;
  char szTemp[132] ;
  int ErrNum, i, n ;

  LogFile = fopen("EQRPT", "w") ;
  if (LogFile == NULL)
  {
    ErrNum = errno ;
    printf(" Error number %d is %s \n", ErrNum, strerror(ErrNum));
  }
  else
  {
    printf("Successfully opened print file\n");
    for (i = 0; i < 200; i++)
    {
      sprintf(szTemp, "This is row number %d\n", i) ;
      n = fwrite(szTemp, strlen(szTemp), 1, LogFile) ;
      if (n == 1)
        printf("Row %d output succeeded\n", i) ;
      else
        printf("Row %d output failed\n", i) ;
    }
    fclose(LogFile) ;
  }
  return(0) ;
}

However!!!
It does not produce a spool file. I see absolutely no evidence that it
writes something somewhere!

So the situation is a bit more clear :-), but does not remove the simple
question: "What's wrong?"

And additionally - _Ropen and its family works in C and C++ the same way,
they accept path and *LIBL and do what they are expected to.

Jevgeni.


On Wed, Oct 14, 2015 at 6:52 AM, Scott Klement <[email protected]>
wrote:

> Hi Jevgeni,
>
> Is it possible that you are using IFS mode,  for example, with
> SYSIFCOPT(*IFSIO) on the compile command?  This error looks like the one
> you get when you specify an unknown IFS path -- and, yeah, *LIBL/EQRPT
> would certainly not be a valid IFS path.
>
> The fopen() API and friends (fwrite, fputs, fgets, fclose, etc, etc) are
> designed to access the traditional library file system by default, but with
> SYSIFCOPT(*IFSIO) -- or similar options -- they switch to using IFS names.
> IFS names don't allow library list.
>
> Have you considered using _Ropen() and friends (record I/O functions) for
> a spooled file? It's been an awfully long time since I've generated a
> report from C, but I'm pretty sure that this is what I used. Something to
> think about...
>
> -SK
>
>
> On 10/13/2015 3:11 AM, Jevgeni Astanovski wrote:
>
>> Good morning, colleagues
>> It should be very simple, but looks like I am missing something
>> fundamental..
>>
>> When I need to generate printed output from my C program, I write
>> something
>> like:
>>
>> ....
>> FILE *LogFile ;
>> char szTemp[133] ;
>>
>> LogFile = fopen("*LIBL/EQRPT", "w") ;   // EQRPT - generic PRTF
>> sprintf(szTemp, "Printed output\n") ;
>> fwrite (szTemp, strlen(szTemp), 1, LogFile) ;
>> fclose(LogFile) ;
>>
>> ....
>>
>> works fine in batch and interactive programs. Produces a spool file in an
>> output queue as expected.
>>
>> However, when I place the same code in a program that runs in QUSRWRK (job
>> QZRCSRVS - a remote program call),
>> LogFile is *NULL after fopen and errno is 3025: "No such path or
>> directory"
>> produces strerror.
>> I run the job under debugger using strsrvjob to check if EQRPT is indeed
>> in
>> the path - I see that it is.
>>
>> Can someone explain what am I doing wrong?
>>
>> Thanks in advance,
>> Jevgeni.
>>
>>
> --
> This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
> mailing list
> To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/c400-l
> or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/c400-l.
>
>
-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.