|
Hi Jeff,
If you're using Glenn's command definition, you need to be aware of what
the system does when you use a type that includes ELEM statements. Check
out http://www.ibm.com/support/knowledgecenter/ssw_i5_54/cl/elem.htm.
For the parm defined by
PARM KWD(PERIOD) +
TYPE(E01C5) +
CHOICE(*NONE) +
PROMPT('Time period for log output' 2)
E01C5: ELEM TYPE(E01FF) +
CHOICE(*NONE) +
PROMPT('Start time and date')
ELEM TYPE(E0272) +
CHOICE(*NONE) +
PROMPT('End time and date')
E01FF: ELEM TYPE(*TIME) +
DFT(*AVAIL) +
SPCVAL( +
(*AVAIL 000000)) +
EXPR(*YES) +
PROMPT('Beginning time')
ELEM TYPE(*DATE) +
DFT(*CURRENT) +
SPCVAL( +
(*CURRENT 000004) +
(*BEGIN 000005)) +
EXPR(*YES) +
PROMPT('Beginning date')
E0272: ELEM TYPE(*TIME) +
DFT(*AVAIL) +
SPCVAL( +
(*AVAIL 235959)) +
EXPR(*YES) +
PROMPT('Ending time')
ELEM TYPE(*DATE) +
DFT(*CURRENT) +
SPCVAL( +
(*CURRENT 000004) +
(*END 000006)) +
EXPR(*YES) +
PROMPT('Ending date')
here's what the system is going to pass to the CPP (Command Processing
Program):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
25 26 27 28 29 30 31 32 33 34 35 36
00 02 00 15 00 06 00 02 F2 F3 F5 F9 F5 F9 F0 F0 F4 F0 F0 F0 F0 00 02 F0
F0 F0 F0 F0 F0 F0 F0 F4 F0 F0 F0 F0
^ ^ ^ ^ ^ ^ ^ ^
^
| | | | | | | |
Beginning of value for 1st ELEM's 2nd ELEM, i.e. "Starting
date"
| | | | | | |
Beginning of value for 1st ELEM's 1st ELEM, i.e. "Starting time"
| | | | | | Offset
x'0015' is beginning of 1st ELEM.
| | | | | Beginning of value for 2nd
ELEM's 2nd ELEM, i.e. "End date"
| | | | Beginning of value for 2nd ELEM's 1st ELEM, i.e.
"End time"
| | | Beginning of ELEM at offset x'0006'. Note that this is
the 2nd ELEM
| | Offset to second ELEM's value within this parm
| Offset to first ELEM's value within this parm
Number of elements in the list
The first thing to notice is that it's passing 36 bytes, not 26. That's
because ELEM statements indicate elements in a list, so the first thing the
system tells you is how many elements there are in your list, in this case
2. Then it passes you a list of offsets to the beginning of each ELEM.
The second thing to notice is that the first offset is larger than the
second offset. That means the value for the first ELEM comes /after/ the
value for the second ELEM.
The third thing is that each of those 2 ELEMs is defined as two more
ELEMs. So the first thing you get in the value for that ELEM is the number
of ELEMs in /that/ list. Because these secondary ELEMs are defined as basic
types (i.e. *DATE and *TIME), there are no offsets to those values, you
just have to know the size for each type.
For the *TIME data type, the system passes a 6-digit zoned decimal number
of the format hhmmss.
For the *DATE data type, the system passes a 7-digit zoned decimal number
of the format cyymmdd.
Since the PARM is not defined as a list itself (i.e. MAX(1)), the number
of ELEMs will always be 2. Same for the sub ELEMs. So you can define your
CL variable to hold the parm as *char 36. Then retrieve the values as
start date: %sst(&P01 30 7)
start time: %sst(&P01 24 6)
end date: %sst(&P01 15 7)
end time: %sst(&P01 9 6)
You can convert the dates with the CVTDAT command.
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx>
/On 10/21/2016 11:00 AM, Jeff Young wrote:
Glen,--
Using the information provided, I created a test command and program to
determine what data is passed:
This is my CL program:
PGM PARM(&p01)
dcl &p01 *char 26
chgvar &p01 &p01
return
ENDPGM
Using the default values, I get this in my input parm:
Time period for log output:
Start time and date:
Beginning time . . . . . . . . *AVAIL Time, *AVAIL
Beginning date . . . . . . . . *CURRENT Date, *CURRENT, *BEGIN
End time and date:
Ending time . . . . . . . . . *AVAIL Time, *AVAIL
Ending date . . . . . . . . . *CURRENT Date, *CURRENT, *END
EVAL &p01
&P01 = ' 2359590040000 000'
EVAL &p01 :x
00000 00020015 00060002 F2F3F5F9 F5F9F0F0 - ........23595900
00010 F4F0F0F0 F00002F0 F0F0.... ........ - 40000..000......
What am I missing?
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.