Ummm... LF is 0A, not 04. . . but your code seems to know that.
JOB's CCSID is where I'd look. But we don't know how the LF got into there (reading a text file perhaps? via read() perhaps?), and we don't know what happens to it after %REPLACE (so that you know something's not right) or how _whatever_that_is_ happens. So it's a bit of a leap.
++
Dennis
++
"If you steal something small you are a petty thief, but if you steal millions, you are a gentleman of society."
-- Greek Proverb
"We hang the petty thieves and appoint the great ones to public office."
-- Aesop
Bravely sent from my Galaxy tablet phone.
++
James Lampert <jamesl@xxxxxxxxxxxxxxxxx> wrote:
Given the following block of code:
C CLEAR LFPOS 5 0
C EVAL LFPOS = %SCAN(X'0A':EVENTDTLX)
C DOW LFPOS > 0
C EVAL EVENTDTL = %REPLACE('\n':EVENTDTLX:LFPOS:1)
C EVAL LFPOS = %SCAN(X'0A':EVENTDTLX)
C ENDDO
and the following data in EVENTDTLX:
00000 C9409389 928540A2 9781944B 0A0AC940 - I like spam...I
00010 93899285 40A29781 944B0A0A C9409389 - like spam...I li
00020 928540A2 9781944B 40404040 40404040 - ke spam.
I get completely different behavior, depending on whether it executes in
an interactive job or in a server job:
In an interactive job, it behaves correctly, replacing each hex '04'
byte (an ASCII linefeed; not quite sure what it is in EBCDIC) with a
backslash and a lowercase 'n', producing a final value for EVENTDTL of
"I like spam.\n\nI like spam.\n\nI like spam."
But in a server job, the %REPLACE is evidently doing absolutely nothing,
as if it's somehow treating the '\n' the way C would treat it (an escape
sequence representing a linefeed), with the result that this thing
tightloops.
Has anybody ever heard of such a thing happening?
The server program uses HTTPAPI to call the Google Calendar web
services, while the test program I executed on a terminal makes no
explicit external calls whatsoever.
--
JHHL
As an Amazon Associate we earn from qualifying purchases.