|
midrange.com
Hi Bruce...
I agree wholeheartedly with your statements in #2 & #3 (quoted below),
but have some questions about #1.
You say that he should look for *LOVAL instead of *BLANKS (other
people have also suggested *ALLx'00', as well) But, what happens
if the user space was created with, say, only 1 byte? Then extended
by the QUSLMBR API? What will be at the end, then? Or what happens
if the data returned by the API fills up all of the available area
in the *USRSPC. Wouldnt his call to QUSRTVUS then fail, causing
the program to never complete normally?
It seems to me (after considering it further) that not only are you
100% right in your "Point #2" below, (a point which I also tried to
make in my earlier message, as well) but it seems to be the ONLY
reliable method of doing this. :)
I guess the purpose of this message is just to emphasize that :)
Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.
bvining@VNET.IBM.COM wrote:
> ---------------- Part 1 ----------------
> Just a few observations:
>
> 1) I suspect that the *USRSPC may be being created with a x'00' (nul
> rather than x'40' (blank) initializer. Your RCRTUS *PGM would be
> the place to check if this is true. If so, your compare should b
> to *LOVAL rather than *BLANKS.
>
> 2) List APIs return the number of entries found in the *USRSPC gener
> header entry at offset 133. By using this value to control the
> loop you do not have to assume a given value such as *BLANKS or
> *LOVAL to exit the loop. This generic header can be found in the
> Programming Tips chapter of the System API Reference, and also
> member QUSGEN of QSYSINC/QRPGSRC or QSYSINC/QRPGLESRC.
>
> 3) This program is hard coded with API values that may not always ho
> true. Rather than always going to offset 513 (STRPOS) for the
> first
> returned list entry the program really should find this offset
> value
> in the *USRSPC generic header (offset 125) of the List API.
> Likewise,
> rather than always adding 10 to STRPOS to access the next list
> entry
> the program should really add the value found in the *USRSPC
> generic
> header (offset 137) Size of each entry. By not hardcoding these
> types of values, your program can become tolerant of format
> expansions/changes (which do periodically occur).
>
> If this program is just a one time shot, then you can ignore 2 and 3
> above; but if this program is intended to run for the next umpteen
> years and releases I would suggest using the above approaches for
> processing the returned list.
>
> Bruce Vining
>
> >
> >Hi All,
> >I have a unique problem in that I wrote a small pgm to simply copy
> members
> >of a source file to a folder.
> >The loop where RECARR(X) eventually becomes blank and should then
> leave
> >does not seem to work.
> >I ran it in debug and physically saw RECCARR(X) contained *blanks a
> then
> >watched it continue processing.
> >Is there something inherently wrong with the logic which I can't se
> or is
> >there something else happening here?
> >This is not the first time I have seen this happen ]
> >
> >DSPC_NAM S 20 INZ('MBRLIST QTEMP')
> > DFMT_NAM S 8 INZ('MBRL0100')
> > DOVERRIDE S 10 INZ('1')
> > DSTRPOS S 9B 0 INZ(513)
> > DDTALEN S 9B 0 INZ(10)
> > DRETCODE S 30
> > DRECARR S 10 DIM(9999)
> > DDB_FILE S 20
> > DX S 5 0
> > DTESTLEN S 2 0
> >
> > DCMDLEN S 15 5
> > DCMD1 S 18 INZ('CPYTOPCD FROMFILE('
> > DCMD2 S 8 INZ(') TOFLR(')
> > DCMD3 S 11 INZ(') FROMMBR(')
> > DCMD4 S 8 INZ(') TODOC(')
> > DCMD5 S 15 INZ(') REPLACE(*YES)')
> > DTODOC S 13
> >
> > DCOMMAND S 110
> >
> >
> > C *ENTRY PLIST
> > C PARM FILENAME 1
> > C PARM LIBRARY 1
> > C PARM MEMBER 1
> > C PARM FOLDER 1
> >
> > C MBRLIST PLIST
> > C PARM SPC_NAM
> > C PARM FMT_NAM
> > C PARM DB_FILE
> > C PARM MEMBER
> > C PARM OVERRIDE
> >
> > C RTVLIST PLIST
> > C PARM SPC_NAM
> > C PARM STRPOS
> > C PARM DTALEN
> > C PARM RECARR(X)
> > C PARM RETCODE
> >
> > C QCMDLIST PLIST
> > C PARM COMMAND
> > C PARM CMDLEN
> >
> >
> > C EVAL DB_FILE = FILENAME + LIBRARY
> >
> > C IF MEMBER = '*ALL'
> > C CALL 'RCRTUS'
> > C PARM SPC_NAM
> > C CALL 'QUSLMBR' MBRLIST
> > C ENDIF
> >
> > C CLEAR X
> > C DOU RECARR(X) = *BLANKS
> > C EVAL X = X + 1
> > C CALL 'QUSRTVUS' RTVLIST
> > C EVAL STRPOS = STRPOS + 10
> > C ENDDO
> >
> >
> > C CLEAR X
> > C DOU RECARR(X) = *BLANKS
> > C EVAL X = X + 1
> > C CLEAR TESTLEN
> > C EVAL TESTLEN = %LEN(%TRIM(RECARR(X)))
> >
> > C IF RECARR(X) = *BLANKS
> > C LEAVE
> > C ELSE
> >
> > C CLEAR TODOC
> > C IF TESTLEN > 8
> > C EVAL TODOC = %SUBST(RECARR(X):1:8) +
> '.'
> > C + %SUBST(RECARR(X):9:2)
> > C ELSE
> > C EVAL TODOC = RECARR(X)
> > C ENDIF
> >
> > C EVAL COMMAND = CMD1 + %TRIM(LIBRARY)
> '/'
> > C + %TRIM(FILENAME) + CMD2 +
> %TRIM(FOLDER)
> > C + CMD3 + %TRIM(RECARR(X)) + CMD4
> > C + %TRIM(TODOC) + CMD5
> >
> >
> > C EVAL CMDLEN = %LEN(%TRIM(COMMAND))
> > C CALL 'QCMDEXC' QCMDLIST
> > C ENDIF
> > C ENDDO
> >
> > C SETON
> LR
> >
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List! To submit a new *
* message, send your mail to "RPG400-L@midrange.com". To unsubscribe *
* from this list send email to MAJORDOMO@midrange.com and specify *
* 'unsubscribe RPG400-L' in the body of your message. Questions should *
* be directed to the list owner / operator: david@midrange.com *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
