* copyright (C) 1984-2019 merrill consultants dallas texas usa

PCTCPUBY will now both always be set to missing for

compatibility with any existing user reports. Use the

ZRBCPU and/or ZRBLCP datasets for equivalent data.

-New ZRBGEI dataset variables (36):

GEICASL ='64-BIT*COMMON*AUX STORAGE*SLOTS'

GEICFFR ='64-BIT*COMMON*FRAMES*FIXED IN REAL'

GEICFR ='64-BIT*COMMON*FRAMES*BACKED IN REAL'

GEICMO ='64-BIT*COMMON*OBJECTS*ALLOCATED'

GEICSIZ ='HIGH*COMMON*AREA*SIZE'

GEICUSE ='HIGH*VIRTUAL*COMMON PAGES*IN-USE'

GEIEHIAL='LSQA/SWA/229/230*ALLOCATED*ABOVE 16M'

GEIELOAL='USER REGION*ALLOCATED*ABOVE 16M'

GEIHIAL ='LSQA/SWA/229/230*ALLOCATED*BELOW 16M'

GEILCMO ='FIXED*MEMOBJECTS*ALLOC IN*COMMON*STORAGE'

GEILCMU ='1MB HIGHVIRT*COMMON OBJECTS*OWNER GONE'

GEILCPR ='1MB HIGHVIRT*COMMON PAGES*BACKED*IN REAL'

GEILCPU ='1MB HIGHVIRT*COMMON PAGES*OWNER GONE'

GEILF4K ='1MB FIXED*FRAMES USED*BY 4K*PAGE REQS'

GEILFPF ='1MB FRAMES*IN LFAREA*SATISFY*1MB REQS'

GEILFUSE='1MB FRAMES*USED BY*FIXED*MEMORY OBJECTS'

GEILOAL ='REGION*ALLOCATED*BELOW 16M'

GEILP4K ='1MB PAGEABLE*PAGES USED*BY 4K*PAGE REQS'

GEILPAG ='1MB FRAMES*USABLE*PAGEABLE*DREF'

GEILPFCI='DEMOTED 1MB*PAGEABLE PAGES*CVRT TO 4K'

GEILPFRI='FAILED 1MB*PAGEABLE PAGES*REQUESTED'

GEILPUSE='1MB FRAMES*USED BY PAGE/DREF MEMOBJECTS'

GEILSIZ ='MAXIMUM*LARGE*FRAME*SIZE'

GEIRBFIX='FIXED*FRAMES*BELOW 16 MB*IN REAL'

GEIRLMO ='LARGE*MEMORY*OBJECTS*ALLOCATED'

GEIRLPR ='1 MB FRAMES*BACKED IN*REAL STORAGE'

GEIRSTRF='HIGH VIRT*COMMON*PAGES*IN-USE'

GEIRTFIX='TOTAL*FIXED FRAMES'

GEISASL ='HIGH VIRT*SHARED MEMORY*AUXSTORAGE*SLOTS'

GEISEQ ='CPC*SEQUENCE*NUMBER'

GEISFR ='HIGHVIRT*SHAREDMEM*FRAMES*BACKED IN REAL'

GEISLTA ='CURRENTLY*AVAILABLE*SLOTS'

GEISMO ='HIGHVIRT*SHAREDMEM*OBJECTS*ALLOCATED'

GEISSIZ ='SHARED*AREA*SIZE'

GEISUSE ='HIGH*VIRTUAL*SHARED PAGES*IN-USE'

GEITOTPI='TOTAL*NUMBER OF*PAGED-IN PAGES'

-The ASMRMFV Dynamic Method will now detect empty RMF

Monitor III VSAM data sets and NOT dynamically allocate

them. Prior to this change the condition was not

detected until the file was opened, but the dynamic

allocation and subsequent open overhead was unnecessary.

-ASMRMFV CSI search summary message RMFV065I now includes

the count of empty data sets found.

-New ASMRMFV message RMFV054* will be issued for any empty

data sets found during CSI scan or VSAM open. (*=I,A,W).

-New ASMRMFV message RMFV055* will be issued for

"imposter" VSAM data sets that have the correct RMF

Monitor III CISIZE and RECSIZE, but do not have a valid

DSH table id of 'DSIG3'. (*=I,A,W).

-New ASMRMFV message RMFV051* is issued for all data set

