search

MVS-sysgen / sysgen

Jay Moseley MVS 3.8j sysgen automation
71 stars 19 forks source link

No default Rexx execution path for new users... #39

Closed gmgauthier closed 1 year ago

gmgauthier commented 1 year ago

In the Winkelman TK4-, rx will automatically find clists in username.cmdproc PDS or rexx execs username.exec PDS, for users added after-the-fact. In this sysgen, only SYS1 enjoys this privilege. Screenshot from 2023-03-17 21-41-29

Here is how it works in TK4:

Screenshot from 2023-03-18 09-16-38

mainframed commented 1 year ago

I'm not sure why you're getting that issue for rexx scripts, I just provisioned a user NEWUSER, created NEWUSER.EXEC and added the member HELLO1, then logged off and relogged on as that user and it works fine:

image

As for clists we don't allocate userid.cmdproc, we allocate userid.CLIST you can see the allocations in SYS1.CMDPROC(TSOLOGON)

image

mainframed commented 1 year ago

Is this something you need or just looking for feature parity with TK4-? I will, however, look at adding username.EXEC to the TSONUSER procedure.

Personally I think CLISTs being in username.CLIST and executable from there makes far more sense than CMDPROC, CMDLIB is for compiled/assembled/linked executable, not scripts.

gmgauthier commented 1 year ago

Is this something you need or just looking for feature parity with TK4-? I will, however, look at adding username.EXEC to the TSONUSER procedure.

Personally I think CLISTs being in username.CLIST and executable from there makes far more sense than CMDPROC, CMDLIB is for compiled/assembled/linked executable, not scripts.

To be honest, I was using TK4 as a sort of "reference" system. So, "feature parity" in some sense is probably a good way to put it. Perhaps its not fair to do the comparison, but I don't really have any other point of reference for some things, to say "this should be a bug ticket".

I agree with you about the naming of the CLIST library, however. The more like what it is, the better, just for the reduction in cognitive load! :D

As for the actual problem, let me see if I can reproduce it with a fresh sysgen tonight. If I cannot, I'll just close this -- and apologies for the churn.

gmgauthier commented 1 year ago

I'm still seeing the same issue.

One thing that occurred to me, is that the user is created DURING the sysgen. I'll add a fresh user now, to see if that makes a difference... Screenshot from 2023-03-19 00-28-15

mainframed commented 1 year ago

I think I've fixed this. I think the issue was with the dataset not being cataloged. I've just pushed a change that aims to fix this. I'll do a test built tomorrow to see.

gmgauthier commented 1 year ago

I think I've fixed this. I think the issue was with the dataset not being cataloged. I've just pushed a change that aims to fix this. I'll do a test built tomorrow to see.

Didn't quite work. The dataset is definitely there, but something went sideways with the cataloguing....

dataset-not-on-volume

Screenshot from 2023-03-19 13-22-13

Screenshot from 2023-03-19 13-21-43

mainframed commented 1 year ago

Ok, i'm rebuilding in my dev environment to figure out whats wrong with this.

mainframed commented 1 year ago

This is fixed with the latest commit https://github.com/MVS-sysgen/sysgen/commit/0b509b34dfa1adc95eca8bdb16397ea442a6f634