Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Dariusz Piatkowski

Pages: [1] 2 3 ... 11
Programming / RUX function failure - but on multiple tries only...
« on: September 29, 2022, 03:00:21 am »
Umm...I'm scratching my head here because I wrote this script a couple of years ago and it has been rock-solid.

The purpose is to check the connectivity between my box and the NAS, which sometimes just flat-out "goes away". Re-starting the NetDrive control fixes it.

Alright, so here is what I call:

Code: [Select]
/* check ifthe RXU - RXU.DLL - is required */
   IF rxu_api_required = 1 THEN DO
      /* check if the DLL is already loaded */
      rxu_api = RxFuncQuery('rxuinit')
      msg_text="RXU: already in memory, RC="||rxu_api
      IF rxu_api <> 0 THEN DO
         CALL RxFuncAdd 'rxuinit','RXU','rxuinit'
         CALL rxuinit
         msg_text="RXU: loaded into memory, RC="||rxu_api
      CALL debug debug_flag calling_code msg_level msg_text
      /* RXU version API returns a WHOLE bunch of stuff, so parse it first */
      msg_text="RXU: Using version "||msg_text
      CALL debug debug_flag calling_code msg_level msg_text

This normally gives me the following output:

DEBUG : MAIN => Initializing...
DEBUG :    ==> library_load => Initializing...
DEBUG :    ==> library_load => RXU: loaded into memory, RC=1
DEBUG :    ==> library_load => RXU: Using version v1.a
DEBUG :    ==> library_load => RXUTILEX: loaded into memory, RC=1
DEBUG :    ==> library_load => RXUTILEX: Using version 0.1.6
DEBUG :    ==> library_load => Exiting...

During the first run I'm all good, no problems.

However, re-runing the 2nd time and aftewards causes this CLI error msg to be produced:

   282 +++         rxu_api_info = rxuquery();
REX0043: Error 43 running G:\UTIL\MISC\nas_check.cmd, line 282: Routine not

...and produces the following matching LOG:

DEBUG : MAIN => Initializing...
DEBUG :    ==> library_load => Initializing...
DEBUG :    ==> library_load => RXU: already in memory, RC=0
   282 +++         rxu_api_info = rxuquery();
REX0043: Error 43 running G:\UTIL\MISC\nas_check.cmd, line 282: Routine not
    76 +++   Call library_load;

The weird part is that this seems to have literally just started on Sep-26th...prior to that I never saw any such failures...ugghhh???

Is there anything obviously wrong that i'm doing here?

BTW - in my code I check to see if I need a particular REXX DLL, if YES, I load it and then un-load it when my script has completed running.

Storage / JFS - cache MIN and MAX buffer parameters
« on: September 22, 2022, 08:19:00 pm »
Can anyone explain, or has the knowledge of, the use of these parameters by the JFS drivers?

Allow me to explain: I do of course understand at high level what these control, specifically I have the following entry in my CONFIG.SYS:


...however, as I continue to gather JFS runtime stats I haven't quite figured out what is the impact of the MAXBUFFER parameter in particular.

What I am trying to determine is how the BUFFERs are being allocated and how the MAX setting in particular impacts the availability of either the content or i-node metadata buffers.

Any ideas?



Just a quick FYI, I'm seeing a trap in SCANIMAGE.EXE following the deployment of libusb1 1.0.24 RPM package.

My scanner is USB attached, latest AOS drivers and was previously successfully using 1.0.21-2 release.

I went ahead and opened a NEW Issue, but great GitHub functionality prevents you for actually uploading any LOG files...LOL!!!

Anyways, if you're seeing strange results/traps be aware.

Mail-News / PMMail and filters - this one is not working...why?
« on: June 10, 2022, 10:40:00 pm »
So my very, very old email address has gone through cycles of SPAM...but this latest hit is a prolonged one and so I've decided to cook up some extra filters to deal with that challenge.

Luckily for me the vast majority of SPAM email addresses end with a couple of string patters. Here is an example of an email HEADER:

Code: [Select]
Date: Fri, 10 Jun 2022 16:04:45 -0400
From: Beth Buttler <>
Subject: Your Home Depot Verification No.  #3232007

You will noticed the from email address ends with ".click", I am also getting a pile of ".xyz" as well, easy enough to spot!