type errors (not a VSAM RRDS) during a CSI scan or VSAM

open and always includes the DDNAME. (*=I,A,W).

-New ASMRMFV message RMFV067* now directs users to IBM

message IDC3009I for non-zero Catalog Management Return

and Reason Codes produced during a CSI search.

(*=I,A,W).

-Show ASMRMFV error message RMFV066E during Dynamic

Allocation abend.

-Show ASMRMFV message RMFV067E during Catalog/Dsname CSI

search error abend.

-ASMRMFV message RMFV007S could have incorrect Return

and/or Reason Codes shown.

-ASMRMFV message RMFV038* is now message RMFV052*

(*=I,A,W).

-ASMRMFV message RMFV039* is now message RMFV053*

(*=I,A,W).

-ASMRMFV message RMFV037I REPORT= and OUTPUT= settings are

now aligned in output for better readability.

-Multi-severity ASMRMFV error messages controlled by *ERR=

parameter settings and used for a single purpose are now

tailored only once during initialization instead of every

time issued.

-Assemblies of ASMRMFV will no longer print the source

code documentation as this is available to browse in the

ASMRMFV member as well as in ADOCRMFV.

-The ASMRMFV/ZASMRMFV source prologues as well as

ADOCRMFV, JCLRMFV, JCLCRMFV, and JCLDRMFV documentation

members are updated appropriately.

-New variables added to RMF III dataset ZRBLCP:

CPCHOME CPCLPARI CPCLPMAX CPCUPIDV CPCCAPG CPCWMGT

CPCUSEIW LCPUPRNA LCPUONL LCPUDED LCPUWCY LCPUWCN

LCPUICAP LCPUHIPD LCPUONOF LCPUSD LCPUDED LCPUICST

LCPUWCCH LCPUMAXW LCPUABSL LCPUHWCL

-REQUIREMENT: In order to receive these improvements the

current ASMRMFV utility program from this MXG change must

be installed. See MXG SOURCLIB member JCLASM3 for sample

JCL for the assembly and link-edit install steps.
Change 31.180 Detection that a LIBNAME points to a SAS z/OS TAPE-FORMAT

VGETOBS or sequential-format-on-DASD dataset is NOW done by macro

Aug 26, 2013 VGETOBS, so that we can bypass a performance issue, but

Aug 31, 2013 WPS ABENDed with the original VGETOBS because WPS did not

exactly clone the SAS behaviour:

When there is a WHERE clause with PROC SQL's search of

DICTIONARY.TABLES, SAS opens the LIBNAME and scans it,

but WPS ABENDED if the LIBNAME was tape/sequential.

The exposure to this ABEND under WPS occurs when an

input tape/sequential LIBNAME not been OPENed and

VGETOBS's PROC SQL is invoked, for example, when

ASUMUOW is executed standalone. If ASUMUOW instead is

%INCLUDEd as part of the BUILDPDB step, where the input

LIBNAMES to be opened by ASUMUOW are already OPEN,

there is no ABEND.

- History:

When a PROC SQL is issued against DICTIONARY.TABLES that

uses a WHERE clause referencing a LIBNAME that has not

yet been opened or scanned, SAS reads that LIBNAME to

find all SAS Datasets (MEMNAME) in that data library, to

populate that table. But, if the LIBNAME is on tape,

then every tape volume must be mounted and read, since

there is no directory of MEMNAMEs on tape data libraries.

To eliminate that waste of CPU and I/O and the elongated

elapsed time, VGETOBS was enhanced to detect that the

LIBNAME is on tape so it can bypass the multi-vol read.

So while the ABEND is a WPS issue, but because we can, to

help MXG users to keep their jobs (and to keep their JOBS

running without ABENDs), the algorithm was revised to get

around the WPS issue and eliminate the multi-tape read.

FOR MXG EXECUTION ON Z/OS ONLY:
VGETOBS now reads the DICTIONARY.TABLES and writes all

of those names to a temporary table, MXGTABLES, which is

then searched for the LIBNAME & MEMNAME (DDNAME & SAS

dataset). Removing the WHERE clause from the first PROC

SQL prevents that first complete READ of the tape.
If BOTH the LIBNAME and MEMNAME are found in MXGTABLES,

then the LIBNAME was already open and VGETOBS passes back

to its caller the MEMNAME, number of OBS, the create date

and the member type, which is the normal information that

