Author Topic: REXX: RxStartSession, what is wrong with this call?  (Read 926 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
REXX: RxStartSession, what is wrong with this call?
« on: January 03, 2021, 11:37:25 pm »
In my NAS box periodic 'connectivity check' script I'm trying to do away with running a separate REXX cmd script to set the DEFAULT folder VIEW. I decided to just bring the calls in that one-off script directly into my main REXX script.

Here is what I have:

1) the stand-alone cmd script has a call to oo.exe to default the folder VIEW
Code: [Select]
...
/* Setup the default VIEW for the NAS Samba shares - FOLDERS */
'@g:\util\misc\oo.exe /a v:\photo "DEFAULTVIEW=XVIEW;"'
'@g:\util\misc\oo.exe /a v:\video "DEFAULTVIEW=XVIEW;"'
'@g:\util\misc\oo.exe /a v:\music "DEFAULTVIEW=XVIEW;"'
'@g:\util\misc\oo.exe /a v:\public\documents "DEFAULTVIEW=XVIEW;"'
'@g:\util\misc\oo.exe /a v:\public\syslog "DEFAULTVIEW=XVIEW;"'
...

2) the main connectivity check script is using this call
Code: [Select]
...
/* OK, now run the WPS settings utility */
api_rc=0
api_rc=RxStartSession('g:\util\misc\oo.exe','/a v:\photo "DEFAULTVIEW=XVIEW;"','C','F',,'O','A')
...

Now this thing flat out fails all the time. I haven't been able to figure out why, all I can tell is that the stared session VIO window pops up with the following in it:

Code: [Select]
invalid or malformed path

Now, I cannot for the life of me tell what oo.exe is complaining. However, I've tried to successfully convert this in mulitple ways, even did a quick convert of REXX to EXE (REXX2EXE utiility) and strangely enough whenever I do actually get the oo.exe to execute the very same error message is displayed.

So I'm thinking there is some kind of a session issue here...???

EDIT
====
I grabbed the oo.exe sources (which Rich Walsh included in his release) and found where oo is tossing that error. Will debug from there...
« Last Edit: January 04, 2021, 02:19:37 am by Dariusz Piatkowski »

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 50
  • Posts: 1095
  • Karma: +3/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #1 on: January 04, 2021, 02:06:45 am »
Hi Dariusz

I am *Not* a rexx expert and do not seem to have any information on RxStartSession apart from reading somewhere that it is part of the RXU addons for rexx. Just wondering about apostrophes and comma and whether your line would work when rewritten as

   'g:\util\misc\oo.exe /a v:\photo "DEFAULTVIEW=XVIEW;"','C','F',,'O','A'


Regards

Pete

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #2 on: January 04, 2021, 02:26:39 am »
Hi Pete,

...I am *Not* a rexx expert and do not seem to have any information on RxStartSession apart from reading somewhere that it is part of the RXU addons for rexx. Just wondering about apostrophes and comma and whether your line would work when rewritten as

   'g:\util\misc\oo.exe /a v:\photo "DEFAULTVIEW=XVIEW;"','C','F',,'O','A'
...

I would love to try that, the only challenge with that approach is the syntax of the RxStartSession API, which is detailed in the RXU v1.a INF file as:

Code: [Select]
Syntax:

  strc = RxStartSession(pgmname [,args [,related [,fgbg [,title [,type
                        [,ctrl] ] ] ] ] ])

where

  pgmname   = name of .EXE file to execute
                or
              32-bit pointer to populated STARTDATA structure used by DosStartSession
  args      = arg string to pass to program
  related   = Relation of started session to this session, can be:
              'I'ndependent or 'C'hild
  fgbg      = Foreground/Background option, can be:
              'F'oreground or 'B'ackground
  title     = Session title (defaults to program name)
  type      = Program type, can be:
              'D'efault, 'F'ullscreen, 'P'M, 'V'irtual-Dos,
              'W'indowed-Virtual-Dos, vi'O'-windowable
  ctrl      = Program control, can be:
              'V'isible, 'I'nvisible, ma'X'imized, mi'N'imized,
              no'A'utoclose
  strc      = if DosStartSession failed:
              - return code from DosStartSession followed by error info
              if DosStartSession got zero rc:
              - return code from DosStartSession Session-ID Process-ID