So to deal with this I figured that I'd just "beef up" my existing filters by adding the following;

Code: [Select]
(h.fromid.-z = "click" | h.fromid.-z = "xyz")

...alas, this does NOT work, and I cannot figure out why???

That filter is supposed to tell PMMail to simply look for a "*click" or "*xyz" in the actual email address field itself.

So I'm curious, is anything jumping out at anyone here?


Programming / Ghostscript - 9.18 build, any advice?
« on: February 09, 2022, 02:47:24 am »

Alright, so my help ticket hasn't resulted in an answer from the official BWW channel: it sounds like Silvan is alone/himself handling these, and since it's a volunteer effort I best make plans for an alternative approach to debugging my "Failed to print with GS 9.18". Just our reality I think, no fault of his.

Soo....I downloaded BWW's GS codebase, deployed locally, I have studied the source for a couple of days now. Did my share of the official documentation review...I have GCC as well as IBMCPP available here and it looks like the OS2.MAK file can handle either one.

Therefore, before I take the plunge and run with it: any last-minute advice as to what to watch out for???

It's a big app, numerous pieces (display and print devices, etc, etc), but the makefile itself doesn't actually look all that daunting.


Applications / GSView and Ghostscript - printing, how?
« on: February 02, 2022, 03:24:14 pm »
We've got a separate discussion (Programming forum =>,2985.msg33707/boardseen.html) on the challenge I've encountered attempting to use GS 9.18 to faciliate printing with GSView.

As I researched this further, and discovered that perhaps some of the printing functionality is a little off in this release (as compared to earlier ones) that made me wonder about how the rest of you are printing documents that may utilize GS for rendering.

Specifically, and most often I suspect, that would apply to PDFs.

In my case, I can use Lucide to print PDFs. Occasionally I run into an issue though and the print job produces an error on the printer itself (the root cause is unknown to me, but it's some kind of a PS stack overflow and my prior investigation suggested this may be a printer driver issue, which as we all know simply isn't going to get fixed, so case closed).

In such cases, I would most often rely on GSView to handle the printing task, and that has been working quite fine with GS9.04, but we are at 9.18 now and GSView with GS9.04 started to show it's age (various rendering errors would show up here and there), and much slower than GS9.18.

Therefore, I am curious how you print from GSView with whatever version of GS?

With GS9.04 I use the 'pswrite' Device and have the 'PostScript Printer' check box marked given that my Brother HL-5470DW is a PS printer.

With GS9.18 I tried using 'ps2write' Device since 'pswrite' has been obsoleted, but the '\\spool\printer_name\' printer identifier no longer appears to print in GS9.18.


Programming / GSView - make complains of "No such file or directory"
« on: January 29, 2022, 04:29:49 am »
I decided to take a stab at building an updated version of GSView (because the pswrite device is no longer present in our ghostscript 9.18 release and the latest GSView verison seems to have it hard-coded instead of picking the device name up from the gvpm.ini file and using that).

Anyways...couple of small tweaks to the makefile, but I'm getting stumped by a reference to two other makefiles: one for common objects and the other is a GSView version mak (auto-updates the GSView header that contains the version info).

I've attached the makefile here, and I'm seeing the following error:

Code: [Select]
makefile:85: ".\src\common.mak": No such file or directory
makefile:86: ".\src\gvcver.mak": No such file or directory
makefile:174: *** missing separator (did you mean TAB instead of 8 spaces?).  St

which is a result of the following lines in the main makefile:

Code: [Select]
# Common

include "$(SRC)common.mak"
include "$(SRC)gvcver.mak"

And yet, from a CLI where I am executing make from I can certainly do a "dir" and both of those files are certainly there:

[G:\code\source\os2\gsview-5.0]dir .\src\*mak

The volume label in drive G is OS2.
The Volume Serial Number is 45B6:75C3.
Directory of G:\code\source\os2\gsview-5.0\src

11-17-07  4:14p         2,409      0 a---  bzlibmsc.mak
 5-28-11 12:21p         5,677      0 a---  common.mak
 1-17-12  9:26p        23,686      0 a---  gvc.mak
 1-28-22 10:21p         1,802      0 a---  gvcver.mak

So what am I tripping over here?

Is this a OS/2 vs Linux path separator issue?

