Re: Printing from ILE/C program running in QUSRWRK

Hi Jevgeni,

	As Scott mentioned, the problem is the system interface option.  Long
ago when the C++ compiler was added to the system they decided to use a
different default system interface option than was used for the C compiler.
The default for the C compiler is SYSIFCOPT(*NOIFSIO), whereas the default
for the C++ compiler is SYSIFCOPT(*IFS64IO) (64-bit IFS interfaces).  In
order to get the same behavior as the C compiler you should specify
SYSIFCOPT(*NOIFSIO) on the C++ compile command.  Right now the C++ program
is successfully writing to the "EQRPT" file in your default IFS directory.

Thanks,

Aaron




From:	Jevgeni Astanovski <[email protected]>
To:	"Bare Metal Programming IBM i (AS/400 and iSeries)"
            <c400-l-Zwy7GipZuJhWk0Htik3J/[email protected]>
Date:	10/14/2015 03:05 AM
Subject:	Re: [C400-L] Printing from ILE/C program running in QUSRWRK
Sent by:	"C400-L" <c400-l-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]>



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.


-- 
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.