Long variable issue

Richard Kreiss rkreiss at verizon.net
Wed Feb 3 11:51:57 PST 2021


Ernie,

This just doesn't even come close to answering my question.  Why is the
declared value not able to accept the value of getenv()?
If:
Then: declare uname
If" uname= ""
Then: uname=getenv("username") - in this instance uname should have rkreiss
as value.

The declare is located with all the other declared long variable just before
the last line of the processing table.

I really can't sent Fp Tech the files as the contain information that has to
remain private.  Will PF Tech be willing to sign a confidentiality agreement
with GCC Consulting and CCP with regard to this information.  I would need
to send you their complete database as all of the files would be accessed
and tht is the only way the program can be tested.  Also, I would have to
zip the database and it would be too large to upload.  I would have to use
some other means to upload the zip file.


> -----Original Message-----
> From: Filepro-list
<filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com>
> On Behalf Of Ernie Barnard via Filepro-list
> Sent: Tuesday, February 2, 2021 9:27 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: Long variable issue
> 
> You're not close to the limit.
> 
> Maximum number of labels is determined by the current token table size.
> 
> Runtime programs default to 1000 labels available but it can be increased
to
> 32,767 using PFLBSIZE, token table size dependent as well.
> 
> ( More detail sent via fP Online Support )
> 
> On 2/1/2021 1:04 PM, Richard Kreiss via Filepro-list wrote:
> > I have used the debugger an rkreiss does exist and the issue is that
> > the long variable that should hold rkreiss does not get filled. Uname
> > or runnasme(I tried both a uname is a declared value in the calling
> > processing table.  It was originally declared as local but I changed
> > it to global and used a declare extern uname to pass the value to the
> > called table.  In the original table uname has rkreiss but the field is
blank in the
> called table.
> > Even if I do:
> >
> > If uname = ""
> > Then: uname=getenv("username") - I would like to know why if the field
> > already has a value in the calling table why it is empty in the called
> > table.  No one has been able to answer that question.  No one seems to
> > know if there is a limit to the number of variables that filePro can
> > handle. I am aware that filePro needs to account for dummy fields,
> > long variables, arrays, process labels, field edits both global(115)
> > and local (3) in output processing file , as well as system arrays and
> > other items.  Does filePro load an auto process table for the called
> > table if one is in the directory for that process? I have not gotten
> > an answer to my questions form FP Tech as I don't think they know and
> > may need to research this as no developer has reached this point and
> > had this issue. There are 496 labels in the original input process
> > table, that includes @when process as well  subroutine labels and 36
> > labels in the output process and 1 label in the auto Process table
> > used with this output process. FilePro needs to account for all of
> > these and we do not know what the maximum limit is.  Tis would have to
be a
> combined limit as tech support would have no idea of what this breakdown
> would be.
> >
> > I have a feeling I am the first developer to reach this limit and that
> > is what is causing my issue.
> >
> > Issue:
> >
> > I can declare a variable but it will not hold a value trying to be
> > assigned to it.  Why?  I can see the variable in the debugger but can
> > not get it to hold a value.  When I pass a value using -rx and @px the
> > value is present but if I try to use a declared global to hold the
> > same value and declare extern, the value is blank in the called table.
> > If I define the long variable as uname(32,*), the debugger show the
variable
> > as blank with the total length represented by |                        |
> > instead of || when not having a defined length.
> >
> > This is a process running for a system call to an output processing
> > table which does not hold the declared value being assigned to it..
> > Yes, there is an auto process table that runs with this output process
> > but has 7 declare global variables and 5 dummy fields and an output
> > processing table with 95 long variable and 31 dummy fields of which
> > 14 have defined lengths and edits. One of those fields has a length of
> > 1390 as it hold the information from the file being read.  I can
> > replace getenv() everywhere I want to use uname but it would be easier
> > to use uname in the programming the having to type the
> > getenv("username") each time. I need to use the name in programming.
> >
> >
> >> -----Original Message-----
> >> From: Filepro-list
> > <filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com>
> >> On Behalf Of Jason Garner via Filepro-list
> >> Sent: Saturday, January 30, 2021 8:03 AM
> >> To: filepro-list at lists.celestial.com
> >> Subject: Long variable issue
> >>
> >> I guess the low hanging fruit would be to figure out if rkreiss
> >> actually
> > exists in
> >> the environment.
> >>
> >> Like if you do a msgbox getenv("rkreiss"), is the message box also
> >> blank
> > or does
> >> it populate?
> >>
> >> On Sat, Jan 30, 2021 at 3:07 AM
> >> <filepro-list-request at lists.celestial.com>
> >> wrote:
> >>
> >>> Send Filepro-list mailing list submissions to
> >>>          filepro-list at lists.celestial.com
> >>>
> >>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>          http://mailman.celestial.com/mailman/listinfo/filepro-list
> >>> or, via email, send a message with subject or body 'help' to
> >>>          filepro-list-request at lists.celestial.com
> >>>
> >>> You can reach the person managing the list at
> >>>          filepro-list-owner at lists.celestial.com
> >>>
> >>> When replying, please edit your Subject line so it is more specific
> >>> than "Re: Contents of Filepro-list digest..."
> >>>
> >>>
> >>> Today's Topics:
> >>>
> >>>     1. Long variable issue (Richard Kreiss)
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>>
> >>> Message: 1
> >>> Date: Fri, 29 Jan 2021 18:59:33 +0000
> >>> From: Richard Kreiss <rkreiss at gccconsulting.net>
> >>> To: "'filepro-list at lists.celestial.com'"
> >>>          <filepro-list at lists.celestial.com>
> >>> Subject: Long variable issue
> >>> Message-ID:
> >>>          <
> >>>
> >>
> MN2PR04MB6767CDA976815F56DE43CA83B7B99 at MN2PR04MB6767.namprd0
> >> 4.prod.out
> >>> look.com
> >>> Content-Type: text/plain; charset="us-ascii"
> >>>
> >>> I declared a long variable in a called processing table.
> >>>
> >>> Declare runname
> >>>
> >>> In the called processing table I have:
> >>>
> >>> If:
> >>> Then: runname=getenv("username")
> >>> If: getenv("username")="rkreiss"
> >>> Then: debug on   (the debugger is activated)
> >>>
> >>> When I evaluate runname is appears as empty ||
> >>>
> >>> When I change the declare to Runname(32*) and check the value of
> >>> runname again, it the field is emp[ty but the |
> >>> | lines are 32 characters apart.
> >>>
> >>> Does any one have any ideas as to why runname is not being filled
> >>> with "rkreiss".
> >>>
> >>> I have asked this question of FP Tech support and so far have not
> >>> received an answer to this problem.  They have asked for other
> >>> information and for mew to clarify what I wrote even though I gave
> >>> them the processing used and the issue I weas having.
> >>>
> >>> I seem to recall that there is a limit as to the number of variables
> >>> one can have but it is not documented.  Could I be passing this
> >>> limit as there are a lot of declared values in the original
> >>> processing table as well as the called table.  The called table is
> >>> in a different
> >>> folder(directory) then the original processing. Is the total of the
> >>> variable a combination of both tables?
> >>>
> >>> I may be able to eliminate some of the declared variables in the
> >>> called table as this is a copy of one that is for a different
> >>> purpose and I did not remove all of the declared values used in the
> >>> other
> > program.
> >>> Any assistance with this issue will be greatly appreciated.
> >>>
> >>>
> >>> Richard Kreiss
> >>> GCC Consulting
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -------------- next part -------------- A non-text attachment was
> >>> scrubbed...
> >>> Name: winmail.dat
> >>> Type: application/ms-tnef
> >>> Size: 15524 bytes
> >>> Desc: not available
> >>> URL: <
> >>> http://mailman.celestial.com/pipermail/filepro-list/attachments/2021
> >>> 01
> >>> 29/1638b6ac/attachment.bin
> >>>
> >>> ------------------------------
> >>>
> >>> Subject: Digest Footer
> >>>
> >>> _______________________________________________
> >>> Filepro-list mailing list
> >>> Filepro-list at lists.celestial.com
> >>> http://mailman.celestial.com/mailman/listinfo/filepro-list
> >>>
> >>>
> >>> ------------------------------
> >>>
> >>> End of Filepro-list Digest, Vol 204, Issue 10
> >>> *********************************************
> >>>
> >>
> >> --
> >> Jason Garner
> >> Systems Administrator
> >>
> >> 1801 Oberlin Rd, Suite 204
> >> Middletown, PA 17057
> >> Work   717-985-1122 x 1139
> >> Mobile 717-645-3521
> >> <tim.barr at evalsvs.com>jason.garner at evalsvs.com
> >> -------------- next part -------------- An HTML attachment was
> >> scrubbed...
> >> URL: <http://mailman.celestial.com/pipermail/filepro-
> >> list/attachments/20210130/11de3011/attachment.html>
> >> _______________________________________________
> >> Filepro-list mailing list
> >> Filepro-list at lists.celestial.com
> >> Subscribe/Unsubscribe/Subscription Changes
> >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > Subscribe/Unsubscribe/Subscription Changes
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> --
> Ernie Barnard Jr.
> 
> 
> 
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-
> list/attachments/20210202/42c86b0a/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list



More information about the Filepro-list mailing list