For what it's worth I tried the "/" vs "\" with no difference.



I've had a pesky problem on my OS/2 box for a while now, that being on Samba connections Lucide takes far too long to open a PDF that's sitting out there on my NAS box. This is not just a Lucide issue, GSView as well as QPDFView show the same behaviour.

We are talking here PDF files that are about 70-150k in size that take 5-10 secs to open up.

To be clear, I am using NetDrive Samba plugin to make this work, and that could certainly be adding, I just can't tell.

What I can see is that as I open a PDF file my TCP/IP monitor shows multiple traffic spikes, they continue (back and forth) until the file is opened up. Now nearly each one of these are spikes are actually larger than the actual PDF file itself, so that's literally flooring me as I can't for the life of me understand what is causing the traffic to happen. how can I troubleshoot this in order to figure out what all that "overhead" is that appears to be moving back and forth?

I've got Wireshark installed, so I could capture the packets as the transactions start...but is there something a little more human-digestable? I'm thinking Samba logging perhaps?


Networking / Samba Shares - default CAPS in filenames?
« on: January 22, 2022, 05:35:38 pm »
Hi Everyone,

I've noticed this the other week: it would appear that ALL newly created documents which I am saving on my NAS (therefore using Samba client connection) are using UPPERCASE letters, this is despite the fact that within the application itself I am actualy saving with lowercase, and/or combination of the two.

Has anyone else noticed this?

I recall having a sporadic occurence of this before, but I just attributed that to "human mistake" as I rarely create a lot of NEW documents on my NAS. But recently I have been doing a bit of a re-org and moving some of my OS/2 application specific things to formats that non-OS/2 apps can read and that is how I discovered this issue.

The NAS confirmation has not changes at all and so far I haven't spent much time researching the Samba config side of it, that'll be my next step though. In the meantime I was curious if anyone else has been encountering this behaviour?


Applications / LIBC panic errors anyone?
« on: January 09, 2022, 02:18:56 am »
I am running the following LIBC RPM packages:

1) libc.pentium4                            1:0.1.9-1.oc00
2) libc-devel.pentium4                      1:0.1.9-1.oc00
3) libcurl.pentium4                         7.75.0-2.oc00
4) libcx.pentium4                           0.7.2-1.oc00
5) libcx-devel.pentium4                     0.7.2-1.oc00

...and at some point in time (along the upgrade path) I started to notice the following "LIBC PANIC" errors in my trp directory:

LIBC PANIC!! _um_free_maybe_lock: Tried to free block twice - block=37013a00 lo
Call Stack
   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  1FE4B89E   LIBCN0    0001:000FB89E
 0013EAF8  1FE4C0A8   LIBCN0    0001:000FC0A8
 0013EB18  1FDE4B69   LIBCN0    0001:00094B69
 0013EB68  1FDC4D69   LIBCN0    0001:00074D69
 0013EB88  7B395268   XUL       0001:03565268  between js::gc::Arena::finalize + 228 and js::gc::ArenaLists::backgroundFinalize - 3678  (both in Unified_cpp_js_src23.cpp)
 34734D20  344B0538   *Unknown*
 Lost Stack chain - new EBP below previous

This one was actually generated by FF following my upgrade to the latest NSPR and NSS runtimes.

However, I've seen this error repeatedly with other applications, such as:

LIBC PANIC!! _um_free_maybe_lock: Tried to free block twice - block=20030035 lo
 Call Stack
   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  1FE4B89E   LIBCN0    0001:000FB89E
 0012FF14  1FE4C0A8   LIBCN0    0001:000FC0A8
 0012FF34  1FDE4B69   LIBCN0    0001:00094B69
 0012FF84  1FDC4D69   LIBCN0    0001:00074D69
 0012FFA4  000100E0   CRON2     0001:000000E0
 0012FFC4  00014238   CRON2     0001:00004238
 0012FFF4  1FFECE38   DOSCALL1  0004:0000CE38  DOS32R3EXITADDR

...or PMMail and AOO.

So I'm curious if anyone is seeing this too?

I can't quite peg this to a particular release, but it would have happened within the last couple of drops I think?

Applications / Apache OpenOffice - OOWpsWizard anyone?
« on: January 08, 2022, 03:09:49 am »
Alright, so way back when (circa OO3.2) there was a handy little WPS class utility (OOWPSWizard) that defined multiple WPS classes that directly mapped to various AOO program objects.