As best as I can tell that requires me to separate the actual EXE file (1st argument) from the remaining options, such as the EXE command line options themselves, as well as the remaining session configuration options.

Either way, I tried just about all of these remaining API options, the crux seems to be about oo.exe not picking up the passed parameters correctly, or most likely, these parameters not being passed to oo.exe in the way I intend them to be.

Alright, appreciate the pointer. I will jump back into building a debug version of oo.exe, so far I was able to compile the source, which is a great sign!



Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 37
  • Posts: 704
  • Karma: +9/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #3 on: January 04, 2021, 10:11:31 am »
I would be unsure of the error location. The syntax looks correct to me, even when I don't get what you gain from using Rx/DosStartSession (instead of cmd's CALL) and oo.exe (instead of SysSetObjectData).

I would comment other parts out to see if the erroneous line is the cited one. Then check if v:\photo really exists and is accessible. oo's error message assumes that it's not. Another test (without producing more unwanted EAs) is to change the setup string to "OPEN=DEFAULT;".

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 76
  • Posts: 817
  • Karma: +23/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #4 on: January 04, 2021, 02:12:33 pm »
Code: [Select]
Syntax:

  strc = RxStartSession(pgmname [,args [,related [,fgbg [,title [,type
                        [,ctrl] ] ] ] ] ])

where

  pgmname   = name of .EXE file to execute
                or
              32-bit pointer to populated STARTDATA structure used by DosStartSession
  args      = arg string to pass to program
  related   = Relation of started session to this session, can be:
              'I'ndependent or 'C'hild
  fgbg      = Foreground/Background option, can be:
              'F'oreground or 'B'ackground
  title     = Session title (defaults to program name)
  type      = Program type, can be:
              'D'efault, 'F'ullscreen, 'P'M, 'V'irtual-Dos,
              'W'indowed-Virtual-Dos, vi'O'-windowable
  ctrl      = Program control, can be:
              'V'isible, 'I'nvisible, ma'X'imized, mi'N'imized,
              no'A'utoclose
  strc      = if DosStartSession failed:
              - return code from DosStartSession followed by error info
              if DosStartSession got zero rc:
              - return code from DosStartSession Session-ID Process-ID

As best as I can tell that requires me to separate the actual EXE file (1st argument) from the remaining options, such as the EXE command line options themselves, as well as the remaining session configuration options.

Either way, I tried just about all of these remaining API options, the crux seems to be about oo.exe not picking up the passed parameters correctly, or most likely, these parameters not being passed to oo.exe in the way I intend them to be.

Alright, appreciate the pointer. I will jump back into building a debug version of oo.exe, so far I was able to compile the source, which is a great sign!

If you insist on doing it that way, I'd try "double double" quotes in the arg string. Depending on exactly HOW DosStartSession is invoked internally (does it run CMD.EXE under the hoods ? etc.) this could make a difference.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 37
  • Posts: 704
  • Karma: +9/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #5 on: January 04, 2021, 02:44:50 pm »
BTW: This has worked for me when I'd tested it this morning:
Code: [Select]
CALL RxFuncAdd 'rxuinit','RXU','rxuinit'
CALL rxuinit
rcx = RxStartSession( 'oo.exe', '/a F:\Apps\NEPMD\myepm\macros "OPEN=DEFAULT;"')
It really seems that the error is created by oo.exe.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #6 on: January 04, 2021, 07:24:28 pm »
OK, so a bit of an update.

I added a whole bunch of DEBUG statements to oo.exe so that I can trace through what's going up and understand why the failure.