is returned by VGETOBS, and VGETOBS was successful.
If the LIBNAME/MEMNAME is NOT found in MXGTABLES, then

DICTIONARY.LIBNAMES is searched, again without a WHERE

clause creating MXGLIBNAMES, which is then searched for

the LIBNAME. If the LIBNAME is NOW found, and if that

libname is NOT tape format, then that LIBNAME does NOT

contain the MEMNAME we are seeking, and MXG will politely

terminate with an explanatory message on the SAS log.

However, if we determine the LIBNAME is a tape-format

library, we assume you know what you are doing and that

the dataset does exists in that LIBNAME and continue.

If the LIBNAME is not found in MXGLIBNAMES or MXGTABLES

then EXTFILES table is searched for the FILEREF=DDNAME,

and if that DDNAME is found to exist, then it has been

allocated in this step, so we execute a DATA _NULL_ step

that reads the first block in that DDNAME, and examine

the text in that first block for the "SAS" or "WPS" text

that uniquely identifies if this is a SAS or WPS dataset

and whether it is disk or tape format.

If we search EXTFILES and do NOT find the DDNAME or we

find that it is NOT a SAS or WPS sequential dataset, then

WE FORCE YOUR JOB TO ABEND WITH A U1950 ABEND:

IEF450I JOBNAME MXGSAS STEP - ABEND=S000 U1950 REASON=00000000

==> NOTE, PREVIOUSLY WE ONLY PRINTED A WARNING MESSAGE.
If it is a disk dataset, then a LIBNAME command is

issued with either the V9 or WPD engine as appropriate

and then we reinvoke VGETOBS, since executing the LIBNAME

statement populates DICTIONARY.TABLES.

But if instead it is a SEQUENTIAL tape-format library (on

tape OR on disk) we look for that MEMNAME in that first

block, and if found, then the LIBNAME/MEMNAME are valid;

normally, VGETOBS is called by VMXGSUM (or a similar MXG

program) so the next SET statement or reference will open

the LIBNAME without spinning the entire tape. A global

MACRO variable VGETTAPES is populated with the now known

tape DDNAME so that for subsequent VGETOBS executions we

will ALWAYs assume the existence of the dataset rather

than looking for it and possibly causing an unneeded spin

of the tape dataset.
But, if the dataset name is NOT on that first record

then, we gamble that you know what you are doing by

telling us to use that LIBNAME and MEMNAME, so we assume

it must exist further into that tape, so we allow the

processing of the dataset to continue, but we print

MXGWARN messages so you'll know why the job took so long.

Of course, if you lied and the dataset does NOT exist in

that DDNAME, then the job will ABEND ungracefully.

-There are two situations that will cause VGETOBS to issue

a USER ABEND 1950 when executing on z/OS:

- DDNAME is NOT in the EXTFILES list of allocated DDs

- DDNAME exists but the first record does not identify

it as a SAS or WPS data library.
FOR MXG EXECUTION ON ASCII ONLY:

For ASCII, a LIBNAME statement must have been issued for

any LIBNAME, since there's no "JCL", and as there are no

tape-format libraries on ASCII, the WHERE clause is used.

If the search in DICTIONARY.TABLES is unsuccessful, then

it doesn't exist, and with no other place to look,

VGETOBS prints an MXGERROR: message that the dataset does

not exist.

FOR THE HISTORICAL RECORD:

The first implementation of the new algorithm removed the

WHERE clause in the first search. After the functional

tests on both ASCII and z/OS were successful, the primary

QA test step run time jumped from 8 to 155 minutes, due

to that removal of the WHERE clause, but also due to the

unique QA environment that allocates every MXG LIBNAME

and every INFILE that has ever been used in MXG, and

creates every MXG dataset that has ever been created from

every input data source MXG has ever supported, so there

are hundreds of LIBNAMEs and thousands of DATASETs, and

with thousands of VGETOBS calls, that small increase in

the search time of a few LIBNAMEs is magnified. In any

real job there will only be a few of LIBNAMEs, and only

those that are already open are searched without the

WHERE, and typically there is only one VGETOBS call per

JCL step, so there is no issue. But, since the only need

for the removal of the WHERE clause is for the z/OS

environment, the final implementation reinstates the use

of the WHERE clause when executing under ASCII.

