开云体育

Sorry: problem with the english language:

"the parameters on fopen are just an additional method which must not be used."

should read

"the parameters on fopen are just an additional method which can be used or not"

maybe there are better ways to express this ... the original wording was wrong, IMO.?

I don't have much experience with english speaking;
I am only writing IT-related posts since almost 20 years now.
Hope you don't mind.

Sorry again, kind regards

Bernd

开云体育

To be honest, I don't like either, as they both appear to be a kludge. If I had to pick, I would recommend the first and forget the second. That and $3 might buy you a cup of coffee ;-) and if it matters and you have to or want to keep the external characteristics in the code, I'd recommend, as those extra items would come after the 'standard' C parameters.

fopen("my.file",w,recfm=v,lrecl=300,blksize=304);

The syntax of the IBM compilers is as follows:

fopen("my.file","w,recfm=v,lrecl=300,blksize=304");

that is, the second parameter which contains the mode and all the additional options
is a C string (as in the ANSI C function definition for fopen).

BTW: you don't need to use DSN names for the files as in this case;
you can use DDNames as well, if you use this syntax: DD:DDNAME
(that is: ddnames, prefixed with DD:).
And: for the filenames, there is the common rule from TSO;
if with apostrophes, nothing is added, but if without apostrophs,
the user assigned to the job or session is added.

I understand the challenge is dealing with record based I/O rather than stream I/O. Is this a case of not putting that information in the code and leaving it to a FILEDEF to handle the external characteristics? Then your code would be more portable because you would be externalizing those items which are specific to IBM.