As it turns out the issue occurs when oo.exe calls DosQueryPathInfo API, which in turn fails.

1) here is the output of the modified oo.exe when oo.exe processes the very same CLI arguments

Code: [Select]
[G:\tmp]oo.exe /a v:\photo "DEFAULTVIEW=XVIEW;"

DEBUG main => num of MAIN arguments passed:4
DEBUG main => arguments 0 is :oo.exe
DEBUG main => arguments 1 is :/a
DEBUG main => arguments 2 is :v:\photo
DEBUG main => arguments 3 is :DEFAULTVIEW=XVIEW;
DEBUG ParseArgs => num of arguments passed:4
DEBUG ParseArgs => num of characters in the EXE filename:9
DEBUG ParseArgs=> arguments 0 is :OO
DEBUG ParseArgs=> arguments 1 is :/a
DEBUG ParseArgs=> arguments 2 is :v:\photo
DEBUG ParseArgs=> arguments 3 is :DEFAULTVIEW=XVIEW;
DEBUG ParseArgs=> arguments 4 is :(null)
DEBUG ParseArgs => processing argument:0
DEBUG ParseObject => pArg:v:\photo
DEBUG ParseObject => pPath:
DEBUG ParseObject => DosQueryPathInfo API RC:0

2) and here is the output of the modified oo.exe when oo.exe processes these arguments from within my REXX script:

Code: [Select]
DEBUG main => num of MAIN arguments passed:4
DEBUG main => arguments 0 is :oo.exe
DEBUG main => arguments 1 is :/a
DEBUG main => arguments 2 is :v:\photo
DEBUG main => arguments 3 is :DEFAULTVIEW=XVIEW;
DEBUG ParseArgs => num of arguments passed:4
DEBUG ParseArgs => num of characters in the EXE filename:9
DEBUG ParseArgs=> arguments 0 is :OO
DEBUG ParseArgs=> arguments 1 is :/a
DEBUG ParseArgs=> arguments 2 is :v:\photo
DEBUG ParseArgs=> arguments 3 is :DEFAULTVIEW=XVIEW;
DEBUG ParseArgs=> arguments 4 is :(null)
DEBUG ParseArgs => processing argument:0
DEBUG ParseObject => pArg:v:\photo
DEBUG ParseObject => pPath:
DEBUG ParseObject => DosQueryPathInfo API RC:15
invalid or malformed path

So clearly, the DosQueryPathInfo API call returns RC=15, which is weird because per the published CP Guide and Reference these are the valid RC values:

DosQueryPathInfo returns the following values:

0 NO_ERROR
3 ERROR_PATH_NOT_FOUND
32 ERROR_SHARING_VIOLATION
111 ERROR_BUFFER_OVERFLOW
124 ERROR_INVALID_LEVEL
206 ERROR_FILENAME_EXCED_RANGE
254 ERROR_INVALID_EA_NAME
255 ERROR_EA_LIST_INCONSISTENT

Sooo...somehow submitting oo.exe from within my REXX script causes this issue.

I will try the approach you took Andreas, which is to run just this RxStartSession call from a separate REXX script to see if the failure is still there. If not, that would imply something else in my REXX is contributing to this issue.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #7 on: January 04, 2021, 07:26:36 pm »
Hi Lars!

If you insist on doing it that way, I'd try "double double" quotes in the arg string...

Hey, I'm all ears...what are you thinking in terms of other approaches I could take to mark a default view for a folder as XVIEW, basically "DEFAULTVIEW=XVIEW;"?

Thanks,
-Dariusz

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 37
  • Posts: 704
  • Karma: +9/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #8 on: January 04, 2021, 08:02:01 pm »
rc = 15 is ERROR_INVALID_DRIVE. So DosQueryPathInfo failed to find the drive of v:\photo. Note that the toolkit docs have a few flaws. Is it a network drive? But strange that your first code block works. I guess we need to see the whole script for more hints on that.