CHANGE 31.179 Support for Websphere MQ 7.1.0 new subtype 5, 6, and 7:

EXTY1155 DDDDDD DATASET DESCRIPTION SUBTYPE

EXTY1156 TY1155 TYPE1155 SMC POOL HEADER STATISTICS 5

EXTY1157 TY1156 TYPE1156 SMC GETMAIN MANAGER STATISTICS 6

IMAC115 TY1157 TYPE1157 SMC REGION SUMMARY STATISTICS 7

VMAC115

VMXGINIT

AUG 26, 2013

Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.178 WARNING: MULTIPLE LENGTH CAPIFART and more variables when

VMXGRMFI TRNDRMFI was executed the second time because first TRND

AUG 22, 2013 had length 8 but the WEEK.RMFINTRV still had length 5/6.

Now, the variables in RMFINTRV and TRNDRMFI are expanded

to 8 bytes by relocating the LENGTH statement to prevent

that warning (when VARLENCHK=WARN is specified in 9.3).

See Change 31.174.
CHANGE 31.177 SHADOW variable SM01ADCT='ADABAS*COMMAND*COUNT' was INPUT

VMACSHDW incorrectly as an 8-byte duration, but it is 4-byte count.

AUG 27, 2013 -SQL text variable increased to 32000.

SEP 4, 2013

Thanks to Stuart Wildey, MorganStanley, ENGLAND.
CHANGE 31.176 Unused Change Number.
CHANGE 31.175 WARNING: MULTIPLE LENGTHS for PACKNAME corrected, was due

ANALDB2R to a mismatch in compiler faker variable's lengths.

Aug 22, 2013 See Change 31.174.
CHANGE 31.174 WARNING: MULTIPLE LENGTHS for IFAUPTM and ZIPUPTM, with

VMAC7072 RETURN CODE 4 set, can occur with MXG 31.05 because the

Aug 21, 2013 option / INHERIT was not specified when a new PROC MEANS

was used to create the new SUMSTYPE70EN dataset.

Tutorial: WARNING: MULTIPLE LENGTHS message:

This warning message that sets CC=4 was introduced in the

first SAS 9.2 (TS1M0), but there were so many complaints

that a Hot Fix for TS1M0 was created to reverted to SAS

9.1.3 no-warn behavior, and then in SAS 9.2 (TS1M0) the

new VARLENCHK=NOWARN/WARM option, with NOWARN default was

added. So you should not normally see these warnings.

But since there is an underlying issue, VARLENCHK=WARN is

now enabled for the MXG QA stream, and the existing cases

are fixed in the several preceding changes, and will be

caught and corrected in future releases.

Thanks to Don Shelton, Time Customer Service, Inc., USA.

CHANGE 31.173 New variables added to TYPETPMX dataset:

VMACTPMX DBS_I214='DBS_STK*AUTOMATED*3490_SD3'

Aug 20, 2013 DBS_I215='DBS_STK*AUTOMATED*3490_9840'

INCLA ='INCLA*CLASS'

JCL_D ='JCL_D'

OUTCL ='OUTPUT*CLASS'

Thanks to Scott Barry, SBBWorks Inc, USA.
CHANGE 31.172 The SMF 113 counters have different metrics for each CPU

VMAC113 type (z/10, z/196-z/114, and zEC12), but MXG's labels were

Aug 19, 2013 those of the newest processor type. That is unchanged by

default, still, but this change allows you to change those

counter labels if you don't have the zEC12. You only need

to change the old-style macro _XLA113 to the desired token

for the labels, _XLA113A (z/10), _XLA113B (z/196-z/114)

or _XLA113C (zEC12), using this syntax for a z/114:

%LET MACKEEP= MACRO _XLA113 _XLA113B %

Thanks to Perry Lim, Union Bank, USA.

CHANGE 31.171 The use of VIEWs in SMFSRCH, with this straight-forward

VMXGSRCH invocation:

Aug 18, 2013 %SMFSRCH(LOOKFOR=BWM.ABC.LOADLIB,SMFOUT=SMFOUT);

Aug 30, 2013 resulted in this message on the log:

ERROR:UNABLE TO CREATE WORK.TABLES.DATA BECAUSE

WORK.TABLES.VIEW ALREADY EXISTS.

which terminated the search of SMF data in SAS 9.3 & 9.4.

The error is circumvented by changing the temporary table

