Re: Segfault in Debian 12 but not EL7
John Andreasen
03 Apr 25 10:37 PM
I am now seeing code that is triggering the BASIC error that I think should not. It is reproducible with this example.
DIMX $test,ordmapm(varstr;varstr)
MAP1 key$,s,0
MAIN'ROUTINE:
$test("1") = "_"
$test("1") = "_"
$test("2") = "_"
key$ = "1"
DO WHILE NOT .ISNULL($test(key$))
$test(key$) = .NULL
LOOP
END
29
543
Read More
|
|
Re: Segfault in Debian 12 but not EL7
Jack McGregor
02 Apr 25 06:36 PM
Ok, here's a new-and-improved test version (7.0.1770.5) which implements the test (for an attempt to delete a collection element while iterating the collection) at a lower level, where it won't be fooled by code like the example above. But note that it also won't be fooled by my suggested workaround of using another variable in place of the .key($$i) or .NULL references. It still issues that same error 67 ( ?Invalid collection operation or reference), which perhaps isn't as clear and precise as it could be (as opposed to, say, "?Illegal attempt to delete an element of collection during iteration"), but I wasn't sure it was worth christening a new error code. For now, let me just repeat that this is a limitation of the underlying Standard Template Library implementation of collections, not an ASB issue per se. ash70notes.txtash-7.0.1770.5-w32-upd.zipash-7.0.1770.5-el7-upd.tzash-7.0.1770.5-d12-x86_64-upd.tz
29
543
Read More
|
|
Re: XUSER.SYS packet allocation.
Jack McGregor
31 Mar 25 10:00 PM
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.
14
165
Read More
|
|
Re: XUSER.SYS packet allocation.
Stuart
31 Mar 25 09:54 PM
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?
14
165
Read More
|
|
Re: XUSER.SYS packet allocation.
Jack McGregor
31 Mar 25 06:22 PM
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.
14
165
Read More
|
|
Re: Segfault in Debian 12 but not EL7
Jack McGregor
31 Mar 25 05:53 PM
I figured out a way to make the check for an illegal deletion from a collection during iteration more precise. But as it would close off the back door workaround, so I need to be certain that it isn't going to block any otherwise legal/legitimate operations. Figure on an update in a couple of days.
29
543
Read More
|
|
Re: Segfault in Debian 12 but not EL7
John Andreasen
31 Mar 25 04:05 PM
Thanks for the reply. You are correct that this is templated code. So, that is where the func$ mapping is from. I am glad you mentioned the keyword though as I was unaware or had forgotten about it as it is common for us to always map the func$ variable and set it to either a string literal of the function name or .LAST_ROUTINE if it is in a program where we can count on the pragma TRACK_LAST_ROUTINE being enabled. As for the detection, just let us know what you decide.
29
543
Read More
|
|
Re: XUSER.SYS packet allocation.
Stuart
31 Mar 25 09:59 AM
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?
14
165
Read More
|
|
Re: Segfault in Debian 12 but not EL7
Jack McGregor
30 Mar 25 12:21 AM
I'm afraid you've found a crack in the digital firmament. The runtime time detection that was added in order to be able to report an error instead of running the risk of a segmentation fault was far from perfect. It fails to detect workarounds, like assigning .key($$i) to a variable and then using it as the key, or coping .NULL to a variable and using it to delete the key-value pair. At the time, I figured it was better than nothing. But obviously in this case, it's worse than nothing, since your key-value deletion during iteration of a different map is perfectly safe. I have to think about whether it's practical for the runtime system to detect that the map from which the key-value pair is being deleted is not the one being iterated. It may be best to just rely on the compiler to try to flag them before the runtime system gets a chance to see them. In the meantime though, the workaround is simple enough (just copy the .key($$i) value to a variable and use it for the deletion) ...
map1 key$, s, 20
...
FOREACH $$i IN $gc()
key$ = .key($$i)
$ordership'pallet'item_fk_order_pallet_iter_dyn'key(key$)) = .NULL
NEXT $$i
Although this is totally off the subject, for what it's worth, I'd like to make sure that you are aware of a couple of syntactic shortcuts related to your code: The first is that the auto-defined symbol ABC_CURRENT_ROUTINE$ is automatically set to the name of the current function, so there's no real need for your func$ variable definition. (I realize that it's probably your code generator doing this, so weren't not talking about saving wear and tear on your fingers, but it might make the code slightly cleaner to look at.) The second is that the trace.print statement will automatically output the names of variables specified, along with their values, so for example, instead of :
trace.print " " + func$ + " hndl=["+hndl+"] "
you could instead use
trace.print ABC_CURRENT_ROUTINE$, hndl
The output of the second version is virtually identical to the first, e.g.
fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect hndl=[1]
Note that variables on the trace.print line get expanded to var=[value], while literal text, symbols and expressions are just output as is.
29
543
Read More
|
|
Re: Segfault in Debian 12 but not EL7
John Andreasen
28 Mar 25 11:42 PM
The update related to detecting the deleting of elements during iteration seems to have an issue. I was able to reproduce with the code below. A-Shell 7.0.1770.4 EL7
++PRAGMA PRIVATE_BEGIN
PRIVATE DIMX $ordership'pallet'item_fk_order_pallet_iter_dyn'key,ordmap(varstr;varstr)
++PRAGMA PRIVATE_END
MAIN'ROUTINE:
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("1-1") = "_"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("1-2") = "_"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("2-1") = "_"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("2-2") = "_"
CALL fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect(hndl=1)
END
!-------------------------------------------------------------------------
!Function: fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect()
! delete all dyn'key elements for given handle
!
!Parameters:
!--------------------------
! hndl [ITER_HANDLE, i/o] - variable with handle value
!Privates:
!--------------------------
! $ordership'pallet'item_fk_order_pallet_iter_dyn'key()
!-------------------------------------------------------------------------
FUNCTION fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect(hndl as f8:INPUTONLY,dummy=0 as b1:OUTPUTONLY)
MAP1 func$ ,s,0,"fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect()"
DIMX $gc ,ordmap(varstr;varstr) ! key by dyn'key
trace.print " " + func$ + " hndl=["+hndl+"] "
FOREACH $$i IN $ordership'pallet'item_fk_order_pallet_iter_dyn'key(hndl)
!IF (fn'str_startswith(.key($$i), hndl) = TRUE) THEN
IF VAL(.KEY($$i)[1;1]) = hndl THEN
trace.print " " + func$ + " GATHER .key($$i)=["+.key($$i)+"] val=["+edit$(STR($$i), 40)+"]"
$gc(.key($$i)) = ""
ELSE
EXIT
ENDIF
NEXT $$i
FOREACH $$i IN $gc()
trace.print " " + func$ + " DELETE .key($$i)=["+.key($$i)+"] val=["+edit$(STR($$i), 40)+"]"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key(.key($$i)) = .NULL
NEXT $$i
ENDFUNCTION
The operation of deleting the element in the second loop causes a BASIC error.
29
543
Read More
|
|
Re: XUSER.SYS packet allocation.
Jack McGregor
28 Mar 25 06:13 PM
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.
14
165
Read More
|
|
Re: XUSER.SYS packet allocation.
Stuart
28 Mar 25 04:19 PM
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.
14
165
Read More
|
|
Re: Computing working days
Frank
28 Mar 25 02:57 PM
Well that is a good analogy - but why goto the library when you can just get everything online?! Ok well enuf beating this horse glad Jorge got his utility and Jack lives to ride another day  Hey Jorge - thanks for asking. We are all well thanks albeit right now in a very serious wildfire emergency here. Hoping to not have to evacuate. Still working and supporting our customer base.
29
293
Read More
|
|
Re: Computing working days
Jorge Tavares - UmZero
28 Mar 25 07:05 AM
Well Jack, you can count with several drinks on me as well as a nice bottle of some distilled with the promise to keep this topic hot and, I take the chance to invite Frank to join the group to drink and to improve the talk. By the way, Frank how are you and family? What is your current professional situation and plans? Wish a nice last working day for this week 
29
293
Read More
|
|
Re: Computing working days
Jack McGregor
28 Mar 25 05:11 AM
Adding more functions to the SOSLIB doesn’t create any more bloat than adding books to the public library. And if it improves the chances of being able to ‘borrow’ what you were looking for, instead of having to ‘buy’ (write) it, what’s not to like? But perhaps we have taken this idea too far, so Jorge, if you buy me a drink at our next meeting, I promise to never mention this project again! 
29
293
Read More
|
|
Re: Computing working days
Frank
28 Mar 25 02:44 AM
Understood - not being critical i just think simple tasks like these are easily written locally w/o the bloat of a large function of the programming environment (ashell).
29
293
Read More
|
|
Re: Computing working days
Jorge Tavares - UmZero
28 Mar 25 01:51 AM
Frank, apologize, but I don't know what you mean about "we are asking to the operating system"
what are we asking for?
If you read from the initial post, I asked the community if anyone have written a function to count working days, after that we started to joke with non-related stuff and when I thought that we have closed the topic, on the fly, I came up with a draft for a function that could solve my specific needs and, for my surprise, Jack add it to an existing function, among dozens he wrote for the community, but SOSLIB is not operating system, is a collaborative library.
What I find in those 3/4gl languages is an huge ammount of libraries where, almost surely, we can find useful and shareable stuff for all needs and that's what we are trying to get in our small Gauloise Village.
Jack , huuuuuummmmmmmm, now you got me, I don't know if I have enough strength to take that challenge
29
293
Read More
|
|
Re: Computing working days
Frank
28 Mar 25 12:29 AM
Jack - Well then, i have been way ahead of that curve for at least 10 years now!  Jorge - still don't understand why we are asking the operating system / programming language to provide this function. Just so I am clear, is this function avalable in other 3/4gl languages?
29
293
Read More
|
|
Re: Computing working days
Jack McGregor
27 Mar 25 11:31 PM
I advise not exposing those pens to too much light (in order to take pictures), since considering their advanced age, the delicate pigments in the housing might fade, reducing the value.
As for your unavailability list handler, setting aside the possible complication of partial days, what's needed now is just a Fn'Load'Holidays(holidays()) function that loads up the auto_extend holidays() array, preferably using the XCALL DATES DTOP_CVTFMT B4 internal Julian date format (or the Fn'Date'To'JulianY2K version that reduces it to a B2 offset from 1/1/2000). That array could then be easily passed as an optional parameter to the Fn'Day'Ago() function, which I would be happy to update to factor the array of holidays into the elapsed working days calculation.
29
293
Read More
|
|
Re: XUSER.SYS packet allocation.
Jorge Tavares - UmZero
27 Mar 25 10:59 PM
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 
14
165
Read More
|
|
Re: Computing working days
Jorge Tavares - UmZero
27 Mar 25 10:53 PM
Well I'm tempted to extend my collection of Microsabio pens and apologize for the absence of pictures, the banks are already closed to access my secret safe. Frank, fortunately Brazil didn't adopt Thanksgiving (yet) otherwise it would be easier to fill the list of working days instead of the holidays. I'll be happy to jump in that contest with my "unavailability list" handler Apologize for the portuguese labels, anyway it's an easy translation, any AI piece of code can convert the image into a translated one. In a short description, it allows to register unavailable slots of time for the purpose you need. It can be single days (yyyymmdd), periods, yearly days (mmdd) (eg Thanksgiving, Christmas) as well as fixed weekdays or half days (eg: if the company don't work on friday's afternoon). There is also a customizable table for types of days like "national holidays", "regional holidays", "vacations" and so on, to identify the type of slot. This list is saved in an ISAMA table and there is Function to check how many unavailable slots exist in a period (I'm adjusting it right now for my current needs considering this module was written in 2007 and can be optimized). Have fun
29
293
Read More
|
|
Re: Computing working days
Jack McGregor
27 Mar 25 10:11 PM
Steve - opening that package would be like opening a 200 year old bottle of Romanee Conti - not only is the value destroyed, the contents have almost certainly gone bad! You might want to hold on to it a bit longer though, since the new tariff war is sure to drive the prices even higher!
Frank - actually I think the book smart look has gone out of style -- the new look is a goofy T-shirt with a sport coat and baseball cap. And yes, obviously having a standard holiday schedule is out of the question. But it might still be a reasonable idea to create a standard representation for a user-editable list of holidays so that it could be easily incorporated into standardized algorithms. (So maybe reports of my pending resignation are grossly exaggerated!)
29
293
Read More
|
|
|
|