I have had this installed for a long time now...but having just upgraded from AOO 4.1.7 to 4.1.11 I am trying to clean the place up a tad, you know?

So this begs the question: is anyone still using this OOWPSWizard thing?

I can't quite for the life of me remember what use I got out of it back then...clearly I thought there was value in having it installed though..LOL, so maybe the old memory is getting a little shaky???

Come to think of it, the benefit I think we got back then was to map all the AOO program objects to a particular WPS class, which then allowed one to manage those classes and assign WPS associations accordingly.

....yeah, it's been a while, and I really would rather keep the AOO install clean to avoid any problems in the future...which makes me think I should un-install OOWPSWizard...


Storage / JFS - Trap 0003 - anyone?
« on: January 06, 2022, 02:51:27 pm »

I figured I would inquire here first before logging a ticket for the AN folks on this JFS issue.

So the other day I had a weird situation: my nightly RSYNC job LOG needed to be "rotated" having grown to some 32M in size over the past couple of years. I decided to manually split it up into calendar year LOGs. I most likely had the file open in my editor while at the same time attempted to execute a CLI copy of that big file.


JFS died with TRAP 0003...meltdown!

Following a power re-boot JFS did a check disk and uber quickly flashed some messages up on the screen about lost directories. The chkdsk forced an automated re-boot and a 2nd chkdsk run. At the end of what felt like the longest 5 mins ever I got back to my MAINT partition to discover that my 'lost+found' directory now had some 17k files. Clearly chkdsk found some directory problems and moved a boat-load of files into the 'lost+found' directory. Yikes!

Anywyas, I was aware that this is probably the worst JFS situation when directories are mangled. Now luckily for me I had a nightly backup (RSYNC...LOL), so I was able to recover just fine. The mangled directories turned out to be my Firefox and Thunderbird cache, thus the massive listing of files.

Now that I'm up and running again and spending a little time researching this I discovered the following description of a TRAP 0003:

TRAP 0003 - BREAKPOINT. This is a special instruction (INT 3) used in "debugging" software, which was left in the code either accidentally or by design. Contact software support.

Further on, the following is also available:

[G:\]help 1933

SYS1933: A program caused a breakpoint error.  The program was ended.


EXPLANATION: A program started an INT 3 instruction when it was not
being run by a debugger.

ACTION: Correct the program and retry the command.

I found this extremely interesting given that in this latest version of JFS AN announced a successful quashing of a JFS bug when operations on a file LARGER than the JFS CACHE would potentially trap.

In my case I am running a large 1G cache, so I do not think this to be the issue...however as I experiment with various MIN and MAX buffer settings I may have potentially ran into a problem there. Hard to tell and NO I have not tried to replicate this issue!!! ha....

Take a look at the attached TRAP screen...what do you guys make of it?


Multimedia / Audio-Data/CD-Creator - problems scanning the bus
« on: December 28, 2021, 11:17:41 pm »
I figured I would do a clean-up pass through my multimedia apps and configuration during the holidays, and part of that meant replacing as many of the previously added one-by-one apps with RPM modules (where available).

One of these is cdrecord.exe, which I installed the RPM package for and intended to replace my originaly installed 'CDRecord/2 v2.0-Final' that came along with the 'Audio-Data/CD-Creator' application.

Well, as luck would have it having deployed the RPM package I attempted to test by scanning the bus for my DVD device, and that's where I ran into a snag:

Code: [Select]
0: G:\APPS\MULTIMEDIA\ADC_056\bin\scanbus.exe
1: -2147482817
2: G:\usr\bin\cdrecord.exe
Command is: G:\usr\bin\cdrecord.exe -scanbus
G:/usr/bin/sh.exe: 1: G:usrbincdrecord.exe: not found

Alright, so it looks like the SH shell is being invoked by the Audio-Data/CD-Creator application, why? I have no idea...can anyone tell?

It looks to me like sh.exe is stripping the "\", which results in a garbled cdrecord.exe name, which is why the "not found" message shows up.

I'm off to continue looking at this...


Found the following contents of the scanbus.log file:

