 XUSER.SYS packet allocation.
#37914
25 Mar 25 09:56 AM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
It would appear that an existing XUSER.SYS key entry can be ignored and another one created, although I believe in these cases the 'value' for the key does have content, albeit just a space.
So, to clarify, either for Ashell purposes, or just our applications, upon login any given TSKxxx session has 4 entries created in XUSER.SYS using the 'P' xcall XUSER call:
TSKxxxAXSS, TSKxxxUSER, TSKxxxPRNT and TSKxxxSUBM. Upon exiting the application, all the entries should be cleared/deleted, although they are not always.
I think all are cleared however, except SUBM which is left with a space character.
On re-use of the TSKxxx ID, the AXSS, USER and PRNT keys are re-used, but an additional SUBM entry is created.
Obviously, XUSER.SYS is a data file and access would usually be by record number, but XUSER only provides acces by key, so my question is how are the available 'slots' in XUSER.SYS allocated.
What does XUSER use to determine if it should use an existing entry or add another one?
Is it possible to force re-use of an existing one, perhaps by issuing a 'G'et call first?
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37918
25 Mar 25 10:26 AM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
This sounds potentially even more complicated than the working days problem! It sounds like a bug of some kind, but let me review the code and set up a test and get back to (probably tomorrow your time).
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37919
25 Mar 25 11:49 AM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
OK, here's the deal: the 'P'ut operation will use the first empty slot, or the matching slot (if it finds one prior to the first empty slot). So consider the following sequence, starting with an empty XUSER.SYS file ... - 'P'ut TSKxxxUSER (slot 1)
- 'P'ut TSKxxxSUBM (slot 2)
- 'R'ead TSKxxxUSER (read and clear slot 1)
- 'P'ut TSKxxxSUBM (will use empty slot 1)
The above sequence would result in two TSKxxxSUBM packets, one in slot 1 and another in slot 2. Currently, the only way to avoid that is to do a 'R'ead (destructive) prior to a 'P'ut (or at least prior to the first Put of a session.) I'm not sure if this was the explicitly intended behavior, or just a quirk arising from the logic being shared with several other custom routines (COMMON, DSKCOM, etc.) which all share the same basic concepts. If you want, I'd be happy to change it to do a complete scan for a matching packet before using the first available slot. Or perhaps it should sort the table after any deletion to move all the available slots to the end. But obviously that will require you to update. Let me know which you prefer. In the meantime I've asked Ty to add a clarifying note to the documentation.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37923
26 Mar 25 08:25 AM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
Thank you for the clarification and offer.
So far at least, this only appears to be an issue for a few of our G1 customers. I believe that we can work around this for those customers, until they migrate to G2, which all will be doing in due course.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37927
27 Mar 25 05:56 AM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
The work around may not be so straightforward. Ironically, the ability to clear prveious entries, may now be exacerbating the problem, due to how XUSER uses the slots.
I believe knowing above, we can cope with the duplicate TSKxxx entries.
However, we are also now seeing a greater number of duplicate TASxxx entries, that apparently are not so easy to deal with.
In trying to investigate this, it is unclear how the TAS and/or background Job IDs are created. I have started an Ashell process from the Linux command line and put it into the BG via the & option. Whilst the Ashell program is held in a loop and therefore active, I do not see it in the SYSTAT listing. If I leave the Ashell program in the FG at the Linux shell, then I can see the program in SYSTAT, but it has a TSK prefix. In both cases I can see the Ashell process/program in the Linux process list, but there is no visibility of the TAS/TSK process in this list (as I presume it is internal to Ashell). I believe that most, if not all , of these TAS jobs are coming via CRON based Linux shell scripts calling/running Ashell programs/cmd scripts. So, I guess akin to terminal processes, but not run from a terminal as such.
This leaves me with a few questions:
a) What governs if a TSK or TAS prefix is used?
b) Where are the Linux BG processes in Ashell terms?
c) It it possible to see all Ashell processes (with their internal Job IDs)?
d) Are there any existing functions that would allow me to programmatically identify active Ashell TAS processes, that I can compare with XUSER.SYS, in order to clear those that have already terminated?
Last edited by Stuart; 27 Mar 25 07:20 AM.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37931
27 Mar 25 12:21 PM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
The plot certainly thickens! This may be a contender for most complex forum question this year, and definitely worth an hour(s)-long time slot at the next Conference! You're might have to lead it though as I'm not yet sure I can explain what's happening. Theoretically, if you don't use the -j jobname command line switch to specify your own job name, A-Shell will assign the first available TSKxxx if it's a foreground process, or TASxxx if it's a background process. Either way, the job should show up in the SYSTAT. And, if you have TRACE=INOUT in the miame.ini (as I always recommend), the you should see one or more trace messages in the ashlog.log for the launch. However, in trying to reproduce your results, I'm finding that an attempt to launch a background session from the bash prompt using the & suffix doesn't seem to work as expected. For example, I created a CMD:JACK3.CMD that runs a simple test program JACK3.RUN which creates a small output file with the time and sits in a CPU-intensive loop for about 10 seconds before exiting. If I launch it as a normal foreground process... ... it runs as expected. If I redirect the output to a file so it runs silently...
$ ashell -n -e jack3 >jack3.out 2>1
... then it just hangs until I ^C out of it. Looking at the log, I can see that it's hung up trying to handshake with ATE...
27-Mar-25 13:26:14 [p8615-0]<:0> Invalid or no response to AG_HANDSHAKE: 0 (retrying
You wouldn't have that problem because you're not using ATE, but perhaps you're running into a similar problem. I can fix mine by redirecting stdin. I'm not sure exactly why that's an issue, but this works...
$ ashell -n -e jack3 </dev/null >jack3.out 2>1
[5] 16849
The job shows up in SYSTAT (as TASACU here)...
TASACU TASACU jackmc BACK9:150,501 RN JACK3 16849 5088K
TSKACQ TSKACQ jackmc BACK9:150,501 RN SYSTAT 2088 5141K
... and in the ashlog (I also have TRACE=EXEC turned on ...)
27-Mar-25 13:39:37 [tsk:16849-0]<:0> ----------------
27-Mar-25 13:39:37 [tsk:16849-0]<:0> A-Shell 7.0.1762.3 launched on tsk:16849 by jackmc
27-Mar-25 13:39:37 [tsk:16849-73]<:0> In: Nodes=49/88/75 [L], ip=127.0.0.1 0:0:0:0:0:0, (jackmc) inodes: si=0,sm=21
27-Mar-25 13:39:37 [tsk:16849-73]<:0> Exec(CMDLIN): jack3
27-Mar-25 13:39:37 [tsk:16849-73]<JACK3:0> Exec(CMDLIN): LOG JACK:
27-Mar-25 13:39:37 [tsk:16849-73]<LOG:2a26> Exec(CHAIN): /u2/miame/back9/150501/start.cmd
27-Mar-25 13:39:37 [tsk:16849-73]<START:2a26> Exec(CMDLIN): RUN JACK3
27-Mar-25 13:39:37 [tsk:16849-73]<RUN:bad> Exec(CHAIN): /u2/miame/back9/150501/jack3.run
27-Mar-25 13:39:47 [tsk:16849-73]<JACK3:8c> Out: Nodes Remaining = 48P/87L, 2 reads, 0 writes, 0 kbd bytes
As an aside, typically I launch background sessions via either the cron or at background task managers, both of which seem to take care of the stdin issue that was hanging me up above. For example, this works fine...
echo "ashell -n -e jack3 >jack3.out 2>&1" | at now
More typically, I'd have an entry in crontab like this...
45 0 * * * /vm/miame/bin/ashterm jack3 > /vm/logs/jack3.log
where the ashterm script looks something like this...
TERM=dumb
PATH=/vm/miame/bin:$PATH
export TERM PATH
ashell -n -e -i /vm/miame/miame.ini $1 $2 $3 $4
exit
(Setting the TERM to dumb eliminates all the terminal escape sequences from any output that gets redirected to a file, as is usually what happens with these background jobs.) Another common way to launch a background process is via HOSTEX, e.,g.
xcall HOSTEX, "$ASHELL -e run jack4"
Note that without the & suffix, the job launched by the above command is not a background job (it shares the parent job terminal). Even if you add the & suffix, while technically that should make it a background job in the sense that the parent doesn't need to wait for it, it still takes over the terminal, leaving A-Shell to treat it as a foreground job and give it a TSKxxx name. You have to redirect the output to get A-Shell to give it a TASxxx name, e.g.
xcall HOSTEX, "$ASHELL -e run jack4 >jack4.out 2>&1 &"
I may have wandered off the path here, but I suspect that the issue you're having with background processes that don't show up in A-Shell is actually due to the processes getting hung up and not even launching A-Shell. I'm not sure if that answers all 4 of your questions or not. I'm not even positive that I've identified the underlying problem, but I can assure you that there is no deliberate logic that would allow A-Shell to launch without allocating a job that would be visible in the SYSTAT, and especially without any ashlog.log INOUT traces.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37935
27 Mar 25 03:59 PM
|
Joined: Jun 2001
Posts: 3,424
Jorge Tavares - UmZero
Member
|
|
Member
Joined: Jun 2001
Posts: 3,424 |
Sometimes I think to have entered in the wrong forum, because don't understand nothing of what you're talking about. If you go ahead with a session about this in the Conference, can I suggest to do it at the Bar? At least we will have drinks 
Jorge Tavares
UmZero - SoftwareHouse
Brasil/Portugal
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37937
27 Mar 25 04:33 PM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
Good idea; I think it's going to require several rounds of them!
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37944
28 Mar 25 09:19 AM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
To be honest, I think you have 'wandered off', but in the interests of meandering: Unhelpfully, I am not seeing the same results. So, for context, I have tried on a number of different systems and Ashell versions, but the following is based on AShell 6.4.1561.1 on CentOS 7. Ashell program: (bgjob)
significance 11
++include ashinc:ashell.def
DEFINE PRG'NAME = "BGJOB"
DEFINE VERSION = "1.0"
PROGRAM BGJOB,1.0
map1 miamePath,s,0
map1 inum,i,4
map1 start,i,4
map1 check,i,4
START:
xcall HOSTEX, "touch /home/omni/bgjob-running.fil"
xcall MIAMEX, MX_GETENV, "MIAME", miamePath
xcall TIMES, 1, start
do
if (lookup(miamePath+"/dsk0/100000/kill.bgp"))
kill miamePath+"/dsk0/100000/kill.bgp"
exit
endif
xcall TIMES, 1, check
if ((check - 30) > start) exit
loop
kill "/home/omni/bgjob-running.fil"
end
Linux shell script: (runprg)
#! /bin/bash
export MIAME=/vm/miame
PATH=$MIAME:$PATH
export TERM=dumb
cd /vm/miame/dsk0/100007
ashell -n -e run "$@"
cd ~
Direct terminal run - ./runprg bgjob job appears in systat with TSK as expected.
.systat/n
Status of A-Shell Version 6.4.1561.1 on Friday, March 28, 2025 14:48:05
HOOK01 HOOK01 root DSK0:100,0 RN HOOKQ 1741 2324K
TSKAAB TSKAAB EL DSK0:100,35 RN THQDSP 55968 2875K
TSKAAC TSKAAC omni DSK0:100,7 RN SYSTAT 80763 2369K
TSKAAD TSKAAD SYS DSK0:100,7 RN MENU 85475 2798K
TSKAAE TSKAAE JL DSK0:100,7 RN MENU 85616 2816K
TSKAAF TSKAAF omni DSK0:100,7 RN BGJOB 86119 2093K
TASAAG TASAAG root DSK0:100,0 SD TQBL 28621 2579K
7 jobs allocated on system, 7 in use
Total memory on system: 3861212 kB
Sys Up: 14:48:05 up 231 days, 43 min, 6 users, load average: 0.09, 0.07, 0.10
Direct terminal run to bg - ./runprg bgjob job 'disappears' as you found and appears to freeze processing.
.systat/n
Status of A-Shell Version 6.4.1561.1 on Friday, March 28, 2025 14:51:23
HOOK01 HOOK01 root DSK0:100,0 RN HOOKQ 1741 2324K
TSKAAB TSKAAB EL DSK0:100,35 RN THQDSP 55968 2875K
TSKAAC TSKAAC omni DSK0:100,7 RN SYSTAT 80763 2369K
TSKAAD TSKAAD SYS DSK0:100,7 RN MENU 85475 2798K
TSKAAE TSKAAE JL DSK0:100,7 RN MENU 85616 2816K
TASAAG TASAAG root DSK0:100,0 SD TQBL 28621 2579K
6 jobs allocated on system, 6 in use
Total memory on system: 3861212 kB
Sys Up: 14:51:23 up 231 days, 47 min, 6 users, load average: 0.02, 0.08, 0.11
[omni@Test ~]$ ps -ef | grep ashell
root 1741 1 0 2024 ? 06:55:39 /vm/miame/bin/ashell -j hook01 -n
root 28621 1 0 Jan02 ? 00:06:43 /vm/miame/bin/ashell -n
omni 55968 55910 0 10:40 pts/1 00:01:28 ashell -n dsk0:start.lin[100,0]
omni 80763 80706 1 14:06 pts/3 00:00:30 ashell -n dsk0:start.lin[100,0]
omni 85475 85419 0 14:43 pts/4 00:00:00 ashell -n dsk0:start.lin[100,0]
omni 85616 85563 0 14:43 pts/7 00:00:00 ashell -n dsk0:start.lin[100,0]
omni 86519 86518 0 14:51 pts/6 00:00:00 ashell -n -e run bgjob
omni 86622 83145 0 14:52 pts/5 00:00:00 grep --color=auto ashell
omni 116594 1 0 Jan24 ? 00:00:35 ashell -n dsk0:start.lin[100,0]
[omni@Test ~]$
Trying to terminate program manually also ignored:
omni 86519 86518 0 14:51 pts/6 00:00:00 ashell -n -e run bgjob
omni 86622 83145 0 14:52 pts/5 00:00:00 grep --color=auto ashell
omni 116594 1 0 Jan24 ? 00:00:35 ashell -n dsk0:start.lin[100,0]
[omni@Test ~]$ touch /vm/miame/dsk0/100000/kill.bgp
[omni@Test ~]$ ps -ef | grep ashell
root 1741 1 0 2024 ? 06:55:39 /vm/miame/bin/ashell -j hook01 -n
root 28621 1 0 Jan02 ? 00:06:43 /vm/miame/bin/ashell -n
omni 55968 55910 0 10:40 pts/1 00:01:28 ashell -n dsk0:start.lin[100,0]
omni 80763 80706 1 14:06 pts/3 00:00:30 ashell -n dsk0:start.lin[100,0]
omni 85475 85419 0 14:43 pts/4 00:00:00 ashell -n dsk0:start.lin[100,0]
omni 85616 85563 0 14:43 pts/7 00:00:00 ashell -n dsk0:start.lin[100,0]
omni 86519 86518 0 14:51 pts/6 00:00:00 ashell -n -e run bgjob
omni 86797 83145 0 14:53 pts/5 00:00:00 grep --color=auto ashell
omni 116594 1 0 Jan24 ? 00:00:35 ashell -n dsk0:start.lin[100,0]
[omni@Test ~]$
Bringing program back to FG wakes program up and terminatesi it:
[omni@Test ~]$ ./runprg bgjob
[omni@Test ~]$ ./runprg bgjob &
[1] 86518
[omni@Test ~]$ fg 1
./runprg bgjob
[omni@Test ~]$
omni 86519 86518 0 14:51 pts/6 00:00:00 ashell -n -e run bgjob
omni 86797 83145 0 14:53 pts/5 00:00:00 grep --color=auto ashell
omni 116594 1 0 Jan24 ? 00:00:35 ashell -n dsk0:start.lin[100,0]
[omni@Test ~]$ ps -ef | grep ashell
root 1741 1 0 2024 ? 06:55:39 /vm/miame/bin/ashell -j hook01 -n
root 28621 1 0 Jan02 ? 00:06:43 /vm/miame/bin/ashell -n
omni 55968 55910 0 10:40 pts/1 00:01:28 ashell -n dsk0:start.lin[100,0]
omni 80763 80706 1 14:06 pts/3 00:00:30 ashell -n dsk0:start.lin[100,0]
omni 85475 85419 0 14:43 pts/4 00:00:00 ashell -n dsk0:start.lin[100,0]
omni 85616 85563 0 14:43 pts/7 00:00:00 ashell -n dsk0:start.lin[100,0]
omni 86925 83145 0 14:54 pts/5 00:00:00 grep --color=auto ashell
omni 116594 1 0 Jan24 ? 00:00:35 ashell -n dsk0:start.lin[100,0]
[omni@Test ~]$
Again, as you found, redirecting input does result in the program being visible in SYSTAT. However, in this case it is given a TSK job ID, rather than a TAS one. Job terminates normally:
[omni@Test ~]$ ./runprg bgjob
[omni@Test ~]$ ./runprg bgjob &
[1] 86518
[omni@Test ~]$ fg 1
./runprg bgjob
[omni@Test ~]$ ./runprg bgjob </dev/null &
[1] 87333
[omni@Test ~]$
.systat/n
Status of A-Shell Version 6.4.1561.1 on Friday, March 28, 2025 14:58:14
HOOK01 HOOK01 root DSK0:100,0 RN HOOKQ 1741 2324K
TSKAAB TSKAAB EL DSK0:100,35 RN THQDSP 55968 2875K
TSKAAC TSKAAC omni DSK0:100,7 RN SYSTAT 80763 2369K
TSKAAD TSKAAD SYS DSK0:100,7 RN MENU 85475 2798K
TSKAAE TSKAAE JL DSK0:100,7 RN MENU 85616 2816K
TSKAAF TSKAAF omni DSK0:100,7 RN BGJOB 87334 2093K
TASAAG TASAAG root DSK0:100,0 SD TQBL 28621 2579K
7 jobs allocated on system, 7 in use
Total memory on system: 3861212 kB
Sys Up: 14:58:14 up 231 days, 53 min, 6 users, load average: 0.08, 0.05, 0.09
Having noticed that the above starts a secondary process, let's try repeating above in a more direct way:
[omni@Test ~]$ cd /vm/miame/dsk0/100007
[omni@Test 100007]$ ashell -n -e run bgjob < /dev/null &
[1] 89284
[omni@Test 100007]$ .run bgjob
[1]+ Done ashell -n -e run bgjob < /dev/null
[omni@Test 100007]$
.systat/n
Status of A-Shell Version 6.4.1561.1 on Friday, March 28, 2025 15:12:32
HOOK01 HOOK01 root DSK0:100,0 RN HOOKQ 1741 2324K
TSKAAB TSKAAB EL DSK0:100,35 RN THQDSP 55968 2875K
TSKAAC TSKAAC omni DSK0:100,7 RN SYSTAT 80763 2369K
TSKAAD TSKAAD SYS DSK0:100,2 RN MENUEX 87863 2826K
TSKAAE TSKAAE JL DSK0:100,7 RN MENU 85616 2816K
TSKAAF TSKAAF omni DSK0:100,7 RN BGJOB 89284 2097K
TASAAG TASAAG root DSK0:100,0 SD TQBL 28621 2579K
7 jobs allocated on system, 7 in use
Total memory on system: 3861212 kB
Sys Up: 15:12:32 up 231 days, 1:08, 7 users, load average: 0.19, 0.14, 0.14
This time we have the same process number, but still with TSK ID. Final option, via CRON. Job appears in SYSTAT with TAS ID. So, I suspect that some of above may not be that relevant, in the end, but perhaps intriguingly odd. Back to the questions. The first that I don't think has been answered and is probably the most important/relevant, is how does Ashell determine whether to use TAS or TSK? What rule sets the ID? However, this only really came about because of trying to emulate/simulate the actual situation for testing. Given that the CRON processes do appear to use TAS, I can probably use that for testing. Certainly the processes on the customer system are getting TAS IDs and hopefully appearing in SYSTAT. So, I think the ultimate answer will be to use and check SYSTAT output with the XUSER.SYS job IDs. Any XUSER TAS jobs that are not current (in SYSTAT) can probably be safely removed. I can run this at a suitably late/early hour (avoiding other CRONs) which should enable the cleaning of the XUSER.SYS file.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37945
28 Mar 25 11:13 AM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
I thought my status as author of the longest forum posts was secure, but now I'm not so sure! On the bright side, it's a lot quicker/easier to read these epics than to write them, so I will happily step aside to the new titleholder. And now that you've asked the question twice, perhaps it's (past) time for me to deliver a straight answer: A-Shell assigns a TASxxx (rather than TSKxxx) name if and only if it's stdout is not a terminal device. To be more specific, here's the core test in the code (in C) ...
if (isatty(STDOUT_FILENO))
strcpy(m1.jc.jobnam, "TSK");
else
strcpy(m1.jc.jobnam, "TAS");
( isatty() is a standard library function that tests whether the file descriptor is a tty device; STDOUT_FILENO is defined to be the stdout descriptor.) So, the detail that kind of got lost in the woods here is that although the stdin descriptor seems critical in determining whether the process will actually run (vs hanging in wait); it's stdout that triggers TASxxx vs TSKxxx. Merely appending & to the command line to spawn off a child process for the command is not sufficient to decouple that process's stdout from the tty. You have to explicitly redirect it, for example:
$ ashell -n -e run bgjob < /dev/null > /dev/null 2>&1 &
That detail isn't really necessary with cron jobs because they are completely decoupled from any tty from the get go. But processes you launch from your terminal session need explicit redirection else they inherit your tty.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37947
28 Mar 25 05:26 PM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
That's great.
I should now be able to run some tests without having to deal with CRON as well, which should make it a little easier.
Thank you.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37949
31 Mar 25 02:59 AM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
I'm trying to determine if the continued problem of the XUSER.SYS file filling up has become a self generating consequence of the previous fixes.
Based on the fact that we now know that an XUSER slot can be allocated if found empty, regardless of any other presence of any given 'key', that supports the idea of duplicate entries but not necessarily a high number.
We have a customer XUSER.SYS file where the TAS IDs have been used from AAA to AES. There are the odd few 'missing', but that still leaves in the order of 130 entries. I do believe that part of the problem is certain CRON tasks starting multiple sessions, but I'm not sure it would be this many.
So, next question. What determines the next xxx ID in any TASxxx or TSKxxx allocation? Is it simply based on current IDs found in SYSTAT, or something else in addition?
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37952
31 Mar 25 11:22 AM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
As it stands, the next xxx for the TASxxx or TSKxxx job name assignment is based on scanning the job table (i.e. like SYSTAT) and picking the first unused job #. So if you start out with ten jobs, TSKAAA thru TSKAAJ, and then TSKAAB exits, the next job name allocated will be TSKAAB (or TASAAB). It's an entirely arbitrary scheme, and presumably could be changed without affecting anything, given that the next job name is unpredictable. On the other hand, it's conceivable that a change in that algorithm could affect the issue you're running into. For example, if we cycled through all the possible name T??AAA - T??ZZZ before rolling over to AAA again, you'd likely end up filling up your XUSER.SYS even sooner (assuming that you are using the initial destructive read to clear out any packet left over from a prior job of same name. Otherwise, the only difference would be that instead of filling up your XUSER.SYS with a bunch of duplicate packet names, you'd be filling it up with a bunch of unique packet names.) Note that you can control the job name yourself via the -j jobname switch, so maybe you can come up with your own scheme to take control of the uncertainty. In particular the # suffix option (-j name#) would be ideal, assuming no more than 9 jobs with the same base name. But that also requires that the base name be no more than 5 characters, so you couldn't use something convenient like -j $LOGNAME# because the numeric suffix would only work if the $LOGNAME was 1-5 characters. (Then again, A-Shell should probably be smart enough to truncate the base name when there is a # suffix. But that would also require an update, although I'm happy to do that.) Maybe it would be practical for you to assign a short base name to each distinct CRON process, in which case your job names in SYSTAT would be more sensible. Unfortunately, although it's easy to see what's in the XUSER.SYS, we don't have any ready-made way to trace all of the operations on it, other than activating the XCALL TRACE. But that might overwhelm your ashlog, depending on how many other XCALLs you use. On a barely related note, although presumably you are able to do your testing now by redirecting the stdout on the command line, if there's any doubt about that behavior being somehow different than what you get with cron, I would suggest using the at command as an alternative, i.e.
echo "ashell -n -v -e mycmd" > at now
Although it's not quite identical to cron, as long as you are the same effective user as the owner of the crontab in question, the environment created should be identical.
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37953
31 Mar 25 02:54 PM
|
Joined: Oct 2015
Posts: 237
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 237 |
Can I confirm my understanding of your last message.
Is the xxx number acquired, irrespective of the Prefix used? So, as a further example, could the existing entries have been allocated as TSKAAA, TASAAB, TASAAC, TSKAAD, and would the the next XXX be AAE whether the prefix is TSK or TAS?
|
|
|
|
Re: XUSER.SYS packet allocation.
[Re: Stuart]
#37954
31 Mar 25 03:00 PM
|
Joined: Jun 2001
Posts: 11,924
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,924 |
Yes, that's correct. And in fact, if a foreground job loses its terminal connection, it will revert to a background job (until it terminates based on variations of the -h command line switch), changing its prefix from TSK to TAS.
|
|
|
|
|
