Here’s an example slightly dumbed-down from a routine we use to do things only to files with more than seven records.  You could adapt it by changing  “> 7” to “=   0” on the third finfo. It’s a bit fancier that you really need, because I insisted on echoing the file name and eof to the job listing, padded with blanks so the columns add up.

!PURGE   MG, TEMP    >   $NULL
!FILE    MG; REC=-72,,F,ASCII;MSG;DISC=5000,32,1;TEMP
!LISTFILE    fileset.group,6           >>  *MG
!
!SETVAR  _CNT        0
!IF  FINFO("MG",'EXISTS')    =   TRUE
!    WHILE  FINFO("MG","EOF")    >   0   DO
!        INPUT   _LONGNAME   <   MG
!        SETVAR  _NAME_X     lft('!_LONGNAME',26)
!        IF  FINFO(_NAME_X,"exists")
!            SETVAR  _EOF    FINFO(_NAME_X,'EOF')
!            SETVAR  _EOF_X  RHT('     !_EOF',6)
!            IF  FINFO(_NAME_X,"eof") >  7
!                ECHO File-Name = !_NAME_X    EOF = !_EOF_X
!                your commands go here, like maybe "purge !_NAME_X" or "print
!_NAME_X"
!                SETVAR  _CNT    _CNT + 1
!            ENDIF
!        ENDIF
!    ENDWHILE
!ENDIF
!IF  _CNT        =   0
!    your "nothing found" routine goes here, if any

!ENDIF

Is there a clean way to determine, either in a command file or programmatically, whether I am running in batch? I don't want to simply check the variable HPINTERACTIVE or HPJOBTYPE. Those don’t do what I want if we are in a session that was created by a REMOTE HELLO from a batch job on a remote machine.  I want a way to know that such a “session” is really “batch.”

Cathlene Mc Rae of HP's Response Center replies:

When a job is streamed on a system the hp variable set for the job are as  follows:

HPSTREAMEDBY = CATHLENE,MGR.MCRAE (#S102) HPJOBTYPE = J
HPINTERACTIVE = FALSE

When the job does a dsline system and a remote hello the following variables  are set for the remote session:

:remote showvar
 HPSTDIN_ACCESS_TYPE = NS/VT
 HPVT_CLIENT_LDEV_NUM = JOB INPUT SPOOLER  HPVT_CLIENT_JOB_NUM = #J14
 HPVT_CLIENT_JOB_NAME = MGR.MCRAE

 HPINTERACTIVE = TRUE
 HPJOBTYPE = S
 HPSTREAMEDBY = CATHLENE,MGR.MCRAE (#S102)

The variable set when a session does a dsline system and a remote hello are:

HPSTDIN_ACCESS_TYPE = NS/VT
HPVT_CLIENT_LDEV_NUM = 3
HPVT_CLIENT_JOB_NUM = #S102
HPVT_CLIENT_JOB_NAME = MGR.MCRAE     

So, how can you tell if a job or session started the remote  session?

Answer:

The hpvt_client_ldev_num will be may be set to “job input spooler “ and hpvt_client_job_num will be “#J”.

Tony Summers adds:

Please note, the variables won't exist if it's a local session. In the past I've used the BOUND command to prevent command scripts from failing.

IF BOUND(HPVT_etc)    
  IF  (HPVT_etc = "whatever")
      etc

Walter Murray, who posed the original question, commented:

The most clever suggestion was from Jeff Vance, who pointed out that you can try setting HPTYPEAHEAD to TRUE, and then check HPCIERR.  Sure enough, that works!

In the end, I decided to go with a technique that several others suggested, and Cathlene amplified.  There are a number of HPVT_xxx variables that are sometimes set.  I decided to check HPVT_CLIENT_JOB_NUM.

Here's what I came up with:

COMMENT *  Are we running in batch or interactively?
COMMENT *
SETVAR RUNNING_IN_BATCH FALSE
IF HPJOBTYPE = "J"
 SETVAR RUNNING_IN_BATCH TRUE
ELSE
 COMMENT *  A real session, or REMOTE HELLO from a Job?
 IF BOUND(HPVT_CLIENT_JOB_NUM)
   IF TYPEOF(HPVT_CLIENT_JOB_NUM) = 2
     IF LEN(HPVT_CLIENT_JOB_NUM) > 2
       IF STR(HPVT_CLIENT_JOB_NUM,2,1) = "J"
         SETVAR RUNNING_IN_BATCH TRUE
       ENDIF
     ENDIF
   ENDIF
 ENDIF
ENDIF

I face a serious situation on our HP 3000. A batch job which used to run for about 30-45 minutes (stores data in an IMAGE detail with about 3.2 million entries) runs now 4 hours and longer to handle the same amount of data. What should I look for?

Brian Donaldson replies:

Did anyone make program changes? Or change locking strategies in the program -- locking data sets and/or data items and not DBUNLOCKing until the program completes, instead of DBUNLOCKing immediately after an update (DBPUT, DBDELETE, DBUPDATE) has completed?

If TurboIMAGE is the problem, then you can investigate the possibilities of synonym entries in your automatic and manual masters.

If you just use HOWMESSY, however, it doesn’t give you info regarding the offending entries causing the problems. It will just give you a percentage of synonyms in a particular data set, "SET-A has 23% synonyms." Not very helpful if you want to find out the offending entries that caused the collision in the first place.

For example:

data-set-a (master), key item = data-item-a
data-type= X4, key-value="ABCD"

hashes to IMAGE record 1234. Record 1234 already occupied by key value “XXYY”. So then IMAGE has to go find a slot to place key value “ABCD”.

With each DBPUT this hashing/collision nightmare could slow you down immensely.

If TurboIMAGE is your problem you can try changing the capacities on your offending automatic and manual master data sets.

Integer keys on master sets work fine if the key value is between 1 and the capacity of the data set.
When a key value is greater than the capacity then watch out -- the synonym problem will bite you. Generally speaking, “X” type key items (search items in detail sets) work best.

If your app uses integer keys, you cannot just change the data types of these keys without having to modify every piece of source code that manipulates these data sets. Then you have to recompile the entire application. Not exactly the optimum solution.

If you determine that TurboIMAGE is your problem I suggest you go straight to the big guns for assistance and call the gurus at Adager. Those guys will be able to help you best, I’m sure of it.