FILEDEF MYFILE DISK MY DATA A ( recfm=v lrecl=300 blksize=304
...
fopen(MYFILE,w);?

HTH

kind regards

Bernd

Ready; T=0.01/0.01 00:34:42

type forth $prog$

?

:HELLO

.' HELLO!

$

?

Ready; T=0.01/0.01 00:34:54

forth

Your FORTH extensions loaded

FORTH ready

?

hello

HELLO!

?

end

Do you want to save your extensions (Y/N)?

n

Ready; T=0.01/0.02 00:35:06

Now I am thoroughly confused. I have no idea where HELLO is being saved. I erased FORTH $PROG$ A, and logged off, then logged back in ...

Hello Mark,

It looks like the treatment of character data is rather primitive in this version of FORTH. A string with no blanks can be printed with the command .' (dot apostrophe). You need a blank after the .' otherwise I think it wants to interpret what you typed as a number to be put on the stack (hence the error message):

Any ideas?

On Sun, Jun 5, 2022 at 07:32 PM, Jay Maynard wrote:

Except that your proposal is not valid C syntax. That's
why the first proposal is done that way.

Please help me understand your comment. Given that the definition
is ...

FILE *fopen(const char *restrict pathname, const char *restrict mode);

and:

"The fopen() function opens the file whose name is the string
pointed to by pathname and associates a stream with it."

How is using a DDNAME, which points to a file not valid C syntax?
Or is that what fdopen would be used for?

开云体育

Except that your proposal is not valid C syntax. That's why the first proposal is done that way.

On Sun, Jun 5, 2022, 19:30 Mark A. Stevens via <marXtevens=[email protected]> wrote:

On Wed, Jun 1, 2022 at 03:21 PM, Dave Wade wrote:

fopen("my.file","w,recfm=v,lrecl=300,blksize=304");

?

would open “MY FILE A” for writing with variable record lengths, maximum record length of 300, block size 304. I was intended to fix PDPCLIB to work the same way, but when I checked in

?

HELP GCCLIB

?

I see that this has been extended to allow this information to be specified as part of the file name. So the above would need to be….

?

fopen("my file a v 300”,”w”);

?

I think I should fix BOTH libraries to work BOTH ways.

Does any one have any thoughts on this.

To be honest, I don't like either, as they both appear to be a kludge. If I had to pick, I would recommend the first and forget the second. That and $3 might buy you a cup of coffee ;-) and if it matters and you have to or want to keep the external characteristics in the code, I'd recommend, as those extra items would come after the 'standard' C parameters.

fopen("my.file",w,recfm=v,lrecl=300,blksize=304);

I understand the challenge is dealing with record based I/O rather than stream I/O. Is this a case of not putting that information in the code and leaving it to a FILEDEF to handle the external characteristics? Then your code would be more portable because you would be externalizing those items which are specific to IBM.

FILEDEF MYFILE DISK MY DATA A ( recfm=v lrecl=300 blksize=304
...
fopen(MYFILE,w);?

Current man page documentation for fopen() includes the following as values for the second parameter.

       The argument mode points to a string beginning with one of the
       following sequences (possibly followed by additional characters,
       as described below):

       r      Open text file for reading.  The stream is positioned at
              the beginning of the file.

       r+     Open for reading and writing.  The stream is positioned at
              the beginning of the file.

       w      Truncate file to zero length or create text file for
              writing.  The stream is positioned at the beginning of the
              file.

       w+     Open for reading and writing.  The file is created if it
              does not exist, otherwise it is truncated.  The stream is
              positioned at the beginning of the file.

       a      Open for appending (writing at end of file).  The file is
              created if it does not exist.  The stream is positioned at
              the end of the file.

       a+     Open for reading and appending (writing at end of file).
              The file is created if it does not exist.  Output is
              always appended to the end of the file.  POSIX is silent
              on what the initial read position is when using this mode.
              For glibc, the initial file position for reading is at the
              beginning of the file, but for Android/BSD/MacOS, the
              initial file position for reading is at the end of the
              file.

I REALLY Hope This Helps.

?... Mark S.

Except that your proposal is not valid C syntax. That's why the first proposal is done that way.

       FILE *fopen(const char *restrict pathname, const char *restrict mode);

       The fopen() function opens the file whose name is the string
       pointed to by pathname and associates a stream with it.

fopen("my.file","w,recfm=v,lrecl=300,blksize=304");

?

would open “MY FILE A” for writing with variable record lengths, maximum record length of 300, block size 304. I was intended to fix PDPCLIB to work the same way, but when I checked in

?

HELP GCCLIB

?

I see that this has been extended to allow this information to be specified as part of the file name. So the above would need to be….

?

fopen("my file a v 300”,”w”);

?

I think I should fix BOTH libraries to work BOTH ways.

Does any one have any thoughts on this.

       The argument mode points to a string beginning with one of the
       following sequences (possibly followed by additional characters,
       as described below):

       r      Open text file for reading.  The stream is positioned at
              the beginning of the file.

       r+     Open for reading and writing.  The stream is positioned at
              the beginning of the file.

       w      Truncate file to zero length or create text file for
              writing.  The stream is positioned at the beginning of the
              file.

       w+     Open for reading and writing.  The file is created if it
              does not exist, otherwise it is truncated.  The stream is
              positioned at the beginning of the file.

       a      Open for appending (writing at end of file).  The file is
              created if it does not exist.  The stream is positioned at
              the end of the file.

       a+     Open for reading and appending (writing at end of file).
              The file is created if it does not exist.  Output is
              always appended to the end of the file.  POSIX is silent
              on what the initial read position is when using this mode.
              For glibc, the initial file position for reading is at the
              beginning of the file, but for Android/BSD/MacOS, the
              initial file position for reading is at the end of the
              file.

开云体育

I followed some discussions on this topic between Paul (I don't recall his last name, the maintainer of mainframe GCC)
and the community in the past. Paul always had his own mind and was not very open to others' opinions.

IMHO, the first argument of fopen is the file name, and the second is attributes of the file (like "binary" in the
non-mainframe world). So the CMS filemode IMO would belong into the first argument, but the other
parameters like RECFM etc. into the second. That said, the IBM way to do it seems very OK for me
(I am used to this since 1995 ca., OTOH). ... this is true for other "incompatibilities" between GCC and
IBM's C as well. And: the runtime of IBM's C (which is LE, BTW) always served me as a guideline, when I had
to make decisions for the runtime of my Stanford Pascal compiler.?

Kind regards

Bernd

开云体育

?

开云体育

is that the right way to it?