HI Tom, I'm not a C guy but I have done some BASIC stuff in the old days.听 I
followed the directions but I'm getting a DMSACC113S 'T (19F) ' NOT ATTACHED
followed by a DISK 'T' NOT ACCESSED.听 I'm logged into the GCCCMS machine and
these messages occurs when I key *gcc cmsbasic c*.听 I then went ahead with
the directions and *cmsbasic bx10 bas* seems to go into a loop because it
processed well over 4-5 minutes before I re-IPLed CMS.
I then uploaded TBASIC.EXEC and ran it.
tbasic
FILE 'GCCLIB_S TXTLIB' NOT FOUND.
.. ERASE CMSBASIC MAP
.. Compling CMSBASIC
DMSACC113S 'T (19F) ' NOT ATTACHED
DISK 'T' NOT ACCESSED.
.. LOAD CMSBASIC
THE FOLLOWING NAMES ARE UNDEFINED:
STRLEN听 听ISALPHA听 STRCPY听 听STRCMP听 听MALLOC听 听REALLOC听 STRCHR听 听ISDIGIT
FREE听 听 听PRINTF听 听@@EXIT听 听FCLOSE听 听ISUPPER听 FOPEN听 听 FEOF听 听 听FGETC
ATOF听 听 听ATOL听 听 听ATOI听 听 听FGETS听 听 FPRINTF听 SPRINTF听 ISALNUM听 STRCAT
MEMSET听 听FSEEK听 听 FPUTS听 听 REMOVE听 听GETS听 听 听POW听 听 听 ABS听 听 听 ATAN
COS听 听 听 SIN听 听 听 TAN听 听 听 SQRT听 听 听SINH听 听 听TANH听 听 听TOUPPER听 TOLOWER
TIME听 听 听CTIME听 听 ISSPACE听 @@CRT0
.. GENMOD CMSBASIC
.. RENAME MAP
Ready; T=28.69/41.11 20:11:54
What am I doing wrong?
Also, I noticed each C file and BAS file contained a USERID GCCCMS
statement.听 Check out Moshix video M101 on Youtube to get data in/out of
燰M/370 and the Mac/PC.

听

听

I remember a VMFCLEAR module and another VMFCLR module. I do not remember what level of VM or if they were transient modules. Neither one would have been too large to get the text and load/genmod as transient.

/Tom

Thank you.听 I will investigate and see what I can do.

听

Again, Thank You

听

Tom c

听

听

On Sat, Jan 23, 2021 at 4:47 PM Dave Wade <dave.g4ugm@...> wrote:

Tom,

You need to use a DIAG 58 听call. There are no character sequences that clear the screen. I think the simplest solution is to create a 鈥渃lrscrn鈥� module that loads in the transient area and run that with the system command.

Dvae

听

From: [email protected] <[email protected]> On Behalf Of Tom Chandler
Sent: 23 January 2021 20:31
To: [email protected]
Subject: [h390-vm] GCC under VM370 CMS

听

I am trying to figure out to perform a clear screen form a "GCC C" program.听 I am using
the wc3270 program on WIndows to talk to Hercules VM370.听 I have tried several
different hex codes with no luck.听 Has anyone using "GCC C VM370 CMS" sent a command to
clear the screen.

Hope this is clear.

Thank You
Tom c

Thank you.听 I will investigate and see what I can do.

Again, Thank You

Tom c

On Sat, Jan 23, 2021 at 4:47 PM Dave Wade <dave.g4ugm@...> wrote:

Tom,

You need to use a DIAG 58 听call. There are no character sequences that clear the screen. I think the simplest solution is to create a 鈥渃lrscrn鈥� module that loads in the transient area and run that with the system command.

Dvae

听

From: [email protected] <[email protected]> On Behalf Of Tom Chandler
Sent: 23 January 2021 20:31
To: [email protected]
Subject: [h390-vm] GCC under VM370 CMS

听

I am trying to figure out to perform a clear screen form a "GCC C" program.听 I am using
the wc3270 program on WIndows to talk to Hercules VM370.听 I have tried several
different hex codes with no luck.听 Has anyone using "GCC C VM370 CMS" sent a command to
clear the screen.

Hope this is clear.

Thank You
Tom c

听

I am trying to figure out to perform a clear screen form a "GCC C" program.听 I am using
the wc3270 program on WIndows to talk to Hercules VM370.听 I have tried several
different hex codes with no luck.听 Has anyone using "GCC C VM370 CMS" sent a command to
clear the screen.

Hope this is clear.

Thank You
Tom c

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Martin Taylor
via groups.io
Sent: Saturday, January 16, 2021 11:07 AM
To: [email protected]
Subject: Re: [h390-vm] add new dasd to vm/370 sixpack

Hello,
I have had the same issue when adding DASD to a VM370 system at the 1.3 level.
Prior to this a simple create of the DASD and adding it to the machine config file
with a suitable device address (that matches the DASD type) was all that was
required. I had added new DASD to a 1.2 system many time with no issue. A
VARY all devices in AUTOLOG1 brought the DASD online. However moving my
system to 1.3 caused all the DASD I had added to become inaccessible with
message DMKLNK108E NOT LINKED NOT MOUNTED being issued when logging
on to an affected user.

The cause of the above problem is that in VM/370 1.3 a fix is implemented that
meant that the SYSUSR parameter, in DMKSYS, had to be used to have the new
DASD accessible. This means that a CP regen is required. As with the 1.2 system
once the new DASD is online it can be used to allocate mini disks space (just do
not use the first cylinder), or any other use.

Below is an explanation of what that fix was and it鈥檚 implications.

鈥斺赌斺赌斺赌斺赌斺赌斺赌斺�斺赌斺赌斺赌斺赌斺赌斺赌斺�斺�斺�斺�� Start of insert鈥斺赌斺赌斺赌斺赌斺赌斺赌斺�斺�斺�斺�斺��
鈥斺赌斺赌斺赌斺赌斺赌�-
I traced the cause of the DMKLNK108E message down to an flag setting in the
RBLOK field RDEVFLAG. When set to RDEVMOUT its considered not to be
ATTACHED/MOUNTED hence the message.

Further digging showed that adding my DASD to the SYSUSR macro and
regenning CP allowed my userid to logon correctly.

Given the above I did some more searching and found fixes that dealt with these
fields/values. This revealed fix HRC039DK which is not on the 1.2 VM/370 system
but is on the 1.3. This fix is attempted to add clarity and consistency to device
status as explained in HRC039DK MEMO.

So I would say its a pretty safe bet that the behaviour I had seen is not so must
of a bug but a correction to wooly handling of device status in the past. It does
mean that when using VM/370 beta 1.3 the use of the SYSUSR parameter in
DMKSYS is mandated, which I think is the purpose of HRC039DK. Users of the 1.3
beta who just move their directory entries over, as has worked in the past, and
expect the system to run the same as previous versions.

鈥斺赌斺赌斺赌斺赌斺赌斺赌斺�斺赌斺赌斺赌斺赌斺赌斺赌斺�斺�斺�攅nd of insert 鈥斺赌斺赌斺赌斺赌斺赌斺赌斺�斺�斺�斺�斺�斺��
鈥斺赌斺赌斺赌斺赌斺赌斺赌�

Hope this is of use, at least it documents this behaviour for those moving to 1.3
and above from 1.2 systems.

Regards,
Martin.