¿ªÔÆÌåÓý


Re: Two New Projects

 

Awesome - will give them a spin!

Adrian


Two New Projects

 

There are two new applications available on Github for VM370 cms:

CMSBASIC - This is a port of bxbasic from linux, to run under VM370.? I can found at:
????? github.com/tchandler48/cmsbasic

CMSPILOT - A port of the PILOT language from LInux to run via VM370 cms.? It is at
???? github.com/tchandler48/cmspilot

I have tested both, but sure there are some hidden issues.? Questions/comments
are welcome.

Cheers
Tom c.


Re: gcc fopen question

 

Mark,

That functionality does not ?exist in VM/370s filesystem. Remember, it is NOT the shared filesystem, but rather the predecessor ?(800-byte block, IIRC) CMS filesystem.

Joe

On Wed, Jan 13, 2021 at 4:44 PM Mark Waterbury <mark.s.waterbury@...> wrote:
Adrian,

I am not trying to pick on you ...

See:
??

and page down to the section on OPENTYP= where it says:



OPENTYP=
is the type of open to be performed on the file. Acceptable values are:
READ
indicates that the file exists and will only be read.
WRITE
indicates that the file may be written to or read from. All changed and added records are written. Other records remain unchanged. If the file does not exist, it is created.
NEW
indicates that the file does not exist and is then created. It may then be written to or read from. If the file already exists, it is an error and the file is not opened.
REPLACE
indicates that the file is replaced with only the subsequently written records. If the file does not exist, it is created.
NONE
indicates that the file is not actually opened. The file is implicitly opened when the first FSREAD, FSWRITE, or FSPOINT is issued to the file. Use of FSOPEN with OPENTYP=NONE is essentially equivalent to an FSSTATE, and differs from an FSSTATE in that it may be used to create an FSCB for the file. The CACHE parameter is ignored if OPENTYPE=NONE.
You can specify OPENTYP=WRITE or OPENTYP=NONE.? Then just issue FSREADs mixed with FSWRITEs.

Hope that helps,

Mark


Re: gcc fopen question

 

Mark - Don't worry about picking on me - I am only a CMS Level 1 Hobbit, and do need guidance!

But I think (and hope) Dave is right - in VM/370, from reading old old manuals, my understanding was that you had to reopen files to move from write to read and back. If not I kind of wasted some time coding this in GCCLIB!

Tom - please note that you are user #2 - I did create rather extensive automation tests for the IO part however issues will be there for sure. Also documentation is sparse :-(? However it is actively supported, so just raise issues on GITHUB. Projects sound interesting ...

Cheers

Adrian


Re: gcc fopen question

 

¿ªÔÆÌåÓý

Thats a shed load newer than the VM/370 we have¡­

?

Dave

G4UGM

?

From: [email protected] <[email protected]> On Behalf Of Mark Waterbury
Sent: 13 January 2021 22:44
To: [email protected]
Subject: Re: [h390-vm] gcc fopen question

?

Adrian,

I am not trying to pick on you ...

See:
??

and page down to the section on OPENTYP= where it says:


OPENTYP=

is the type of open to be performed on the file. Acceptable values are:

READ

indicates that the file exists and will only be read.

WRITE

indicates that the file may be written to or read from. All changed and added records are written. Other records remain unchanged. If the file does not exist, it is created.

NEW

indicates that the file does not exist and is then created. It may then be written to or read from. If the file already exists, it is an error and the file is not opened.

REPLACE

indicates that the file is replaced with only the subsequently written records. If the file does not exist, it is created.

NONE

indicates that the file is not actually opened. The file is implicitly opened when the first FSREAD, FSWRITE, or FSPOINT is issued to the file. Use of FSOPEN with OPENTYP=NONE is essentially equivalent to an FSSTATE, and differs from an FSSTATE in that it may be used to create an FSCB for the file. The CACHE parameter is ignored if OPENTYPE=NONE.

You can specify OPENTYP=WRITE or OPENTYP=NONE.? Then just issue FSREADs mixed with FSWRITEs.

Hope that helps,

Mark


Re: gcc fopen question

 

Adrian,

I am not trying to pick on you ...