name to TABLE1 and by removal of all VIEWs, since they are

not needed for this ad hoc, occasionally run program. The

actual SQL Table Cleanup issue will be addressed later.

Thanks to Dan Case, Mayo Clinic, USA.

Change 31.170 Variable SM1209BK (Short Server Name) is added to subtype

VMAC120 9 datasets TYP1209C, TYP1209S and TYPE1209U to permit the

Aug 17, 2013 selection of those records to limit volume when merging.
Change 31.169 -New variables SM1132MT and SM1132MM, machine type and the

ASUM113 model were not input because line 919 should be SM113DLN

VMAC113 instead of SM113DON.

Aug 15, 2013 -For the zEC12, MXG's equations for DWINSORM and DWDASORM

were not updated from the z196/z114 equations causing

large negative values. The equations were updated and

now only a few obs with small negative values are seen.

Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.

Thanks to Don Deese, Computer Management Sciences, USA.
Change 31.168 -New variables added by Version 3 to the BVIR02 dataset:

VMACBVIR HOSTHROT='HOST*THROTTLE'

Aug 14, 2013 (no 02 records with which to validate).

Aug 25, 2013 -New variables added by Version 3 to the BVIR10 dataset:

AVGCPUSE 'CPU*USAGE*PERCENT*AT END OF*INTERVAL'

MAXDCUPC 'MAX*DISK CACHE*USAGE*PERCENT'

REAHOSTH 'HOST*WRITE*THROTTLE*REASON'

REACPYTH 'COPY*THROTTLE*REASON'

READEFTH 'DEFERRED*COPY*THROTTLE*REASON'

(no 10 records with which to validate).

-New variable2 added by Version 3 to the BVIR20 dataset:

DEVMAXDL='MAXIMUM*DELAY'

DEVAVGDL='AVERAGE*DELAY'

DEVINTDL='DELAY*INTERVAL*PERCENTAGE'

-New variables added by Version 3 to the BVIR30 dataset:

MAXCPUSE 'MAX*CPU*USAGE*PERCENT'

AVGCPMAX 'AVG*MAX*DISK*USAGE*PERCENT'

MAXDSKPC 'MAX*DISK*USAGE*PERCENT'

REAHOSTH 'HOST*WRITE*THROTTLE*REASON'

REACPYTH 'COPY*THROTTLE*REASON'

READEFTH 'DEFERRED*COPY*THROTTLE*REASON'

Aug 25: +64 corrected to +54 for misalignment in styp 7.

Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.167A VOLTAGE Release 4.2 subtype 5 records with their triplet

VMACZPRO claiming more segments than can fit in the record have

Aug 13, 2013 only a few unreadable segments at the end of each record,

so this circumvention reads those segments that can be

read based on record length and warns that segments were

skipped. Release 4.3.0 corrects this error, and with

that version installed, this MXG change is NOT required.

(Yes, this is the 2nd Change 31.167, too late to change.)

Thanks to Gennady Katsnelson, IBM Global Technology Services, USA.
Change 31.167 DB2 V8 ONLY. %READDB2(IFCIDS=STATS 225) did not read the

READDB2 V8-only ID=102 Subtype=225 records, causing all QW0225xx

Aug 13, 2013 variables in PDB.DB2STATS for DB2 V8 records observations

to be missing values. Several old tests for NE 225 were

removed to allow T102S225 to be populated.

-DB2 V8 ONLY. Missing value messages from VMACDB2H for V8

records which don't contain QWHCLOTC/QWHCLORO/QWHCLOAU

are eliminated. Important only because they had to be

identified to eliminate them as the cause of zero obs.

Thanks to John Leyland, HP Enterprise Services UK Ltd, ENGLAND.

Change 31.166 Support for IFCID=380 STORED PROCEDURE DETAIL RECORD

EX102380 creates new T102S380 dataset.

IMAC102 -Typo PIB.2 corrected to &PIB.2. for syntax consistency in

VMAC102 IFCID=358, but fortunately had no actual impact on value.

VMXGINIT -Typos QWT02R2-zero instead of -OH in IFCID=196 caused

Aug 12, 2013 second and subsequent segments, if they existed, to be

Sep 12, 2013 re-inputs of the first segment impacting T102S106 data.

Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.

Change 31.165 MXG 31.05, PDB.DB2STAT1 not created if READDB2 STATISTICS