When you're already in a REXX script, why don't you just use the following?
Code: [Select]
rcx = SysSetObjectData( 'v:\photo', 'DEFAULTVIEW=XVIEW;')

Rich Walsh

  • Full Member
  • ***
  • Thank You
  • -Given: 1
  • -Receive: 14
  • Posts: 143
  • Karma: +2/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #9 on: January 04, 2021, 08:04:29 pm »
Code: [Select]
DEBUG ParseArgs => processing argument:0
DEBUG ParseObject => pArg:v:\photo
DEBUG ParseObject => pPath:
DEBUG ParseObject => DosQueryPathInfo API RC:15
invalid or malformed path

I wouldn't claim to really understand what the above is saying, but shouldn't 'pPath:' be displaying "v:\photo"? If the path is null, rc=15 (ERROR_INVALID_DRIVE) would not be inappropriate.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #10 on: January 04, 2021, 10:09:23 pm »
Hi Rich!

Ahh...Da Man himself (Rich is the author of oo, as well as the client/server portions that are utilized by oo)...alright sir.

Code: [Select]
DEBUG ParseArgs => processing argument:0
DEBUG ParseObject => pArg:v:\photo
DEBUG ParseObject => pPath:
DEBUG ParseObject => DosQueryPathInfo API RC:15
invalid or malformed path

I wouldn't claim to really understand what the above is saying, but shouldn't 'pPath:' be displaying "v:\photo"? If the path is null, rc=15 (ERROR_INVALID_DRIVE) would not be inappropriate.

You would be correct about that last statement, which is how I initially understood the code to work as well. However, upon further review I realized that this initial call to DosQueryPathInfo actually only checks that the path is a valid location. If so, there is a 2nd call to this API which then actually does the grunt work.

Specifically, here is the section of the code we are talking about:

Code: [Select]
...
// expand partially-qualified names
    rc = DosQueryPathInfo(pArg, FIL_QUERYFULLNAME, pPath, CCHMAXPATH);

    printf("\nDEBUG ParseObject => DosQueryPathInfo API RC:%ld\n", rc);
   
    if (rc != 0)
        ERRBRK( "invalid or malformed path")

    // if we actually find something, then this is a file or directory;
    // otherwise, assume this is an abstract object's title
    if (DosQueryPathInfo( pPath, FIL_STANDARD, &fs3, sizeof(fs3)))
        *pType = typeTitle;
    else
        *pType = RWSI_OPATH;

    fRtn = TRUE;
...

Since the 1st DosQueryPathInfo uses FIL_QUERYFULLNAME, that is a LEVEL_5 information block request, and per the CP book that "Level 5 returns the fully qualified ASCIIZ name of PathName in PathInfoBuf. PathName may contain global file-name characters". It is only at that point in time that pPath actually gets a value assigned to it, that being the fully qualified ASCIIZ path name.

Afterwards the 2nd DosQueryPathInfo call captures the LEVEL_3 info block into the 'fs3' variable.

So for some reason that 1st call fails here, but it only fails when executed from within my REXX script. If oo.exe is ran directly from CLI that works fine.

Here is a quick output of cflow showing where the oo.exe code halts:

