Corrupting MODULE files, DMSITP141T

[btiffin]

Trying to track down a DMSITP141T problem.

I have a few C toyols (toy tools), mostly useless except for the challenge of
it.

One, cbrain (and esoteric programming language) is the focus today, but I can
reproduce a similar problem with this smaller C program.

This is using GCCLIB and GCCCMS from VMCE V1R1M0.

Something triggers badness, that can cause permanent problems with the MODULE.

First the smaller program and sample run. The problems depends on which CMS
routine is called.

/* Call CMS */

#include <stdio.h>
/* #include <cmssys.h> */

int main(int argc, char *argv[]) {
    int rc;

    rc = __cmscmd("LISTFILE PROFILE EXEC *", 1 /*CMS_COMMAND*/);
    fprintf(stderr, "Got: %d\n", rc);
    if (argc > 1) {
        fprintf(stderr, "Trying: '%s'\n", argv[1]);
        rc = __cmscmd(argv[1], 11 /*CMS_CONSOLE*/);
        fprintf(stderr, "Got: %d\n", rc);
    }
    return rc;
}

This is a simple program, only takes a single argument, for demonstration.

gcc callcms (cms
Ready; T=0.49/0.77 16:19:55
load callcms
Ready; T=0.02/0.05 16:20:01
genmod callcms
Ready; T=0.01/0.01 16:20:05
q txtlib
TXTLIB   = GCCLIB   CMSLIB   PLILIB   FORTLIB  TSOLIB
Ready; T=0.01/0.01 16:20:12

And a run. The first call to CMS is LISTFILE PROFILE EXEC, works fine,
multiple times in a row. But other commands are triggering DMSITP141T. I'll
use DIR (and remove some of the output).

callcms dir
PROFILE  EXEC     A1
Got: 0
Trying: 'dir'
Filename Filetype Fm  Format    Recs Blocks    Date     Time   Label
CALLCMS  C        A1  V    64     17      1  04/12/21   13:24  CMS191
CBRAIN   C        A1  V   138    241     13  04/14/21    3:48  CMS191
...
TRIALS   TEXT     A1  F    80      9      1  04/10/21   12:08  CMS191
FIRST    WORK     A1  F    80      2      1  03/23/21    9:23  CMS191
44 files, 3,786 blocks: 3,028,800 bytes.
DMSITP141T OPERATION EXCEPTION OCCURRED AT 980002 IN ROUTINE CALLCMS.
CMS

So that's a minimal example. What's next is more in depth C, but actually
worse in outcome. A genmod module becomes corrupt and stays ccorrupt.

gcc cbrain (cms
Ready; T=13.16/16.68 16:25:56
load cbrain
Ready; T=0.02/0.08 16:25:57
genmod cbrain
Ready; T=0.01/0.02 16:26:01
cbrain pbhello
Hello cbrain niarbc olleH
q
Ready; T=0.01/0.02 16:26:11
cbrain pbhello
Hello cbrain niarbc olleH
q
Ready; T=0.01/0.02 16:26:21

Now, after some programs, in particular MECAFF routines, but there are others.

EE cbrain helpcmd

Immediately causes the CBRAIN MODULE to trip, every time. Across logins,
across shutdown and restart...

Ready; T=0.03/0.06 16:29:43
cbrain pbhello

DMSITP141T OPERATION EXCEPTION OCCURRED AT 020002 IN ROUTINE CBRAIN.
CMS

Need to reload and run another genmod to get back to a usuable MODULE.
Note: no recompile, just a load and genmod.

load cbrain
Ready; T=0.02/0.10 16:30:49
genmod cbrain
Ready; T=0.01/0.02 16:30:53
cbrain pbhello
Hello cbrain niarbc olleH

First, not sure what is causing the DMSITP141T, and worse I'm unclear how
running program can corrupt a different MODULE file on disk.

[BobBolch]

I ran the test case with CALLCMS calling DIR.

The CALLCMS MODULE and the DIR MODULE are both CMS User Area MODULE files and both LOAD at address X'20000'.
CMS content management is minimal. User programs usually load either in the transient area, art address X'E000', or in the user area at address X'20000'. When CALLCMS calls DIR, DIR overlays the CALLCMS MODULE in storage, so when DIR completes, the
CALLCMS program is no longer there, so you get a program check.

What to do: CMS MODULE files are not relocatable, but you can specify an address where they will be loaded.

GLOBAL TXTLIB GCCRES <--- we recommend using the native C runtime library, not GCCLIB
LOAD CALLCMS ( CLEAR ORIGIN 80000
GENMOD CALLCMS MODULE A2

The load address, X'80000' is just a guess of an address that will be higher than the largest MODULE file it will call that loads at X'20000'.

Please let me know if this is not clear. I am guessing that the other programs in your tests are seeing the same issue, but if not I can test them if I have an executable.

Bob Bolch

[btiffin]

Awesome, Bob. Thanks. Development is a lot more fun now.

If you don't mind spending the time, I'll be hosting some of these trials at http://btiffin.users.sourceforge.net/vmce/ In that dir is http://btiffin.users.sourceforge.net/vmce/cbrain.c (I transfer this as V with LRECL 140), and a small test script http://btiffin.users.sourceforge.net/vmce/pbhello.cb V 80. and computus.cb, to show when Easter Sunday is for a given year.

I'll correct the tectonics to move the ORIGIN, but for now, this is the MODULE being whacked (as you explained), but this MODULE stays whacked across login/logout and even across shutdown and restart.

gcc cbrain (cms
load cbrain
genmod cbrain
cbrain pbhelllo

... works fine, but once another module get executed cbrain MODULE always triggers the DMSITP141T. *This example was from ORIGIN A0000, and running FSLIST in between runs.

L CMSUSER CMSUSER
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
LOGON AT 15:05:17 GMT FRIDAY 04/16/21
CMS Community Edition V1 R1.0

Y (19E) R/O
U (19D) R/O
'19D' REPLACES ' U (19D) '
U (19D) R/O
Ready; T=0.01/0.01 15:05:19
cbrain pbhello

DMSITP141T OPERATION EXCEPTION OCCURRED AT 0A0002 IN ROUTINE CBRAIN.
CMS
load cbrain (clear origin a0000
Ready; T=0.01/0.10 15:06:12
genmod cbrain
Ready; T=0.01/0.01 15:06:21

Stays trashed across the login.

Much appreciate the help, Bob. And you can probably close this ticket as "problem is between chair and keyboard".

[BobBolch]

I still plan to look into the cbrain part of the issue. I don't have any explanation for the behavior you are seeing, so I will get the source and do some experiments.

In later versions of VM, IBM introduced the Nucleus Extension architecture to allow user programs to be loaded in high memory. The IBM NUCXLOAD command had the capability to load and relocate a CMS MODULE file to high memory and let it be called in the normal CMS way by entering the MODULE filename as a command name. VM/370 does not have NUCXLOAD, because it does not have support in the program loader to relocate a MODULE to a separate address from where it was generated. However, CMS TEXT files CAN be relocated. VMCE V1 R1.1 will add a new command NUCXTEXT, which loads TEXT files in high memory so they can be accessed as Nucleus extensions. It might be possible to use your 'callcms' program effectively, using NUCXTEXT.
Bob

[BobBolch]

Hi Brian, Just a quick status update. I can duplicate your symptoms here with cbrain. I am getting a series of very weird storage overlays, but the MODULE file itself is not being modified. Maybe it is a C library problem? I will let you know what I find. Bob

…

On Fri, Apr 16, 2021 at 3:11 PM Brian Tiffin ***@***.***> wrote: Awesome, Bob. Thanks. Development is a lot more fun now. If you don't mind spending the time, I'll be hosting some of these trials at http://btiffin.users.sourceforge.net/vmce/ In that dir is http://btiffin.users.sourceforge.net/vmce/cbrain.c (I transfer this as V with LRECL 140), and a small test script http://btiffin.users.sourceforge.net/vmce/pbhello.cb V 80. and computus.cb, to show when Easter Sunday is for a given year. I'll correct the tectonics to move the ORIGIN, but for now, this is the MODULE being whacked (as you explained), but this MODULE stays whacked across login/logout and even across shutdown and restart. gcc cbrain (cms load cbrain genmod cbrain cbrain pbhelllo ... works fine, but once another module get executed cbrain MODULE always triggers the DMSITP141T. *This example was from ORIGIN A0000, and running FSLIST in between runs. L CMSUSER CMSUSER 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 LOGON AT 15:05:17 GMT FRIDAY 04/16/21 CMS Community Edition V1 R1.0 Y (19E) R/O U (19D) R/O '19D' REPLACES ' U (19D) ' U (19D) R/O Ready; T=0.01/0.01 15:05:19 cbrain pbhello DMSITP141T OPERATION EXCEPTION OCCURRED AT 0A0002 IN ROUTINE CBRAIN. CMS load cbrain (clear origin a0000 Ready; T=0.01/0.10 15:06:12 genmod cbrain Ready; T=0.01/0.01 15:06:21 Stays trashed across the login. Much appreciate the help, Bob. And you can probably close this ticket as "problem is between chair and keyboard". — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBMYC4V54FIJOQU66CTTJCDVPANCNFSM43AG4KHQ> .

[BobBolch]

I tracked down the situation with cbrain.

It turns out that the cbrain module is not being corrupted. It is not being built like we think, because
of the defined behavior of the GENMOD command. This is what we see immediately after issuing the GENMOD CBRAIN
command (usinf the default load address of X'20000'):

st 20000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
STORE COMPLETE
Ready; T=0.01/0.01 08:50:20
loadmod cbrain
Ready; T=0.01/0.01 08:50:26
d t20000.100
020000 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF E0 ................
020010 TO 020020 SUPPRESSED LINE(S) SAME AS ABOVE .....
020020 000818DF 5AF0C02C 50FD004C 50ED0048 .....0..&..<&...
020030 47F0C030 00000000 00000058 05C018B1 .0..............
020040 58A0C032 5820C036 58220000 D2032060 ............K..-

The code loaded at X'20000' by the LOAD command is NOT INCLUDED in the MODULE file.
Here is why. This is the sotorage layout after the LOAD command:

.000006 SD 020000
LONG@TO@ 020000
E 020264
CALLCMS 020508
CBHELP 020754
CBRAIN 0209F8
@@main 022310
MAIN 02231C
A 0224DC
MEMREG 02A4DC
S 02A4E0

Here is the definition of the START option of the GENMOD command:
FROM entry1
specifies an entry point or a control section name that represents the
starting virtual storage location from which a MODULE is generated.

If omitted, then the so-called "default load point" is whatever you specified on the LOAD command, with a defult of
the start of the User Area at address X'20000'. However, if you have an entry point in your loaded TEXT, that matches the module name, then that is taken to be the FROM address. The MODULE file then starts at address 209F8 where the CBRAIN symbol is defined.

To build the MODULE you want, supply a FROM operand on your GENMOD. In this case, LONG@TO@ starts at 20000, so that is what you want. Entering the command is complicated by the fact that @ is the default CHARDEL (character delete) editting character:

TERM CHARDEL OFF
LOAD CBRAIN ( CLEAR ORIGIN 20000 or whatever
GENMOD CBRAIN ( FROM LONG@TO@
TERM CHARDEL @

Make sense?

[btiffin]

Yes, yes it does (fibbing for now kinda, I trust your analysis but don't have the whole picture in my head yet). ;-)

Thanks for the education lesson. This is base learnin' that still needs learnin'. These little hints are wondrous.

I've been keeping CP SET LINEDIT OFF and TERMINAL ESCAPE OFF in a profile exec when testing these engines.

Feel free to close this report. Initial trials working. Will keep on reading more docs.

Thanks a lot, Bob. This bodes well for setting up an attempt at getting some tools from busybox or Landley's toybox running under CMS, and will definitely help with polishing libforth.

[BobBolch]

Issue resolved