READDB2 option was used, because a typo in Change 31.128 had only

Aug 11, 2013 one period in line 3112, where two were required:

MACRO _LDB2ST1 &PDB2ST1..DB2STAT1 %

With only one period, SAS did what it was told and wrote

the data to the dataset named WORK.PDBDB2STAT1.

Note that the %READDB2 STATISTICS option is archaic and

the STATS option instead has been strongly recommended,

at least in the comments in READDB2:

STATS READ ID=100 SMF RECORD TO CREATE

DB2STATS, DB2STATR DB2GBPST AND

DB2STATB, DB2STAT5

STATISTICS ARCHAIC. READ ID=100 TO CREATE

DB2STATS, DB2STATR AND DB2GBPST,

BUT ALSO WRITES THE REDUNDANT STATS

DATASETS (DB2STAT0/1/2/4/225/B)

THAT ARE ALREADY IN DB2STATS.

Since IBM has created additional DB2 stats IFCIDS over

time, any new interval statistics subtypes will be added

only into the PDB.DB2STATS dataset.

Thanks to Larry Stahl, IBM Global Services, USA.
Change 31.164 Error messages DISKxxxx HAS X NRCOUNTERS BUT DSKSEQ HAS Y

VMACNMON followed by INVALID DO CONTROL error ABEND was caused by

Aug 12, 2013 truly invalid NMON data. The DISKxxxx descriptor records

defined 66 disks, but interval T0166 created a pair of

DISKBUSY/DISKBUSY1 with 185 device's data, but without a

clue that the hardware configuration changed. The DO

Control ERROR is now eliminated, but the bad data can't

be validly processed. Up to 20 messages per HOST will be

printed when DSKSEQNR NE NRDSKSEQ. This text will be

revised if/when a correction from IBM has been tested.

Thanks to Xiaobo Zhang, Fiserv, USA.
Change 31.163 WPS ONLY. The WPS Compiler failed to correctly resolve

ANALDB2R an old-style macro _S102&IFC deep inside READDB2 when it

READDB2 was invoked by ANALDB2R that should have generated the

Aug 8, 2013 _S102023 token for IFCID=023 but instead created _S102004

which is NOT a dataset created by this %ANALDB2R, which

caused ERROR: DATASET WORK.T102S004. We have provided

a detail trace to our customer to open a problem with WPS

support, which appeared to be an incorrect order of macro

resolution between old-style and new-style %macros, but

but we found that by replacing the _S102&IFC token that

was not correctly resolved, with this alternative syntax

%LET IFCSTRING=S102&IFC;

_&IFCSTRING

the WPS error appears to be circumvented.

This is the %ANALDB2R invocation that failed, even with

//SMF DD DUMMY because it's a compiler issue and not data

driven:

%ANALDB2R(DB2=ADSN DSN,

PDB=SMF,PMACC01=NO,PMACC02=NO,PMAUD01=NO,SORTBY=DB2,

PMAUD02=YES,PMAUD03=NO,

AUDIT=AUTHFAIL AUTHCNTL DDL DML BIND AUTHCHG UTILITY,

PMSTA02=NO);

Change 31.162 -Variables JOB, the job creating the list, and BETAJOBN,

VMACBETA the job name of the BETA task, were inconsistent/wrong as

Aug 5, 2013 both variables do not always exist, although both were

kept in all datasets. This table identifies which will

exist in each subtype (?? - not yet validated with data):

Subtype BETAJOBN JOB

0 yes yes

1 no yes

2 ?? ??

3 ?? ??

4 ?? ??

5 yes NO

6 ?? ??

7 ?? ??

8 ?? ??

20 yes yes

21 yes yes

22 ?? ??

25 yes yes

40 ?? yes

41 ?? yes

42 ?? yes

49 no yes

50 yes no

51 no yes

-Variable BETAJOB was only kept in BETA20 and should not

have been created, since JOB is the normal variable, but

it is kept to prevent variable not found errors.

-Variable BETALJOB was kept in BETA21/25/40/41/42 but as

it contains the JOB value, those datasets variable JOB

is now correctly populated from BETALJOB variable, which

is also still kept to prevent variable not found errors.

-This change now correctly inputs BETAJOBI for BETAJOBN or

inputs JCTJOBID for JOB in the header, based on subtype,

but only the records above with yes or no are validated.

If you create obs in those other datasets, please send