Code: [Select]
    1 {   0} +-main: int (int argc, char *argv[]), <oo.c 194>
    2 {   1}   +-RwsQueryVersion: <>
    3 {   1}   +-ErrMsg: void (char *msg, ULONG rc), <oo.c 1297>
    4 {   2}   | +-RwsGetRcString: <>
    5 {   2}   | +-sprintf: <>
    6 {   2}   | +-DosWrite: <>
    7 {   2}   | \-strlen: <>
    8 {   1}   +-printf: <>
    9 {   1}   +-ParseArgs: BOOL (int argc, char *argv[]), <oo.c 287>
   10 {   2}   | +-ParseExe: int (char *pArg), <oo.c 544>
   11 {   3}   | | +-strrchr: <>
   12 {   3}   | | +-strspn: <>
   13 {   3}   | | +-strchr: <>
   14 {   3}   | | \-UppercaseArg: BOOL (char *pArg), <oo.c 839>
   15 {   4}   | |   +-DosMapCase: <>
   16 {   4}   | |   \-strlen: <>
   17 {   2}   | +-printf: <>
   18 {   2}   | +-strspn: <>
   19 {   2}   | +-strchr: <>
   20 {   2}   | +-ERRBRK: <>
   21 {   2}   | +-ParseOption: int (char *pArg), <oo.c 591>
   22 {   3}   | | +-UppercaseArg: 14
   23 {   3}   | | +-strchr: <>
   24 {   3}   | | \-ErrMsg: 3
   25 {   2}   | +-ParseObject: BOOL (char *pArg, char *pPath, PULONG pType), <oo.c 640>
   26 {   3}   | | +-printf: <>
   27 {   3}   | | +-strchr: <>

DEBUG => This next statement is what catches the DosQueryPathInfo API call's RC=15

   28 {   3}   | | +-ERRBRK: <>

   29 {   3}   | | +-strcpy: <>
   30 {   3}   | | +-ParseHandle: BOOL (char *pArg, char *pPath, PULONG pType), <oo.c 736>
   31 {   4}   | | | +-strlen: <>
...





Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #11 on: January 04, 2021, 10:20:24 pm »
Hi Andreas,

rc = 15 is ERROR_INVALID_DRIVE. So DosQueryPathInfo failed to find the drive of v:\photo. Note that the toolkit docs have a few flaws. Is it a network drive? But strange that your first code block works. I guess we need to see the whole script for more hints on that.

When you're already in a REXX script, why don't you just use the following?
Code: [Select]
rcx = SysSetObjectData( 'v:\photo', 'DEFAULTVIEW=XVIEW;')

Yes, this is a network drive, basicaly a NetDrive connection to my NAS box. My REXX script checks that this location is still accessible every 15 mins. I do this because for some reason my NetDrive connection to this NAS box will go dead. I haven't figured out why it does this, it's only the NAS box itself, other NetDrive connections to Winx machines stay up. So for all I can tell there may be something inherent about the NAS box Samba server that just kills the connection NetDrive has started.

The problem is that numerous shadow objets in my WPS, which point to the NAS box, go dead and there really is no knowing about it unless and until you actually attempt to access that folder.

I tried the suggestion you provided as well. That was in fact my 1st approach. But for whatever reason I could not make that work. The call would execute but openning the shadow folder from WPS still produced an ICON view as opposed to the XVIEW one.

I've attached the whole script here (change the 'txt' to 'cmd' if you pull it into an IDE and want some sort of syntax highliting, etc.). The section where you see this comment is where my various attempts at making this work start:

Code: [Select]
...
/* OK, now run the WPS settings utility */
...

I also included the full clfow output for the oo.exe utility.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 37
  • Posts: 704
  • Karma: +9/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #12 on: January 04, 2021, 11:48:41 pm »
The problem may be that drive V: doesn't support EAs. Then you can't apply a setup string to a file object.
« Last Edit: January 05, 2021, 01:04:22 am by Andreas Schnellbacher »

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 29
  • Posts: 965
  • Karma: +18/-0
    • View Profile
Re: REXX: RxStartSession, what is wrong with this call?
« Reply #13 on: January 05, 2021, 01:28:15 am »
The problem may be that drive V: doesn't support EAs. Then you can't apply a setup string to a file object.

Yes, you are right, the NAS itself does not support EAs, so the NetDrive folder mapping itself does not either. However, the WPS shadow object does accept this setting because running oo.exe from CLI certainly does work. I have my one-off REXX cmd file doing precisely that, it just calls oo.exe multiple times, each time is specific to each folder shadow I have on my OS/2 Desktop.

Yeah, I am stumped by this, but again, not a heavy REXX or C/C++ developer here, so I'm sure there may be a few things I'm just overlooking (I hope  ;D).