Code: [Select]
0: G:\APPS\MULTIMEDIA\ADC_056\bin\scanbus.exe
1: -2147482739
2: G:\usr\bin\cdrecord.exe

Command is: G:\usr\bin\cdrecord.exe -scanbus

Drop down listbox cleared.

Scanbus done.

...which literally imply that this is working fine here, and yet the actual VIO window must be failing as no device ID is actually populated in the setup window.

Multimedia / mplayer - H265 problems anyone?
« on: December 13, 2021, 03:35:16 am »
That's right...not H264, but H265...

I published another engine building video on my channel a couple of weeks ago, and it being nearly 20 mins made for a pretty good-sized file, even the YouTube 720 version was about 1.6G.

So I went back to my old trusy video encoder, that being HandBrake, which I'm running on the Ryzen7 Win10 box here and played around with a few different setups. Eventually I compared the H264 to a H265 encoding because the Nvidia video card that's in that box supports H265 hardware encoding...YEAH...big improvement, from about 20 mins on Super1080HQ on CPU-alone, to just about 3 mins on the GPU!

Anyways...was pretty happy...but I always do my final review on my OS/2 box to see how the slower hardware handles it. Now here is where the surprise showed up: mpalyer wasn't able to play the H265 video normal. What I mean by that is that the playback was about 1/2 speed and it was definitely single threaded, my CPU monitor would show a single core at 100%, which would switch to another core, etc, etc.

In comparison a regular H264 1080HQ playback normally uses about 15-20% spread on the 6 cores, and it's definitely multi-threaded.

I'm running MPlayer SVN-r38083-9.1.0, smPlayer is just fine and VLC seems to be OK, but for some reason I discovered that none of the 1080 vides are producing video outputs in VLC, but that's a separate issue.

Sooo...I'm curious: has anyone else seen this?

I logged an issue report for this, see =>

Thanks everyone!

Internet / PMMail - corrupted folders?
« on: December 08, 2021, 02:35:16 pm »
Hi Everyone,

I've been happily using PMMail [ (32798) - Mar 13 2020 17:32:02 +0000 (GMT)] for a while now. No issues, although occasionally at start-up it'll trap, meaning the WPS goes locked but usually after a few ESC-CTRL hits it'll re-awake. Mostly a nuissance really.

As best as I can tell I have never encountered any problems, however the other day I was putting away some new emails into a much much older folder and couldn't find the emails afterwards. I re-index that particular folder at first, no change, I then re-index that whole folder tree, still no change.

This morning I hit CLI and went looking for the actual email MSG file itself...lo' and behold, nowhere to be found...worse yet, that whole folder TREE is completely missing!!! ugh????

Now the strange thing (to me anyways) is that from within PMMail I am still able to access each one of the folder tree it looks like the stuff is still there (thank God, so I haven't lost anything it would seem), but attempting to move new emails into that tree does appear to send the messages into "nowhere".

So am I seeing some kind of a corruption here?

No idea at all how to troubleshoot this...any hints/suggestions would be greatly appreciated!



I went looking through the PMMail program logs and I think I found the matching entries for this email move transaction...however it appears to have completed just fine?

Code: [Select]
2021-12-08T08:19:15.033 (008)-I-MessageMoveMessage: enter. use mutex [1]                                                                                           
2021-12-08T08:19:15.033 (008)-I-MessageMoveMessage: moving from [Dariusz]:[Inbox] to [Dariusz]:[Mopar Archives]:[Engine Components]                               
2021-12-08T08:19:15.037 (001)-I-oswin_msg_drag: dragged [1] of [1] allowed of [1] requested                                                                       
2021-12-08T08:19:15.037 (001)-I-oswin_msg_drag: Dropped on Accounts/Folder                                                                                         
2021-12-08T08:19:15.039 (001)-I-oswin_msg_drag: leave                                                                                                             
2021-12-08T08:19:15.065 (008)-I-xmlfolder.profile_save: fld change [1], saving [Dariusz]:[Inbox]                                                                   
2021-12-08T08:19:15.072 (008)-I-xmlfolder.profile_save: fld change [1], saving [Dariusz]:[Mopar Archives]:[Engine Components]                                     
2021-12-08T08:19:15.080 (008)-I-MessageMoveMessage: leave.                                                                                                         

Pages: [1] 2 3 ... 11