See:
??

and page down to the section on OPENTYP= where it says:



OPENTYP=
is the type of open to be performed on the file. Acceptable values are:
READ
indicates that the file exists and will only be read.
WRITE
indicates that the file may be written to or read from. All changed and added records are written. Other records remain unchanged. If the file does not exist, it is created.
NEW
indicates that the file does not exist and is then created. It may then be written to or read from. If the file already exists, it is an error and the file is not opened.
REPLACE
indicates that the file is replaced with only the subsequently written records. If the file does not exist, it is created.
NONE
indicates that the file is not actually opened. The file is implicitly opened when the first FSREAD, FSWRITE, or FSPOINT is issued to the file. Use of FSOPEN with OPENTYP=NONE is essentially equivalent to an FSSTATE, and differs from an FSSTATE in that it may be used to create an FSCB for the file. The CACHE parameter is ignored if OPENTYPE=NONE.
You can specify OPENTYP=WRITE or OPENTYP=NONE.? Then just issue FSREADs mixed with FSWRITEs.

Hope that helps,

Mark


Re: gcc fopen question

 

Thank you for the response.? I will download and hopefully update with the "new" GCCLIB.

I have two projects that I am working on that need this type of access:

Conversion of the MUMPS programming interpreter to VM370 CMS.? It compiles and
links, but does not execute properly, yet......
and? conversion of the package apl_11 from linux gcc to VM370 CMS.? OF the 22
modules, 20 are compiling great, two still have compile time errors.? working on
them.

It is another step in the process and again, thank you.

Cheers
Tom c


On Wed, Jan 13, 2021 at 1:31 PM adriansutherland67 <adrian@...> wrote:
Hi Tom

The version of GCCLIB on Six Pack 6 Beta 3 does not support read/right files because CMS does not support r/w files.

The updated version of GCCLIB has re-implemented the IO functions (done by myself). This supports r+ modes etc. via emulation (it reopens the file as needed).

Hope this helps

Adrian


Re: gcc fopen question

 

Ah ... I mean CMS does not support opening a file for reading and writing

Cheers

Adrian


Re: gcc fopen question

 

What do you mean by "CMS does not support r/w files"??

Where did you get that information?

I wrote code circa 1981 that allowed for safely updating a large file on a CMS minidisk that could be shared "read-only" by multiple users, and simultaneously accessed in write-mode by using the "multi-write" feature of CP, by one "writer" (at a time), and eventually we got it all working just fine.


Re: gcc fopen question

 

Hi Tom

The version of GCCLIB on Six Pack 6 Beta 3 does not support read/right files because CMS does not support r/w files.

The updated version of GCCLIB has re-implemented the IO functions (done by myself). This supports r+ modes etc. via emulation (it reopens the file as needed).

Hope this helps

Adrian


gcc fopen question

 

I am trying to open a file using fopen:
fopen("tmp.dat","r+")

I need to open it for read & write.? However the compiler
complains with an error stating invalid option? "r+".
Can you on vm370 gcc open a file for both read and write?

Thank You
Tom c


Re: gcc vm370 lseek

 

On Mon, Jan 11, 2021 at 07:12 PM, Dave Wade wrote:
The C90 equivalent is fseek() but its very inefficient on CMS.

The updated version of GCCLIB implements IO differently. For fixed record length files it supports random access (but only using C90 functions, not POSIX).

https://github.com/adesutherland/CMS-370-GCCLIB


Re: gcc vm370 lseek

 

On Mon, 2021-01-11 at 12:43 -0800, carlos feldman wrote:
That's why I like PL/I , the language includes I/O. C, sometimes can
be very limitative, since lot of functions are not implemented the
same way, And you have to write your own implementation. for instance
atoi(), something basic if you are wirking with user interfases. In
PL/I you write number=string; and you only get a compiler warning
I do a lot of embedded work and *not* having/needing a full C runtime
allows for writing the applications/OS/RTOS in an efficient manner.

