We have a client that is getting an error 99 in *plus/proj/pathinfo on PXP sessions that are running in Linux as cron tasks (ie: there is no Windx connected session).  It appears that this program is related to the TortoiseSVN functionality, but we have never used ANY of the SVN functionality.

The client system is running PXP10, and the line of code getting an error is: 0146 LET api=NEW("[lcl]*obj/winapi")   This line appears to require a Windx session to work correctly.  It does NOT get an error when our programs are run via a Windx session.  It only gets the error when a cron-based program is running.

This system is fairly old and has NOT been updated at all for quite some time, so we are really scratching our heads on why this problem would suddenly appear.  Our guess is that somehow, a program was added to SVN, and is now resulting in this error.  That's just a wild guess at this point, since we have no familiarity with SVN.  Our staff and some of the client staff do have access to PXP consoles, so it's possible that somebody fat-fingered something and turned this on. 

Anyone have any suggestions on how to determine if SVN was somehow turned on for a particular program?

Further info:
We have a utility program named "ischn", which is used for closing channels.  We call that utility program with a line label (ie: call "ischn;CLOSE") to close the open channels.  The error 99 is reported on that CLOSE line label.  So, as soon as that line label is hit, PXP ends up in /usr/pxp10/lib/_plus/proj/pathinfo at line 146, where the actual error 99 occurs.  The prior level program is line 264 of /usr/pxp10/lib/_plus/proj/pxdta

Perfect!  Thanks, Mike!

I read the header into r$, and got the value.  Looks like I have room to add a few more really_long_variable_name$

-}?dec(mid(r$,101,4))-dec(mid(r$,105,4))
 27173

Thanks, Ken.  That blows my idea out of the water.  We're getting an occasional error 278 on a memory file, so I was thinking it was a problem with the client.  Back to square one, I guess!

Yes.  Our implementation is done entirely within PXPlus using the Avalara SOAP/XML interface.  Avalara is one of the few API's that is very well documented, and they have a fully-functional test system that can be used during development.  Our implementation has been in use for years, since back when SOAP/XML was the only option.  We generate all of the SOAP data and then do the communication using [TCP] ports within PXPlus.  Avalara isn't really pushing the SOAP implementation any longer, since they prefer to use JSON.  That's even better and easier than SOAP, and building JSON with PXPlus is really easy.  We send all of the web calls using our own logic, but there are utilities within PXPlus to generate web service calls - others here on the forums are better able to address those questions.  Let me know if you have questions about integrating Avalara (or other tax software.  I've worked on a few.)

Jeff, I've used www.eztexting.com for years.  It has a simple interface, but also more extensive functionality if necessary.  You can buy blocks of credits, or monthly/yearly plans.  It also allows you to login to the site and check the status of any text message if there are problems.  You can also get a 'short code' which makes it easier for the recipients to know who is texting them (and thus not block the number, which is the only problem I ever ran into.)

Sending a text is simply a matter of opening an HTTPS connection, or using any of the utilities in Providex to make the connection.  An example of the URL is below:

https://app.eztexting.com/api/sending/?user=MyLogin&pass=MyPassword&phonenumber=8885551212&subject=TestMessage&message=This_Is_A_Test&express=1

Thanks for the tips, Mike.  Based on your explanation of how the Linux locks work, I did find some old logic further down the stack in called programs which read the record (and thus clear the extract).  They are obviously a problem, but that logic isn't executed in these two instances.  Still, it shows that there might be a few other bugs hiding away that i haven't found yet!   I'll keep digging, and look into using the SB and XI params. 

Recently, we've had a couple instances where the EXTRACT on a channel *seems* to be failing to prevent other processes from accessing the record, and I'm trying to figure out if that is really the case, or why.  I'm not certain that is the problem, but it's really the only logical explanation I can find.

We have an order update process that EXTRACTs the order record and writes the record to a different file, but never touches the extracted channel again until it REMOVEs the record when done.  The process hasn't changed for years, and has never been a problem.  Recently, a couple of the records were duplicated, which (seemingly) could only happen if two processes had extracted the record at the same time.

The two processes that run are both using the same FID of "IO", but I don't think that should matter.   There servers are Linux (RedHat) with multiple CPU's, and are fairly new and fast servers, so the processing time is milliseconds when this occurs.  I'm wondering if there is some write caching with the OS or hardware that is affecting this, but don't know how to check that.

In searching these forums and the documentation, I've seen suggestions of using "TIM=0" on the extract, and see that there is a FLUSH command to flush the write buffer to disk.  I don't know if either of these would be useful, but would appreciate any feedback or suggestions!

I'm not aware of a utility, but I've done this is a few programs.  The groups used by *wingrp are really just a string of data.  The first 3 characters is the number of controls in the group, and this is followed by a series of 3-character strings which are the BIN value of the controls.  Following this is a string of data representing screen items without a control number (like lines/frames/labels), which are a little different.

Groups are created in *winproc.dsp in the DEF_GRP section, and you can use that to figure out how the group string is created.  You can also see how it is used in *wingrp.

If you're just trying to create a group that has controls in it (ie: buttons, checkboxes, dropboxes, etc.), below is a simplified program that shows how to do that.

One caveat:  If you're using Nomads, it's probably best to have the group defined on the panel by default with at least one control, since Nomads does keep track of the group names.  You should be able to modify the group after that without a problem.

0010 BEGIN
0020 PRINT 'CS'
0030 LET test1.ctl=10; BUTTON test1.ctl,@(0,0,10,2)="Test1"
0040 LET test2.ctl=20; BUTTON test2.ctl,@(10,0,10,2)="Test2"
0050 LET grp$="000"
0060 LET ctlnum=test1.ctl,tp=0; GOSUB DEF_GRP
0070 LET ctlnum=test2.ctl,tp=0; GOSUB DEF_GRP
0080 LET test.grp$=grp$
0090 PRINT @(0,5),'CE',"Group created"; WAIT 2
0100 PRINT @(0,5),'CE',"Hide Group..."; CALL "*wingrp;hide",test.grp$; WAIT 2
0110 PRINT @(0,5),'CE',"Show Group..."; CALL "*wingrp;show",test.grp$; WAIT 2
0120 PRINT @(0,5),'CE',"Disable Group..."; CALL "*wingrp;disable",test.grp$; WAIT 2
0130 PRINT @(0,5),'CE',"Enable Group..."; CALL "*wingrp;enable",test.grp$; WAIT 2
0140 END
0150 !
0160 DEF_GRP:
0170 LET grpct=NUM(grp$(1,3))
0180 LET _g$=BIN(ctlnum,2)+BIN(_tp,1)
0190 LET grp$=STR(grpct+1:"000")+grp$(4,grpct*6)+HTA(_g$)
0200 RETURN