I cannot comment on the question concerning NOTE, POINT, ftell() and
fseek(),
but, in general, when processing COPY instructions (or INCLUDE files, in
other languages),
you don't need such file positioning functions, because you can easily
keep files open
while processing other files which contain the COPY books or include
files and then
return to the original file. You only need to manage a table (or stack)
of file pointers and
return to the previous file pointer in the stack, when you reach the end
of the file
of your "current" include file.
I've done this recently, when I processed include files coming from
different
CA-librarian master files, this way implementing a search chain on
CA-librarian
include statements, which CA-librarian does not provide ... CA-librarian
requires
instead, that all include files come from one single master file.
I support up to 9 CA-Librarian master files, but there are much more
members which
can be open simultanously (the include nesting level may be much deeper
than 9).
This was CA-Librarian on VSE, BTW; but it should work much the same way
on MVS.
Kind regards
Bernd
Am 31.03.2022 um 14:13 schrieb Paul Gilmartin:
If SYSLIB contains UNIX directories and my program contains
nested COPY instructions, does HLASM use NOTE and POINT
to return to the point of the outer copy member?
I know it took a couple APARs to get this finally working.
Was the fix ini BPAM, or did HLASM resort to ftell() and
fseek()? Or did it resort to an enormous buffer making
POINT unnecessary?