In many cases I compile my C code with --no-stdlib and the like because
I don't need/want a lot of the C run-time. For example, in one case I
hand wrote a 64-bit divide by 1000 function because that was the only
use of the entire 64-bit math library on a 32-bit CPU. It saved almost
1KB of code (and was significantly faster as well). You might say a
1KB savings isn't alot but what I was doing, I only had 128KB for the
entire application and RTOS.

TTFN - Guy


Re: gcc vm370 lseek

 

That's why I like PL/I , the language includes I/O. C, sometimes can be very limitative, since lot of functions are not implemented the same way, And you have to write your own implementation. for instance atoi(), something basic if you are wirking with user interfases. In PL/I you write number=string; and you only get a compiler warning
--
Carlos

Argentina


Re: gcc vm370 lseek

 

Folks,

GCC only supports the "C90" standard library. lseek() is a UNIX specific interface and is not part of the "C90" standard.
The C90 equivalent is fseek() but its very inefficient on CMS. The problem is, in generally you don't know how much space is taken by BDW and RDW.
So you end up just reading the appropriate number of bytes.
Avoid.

Dave

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
ggs@...
Sent: 11 January 2021 18:45
To: [email protected]
Subject: Re: [h390-vm] gcc vm370 lseek

On Mon, 2021-01-11 at 09:36 -0800, Tom Chandler wrote:
I am working on some "C" code, and it appears that the gcc compiler
does not support the lseek function. Did I misread it or is there
another option.
Just being a bit pedantic, but there is nothing in the C language that specifies
any of the stdio functions (such as lseek and such). Those are part of the
standard "C" libraries and those are distinct from the compiler itself.

Typically to get lseek and friends you need to include the appropriate header
files (unistd.h on my Linux system).

So, what error are you seeing? Is there a small snippet of code that
demonstrates the problem?

TTFN - Guy







Re: gcc vm370 lseek

 

On Mon, 2021-01-11 at 09:36 -0800, Tom Chandler wrote:
I am working on some "C" code, and it appears that the gcc compiler
does not support the lseek function. Did I misread it or is there
another option.
Just being a bit pedantic, but there is nothing in the C language that
specifies any of the stdio functions (such as lseek and such). Those
are part of the standard "C" libraries and those are distinct from the
compiler itself.

Typically to get lseek and friends you need to include the appropriate
header files (unistd.h on my Linux system).

So, what error are you seeing? Is there a small snippet of code that
demonstrates the problem?

TTFN - Guy


gcc vm370 lseek

 

I am working on some "C" code, and it appears that the gcc compiler
does not support the lseek function.? Did I misread it or is there
another option.

Any advice would be appreciated.

Thank You
Tom c


Re: Question about LOGOFF in an exec.

 

On Thu, 07 Jan 2021 21:09:21 -0800, Ren¨¦ Ferland
<ferland.rene@...> wrote:


On Thu, Jan 7, 2021 at 08:41 PM, Fernando M. Roxo da Motta wrote:


Is it possible to logoff a session from an exec?
Yes, but logoff is a CP command, so you need to type

CP LOGOFF

in your EXEC, not just

LOGOFF
Thanks Ren¨¦, that was perfect.


All the best.


Rene FERLAND, Montreal










Roxo

--
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <mvs@...> | Editor?
Except where explicitly stated I speak on my own behalf.| VI !!
PU5RXO | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!


Re: Question about LOGOFF in an exec.

 

On Thu, Jan 7, 2021 at 08:41 PM, Fernando M. Roxo da Motta wrote:
Is it possible to logoff a session from an exec?
Yes, but logoff is a CP command, so you need to type

CP LOGOFF

in your EXEC, not just

LOGOFF

Rene FERLAND, Montreal


Question about LOGOFF in an exec.

 

Hi all,

I am toying with execs in 6 Pack 1.3 and was testing to issue a
LOGOFF in an exec. Like:

EMIT ------------------------------------------------------------
EMIT LOGGING OFF NOW
EMIT ------------------------------------------------------------
EMIT
LOGOFF

The exec lists the message in terminal but the LOGOFF command did not
logs the user (CMSUSER) off and do not issue nay error.

Is it possible to logoff a session from an exec?



Roxo

--
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <mvs@...> | Editor?
Except where explicitly stated I speak on my own behalf.| VI !!
PU5RXO | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!