The question's still open, and seems to revolve around the actual function
of CLEANXL - is there a temp file involved and a moment of no XL file?
Duane suggests that I adjust my BUILDXL; while I'm sure it's my code that's
clobbering the XL, it should never get the opportunity - that buildxl is in
there for those times when I want a REALLY clean system and simply purge the
XL before starting.
I might add - I have XL-rez subpgms named
ACCESS ACLIS COMMENT CTLIS CTMNT DATES DTDIF EACHACR EACHACT EACHCTR FCLIS
FCTMNT GAP ISONACR ISONACT ISONCTR PASSWD PRSET SCHED SCREEN TILIS TSTDIS
UALIS UAMNT VUMNT WAIT1 WAIT2 WALIS WAMNT WDLIS WDMNT WMLIS WMMNT WOLIS
and at the time of installation yesterday, my XL was missing the first half
of them. Same bit 2nd time, but I'm not sure it was exactly the same files
missing, but same pattern. It appears that somewhere along the way the XL's
really not there for a moment.
> -----Original Message-----
> From: Tracy Pierce
> Sent: Friday, March 26, 2004 9:11 AM
> To: [log in to unmask]
> Subject: LINKEDIT CLEANXL problem?
>
>
> I'm experiencing weird troubles I've never seen before; maybe
> someone can shed light? Running MPE 6.0 on a 937, I have a
> jobstream JCOBOL which compiles <parm>.src, tries to link
> standalone; if link fails with "no _start found", I make sure
> the XL exists, then try up to 10 times to add to it, running
> CLEANXL at each link (details are below). When I make a
> major change to anything that affects a large number of
> programs, I stream a job which in turn streams my JCOBOL for
> every file in my .src group; this usually works just great,
> leaving me with a freshly compiled complete system, ready for
> installation. But yesterday I did this (and I'll note that
> the number of XL-resident subprograms in the system has been
> growing), checked for trouble spots (via saved $stdlists if
> problems), and installed all. Much to my dismay, my programs
> wouldn't run due to missing XL subprograms, LOTS of them! I
> went through the process again, similar results, and the only
> thing I can think of is that there might be a loophole during
> CLEANXL, via which my XL is non-existent long enough for
> another compilation stream to come along and rebuild the XL,
> clobbering everything already compiled to it. Any ideas
> please? I run up to 10 of these compete-for-the-XL jobs at a time.
>
> Tracy Pierce
>
>
> ! IF LKEDCMD = 1001
> ! comment 1001 = no _start found, NOT a standalone
> program, XL it...
> ! IF NOT FINFO ("XL.!'EXE'","EXISTS")
> ! warnf !WHO2TELL !hpjobnum !hpjobname @No XL.!"EXE"
> found!!!, building i
> ! ECHO BUILDXL XL.!"EXE" > LINKCMDS
> ! ECHO EXIT >> LINKCMDS
> ! CONTINUE
> ! RUN LINKEDIT.PUB.SYS;STDIN=LINKCMDS
> ! ENDIF
> ! SETJCW CIERROR 0
> ! ECHO XL XL.!"EXE" > LINKCMDS
> ! ECHO ADDXL O!"PGM".!"OBJ";REPLACE;SHARE >> LINKCMDS
> ! ECHO CLEANXL;COMPACT >> LINKCMDS
> ! ECHO EXIT >> LINKCMDS
> ! CONTINUE
> ! SETJCW LINKTRIES 0
> ! SETJCW MAXLINKTRIES 10
> ! WHILE LINKTRIES < MAXLINKTRIES
> ! SETJCW LINKTRIES LINKTRIES + 1
> ! CONTINUE
> ! RUN LINKEDIT.PUB.SYS;STDIN=LINKCMDS
> ! IF LKEDSTAT = 0
> ! TELL !WHO2TELL ADDXL O!"PGM".!"OBJ" to XL.!"OBJ" looks ok
> ! SETVAR ADDXL_OK 1
> ! SETVAR LINKTRIES MAXLINKTRIES
> ! ELSE
> ! SHOWJCW CIERROR
> ! SETVAR ADDXL_OK 0
> ! TELL !WHO2TELL ADDXL O!"PGM".!"OBJ" 2 XL.!"OBJ" failed.
> ! IF LKEDCMD = 1112 OR LKEDCMD = 1106
> ! IF LINKTRIES < MAXLINKTRIES
> ! TELL !WHO2TELL at try # !LINKTRIES;XL busy,
> pausing 10...
> ! PAUSE 10
> ! ELSE
> ! SET STDLIST=SAVE
> ! TELL !WHO2TELL Can't open XL after
> !LINKTRIES tries; quitting.
> ! SETVAR ADDXL_OK 0
> ! SETVAR SAVESPOOLFILE 'Y'
> ! EOJ
> ! ENDIF
> ! ENDIF
> ! ENDIF
> ! ENDWHILE
> ! ENDIF
> ! ENDIF
> !ENDIF
>
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
