Thanks to all contributors, I am pleased to post a test version of the third
release of VMCE. This is a release candidate version, and is available for anyone
to download, for testing purposes. I would like to set a target date for the final 1.1.2
version for about 2 weeks from now. If you have time to take a look and comment
here in the forum, I would really appreciate it.

The downloaded unzipped directory from my DROPBOX contains file:
readme-vmce-1_1_2.txt which provides a list of the changes.



I hope you take a look and find some bugs.
Bob Bolch

开云体育

开云体育

开云体育

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);?

This is, of course, possible with VM and with MVS;
you can specify all the options on FILEDEF or on DD statements (in MVS JCL);
the parameters on fopen are just an additional method which must not be used.
I never use it, just to keep my programs as portable as possible,
so that they run with minimum changes on Linux and Windows etc.
and on the mainframe environments.

HTH

kind regards

Bernd

On Mon, Jun 6, 2022 at 11:41 PM, René Ferland wrote:

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

Finally, this is my experience with what you did, repeated on my system.

Written new file: FORTH $PROG$ A1
Ready; T=0.11/0.15 19:07:15
type forth $prog$ a
?
:HELLO
.' HELLO!
$
?
Ready; T=0.01/0.01 19:07:23
forth
Your FORTH extensions loaded
FORTH ready
?
hello
HELLO???? Invalid NUMERIC field
?
end
Do you want to save your extensions (Y/N)?
Y
'FORTH $PROG$ A'? I/O ERROR
ERROR 00?? - Inform Technical Support
Ready; T=0.01/0.01 19:08:27
type forth $prog$ a
?
:HELLO
.' HELLO!
$
?
Ready; T=0.01/0.01 19:10:17
forth
Your FORTH extensions loaded
FORTH ready
?
hello
HELLO???? Invalid NUMERIC field
?
end
Do you want to save your extensions (Y/N)?
n
Ready; T=0.01/0.01 19:10:26

?... Mark S.

On Tue, Jun 7, 2022 at 07:51 PM, Mark A. Stevens wrote:

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

L XMAS
ENTER PASSWORD:
?
DASD 190 LINKED R/O; R/W BY MAINT; R/O BY 004 USERS
DASD 19D LINKED R/O; R/W BY MAINT; R/O BY 002 USERS
DASD 19E LINKED R/O; R/W BY MAINT; R/O BY 004 USERS
DASD 5E5 LINKED R/O; R/W BY MAINT
LOGON AT 19:02:11 GMT TUESDAY 06/07/22
VM Community Edition V1 R1.1
?
Y (19E) R/O
U (19D) R/O
B (5E5) R/O
E (194) R/O
T (196) R/O
R (193) R/O
Ready; T=0.01/0.01 19:02:13
forth
'FORTH $PROG$ A'? File does NOT exist
FORTH ready
?
:HELLO
>
.' Hello
>
;
?
hello
DMSITP141T PROTECTION EXCEPTION OCCURRED AT 0205F6 IN ROUTINE FORTH.
CMS

?... Mark S.

On Mon, Jun 6, 2022 at 11:41 PM, René Ferland wrote:

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):

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

L XMAS
ENTER PASSWORD:
?
DASD 190 LINKED R/O; R/W BY MAINT; R/O BY 004 USERS
DASD 19D LINKED R/O; R/W BY MAINT; R/O BY 002 USERS
DASD 19E LINKED R/O; R/W BY MAINT; R/O BY 004 USERS
DASD 5E5 LINKED R/O; R/W BY MAINT
LOGON AT 18:46:11 GMT TUESDAY 06/07/22
VM Community Edition V1 R1.1
?
Y (19E) R/O
U (19D) R/O
B (5E5) R/O
E (194) R/O
T (196) R/O
R (193) R/O
Ready; T=0.01/0.01 18:46:13
forth
'FORTH $PROG$ A'? File does NOT exist
FORTH ready
?
: HELLO
:???????? program PREVIOUSLY defined
HELLO???? Invalid NUMERIC field
?
: HI
:???????? program PREVIOUSLY defined
HI??????? Invalid NUMERIC field
?
end
Do you want to save your extensions (Y/N)?
Y
Your FORTH extensions saved
Ready; T=0.01/0.01 18:47:17
type forth $prog$ a
?
$
?
Ready; T=0.01/0.01 18:47:26

On Mon, Jun 6, 2022 at 06:26 PM, Mark A. Stevens wrote:

Any ideas?

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):

--

I am by no means a Forth expert, but from what little I do know this should work. I am running this on VM/370 CE V1R1.1

Written new file: FORTH $PROG$ A1
Ready; T=0.08/0.10 19:23:10
type forth $prog$ a
?
: HELLO? ( -- )? CR ." Hello, World!" ;
?
Ready; T=0.01/0.01 19:23:21
forth
Your FORTH extensions loaded
FORTH ready
?
HELLO
HELLO???? Invalid NUMERIC field
?
CR .( Hello, World!)
CR??????? Invalid NUMERIC field
?
end
Do you want to save your extensions (Y/N)?
n
Ready; T=0.01/0.01 19:23:44

Any ideas?

?... Mark S.

Mark A. Stevens wrote:

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?

Maybe it's because your proposal:

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

Does not match the very C definition (syntax) that you quoted? In 'C', the function 'fopen' is passed only TWO parameters, BOTH being string parameters, whereas in your proposed syntax, the function is being passed FIVE parameters, each of the second through fifth parameters are of an unknown/undefined type. Perhaps you meant to enclose them with double quotes like Dave proposed?

I myself haven't been following this thread too closely and I have zero interest in Paul's hacks, but I would listen to Dave Wade. He knows what he's talking about/doing.

Me? I would vote for Dave's original proposed syntax, but with blanks instead of commas as the separators in the second string parameter:

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

<shrug>

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

开云体育

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);?

The fopen with the recfm=v (hopefully you have a v defined with a value)

The as defined variables recfm,? lrecl, blksize would all be assigned the values shown.

Unless the assignment of values to those variables serve some purpose, they will have no impact on the call to fopen, the values will be passed.

The w requires a value such as "w" which is conventional.

this is submitted as FWIW.? The assignments in the parameters work, but I don't usually do that as one can miss them or otherwise when reading code.? Worse believe them if someone codes them wrong.? The variables have no impact at all in the routine called as they aren't passed.

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.

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.

Jay,

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?

?... Mark S.

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.

开云体育

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